本文选自“字节跳动基础架构实践”系列文章。

“字节跳动基础架构实践”系列文章是由字节跳动基础架构部门各技术团队及专家倾力打造的技术干货内容，和大家分享团队在基础架构发展和演进过程中的实践经验与教训，与各位技术同学一起交流成长。

自从 Google 发布 Spanner 论文后，国内外相继推出相关数据库产品或服务来解决数据库的可扩展问题。字节跳动在面对海量数据存储需求时，也采用了相关技术方案。本次分享将介绍我们在构建此类系统中碰到的问题，解决方案以及技术演进。

互联网产品中存在很多种类的数据，不同种类的数据对于存储系统的一致性，可用性，扩展性的要求是不同的。比如，金融、账号相关的数据对一致性要求比较高，社交类数据例如点赞对可用性要求比较高。还有一些大规模元数据存储场景，例如对象存储的索引层数据，对一致性，扩展性和可用性要求都比较高，这就需要底层存储系统在能够保证数据强一致的同时，也具有良好的扩展性。在数据模型上，有些数据比如关系，KV 模型足够用；有些数据比如钱包、账号可能又需要更丰富的数据模型，比如表格。

相比而言，range 分区对数据进行范围分区，连续的数据是存储在一起的，可以按需对相邻的分区进行合并，或者中间切一刀将一个分区一分为二。业界典型的系统像 Hbase。这种分区方式的缺点是一、对于追加写处理不友好，因为请求都会打到最后一个分片，使得最后一个分片成为瓶颈。优点是更容易处理热点问题，当一个分区过热的时候，可以切分开，迁移到其他的空闲机器上。

整个系统主要分为 5 个组件：SQLProxy, KVProxy, KVClient, KVMaster 和 PartitionServer。其中，SQLProxy 用于接入 SQL 请求，KVProxy 用于接入 KV 请求，他们都通过 KVClient 来访问集群。KVClient 负责和 KVMaster、PartitionServer 交互，KVClient 从 KVMaster 获取全局时间戳和副本位置等信息，然后访问相应的 PartitionServer 进行数据读写。PartitionServer 负责存储用户数据，KVMaster 负责将整个集群的数据在 PartitionServer 之间调度。

如上图所示是 ByteKV 的分层结构。 接口层对用户提供 KV SDK 和 SQL SDK，其中 KV SDK 提供简单的 KV 接口，SQL SDK 提供更加丰富的 SQL 接口，满足不同业务的需求。

弹性伸缩层通过 Partition 的自动分裂合并以及 KVMaster 的多种调度策略，提供了很强的水平扩展能力，能够适应业务不同时期的资源需求。

存储引擎层采用业界成熟的解决方案 RocksDB，满足前期快速迭代的需求。并且结合系统未来的演进需要，设计了自研的专用存储引擎 BlockDB。

ByteKV 对外提供两层抽象，首先是 namespace，其次是 table，一个 namespace 可以有多个 table。具体到一个 table，支持单条记录的 Put、Delete 和 Get 语义。其中 Put 支持 CAS 语义，仅在满足某种条件时才写入这条记录，如仅在当前 key 不存在的情况下才写入这条记录，或者仅在当前记录为某个版本的情况下才写入这条记录等，同时还支持 TTL 语义。Delete 也类似。

表格接口在 KV 的基础上提供了更加丰富的单表操作语义。用户可以使用基本的 Insert，Update，Delete，Select SQL 语句来读写数据，可以在 Query 中使用过滤（Where/Having）排序（OrderBy），分组（GroupBy），聚合（Count/Max/Min/Avg）等子句。同时在 SDK 端我们也提供了 ORM 库，方便用户的业务逻辑实现。

关键技术

作为一款分布式系统，容灾能力是不可或缺的。冗余副本是最有效的容灾方式，但是它涉及到多个副本间的一致性问题。ByteKV 采用 Raft[1]作为底层复制算法来维护多个副本间的一致性。由于 ByteKV 采用 Range 分片，每个分片对应一个 Raft 复制组，一个集群中会存在非常多的 Raft Group。组织、协调好 Raft Group 组之间的资源利用关系，对实现一个高性能的存储系统至关重要；同时在正确实现 Raft 算法基础上，灵活地为上层提供技术支持，能够有效降低设计难度。因此我们在参考了业界优秀实现的基础上，开发了一款 C++ 的 Multi-Raft 算法库 ByteRaft。

ByteRaft 在原有 Raft 算法的基础上，做了很多的工程优化。如何有效整合不同 Raft Group 之间的资源利用，是实现有效的 Multi-Raft 算法的关键。ByteRaft 在各种 IO 操作路径上做了请求合并，将小粒度的 IO 请求合并为大块的请求，使其开销与单 Raft Group 无异；同时多个 Raft Group 可以横向扩展，以充分利用 CPU 的计算和 IO 带宽资源。ByteRaft 网络采用 Pipeline 模式，只要网络通畅，就按照最大的能力进行日志复制；同时 ByteRaft 内置了乱序队列，以解决网络、RPC 框架不保证数据包顺序的问题。ByteRaft 会将即将用到的日志都保留在内存中，这个特性能够减少非常多不必要的 IO 开销，同时降低同步延迟。ByteRaft 不单单作为一个共识算法库，还提供了一整套的解决方案，方便各类场景快速接入，因此除了 ByteKV 使用外，还被字节内部的多个存储系统使用。

数据同步是存储系统不可或缺的能力。ByteKV 提供了一款事务粒度的数据订阅方案。这种方案保证数据订阅按事务的提交顺序产生，但不可避免的导致扩展性受限。在字节内部，部分场景的数据同步并不需要这么强的日志顺序保证，为此 ByteRaft 提供了 Learner 支持，我们在 Learner 的基础上设计了一款松散的按 Key 有序复制的同步组件。

在字节内部，ByteKV 的主要部署场景为三中心五副本，这样能够保证在单机房故障时集群仍然能够提供服务，但是这种方式对机器数量要求比较大，另外有些业务场景只能提供两机房部署。因此需要一种不降低集群可用性的方案来降低成本。Witness 作为一个只投票不保存数据的成员，它对机器的资源需求较小，因此 ByteRaft 提供了 Witness 功能。

和目前大多数存储系统一样，我们也采用 RocksDB 作为单机存储引擎。RocksDB 作为一个通用的存储引擎，提供了不错的性能和稳定性。RocksDB 除了提供基础的读写接口以外，还提供了丰富的选项和功能，以满足各种各样的业务场景。然而在实际生产实践中，要把 RocksDB 用好也不是一件简单的事情，所以这里我们给大家分享一些经验。

Table Properties

除了上面提到的几个用法以外，这里我们再给大家分享 RocksDB 使用过程中可能遇到的一些坑和解决办法：

1. 你是否遇到过数据越删越多或者已经删除了很多数据但是空间长时间不能释放的问题呢？我们知道 RocksDB 的删除操作其实只是写入了一个 tombstone 标记，而这个标记往往只有被 compact 到最底层才能被丢掉的。所以这里的问题很可能是由于层数过多或者每一层之间的放大系数不合理导致上面的层的 tombstone 不能被推到最底层。这时候大家可以考虑开启 level_compaction_dynamic_level_bytes 这个参数来解决。
2. 你是否遇到过 iterator 的抖动导致的长尾问题呢？这个可能是因为 iterator 在释放的时候需要做一些清理工作的原因，尝试开启 avoid_unnecessary_blocking_io来解决。
3. 你是否遇到过 ingest file 导致的抖动问题？在 ingest file 的过程中，RocksDB 会阻塞写入，所以如果 ingest file 的某些步骤耗时很长就会带来明显的抖动。例如如果 ingest 的 SST 文件跟 memtable 有重叠，则需要先把 memtable flush 下来，而这个过程中都是不能写入的。所以为了避免这个抖动问题，我们会先判断需要 ingest 的文件是否跟 memtable 有重叠，如果有的话会在 ingest 之前先 flush，等 flush 完了再执行 ingest。而这个时候 ingest 之前的 flush 并不会阻塞写，所以也就避免了抖动问题。
4. 你是否遇到过某一层的一个文件跟下一层的一万个文件进行 compaction 的情况呢？RocksDB 在 compaction 生成文件的时候会预先判断这个文件跟下一层有多少重叠，来避免后续会产生过大的 compaction 的问题。然而，这个判断对 range deletion 是不生效的，所以有可能会生成一个范围非常广但是实际数据很少的文件，那么这个文件再跟下一层 compact 的时候就会涉及到非常多的文件，这种 compaction 可能需要持续几个小时，期间所有文件都不能被释放，磁盘很容易就满了。由于我们需要 delete range 的场景很有限，所以目前我们通过 delete files in range + scan + delete 的方式来替换 delete range。虽然这种方式比 delete range 开销更大，但是更加可控。虽然也可以通过 compaction filter 来进一步优化，但是实现比较复杂，我们暂时没有考虑。

BlockDB 需要解决的一个核心需求是数据分片。我们每个存储节点会存储几千上万个数据分片，目前这些单节点的所有分片都是存储在一个 RocksDB 实例上的。这样的存储方式存在以下缺点：

1. 无法对不同数据分片的资源使用进行隔离，这一点对于多租户的支持尤为重要。
2. 无法针对不同数据分片的访问模式做优化，比如有的分片读多写少，有的分片写多读少，那么我们希望对前者采取对读更加友好的 compaction 策略，而对后者采取对写更加友好的 compaction 策略，但是一个 RocksDB 实例上我们只能选择一种单一的策略。
3. 不同数据分片的操作容易互相影响，一些对数据分片的操作在 RocksDB 中需要加全局锁（比如上面提到的 ingest file），那么数据分片越多锁竞争就会越激烈，容易带来长尾问题。
4. 不同数据分片混合存储会带来一些不必要的写放大，因为我们不同业务的数据分片是按照前缀来区分的，不同数据分片的前缀差别很大，导致写入的数据范围比较离散，compaction 的过程中会有很多范围重叠的数据。

除了数据分片以外，我们还希望减少事务的开销。目前事务数据的存储方式相当于在 RocksDB 的多版本之上再增加了一层多版本。RocksDB 内部通过 sequence 来区分不同版本的数据，然后在 compaction 的时候根据 snapshot sequence 来清除不可见的垃圾数据。我们的事务在 RocksDB 之上通过 timestamp 来区分不同版本的用户数据，然后通过 GC 来回收对用户不可见的垃圾数据。这两者的逻辑是非常相似的，目前的存储方式显然存在一定的冗余。因此，我们会把一部分事务的逻辑下推到 BlockDB 中，一方面可以减少冗余，另一方面也方便在引擎层做进一步的优化。采用多版本并发控制的存储系统有一个共同的痛点，就是频繁的更新操作会导致用户数据的版本数很多，范围查找的时候需要把每一条用户数据的所有版本都扫一遍，对读性能带来很大的影响。实际上，大部分的读请求只会读最新的若干个版本的数据，如果我们在存储层把新旧版本分离开来，就能够大大提升这些读请求的性能。所以我们在 BlockDB 中也针对这个问题做了设计。

性能需求

另外，为了进一步发挥磁盘性能，减少文件系统的开销，BlockDB 还设计了一个 Block System 用于 Block 的存储。Block System 类似于一个轻量级的文件系统，但是是以 Block 为单位进行数据存储的。Block System 既可以基于现有的文件系统来实现，也可以直接基于裸盘来实现，这一设计为将来接入 SPDK 和进一步优化 IO 路径提供了良好的基础。

小结

获取最新《大规模混合部署项目在字节跳动的落地实践》技术沙龙的回放地址和 ppt 链接，请在「字节跳动技术团队」微信公众号后台回复：架构技术沙龙。

字节跳动基础架构团队

公司内，基础架构团队主要负责字节跳动私有云建设，管理数以万计服务器规模的集群，负责数万台计算/存储混合部署和在线/离线混合部署，支持若干 EB 海量数据的稳定存储。

欢迎关注字节跳动技术团队