如何实现一个百万亿规模的时序数据库，百度智能云 BTS 架构解析和实践分享

本文整理自 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 新增了时序引擎。同时，目前正在进行多模引擎的重构。

1 BTS 系统架构

下面详细介绍下 BTS 的整体系统架构。如图所示，整个架构分三层：接入层、引擎层和存储层。

存储层负责数据块的管理，整体采用了存算分离架构，实现了模块化的设计。数据均下沉存储于存储层，提供多种存储介质和压缩格式，为客户提供数据生命周期管理的能力。

引擎层提供了核心数据处理和管理能力，根据多维度策略对各模块做智能化调度。由于引擎层的数据都是无状态的，所以各个子功能都能够做到模块化，彼此之间解耦并可独立伸缩。另外，引擎层专门设计了智能化调度模块，可针对不同切片负载，做到自动化切片和合并。目前，我们在做基于反馈的自动调动，比如根据数据预测业务波动的情况，进行提前自动化调度。

最后，上层接入层支撑了丰富的接口和生态的能力。目前 BTS 支持 HBase, Influx 接口，更多接口也在逐步完善中。

2 BTS 核心技术架构设计

NoSQL 伴随着互联网业务发展而来，生来就是为了解决关系型数据库在垂直场景的不足。因此对于 NoSQL 数据库来说，高性能、低成本、高可用、高扩展是其核心能力。

2.1 单机引擎读写路径

接下来会重点介绍 BTS 是如何实现这些能力的。在这之前先介绍下单机引擎的读写路径，这是性能优化和高可用实现的前提。

首先是写路径，客户端写入数据后，数据写入 Redo-Log 并写进内存表中，导出数据压缩后以单元数据模式存储，可以支持多级压缩。详细的路径是：客户端写->数据写 Redo-Log->进入内存表-> dump 数据。压缩后以单元数据模式存储，支持多级压缩。

读路径则和写路径刚好相反：客户端读->优先在数据块缓存查询(如有)->如未命中，下沉到单元数据中查询->将数据返回客户端。读取数据的时候，核心能力是利用数据缓存加上内存里面的数据进行合并，加快读数据。

2.2 高性能优化和低成本管理

我们首先看下如何实现 NoSQL 数据库中最关键的性能和成本。

在性能方面我们有几个关键的优化，分别是：

通过 GroupCommit 将小块写合并处理，从而大幅度提升写吞吐。这在 HDD 介质上有明显的提升效果。
多种 Compaction 策略减少 I/O 放大。
写数据是把 I/O 合并，而读取数据的逻辑相反，把较大的 I/O 拆成小的 I/O 提供并发能力，通过「并发 I/O + 预读」提升读吞吐。
支持可配置缓存（Cache），提供内存、SSD 等多级缓存的能力。

在成本方面，BTS 底层支持多种压缩类型，包括三副本、Snappy、EC 等多种方式压缩节省空间。另外，BTS 还支持容量型和性能型切换，未来将提供同一张表自动降冷的能力。

2.3 高可用架构设计

接下来介绍 BTS 的高可用实现方法。

我们都知道数据的可靠性是存储层来保证的。在高可用上， BTS 有一整套的 HA 框架。这套框架包含控制节点和工作节点两部分，它们都支持高可用冗余。其中，工作节点之间是热备，数据通过 Redo-Log 进行同步。控制节点负责高可用的切换。主节点如果出现故障，可以进行快速切换，不可用时间控制在百毫秒内，切换时间控制在 RPC 调度时间之内。

依赖这个架构，可以实现快速 Failover，服务单元 MTTR 从秒级下降至百毫秒以内。另外，在系统升级的过程中，工作节点会主动切主，这个场景下业务无感知。

BTS 具备了完善的高可用的能力，比如多层次的容错和调度设计、多层弹性多租户隔离机制、端到端数据校验和实时监控和完善的运维。通过内核高可用框架和企业级能力来整体保证高可用的能力。