万亿级时序数据存储架构，百度是这样搭建而成的

作者介绍

运小尧，百度高级研发工程师，负责百度运维大数据存储平台的设计和研发，致力于追求大规模存储系统的高性能和高可用。

万亿架构设计

在百度监控系统 TSDB 的常态工作负载下，单机每秒处理 20 多万数据点，集群每秒处理数万次查询，每天有几万亿的数据点在 TSDB 中穿梭，这样强悍的性能除了得益于 HBase 本身的性能优势外，架构层面的针对性设计同样功不可没。

面对已是万亿级别却仍持续增长的数据规模，我们设计了读/写分离且无状态的“弹性”架构；

为了在高负载下仍保证低延迟的写入和查询，我们将数据进行分层，分别存入 Redis、HBase 和 Hadoop；

为了不间断地为业务提供可靠的服务，我们设计了具备分钟级自愈能力的异地冗余架构；

为了节约存储成本，我们引入并改进了 Facebook 的时序数据压缩算法。

TSDB 的整体架构如图 1 所示。

图1：TSDB整体架构

可扩展 

我们希望通过简单地增加节点就使系统的处理能力线性提升，如果节点之间完全对等、互不影响，那么对整个集群而言，增加节点没有额外的资源消耗，就可以使处理能力随着节点数线性增长。

根据时序数据写多读少的特点，我们将读、写操作分离，设计了无状态的查询模块 Query-engine 和写模块 Saver，使得 Query-engine 或 Saver 的每个实例完全对等，并在上游应用轮询或者一致性哈希进行负载均衡。

实例的部署是基于百度内部的容器方案 Matrix，一则可以合理地分配资源，二则由于写入和查询隔离开来、互不干扰，其各自的性能均得到充分发挥。基于 Matrix 的虚拟化方案也使 TSDB 能够在分钟级完成任意数量的实例扩容。

高性能 

在图 2 的“水平分表”策略中，存在 HBase 里的数据被按时间划分到了不同的 Slice，老的 Slice 访问压力相对较小，减轻了系统处理这部分数据的负载。

图2：按时间水平分表

然而最新的一个 Slice 仍然会保持很高的热度，相对集中的负载仍然给 HBase 集群带来不小的压力。因此，我们利用内存缓存了部分热点数据(查询量相对更多的数据)，以空间换取更低的查询响应时间，同时分流 HBase 的查询压力。

缓存能力由百度运维部 DBA 团队的 BDRP 平台提供。但由于数据量太大，缓存一小时的数据需要较多的内存资源，我们在性能和成本之间做了权衡，选择只将核心指标数据写入缓存。

在大批量查询历史数据的场景中，查询的频率不高，对数据时效性的要求也较低，其目标数据通常是冷数据，因此我们把这部分数据从 Saver 的流量中复制出来，定期地灌入独立的 Hadoop 集群，将此类查询压力从 HBase 分流出去。

经过 Hadoop 和 Redis 的查询分流，HBase 仍然存储全量的数据，但其只承接常规的趋势图查询请求以及从缓存穿透的请求。

低成本 

为了降低数据的存储成本，我们引入了 Facebook 在论文《Gorilla: A Fast, Scalable, In-Memory Time Series Database》中介绍的一种时序数据压缩算法（见图 3），它能够达到 10 倍的压缩比，我们将其进行改造后应用到了缓存中。

图3：Facebook Gorilla中的压缩算法示意图

Gorilla 中的压缩算法较容易理解，其核心思想是增量压缩，不仅针对数据点取值进行压缩，且对时间戳应用了一种 Delta-of-Delta 压缩方法。经过压缩的数据点，其存储空间占用可以“bit”计，算法对于周期稳定、取值变化幅度较小的数据的压缩效果尤其好。

然而，这种增量压缩的算法中，后一个数据点的压缩结果依赖前一个数据点的压缩结果，这要求在集群中为每个时间序列维护压缩的状态，论文未对其分布式实现做详细的介绍，我们将数据压缩成 Byte 流，以 Key-Value 的方式存储在 Redis 中。

此外，论文中的算法仅支持浮点型数值，而我们改造后的算法还支持整数型和统计型数值（即上文提到的 StatisticsValue，每一个具有 max、min、sum、count 四个统计值）。

数据压缩的整体方案在实际使用中为我们节省了 80% 的存储空间，额外的 CPU 消耗不超过 10%。

高可用

冗余是高可用的一大法宝，我们使用了简单有效的异地互备的方案，即冗余出一整套集群和数据来实现高可用。

写入时，客户端将数据双写到两个集群，查询时通过动态路由表或百度名字服务（Baidu Naming Service, BNS）访问到其中一个集群（图 4），在此基础上我们具备故障自愈机制，可以实现分钟级的单机房故障自愈。

图4：异地互备

总结

近年来，TSDB 在智慧城市、物联网和车联网等等领域都有着十分广泛的应用，更是成为监控场景的标配基础服务。从实际的需求出发，我们认为 TSDB 的架构设计思路和功能侧重点并不局限于文中所述。

技术上，在大规模的时序数据存储系统中，我们选择了 HBase 作为底层存储，但并不代表 HBase 在任何场景下都是最合适的选择；在应用上，TSDB 也会与分布式计算、数据挖掘、异常检测甚至 AI 技术进行深度结合，将会面临更加复杂和富有挑战的场景。

我们设想将 TSDB 抽象成各种功能组件，能够根据不同场景的特点，灵活地搭配各个功能组件，以满足不同的需求。例如在数据量级较小的时候可以基于 MySQL 进行单机存储；或者作为缓存层直接基于内存存储；或者利用 Elasticsearch 的强大检索能力做多维度聚合分析等等。

目前我们已经进行了一些组件化的工作，并在这些工作的基础上实现了对 Cassandra 的支持，后续还将丰富框架和组件，引入新的功能，并逐步实现对 Elasticsearch、MySQL 等存储系统的支持。

限于篇幅，文章并未在细节处展开探讨，对 TSDB 甚至是其它大规模分布式系统有兴趣的同学，欢迎留言讨论。

网址：万亿级时序数据存储架构，百度是这样搭建而成的 https://mxgxt.com/news/view/242625

相关内容

基于大数据的舆情分析系统架构
论文阅读: TAO：Facebook的社交图谱的分布式数据存储(一)开启掘金成长之旅！这是我参与「掘金日新计划 · 12
数据治理与组织架构
【大数据播报】IT圈儿的“网红”究竟是谁？
吉利+百度=集度汽车？百度：这是AI取的名字
客服组织架构：构建高效客服团队的框架图
全国总票房实时大数据
百度天量数据挖掘明星关系，极客都是好娱记
大数据的舆情分析
大数据播报：IT圈儿“网红”究竟是谁？

随便看看