3. 工业数据模型与Schema设计

在工业时序数据库落地过程中，Schema 设计往往比数据库选型本身更早决定系统上限。设备、测点、标签三者构成工业数据的基本骨架：设备是物理或逻辑资产，测点是设备上被采集的物理量或状态量，标签则是对设备和测点进行分组、过滤、聚合的维度信息。三者不是简单的父子关系，而是“设备—测点”构成采集路径，“标签”横向附着在路径上，形成可检索、可聚合的索引面。

一、设备-测点-标签的层次化建模

以一条水泥生产线为例，设备层可包含“回转窑1号”“篦冷机2号”“生料磨A”；测点层挂在设备下，如回转窑1号的“窑尾温度”“窑头负压”“主电机电流”；标签层则描述这些测点的归属与属性，例如 line=clinker_01、area=kiln、unit=rpm、vendor=siemens。在时序库中，通常把设备与测点合并为一条时间线标识（metric），标签作为该时间线的元数据集合。

层次化建模的关键是确定“什么进路径、什么进标签”。经验规则是：变化频率极低、用于唯一定位时间线的信息进路径，如设备编号与测点编码；需要频繁用于过滤、分组、聚合的维度进标签，如产线、区域、工段、设备类型。若把设备编号也做成标签，会导致时间线数量膨胀且路径语义弱化；若把区域、工段写进路径，则后续按区域聚合时无法利用标签索引，只能做字符串匹配。

二、窄表与宽表模型对比

窄表模型把每个测点值写成一行，字段通常为 timestamp、metric、tags、value。它的优势在于写入路径统一、新增测点无需改表结构、标签索引天然可用，且同一 metric 的连续值在列式存储中压缩率很高。缺点是单设备多测点查询需要按 metric 过滤后聚合，若标签基数过大，索引膨胀会拖慢写入。

宽表模型把同一时间戳下多个测点值放在一行，列即测点。它的优势是单行读取快、列裁剪友好，适合“固定测点集合、按时间范围取多列”的场景。缺点是测点增删需要改表结构，稀疏采集时大量空值浪费存储，且标签维度难以直接附着在列上，通常需要额外维表关联。

三、标签索引设计

标签索引的本质是把“标签键值对”映射到时间线集合。设计时要控制三个量：标签基数（不同取值的数量）、标签组合数（笛卡尔积规模）、查询选择度（过滤后剩余时间线比例）。例如 line 只有 3 条产线，基数低、选择度高，适合做一级索引；batch_id 每批次都不同，基数极高，若直接建索引会导致索引条目爆炸，通常应改为范围查询或写入时降维。

一个可执行的索引设计检查表如下：

• 列出所有标签键，标注基数与更新频率；
• 基数 < 100 且查询频繁的键，建倒排索引；
• 基数 > 10000 的键，评估是否降维为数值列或分区键；
• 组合查询最多的 2～3 个键，建立联合索引；
• 定期统计各标签选择度，淘汰低效索引。

四、对存储成本、查询性能与容量规划的影响

存储成本方面，窄表在列式压缩下通常比宽表节省 30%～60%，因为同一 metric 的值类型一致、变化连续，适合 delta 与字典编码；宽表在测点稀疏时，空值仍占列位，压缩收益下降。查询性能方面，窄表在“按标签过滤 + 多测点聚合”场景更优，宽表在“单设备固定测点 + 时间范围扫描”场景更优。容量规划方面，窄表按“时间线数 × 采样频率 × 保留时长 × 单点字节”估算，宽表按“行数 × 列数 × 单值字节”估算，前者更贴近实际写入量。

综合来看，工业场景更推荐“窄表为主、宽表为辅”的混合策略：高频、多测点、强标签过滤的采集数据走窄表；固定测点集合、需要单行快速读取的报表或快照走宽表。Schema 设计阶段就应把设备、测点、标签的层次关系固化下来，并据此确定索引与分区策略，避免后期因标签基数失控或测点频繁变更导致存储与查询双双劣化。