云栖深度干货 | 打造“云边一体化”，时序时空数据库TSDB技术原理深度解密

时间 2019-12-20

标签深度干货打造一体化时序时空数据库 tsdb 技术原理解密栏目 SQL 繁體版

原文原文链接

本文选自云栖大会下一代云数据库分析专场讲师自修的演讲——《TSDB云边一体化时序时空数据库技术揭秘》html

自修 —— 阿里云智能数据库产品事业部高级专家算法

认识TSDBdocker

第一代时序时空数据处理工具虽然通用关系数据库能够存储时序数据，可是因为缺少针对时间的特殊优化，好比按时间间隔存储和检索数据等等，所以在处理这些数据时效率相对不高。第一代时序数据典型来源于监控领域，直接基于平板文件的简单存储工具成为这类数据的首先存储方式。以RRDTool，Wishper为表明，一般这类系统处理的数据模型比较单一，单机容量受限，而且内嵌于监控告警方案。数据库

第二代面向时序时空领域的数据库伴随着大数据和Hadoop的发展，时序数据量开始迅速增加，系统业务对于处理时序数据的扩展性等方面提出更多的要求。基于通用存储而专门构建的时间序列数据库开始出现，它能够按时间间隔高效地存储和处理这些数据。像OpenTSDB，KairosDB等等。架构

这类时序数据库在继承通用存储优点的基础上，利用时序的特性规避部分通用存储的劣势，而且在数据模型，聚合分析方面作了贴合时序的大量创新。好比OpenTSDB继承了HBase的宽表属性结合时序设计了偏移量的存储模型，利用salt缓解热点问题等等。然而它也有诸多不足之处，好比低效的全局UID机制，聚合数据的加载不可控，没法处理高基数标签查询等等。随着docker，kubernetes, 微服务等技术的发展，以及对于IoT的发展预期愈来愈强烈。并发

在数据随着时间而增加的过程当中，时间序列数据成为增加最快的数据类型之一。高性能，低成本的垂直型时序数据库开始诞生，以InfluxDB为表明的具备时序特征的数据存储引擎逐步引领市场。它们一般具有更加高级的数据处理能力，高效的压缩算法和符合时序特征的存储引擎。好比InfluxDB的基于时间的TSMT存储，Gorilla压缩，面向时序的窗口计算函数p99，rate，自动rollup等等。同时因为索引分离的架构，在膨胀型时间线，乱序等场景下依然面临着很大的挑战。less

第三代云时序时空数据库从2016年开始，各大云厂商纷纷布局TSDB，2017.4 Microsoft发布时序看法预览版，提供的彻底托管、端到端的存储和查询高度情景化loT时序数据解决方案。强大的可视化效果用于基于资产的数据看法和丰富的交互式临时数据分析。针对数据类型分为暖数据分析和原始数据分析，按照存储空间和查询量分别计费。2018.11 Amazon在AWS re Invent大会发布Timestream预览版。适用于 IoT 和运营应用程序等场景。提供自适应查询处理引擎快速地分析数据，自动对数据进行汇总、保留、分层和压缩处理。按照写入流量，存储空间，查询数据量的方式计费，以serverless的形式作到最低成本管理。运维

阿里云智能TSDB团队自2016年初版时序数据库落地后，逐步服务于DBPaaS，Sunfire等集团业务，在2017年中旬公测后，于2018年3月底正式商业化。在此过程当中，TSDB在技术方面不断吸纳时序领域各家之长，逐步造成了高性能低成本，免运维，易用性逐步提高，边云一体化，生态丰富等产品优点。分布式

技术揭秘函数

1. 分布式流式聚合器

时序聚合运算是时序数据库区别于通用数据库的特点之一。TSDB的聚合器主要算子涵盖了插值，降采样，降维等等OpenTSDB协议中的计算函数。借鉴传统数据库执行模式，引入pipeline的执行模式（aka Volcano / Iterator 执行模式）。

Pipeline包含不一样的执行计算算子(operator), 一个查询被物理计划生成器解析分解成一个DAG或者operator tree，由不一样的执行算子组成，DAG上的root operator负责驱动查询的执行，并将查询结果返回调用者。在执行层面，采用的是top-down需求驱动 (demand-driven)的方式，从root operator驱动下面operator的执行。这样的执行引擎架构具备优势：

这种架构方式被不少数据库系统采用并证实是有效;

接口定义清晰，不一样的执行计算算子能够独立优化，而不影响其余算子;

易于扩展：经过增长新的计算算子，很容易实现扩展功能。好比目前查询协议里只定义了tag上的查询条件。若是要支持指标值上的查询条件(cpu.usage <= 70% and cpu.usage <=90%),能够经过增长一个新的FieldFilterOp来实现

从查询优化器到生成执行计划，把查询语句重写成子查询后构建Operator Tree, 执行器驱动Operators完成聚合逻辑，执行Fragment顺序：Filtering -> Grouping -> Downsampling -> Interpolation -> Aggregation -> Rate Conversion -> Functions

区分不一样查询场景，采用不一样聚合算子分别优化，支持结果集的流式读取和物化, Operator的结果在包含None,dsOp等状况下采用流式聚合，而一些时间线之间的聚合仍然是物化运算。

2.时空数据的查询和分析

在介绍时空数据的查询分析以前，简单介绍下什么是时空数据以及时空数据的特色。

大数据时代产生了大量的有时间和空间、标记对象个体行为的时空数据。

好比我的手机产生的信令数据、共享出行的司乘位置和订单数据、车联网和无人驾驶行业的实时车辆数据、物流的位置流数据，以及外卖小哥的送餐轨迹等，都是这类数据。

时空数据的特色之一是复杂性和目标的多样性，存在许多时空分析方法，好比聚类，预测，变化检测，频繁模式挖掘，异常检测和关系挖掘。

时空数据另一个特色是数据量级呈指数型增加，也是时序数据的在高维空间的展开。传统数据库可伸缩性差，难以管理海量时空数据。高并发状况下，因为存储和计算没有分离，时空数据的检索会是很大瓶颈，可能形成检索性能急剧降低，响应时间超过数分钟。

面对这样的数据量、计算量和对分析延时要求的挑战，时空数据库TSDB从多个技术维度进行了突破。如存储计算分离、高性能时空索引、时空SQL优化器、时空计算引擎、时空数据压缩算法。

**时空过滤条件的识别与下推

有别于通用数据的<，>和=关系，时空数据的查询过滤条件一般是一些相似于st_contains(),

st_intersects() 的空间分析函数。所以SQL优化器会解析识别过滤条件之中的时空过滤条件，根据存储引擎的特性，决定哪些过滤条件能够下推，若是有没法下推的条件，则会将这些条件留在Filter算子之中，由计算引擎来进行过滤。而若是过滤条件能够被下推，则优化器会生成新的Filter算子。优化先后的关系算子以下图所示：

时空计算引擎

在通用数据库中，JOIN是两张表之中某两个列相等，对应的有NestedLoopJOIN、HashJOIN，SortMergeJOIN等算法。

对于时空数据而言，找到两个相等的几何对象几乎不可能，可能是基于st_contains()等空间位置关系或是st_distance()距离关系，来作JOIN。

好比找出云栖小镇附近1千米的全部出租车，JOIN条件就是出租车位置要包含在云栖小镇为圆心，半径1千米的圆形空间范围以内；好比找出离我最近的出租车，这就要用到KNN JOIN。而这些JOIN就超出了通用数据库JOIN算法能够优化的范畴。

在时空数据库TSDB之中，采用了专门的Scalable Sweeping-Based Spatial Join算法、时空索引、存储层+计算层的Two level index进行优化。当SQL优化器识别到两表JOIN的条件为时空分析函数时，若是参数等条件都符合要求，则SQL优化器会生成专门的时空JOIN算子，采用专门的JOIN算法来实现，这样的算法比朴素的JOIN算子性能要高出不少。

开源生态

TSDB 提供开源influxDB 和开源Prometheus 两大生态的支持。

influxDB是DBengines上排名第一的时序数据库，阿里云influxDB®在开源influxDB基础之上提供一下功能：

1.水平可扩展集群方案

2.全局内存管理

3.全面兼容TICK生态

水平可扩展集群方案

使用raft实现influxDB数据节点的高可用，同时提供多个高可用方案，让用户能够在可用性和成本中选择最适合本身的方案。

阿里云influxDB®支持根据数据量大小，动态增长influxDB数据节点的高可用组。