百度信息流和搜索业务中的 KV 存储实践
导读：近年来，云原生化、全用户态、软硬协同等技术对 KV 存储服务产生了巨大的影响，上述技术在极大提升了服务的性能和降低服务成本的同时，也对系统的架构和实现提出了新的要求。百度在信息流和搜索业务中大量使用了 KV 存储服务，服务每天响应近千亿次各类访问请求，如何运用上述技术提升系统的性能、稳定性和运维人效是我们重点考虑的问题。本文通过介绍我们应用上述技术打造高性能 KV 存储系统的实践过程，为大家分享了我们在单机性能优化，大规模集群设计、管理等方面的思路和实践经验。
全文 7854 字，预计阅读时间 21 分钟。
自 2016 年起，百度进入『搜索+信息流』双引擎驱动构建内容生态的“信息分发 2.0 时代”，搜索、推荐的内容也不再局限于网页，而是引入越来越多的视频、图片、音频等多媒体资源。KV 存储作为在搜索和推荐中台中被广泛使用的在线存储服务，更是受到了存储规模和访问流量的双重考验。
至 2018 年初，我们投入各类 KV 存储服务的服务器数量便超过万台，数据规模超过百 PB，承接了每天近千亿次的各类访问请求。集群规模的增长除了资源成本的提升，还加剧了运维管理的难度。作为有状态服务，集群的故障机处理、服务器升级、资源扩缩容都需要专人跟进，运维人力随集群规模呈正比增长。彼时又逢推荐业务完成了微服务化改造，业务资源交付和上线都能当天完成，存储资源动辄周级的交付能力也成了业务上线效率的瓶颈。
这些都促使我们对原来的系统架构进行彻底升级，通过提升单机引擎性能和云原生化有效降低资源成本和运维人力成本。同时我们还要满足业务对服务的敏捷性要求，通过云基础设施提供的资源编排能力，使系统具备小时级服务交付能力。
一、问题与挑战
1）性能挑战
单机引擎性能是 KV 系统的关键指标，一般我们通过读写性能（OPS、延时（latency））和空间利用率来衡量引擎的性能，由于当前引擎架构和存储设备硬件性能的制约，我们在引擎中往往只能选择读性能、写性能和空间利用率中某个方向进行重点优化，比如牺牲空间利用率提升写吞吐，或者牺牲写吞吐、提升空间利用率和读吞吐。
这类优化对于业务单一的场景比较有效，之前我们的系统就针对大业务场景进行逐一调参优化，针对其他业务则使用读写性能和空间利用率均衡的『均衡型』引擎接入。
但是百度的信息流和搜索业务规模都非常庞大、业务场景极其复杂，我们接入的数千个业务中有每天更新 PB 级数据的业务，也有读写比超过 100:1 的业务，还有要求强一致性、存储规模数十 PB 的业务，不少业务还会体现出潮汐特性，全天流量都集中在某个特定时段。
因此我们通过引擎优化，既要解决如何在降低读写放大的同时，尽可能平衡空间放大的问题；又要在引擎内实现自适应机制，解决业务充分混布场景下，吞吐模式多变的问题。
2）云原生化挑战
云原生架构的主要价值在于效率的提升，包括资源利用效率和研发效率两个方面。
百度信息流和搜索业务对其业务模块制定了统一的云原生化标准：
微服务化：每个服务粒度应该在限定的范围内。
容器化封装：一个服务的部署，应该只依赖基础架构以及本容器内的组件，而不应该依赖其他业务服务。
动态管理：每个服务应该可以动态调整部署，而不影响自身对外承诺的 SLA。
KV 服务在对齐上述标准的过程中，主要难点在于容器化改造和动态管理两个方面。
容器化改造方面，单机时代的 KV 服务以用满整机资源为目标，对内存资源和存储介质 IO 的使用往往不加任何限制。引擎的容器化改造，要求我们精细化控制对上述资源的使用：
内存资源：存储引擎除了显式使用系统内存，更多的是对 page cache 的使用，文件系统中诸如 Buffered I/O 和文件预读都会产生 page cache。我们需要在引擎中对其加以控制，避免超过容器配额触发硬限。
存储介质 I/O：KV 服务的主要介质是 SSD，我们不少业务也需要使用 SSD 提升读写性能，这些业务本身往往只需要不到 100GB，因此为了提升 SSD 的使用率，KV 服务需要和这些业务进行混布。这也要求我们不但能有效利用 SSD I/O，还要能对 I/O 加以控制，避免影响混布业务。
动态管理则要求业务具有一定的容错能力和弹性伸缩能力，由于 KV 是典型的有状态服务，兼具了数据持久化、多分片、多副本等特点，我们在动态管理中需要关注：
服务可用性：与无状态服务不同，多分片服务不能看服务的整体可用性，而要确保每个分片都可用。比如一个服务有 10 个分片，每个分片有 3 个容器，服务整体可用度为 90%。从无状态服务视角 2 个容器故障不会影响服务可用性，但是从 KV 服务视角，如果这两个容器正好服务同一个分片的两个数据副本，那么该服务就会出现数据不可用问题。因此服务在持续部署时，需要确保每个数据分片的可用性。
数据可靠性：云原生化后为了提升资源利用率，在线数据迁移和动态伸缩频率将远高于物理机时代，数据的动态伸缩过程需要对业务透明，也不能出现数据丢失或一致性问题。
管理效率：确保管理服务能即时响应管理操作，对系统的稳定性起着关键作用。随着集群规模的增加，并发的管理操作数量也会增加，如果响应操作的时间也逐渐增加，最终将导致系统雪崩，因此我们需要系统响应管理操作的能力也能水平伸缩。
部署效率：KV 服务的部署包括部署应用和完成数据迁移，因此我们不但要在功能上做到可迁移，还要确保数据迁移的效率。比如一个有 100 个实例的服务，如果迁移一个实例要 12 个小时，且每轮只允许迁移 1 个实例，遇到内核升级、操作系统升级等需要重启的操作，全服务迁移一轮就需要 1 个半月，这样的效率还不如人工操作。这样的服务就不能算支持动态管理，因为没有在线操作可以容忍这样低的迁移效率。
3）满足业务的特化需求
之前也提到百度的信息流和搜索业务规模都非常庞大，一些大业务根据自身场景已经做了单机引擎的特化，有些特化还涉及修改 linux 内核，通用引擎在性能上无法超越这些特化引擎，这就要求能从业务中提取共性，同时允许其保留特性，使业务团队能在资源利用效率和研发效率两个方面都获得收益。
为此我们提出了 UNDB - NoSQL 联合存储系统（United NoSQL Database）的概念，兼顾统一通用能力与保持业务特性：
统一框架：使用统一的云原生存储框架，打平各系统的运维、集群管理差异，同时打破原有的资源屏障。
通用接口：各 KV 服务剥离业务协议，对齐基本 KV 接口协议，对用户提供基于基本 KV 接口封装的 SDK，使业务可以在各服务间平滑迁移，降低学习成本。
通用引擎：自研高性能通用 KV 引擎，便于其他 NoSQL 服务在此之上实现高性能的存储服务。
分层可插拔架构：通过可插拔的接口层、数据模型层、数据同步层、引擎层设计，使接入系统能快速实现业务特性化差异。
二、引擎优化
引擎是 KV 系统的核心组件，鉴于 RocksDB 在开源社区和工业界的广泛应用，我们一开始便直接使用 RocksDB 作为单机引擎。基于 LSM-Tree 实现，RocksDB 在 HDD 介质上有良好的性能，但在 SSD 介质上的性能表现却并不出众，主要问题在于：
RocksDB 在设计实现中,为了避免随机 I/O，增加了大量顺序 I/O 开销（读放大、写放大），而 SSD 介质的随机 I/O 尤其是随机读性能和顺序 I/O 差距不大，因此针对 HDD 介质的优化在 SSD 介质中反而造成了读写带宽浪费。
上述额外的 I/O 开销所产生的高写放大，还增加了 SSD 介质的寿命损耗，在高吞吐环境中，新盘的平均使用寿命不足 2 年。
LSM-Tree 结构对业务数据长度也十分敏感，由于每层 SST 文件大小是固定的，数据长度越大，越容易触发 Compaction，从而造成写放大；同时数据长度越大，每层 SST 文件能记录的数据条目数就越少，读请求向下层访问概率就越高，从而造成了读放大。
我们业务场景中的 value 一般在 KB ~ 百 KB 级别，为了降低 LSM-Tree 的写放大，我们在 RocksDB 基础上实现了 Key-Value 分离的单机存储引擎，如下图左侧引擎结构所示：
图 1：普通引擎与基于 OpenChannel SSD 的软硬协同引擎的架构对比
在 RocksDB 中存储 Key 和 Value 的地址索引(BlockID+Offset)，RocksDB 的 Compaction 只影响到索引，不会引起 Value 的变动。
Value 单独持久化，我们称之 Data Block 文件，Data Block 文件单独进行 Compaction。
为了进一部提升引擎的 I/O 效率，我们又对 Compaction 策略和压缩方式进行了优化：
自适应 Compaction 机制：综合引擎 I/O 和剩余存储空间，调节对 Block 文件空洞率的选择阈值，实现流量规避、动态调节空间放大能力。
冷热分层：减少冷热混合导致的不必要 Compaction，并选择流量空闲时段对冷数据进行 Compaction，降低触发 SSD 静态磨损均衡频率。
全局压缩：在 Block File 粒度支持了 zstd-dict 压缩方式，进一步提升了 Block 文件的压缩率。
此外，我们在引擎中为同步框架封装了 Log View，实现数据同步与引擎复用，WAL 降低了数据同步造成的写放大。
通过上述优化，在软件层面，我们在空间放大 ＜1.6x 的情况下，将写放大控制到了 ＜ 1.5x。在业务持续以 30MB/s 更新数据的场景下，单盘寿命由之前的半年内提升至 3 年左右。
但是，SSD 的写放大并不限于软件层，物理特性决定其不支持覆盖写，只能先擦除旧数据再写入新数据，大部分 SSD 按 4KB（Page）写入、按 256KB ~ 4MB（Block）擦除数据。SSD 在擦除一个 Block 时，需要迁移 Block 中仍然有效的 Page，这个迁移动作导致了 SSD 硬件层的写放大，硬件层写放大又与 SSD 剩余空间密切相关，一般情况下，当 SSD 容量使用达 90%时，写放大会超过 3.5x。
细心的同学或许会发现，我们之前在计算 SSD 寿命时并没有提到这部分放大，这里其实包含了 SSD 厂商的优化：SSD 介质的实际容量单位是 GiB（Gibibyte），1GiB = 230bit，提供给用户的指标则是 GB（Gigabyte），1GB = 109 bit，前者比后者多了 7.374%的空间，被厂商用作了内部操作空间。加之我们在实际使用时，也会保持磁盘用量不超过 80%，因此可以控制写放大。但是这些策略其实牺牲了 SSD 的容量。
为了进一步发掘设备潜能，我们和百度的基础架构部门合作，基于 Open Channel SSD 实现了一款软硬协同设计的引擎，如上图右侧引擎结构所示与传统用法相比：
实现了全用户态 I/O 操作，降低了引擎读写延迟；
引擎直接管理 Flash 物理地址，避免了文件系统、LBA、PBA 三层映射造成的性能损失和空间浪费；
将 FTL 中 Wear Leveling、GC、PLP、Error Handling 上移至引擎，和 KV 原有的 Compaction，Crash Recovery 逻辑合并，合并了软、硬两层操作空间。
软硬协同引擎在性能上超过软件引擎 ＞ 30%，软硬整体放大率 ＜ 1.1x。
图 2：引擎性能对比，依次为：数据加载性能、读写吞吐（读写 1：1）、99 分位写延时、99 分位读延时
上图是我们实现的 KV 分离引擎（Quantum）、软硬协同引擎（kvnvme）和开源 Rocksdb 在数据加载、随机读写场景下的性能对比。
测试中我们选用：NVME 1TB SSD（硬件指标：4KB 随机写 7 万 IOPS，随机读 46.5 万 IOPS）。数据集选用：1KB、4KB、16KB 和 32KB 共 4 组，每组数据集都随机预构建 320GB 初始数据，再采用齐夫分布（Zipf）进行读写测试，读写测试时保持读写比为 1：1。
从测试结果可以发现：
Value 越大，KV 分离引擎和软硬协同引擎的读写优势就越为明显，在 32KB 时软硬协同引擎的吞吐是 RocksDB 的近 5x。
软硬协同引擎在读写延时控制上，尤其是写延时控制上也明显优于其他引擎。
三、云原生实践
上节中我们通过引擎优化重构解决了业务混布性能和容器化问题，这节将介绍一下我们是如何解决动态管理问题。
UNDB 服务整体框架如下图所示：
图 3：UNDB 系统框架
架构上我们将服务分成了 Operator（数据调度）、控制面和数据面三部分：
Operator：负责向 PaaS 传递控制面和数据面中所有容器的状态信息和进行用户数据调度
控制面：包括元信息服务、集群控制服务、接入管理服务、路由服务和用户数据中心，负责管理一个 IDC（Internet Data Center）中的所有存储集群（Store Clusters）和用户发现、接入存储集群的路由映射关系，不同 IDC 间部署不同的控制面服务。
数据面：IDC 中 KV 服务管理的所有存储集群的集合。存储集群按存储设备类型（比如：NVMe SSD、SATA SSD、OpenChannel SSD、HDD、……），存储机制的容量，引擎类型，以及引擎使用的 CPU、内存资源数量进行划分。
我们在系统设计、实现中主要考虑如何实现数据全局调度能力和海量存储实例的动态管理能力。
3.1 数据全局调度能力
数据全局调度指：
用户数据可以在数据面中的不同存储集群间任意迁移、扩缩容。
用户数据可以在不同数据中心间任意迁移、复制。
这种能力的意义在于：
当业务形态、引擎技术和存储设备发生变化时，我们能用对业务无感的方法将数据迁移到合适的集群中。
当部门新建数据中心，业务新增、切换数据中心，或是数据中心数据恢复时，我们能以最低的运维成本实施数据迁移、恢复。
图 4：Table 在 UNDB 集群间迁移示意
如上图（图 4）所示，全局调度由 Operator 发起，通过控制面协调数据面中的存储实例完成操作，其中：
元信息服务和集群控制服务，为 Operator 对用户数据进行全局调度从底层机制上提供了无损迁移和无损伸缩能力。
数据中心：通过分析存储集群的流量、容量分布和业务数据的流量、容量增长趋势，向 Operator 提供了全局调度方案。
Operator：基于 K8S Operator 框架实现，通过声明式原语，引导控制面完成数据迁移。
基于上述能力，我们除了支持即时集群容量均衡和即时业务容量调整，还实现了周级机房建设、搬迁。
3.2 海量存储实例的动态管理能力
之前提到我们在动态管理中需要关注服务可用性、数据可靠性、管理效率和部署效率，上节中我们通过引擎优化实现了小时级完成 TB 数据的迁移、恢复。这里我们将关注如何在动态管理中确保服务的可用性、数据可靠性和管理效率。
业务访问 KV 服务的过程可以简单概括为：
业务通过路由发现数据所在的存储节点。
访问存储节点获取数据。
数据和存储节点映射关系发生变更时，通知业务更新路由。
我们在数据面中：
按 3-2-1 原则确保数据安全。
使用 Multi-Raft 确保数据一致性。
采用多地多活确保重要业务的可用性。
由于数据中心间的元信息不尽相同，尤其是拓扑信息完全不同，且拓扑信息具有极强的时效性，冷备效果并不好，因此对于控制面我们采用了利用数据面，集群控制服务多级兜底的思路，如下图（图 5）所示：
冷备机制：对于低频更新的元信息，诸如业务数据属性、配额实时备份 SQL 数据库。
反向恢复机制：利用集群控制服务和存储集群都有拓扑镜像的特点，支持通过上述服务反向恢复拓扑信息。
异变拦截机制：在控制面、数据面及业务端（Client）拦截异常变更，避免拓扑异常时，服务迅速异常雪崩。
图 5：元信息多级拦截、反向恢复
另外我们还通过独立的路由服务向业务屏蔽了元信息服务，业务间通过多组路由服务进行物理隔离。并通过接入管理服务管理业务和路由服务间的映射关系，这样可以有效防止由于某个业务的异常访问（比如：连接泄露）影响其他业务的路由访问。
在提升管理效率方面，我们主要采用了元信息和集群控制分离的设计，由于元信息服务需要确保节点间数据一致性，我们的数据修改操作只能在 Leader 节点上进行，如果不采用分离设计，所有控制操作只有 Leader 节点才能进行，当集群规模和数量增加后，无法通过水平扩容节点增加控制面算力，因此我们选用了两种模块分离的方法，使控制面具备水平伸缩控制算力的能力以应对超大规模集群。
四、多模型存储架构
NoSQL 概念发展至今，业界已经出现了数百种不同的开源和商业 NoSQL 数据库，当业务发展到一定程度，对标准数据库进行改造，使其更适合业务模型的需求也变得越来越普遍。因此我们在整合 KV 系统时，提出了整合通用功能保留业务特性的设计思路。在这个思路指导下，我们统一了控制面，用于实现统一的运维管理，数据面则分成了 3 个功能模块、6 个分层向业务开放了对服务接口、数据模型、存储模式、以及对同步框架的定制化能力，如下图所示：
图 6：UNDB 多模型存储架构
DbProxy 模块：整个架构的第一层，是一个独立部署的模块，DBProxy 是对所有代理存储节点（Store Node）的 Proxy 服务的总称，按功能不同还有诸如 KvProxy，GraphProxy 等，该模块主要用于：
分担存储节点（Store Node）访问压力：当业务存在大量的 Fanout 读，或离线任务（map reduce 任务）存在大量写连接时，通过 proxy 可以减少对存储节点的压力;
减少上下游连接开销：主要用于超大规模业务，比如搜索业务的一张索引表就分布在上万个实例中，这也意味访问该表的每个下游都要维护上万个连接，因此需要通过 proxy 减少客户端的连接开销。
存算分离：当前通过 NVMe-OF、RDMA 技术网络已经不是系统的主要瓶颈，像图数据库这样的服务，一次请求需要访问多个存储节点才能完成，还需要通过本地缓存构建子图加速业务查询速度，整合在存储节点中几乎无法带来的性能收益，还容易出现热点查询，因此我们也通过 Proxy 实现存算分离。
libNode 模块：该模块承担了存储节点的业务逻辑、节点管理和数据同步：
分布式管理层：通过 CtrlService 向业务提供了一组响应分布式状态管理的核心原语，并提供了默认原语实现。
接口协议层 & 数据模型层：提供 KvService 作为所有服务共同遵守的最简 KV 协议，开放服务注册和模型层（Module）供业务组织管理自己的定制化服务接口以及数据结构。为了能让模型使用适应不同引擎，我们统一 KV 接口作为模型层的序列化反序列化接口。
同步框架层：不同业务对服务的可用性、数据一致性的要求并不相同，比如用户模型关注可用性和吞吐能力，内容模型则关注读写延时和数据的强一致性。我们也针对业务的不同需求提供了最终一致性（高可用、高吞吐）、顺序一致（braft 实现的一致性，介于最终一致和强一致性之间）和线性一致（强一致）三个层级的一致性保证，其中线性一致是我们在 braft 基础上，通过 ReadIndex 和 LeaseRead 算法满足的一致性语义。
引擎模块：也是 6 层架构中的最后一个分层『引擎层』，主要负责单机存储功能，与 libnode 共同组成了一个存储节点（Store Node）。上节提到的引擎优化，就是对这个模块的一系列优化工作。
五、总结
UNDB 系统自落地以来，已经覆盖了百度信息流和搜索主要业务场景，涉及集群规模数十万实例，每天承接了超过万亿次的各类访问流量，成本相较原先降低近 50%。同时系统还保持着月级频率的全集群业务无感更新。在运维方面则实现了高度自动化，集群无专职运维，全部由研发团队自主管理。目前团队还在打造多模型数据库、单机性能优化、存储架构优化等方向持续努力，力求使 UNDB 具备更完善的业务生态。
推荐阅读：
---------- END ----------
百度 Geek 说
百度官方技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢迎各位同学关注
版权声明: 本文为 InfoQ 作者【百度Geek说】的原创文章。
原文链接:【http://xie.infoq.cn/article/56d1b73dc536cae2a41cade5e】。文章转载请联系作者。
百度官方技术账号 2021.01.22 加入
关注我们，带你了解更多百度技术干货。
评论