日均采集1200亿数据点，腾讯千亿级服务器监控数据存储实践

近几年开源的大年夜数据处理体系已经慢慢成长到一个比较成熟的阶段了，各类大年夜数据处理的场景都有了响应的解决筹划，如同 MySQL 在当今互联网公司中的关系数据存储广泛应用地位一样。

腾讯今朝有几十万台量级的办事器，TMP 体系按 1 分钟粒度采集监控数据，平均天天采集 1200 多亿的数据点。

TMP 当前存储架构分析

我们起首看下当前的 TMP 的 1 分钟粒度数据存储架构。Agent 上报的数据，经由过程 Collector 大年夜 MySQL 数据表中萌芽索引和路由规矩 a，分发到不合的数据存储结点上。

数据节点 Datacache 收到数据后先缓冲到内存中，内存的数据按期 DUMP 到文件体系中。

这套架构长处很明显，设计简洁、有最新数据缓存、数据分布式存储、可横向扩大，同时完全自研，各自实现细节可控。

但同样存在一些问题：

Hbase 存储引擎优势

Hbase 是 Hadoop 生态栈中的分布式列存储数据库，基于 Bigtable 模型和 LSM-Tree 存储引擎，用于海量数据的随机读写，在业界的大年夜范围监控体系的时序数据存储中已有成熟应用案例，如某度和某宝。

我们看下应用 Hbase 存储有何优势：

数据高靠得住，高可用。数据在写内存的同时，会写一份 HLog 到 HDFS 中，如不雅某台 RegionServer 异常，内存中的数据会大年夜 Hlog 中主动恢复。持久化数据保存在 HDFS 中，默认持有 3 个副本，无单点损掉数据风险。

高机能。LSM-Tree 存储引擎包管了 Hbase 超高的写机能，实际上前面介绍的 TMP 自研存储体系也是一种简化版的 LSM-Tree 存储引擎，因而同样有如斯高的机能。

天然的程度伸缩，高可扩大性。存储层 DataNode，数据办事层 RegionServer 均支撑自由伸缩扩容。

数据表支撑紧缩，空列不占存储空间。

这里我们将天天的数据表预切分为 100 个 Region，以{0x01， 0x01 … 0x63}，即二进制的 1~99 为 splitKeys，第一个 Region Rowkey 范围为 [0x00…~0x01]，第二个 Region Rowkey 范围为 [0x01…~0x02]，以此内推。

Opentsdb 测验测验及瓶颈分析

在预备应用 Hbase 存储 TMP 监控数据之初，我们曾测验测验应用基于 Hbase 的开源时序数据库 Opentsdb 来直接存储办事器监控数据。但 Opentsdb 到 70w/s 的时刻全部 Hbase 集群就已超负荷运转、响应迟缓了，完全无法知足如斯大年夜范围的存储需求。

我们细心分析了 Opentsdb 在超大年夜范围时序数据存储上存在的重要瓶颈：

所有 metric 跟 tag 都要经由 tsdb-uid 表的转换，此设计本意是为了紧缩 rowkey 大年夜小，但惹人较大年夜的计算资本开销;
数据写入的 Append 机制及原始 compaction 设计存在较大年夜的机能问题，这在后面部分会具体分析;
所有的数据都放在同一张表里，晦气于基于时光对数据进行保护操作，比如对一个月前非热点数据进行抽样存储，且无法控制 Region 数，也就无法控制 split，对机能影响较大年夜;

基于这些原因，我们最终决定直接应用 Hbase 进行 TMP 办事器监控数据存储。

TMP 监控存储设计实践

Hbase 的应用在全部 hadoop 生态栈中属于较为复杂的一个类别。TMP 监控存储设计结合了业界应用 Hbase 的一些成熟的实践经验，同时参考和改进了 OpenTSDB 在应用 HBase 时的比较好的设计思惟，以支撑 TMP 监控数据的大年夜范围读写。

Region 预切分

同时因为开端时代只有少量 Region，数据的读写很轻易全落在单台 RegionServer 上，造成 HotSpot 现象，严重影响读写机能。是以对存储表进行 Region 预切分处理是 Hbase 应用中十分重要的一步。

2.2 版本参加的 append 机制更是每一次写操作产生一次读操作，对 Hbase 应用很不经济，写入量大年夜时会半数个集群的读压力造成巨大年夜影响。

　　推荐阅读

　　如何使用SIOC存储策略优化负载性能？

存储瓶颈会对存储延迟和虚拟机机能表示造成严重影响，是以治理员应当控制若何应用SIOC存储策略解决这种存储资>>>详细阅读

地址：http://www.17bianji.com/lsqh/36675.html