玉溪卷烟厂通过正确选择时序数据库 轻松应对超万亿行数据
公司简介
玉溪卷烟厂的前身是创建于 1956 年的玉溪烟叶复烤厂。1991 年，玉溪卷烟厂成为全国烟草行业唯一的“国家一级企业”，“红塔山”荣获国家金质奖章。
经历了几十年的发展，玉溪卷烟厂成为红塔集团的主要卷烟生产厂。
截至 2021 年底，玉溪卷烟厂拥有完备的打叶复烤线、制丝生产线、梗丝生产线、卷接机组、包装机组、滤棒成型机组，年卷烟生产能力 220 万箱以上，厂区占地面积 134.04 万平方米，在岗员工数千人。工厂 22 项对标指标同比提升 18 项，其中 4 项排名行业第一、13 项排名行业前十，前十指标数量在行业卷烟工厂中排名第二、在云南中烟所属卷烟工厂中排名第一。
业务背景
玉溪卷烟厂主要生产业务涉及复烤、制丝和卷包三个工艺流程。卷烟原料的烟叶复烤环节是卷烟生产的首个工艺流程，烟叶从烟田采摘完毕，转至烟农处进行初烤，根据商业公司的采购送至复烤车间，根据预先设置的配方，对烟叶进行工艺流程加工存储。卷烟制丝工艺是卷烟生产的主要加工工艺，制丝加工是根据原料烟叶的理化特性，按照一定的加工程序，经过多种加工工序把烟叶制成合格烟丝的过程。当烟丝、辅料及卷包设备准备就绪，生产将进入卷包工艺，主要包括风力送丝、滤棒输送、辅料出入库、卷接、包装、及成品出入库。与上述工艺流程相对应，生产业务涉及复烤车间、制丝车间和卷包车间三个车间。复烤车间主要将原烟分离成叶片和烟梗，再分别干燥；制丝车间主要将淳化的烟叶进行加料加香和切丝工作；卷包车间主要是将烟丝卷接成支，再分别包装成包、条和件。
制丝环节直接决定了成品卷烟的感官品质和烟丝质量，是卷烟加工的重要环节，提升制丝过程质量保障能力直接决定着卷烟内在品质，进一步影响着品牌在市场上的认可度。因此，围绕过程制造能力，围绕工艺品质提升能力，围绕数字化管理能力，打造稳定、强大、可靠的制丝数采，切实保障生产运营与工艺提升，是数字化转型、实现智能产线的基础。
而制丝车间本身生产设备多且工艺复杂，一条制丝线有 8 个工艺段，260 多类设备，每个设备 11 个分类，合计 3 万 6 千多个数采点。主要涉及温度、湿度、水分、重量、风量、流量、液位、频率等多种数据，这些数据产生频率高，而且是实时的，每个监测点每秒都会产生数据。由此产生的实时数据量之大也可想而知，对于磁盘存储空间的消耗也非常严重。此外，这些数据大多是设备产生，同时也是按照时间戳实时采集和记录，所以也会有比较多的插入操作，对于实时、高频率、海量写入和存储的需求较大。从这两点出发，时序数据库（Time Series Database）是比较理想的选择。
此次我们打造的项目是「精品线智能制造试点」，数据库存储的是制丝产线上产生的时序数据。此前我们使用的是国外传统的时序数据库，虽然它支持 OPC 数据直接采集，但在稳定性和安全性上存在一定的不足，而且还存在查询速度慢、运维成本高等问题。
后面切换到 TDengine 后，凭借着从时序数据特点出发设计的超级表机制，以及按照时间分片的存储引擎，即便是单表千亿级别的总数据量，TDengine 也可以在物理逻辑上完成划分，直接操作对应时间段的数据文件，摒弃无效的搜索消耗，这一点解决了我们最大的难题。另外基于高效的列式压缩设计，数据的存储成本也显著降低了。
实践经验
为推进高端高档精品线建设，提升高端卷烟加工的内在品质，精品线智能制造试点项目以提升精品线生产过程制造能力、工艺技术水平为目标，充分应用新的工艺技术、前沿的信息化手段，打造全流程感知、全产业链协同、决策过程实时、IOT 融合的前沿生产制造车间，确保生产全过程批内批间品质的稳定性和一致性。全过程感知架构如下图所示：
其中精品制丝线数据链路是这样的：PLC 设备通过 OPC Server 以 OPC UA 协议采集数据，然后把数据发送到 Kafka/Flink 集群，其中 Flink 起到消息缓冲的作用。Flink 的 job 运行在大数据平台 Yarn 的计算平台上，它里面包含 Kafka client、时间戳、窗口、数据过滤和聚合算子，架构如下图所示。
最后，数据通过 TAOSC 模块把数据写入我们部署的 TDengine 企业版 6 节点集群中。
我们每条产线有 8 个工艺段、每个工艺段 30 多个设备、每个设备有 1000 多个数采点类型，总结而言，设备采集点共有 36526 个，数据类型包括浮点数、布尔型、整型和字符串。自然而然，我们需要根据这个体系来建库建表。
考虑到好的建模是后续顺利使用 TDengine 的根基，因此我们在这上面也用了很多心思。当时一共有三种方案：
- 创建一张超级表存储所有采集点的数据，一个采集点一张子表。超级表采用单列模型，采集值类型为字符串。
- 优点：在获取某个 MES 业务计算所需要的 n 个测点全量数据时，可以用一条 SQL 查出，不需 join
- 缺点：布尔、浮点数也会作为字符串存储，压缩比会受影响，且无法使用预计算，还可能需要对结果集做列转行操作
- 创建多张超级表，单列模式，针对每一种数据类型创建一张超级表，一个采集点一张子表，采集点根据对应数据类型使用对应类型超级表。
- 优点：采集点增减可以灵活匹配，且数值型采集值有预聚和优化
- 缺点：获取某个 MES 业务计算所需要的 n 个测点全量数据时，需要分别从三个超级表中查询，后期考虑用 join，但仍会有结果集列转行的工作
- 为每个 MES 业务计算任务（比如产品质量计算）所涉及的采集点建超级表（也可能是普通表），采用多列模式。
- 优点：MES 业务涉及到的查询可以直接从对应表按时间段查出来，且不同测点的数据类型可以保留，预计算优化也会被保留
- 缺点：表结构固定，不同 MES 业务系统之间的超级表可能会用到相同的指标，这些指标的数据就会反复存储。如果 MES 业务计算需求变化，则需要修改表结构，写入时要求所有采集点字段同时写入
最终，我们决定采用方案二、方案三的组合。数据分库存储，一个库存单列模式的全量原始数据，一个库将 MES 业务计算的采集点单独存储，再起一个库存储震动的高频数据。
这样设计的好处主要有如下几点：
- 单列模式可以保证其他业务使用数据的灵活性，而 MES 业务需要的指标组合几乎不变，针对性建表就可以保证计算的便捷性；
- 超级表可以加数据标签，单列模式便于对数采点进行管理，能够将制丝数采点表的 BOM 结构延袭到 TDengine 中，从而能够实现基于标签的快速查询和筛选；
- 得益于 TDengine 强大的压缩能力，多出的数据并不会带来很多成本；
- 根据数据的重要程度和采集频率分库存储，对每一个进行采集存储程序的单独维护，互不干扰，有效保障存储稳定性，一个库的存储故障不会影响其他库。
落地过程&应用展示
最终，我们按照上述方案进行分库建表。
以 yjpzsa 库（制丝生产全量数据库）为例子，我们把 36526 个采集点，根据数据点类型设计成 7 个超级表。遵循一个数据类型一张超级表，一个数据采集点一张子表，表名使用数据点编码，且超级表标签继承数采点表 BOM 结构的原则，构建起“一码到底”的数采体系。
分别为 yjpzsa_bigint，yjpzsa_float，yjpzsa_nchar，yjpzsa_bool，yjpzsa_binary，yjpzsa_int，yjpzsa_timestamp。
能够方便的根据数据标签查询某个工艺段、某个设备的数采点，如下图所示为烘丝工艺段烘丝机实际测量分类下的数采点数据。
存储方面
其中既有单个字段 16 KB 的大表，也有只存单列数字类型数据的表：
我们主要的超级表都已经存储了数千亿行数据，总数据量轻松超过了万亿行。即便是在三副本（数据存储三份确保高可用）的配置下，目前占用的总空间也仅有 1TB 左右。
我们采集电机高频振动信号，信号频率为10 Khz，TDengine 支持我们将每秒一万条振动加速度数据存入数据库中，用于时域和频域分析，如下图所示。
查询方面
1. 对超级表 voltage_prop 表执行时间段查询。
select * from yjpzsa_phm_opc.voltage_prop where ts >'2022-06-22 10:00:000' and ts <'2022-06-22 15:10:000';
2. 对单设备的查询，既可以通过超级表筛选找到子表，也可以直接通过子表找到。
以上便是我们使用 TDengine 的落地过程与应用展示。
写在最后
从选型测试到落地使用至今，我们和 TDengine 团队一直保持着充分的合作与交流。在帮助 TDengine 完善自身的同时，我们也得到了越来越好的产品与服务，最终达成了现在的使用效果，我们双方对此都是满意的。也祝 TDengine 越来越好。
想了解更多 TDengine Database的具体细节，欢迎大家在GitHub上查看相关源代码。
