关于数据库:玉溪卷烟厂通过正确选择时序数据库-轻松应对超万亿行数据

4次阅读

共计 3504 个字符,预计需要花费 9 分钟才能阅读完成。

公司简介

玉溪卷烟厂的前身是创立于 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 业务计算的采集点独自存储,再起一个库存储触动的高频数据。

这样设计的益处次要有如下几点:

  1. 单列模式能够保障其余业务应用数据的灵活性,而 MES 业务须要的指标组合简直不变,针对性建表就能够保障计算的便捷性;
  2. 超级表能够加数据标签,单列模式便于对数采点进行治理,可能将制丝数采点表的 BOM 构造延袭到 TDengine 中,从而可能实现基于标签的疾速查问和筛选;
  3. 得益于 TDengine 弱小的压缩能力,多出的数据并不会带来很多老本;
  4. 依据数据的重要水平和采集频率分库存储,对每一个进行采集存储程序的独自保护,互不烦扰,无效保障存储稳定性,一个库的存储故障不会影响其余库。

落地过程 & 利用展现

最终,咱们依照上述计划进行分库建表。

以 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';

  1. 对单设施的查问,既能够通过超级表筛选找到子表,也能够间接通过子表找到。

以上便是咱们应用 TDengine 的落地过程与利用展现。

写在最初

从选型测试到落地应用至今,咱们和 TDengine 团队始终放弃着充沛的单干与交换。在帮忙 TDengine 欠缺本身的同时,咱们也失去了越来越好的产品与服务,最终达成了当初的应用成果,咱们单方对此都是称心的。也祝 TDengine 越来越好。


想理解更多 TDengine Database 的具体细节,欢送大家在 GitHub 上查看相干源代码。

正文完
 0