Bright Machines 如何在不开放工厂入站访问的情况下提供实时工厂数据看板

Databricks：Blog·2026-11-12 00:10· 51 分钟前AI 评分44

气隙隔离，而非数据黑箱：Bright Machines 如何在不开放工厂的情况下为客户提供实时工厂仪表盘

AI 导读

Bright Machines 用 Debezium 在工厂边缘捕获 PostgreSQL 变更、写成 Apache Iceberg，经单一可审计出站路径推送，再由 Databricks 通过 Unity Catalog federation 原地读取，全程不开放任何入站端口。

正文 · 原文

Bright Machines 为客户提供实时、受治理的工厂数据仪表盘，同时不向其气隙隔离的工厂开放任何入站访问。它在工厂边缘用 Debezium 捕获 PostgreSQL 变更，将其写成 Apache Iceberg，通过单一可审计的出站路径发送出去，并在 Databricks 中通过 Unity Catalog federation 原地读取。首个客户可见的仪表盘在项目启动约两个月后上线。

• 问题：客户想要工厂数据，而唯一的共享方式是在本地重新运行报告并通过电子邮件发送。
• 解决方案：Debezium 变更数据捕获、Apache Iceberg、AWS Glue、Unity Catalog、Databricks SQL、AI/BI Dashboards 和 OpenSharing。
• 结果：九个松耦合服务被一个受治理的平台加一条边缘路径取代，且工厂零入站端口。
• 新鲜度：产线上提交的一行数据可在一到两分钟内在 Databricks 中查询，仪表盘每十分钟刷新一次。
• 监控：心跳检查可在三十分钟内检测到管道中断，此前需要数天。

为什么客户看不到自己的工厂数据？

每次客户参观我们的工厂车间，都会发生同样的事。他们会站在装配仪表盘前，看着产线运行，然后索要一份数据副本：各工位良率、周期时间趋势、按原因划分的停机时间、批次谱系。

这些数据我们全都有。我们为自己的运营团队构建了那些仪表盘，它们在车间针对产线数据库运行。客户无法通过互联网直接访问其中任何内容。工厂按设计是气隙隔离的：无入站访问，仅一条严格受控的出站路径，以及限制入站访问的基于角色的访问规则。

每份新报告都需要数据工程通过多个 ETL 作业重塑数据，耗费数小时到数天的工程时间。

Bright Machines 是谁？

Bright Machines 构建软件定义、自动化优先的生产线，运行在客户的工厂内。这些工厂按设计被锁定：无入站访问、最少出站、对风险零容忍。每条产线运行一组本地服务（我们的自研 MES、与客户 MES 的集成、操作员屏幕、机器人工作流编排器和装配仪表盘），它们都持久化到工厂本地集群上的 PostgreSQL。运行这些的软件团队是一个精简团队，端到端管理数据管道以及数据应用软件栈。这些数据驱动各种 KPI 仪表盘、财务报告、运营、质量、供应商组件质量、NCR 跟踪、谱系、OEE 以及每个班次背后的停机和周期时间分析。

旧的工厂数据管道是什么样子，为什么失败？

在我们首次尝试解决这个问题时，我们通过应用程序事件在九个松耦合服务中重建了每个工厂数据库的云副本。在工厂车间，情况看起来不错。车间之外的一切，正是这种复杂架构和管道的问题所在。

这九项服务分别是一个消息代理、一个自定义搬运器、一个队列、对象存储、少量无服务器函数、一个云关系数据库、一个调度器、一条 ETL 管道，以及一个流行的开源 BI 工具（其 RBAC 支持非常基础）。

该管道失败的原因如下：

• 模式演进。模式经常变化，除非每次本地仪表盘或模式发生变化时都更新 ETL 作业，否则管道会静默丢弃已变更的数据。
• 缺少监控。管道出现过故障，而死信队列又难以监控，因此遗漏或重复的事件无人察觉。
• 数据校验。数据一旦落入存储桶，就没人能确信它是否准确、是否来自正确的源。
• 数据治理。对我们共享的视图和数据实施恰当的治理和基于角色的访问控制。

要修复上述所有功能，需要从底层重新架构。

新架构有哪些要求？

除上述原因外，以下约束也塑造了新设计：

安全模型。工厂无入站连接，所有访问均可审计。

可展示的治理。客户能确切看到其角色在车间被允许做什么，并且我们必须能够证明适当的限制已经到位。

分钟级新鲜度。本地仪表盘视图能在几分钟内通过互联网看到相同的数据。

新架构

Bright Machines 为什么选择边缘捕获与联邦，而不是直接摄取？

Bright Machines 选择边缘变更数据捕获与 Unity Catalog 联邦，因为这是唯一一种在应用治理之前，客户和/或 Bright Machines 自有账户之外的任何计算都不会接触工厂数据的方案。

我们的标准按顺序是：与车间已执行的访问控制相匹配、一条可向任何安全团队解释的出站可审计路径、分钟级新鲜度，以及边缘的开放格式。

在编写任何代码之前，我们与 Databricks 解决方案架构师一起梳理了各种选项。两个显而易见的选项是 Lakeflow Connect 直接从 PostgreSQL 摄取，以及由 Auto Loader 拾取 Postgres 导出。两者都能更快搭建起来。我们的威胁模型遵循这样的规则：数据可以推出去，但外部任何东西都不能进来。基于拉取的摄取模式需要一条从云到工厂数据库的网络路径，并且在数据所在账户之外的环境中运行摄取。因此问题变成了：我们如何在保持所有接触原始工厂数据的组件都位于我们自有环境内的同时，获得同样受治理的结果？

答案是翻转方向。在边缘捕获变更，将其落地为开放格式，通过一条可审计路径推送出去，并让 Databricks 就地读取。

我们在一条复制的产线上用两名工程师花了大约六周时间进行了验证，该产线类似于生产现场。标准有两部分。第一，产线上提交的一行数据必须能在五分钟内被查询到，且不开放任何入站端口。第二，客户主体必须只能看到其角色所允许的表和仪表盘，别无其他。

决定性因素是，Databricks 已经实施了与我们一致的安全模型：Unity Catalog 负责谁能看到什么，OpenSharing 负责在不复制的情况下发布受治理的表。起初，我们担心联邦表上的治理对于审计来说不够严格。它确实严格，而在切换期间让我们遇到麻烦的严格性，正是我们现在所依赖的严格性。

数据如何从气隙工厂进入 Databricks？

数据通过一条出站路径、分五步离开工厂，Databricks 就地读取，无需复制作业。操作员保留本地装配仪表板，因为他们需要实时数据。Databricks 云为客户和内部团队提供服务。

使用 Debezium 在边缘捕获。Debezium Server 跟踪 PostgreSQL 复制槽，并将仅追加的 Apache Iceberg 变更日志写入本地对象存储。如果广域网中断，积压会变成落地的对象，而不是在生产数据库上堆积的预写日志。

通过一条路径发送出去。单个边缘组件将每个对象复制到站点云账户中的存储桶。这是工厂唯一的出站数据路径，其凭证只能写入那一个存储桶，不能写入其他任何地方。跨账户复制将对象传送到分析账户。

将其联邦到 Unity Catalog。Iceberg 表注册在 AWS Glue 中，Unity Catalog 将 Glue 联邦为只读目录。这使得工厂 PostgreSQL 数据库中超过一百张表可以在 Databricks 中查询，而无需复制。

在 Databricks SQL 中建模。Bronze 视图将变更日志折叠为当前状态。Lakeflow 作业每十分钟重建 silver 模型，全部使用 SQL，并通过 Databricks Asset Bundles 从 Git 部署。

通过仪表板和 OpenSharing 提供服务。多个 AI/BI 仪表板基于角色权限从 silver 层读取处理后的数据。这使得外部客户和内部团队都能看到相同的数字。OpenSharing 允许将同一份数据安全地共享给我们的客户。

为什么在 AWS Glue 中注册 Iceberg 表，而不是让 Databricks 直接指向存储桶？

在 AWS Glue 中注册表使 Bright Machines 能够精确控制每张表何时向前推进。对象存储上的变更日志是一系列新的元数据文件。一个小函数仅在新元数据文件完全复制后，才在 Glue 中推进每张表的指针，并且只向前推进。Glue 持有指针，Unity Catalog 持有权限，Databricks 只读取我们已验证的版本。

如何区分空闲的生产线和损坏的管道？

使用心跳。当生产线因换班而停止时，没有新行到达，这看起来与损坏的管道完全相同。行数无法区分这两个极端。

Debezium 每五分钟更新每个源数据库中的单行心跳表，无论生产线是否运行。该更新与生产数据走同一条路径。Lakeflow 作业的第一个任务检查心跳，如果任何心跳超过三十分钟，任务就会失败，整个作业变红。仪表板继续显示最后的好数据，而不是将过时数据呈现为当前数据。

迁移是如何分阶段进行的，我们学到了什么？

我们分四个阶段进行：1.) 在 PoC 生产线上试点，2.) 让价值最高的生产线投入运行，3.) 与旧的快照路径并行运行以检查逐行一致性，4.) 硬切换面向客户的仪表板。

让我们意外的地方。规模出现在错误的维度上。我们每天迁移几百 GB 数据，但都是数十万个小对象，所以每个设计决策最终都围绕对象速率而非字节数来定。

我们会改变的做法。第一天就构建对账流程。由创建事件驱动的同步永远不会回头处理它错过的对象，下游也无人察觉，直到某次查询触及它。

Bright Machines 看到了什么结果？

这些客户拜访的重点变了。没有人再要一份仪表盘的副本，因为他们已经有了，就在他们可用的角色下。客户分析师在办公桌前打开质量仪表盘，看到的数字与产线主管在现场看到的相同，延迟约十分钟。我们从不运行报表。第一个客户可见的仪表盘在上线启动约两个月后上线。

其他团队应该从中学到什么？

给任何从封闭站点共享数据的人的五条经验：

1. 从你已有的安全模型出发。我们的数据治理要求定义了角色和限制。我们选择的平台精确执行了这些要求，而不是近似执行。
2. 先设计好唯一出口，并在其后缓冲。单一可审计的出口让之后与安全团队的每次沟通都变得可控。在边缘缓冲意味着 WAN 抖动永远不会变成生产数据库事故。
3. 掌控表何时向前推进。你自己拥有的目录跳转，加上指针上的守卫，意味着湖仓只会看到你验证过的版本。
4. 数据只构建一次，其余交给权限。为每份报表维护客户版本和运营版本才是耗费大量时间的事。
5. 用心跳而非行数来断言新鲜度。没有新行意味着产线空闲。没有新心跳意味着管道故障。

Bright Machines 的下一步是什么？

既然数据已受治理且可访问，下一步是通过 Genie 的自然语言分析、面向运营的自定义 AI 代理，以及将工厂数据转化为前瞻性决策的预测分析，让 AI 功能更易使用这些数据。

为运营分析和调查构建自定义 AI 代理。在这些产线上工作的人——操作员、质量工程师、维护技师——拥有领域专业知识，但不是 SQL 用户。自定义 AI 代理（通过 Databricks Apps 或 Agent Bricks）可以让产线主管询问“为什么 4 号工位这个班次停机时间更长？”Bright Machines 提供的知识文档连同运营数据，可以得到基于同一受治理 silver 数据的答案。这是“改善底线”的玩法——缩短工厂现场从提问到行动的时间。

常见问题部分

Databricks 能用于气隙隔离的工厂吗？可以。Bright Machines 对工厂的数据保持零入站端口开放。变更在工厂内部捕获，并通过一条可审计的出站路径推送出去，Databricks 通过 Unity Catalog 联邦就地读取生成的 Apache Iceberg 表。

Databricks 中的工厂数据有多新鲜？在产线上提交的一行数据在稳态下可在一到两分钟内于 Databricks 中查询。Silver 模型和仪表盘每十分钟刷新一次。需要实时视图的操作员继续使用本地装配仪表盘。

客户如何访问数据？有两种方式：一是带有基于角色权限的 AI/BI 仪表板，并与 Bright Machine 的 SSO Federation 集成；二是提供 OpenSharing 访问的额外能力，可将零拷贝的受治理 silver 表发布给拥有 Databricks 账户的客户。

是什么取代了旧的九服务流水线？一个受治理的平台 Databricks，加上一条由 Debezium、本地对象存储和一个同步组件组成的单一边缘路径。Bronze 视图、silver 模型、作业、仪表板和共享全部从一个 Databricks Asset Bundle 部署。

此设计专门构建在 AWS 上，该设计能在 Azure 或 Google Cloud 上运行吗？与云相关的部分是边缘同步目标、跨账户复制和目录跳转。Databricks 侧的所有内容在任何云上都是相同的，因此迁移它只需更改少量资源，而无需重建。

花了多长时间？概念验证由两名工程师耗时约六周完成。首个客户可见的仪表板在上线启动后约两个月上线。

想要在不开放入站访问的情况下共享来自锁定站点的受治理数据？了解 Unity Catalog 如何联合来自 AWS Glue 的 Apache Iceberg 表，或与您的 Databricks 客户团队讨论您的架构。

来源：Databricks：Blog · databricks.com