主题简介：

大家好，我是张观石，目前在虎牙直播负责直播业务运维工作。之前看到社群发了一篇《基于InfluxDB+Grafana打造大数据监控利器》，提到了时序数据库，今天分享主题有点类似，不过我会从不同的角度来说一说。

为什么会讲时序数据库呢？各位DBA可能主要关注关系型数据和各种NoSQL，而时序数据库最近有一种兴起趋势，所以特地拿来讲一讲。

时序数据库是一种为了处理时间序列数据而特别优化的数据库。它以时间系列为关键索引，特别适合于连续时间分片的数据存储和检索。主要用于处理带时间标签（按照时间的顺序变化，即时间序列化）的数据。

在传统行业，如电力行业、化工行业、物联网等各类型实时监测、检查与分析设备所采集、产生的数据，都是时间序列数据，这些工业数据的典型特点是：产生频率快（每一个监测点一秒钟内可产生多条数据）、严重依赖于采集时间（每一条数据均要求对应唯一的时间）、监测点多信息量大（常规的实时监测系统均有成千上万的监测点，监测点每秒钟都产生数据，每天产生大量数据）。

目前很多企业对于时序大数据的存储和处理往往采用关系型数据库的方式进行处理，但由于关系型数据库天生的劣势导致其无法进行高效的存储和数据的查询。时序数据库通过使用特殊的存储方式，使得时序大数据可以高效存储和快速处理海量时序数据，是解决海量数据处理的一项重要技术。该技术采用特殊数据存储方式，极大提高了时间相关数据的处理能力，相对于关系型数据库它的存储空间减半，查询速度极大的提高。特别在互联网行业的运维监控，业务监控中使用。

时间序列

我们常说的时间戳，timestamp，unix_time 是一个时间点，而无数个时间点连接起来就是所谓的时间系列，简称时序。

时序数据

带维度标签、以时间点或时间范围为索引的数据也称为时序数据。理解为某一度量指标在某一时间点的一个值。

时序数据结构

从以上几点可以了解时序数据应该包括几个方面：度量指标、标签、值、时间点。

举个例子，度量指标数据：

这里分成几个部分：

• Metric：usercount

• Timestamp：1497344217 

• Value：500

• Tags：platform=dbaplus，speaker=zhangguanshi

各部分解释：

• Metric：监控项/指标度量，如同时在线用户usercount。

• Tags：标签/维度，在OpenTSDB里面，Tags由tagk和tagv组成，即tagk=tagv。标签是描述Metric的属性，分享主题的讲师，tags可为speaker=zhangguanshi。

• Value：一个Value表示一个metric的实际数值，譬如上面的500

• Timestamp：即时间戳，用来描述产生时序数据的时间点，上面的1497344217 

• Data Point：即某个Metric在某个时间点的数值。

  1）Data Point包括以下部分：Metric、Tags、Value、Timestamp

  2）上面描述的本场分享在21:09时候的同时在线用户，就是1个DataPoint

数据特点：

• 基本上都是插入，没有更新的需求；

• 数据基本上都有时间属性，随着时间的推移不断产生新的数据，旧的数据不需要保存太久；

• 业务方对时序数据通常有几个查询需求；

• 获取最新状态，查询最近的数据（例如传感器最新的状态）；

• 展示区间统计，指定时间范围，查询统计信息，例如平均值，最大值，最小值，计数等；

• 获取异常数据，根据指定条件，筛选异常数据。

跟普通数据的区别1：

• 时序数据库就是存放时序数据的数据库；

• 而时间序列是无穷的，不断递增的，而指标也可以成千上万，为海量数据而设计的；

• 时序数据是特别为顺序写入；

• 时间是数据库插入查询的核心条件，以时间为连续条件。

跟传统数据库的区别2：

• 时序数据库简单，没有复杂模式/范式设计。某一度量指标在某一时间点只会有一个值；

• 没有事务；

• 写多读少无更新；

• 顺序读、区间范围读；

• 基数大。

时序数据库要解决的问题：

• 以时间点为顺序产生的数据；

• 数据量大，数据来源多；

• 数据的维度多，不同指标有不同维度；

• 统计查询复杂，如任意时间访问，多粒度的检索；

• 需要快速响应查询；

• 对中小团队收益特别大。

简介

在《解密Google SRE》一书中作者提到了Google的监控系统borgmon 和 prometheus非常像。prometheus是一款开源的时序数据库，可以想见Google也是用的类似时序数据库进行监控。Fackbook开源了时序数据库引擎Beringei。他们内部也用的这个做监控。阿里巴巴的Goldeye黄金眼，也是一款时序数据库；百度云产品TSDB，主要用于物联网相关的监控；国内非常火的监控系统Open-falcon也是一款开源时序数据库。当然还有知名的开源软件：Graphihe、OpenTSDB、InfluxDB、Druid、TimeScaleDB等。

我们看下DB-Engine网站对时序数据库的排行。

出处：https://db-engines.com/en/ranking/time+series+dbms

参考资料：http://liubin.org/blog/2016/02/25/tsdb-list-part-1/

这里以OpenTSDB为例重点介绍下时序数据库的一些技术。

介绍Opentsdb及相关组件

Tsd和存储层

OpenTSDB的核心，本身比较简单，是Java实现的一套程序。用来读写底层存储及数据处理。

存储：

OpenTSDB底层存储使用的HBase，自然ZooKeeper、HBase、Hadoop HDFS是少不了的。其架构分布式、高可用也是由HBase实现。

Rowkey的设计是亮点：

说OpenTSDB没有设计模式是指上层上报来的数据，在底层OpenTSDB还是有存储表的，在往HBase中写入和查询使用了一套自定义的数据结构，OpenTSDB的存储格式是在HBase存储了几个表：

• Data Table：表名默认叫tsdb ，存储时序数据的表。

• UID Table：表名tsdb-uid，UID映射表，时序数据存储时不用实际的字符串，而是经过此表映射之后，取得一个UID，存储在data table中的其实是整个uid。

• Meta Table：元数据表，时间序列数据的索引表。

• Tree Table ：树表，也是存储元数据用的。

• Rollup 表：存储rollup 和 pre-aggregation的数据。

WebUI

OpenTSDB有多个展示端，Grafana是其中一个支持得较好的。前面文章也讲到了Grafana，这里不多讲。

采集层

采集支持udp协议、http协议、telnet。可使用多种采集上报方式，包括脚本、应用内上报等。

保存数据最简单的方式是：

告警层

官方推荐是bosun，一套强大的开源告警软件。

插件

开发了新插件，如支持内部uid到主播的映射。

背景

大家可能都知道直播是众多互联网行业中技术比较复杂的技术，视频从主播端采集到推流节点，到转推环节，到分发网络，到观众端，这么复杂的链路中要保障音视频直播的流畅是很有挑战的。

视频质量指标很多：

• 感官卡顿比 

• 网络卡顿比 

• 错误率

• 慢速比

• 视频加载成功率

• 播放时延

• 卡比例

• 视频加载时间

• 连接时间

• RTT

微服务的质量指标：

虎牙直播后端是微服务架构，我们把数千个微服务的成功率，调用次数、延时等信息都通过时序数据库来监控。

同时在线用户规模大

维度多：分端、分地区、分主播、分线路

所以部分用户说卡的时候，要分析N多种情况。

基本架构

整套系统包括采集、存储分析、输出等几个部分，采集端使用了多种采集手段和方法。

在系统的使用层包括账号、安全这些通用措施，也包括TSDB数据层，存储层，及前端展示UI层。

输出是利用时序数据库中的数据实现运维需求。

技术架构

我们采集了所有能采集到的质量相关数据，其中包括主播、观众、中间各个环节。采集数据规模非常的大，要实时采集，尽可能实时展示，所以全部都直接读写TSDB是不行的，我们通过流式计算的环节进行预处理，这一层是微服务架构，可以很容易扩展。原始数据可能是各种复杂格式的，通过预处理也可以达到过滤、聚合、预计算的目的，可以按业务的需求进行灵活处理。

我们微服务的质量数据，包括成功率、调用延时数据原来是通过MySQL保存，通过开发web后台来展示，后来改造为通过时序数据库来保存展示。

监控告警

Bosun 是一个新型的监控和告警系统，由Stack Exchange团队打造，使用Golang编写，支持定义复杂的告警规则，支持OpenTSDB、Graphite、Logstash-Elasticsearch 等数据源。bosun 将是Zabbix、Nagios的有力竞争者。

bosun从TSDB读取时序数据，可以经由bosun表达式做一系列的计算，根据告警策略发送告警，告警的内容是定义好的bosun模板。

这些质量监控告警不断持续反馈给各相关人员、厂商。实时告警打通各渠道：微信、QQ、钉钉、YY、邮件等。

时序数据的其它用途

我们还通过TSDB API从时序数据库获取数据，定制各种定期报告如日报、周报等。

质量数据效果图：

Q1：虎牙用的是时序数据库+大数据构建业务监控体系吗？

A1：是的，在预处理环节有分析逻辑。

（接上问）

Q2：那么这样做应该只能对:应用层做监控，对吧？涉及到数据库如MySQL就没办法监控，是吗？

A2：时序数据库也适合基础监控，我个人主要做业务运维，所以重点是业务监控。

Q3：预处理是用什么作的？怎么实时写OpenTSDB？

A3：是一套微服务程序，Java的，上报到这里，经过分析后得到指标数据，再存入TSDB。

（接上问）

Q4：这和其它的实时分析有何区别？

A4：时序数据库以极低的成本来存储分析时序数据，其它实时分析会重不少，场景也不太一样。

Q5：也就是说时序数据库主要应用在应用监控？还有其它场景应用吗？

A5：前面说了也适合基础监控。只要是时间顺序数据都可以存。

Q6：时序数据库的瓶颈是什么，可以分享下这个应用监控体系构建中的一些经验吗？如果我们也准备构建一套监控的话。

A6：在我们使用过程中，分布式的写入性能，查询性能有碰到问题。OpenTSDB散列要均匀。

https://m.qlchat.com/topic/270000376855401.htm?isGuide=Y

密码：666