引言

随着近几年物联网的发展，时序数据迎来了一个不小的爆发。为了存储这些时序数据，各大企业纷纷推出自己的时序数据库。
Tablestore作为阿里云自研的NoSQL多模型数据库，能够提供海量结构化数据存储以及快速的查询和分析服务，其在存储模型、数据规模以及写入和查询能力上，都能很好的满足时序数据的场景，另外已经支持很多时序类业务，例如监控类的云监控，事件类的阿里健康药品追踪以及快递包裹轨迹等。
为了让用户能够更加专注于业务开发，我们提供了Timestream时序模型，其适用于监控、金融、轨迹溯源等时序业务场景。

时序数据简介

参考维基百科对于时间序列的定义：时间序列是一组按照时间发生先后顺序进行排列的数据点序列。简单来说，时序数据就是描述一个主体在一组时间点上的状态，这里的时间可能是周期性的采样，也可能是离散的，其中周期性采样的数据可以称监控类数据，离散的数据称之为事件类数据。

时序数据常见于IT基础设施、监控运维、物联网等场景中，比如说设备或应用监控数据、物流轨迹数据、金融股票K线等等，这些时序数据包含以下特点：

• 时间属性，数据包含时间信息，且写入的数据会按照时间顺序往后进行追加。
• 随机写入，在某个时间点会写入不同主体的状态，而不是相同主体的不同时间点的数据。
• 连续查询，会按照时间范围查询某个主体的数据。
• 写多读少，在时序场景中，写入的速率稳定且远大于读取。
• 数据维度很多，不同主体会有不同的维度信息，需要复杂的数据检索能力。

Tablestore在支持时序数据存储场景上，有比较大的优势，主要体现在：

• 高可用、高可靠、可伸缩
• 高并发写入能力
• 按照时间范围高效数据查询
• 复杂的时间线索引能力
• 数据聚合和分析能力
• 数据生命周期管理

Tablestore作为一个多模型分布式NoSQL数据库，为了更好的支持时序数据场景，新推出了Timestream模型。该模型主要应用于时序和时空场景，也是Tablestore综合了业界主流的时序数据库，所定义和抽象的数据模型。

Tablestore Timestream

数据模型

上面是时序数据的抽象模型，我们可以定义下时序数据的一个完整模型：

这个定义中包含：

• Name：定义数据的类别
• Tags：唯一标识个体的元数据
• Attributes: 个体的可变属性
• Timestamp：数据产生的时间戳
• Location：数据产生的空间信息
• Fields：数据对应的值或状态，可提供多个值或状态，非一定是数值类型

时序数据包含元数据和数据点两个部分，其中元数据由Name、Tags以及Attributes组成，而Name+Tags唯一确定某个元数据；数据点则是由Timestamp、Location以及Fields组成。

下面通过事件类的物流轨迹场景来看一下Timestream数据模型是如何使用的。

这是一个快递的物流轨迹数据，其记录的是快递在不同时间点的状态变化。该轨迹数据的元数据则是快递本身，包含了单号、物流平台、快递当前位置信息以及快递寄件/收件等元信息，其中单号以及物流平台的组合（Identifier）唯一确定这个快递。下面分析一下数据存储方式：

• 将物流平台作为Name进行存储，一个快递平台的数据属于同一类数据，对数据检索性能有一定的提升
• 将快递单号作为Tags存储，唯一确定一个快递
• 快递的其他元信息存储在Attributes中，避免Tags过长导致的性能问题，同时能够支持这些信息的修改
• 将快递的当前位置也存在在Attributes中，可以实现根据某个位置检索当前时间附近的快递
• 快递的轨迹时序数据（位置/状态）放在Fields中，可以查询某个快递在某个时间范围内的轨迹

特点和优势

以上是基于Tablestore Timestream来构建一个时序数据存储、计算和分析的完整架构。热数据通过agent直接写入到Tablestore中，再通过通道服务将数据增量流出到函数计算进行事件监测，以及流到流计算系统进行后聚合，再将聚合后的数据写回到表格存储中。
这是一套Serverless的架构，通过组合云产品的方式，能够做到提供完整的时序场景所需的所有功能。并且，各组件可以替换成其他同类云产品，架构灵活，相比开源时序数据库在以下方面有很大的优势：高性能&高可靠&高可用、全托管、元数据检索、冷热数据分层和灵活计算分析能力。

元数据检索

元数据是时序数据里非常重要的一块数据，其数据量比时序数据要小很多，但查询的复杂度却高很多，并且数据查询往往是需要先定位时间线，所以元数据检索是查询的核心之一。

元数据检索往往是通过Name, Tags,以及Attributes来定位满足条件的时间线。在元数据检索功能方面，Tablestore Timestream支持Name/Tags的精确查询、前缀查询，Attributes的GEO/精确/前缀/范围/模糊查询，还支持这四部分数据的多字段组合查询需求，能够很好的满足业务对于时间线元数据的检索需求。
性能方面，Tablestore Timestream能够支撑百亿级的时间线检索并且提供毫秒级的延迟。

计算分析能力

表格存储实现了与各计算产品的无缝对接，包括离线数据分析、流式计算、事件驱动等，能够提供灵活的计算分析能力，满足时序场景下的各类计算需求。特别是，Tablestore与Blink深度结合，可作为Blink的源和结果，让整个数据流可形成闭环，并借助Blink实现更灵活的计算配置，可以满足复杂的数据计算需求，比如说数据降维、降精度、异常状态检测、实时统计分析等需求。
另外，Tablestore也支持通过通道服务将数据增量实时流出，实现定制化分析。
Tablestore也提供了轻量级的交互式数据分析能力，满足常见的数据查询计算需求，比如sum，group by等。

冷热数据分层

时序数据有一个显著特征是数据访问冷热分明，最近写的数据会被更频繁的访问。基于Timestream的架构中，可以用高性能实例来存储热数据，满足交互式需要较快速度的数据分析。降维或者降精度之后的冷数据存储在容量型实例，满足离线计算场景。并且，对于冷数据，我们会通过Erasing Coding以及极致压缩算法进一步降低存储成本。

更多的时序介绍架构和优势介绍参考《Tablestore时序数据存储 - 架构篇》。

典型应用场景

前面介绍了时序场景根据数据的时间特性可以分为事件和监控两大类。这两类场景各有一些典型特征，比如说监控类场景时间线生命周期长，有降精度需求等；事件类场景时间线生命周期短，时间线数量庞大，无降精度需求，需要大规模时间线的高效检索。上面介绍了表格存储Timestream的优势，我们已经很好的支持了这两类业务，比如监控类的云监控，事件类的阿里健康药品追踪以及邮政包裹轨迹等。

后续我们会对不同的场景提供实战文档，敬请关注。

快速入门

1. 创建TimestreamClient

        AsyncClient asyncClient = new AsyncClient(endpoint, accessKeyId, accessKeySecret, instance);TimestreamDBConfiguration conf = new TimestreamDBConfiguration(metaTableName);TimestreamDB db = new TimestreamDBClient(asyncClient, conf);

1. 创建数据表和元数据表

        db.createMetaTable();db.createDataTable(dataTableName);

1. 读写数据

TimestreamIdentifier identifier = new TimestreamIdentifier.Builder("cpu").build();Point point = new Point.Builder(System.currentTimeMillis(), TimeUnit.MILLISECONDS).addField("a1", 1).build();// 写时序数据TimestreamDataTable dataTable = db.dataTable(dataTableName);dataTable.asyncWrite(identifier, point);// 查时序数据Iterator<Point> iter = dataTable.get(identifier).timeRange(TimeRange.range(0, 10000, TimeUnit.MILLISECONDS))    //查询[0, 10000)范围内的数据.fetchAll();// 写时间线元数据TimestreamMeta meta = new TimestreamMeta(identifier).addAttribute("a1", "");TimestreamMetaTable metaTable = db.metaTable();metaWriter.put(meta);// 查时间线元数据TimestreamMeta meta = metaTable.get(identifier).fetch();

更多示例请参考：Timestream使用参考

扩展阅读

基于Tablestore的Wifi设备监管系统架构实现
基于Tablestore管理海量快递轨迹数据架构实现
药品监管系统架构揭秘：元数据管理与轨迹溯源

欢迎加入

如果您对表格存储、时序模型感兴趣，对模型使用有疑问、想探讨，欢迎加入【表格存储公开交流群】，群号：11789671。