时序建模思路
本文档为“时序数据建模”章节的第二篇。YMatrix 认为，数据模型的设计会直接影响到数据消费与使用的价值。因此，除技术介绍外，我们尝试通过整个章节使你对时序数据模型（Time-series Data Model）的概念、应用及发展都有清晰的理解。
- 首篇为“时序数据模型是什么？”，通过回答几个层层深入的问题，最终使你对时序数据模型概念本身有清晰的理解。
- 第二篇“时序建模思路”（即此文档）将尝试从理论指导的角度给出 YMatrix 关系模型设计思路参考。
- 第三、四篇为车联网场景及智能家居场景下的数据建模示例，以“时序建模思路”为指导，给出 YMatrix 中不同时序场景的建模最佳实践。
1 首先：了解时序数据模型
在构建属于你的时序数据模型前，请先从此章节首篇文档：时序数据模型是什么？了解 YMatrix 眼中的时序数据模型。
2 其次：了解时序场景需求
YMatrix 认为，了解现有的时序查询特点，即是了解了现有的时序场景需求的核心。一个实际时序场景，通常拥有着综合的查询需求，它可能是下表中几种不同查询需求的集合。下表的应用场景主要以车联网场景为示例。
| 查询特点 | 描述 | 应用场景 |
|---|---|---|
| 单设备 | ||
| 单设备点查询 | 查询单个设备某个指标或多个指标在某个时间点的值，最常见的查询是某个设备某些指标的最新值或非空最新值 | 某辆车行驶中的实时车速等 |
| 单设备明细查询 | 查询某个设备在某个时间区间的明细数据，可能涉及单个指标也可能是多个指标 | 通常为进一步的详细分析，如售后服务中的故障原因分析 |
| 单设备聚集值 | 查询某个设备的某些指标在某个时间区间的聚集值，譬如最大值、最小值、第一个值、最后一个值、平均值等 | 车辆在某段时间内的平均速度等 |
| 多设备 | ||
| 多设备点查询 | 查询多个设备在某个时间点的指标值，可能涉及单个指标也可能是多个指标 | 组合信号查询，状态监测（如车辆油/电量低时启动报警机制）；查询指标 a 和 10s 前的指标 b ，看是否匹配，以判断车辆是否处于某种状态（如车辆老化） |
| 多设备明细查询 | 查询多个设备在某个时间区间的明细数据，可能涉及单个指标也可能是多个指标 | 数据现象发现。如根因分析、新品追踪等。一般面向研发人员 |
| 多设备聚集值 | 查询多个设备的某些指标在某个时间区间的聚集值，譬如最大值、最小值、第一个值、最后一个值、平均值等，并按照设备分组 | 各区域网络状况检查，求平均网速以确认多个车到达某一地点是否都网络不好 |
| 其他查询 | ||
| 多维查询 | 根据标签或属性信息查询符合条件的设备的最新值、明细或聚集值，如果涉及到多个设备，则会按照设备分组 | 监测车辆的当前状态 |
| 多表关联 | 多表关联查询可以清晰地知晓时序数据的特定含义，多表关联得到的内容可以成为限定某个时序数据含义的定语集合，YMatrix 中通过 JOIN 语句实现这一功能 |
如不同车辆业务表关联分析等 |
| 高级分析 | 子查询、窗口函数、Cube、CTE、累计和、增量计算、增速计算、变化点、信号跳变差值查询、分位数函数、行列转换、累计分布函数、CASE...WHEN...表达式、滑动窗口、线性插值、峰值检测、递归查询等 |
特定模式识别、趋势预测、根因分析、阈值修正、异常数据检测、售后故障分析、监控大屏展示、即席分析、电池告警、尖峰值过大告警、异常数据清洗、空值填充、指定设备在指定时间范围内指定指标的 TOP N 峰值等 |
| 联邦查询 | 访问 MySQL 等数据库、访问 Hive | 部分数据存放在 MySQL 等数据库中，支持和数据库进行关联查询、离线数据存放在 Hive 等系统中，支持和其中数据进行关联查询 |
| 机器学习 | 线性回归预测 | 根据 1 月 1 日至 10 日的数据，计算线型回归模型，来预测 11 日的指标 |
| 时空特定查询 | first 函数、last 函数、窗口查询等，有时还会涉及到与空间数据相结合的查询 | 开始油量、结束油量等 |
3 最后：设计时序数据模型
现在，你已经根据你想得到的数据可视化结果，推断出了你所应掌握的时序场景查询需求及数据源（数据采集的源头），可以进入正式的模型设计阶段，恭喜。
综上信息，你大概能估计出该场景的设备数量、数据规模、指标数量、指标数据类型。没错，正是这些因素决定了你的模型设计之路。
3.1 核心判断因素
| 核心判断因素 | 描述 |
|---|---|
| 设备数量 | 不同场景下的“设备”可能有不同语义，如车联网场景下“一个设备”可能指一辆车，也可能指一个传感器 |
| 指标类型 | 指标的数据类型。如 int、float、text 等 |
| 指标数量 | 指标数量或规模 |
YMatrix 认为时序数据建模的三个核心判断因素为：设备数量，指标类型，及指标数量。
设备数量、指标类型、指标数量对于前期模型设计阶段有着不同方面的影响：
- 首先，设备数量、指标类型、指标数量三者都关乎于模型的数据点容纳能力。除此之外，数据采集频率及保存时长对模型容纳能力的评估也有一定的影响。考虑到随着业务的不断发展，其涉及到的设备数量、指标类型和数量都会不断增长，同时不同业务对数据保存时长、采集频率的需求都不同，在前期设计阶段，我们需要对一段时间内时序数据模型的动态容纳能力有充分的预测。
- 其次，指标类型与指标数量前期设计阶段的确定性有多高会直接影响到我们对于宽表 / 宽表变式 / 窄表 / 窄表变式模型的选取。在指标数据类型、指标数量的确定性都较高的情况下，首选宽表及宽表变式模型，因为这样最有利于保持优越的查询性能；在指标数量无法预知，但指标类型确定性较高的情况下，可以使用窄表变式模型；在两者确定性均较低的情况下，可以使用窄表模型，将写入的简便最大化。
3.2 选取时序模型类型
在“数据建模”章节的首篇 什么是时序数据模型？ 中我们已详细介绍过非关系模型与关系模型的关系，同时简单介绍了宽表、宽表变式、窄表、窄表变式有何不同。在此篇文档，将着重介绍如何选取具体的模型类型。
3.2.1 数据指标及其类型确定的场景 —— 宽表
使用宽表模型意味着你最终将得到一个包含很多指标名列及指标值列的时序表。根据你拥有的指标数量，宽表可以变得非常宽，正如其名称所示。经过前期的良好设计，宽表查询速度会非常快。在单个表中看到 200 或更多列是很常见的。以下是宽表的一个简单示例：
| 时间戳 | 设备ID | 温度 | 风力 | 湿度 |
|---|---|---|---|---|
| 2021-11-16 13:57:13 | 1 | 29.2 | 3.2 | 55 |
| 2021-11-16 13:57:13 | 1 | 21.5 | 8.5 | 35 |
| 2021-11-16 13:57:13 | 1 | 22.3 | 7.2 | 40 |
| 2021-11-16 13:57:13 | 2 | 24.1 | 6.8 | 21 |
| 2021-11-16 13:57:13 | 2 | 19.8 | 2.9 | 38 |
| 2021-11-16 13:57:13 | 2 | 20.7 | 4.5 | 56 |
| ...... |
宽表是 YMatrix 的优势模型。其一行承载的数据信息更多，而时间戳、设备 ID 列均只有一个（因为只有一张指标表），这样就减少了冗余。对于创建索引来说，窄表的索引开销很明显，而宽表由于行数少，索引的代价也相对低，利于查询性能。就上述示例而言，假如你想要知道每个设备的相关温度数据，可以通过创建一张可以映射设备和指标关系的 Lookup 表来拆分这些表，实现单设备/部分多设备查询。
那么只有一张表的宽表，对存储的利用已经达到极致了吗？我们认为，这要根据具体业务场景写入空值的情况来判断。值列为空或不为空，主要取决于实际指标数据采集的方式和频率。实际上，在有大量空值数据写入的场景（我们也称之为超宽稀疏表）下，空值数据也占用了相当大的存储空间。
在设计好的宽表模型上增加新的“指标名列 + 指标值列”，或增加新的指标值类型都不算简便，因此宽表前期设计成本相对窄表更高，需要周全地考虑。但一旦有了良好的设计，很大程度上也就收获了后期良好的查询性能。
其主要适用于前期设计阶段数据指标及其类型就已经相对确定的场景，如某些车联网相关场景等。
3.2.2 数据查询频率分级明显 —— 宽表变式
在一些场景中，对于不同指标数据的查询频率有很大差异。此情况下，YMatrix 通过实现结构化 + 半结构化的宽表变式工作流，将被高频查询的数据和被低频查询的数据以不同方式写入表，保护高频数据的查询性能的同时，平衡了低频数据的写入便捷性。所谓“结构化”即关系型数据库中传统宽表的存储方式，“半结构化”则意味着在现有宽表（即将超出最大列数限制）的最后一列使用半结构化的存储方式（JSON / MXKV）存储扩展指标名与指标值数据，以此实现超宽表灵活的扩展性。简单示例如下：
| 时间戳 | 温度 | 风力 | 湿度 | ...... | 标签 |
|---|---|---|---|---|---|
| 2021-11-16 13:57:13 | 29.2 | 3.2 | 55 | 气象传感器，型号 A，北京市，怀柔区 | |
| 2021-11-16 13:57:13 | 21.5 | 8.5 | 35 | 气象传感器，型号 A，上海市，崇明区 | |
| 2021-11-16 13:57:13 | 22.3 | 7.2 | 40 | 气象传感器，型号 A，北京市，海淀区 | |
| 2021-11-16 13:57:13 | 24.1 | 6.8 | 21 | 气象传感器，型号 B，北京市，怀柔区 | |
| 2021-11-16 13:57:13 | 19.8 | 2.9 | 38 | 气象传感器，型号 B，上海市，崇明区 | |
| 2021-11-16 13:57:13 | 20.7 | 4.5 | 56 | 气象传感器，型号 B，北京市，海淀区 | |
| ...... |
3.2.3 数据指标及其类型不确定的场景 —— 窄表
窄表布局与宽表正好相反，窄表的一个普遍特征是指标值列很少，通常只有一个。以下是一个简单的窄表模型示例：
| 时间戳 | 设备ID | 指标名 | 指标值 |
|---|---|---|---|
| 2021-11-16 13:57:13 | 1 | 温度 | 29.2 |
| 2021-11-16 13:57:13 | 1 | 风力 | 3.2 |
| 2021-11-16 13:57:13 | 2 | 温度 | 21.5 |
| 2021-11-16 13:57:13 | 2 | 风力 | 8.5 |
| ...... |
如你所见，窄表模型中除固定的“时间戳 + 标签（设备 ID）”组合外，只有一个指标名列和一个指标值列，指标名列存储了所有的指标名，指标值列存储了所有数据类型相同的指标值。也就是说，如果业务升级需增加指标或设备，只需增加一行数据即可。如果需存储的指标值类型增多，则需要增加相应指标值类型的列或者创建相应的表来存储其他类型。因此就需要改表结构或者创建额外的表。当然，如果你经常使用 JSONB 为值列的数据类型，你也可以选择在此列中存储有效的 JSON 值，不过请注意，这样会同时增加额外的 JSON 解析。
窄表模型在例如泛物联网（IoT）场景智能家居等：前期设计阶段设备数量、类别或指标非常不确定的场景下占有优势。数据存储、写入、模型扩展都很简易，但这需要在指标值类型也相对单一的前提下。因为每增加一个指标值类型，都意味着要新增一张除了指标值外所有列都冗余的表。
3.2.4 指标不确定但其类型确定的场景 —— 窄表变式
在某些实际场景中，指标值的数据类型会随着业务需求不断增加。对于这种情况，传统的窄表模型只能通过增加表数量的方式实现扩展。显然，此种方法是很大有局限的。因此，我们可以设计一个窄表的变式：其尺寸介于窄表和宽表之间，基本设计原则是为每种必要的数据类型都创建一列。也就是说，如果我们有两种不同的数据类型：整数和浮点数（假设为 float8）。那么我们最终会得到两个不同的值列，如下所示：
| 时间戳 | 设备ID | 指标名 | 指标值_int | 指标值_float |
|---|---|---|---|---|
| 2021-11-16 13:57:13 | 1 | 温度 | 29.2 | |
| 2021-11-16 13:57:13 | 1 | 风力 | 3.2 | |
| 2021-11-16 13:57:13 | 1 | 湿度 | 55 | |
| 2021-11-16 13:57:13 | 2 | 温度 | 21.5 | |
| 2021-11-16 13:57:13 | 2 | 风力 | 8.5 | |
| 2021-11-16 13:57:13 | 2 | 湿度 | 35 | |
| ...... |
使用这种设计，常常需要另外再建一张查找表（Lookup）。
| 指标名 | 数据类型列名 |
|---|---|
| 温度 | 指标值_float |
| 风力 | 指标值_float |
| 湿度 | 指标值_int |
写入或查询具体指标值时，便可通过 JOIN 语句连接两张表来定位数据位置。
如果你需要更多指标值类型，添加更多列即可。与提前了解所有可能的指标相比，提前了解所有可能的指标值类型相对容易一些，同时也需要知道指标值类型和指标的映射关系。
注意！
具体场景下的模型构建示例请见车联网场景下的数据建模示例及 智能家居场景下的数据建模示例。