万亿级时序数据存储架构设计

1、 万亿级时序数据存储架构设计万亿架构设计在百度监控系统 TSDB 的常态工作负载下，单机每秒处理20 多万数据点，集群每秒处理数万次查询，每天有几万亿的数据点在 TSDB 中穿梭，这样强悍的性能除了得益于 HBase 本身的性能优势外，架构层面的针对性设计同样功不可没。面对已是万亿级别却仍持续增长的数据规模，我们设计了读/写分离且无状态的“弹性”架构；为了在高负载下仍保证低延迟的写入和查询，我们将数据进行分层，分别存入 Redis、HBase 和 Hadoop；为了不间断地为业务提供可靠的服务，我们设计了具备分钟级自愈能力的异地冗余架构；为了节约存储成本，我们引入并改进了 Facebook 的

2、时序数据压缩算法。TSDB 的整体架构如图 1 所示。图1：TSDB整体架构可扩展我们希望通过简单地增加节点就使系统的处理能力线性提升，如果节点之间完全对等、互不影响，那么对整个集群而言，增加节点没有额外的资源消耗，就可以使处理能力随着节点数线性增长。根据时序数据写多读少的特点，我们将读、写操作分离，设计了无状态的查询模块 Query-engine 和写模块 Saver，使得 Query-engine 或 Saver 的每个实例完全对等，并在上游应用轮询或者一致性哈希进行负载均衡。实例的部署是基于百度内部的容器方案Matrix，一则可以合理地分配资源，二则由于写入和查询隔离开来、互不干扰，其各

3、自的性能均得到充分发挥。基于 Matrix 的虚拟化方案也使 TSDB 能够在分钟级完成任意数量的实例扩容。高性能在图 2 的“水平分表”策略中，存在 HBase 里的数据被按时间划分到了不同的 Slice，老的 Slice 访问压力相对较小，减轻了系统处理这部分数据的负载。图2：按时间水平分表然而最新的一个 Slice 仍然会保持很高的热度，相对集中的负载仍然给 HBase 集群带来不小的压力。因此，我们利用内存缓存了部分热点数据(查询量相对更多的数据)，以空间换取更低的查询响应时间，同时分流HBase 的查询压力。缓存能力由百度运维部 DBA 团队的 BDRP 平台提供。但由于数据量太大，

4、缓存一小时的数据需要较多的内存资源，我们在性能和成本之间做了权衡，选择只将核心指标数据写入缓存。在大批量查询历史数据的场景中，查询的频率不高，对数据时效性的要求也较低，其目标数据通常是冷数据，因此我们把这部分数据从 Saver 的流量中复制出来，定期地灌入独立的 Hadoop 集群，将此类查询压力从 HBase 分流出去。经过 Hadoop 和 Redis 的查询分流，HBase 仍然存储全量的数据，但其只承接常规的趋势图查询请求以及从缓存穿透的请求。低成本为了降低数据的存储成本，我们引入了 Facebook 在论文Gorilla: A Fast, Scalable, In-Memory Ti

5、me Series Database中介绍的一种时序数据压缩算法（见图 3），它能够达到 10 倍的压缩比，我们将其进行改造后应用到了缓存中。图3：Facebook Gorilla中的压缩算法示意图Gorilla 中的压缩算法较容易理解，其核心思想是增量压缩，不仅针对数据点取值进行压缩，且对时间戳应用了一种 Delta-of-Delta 压缩方法。经过压缩的数据点，其存储空间占用可以“bit”计，算法对于周期稳定、取值变化幅度较小的数据的压缩效果尤其好。然而，这种增量压缩的算法中，后一个数据点的压缩结果依赖前一个数据点的压缩结果，这要求在集群中为每个时间序列维护压缩的状态，论文未对其分布式实现

6、做详细的介绍，我们将数据压缩成Byte 流，以 Key-Value 的方式存储在 Redis 中。此外，论文中的算法仅支持浮点型数值，而我们改造后的算法还支持整数型和统计型数值（即上文提到的 StatisticsValue，每一个具有 max、min、sum、count 四个统计值）。数据压缩的整体方案在实际使用中为我们节省了 80% 的存储空间，额外的 CPU 消耗不超过 10%。高可用冗余是高可用的一大法宝，我们使用了简单有效的异地互备的方案，即冗余出一整套集群和数据来实现高可用。写入时，客户端将数据双写到两个集群，查询时通过动态路由表或百度名字服务（Baidu Naming Servic

7、e, BNS）访问到其中一个集群（图 4），在此基础上我们具备故障自愈机制，可以实现分钟级的单机房故障自愈。图4：异地互备总结近年来，TSDB 在智慧城市、物联网和车联网等等领域都有着十分广泛的应用，更是成为监控场景的标配基础服务。从实际的需求出发，我们认为 TSDB 的架构设计思路和功能侧重点并不局限于文中所述。技术上，在大规模的时序数据存储系统中，我们选择了HBase作为底层存储，但并不代表 HBase 在任何场景下都是最合适的选择；在应用上，TSDB 也会与分布式计算、数据挖掘、异常检测甚至 AI 技术进行深度结合，将会面临更加复杂和富有挑战的场景。我们设想将 TSDB 抽象成各种功能组件，能够根据不同场景的特点，灵活地搭配各个功能组件，以满足不同的需求。例如在数据量级较小的时候可以基于 MySQL 进行单机存储；或者作为缓存层直接基于内存存储；或者利用 Elasticsearch 的强大检