字节跳动分布式表格存储系统的演进

数据存储引擎方面我们团队采用了业界流行和广泛验证过的 RocksDB 作为存储引擎。与 TiDB, CockroachDB 不同的是，Bytable1.0 的每一个 Tablet 都对应一个 RocksDB 实例，在数据迁移的过程中可以直接进行 RocksDB 的文件读取、传输与写入，不需要额外的扫描、文件生成和文件注入，避免了扫描时多文件归并引起的磁头移动问题、RocksDB 文件注入操作误入 L0 潜在的 Write Stall 问题和 RocksDB 文件注入操作不允许存在并发的普通写入的卡顿问题，实现了快速轻量的数据迁移。此外还可以合理的控制一个 LSMTree 的大小，避免 LSMTree 大小变化后与 RocksDB 参数不匹配的问题。

Split 和 Merge 操作的高效实现则是一个 Tablet 对应一个 RocksDB 实例使用方式引入的难题。对于 Split 操作来说，需要将原先的一个 RocksDB 实例分裂为两个 RocksDB 实例，在我们的实现中利用了 LSMTree 的特性，首先会进行一轮全量的引擎文件硬链，然后停写，再进行一轮增量的引擎文件硬链并打开写入，不可用时间为增量的少量硬链操作所需要的时间。对于 Merge 操作来说，我们对 RocksDB 进行了改造，在文件注入时将是否是注入进来的文件以及 GlobalSequence 都存储在 Manifest 中以便允许直接注入另外一个 RocksDB 实例中文件。与 Split 的过程类似，Merge 的过程也使用了增量的策略进行注入以减少不可用时间。

对比多个 Tablet 公用一个 RocksDB 实例的实现方式，Bytable1.0 的方案在迁移的稳定性和效率与单个 LSMTree 的大小控制上都更有优势，但在分裂与合并的引起的抖动上存在一定的劣势。

下图列举了在相同机器环境下，读写混合场景（读 50%，写 50%）下，Bytable1.0 TabletServer 与 HBase RegionServer 的延时对比。可以看出，Bytable1.0 在平均延时和 p99 延时上均有大幅降低。

2.3 优化细节

---

2.3.1 点读优化

因为我们在 RocksDB 的 KV 模型之上封装了 Table 数据模型，所以无法利用其内置的 BloomFilter 以优化点读性能，我们为每一个 SST 在 Flush 和 Compaction 的过程中手工生成一个 BloomFilter 存储在其 TableProperty 中，并关闭了内置的 BloomFilter 以节省空间。在查询时利用 TableFilter 功能，查找到 SST 对应的手工生成 BloomFilter 进行判断，以优化点读的性能。

2.3.2 热点写入优化

因为我们使用了 Raft 作为副本复制协议，而 Raft 的 Apply 流程是串行的，当出现写入热点时需要通过热点 Tablet 分裂来扩展性能。因为我们的分裂合并操作相对比较重，热点分裂的决策并不适合过于实时和敏感，为了扩展单个 Tablet 的写入性能，我们实现了一种新型的 RocksDB MemTable，写入时仅写入队列中实现了 O(1) 复杂度的在线写入，靠后台线程池将数据并发的写入实际的 SkipList 中，在读取的时候使用 ReadIndex 的机制进行等待。将单线程的最大承载能力扩展到单机的最大承载能力。

2.3.3 写入反压优化

当单个 Tablet 写入过快时，由于硬件资源的略微差距总会有一个副本的速度赶不上其他副本，逐渐累积引起慢副本重装快照。当出现这种情况的时候，如果速度快的两个副本有一个副本机器 Down 机，就会出现这个 Tablet 的短期不可写的情况（其中一个副本正在重装快照）。为了避免这种情况，我们会在一定的条件下进行慢节点反压，限制整体的写入速度，防止慢副本落后过多，实现了极限情况下的可用性提升。此外，我们会设定一定的限制避免磁盘降速故障引起的慢节点反压。