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

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

• 问题：客户想要工厂数据，而唯一的共享方式是在本地重新运行报告并通过电子邮件发送。
• 解决方案：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 管道，以及一个支持非常基础 RBAC 的流行开源 BI 工具。

该管道因以下原因失败：

• Schema Evolution（模式演进）。模式经常变化，除非每次本地仪表盘或模式发生变化时都更新 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 变更日志写入本地对象存储。如果广域网中断，积压的数据会变成本地对象，而不是在 production 数据库上堆积的预写日志。

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

将其联邦到 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 模型和仪表盘每十分钟刷新一次。需要实时视图的操作员继续使用本地装配仪表盘。

客户如何访问数据？有两种方式：与 Bright Machine 的 SSO 联合集成的基于角色的权限的 AI/BI 仪表盘，以及提供 OpenSharing 访问的额外能力，后者将零副本的受治理 silver 表发布给拥有 Databricks 账户的客户。

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

这个设计是专门基于 AWS 构建的，它在 Azure 或 Google Cloud 上能行得通吗？与云相关的部分是边缘同步目标、跨账户复制和目录跳转。Databricks 侧的一切在任何云上都是相同的，因此迁移它只是更改少量资源，而不是重建。

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

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