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

下图列举了在相同机器环境下，读写混合场景（读 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 的短期不可写的情况（其中一个副本正在重装快照）。为了避免这种情况，我们会在一定的条件下进行慢节点反压，限制整体的写入速度，防止慢副本落后过多，实现了极限情况下的可用性提升。此外，我们会设定一定的限制避免磁盘降速故障引起的慢节点反压。

2.4 分布式事务

---

目前有些业务场景下存在分布式事务的使用需求，我们团队按照 Percolator 的事务模型，在 Bytable 上层实现了一套分布式事务解决方案，相关内容将在后续专题文章中详细描述。

3. Bytable2.0 追求极致的第二代表格存储系统

=============================

随着 Bytable1.0 的上线与稳定，业务对表格存储系统的成本、稳定性和性能都有了更高的要求。从成本角度来考虑，目前使用三副本方式来存储数据相比分布式文件系统的 EC(Erasure Code) 方案需要多消耗将近一倍的存储空间，此外目前存在三副本独立 Compaction 的情况多消耗了两倍的 CPU。从资源利用率的角度来考虑，目前存在读写请求和磁盘空间占用不匹配的情况，会出现 CPU 资源剩余但磁盘空间用尽或者 CPU 资源用尽但磁盘空间剩余的情况。从与离线 Hadoop 生态系统打通的角度来看，现在做备份、导出和数据加载都比较麻烦。从稳定性的角度来考虑，目前在分裂与合并的过程中仍然存在一定的延时抖动，我们也希望将尾延时优化到极致。从运维复杂度的角度来考虑，基于分布式文件系统可以将我们的服务无状态化，结合 K8S 的调度技术，我们不再需要考虑机器和磁盘的故障报修和重新上线，将极大地降低我们的运维成本。