先说一个结论在智慧工厂里堆一套庞大的中心数仓真正让人头疼的往往不是“存不下”而是“想查一个数要等半天”。设备点位从几千涨到几十万之后一条告警链路、一张实时看板、一次分钟级的边缘统计全被一个慢查询拖垮。我们后来把数仓拆成两层——边缘数仓负责“即时响应”中心数仓负责“长期洞察”用一套时序采集与分析协同机制把两边的数据串起来才算真正跑顺。这篇文章就把这段实践完整拆开讲为什么拆、边缘层怎么建、中心层怎么建、两层怎么协同以及我们踩过的那些真坑。1. 为什么我从“一套大数仓”改成了“边缘中心”两级架构1.1 从一次产线事故说起去年年中我们工厂做了一次设备改造产线上新增了一批带高速采集的传感器点位规模从原来的几千个一下冲到接近五十万采集频率也从 5 秒一档提到了 1 秒一档。当时我还没意识到问题的严重性觉得“数仓嘛无非就是扩容”结果上线的第三天就出事了。产线操作员反馈设备状态看板上的数据滞后超过两分钟。后台一查是边缘网关把数据打到中心 Kafka中心数仓在凌晨批量计算时积压了当天的明细结果实时统计跑不出来。更要命的是现场一名工艺工程师想查某台设备过去一个小时的温度曲线用来判断当天的异常根因前端页面直接超时。说白了不是数据丢了是“一套中心数仓包打天下”的模式在时序数据膨胀之后彻底扛不住了。那次事故之后我做了个简单的容量测算。50 万个点位、1 秒 1 条一天就是 4320 亿条记录哪怕每条只占 50 字节单日原始数据就有 2TB 左右一年就是七八百 TB。把这种量级的明细数据全部实时灌进中心数仓做查询存储成本和查询延迟都不可接受。更不合理的是产线上一半以上的监控逻辑其实只关心最近几分钟到几小时的数据压根不需要跨天分析。1.2 时延、成本与数据特征的拉扯想明白之后我意识到问题出在“用一套数据系统同时满足两种完全不同的需求”。我把智慧工厂里的数据需求粗分成两类。一类是“即时响应型”比如设备突发停机、温度超限、振动特征突变。这类需求对时延极其敏感理想状态是几百毫秒到秒级出结果决策逻辑简单直接主要看单个设备或单个点位的当前状态。另一类是“长期洞察型”比如月度 OEE 趋势、某批次产品的工艺参数和质量指标关联、跨产线横向对比。这类需求允许分钟级甚至小时级的延迟但数据维度多、关联复杂需要把设备数据、工单、质量、能耗等揉在一起分析。两类需求对数据系统的要求是矛盾的。即时响应型需要数据靠近现场、查询路径短、存储粒度可以粗一点长期洞察型需要数据集中、schema 宽、历史留存久。硬塞在同一套中心数仓里结果就是实时任务和批量任务互相抢资源谁都跑不快。成本曲线也在逼我们做拆分。中心侧如果要保留全量秒级明细就得维持高配置的计算和存储集群但绝大部分历史明细数据实际访问频率极低。比较合理的做法是边缘侧保留短周期的秒级原始数据中心侧保留降采样后的聚合数据和较长周期的特征数据把原始明细压缩到几天或几周的窗口。1.3 两层数仓的定位切分最终我们确定的分工是这样的。边缘数仓定位在厂区或车间内部承接各类工控协议Modbus TCP、OPC UA、S7 等上报的时序数据负责秒级和分钟级的计算、告警、短时查询。它服务的对象是产线班组长、设备维修人员和现场工艺工程师。中心数仓定位在企业级负责跨车间、跨班次、跨产线的长周期分析对接 MES、ERP、QMS 等业务系统服务对象是生产计划、质量分析、工艺优化和工厂管理层。数据流向是单向闭环边缘层采集时序数据后先落地到本地时序库一部分直接用于边缘计算另一部分按策略同步到中心数仓中心数仓做更重的清洗、关联和建模再通过数据服务把分析结果反哺到报表平台和 BI。边缘和中心不是主从复制的关系而是各有独立计算能力又互相配合的两级体系。2. 边缘数仓怎么实现“即时响应”2.1 时序数据库选型它才是边缘的主角想实现即时响应核心是把时序数据落到对的存储引擎上。关系型数据库和普通 Hadoop 数仓在这个场景下基本不适用因为时序数据的写入模式是“以当前时间为轴持续追加”查询模式则高度集中在“某个设备某个时间段内的数值序列”。我们当时在 TDengine、InfluxDB 和 IoTDB 之间做对比。InfluxDB 生态成熟、文档多但单机写入吞吐受磁盘和内存配置影响明显在几十万点位场景下要精心设计分片IoTDB 对工业场景支持不错支持对齐时间序列和复杂路径查询适合需要精细建模的场景TDengine 的优势是“超级表”模型和内置的降采样、连续查询功能对点位这类“设备 多测点”的结构非常友好集群运维也简单。我们的选择是 TDengine核心原因是它的存储模型和我们的数据形态匹配。在 TDengine 里每台设备建一张子表测点作为子表的列所有同类型设备归到一张超级表下。写入时按设备维度落盘查询时只要指明时间范围和设备标签就能迅速定位到对应分片不用做全局扫描。选型时我不建议只盯基准测试的数字还得结合实际写入模型。我们在现场环境测了五千点位的持续写入和并发查询重点看两个指标一是在磁盘 I/O 波动时写入是否积压二是多条件聚合查询的 P99 时延。实测下来TDengine 在百路并发写和二十路聚合查询混跑时P99 能稳定在 300 毫秒以内符合即时响应的要求。2.2 点位建模别把时序点存成关系表这是很容易翻车的一步。很多团队第一次搭时序存储下意识地模仿关系库建一张宽表每行一条记录字段是“时间戳、设备 ID、测点 A、测点 B、测点 C”结果数据量大之后存储膨胀得厉害查询也越来越慢。我们在边缘侧采用“设备根 测点列”的模式每台物理设备对应一张子表字段固定为时间戳和需要关注的测点值设备自身的属性区域、产线、型号放在标签里。这样做的直接好处是同一设备的测点天然存储在一起按设备查询时不需要大量 join另一个好处是写入时按设备批量提交减少网络往返。点位还要做分级。有些点位的值高频变化比如振动加速度、电机电流必须 1 秒级采集有些点位变化缓慢比如环境温度、液压油位5 秒甚至 30 秒采集就够了。我们把点位分成三类分别配置采集频率和保留周期点位类型示例采集频率边缘保留周期中心保留策略高频波动点振动、电流、压力1 秒7 天原始10 秒降采样留 12 个月中频状态点温度、转速、流量3-5 秒30 天原始1 分钟降采样留 24 个月低频累积点能耗、产量计数30 秒90 天原始5 分钟聚合长期保留点位分级表在建库之前就要定好因为后续的聚合任务、上传策略、数据生命周期管理全都依赖这个分级。别想着“先全采下来再说”点位膨胀带来的成本是成倍增长的。2.3 聚合、告警与短窗口留存边缘层不负责长期分析但必须处理三类任务。第一类是降采样聚合。TDengine 的连续查询可以直接在边缘库上定义滚动窗口聚合把 1 秒原始数据压成 10 秒或 1 分钟的均值、最大值、最小值。聚合结果单独建表存储供看板查询。这样即使原始数据因老化被清理短期报表能力也不会受影响。第二类是阈值告警和异常判定。我们最初用简单的规则引擎每个点位配置上限、下限和变化率超过阈值就推 Kafka 告警。后来发现单纯的阈值在工况切换时误报太多于是叠加了滑动窗口统计取最近 30 个点的均值和标准差如果当前值偏离均值超过 4 倍标准差才判定为异常。规则虽然简单但在边缘侧非常好使而且计算成本几乎可以忽略。第三类是短窗口留存也就是给维修人员留一个“回溯窗口”。设备出故障后维修人员第一件事就是翻故障前几分钟的原始数据。边缘库只要保留最近 7-30 天的秒级明细就能覆盖绝大多数故障排查场景完全不需要去中心库查。边缘层还有一个容易被忽略的设计写入协议要精简。我们统一使用 MQTT 上报 JSON 报文边缘网关做解析后批量写入时序库每条报文包含网关 ID、设备 ID、点位数据组、采集时间。批量大小控制在 500-1000 条一次能显著降低写入开销。3. 中心数仓怎么支撑“长期洞察”3.1 中心侧的数据分层与存储中心数仓侧的数据架构我们采用了“湖仓一体分层”的思路。对象存储保存全量降落数据数仓引擎负责结构化建模按 ODS-DWD-DWS-ADS 四层组织。ODS 层是“原始落地层”接收边缘侧上传的时序聚合数据和业务系统同步的数据。这里我特别建议把时序聚合文件和业务系统数据分开放在不同的目录前缀下避免混在一起导致后续处理任务互相阻塞。比如时序数据按“产线 / 设备 / 日期”分区业务数据按“业务域 / 日期”分区。DWD 层做清洗和标准化。时序数据的标准化主要是统一时间精度、处理时区偏移、给缺失值打标记。工业现场经常出现设备停机不采集导致的“无数据窗口”这一层要把这些窗口显式识别出来不能直接当成平均值参与计算。DWS 层是核心。这里把时序数据进一步转成业务口径的宽表比如“设备小时统计表”“产线班次日报表”字段包括运行时长、平均负载、温度均值、有效产出等。这张宽表会与 MES 里的产量数据做关联供上层直接查询。ADS 层面向具体应用可以是 BI 数据集也可以是算法特征宽表。这一层不强调实时而是强调口径统一和查询性能。3.2 从“时序明细”到“特征化表”中心数仓和边缘数仓最本质的区别是中心要把时序数据变成“可用于分析和建模的特征”而不是继续保留“某年某月某秒某个点位是多少”的原始形态。我们做了一个“特征化加工层”把上传的聚合时序数据进一步提炼成业务特征。比如某台注塑机的温度曲线边缘上传的是每 10 秒的均值。中心建模时我们会在这个基础上算出一个班次内的温度均值、方差、最大波动幅度温度曲线与注塑周期内设定曲线的均方根误差升温阶段的斜率、降温阶段的斜率温度在设定范围外的累计时长和占比。这些特征才会真正被后续的质量分析使用。早期我们尝试直接在 BI 上拖拽原始时序数据做分析效果很差因为同一台设备的原始曲线在不同班次之间交错在一起根本无法直接对比。特征化之后每个班次变成一行记录质量人员可以做“班次之间的横向对比”和“参数与不良率的相关分析”。特征化表的设计建议先跟工艺工程师和数据分析师对齐不要拍脑袋定义。我们第一版的特征表字段太多很多特征从来没人用过后来砍到只保留与质量、能耗、设备健康度直接相关的指标表结构瘦身了三分之一查询效率明显提升。3.3 跨产线、跨班次的横向对比才是中心的优势边缘层盯的是“这条线这台设备现在有没有异常”中心层盯的是“这台设备跟同型号的其他设备比是不是有隐性劣化”。这里举一个实际案例。我们在某条产线的四台注塑机上装了同型传感器边缘侧每台都做了独立告警阈值相同四台设备看起来都很正常。但中心数仓把四台设备的温度均值按班次做对比发现 3 号机的平均温度比其他三台高 3 摄氏度并且差异随时间缓慢扩大。单看边缘告警3 号机没有任何一次触发阈值但放到产线整体视角它就非常显眼。后来停机检查发现是冷却水回路堵塞如果不做跨设备对比这个问题可能要被掩盖一两周。这就是“长期洞察”的价值。中心数仓要做的事是把单条时序曲线放到设备群、时间段、工艺条件的多维坐标系里去做比较找到边缘层看不到的“相对异常”。所以中心层的建模不要只盯着设备维度还要把批次号、工单号、班次、工艺配方版本作为关联键跟 MES 和 QMS 的数据打通。4. 两级协同的关键机制同步、任务分配与统一查询4.1 数据上行与同步策略边缘数仓和中心数仓之间是单向的数据上行但这个“上行”不能做成无脑全量复制。我们设计了分级上传策略。按点位分级高频波动点上传播放的是 10 秒降采样结果中频状态点上传播放的是 1 分钟结果低频累积点则上传 5 分钟聚合。原始秒级数据只在特殊场景下按需调取例如质量追溯需要用到完整的信号片段时。上传时机也要错开。边缘网关会把待上传的数据先落到本地队列文件按“每小时整点批量上传”的方式发送避开交接班前后的业务高峰。如果中心侧的接收服务过载会返回退避指令边缘侧自动降速而不是重试风暴。我们的队列采用本地磁盘缓存加断点续传网络抖动不会丢数据。还有一个重点是数据版本管理。边缘层的聚合计算偶尔会因为补数据、修正点位漂移而产生更新如果直接覆盖中心数仓的数据会导致下游报表产生历史跳变。我们给每次上传的数据附一个“批次版本号”中心侧按“增量追加 最新版本覆盖”的方式处理分析任务只消费“最终一致”的快照视图。4.2 计算任务的分工边界两级协同最容易犯的错是把边缘当成了“薄采集器”什么计算都往中心塞。我们花了几周时间把既有的计算任务全部梳理了一遍按“时间敏感度”和“数据范围”重新分配。留在边缘层的任务有三个特征只依赖本设备或本网关的数据需要秒级到分钟级出结果需要高频访问原始/近原始数据。典型的包括设备状态实时看板、基于滑动窗口的异常检测、短时故障回放。放到中心层的任务也有三个特征依赖多个设备、多个系统的数据允许分钟级以上的延迟需要长周期的历史数据。典型的包括 OEE 趋势分析、质量与工艺参数相关性分析、设备群劣化对比、能耗月报。边界不是黑白的有些任务在两个方向都可以做。我们的原则是如果任务的数据源主要落在边缘且结果需要回传现场操作端就留在边缘如果任务的数据源跨越多个边缘节点或需要跟业务系统 join就放中心。宁可让中心多算也不要在边缘做跨节点聚合边缘节点之间的网络联调复杂度太高。4.3 统一查询层屏蔽物理分布对上层应用来说它不应该关心“这个查询是打到边缘还是打到中心”。我们开发了一个统一的数据服务 API把两级数仓封装到同一个查询接口后面。接口的设计逻辑很简单请求先带一个“时效性”参数实时类查询默认路由到边缘层分析类查询默认路由到中心层如果边缘层没有该点位的数据比如已经超过保留期自动 fallback 到中心层。为了控制查询成本我们在接口层强制做了“时间范围限制”和“降采样级别限制”。比如查询范围超过 7 天的时序曲线服务端会自动把粒度提升到分钟级避免返回数百万行数据压垮前端图表。这个限制一开始被业务部门吐槽后来大家发现看月趋势本来也不需要秒级粒度。统一查询层还承担数据权限的职责。边缘层数据权限按工区隔离中心层按业务域隔离。运维人员只能查自己负责工区的数据质检人员只能查跟质量相关的表。这一步如果不在 API 层做死后期合规审计会很麻烦。5. 协同落地中踩过的坑与排查复盘5.1 聚合口径不一致边缘与中心对不上账上线后第一周工艺工程师就发现一个诡异的事边缘层看板显示某台设备当天温度均值是 81.2 度中心数仓报表里却是 79.6 度。两边差了 1.6 度虽然不多但没人能解释。排查下来根因是两层用了不同的聚合算法。边缘层连续查询里用的是“按窗口内非空值个数做平均”剔除了一些由于网关瞬断产生的空值中心数仓在清洗时则把空值窗口先填充成了上一个有效值再参与平均。两边的“空值处理策略”不同聚合结果自然对不上。修复方案是统一空值语义凡是边缘上传的聚合序列空值窗口只允许用固定标记位表示不允许在源头填充中心侧只有在进入特征化层时才按业务规则决定是否填充且填充逻辑写入数据血缘文档。从那之后两边口径终于能对上。5.2 时钟漂移造成的时序乱序边缘网关分布在车间不同位置部分网关的本地时钟会漂移。设备上报的采集时间戳来自传感器或 PLC而网关的上报时间戳来自系统时钟两者一旦不一致时序库里就会出现“时间往回跳”的数据点。这个问题在单机时几乎不可见但在多网关并发查询时非常致命。我们有一次做设备劣化分析发现某台设备的振动均值曲线出现了周期性的“尖刺回退”数据点的时间戳比前一条还早几百毫秒导致降采样窗口错位。解决办法分两层。第一层是边缘网关统一用 NTP 同步并且在采集链路里约定“传感器时间优先、网关接收时间为辅”每条记录同时携带采集时刻和接收时刻入库时按采集时刻排序。第二层是中心侧在 ODS 层增加乱序检测任务把同设备同点位中时间戳差值超过阈值的记录标记出来不参与后续聚合待修正后再重新进入。5.3 上传任务占满带宽引发产线卡顿这个坑相当隐蔽。我们把上传任务统一安排在整点批量执行后某段时间频繁出现产线 HMI 画面卡顿监控网络发现整点前后网关上传流量飙升把车间交换机的上行端口带宽快打满了。原因是几十个边缘网关在同一时刻并发上传且上传内容包含了一些未经降采样的明细点。细节很蠢因为某些点位虽然被标记为“低频”但我们的上传脚本默认取的是“该点位最近一小时所有原始值”而不是聚合值。修复很简单上传脚本严格按点位分级取数上传时段改为随机化的“整点后 5-15 分钟”窗口带宽占用超过阈值时自动降级先传核心点位聚合数据非核心点位顺延。后来再也没有出现过类似卡顿。5.4 中心回溯重算覆盖了边缘修正结果这一版是最痛的。边缘层有一次因为传感器漂移运维人员手工修正了一批点位值修正后的上传数据带了新的版本号。但中心数仓夜里跑了一个周度回溯任务这个任务读的是旧版本快照重算后又把修正前的数据写回了 DWD 层等于把运维白天的修正全部覆盖了。问题出在“回溯任务没有感知数据版本变更”。我们当时的处理是在数据服务层增加“基于目标点位 时间区间 版本号”的锁机制回溯任务启动前必须先检测目标分区的最新版本号如果与任务计划版本不一致直接中止并提示人工介入。这个机制之后中心侧的回溯重算全部要显式声明“基于哪一版数据”不允许多个任务对同一分区随意覆盖。数据血缘也因此清晰了很多。5.5 一些设计与运维层面的经验沉淀走完这一轮踩坑我的体会是边缘中心和中心数仓的协同本质上是“数据命名的统一”“计算口径的统一”“版本语义的统一”这三个统一的工程化。技术选型反而是相对容易的部分难的是把这些规则贯彻到每条链路里。举个例子点位命名。早期不同产线对同一个测点的命名不一样A 线叫 “Temp1”B 线叫 “zone_temp”导致中心侧关联分析时不得不用手工映射表维护维护成本居高不下。我们后来统一了全厂的点位编码规则格式为“产线编码-设备编码-测点类型-序号”从源头避免命名混乱。这个动作对后续所有分析和运维都有长远好处。运维层面还有一个容易被低估的项边缘节点的磁盘水位监控。边缘时序库一旦写满会导致写入失败甚至进程崩溃而且这种故障通常发生在半夜。我们加了每 5 分钟扫描一次磁盘水位、超过 70% 自动触发历史数据压缩的策略同时给核心点位单独划保留空间避免被低频点位的长期数据挤占。如果你也要搭这套两级架构我的建议是先把点位分级和口径语义定下来再选时序引擎最后再谈数据同步和查询接口。顺序反了后面返工的工程量会非常可观。这套方案我们已经跑了三个多月边缘层的即时查询 P99 在 500 毫秒以内中心层常规报表的日活查询没再出现过超时告警总算从当初那场事故里彻底走出来了。