气隙隔离不阻数据：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 工具。

该管道因以下原因失败：

• 模式演变。模式经常变化，除非每次本地仪表板或模式变化时都更新 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.) 对客户仪表板进行硬切换。

让我们意外的地方。规模出现在错误的维度上。我们每天传输几百吉字节，但它们是数十万个小对象，因此每个设计决策最终都围绕对象速率而非字节数来做出。

我们会改变的做法。从第一天起就构建对账环节。由创建事件驱动的同步永远不会回头去找它遗漏的对象，下游也不会有任何东西察觉，直到某个查询触及它。

Bright Machines 看到了什么结果？

那些客户拜访的重点变了。没有人再索要仪表板的副本，因为他们已经拥有了，就在其可用的角色下。一位客户分析师从自己的办公桌打开质量仪表板，看到的数字与产线负责人在车间看到的相同，时间差约为事情发生后十分钟。我们从不运行报告。第一个客户可见的仪表板在项目启动后约两个月上线。

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

对于任何要从封闭站点共享数据的人，有五条经验：

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

Bright Machines 的下一步是什么？

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

用于运营分析和调查的自定义 AI 智能体。在这些产线上工作的人员——操作员、质量工程师、维护技师——拥有领域专业知识，但不是 SQL 用户。自定义 AI 智能体（通过 Databricks Apps 或 Agent Bricks）可以让产线负责人提问：“为什么 4 号工位本班次的停机时间更高？”Bright Machines 提供的知识文档连同运营数据，可以基于同一套受治理的 silver 数据给出有依据的答案。这就是“改善利润”的策略——缩短工厂车间从提问到行动的时间。

常见问题解答（FAQ）

问：Databricks 能否用于气隙隔离的工厂？

可以。Bright Machines 不为数据保留任何向工厂开放的入站端口。变更在工厂内部捕获，并通过一条可审计的出站路径推送出去，Databricks 通过 Unity Catalog 联合就地读取生成的 Apache Iceberg 表。

问：Databricks 中的工厂数据有多新？

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

问：客户如何访问数据？

有两种方式：具有基于角色权限的 AI/BI 仪表板，并与 Bright Machine 的 SSO 联合集成；以及提供 OpenSharing 访问的额外能力，可将受治理的 silver 表以零拷贝方式发布给拥有 Databricks 账户的客户。

问：什么取代了旧的九服务流水线？

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

问：此设计专门构建在 AWS 上，该设计是否适用于 Azure 或 Google Cloud？

云相关的部分是边缘同步目标、跨账户复制和目录跳转。Databricks 侧的所有内容在任何云上都是相同的，因此迁移它只需更改少量资源，而无需重建。

问：花了多长时间？

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

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