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. 未来与展望

一、走进时序数据库

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

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

时序数据库的概念

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

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

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

时序数据库的迅猛发展

由于时序数据库的适用性非常广泛，因此其在 DB-Engine 上的受关注度一直处于增长态势。面对这样的关注度增长态势，时序数据库技术的发展也作出了积极的响应。无论是在开源领域还是商用领域，都推出了大量的时序数据库产品，比如 InfluxDB、OpenTSDB、TimescaleDB 以及阿里云时序时空 TSDB 等。

二、认识阿里云 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 亿。

三、阿里云 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 操作。

四、未来与展望

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

阿里云 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 还能够支持海量围栏，同时检测大规模移动目标。

本文作者：七幕

阅读原文

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