时序 + 分析:YMatrix “智慧工厂“数据平台双方案详解

前言

过去一年,YMatrix 参与了诸多制造业相关项目。从动力电池产线,到手机工厂,再到电动车制造。这些行业,作为先进制造业,是落地和实践"智慧工厂"理念的先锋厂商。在与这些客户的合作过程中,我们对于"智能制造"这一领域客户需求的理解,也得到了极大加深。

今天,我们就从实际项目中观察到的典型问题出发,抽丝剥茧,谈谈"智能制造"到底需要什么样的数据解决方案?

01 "智慧工厂"难点在哪?

在 YMatrix 深耕的先进制造业领域中,几乎所有客户早已使用了很高水平的数字化技术,比如:MES、SCADA、QMS、设备运维与 BI 看板,这些客户已具备了产品生产制造的全流程的数字化能力。那么这些代表了国内外先进制造业先进实践的 IT 系统,是否能很好的满足不同角色用户的需求呢?

过去,我们在各种项目中,经常听到种种类似的抱怨:管理人员抱怨实时性差,无法及时调整产线参数;高管抱怨看板内容不足,无法实现多种指标联合分析;IT 人员抱怨架构复杂,数据链路天天出问题......

这些抱怨的根源是什么,如何才能解决?需要我们深入挖掘工厂场景中,从数据生产与数据消费每个环节中的常见问题开始。

1.1 采数

性能是第一个考点。M 工厂从试制线向小批量生产、大规模量产,再到多品类柔性制造演进,全厂目前已部署超 1000 台设备,每台设备挂载上千个采集点位,以秒级频率上报压力、温度、电流等时序信号,每秒产生数万条记录,单日保守估计可达 17 亿行规模,能不能承载这样的数据量,是数据库要解决的第一个难题。

其次,在高度数字化的工厂中,由于制造业本身的行业特点,采数过程本身面临诸多挑战,并非单一的采数存数的性能问题。F 工厂随着近年来产能逐步扩大,产线逐步增加、换代,由于产线品牌不同,代际差异,其采集的数据频率、指标数量,字段名称,指标单位等都各有分别。除此之外,整个产品生产全周期涉及多个系统,未来要进行统一分析,就需要将不同数据源的数据集中存储,否则数据就只能停留在单一系统中,只能进行盲人摸象式的分析,无法为整体效率优化提供更高维度的视角。

F 工厂项目前期调研中了解到的不同系统所使用的数据库

1.2 流动

不同产线的的设备,虽然一般都带有自己的数据库,然而性能、功能有限,要实现具备全局的视角的分析,一方面要进行数据加工处理,一方面还需要汇总和其他数据关联分析。因此,数据的流动又是一个门槛。

L 工厂中,现有链路从设备侧到云端再到报表分析,经过多级采集、传输、落库与计算,整体路径冗长且技术栈分散。在典型业务中,现场产生的数据往往需要分钟级甚至更长的等待才能形成可用的分析结果。

某行业领先工厂生产管理数据全链路示意

1.3 分析

工厂的智能化也意味数据分析的复杂化,同时数据能力,在整个生产流程中的作用越来越关键。传统的时序数据库,虽然能在数据采集、实时告警方面很好的满足工厂客户的需求,然而当面临大数据量场景下报表BI,溯源分析等场景则远远不够,不得不引入其他分析型数据库产品。

我们的客户中,F 工厂需要建设总数据量数百 TB 全面的溯源系统,M 工厂需要支持数百个实时看板。随着上层应用不断增加,数据的不断增加,数据库还必须能够保证各类查询即时响应,以保障生产决策能够实时处理,流程查询能够得到及时响应。

同时,由于生产高度自动化,效率极高,排产,调整,告警,追溯等功能的实时性对工厂效率影响越来越大。面对一个不起眼的指标异常,如果能够及时发现并调整就能大大提升产品的良率。数百个工序,数百条产线,多个微小的调整叠加起来,带来的是工厂效益更大提升。

02 为什么现有方案不好用?

"智慧工厂"不是简单的"更新换代",而是生产管理理念进化、设备技术进化、管理软件理论进化、软件产品能力进化共同交织的缓慢过程。在某个领域发生的进步一方面会直接解决一些问题,另一方面也要求其他领域也发生进化,才能最大化技术进步带来的收益。

过去,为了解决设备指标的写入压力,查询效率问题,出现了专用的时序数据库,相较传统的关系型数据库,它进行了专有的优化,不但能够应对时序场景特有的海量数据量、高并发写入压力的挑战,还提供更好用的专用函数,让指标数据的存储、使用更高效便捷,充分满足了企业在生产数字化方面的要求;为了提高数据监控、分析的实时性,Spark、Flink 等流式实时工具也不断进步发展,从实时性角度帮助企业挖掘数据价值;而由于有了更多的数据,上层报表、BI 等分析型应用也越来越多,越来越复杂,同时随着 AI 技术发展,现在更进一步发展出类似预测性维护这类"智能"应用。

然而用户也发现,有不少时候这些技术只是"看起来很美":给设备指标专用的时序库虽然能存数能监控,但是当需要拉取一些稍复杂的报表时,功能、性能都无法满足需求;各类流式处理工具虽然能提供很好的实时性,但增加一项功能就得同时在多个组件上开发,每种组件还涉及不同的开发技术;上层 BI 工具虽然能够提供各种报表,然而当需要综合多项工序、多个系统数据进行分析时,发现数据不在一处,根本做不到。

因此,"智慧工厂"的建设绝不能简单依赖单一方向的技术进步;除了每个具体环节的进步,还需要具备打通全局的能力,才能用"智慧"的方式,让整个工厂系统发生进化。**03时序+分析:YMatrix 如何构建"一套底座"打通全流程?**针对市场现有的一般解决方案的弱点,YMatrix 的突出特点是同时具备时序+分析的关键技术能力。

一方面针对时序场景特有的需求, YMatrix 进行了大量针对性的优化,在写入性能、压缩比、使用便利性方面可以比肩甚至超越时序专用数据库;另一方面,还进一步强化了分析场景的性能、功能,二者融合,使 YMatrix 具备了一套数据库支撑工厂数据采集、加工、服务全流程的能力。

方案1 :更先进的 "时序+分析"一栈式融合架构

在传统的智慧工厂数据方案中,不同产线大多自带数据库,数据通过各种方式同步至数据库,中间还要利用 Spark、Flink 等工具进行加工,不但时效性差,维护困难,而且由于涉及环节多,不可避免的造成了产线数据冗余,整体运行成本更高。

在此套方案中,YMatrix 针对产线、设备规模快速扩张,在"数据入口+写入链路"上做统一设计:

  • **统一数据入口:**产线设备优先通过 MQTT 接入,其他协议由边缘网关转换后统一写入 RocketMQ。这样不管是高速贴装线、组装线还是检测线,不管是国产设备还是进口设备,最终都通过同一套"消息总线"进厂,解决了多协议、多品牌导致的数据接入碎片化问题,同时由于产线数据直接入库,避免一份数据多处存储带来的数据冗余开销。
  • **高并发写入:**下游通过 MatrixGate 将 RocketMQ 中的数据批量、并行写入 YMatrix 数仓。并行消费,多通道批量写入;产线越多,只需要水平扩展写入通道与节点即可。
  • **高效加工与服务:**在质量分析场景中,同一条产线往往涉及多次过站、返修回流与时限判定。为了兼顾实时性和系统压力,YMatrix 对计算链路做了简单分工:绝大部分统计指标和质量判定逻辑,直接在数据库内部完成,利用向量化执行引擎一次性批量计算,把结果表直接提供给看板和追溯查询;只有少量需要多层聚合的指标,才放到 Flink 流处理中按层级加工、预汇总后落入 ADS。

通过这套链路,设备数量、产线数量可以持续增长,写入能力可以线性扩展,既保证了秒级写入和数据不丢,又为后续实时报表、质量追溯和异常监控打好了一个干净、统一、顶得住吞吐量的数据底座。

在 M 手机工厂实践中,该套数据架构系统可实现约 14 万行/秒 的写入能力,将"写入延迟 30 分钟、丢数率>5%"的典型问题收敛到可控范围,让生产状态回到"看得见、看得准、看得快";同时,"设备过站良率"等指标在库内计算约 475ms ,满足分钟级刷新与现场决策需求,并通过 PL/Python 扩展库内算法能力,支撑预测性维护等高级应用的落地。

方案 2:迁移更平滑的流式数仓方案

在该方案中,我们保留了生产端已有的稳定架构(SQLServer),在此基础上,通过定时同步任务同步增量数据至 YMatrix;在此之后,利用 YMatrix 独创 Domino 流计算引擎,直接在数据库内完成数据加工过程;而 YMatrix 强大的分析性能,可以直接将加工结果用于上层应用服务。

目前,该方案正在在 L 工厂落地,通过部分已落地的工作和前期 PoC,方案为客户带来诸多收益:

  • **简化数据流转:**YMatrix 利用该方案将涉及数据库中转、Kafka、Flink、Spark 等多级组件全部整合在 YMatrix 内部,端到端延迟从原先的二十多分钟直接下降到个位数秒,制造过程中的质量信号、设备状态波动与关键过程参数可以近乎实时地呈现,使工厂具备即时分析和快速响应能力。
  • **实时响应:**数据通过 Domino 流计算引擎秒级完成从采集到入库再到 DWS 层的加工,使业务看板能够实时刷新关键生产指标,包括节拍、良率、设备报警、过程参数偏移等。管理人员无需等待批处理出数或云端同步延迟,即可掌握最新生产状态,实现现场决策的即时化。看板由"事后呈现"转变为"过程洞察",让数字能力真正服务于生产过程。
  • **大幅降本:**原有架构依赖多套云上组件与计算引擎,资源分散、运维复杂,导致智能工业部门每年需向智能云部门结算千万元级费用,智能云部门再向云厂商购买软硬件与服务,成本压力持续上升。新方案在工厂侧即可完成全链路处理,极大减少对云侧计算、存储与传输资源的依赖,整体云成本被显著压缩,费用结构更加可控、可预期。

04结语:智能制造的本质,是从"经验驱动"走向"数据驱动"

智能制造的本质不是"用机器替代人",而是通过数据流动效率的提升,推动工厂从"经验驱动"迈向"数据驱动"的决策方式变革。这个过程,对于工厂的 IT 系统建设者也是全新的挑战。

过去,很多工厂借助各种时序数据库产品,已经完成了基本的产线数字化,做到了整个生产过程中数字化,实现了实时监控,实时告警等功能;而"数字工厂"还远远不是"智慧工厂",只有将产线数据和其他数据打通,通过各种分析充分挖掘其背后的业务事实,才能真正实现"智慧"。

这一目标,过去我们通过串联各种组件,分别满足数据采集、加工、服务的不同需求,虽然部分达成了目标,但要真正的构建有"智慧"的工厂,需要的是基础设施的革新。针对这一场景,只有同时具备高性能时序写入与高性能数据分析能力的数据库,才能把"智慧工厂" IT 系统建设从"打补丁"架构改变成为"搞基建"模式,把工厂的智慧化之路走。

你所在的工厂,最卡的一环是哪一个------采数写不进、链路跑不稳、还是看板和追溯查不动?欢迎把你的设备规模、点位频率、看板数量和当前架构留言给我们,可以据此判断:更适合"一栈式时序+分析融合架构",还是"平滑迁移的流式数仓方案",以及从哪一步改造最能最快见效。

相关推荐
熊文豪2 小时前
电科金仓数据库KingbaseES V9R2C13元数据处理详解
数据库·金仓数据库·电科金仓·kes
小画家~2 小时前
第四十三:redis 查找所有KEY应用方法
数据库·redis·bootstrap
攻心的子乐2 小时前
redis 使用Pipelined 管道命令批量操作 减少网络操作次数
数据库·redis·缓存
QT 小鲜肉2 小时前
【Linux命令大全】001.文件管理之slocate命令(实操篇)
linux·运维·服务器·数据库·笔记
zfj3213 小时前
Linux 系统 I/O 监控命令大全
linux·服务器·数据库·io·监控
凯子坚持 c3 小时前
Qt常用控件指南(1)
开发语言·数据库·qt
Evand J3 小时前
【信号处理MATLAB例程】小波变换执行边缘检测、突变点识别和去噪功能。附代码下载链接
数据库·matlab·信号处理
MoonBit月兔3 小时前
用 MoonBit 打造的 Luna UI:日本开发者 mizchi 的 Web Components 实践
前端·数据库·mysql·ui·缓存·wasm·moonbit
天骄t3 小时前
HTML入门:从基础结构到表单实战
linux·数据库