写点什么

百度大规模时序数据存储(二)| 存储选型及数据模型设计

2019 年 9 月 09 日

百度大规模时序数据存储(二)| 存储选型及数据模型设计

在百度大规模时序数据存储(一)| 监控场景的时序数据文章中,我们简要地介绍了百度监控场景时序数据的特点,且分析了在每天万亿级的数据规模下,时序数据的存储所面临着的诸多挑战。本篇将介绍 TSDB 在方案选型和存储模型设计上的实践。


一 简介

TSDB(Time Series Database,时间序列数据库)是一种日趋流行的数据库,从 DB-Engines 提供的最近一年各类数据库流行趋势来看,最近一年 TSDB 的增长势头强劲,远超其它类型的数据库。



图 1 数据库分类流行趋势


二 底层存储选型

为了更好地适应业务需求,我们选择自研 TSDB,由于时序数据的规模很大,我们在底层存储的选型上需要慎重考量。在百万级指标的规模下,用 MySQL 来实现就可以满足需求,如开源监控系统 Zabbix 的底层存储方案。


随着业务的快速发展,我们的数据规模也从百万级涨到了千万级以至于现在的万亿级,此时传统关系型数据库愈显乏力。我们尝试过的一些集群方案在读/写延迟上并没有显著的提升,其扩展能力也只是差强人意,这迫使我们寻求新的方案。


重新审视我们对存储系统的核心需求:高吞吐、低延迟、可扩展。对于监控场景来说,关系型数据库的强一致模型、事务机制以及联合查询等强项并不是我们关注的重点,单个数据点的丢失并不影响监控指标的整体趋势,数据的偶发延迟也可以接受。


近两年开源的 TSDB 项目不断涌现(见图 2),许多优秀的项目也成为我们调研和学习的对象,我们发现这些项目在底层存储的选型上各有偏好,这里列举一些:


  • OpenTSDB:著名的老牌 TSDB,底层存储最初只支持 HBase,后来增加了对 Cassandra 的支持

  • InfluxDB:基于自研的 TSM 存储引擎,集群方案未开源

  • KairosDB:发源于 OpenTSDB,早期底层选用 HBase,目前主打使用 Cassandra,还支持 H2(用于非生产环境)

  • Prometheus:Google 监控系统 Borgmon 的开源版本,基于 LevelDB 和本地存储



图 2 TSDB 排名变化趋势


然而无论是 HBase、Cassandra、LevelDB 还是 InfluxDB 的 TSM 存储引擎,他们的一个重要共同点就是都基于 LSM-tree 实现(Log-Strutured Merge-tree,日志结构合并树)。如图 3 所示,LSM-tree 这种树形结构可以像打印日志一般,以追加的方式顺序写入数据,并且不断地将较小的数据块合并成更大的块,最终将数据批量地刷写到磁盘。



图 3 LSM-tree


使用 LSM-tree 有什么实际的意义?在上一篇文章中我们提到,监控数据的写入量非常大(每秒数千万数据点),存储时长最长可达数年,从成本角度考虑,廉价的磁盘自然是合适的选择。然而,磁盘的机械结构使得其随机 I/O 性能在面对每秒数千万的写入请求时显得力不从心。LSM-tree 正是能够借助内存缓冲将大量的随机写入转化成批量的顺序写入,使得最终磁盘承载的写入次数对数级减少,极大地提升了写入吞吐量。


综合来看,NoSQL 数据库是更合适的选择。在诸多 NoSQL 数据库中,我们选择了基于 LSM 实现的 HBase ,主要出于如下考虑:


  • 高吞吐、低延迟,满足读/写性能需求

  • 数据存储在 HDFS,支持多副本冗余,满足可靠性需求

  • 表格存储,模型简单、业务开发较为方便

  • 支持横向扩展,可线性扩容,能够适应业务增长

  • 成熟的代码、活跃的社区和广泛的应用案例


三 基于 HBase 的存储设计

HBase Table 中的数据按照 RowKey 的字典序排列,在行的方向上数据可以分布到多个 HRegion 中,而 HRegion 可以分布在不同的节点上,因此只要能够使数据均匀地分布在 HRegion 中,就可以实现存储的负载均衡。






图 4 HRegion 的分布


容易看出,RowKey 的设计是负载均衡的关键。如果 RowKey 设计不好,就容易形成热点 HRegion,导致其所在节点负载过重,进而集群的整体性能下降。


接下来重点介绍 TSDB 中最关键的两张表的设计:数据表和维度索引表。前者支撑了所有时序数据的存储和查询,后者是多维度聚合查询的基础。


1 数据表

前文介绍过,监控时间序列构成如下:


时间序列 = 监控对象 + 标签列表 + 监控项 + 数据点


为方便讲解,换一种形式表述:


ts = (object + tags) + metric + [(timestamp, value), (timestamp, value), …]


可见,由 object + tags + metric + timestamp 可以唯一定位一个数据点的取值。为了充分利用 HBase 的特性,我们借鉴了 OpenTSDB 的做法,将 RowKey 设计如下:


RowKey = entity_id + metric_id + timebase


entity_id 是由 object 和 tags 的经过 hash 得到的一个固定长度的值,hash 后原始字符串的自然顺序被打乱,使得 RowKey 能够相对均匀地分布在不同 HRegion 中。


metric_id 为 metric 的字符串 hash 值,同样是固定长度。


timebase 为 Unix 时间戳按照 1 小时(3600 秒)取整得到的数值,固定 4 个字节的长度


这样的设计有如下好处:


  • entity_id 和 metric_id 的散列使得数据相对均匀分布

  • timebase 置于 RowKey 的字节低位,使得同一个时间序列数据的 RowKey 连续分布,可以高效地按时间进行范围扫描

  • 固定长度的 RowKey 减少了空间浪费,同时前缀式的设计可以充分利用 HBase 的前缀压缩机制,进一步节省 RowKey 所占空间


RowKey 代表的行包含 1 小时的数据,行中数据点按照当前时间在 1 小时内的偏移量进行存储,最终的表结构示意如表 1:


表 1 数据表 RowKey 设计



2 维度索引表

在数据表的设计中,tags 被编码进固定长度的 entity_id 中,同时 HBase 并没有对索引的原生支持,这导致无法通过 tag 找到对应的 entity_id,也就无法满足数据的多维度检索聚合需求。为此我们引入了一张索引表,建立从 tag 到 entity_id 的映射,以支持通过 tag 筛选数据。


如图 5 所示,通过指定一个 tag: k1=v1,可以查到所有包含这个 tag 的 entity_id1、entity_id2 和 entity_id3。



图 5 维度索引


RowKey 的构造比较简单:


RowKey = key + value


索引对应的 entity_id 直接作为 Column 的 Qualifier 存储,对应的 Column Value 留空,最终的表结构:


表 2 索引表设计



总结

底层存储选型和数据模型设计是 TSDB 设计中的两个重要的基础环节,前者决定了后者的设计思路,后者的设计影响上层功能的设计实现,二者又与集群的架构设计和性能表现息息相关。然而,影响系统性能和可用性的设计环节还有很多,接下来的文章将逐步为读者介绍百度 TSDB 在功能和架构上的设计实践。敬请期待~~


作者介绍:


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


本文转载自公众号 AIOps 智能运维(ID:AI_Ops)。


原文链接:


https://mp.weixin.qq.com/s/auC78dnssip2AMo9ygw1Ng


2019 年 9 月 09 日 18:491111

评论

发布
暂无评论
发现更多内容

TCP与UDP首部格式详解

互联网架构师小马

Java基础--2021Java面试题系列教程--大白话解读

JavaPub

Java 面试题 javapub

HDFS是如何设计架构的?

大数据老哥

关于垃圾收集器你了解多少?一文总结七大垃圾收集器

Java鱼仔

Java JVM 垃圾收集

创业失败启示录|雨季后的明媚阳光

青城

28天写作 创业失败启示录

如何养成一个好习惯

熊斌

读书笔记 28天写作

浪漫主义的消亡

石君

28天写作

GNUCash 5: 报表

lidaobing

GNUCash 28天写作

工程师思维是什么?能吃吗?

Justin

工程师思维 架构设计 28天写作

机器学习应用设计阶段的 10 个陷阱和 11 个最佳实践

浪潮云

机器学习

强无敌!阿里P8都在看的架构进阶宝典

互联网架构师小马

28天瞎写的第二百三十天:DIY 键盘的故事

树上

28天写作 机械键盘 GH60

壁纸收藏

小马哥

摄影 七日更

我们都很忙

Ian哥

28天写作

Vue3 中 v-if 和 v-show 指令实现的原理 | 源码解读

五柳

源码分析 前端 Vue3

WebPack | Loader处理非JavaScript模块机制详解

梁龙先森

JavaScript 前端 webpack 28天写作

原来酸奶是这个味道,真香!「幻想短篇 20/28」

道伟

28天写作

公司开始为远程办公做准备了

Tango

七日更

机器学习·笔记之:Cost Function - Intuition I

Nydia

架构师训练营知识点思维导图

晴空万里

架构师训练营第2期

进大厂必看!拼多多大佬总结的10万字Springboot经典学习笔记

武哥聊编程

Java springboot 28天写作

记录关于写作的两个小想法

JiangX

28天写作

Soul 源码阅读 05|Http 长轮询同步数据分析

哼干嘛

个人隐私之老话重谈

张老蔫

28天写作

前端模拟假数据(json-server光速入门篇)

学习委员

json 前端 Node 28天写作 json-server

产品训练营-第五课

Geek_娴子

淘宝网前期技术架构演进分析

andy

年底跳槽之 如何找工作方向?

一笑

职业规划 28天写作

技术根儿扎得深,不怕“首都”狂风吹!

Arvin

操作系统

开发质量提升系列:用户体验

罗小龙

最佳实践 方法论 28天写作

面对key数量多和区间查询低效问题:Hash索引趴窝,LSM树申请出场

华为云开发者社区

数据库 数据 存储 Hash索引 LSM树

2021年全国大学生计算机系统能力大赛操作系统设计赛 技术报告会

2021年全国大学生计算机系统能力大赛操作系统设计赛 技术报告会

百度大规模时序数据存储(二)| 存储选型及数据模型设计-InfoQ