![]()
本文整理自 2023 年 12 月 16 日，百度智能云数据库总架构师朱洁在《国产数据库共话未来趋势》技术沙龙上的主题分享。
随着互联网和物联网的高速发展，产生了大量的结构化、半结构化数据。在百度集团内部， BTS（Baidu Table Storage） 成为处理这些半结构化数据的关键产品。随着技术的不断发展和业务需求的多样化，BTS 在百度内部经历了从支持单一 Table 能力到支持宽表、时序等多模能力的演进。
BTS 是百度智能云的半结构化存储产品，对内支撑百度核心业务（搜索、Apollo、凤巢、feed、系统监控等），对外提供高性能、低成本的 NoSQL 表格存储服务。
BTS 可用于丰富的场景，比如横向业务场景（分布式存储、结构化、聚合、高性能检索）、纵向行业场景（互联网、广告、feed、物联网、大数据、时序）以及一体化解决方案（大数据分析生态，监控）等，支撑业务创新。并且提供了多种 API、SDK 和可视化的 Web 管理平台供研发人员快速接入。通过 Batch 写、并发读、多级 Cache 加速等方式，打破性能瓶颈。通过热备副本、实时 Failover 和表回收站技术保证数据库高可用。另外，BTS 还提供企业级安全保障，服务可用性高达99.9%，数据可靠性达到了 99.99999999%（10 个 9）。BTS 的优势积累源于在百度内部的技术沉淀，到现在一共有 12 年的历史，共分为三代。- 1.0 版本：在 2011 年，百度设计了第一代分布式 Table 以满足集团内部业务需要。1.0 版本实现了分布式技术的突破，条目数做到百亿级别，满足了海量数据存储的需求。在 2014 年之前，该版本主要为搜索等业务提供定制服务。
- 2.0 版本：2015 年百度开始拓展商业广告等业务场景，增加了 FreeSchema、存算分离和稀疏表等能力。
- 3.0 版本：2018 年百度开始推出云上服务，场景进一步拓展，包括 feed 推荐、AI 等场景，条目数增长至百万亿量级。现在已经涵盖了系统监控/自动驾驶等场景。由于 BTS 的单一 Table 能力模式无法满足新场景的需要，因此从 3.0 开始，BTS 新增了时序引擎。同时，目前正在进行多模引擎的重构。
下面详细介绍下 BTS 的整体系统架构。如图所示，整个架构分三层：接入层、引擎层和存储层。
存储层负责数据块的管理，整体采用了存算分离架构，实现了模块化的设计。数据均下沉存储于存储层，提供多种存储介质和压缩格式，为客户提供数据生命周期管理的能力。引擎层提供了核心数据处理和管理能力，根据多维度策略对各模块做智能化调度。由于引擎层的数据都是无状态的，所以各个子功能都能够做到模块化，彼此之间解耦并可独立伸缩。另外，引擎层专门设计了智能化调度模块，可针对不同切片负载，做到自动化切片和合并。目前，我们在做基于反馈的自动调动，比如根据数据预测业务波动的情况，进行提前自动化调度。最后，上层接入层支撑了丰富的接口和生态的能力。目前 BTS 支持 HBase, Influx 接口，更多接口也在逐步完善中。![]()
NoSQL 伴随着互联网业务发展而来，生来就是为了解决关系型数据库在垂直场景的不足。因此对于 NoSQL 数据库来说，高性能、低成本、高可用、高扩展是其核心能力。接下来会重点介绍 BTS 是如何实现这些能力的。在这之前先介绍下单机引擎的读写路径，这是性能优化和高可用实现的前提。首先是写路径，客户端写入数据后，数据写入 Redo-Log 并写进内存表中，导出数据压缩后以单元数据模式存储，可以支持多级压缩。详细的路径是：客户端写->数据写 Redo-Log->进入内存表-> dump 数据。压缩后以单元数据模式存储，支持多级压缩。读路径则和写路径刚好相反：客户端读->优先在数据块缓存查询(如有)->如未命中，下沉到单元数据中查询->将数据返回客户端。读取数据的时候，核心能力是利用数据缓存加上内存里面的数据进行合并，加快读数据。
![]()
我们首先看下如何实现 NoSQL 数据库中最关键的性能和成本。- 通过 GroupCommit 将小块写合并处理，从而大幅度提升写吞吐。这在 HDD 介质上有明显的提升效果。
- 多种 Compaction 策略减少 I/O 放大。
- 写数据是把 I/O 合并，而读取数据的逻辑相反，把较大的 I/O 拆成小的 I/O 提供并发能力，通过「并发 I/O + 预读」提升读吞吐。
- 支持可配置缓存（Cache），提供内存、SSD 等多级缓存的能力。
在成本方面，BTS 底层支持多种压缩类型，包括三副本、Snappy、EC 等多种方式压缩节省空间。另外，BTS 还支持容量型和性能型切换，未来将提供同一张表自动降冷的能力。![]()
我们都知道数据的可靠性是存储层来保证的。在高可用上， BTS 有一整套的 HA 框架。这套框架包含控制节点和工作节点两部分，它们都支持高可用冗余。其中，工作节点之间是热备，数据通过 Redo-Log 进行同步。控制节点负责高可用的切换。主节点如果出现故障，可以进行快速切换，不可用时间控制在百毫秒内，切换时间控制在 RPC 调度时间之内。依赖这个架构，可以实现快速 Failover，服务单元 MTTR 从秒级下降至百毫秒以内。另外，在系统升级的过程中，工作节点会主动切主，这个场景下业务无感知。BTS 具备了完善的高可用的能力，比如多层次的容错和调度设计、多层弹性多租户隔离机制、端到端数据校验和实时监控和完善的运维。通过内核高可用框架和企业级能力来整体保证高可用的能力。![]()
第一点是支持缓存加速器。可以配置缓存，并且支持多层级特性，包含内存和 SSD 。支持对指定的表进行多层级加速，可以有效地提升热数据的读取速度，满足多重场景的诉求。第二点是多活架构。整体架构为热备多活，支持自动化故障切换，可以实现毫秒级故障切换，主动升级业务无感，适合对高可用有要求的业务。第三点是存储层支持多级数据压缩。该方式减少了无用数据的 I/O 消耗，支持直接对压缩后的数据进行操作，可以提升读性能以及节省存储空间。最后一点是正在进行内部测试的 key value 分离存储功能。通过分离存储可以做到单独压缩，查询的时候减少整行存取的 I/O 消耗，读写性能提升 50%。在介绍了 BTS 技术架构之后，我们进一步探讨下 BTS 架构在实际使用场景中的应用。BTS 目前支持超万亿的日均访问量，场景上覆盖了宽表、时序、大数据的处理和分析场景，覆盖了物联网、AI、feed 流、广告、健康、搜索、web 应用、自动驾驶等诸多方向。![]()
Apollo 无人车自动训练是其中一个重要的场景。在此场景下，需要进行模型训练、仿真，按需获取多维度环境数据。这种类型的数具备如下特征：- 车端数据具有多源，包括位置数据、雷达数据、影像数据、红外数据等。
- 单车单天 TB 级别，海量数据导致存储成本压力大。
从这些特征中我们可以看出，自动驾驶场景最大的特点就是吞吐高、数据量大，同时具备大数据和时序特征的场景。在这种海量时序数据场景中，性能和成本是其中的关键。在性能上，关键的解决办法就是按车和传感器进行区分，将时序写入打散，从而解决写入瓶颈。底层存储单元支持按大小，负载自动分裂和合并来解决数据热点问题。在成本上，BTS 支持数据转冷、按季度分表、转表、数据降冷等，从而实现高效的存储。通过 BTS 综合解决方案，实现了百 PB 数据低成本的存储，百 GB 的吞吐能力，支持业务精细化仿真，按需读取维度数据的能力。![]()
和自动驾驶场景不同，监控数据天然是打散的。监控场景中的物理服务器、虚拟机、容器等，均需要各个维度的监控以提升业务可视化程度。但是监控数据的小 value 很多，这导致读写和 Compaction 消耗很高。这也是监控业务相比自动驾驶业务不同的地方。
监控业务最大的痛点是离线流量和在线流量混合。离线流量需要分析全量数据，然后输出业务报表，对系统消耗很高。在线流量主要是实时监控、实时报警，要求数据能实时处理，不能阻塞。BTS 通过支持在离线分级管理的方式，用不同的访问标识区分在离线任务。离线任务会切成很小块，一个小块占用不多的时间，让高优在线任务能够随时插入进来。在线流量低时，离线流量可以充分把资源利用起来，当在线流量起来后，离线又能够快速让出资源，不阻塞在线任务。另外一点是监控对成本要求高的同时，对性能的要求也很高。所以利用监控业务读取最新数据的特征，通过多种缓存策略，让热数据尽量保持在高速缓存以保证高性能，冷数据放在 HDD 上，从而实现了成本的降低。通过这些整体方案，已经可以实现缓存命中率超过 80%，在兼顾成本的同时又具备高性能。通过以上方案，在百度集团内部的系统监控场景下，最终达到了业务成本下降 50% 以上、可支持每天十万亿级监控点采集、离线流量对在线流量 0 影响，实现监控 0 丢点率的效果。目前 BTS 在支持了宽表和时序的基础上，将进一步发展支持文档、搜索的多模能力，给客户提供跨模态统一分析和计算的能力，即支持客户通过一个任务即可统一分析多个模态数据。前面介绍了关键产品 BTS，最后简单回顾一下百度智能云产品矩阵。百度智能云数据库包括 RDS、NoSQL、云原生数据库，OLAP 等产品。相比业界其他云厂商，百度智能云数据库有两个显著特点：- 百度智能云数据库可以做到一套架构，云上云下客户享受同等的产品能力。
- 支持国内最全的产品形态，包括公有云，专有云 ABC Stack，边缘计算节点 BEC，本地计算集群 LCC 等多种形态，可以服务各类诉求的客户。
![]()
- - - - - - - - - - END - - - - - - - - - -
传送门
