制造公司Bright Machines从气隙工厂推数据出来：边缘捕获与联邦查询替代九服务管道

客户走进Bright Machines的工厂，站在装配看板前看产线运行，然后要求一份数据：各工位良率、节拍趋势、按原因分的停机时间、批次追溯。Bright Machines内部有这些数据，操作团队每天都在看。但客户无法通过网络直接访问——工厂的安全设计是气隙的：没有入站访问，出站路径极少，对风险零容忍。过去唯一的共享方式是在本地重跑报表然后用邮件发送，每次新报表需要数据工程团队通过多个ETL作业重塑数据，耗时数小时到数天。

Bright Machines为制造业客户构建软件定义的自动化产线，运行在客户工厂内部。每条产线跑着一整套本地服务——自研MES、客户MES集成、操作屏、机器人编排器和装配看板——全部持久化到工厂本地PostgreSQL集群。数据驱动良率、财务、运营、质量、供应商组件质量、NCR追踪、批次追溯、OEE以及每班的停机与节拍分析。

团队最初尝试在云端重建每个工厂数据库的副本，基于应用事件驱动，跨越九个松耦合服务：消息代理、自定义搬运器、队列、对象存储、若干无服务器函数、云关系数据库、调度器、ETL管道和一个基础RBAC的开源BI工具。这套架构在工厂内运行正常，但出了工厂门全是问题：模式频繁变更时管道静默丢弃数据；死信队列难以监控，丢失或重复的事件无人察觉；数据落桶后无法确认准确性和来源；缺乏可演示的治理和角色化访问控制。

新架构的需求约束按优先级排列：访问控制必须匹配工厂内已有的角色限制；必须有一条可向任何安全团队解释的单一可审计出站路径；新鲜度以分钟计；边缘使用开放格式。威胁模型的核心规则是：数据可以被推出去，但外部不能伸进来。

这意味着两个显而易见的拉取式方案——Lakeflow Connect直接从PostgreSQL摄取，以及PostgreSQL导出被Auto Loader拾取——都被排除了。拉取式摄取需要一条从云到工厂数据库的网络路径，并且需要在数据所在账户之外的环境中运行摄取计算。问题变成了：如何在保持所有接触原始工厂数据的组件都在自有环境内的前提下，得到同样的治理结果？

答案是翻转方向：不在云端拉，而是在边缘推。Bright Machines的架构分五步。第一步，Debezium Server在工厂边缘尾随PostgreSQL复制槽，将变更写入本地对象存储上的追加型Apache Iceberg变更日志。如果广域网中断，积压变成工厂本地的对象文件，而不是生产数据库上堆积的预写日志。第二步，一个边缘组件将每个对象复制到该站点云账户中的一个存储桶——这是工厂唯一的出站数据路径，其凭证只能写入这一个桶。跨账户复制将对象传到分析账户。第三步，Iceberg表注册在AWS Glue中，Unity Catalog将Glue联邦为只读目录，使工厂PostgreSQL数据库中超过一百张表可在Databricks中直接查询而无需复制。第四步，Databricks SQL中用Bronze视图将变更日志折叠为当前状态，一个Lakeflow作业每十分钟重建Silver模型。第五步，AI/BI看板读取Silver层数据并提供角色化权限，OpenSharing将同一份治理数据零拷贝分享给客户。

一个关键设计决策是为什么在AWS Glue中注册Iceberg表，而不是让Databricks直接指向存储桶。对象存储上的变更日志是一串不断新增的元数据文件。一个小函数只在新的元数据文件完全复制完成后才推进Glue中该表的指针，而且只能向前推进。Glue持有指针，Unity Catalog持有权限，Databricks只读取已验证的版本。这给了Bright Machines对每张表何时向前移动的精确控制——一个自己拥有的目录跳跃，加上指针上的守卫。

另一个容易被忽视的运维问题：如何区分空闲产线和故障管道？产线换班时停止运行，没有新行到达，这看起来和管道断裂完全一样。行数无法区分这两种极端。Debezium每五分钟更新每个源数据库中的一行心跳表，无论产线是否在运行。这个心跳更新走与生产数据相同的路径。Lakeflow作业的第一个任务检查心跳，如果任何心跳超过三十分钟未更新，任务失败，整个作业变红。看板继续显示最后一次好数据，而不是把过期数据呈现为当前数据。