TableStore时序数据存储 - 架构篇

摘要： 背景 随着近几年物联网的发展，时序数据迎来了一个不小的爆发。从DB-Engines上近两年的数据库类型增长趋势来看，时序数据库的增长是非常迅猛的。在去年我花了比较长的时间去了解了一些开源时序数据库，写了一个系列的文章（综述、HBase系、Cassandra系、InfluxDB、Prometheus），感兴趣的可以浏览。

背景

随着近几年物联网的发展，时序数据迎来了一个不小的爆发。从DB-Engines上近两年的数据库类型增长趋势来看，时序数据库的增长是非常迅猛的。在去年我花了比较长的时间去了解了一些开源时序数据库，写了一个系列的文章（综述、HBase系、Cassandra系、InfluxDB、Prometheus），感兴趣的可以浏览。

这几大开源时序数据库的实现各有千秋，都不是很完美，但是如果可以取长补短，倒是能实现一个比较完美的时序数据库。

TableStore作为阿里云自研的分布式NoSQL数据库，在数据模型上我们是多模型设计，包含和BigTable一样的Wide Column模型以及针对消息数据的Timeline模型。在存储模型、数据规模以及写入和查询能力上，都能比较好的满足时序数据场景的需求。但我们作为一个通用模型数据库，时序数据存储要完全发挥底层数据库的能力，在表Schema设计以及计算对接上，都要有比较特殊的设计，例如OpenTSDB针对HBase的RowKey设计以及UID编码等。

本篇文章是架构篇，主要探讨时序数据的数据模型定义、核心处理流程以及基于TableStore来构建时序数据存储的架构。之后还会有方案篇，会提供一个高效的时序数据和元数据存储的表Schema设计以及索引设计方案。最后还会有计算篇，会提供几个时序数据流计算和时序分析的方案设计。

 

什么是时序数据

时序数据主要划分为两类，一类是监控类时序数据，另一类是状态类时序数据。当前开源的时序数据库，针对的都是监控类时序数据，针对该场景下数据特征做一些特定的优化。但按照时序数据的特征来看，还有一类是状态类时序数据。这两类时序数据分别对应不同的场景，监控类顾名思义对应的是监控场景，而状态类针对的是其他场景，例如轨迹溯源、异常状态记录等。我们最常见的包裹轨迹，就是状态类时序数据。

但为何把这两类数据都归类到时序，因为在数据模型定义、数据采集、数据存储以及计算上，两者是完全一致的，可以抽象出用同一个数据库及同一套技术架构。

 

时序数据模型

在定义时序数据模型之前，我们先对时序数据做一个抽象的表述。

• 个体或群体（WHO）：描述产生数据的物体，可以是人、监控指标或者物体。通常描述个体会有多维的属性，可以通过某一类唯一ID来定位到个体，例如身份ID定位到人，设备ID定位到设备。也可以通过多维属性来定位到个体，例如通过集群、机器ID、进程名来定位到某个进程。

• 时间（WHEN）：时间是时序数据最重要的特征，是区别于其他数据的关键属性。

• 时空（WHERE）：通常是通过经纬度二维坐标定位到地点，在科学计算领域例如气象，通过经纬度和高度三维坐标来定位。

• 状态（WHAT）：用于描述特定个体在某一刻的状态，监控类时序数据通常是数值类型描述状态，轨迹数据是通过事件表述状态，不同场景有不同的表述方式。