7 Crucial Barriers Between Data Teams and Self-Healing Data Architecture

数据团队与自修复数据架构之间存在的7个关键障碍 | Towards Data Science

数据科学

数据团队与自修复数据架构之间存在的7个关键障碍

数据团队需要借助AI构建什么，才能使自修复数据架构成为现实

Hugo Lu

2026年6月20日

11分钟阅读

分享

照片由SoloTravelGoals通过Unsplash提供

引言

对许多数据工程师而言，数据工程中的AI示例都围绕着一件事：修复一个数据管道。工程师打开Claude Code，粘贴一些日志，然后就生成了一个拉取请求。

语义在这里是关键。因为当人们说“自修复”时，他们实际上指的是“自管理”。AI成功的关键不在于手动干预和交互，而在于没有这些干预和交互。

数据团队的梦想是一个系统，其中数据管道和工作流在没有任何人工干预的情况下通常都能成功。然而，我们与这个理想未来之间还存在一些障碍。

代理需要上下文——修复一个管道可能是由于瞬时错误、上游模式变更，或者完全无法控制的事情，比如某人删除了一个表。经验为工程团队提供了如何修复这些问题的知识；而上下文代理却缺失了。

思维方式的转变也将很明显。旧的“新建分支、合并、重新运行”的模式明显缓慢，而且不具有代理性。除非我们改变我们的模式，允许代理合并拉取请求，否则似乎需要一次重大的思维方式转变。

最后，数据本身并不适合“分支”。Lake FS等项目承诺让“数据的Git”成为主流，但目前尚未实现。我多年来一直在撰写关于零拷贝克隆的内容，但目前仍不广泛使用。代码和数据之间的区别并不明显。

在本文中，我们将探讨当今典型数据堆栈与自修复数据管道/自主数据管道理想状态之间的7个障碍。

让我们深入探讨！

障碍1 | 上下文与故障回溯

数据管道可能因多种原因而失败，而能够修复数据管道是AI系统的一项基本要求。我们可以将故障分为几大类：

• 基础设施问题

• 代码问题

• 数据问题

• 瞬时或第三方问题

通常，修复数据需要对系统有所了解。例如，Acme的Kubernetes集群可能只能由Bob访问，而Bob是唯一拥有访问权限的人，他拥有隐藏在AWS Secrets Manager中的特殊访问密钥，且该密钥具有非标准的头部。AI并不知道Bob的密钥，因此无法修复集群。

同样，分析师Sophie可能知道在Widgets公司中，正确的方法是简单地忽略销售以多种货币报告的事实，并将数字调整为比昨天高出10%。AI并不知道如何处理这些数字。

AI可能也不知道，为了处理内部API的故障，只需要在凌晨2:47到3:12之间再次尝试调用它。

这些例子听起来有些荒谬，但它们说明了修复这些不同类型错误的知识通常存在于个人的脑海中。仅仅谈论“元数据上下文”是不够的。虽然收集血统、日志、代码、文档和其他书面上下文无疑是至关重要的，但AI实际上非常擅长自己推断出这些信息。

作为数据从业者，我们都有过这样的经历，我们（或者我们与之交谈过的人）可能曾想过：

“天哪，我怎么可能知道呢？”

说到底，只有人类才知道那些“尸体”埋在哪里。

整个结构都是技术债务，可以通过 AI 进行分解。来源

障碍 2 | 弹性基础设施

就基础设施类型的问题而言，我提出一个新术语：“弹性”基础设施。“弹性基础设施”不仅仅是能够扩展，还具备用于管理它的 API。

一个 EC2 实例并不具备弹性，因为它无法扩展到某个特定点以外。

如果在一个锁定的机器上运行 Kubernetes 集群，那么它相对于云而言也不具备弹性，因为没有用于管理的 API。

原因在于，AI 需要访问基础设施，以便从中恢复故障。

SaaS 提供商应该珍惜这个机会。SaaS 提供商通过收费的方式，必然地将基础设施管理的负担从数据团队中移除。这是一种非常 AI 友好的方法，但在障碍 6 方面存在缺陷，我们稍后会谈到。

障碍 3 | 运营代理与高质量数据

财务部门的 Pete 再次覆盖了美国的供应链和运营计划 Google 表格。国际预测已经损坏，你的管道正在失败。us_forecast_dec_v1 中没有一行数据，而 forecasts_agg 已经过时。

AI 告诉你连接器没有问题，但没有数据。它什么都做不了。

这里的解决方案是什么？我们来玩个问答游戏吧。我会给你一些想法，你来选择正确的答案。

• 选项 1：让 AI 虚构预测数据

• 选项 2：让 AI 在数据仓库中虚构预测数据，并稍后重新运行 Google 表格管道

• 选项 3：让 AI 告诉 Pete 上载该死的预测数据！

• 选项 4：有一个“温热池”租赁的人类团队。当这种类型的管道失败时，AI 会指示温热池的人亲自去麻烦 Pete，直到他手动修复管道为止

当然，这里没有正确答案！所有选项都不太好，从糟糕到荒谬不等。事实上，选项 4 根本不需要 AI，而是需要一种叫做“团队合作”的东西。

一如既往，高质量的数据对数据工程师来说是最重要的。数据团队在面试时应该问这个问题：“你的数据有多好？”这在很大程度上决定了生活质量，令人惊讶的是，这个问题并没有得到更多的提及。

这并不是说运营代理没有存在的空间——例如，真正的“手指打滑”错误很容易通过运营代理进行纠正。例如，假设有一个新的 1000 万美元的交易——也许正确的数字是 100 万美元。拥有 Salesforce API 密钥的代理可以轻松地修改数据，并重新启动管道。

在上述两种情况下，AI都需要一个新的分支来完成其工作。该分支需要数据的零拷贝克隆，需要一种以数据为中心的Git方法，并且你需要能够高效地在最后“切换”进这些数据。

简单的以数据为中心的Git工作流程

如果没有这种结构，我很难想象AI如何能够被信任，可靠地修复问题，而不会造成治理上的噩梦，即AI拥有对生产数据的写入权限。

在这方面，像Snowflake这样的公司处于有利地位，因为它们长期以来一直支持诸如零拷贝克隆等功能。Motherduck也支持这一功能。不过，最明显的优势者是Iceberg。

Iceberg支持时间旅行、回滚和以数据为中心的Git。像Bauplan这样的公司已经围绕Iceberg构建了计算引擎，这为AI提供了一个友好的体验。AI应该是推动Iceberg发展的重要催化剂。

障碍 5 | 贯穿行业的普及

当谈到互操作性时，自愈架构遇到了一个问题。

Fivetran和dbt在2025年大肆宣传开放数据基础设施，这与开源数据基础设施并不相同，而是指一种我认为更恰当称为模块化数据架构的方法，其中不同的功能使用不同的工具。下面有一个例子。

模块化数据架构。来源

如果底层组件不支持，那么拥有自愈架构是没有意义的。底层服务提供商应提供相关API，支持本文中提到的所有原则，并且自身具备自愈功能，以使模式能够运行。

例如，假设一个ELT提供者出现了静默故障，其中子模式发生了变化；列和类型保持不变，但值发生了变化。也许现在报告的货币包括日元和美元，但currency和local_value这两列仍然存在。

正确的做法可能是在暂存环境中修改ELT任务，从该暂存数据验证整个管道，切换出现在正确的数据，然后最终切换出错误地成功执行的ELT任务。

许多ELT工具根本无法提供实现此功能所需的API。然而，如果你使用自己控制的Python脚本进行此操作，就不会有问题。这将对当今的ETL玩家施加巨大的压力，迫使他们改变结构或被淘汰。

这是当今模块化系统与真正自愈自主架构之间的一个巨大障碍。其他可能的例子是系统本身都成为独立的自愈系统，因为如果你希望系统的所有部分都能自愈，那么整个系统也应该如此。

障碍 6 | 代理沙箱和新的编排器

修复问题的代理逻辑上应该在编排工具中运行。

这是因为编排工具具备代理所需的一些功能。

• 能够运行任何代码，并使用任意参数集重新运行任何DAG

• 与代理可能需要的系统不同部分的连接（记住，编排器负责编排，因此它能够访问这些资源）

• 内置的警报，包括监控、恢复和可扩展的基础设施

然而，有一个巨大的问题——那就是安全性。

像 Cloudflare 这样的公司已经构建了代理沙箱。这是因为像 Fable（最近被封禁）这样的模型需要沙箱，因为它们可能会突破限制。尤其是在受到提示注入攻击时，这种情况尤为明显。

在与传统编排器共享同一基础设施中运行 AI 代理时，提示注入的危险

传统的编排工具根本无法以这种方式处理代理。安全风险巨大。更不用说 AI 工作负载可能会干扰数据工作负载！

很明显，代理将需要访问编排框架。无论这是 Open AI 和 Anthropic 提供的编排器，还是具有代理沙箱的新一代编排器，或者两者之间某种形式的互操作性——这里必须有所让步，因为安全问题。

障碍 7 | 代理服务器和代理定义的标准

一种安全方法是为代理设置一个代理服务。而不是在沙箱中安装秘密信息，代理可以访问一定数量的工具 / MCP。

然后，代理服务是唯一可以访问外部系统的组件。这意味着即使代理成为提示注入攻击的受害者，它所能做的也仅限于其可访问的 MCP 端点所允许的范围。

一个带有认证服务器和凭证数据库的基本代理服务示意图

这个代理服务应该是什么样子并不明显。MCP 很庞大。Cloudflare 发布了 Code Mode。如果你需要访问多个不同的端点，MCP 服务器应该如何配置并不是显而易见或直接的。

开放标准应该占主导地位——任何希望与多个系统安全交互的代理，从安全角度来看，与代理服务进行交互都会受益。这些标准今天已经存在，但只存在于像 Foundry 这样的私有 SaaS 工具中。

设计代理的框架也需要出现。在上面的例子中，一个需要与数百个系统集成的代理可能不可行，因为访问数百个 MCP 所需的上下文可能太大。

综合起来 | AI 的单一控制面板

总体而言，实现上述目标将使数据团队能够为 AI 构建一个单一控制面板。

• 上下文：为代理提供解决问题所需的信息
• 弹性基础设施：为修复管道提供基础
• 高质量数据：消除数据输入中的人为因素
• 数据的 Git：在 AI 中创建可靠性和信任
• 大规模采用：防止行业崩溃
• 代理沙箱和新编排器：消除传统架构
• 代理服务器：尽最大努力确保安全

这个单一控制面板将使 AI 代理能够以安全的方式运行。它们会在需要时执行，并且拥有完成所需任务所需的上下文。

像数据的 Git、弹性基础设施以及生态系统中的支持这样的核心数据原语，将使这一理论想法变为现实。

希望实现自主架构的数据团队将对现有供应商施加巨大的压力，以支持互操作性。

这将加剧整合，因为像 Salesforce、SAP 和 ServiceNow 这样的传统封闭系统将推出自己的代理产品和数据工作室，能够控制端到端流程，但不提供互操作性。

撰写人

查看 Hugo Lu 的所有文章

代理 AI

,

数据架构

数据工程

数据管道

数据团队

分享本文

• 在 Facebook 上分享

• 在 LinkedIn 上分享

• 在 X 上分享

Towards Data Science 是一份社区出版物。提交你的见解，以触达我们的全球读者，并通过 TDS 作者支付计划获得报酬。

更新 href 为你的实际投稿网址

为 TDS 写作

✦ 结束 CTA ✦