译者 | 李睿

审校 | 重楼

无头（Headless）数据架构是组织中心数据访问层的形式化。它包含流和表，为操作用例和分析用例提供一致的数据访问。流提供了低延迟的功能，以支持对事件的及时响应，而表提供了更高延迟但非常高效的批量查询功能。用户只需选择与其需求最相关的处理头，并将其插入数据中即可。

构建无头数据架构需要识别在数据分析平台内部深处已经开展的工作，并将其向左移动，将用户已经在下游进行的工作（例如数据清理、结构化和模式化）向上游推送到源系统中。数据消费者可以依赖通过流和表提供的一组标准化数据来支持他们的操作、分析和所有中间环节。

通过左移方法创建无头数据架构。下面的图表强调了总体思路。通过将工作左移，显著降低了下游成本。

与传统的多跳方法相比，左移方法为创建、访问和使用数据提供了一种更简单、更具成本效益的方法。

多跳和奖章数据架构

如果你像绝大多数组织一样，那么可能建立了一些提取-转换-加载（ETL）数据管道、数据湖、数据仓库和/或数据湖。分析平台的数据分析师需要不同于操作平台软件开发人员所使用的专门工具。这种通用的“左移数据”结构通常被称为多跳数据架构。

奖章架构可能是多跳架构中最流行的形式。它有三个级别的数据质量，采用奥运奖牌的颜色（铜、银和金）来表示。铜层作为着陆区，银层作为清理和定义明确的数据层(第二阶段)，金层作为业务级聚合数据集(第三阶段)。

进入第一阶段的数据通常是原始的非结构化数据。然后对其进行清理、图式化和标准化，然后写入第二阶段。从这里开始，它可以进一步聚合、分组、非规范化和处理，以在第三阶段中创建特定于业务的数据集，这些数据集将继续为仪表板、报告提供动力，并为人工智能和机器学习模型提供训练数据。

多跳架构的问题

首先，多跳架构的速度很慢，因为它们通常是通过周期性触发的批处理进程实现的。在下一跳开始之前，数据必须从源传输到铜层。

例如，如果每隔15分钟将数据拉入铜层，那么随后的每一跳也只能每隔15分钟进行一次，因为数据只能以最慢部分的速度从一个阶段移动到另一个阶段。即使将每一跳的间隔时间缩短到1分钟，那么在金层中仍然需要至少3分钟才能获得这些数据(不包括处理时间)。

其次，多跳架构开销很大，因为每一跳都是数据的另一个副本，这需要处理能力来加载、处理数据，并将其写入下一跳阶段。这很快就会累积起来。

第三，多跳架构往往很脆弱，因为工作流的不同阶段、源数据库和最终用例通常由不同的人负责。为了防止中断，需要非常强的协调。但在实践中，这往往很难扩大规模。

第四，通过让数据分析师有责任获取他们自己的数据，最终可能会得到相似但又不同的数据管道。每个团队都可以构建自己的自定义管道，以避免分布式所有权问题，但这可能导致相似但不同的管道的蔓延。公司的规模越大，相似但又不同的管道和数据集就越常见。找到所有可用的数据集可能会变得很有挑战性。

但这导致了出现第五个问题，即相似但不同的数据集。为什么会有多个数据集？应该使用哪一个？这个数据集是否还在维护中，或者它是一个僵尸数据集，虽然还在定期更新，但有没有人监督？当依赖本应相同但实际上并不相同的数据集进行重要计算，而这些计算结果又相互矛盾时，问题就出现了。向客户提供相互矛盾的报告、仪表板或指标会导致信任丧失，在最坏的情况下，还会导致业务损失甚至法律诉讼。

即使解决了所有这些问题—减少延迟、降低成本、删除重复的管道和数据集以及消除故障修复工作，仍然没有提供任何操作可以使用的程序。它们仍然是独立的，在ETL的上游，因为所有的清理、结构、重构和分发工作只对数据分析领域的人真正有用。

左移以实现无头数据架构

构建无头数据架构需要重新思考如何在组织中循环、共享和管理数据——这是一种向左的转变。从下游提取ETL->铜牌层->银牌层，并将其放在数据产品的上游，更接近数据源。

“流优先”的方法为数据产品提供了亚秒级的数据新鲜度，这与ETL生成的周期性数据集形成了鲜明对比，这些数据集最多只有几分钟的历史并且过时。通过左移，可以让公司各部门的数据访问成本更低、更便捷、更快速。

使用数据产品构建无头数据架构

在无头数据架构中，数据的逻辑顶层是数据产品，你可能已经通过数据网格方法对它有所了解。在无头数据架构中，数据产品由流(由Apache Kafka提供支持)和相关表(由Apache Iceberg提供支持)组成。写入流的数据也会自动附加到表中，这样你就可以作为Kafka主题或Iceberg访问数据。

下图显示了从源系统创建的流/表数据产品。首先将数据写入流。然后，可以选择转换流中的数据，最终将其具体化到Iceberg表中。

可以使用流（Kafka主题）来支持低延迟的业务操作，例如订单管理、车辆调度和金融交易。与此同时，也可以将批量查询头插入到Iceberg表中，以计算更高延迟的工作负载，例如日常报告、客户分析和定期人工智能训练。

数据产品是一种值得信赖的数据集，专门用于与其他团队和服务共享和重用。它是职责、技术和流程的规范化，以简化获取你和你的服务所需的数据。你可能还听说过将数据产品称为可重用数据资产，尽管其本质是相同的——可共享、可重用、标准化和可信赖的数据。

数据产品创建逻辑在很大程度上依赖于源系统。例如：

• 事件驱动的应用程序将其输出直接写入Kafka主题，这可以很容易地具体化到Iceberg表。数据产品创建逻辑可能非常简单，例如，屏蔽机密字段或完全删除它们。
• 传统的请求/响应应用程序使用更改数据捕获(CDC)从底层数据库中提取数据，将其转换为事件，并将其写入Kafka主题。更改数据捕获(CDC)事件包含一个基于源表的定义良好的模式，你可以使用连接器本身或更强大的工具(例如FlinkSQL)对数据执行进一步的转换。
• SaaS应用程序可能需要使用Kafka Connect对端点进行周期性轮询以写入流。

流优先数据产品的优雅之处在于，你只需将其写入流即可。你不必管理分布式事务来同时向流和表写入数据(这很难正确完成，而且速度相对较慢)。相反，你可以通过Kafka Connect或专有的SaaS流到表解决方案(例如Confluent的Tableflow)从流创建一个只能追加的Iceberg表。容错和只写一次可以帮助检查数据完整性，无论从流还是从表中读取，都可以得到相同的结果。

选择左移的数据集

“左移”并不是非此即彼的。事实上，它是非常模块化和渐进的。你可以有选择地决定哪些负载需要左移，哪些保持不变。你可以设置一个并行的左移解决方案，对其进行验证，一旦满意，就可以将现有的作业切换到该解决方案上。这个过程大致如下：

（1）在分析平台中选择一个常用的数据集。越常用的数据集，越适合左移。几乎没有容错余地的业务关键数据(如账单信息)也是左移的理想选择。

（2）识别操作平台中的数据来源。这就是你需要用它来创建数据流的系统。需要注意的是，如果这个系统已经是事件驱动的，那么你可能已经有一个可用的流，可以跳到下面的步骤4。

（3）创建一个与现有ETL管道并行的源到流工作流。你可能需要使用Kafka连接器(例如CDC)来将数据库数据转换为事件流。或者，你可以选择直接向流生成事件；只需确保编写了完整的数据集，使其与源数据库保持一致。

（4）从流中创建一个表。你可以使用Kafka Connect来生成Iceberg表，或者你可以依靠自动化的第三方专有服务来为你提供Iceberg表。完全披露：使用Kafka Connect会导致数据的副本被写入Iceberg表。在不久的将来，预计期望看到第三方服务提供扫描Kafka主题作为Iceberg表的能力，而无需制作数据的第二份副本。

（5）将表插入到现有的数据湖中，与银层中的数据放在一起。现在可以验证新的Iceberg

表是否与现有数据集中的数据一致。一旦满意，就可以将数据分析作业从旧的批量创建的表中迁移出去，弃用它，然后在方便的时候将其删除。

其他的无头数据架构注意事项

你可以将Iceberg表插入任何兼容的分析端点，而无需复制数据。对于数据流来说，情况也是如此。在这两种情况下，只需选择处理头，并根据需要将其插入表或流中。

左移还解锁了典型的复制粘贴、多跳和奖章架构所没有的一些强大功能。你可以从单个逻辑点一起管理流和表的演烃，验证流演化不会破坏Iceberg表。

由于工作已从数据分析空间中转移出来，你可以将数据验证和测试集成到源应用程序部署管道中。这可以帮助防止在代码进入生产环境之前发生的破坏，而不是在下游很久之后才检测到它。

最后，由于表是从流派生出来的，因此只需要在一个地方修复它，无论你向流写入什么内容，都会传播到表中。流媒体应用程序将自动接收纠正的数据，并进行自我纠正。但是，需要识别并重新运行使用该表的定期批处理作业。但无论如何，这与在传统的多跳架构中需要做的事情是相同的。

无头数据架构可以在整个组织中解锁前所未有的数据访问，但它从左移开始。

原文标题：How to implement a headless data architecture，作者：Adam Bellemare