Timestream开发最佳实践

背景

Timestream模型是针对时序场景设计的特有模型，可以让用户快速完成业务代码的开发，实现相关业务需求。但是，如果业务系统不仅想实现基础的相关业务功能，还要达到最佳的性能，并且兼顾到未来的扩展性的话，就不是一件特别容易的事情。

本文会以共享汽车管理平台为例，介绍一系列的timestream最佳设计和使用，给业务设计和使用提供一些参考。

场景和模型简介

在共享汽车管理平台这个场景中，主要是对车辆的状态轨迹监控、车俩元数据以及订单元数据进行管理。另外，还会对相关的数据进行计算分析并存储相关结果：

车辆状态轨迹：记录了车辆的状态监控，比如车速、位置、续航等数据，另外还需要记录车辆行驶过程中的违章记录，比如：是否超速、是否闯红灯等等；
车辆元数据：记录车辆的基本属性信息，便于用户进行车辆检索，比如：车型、车牌、颜色等；
订单元数据：订单相关信息记录，包含行程的起止时间、车辆、用户、费用等信息

业务主要是对上面三部分数据进行查询和检索，满足业务场景的需求。其中车辆元数据以及状态轨迹数据是典型的时序序列，可以很方便的映射到Timestream模型中。

下图是数据模型的映射：

下面介绍一下模型设计的细节以及设计中需要注意的一些优化点，这些优化点对于业务功能以及性能上都有一定的提升。

业务模型设计

在Timestream模型中，主要包含了元数据和数据点两部分数据，分别使用一个元数据表以及若干个数据表进行存储。下面介绍这两类数据在存储设计的关键点。

元数据表设计

在共享汽车这个场景下，元数据表主要存储两类数据：车辆的基本信息、车辆的最近状态数据（位置、续航、状态、违章统计等），业务会根据各类信息进行多条件的组合查询符合条件的车辆。

如上图所示，Timestream的元数据表会通过多元索引来提供丰富的数据检索能力。在Timestream模型的元数据中，包含了name、tags、attributes三类数据，其中name、tags默认会提供数据检索能力，attributes则需要在创建Meta表的时候指定需要索引的attributes字段以及相关信息，默认attributes并不支持检索。
需要注意的是，目前并不支持动态修改Meta表的索引字段，所以最好能在设计之初能够考虑到当前以及未来的功能需求，下面介绍一下相关信息是如何映射到模型以及相关的设计。

name设计

name字段的选取是很关键的，是数据检索性能的一个重要影响因素，不同的name字段设计可能会导致查询延时相差一个数量级。name字段的选取建议满足以下条件：

绝大多数查询场景都会对该字段进行精确查询
该字段单个取值下的最大记录数不宜过多，比如说不超过一千万条记录

在共享汽车管理平台这个场景下，管理的是各个平台的车辆，而在车辆检索的时候，一定会指定的条件是平台的名字，并且某个平台的车辆其实也不会太多，一般也就百万量级，所以这里可以将平台作为name。

tags设计

在Timestream模型中，Name和Tags可以唯一确定某个元数据，在这个场景中，唯一确定某辆车的信息是：平台、车辆ID，其中平台是name，所以，tags中只需要存储ID即可。
tags设计需要注意：

tags的总长度尽可能的短，只把唯一确定主体的信息放到tag中，其余信息均放到attributes中
tag只支持string类型的数据，如果业务字段是数值类型，需要将其转成string进行存储

attributes设计

attributes是主体的可变属性，也可以用来存储主体的非唯一属性。在这个场景中，车辆的基本信息以及当前状态都是用attributes来进行存储。attributes设计关键点：

创建meta表的时候需要指定有检索需求的attributes以及相关属性，默认attributes是不支持索引的
数值型数据尽可能使用int来存储，attribute支持多类型的数据，但在数据检索过程中，int类型的数据检索效率比string类型高的多，建议使用int，索引类型为LONG
考虑未来系统的扩展性，可以预留一列作为扩展字段，索引类型为KEYWORD，并且是Array

索引创建示例代码：

public void createMetaTable() {db.createMetaTable(Arrays.asList(new AttributeIndexSchema("地区", AttributeIndexSchema.Type.KEYWORD),...// 数值类型索引new AttributeIndexSchema("座位", AttributeIndexSchema.Type.LONG), ...// 扩展字段，数组类型索引new AttributeIndexSchema("配置1", AttributeIndexSchema.Type.KEYWORD).isArray()  ));

数据表设计

Timestream可以支持多个数据表的存储，来满足不同的业务场景需求。另外，为了能够利用底层引擎所做的性能优化，我们推荐append的写入方式，即不会对已有数据进行修改，所以在以下场景中，我们建议业务将数据分到不同数据表中进行存储：

数据精度不同，特别是在监控场景下，这个需求更加突出。按数据精度分表便于后续数据的查询，如果查询长周期的数据可以去查询低精度的表，减少查询的数据量，提高查询效率
需要对数据进行加工处理，也就是会对数据进行更新，建议将处理之后的数据写到另外一张表中

在共享汽车这个场景中，需要对车辆的状态轨迹数据进行流式处理，比如检测是否超速等违章、车辆状态轨迹是否异常等，然后将处理之后的数据写到另外一张表中，提供给业务进行查询。

sdk使用

前面介绍了业务模型设计需要注意的地方，对业务功能拓展能力以及性能都有一定的提升。下面介绍一下timestream sdk使用的一些性能优化点。

数据写入

元数据

元数据写入支持两种方式：put和update。其中put会删除老的记录，并且插入一个全新行；update则是对原有记录的部分attributes进行更新。建议尽量使用Put的方式进行写入。
示例代码：

public void writeMeta() {TimestreamIdentifier identifier = new TimestreamIdentifier.Builder("*滴").addTag("ID", carNo).build();TimestreamMeta meta = new TimestreamMeta(identifier).addAttribute("地区", "杭州").addAttribute("座位", 4)....addAttribute("状态", "闲置");// 插入车辆信息metaWriter.put(meta);
}

数据点

数据点写入也提供了两种方式：同步和异步。其中异步接口底层是通过TableStoreWriter进行异步写入，其写入吞吐能力更高，对写入延时不是特别敏感的业务建议使用异步方式。
示例代码：

public void writeData() {TimestreamIdentifier identifier = new TimestreamIdentifier.Builder("*滴").addTag("ID", carNo).build();Point point = new Point.Builder(1546272000, TimeUnit.SECONDS).addField("位置", "30.1457580736,120.0563192368").addField("车速", 30).addField("续航", 100).build();// 异步写入dataWriter.asyncWrite(identifier, point);
}

数据查询

元数据查询

元数据查询的时候，建议指定需要返回的列名。如果没有显示指定列名的话，会去读主表以获取完整的信息，这样每一行元数据都会反查一次主表，查询性能会更差一些。
示例代码：

Filter filter = Name.equal("*滴");// 用selectAttributes指定需要返回的attributes
Iterator<TimestreamMeta> iter = metaTable.filter(filter).selectAttributes("座位", "状态").fetchAll();