DTCC 2019 | 阿里云TSDB: 教你解锁时序时空数据库的种种黑科技

阿里云TSDB是阿里自研的一种高性能，低成本，稳定可靠的在线时序时空数据库产品。该产品统一了阿里巴巴集团90%以上的APM数据和事件型数据的存储和计算，并在普遍应用于外部的物联网，工业制造，电力，化工以及IT运维等行业。本文中，阿里云智能数据库产品事业部技术专家伊翼就为你们介绍了阿里云TSDB的种种黑科技。

专家简介：伊翼（花名：老滚）。阿里云智能数据库产品事业部技术专家，主要从事TSDB核心引擎的研发工做。

直播回放

连接：https://yq.aliyun.com/live/1044

议题PPT下载，戳这里！

https://yq.aliyun.com/download/3563

本次分享的内容主要包括如下四个方面：

1. 走进时序数据库
2. 认识阿里云TSDB
3. 阿里云TSDB技术内幕
4. 将来与展望

1、走进时序数据库

熟悉而又陌生的时序数据
时序数据库自己是一个比较新的概念，直到5年前，DB-Engine才将时序数据库列为一个独立的分类。虽然时序数据库的概念比较新，可是时序数据却由来已久。从古至今，在咱们的平常生活中，时序数据从未缺席。古代记录灾害与祥瑞出现时间的县志也可以发挥相似今天时序数据库的做用，帮助决策者指定相关的决策，地方官员能够根据县志中的记录判断是否须要进行祭祀，也能够决策是否须要向中央朝廷报告祥瑞以谋取升迁等，所以当时的县志也发挥了相似于OLAP的功能。但因为理念和技术的限制，当时所记录的时序数据信息是有限的，精度也是有限的。

技术发展到今天，时序数据所能记录的信息和精度都有了极大的提高。以下图所示的是杭州市空气监测时序数据片断。由此能够看出，时序数据有一些共同的特征，好比多样的指标值、比较稳定的采集频率以及任何一个数据点都有时间戳。在技术飞速发展的今天，时序数据的规模愈来愈大，增加速度也愈来愈快。所以，咱们须要面对一些问题，好比面对如此大规模的时序数据，应该将其存放在哪里。

时序数据库的概念
在十几年前，时序数据只能选择存放在关系型数据库中，可是随着通讯技术的发展，特别是互联网技术的发展，时序数据的增加速度呈现指数级别，使用关系型数据库来存储时序数据显然跟不上时代的节奏了，因此时序数据库应运而生。时序数据库就是一类专门为处理时间序列数据而设计并优化的数据库管理系统。

相较传统的关系型数据库，时序数据库的特色以下：
 存储的任何一条数据记录都必然带一个时间戳
 一般高频访问热数据
 数据写入频率相对稳定，且远大于数据读取的频率
 一般按照时间窗口查询数据
 基本不提供单点数据的更新或删除功能
 无需提供相似关系型数据库事务级别的数据强一致性

目前，使用时序数据库的行业应用愈来愈普遍。
 电力行业：智能电表、电网、发电设备的集中监测
 交通行业：实时路况，路口流量监测，卡口数据的采集与分析
 石油石化：油井、运输管线、运输车队的实时监测
 物流行业：车辆、集装箱的追踪监测
 环境监测：天气、空气、水文、地质环境等监测
 物联网：电梯、锅炉、机械、水表、气表等各类联网设备的数据采集、分析与检测
 军工行业：军事装备的数据采集、存储与分析
 制造业：生产过程管控，流程数据、供应链数据采集与分析
 互联网：互联网应用的PV/UV数据，基础设施的性能监控

时序数据库的迅猛发展

因为时序数据库的适用性很是普遍，所以其在DB-Engine上的受关注度一直处于增加态势。面对这样的关注度增加态势，时序数据库技术的发展也做出了积极的响应。不管是在开源领域仍是商用领域，都推出了大量的时序数据库产品，好比InfluxDB、OpenTSDB、TimescaleDB以及阿里云时序时空TSDB等。

2、认识阿里云TSDB

阿里云时序时空TSDB架构
以下图所示的是阿里云时序时空TSDB的总体架构，从左到右依次是采集端、TSDB服务端以及靠近最终用户和开发者的实例端。在采集端，阿里云时序时空TSDB采用了边缘计算的解决方案，其能够应用在资源受限或者网络情况不稳定的场景下。采集端能够和服务端进行打通，服务端能够向边缘下发各类各样的规则，使得边缘端可以直接进行数据清洗和计算，这就实现了“边云一体化”。图中的中间部分是TSDB的服务端，它也分为几个组件，TS计算引擎主要负责预聚合、降精度以及持续查询，TSQL引擎主要负责处理SQL查询，此外还有一个基于已经训练好的模型算法库，提供各行业定制化解决方案的智能引擎。在这三个引擎下面就是TSDB的时序引擎。

接下来为你们介绍阿里云时序时空TSDB在功能层面的一些特性。
特性1：强力的数据模型支持
阿里云TSDB支持多样的数据模型，同时支持了多值模型和单值模型。举例而言，温度监控设备须要每间隔一段时间向数据库上报温度数据，其上报的数据中必然带有一个时间戳以及温度值，这样最基础的数据形式称之为单值模型。而若是上报的数据中不只仅包含了一个时间戳和室内温度，还包含了室外温度以及空气湿度等，这样的数据就能够称之为多值模型。其实，时序数据库对于多值模型的支持并非行业要求，所以即使是在开源领域，各类数据库对于多值模型的支持也不一样。支持多值模型的好处在于能够提高数据的写入效率，另一方面就是对于业务应用的开发者而言可使得设计更加直观。

除了对于多值模型的支持以外，阿里云TSDB还支持多种的数据类型，不只支持传统数据类型，还可以支持字符串类型数据，而且可以支持精确到毫秒的时间戳。

特性2：降采样&数据聚合 
对于时序数据库而言，降采样和数据聚合也是很是重要的特性。依旧以温度采集为例，温度采集设备可能上报数据的频率很是高，好比每秒钟上传一次数据，可是在作数据查询的时候并不须要按照原始的数据采集频率进行分析和展现，所以就须要对于上报的数据进行降采样操做，好比将按秒采样的数据降采样为按小时或者按天进行分析和展现。

与之相对的，数据聚合在分析和展现中也很是重要。一般状况下，有不少个数据采集设备，不一样设备每隔一段时间上报数据的时候就认为这些数据属于不一样的时间序列，而随着设备的增多，必然使得时间序列变得很是多，而在作分析和查询的时候并不须要对多个时间序列进行分析，只须要将其进行汇总，好比使用汇总后的平均值进行分析。这种状况下就是对于一个数据的指标值按照时间维度将多个时间序列聚合成一条，这就是数据聚合。不管是降采样仍是数据聚合，阿里云TSDB都提供了很是丰富的聚合算子，有了这样的能力，就能够仅凭借阿里云原生能力来知足各类复杂的查询分析场景。

特性3：SQL查询能力 
因为时序数据库自己属于比较新的概念，为了下降开发人员以及数据分析人员使用时序数据库的门槛和学习成本，阿里云TSDB也提供了基于SQL的查询接口。有了SQL的查询接口，用户就能够很是方便地使用SQL来操做时序模型。而阿里云TSDB的SQL接口也基于时序场景进行了算法上的优化，能够将SQL中的过滤、聚合等操做所有下推到TSDB的内核中，这样就能够最优化的方式来处理时序数据的分析和查询。

特性4：内置对接Prometheus
在最新版的阿里云TSDB中，已经实现了内置对接Prometheus的能力。Prometheus是一个很是适用于监控Kubernetes集群的工具，可是其对于监控数据的存储能力比较薄弱，虽然社区也考虑到这一点而且提供了Prometheus Adapter的第三方组件来将Prometheus的数据对接到各类各样的数据源上，可是当数据链路中增长一个组件就意味着查询性能的下降。为了在阿里云TSDB对接Prometheus的同时保持较高的查询效率，TSDB内置了对接Prometheus的能力。通过测试，内置对接Prometheus的方式相对于经由Prometheus Adapter中转方式的查询性能要高不少。

特性5：边缘计算能力
阿里云TSDB的边缘端计算能力处于行业内的领先地位。由于在物联网应用和工业大数据的应用场景中，没法保证数据的采集端是实时在线的，这样的场景就是边缘计算的用武之地。考虑到用户数据的可用性，TSDB边缘端再设计的时候也采用了高可用架构。当网络情况恢复稳定的时候，边缘段会将数据同步给阿里云TSDB服务端，这样能够方便用户在服务端进行统一的数据分析和查询。

与其余时序数据库的功能对比 
下图中的表格列出了目前主流的时序数据库在功能特性上的支持状况对比。

接下来为你们介绍几个阿里云TSDB实际的应用案例。
案例1: 某互联网餐饮系统研发企业

该企业在本身的解决方案中将阿里云TSDB整合了进去，利用阿里云TSDB高性能写入将整个链路中的全部时序数据以及业务指标所有写入了TSDB中，借助TSDB优越的查询性能以及将监控系统整合在一块儿，从而支持了对于整个解决方案中全部链路节点的实时监控，与此同时提升了系统的总体稳定性。

案例2:某直播平台运维监控APM

该直播平台原来的APM系统中将全部采集到的时序数据所有经过消息队列存储到OpenTSDB集群中，可是很快就发现OpenTSDB的写入存在瓶颈，并且OpenTSDB在时序索引方面天生存在薄弱点，所以在面向较为复杂的查询的时候，几乎处于不可用的状态。在通过比较以后，该直播平台选择使用阿里云TSDB来替换全部的OpenTSDB，而且加大了写入规模，从实际效果来看，阿里云TSDB达到了所指望的效果。

案例3: 阿里巴巴集团内部全业务对接
最后的一个案例是阿里巴巴集团内部的案例。从上图能够看出，不管是底层的资源调控、总体监控仍是上层应用，阿里云TSDB已经覆盖了阿里集团内部的130余个线上业务。而在2018年双11大促期间，阿里云TSDB承接的来自于阿里集团内部的各个业务的时序数据，写入TPS峰值达到了4000万TPS，查询峰值达到了2万QPS，累计时间线数量超过了100亿。

3、阿里云TSDB技术内幕

时序时空TSDB引擎的核心技术
阿里云时序时空TSDB引擎具备不少的核心技术，在本次分享中主要为你们介绍数据压缩、时序索引以及聚合引擎三个方面的核心技术。

数据压缩
时序数据的规模增加速度很快，而用户每每出于往后须要进行查询或者分析的考虑，但愿所可以存储的时序数据越多越好。可是一般状况下，对于大规模时序数据的查询而言，每每很是困难。一方面须要知足用户对于查询的需求，另一方面须要有效地下降用户存储的成本。针对于以上两方面的诉求，阿里云TSDB研发了一套数据压缩技术。下图中左侧是一张示意图，其每一行表明一个时间序列，其列表明数据点。在没有进行数据压缩的状况下，若是想要将其数据调整到毫秒级别，就会发现其列数会增长到360万，这样的数据量是很是可观的，因此必需要进行压缩。阿里云TSDB所采用的压缩思路借鉴了Facebook Gorilla的实现思路，会将时间戳和数据两块压缩成两个大数据块，对时间戳采用了delta-delta的压缩方法，而对于不一样的数据类型则采用了相应的数据压缩算法。在压缩成两个大数据块基础之上，再对其进行通用的块压缩。通过两部分的压缩就使得数据压缩比达到15:1的效果。

以下图所示的是真实场景下的数据压缩效果。原始状况下数据大约6TB，一开始尝试最普通的块压缩，将数据压缩到了715G，但此时的数据压缩比不到10:1，而采用先进行时序压缩再追加一次块压缩后使得最终数据压缩为413G，压缩比达到了15:1。那么，追求如此之高的数据压缩比有什么好处呢？其实主要有两个好处，第一个好处就是可以帮助用户下降存储成本；另一个好处就是由于数据压缩比很大，所以当在进行大范围的时序数据查询的时候，IO效率会很是高，在这个例子中能够将查询延时下降约50%。

时序索引
TSDB的总体查询流程很是简单，当用户指定了一个查询条件，阿里云TSDB首先会解析这个查询条件，同时作必定程度的优化。接下来会作两件事情，一件是将查询条件扔给时序索引模块，时序索引模块会根据查询条件计算命中的时间线数量以及相关信息，拿到时间线信息以后再将时间线集合扔给聚合索引，聚合索引再到底层存储上面获取相应的时间数据并进行降采样、聚合等操做。虽然这一过程看上去比较简单，可是却存在不少值得研究的点。

以下图所示的是时间线的生命周期，若是用户想要查询T2-T3时间范围内的数据，确定不但愿数据中包含T0-T2已经消亡或者说再也不有新的数据进来的时间线，因此这部分也是时序索引能够进一步研究的地方。

对于时序索引而言，还须要支持模糊查询，所谓模糊查询就是给出的并非一个完整的时间序列定义，而多是Tag的全量匹配，或者基于Tag或者Tag Value的模糊查询，须要可以找到相应的时间线，此时就须要基于Tag Key或者Tag Value作一个倒排索引。在时间序列生命周期的启发下，在倒排索引技术基础之上，TSDB增长了时间序列生命周期的倒排索引。同时加上对于生命周期的进一步过滤，最终获得相对较少的时间线。将这些相对较少的时间线扔给下一层进行计算的时候就会带来一个好处就是减小了IO，提供了极致的查询性能。除了上述优化工做以外，TSDB还将整个倒排索引持久化到存储层，这使得索引节点能够处于无状态的结构，而且使得水平扩展变得很是容易，对于时间线数据实现TTL。

在时序索引模块中还实现了一个评估器， 评估器会以本身认为的最合适的方式计算时间线，由于当查询条件很是复杂的时候，计算时间线的方式有不少种，就比如在关系型数据库中作Join也有不少种方法。评估器会根据几个相应的来源作评估，分别是HHL技术器、BloomFilter以及时序索引缓存。HHL计数器所记录的就是倒排索引中命中的时间线数量，BloomFilter记录的是时间线是否还真实存在的状况，这两部分数据并非很是精确的，它们是在过去写入查询的过程当中所获得的粗略统计数据。可是当时间线自己出现量级差别的时候，这样的评估就会变得很是有意义，其可以以最优化的代价来获取时间线。所以，评估器的做用就相似于关系型数据库中的CBO (Cost-based Optimizer)。

聚合引擎
时序索引的下个模块就是聚合引擎，时序索引将查询条件所命中的时间线集合获取以后交给聚合索引。而聚合索引就是按照传统关系型数据库的执行器的火山模型模型进行设计的，咱们为其设计了不少的聚合算子和插值算子，这些算子都是以Pipeline方式进行一轮轮迭代的。目前，一共实现了10多个核心聚合算子，20多个填充策略以及10多个插值算法，而且这些算子的数量还在不断地增长中。

借助聚合引擎，能够减小内存开销以及对于底层存储的查询压力，这是由于有了算子的支持以后，只须要每次抓取少批量数据进行计算便可。此外，聚合引擎和预聚合、降采样也进行了无缝对接，当数据写入的时候已经实施了采样过程，在实际查询的时候就能够很容易地实现采样，聚合引擎就不会从存储层捞取原始数据，而是直接捞取预降采样数据，从而进行进一步的数据计算，这就减小了底层存储的IO操做。

4、将来与展望

最后为你们介绍一下，阿里云数据库技术团队目前在时序时空领域所作的工做和尝试。

阿里云TSDB自研引擎的将来像

阿里云TSDB自研引擎的将来四个发展方向主要包含四点：

1. 冷热数据异构存储；对于用户而言，每每但愿将时序数据所有保存下来，所以须要考虑写入、存储以及查询成本等。而对于时序数据而言，用户每每对于热数据更感兴趣，所以可能须要考虑冷热数据异构存储。目前，TSDB正在尝试与阿里云OSS存储解决方案进行打通。
2. Serverless读写能力；但愿可以赋予阿里云TSDB以Serverless读写能力，拥有该项能力就能够进一步下降存储和计算成本。
3. 拥抱时序生态；将来，TSDB还将更加紧密地拥抱时序生态。TSDB目前已经对接了Prometheus的生态，而在将来会进一步对接更多开源生态，但愿可以经过与生态的对接使得阿里云TSDB中一些比较有意义的特性可以发挥更大的价值。
4. 时序智能分析；阿里云TSDB也但愿可以在时序智能方面训练更多的模型，而且深刻到各个具体的行业中，为行业解决特定的问题。

时序时空领域的新尝试
阿里数据库团队除了在自研时序数据库方面作了大量的工做以外，还在其余方面进行大量的尝试。好比开源版时序数据库InfluxDB的云端产品化——TSDB for InfluxDB，其瞄准的痛点就是若是用户使用开源版本的自建InfluxDB时，会感受到内存管理不稳定，在进行一些稍微复杂的查询时就会触发OOM。TSDB for InfluxDB会优化和重构InfluxDB的内存管理模块，提升稳定性。 
TSDB for InfluxDB

由于时序数据库在整个业界而言都是比较新的技术，能够想象若是使用自建的InfluxDB，运维成本就会很是高，而若是使用了TSDB for InfluxDB的基于阿里云服务，运维成本就会极大地下降，除了可以获得99.9%的SLA承诺，并可以获得InfluxDB专家的在线技术支持。虽然阿里云对于InfluxDB作了改动和产品化，可是不影响二者生态的兼容。TSDB for InfluxDB能够无缝地对接到用户的Telegraf、Chronograf以及Kapacitor工具链中。TSDB for InfluxDB在上月月底正式上线进行公测，公测期间无偿使用，所以你们若是感兴趣能够尝试，而且也提供了数据的零感知迁移工具，可以帮助用户一键式实现数据迁移。

TSDB for Spatial Temporal

阿里云数据库团队还在作的另一项尝试就是TSDB for Spatial Temporal，其属于存储时空数据的数据库。TSDB for Spatial Tempora为基于时空数据构建大规模应用提供了两大利器——自研的S3时空索引和高性能电子围栏。S3 时空索引实现千万级时空数据的秒级查询能力，助力用户实现时空数据的低延迟查询分析，知足实时交互查询及实时数据分析场景。并且TSDB for Spatial Temporal还可以支持海量围栏，同时检测大规模移动目标。

原文连接 本文为云栖社区原创内容，未经容许不得转载。