AWS Re:Invent的Zero-ETL方案消除了对 ETL 需求，Snowflake 通过他们的混合表以及与 Salesforce 的合作伙伴关系也宣布了这一点。

对 "零ETL" 的命名有点异议，从表面上看所描述的功能通常更接近零集成的未来，这可能还不够“令人兴奋”。这也可能只是 AWS 和 Snowflake 消除对 ETL 需求的计划的第一阶段。

总的来说减少现有的重复逻辑和数据量的想法非常好。作为一名数据工程师，有时数据管道会变得过于复杂而且非常脆弱，这取决于它们对数据生产者的依赖程度。因此如果存在某种形式的 ETL 方案，我们应该实现它。

本文将介绍零 ETL 的未来以及如何实现这一目标。

认知

当读到或听到这样的公告时，我认为其中存在未讨论的细微差别。但我发现当企业阅读这些类型的公告时，他们会按字面意思看待。

他们回来告诉他们的团队，我们想要转向这个无代码、零 ETL 和无服务器的未来。从商业角度来看这一切听起来都不错：成本将会降低^[1]，人员数量可以减少，并且可以立即从数据中获得价值。

但这将跳过所有其他不可避免的细微差别。

甚至我读过的一篇文章提到：

ETL 是每个数据科学家和团队的祸根，因为他们试图使数据成形以使其发挥作用。正如 AWS 首席执行官 Adam Selipsky 解释的那样，您可能在许多不同的地方拥有数据，例如数据库中的应用程序使用数据和数据湖中的客户评论。到目前为止，将它们放在一起一直是一项重大挑战。

听起来好像通过 AWS 的解决方案可以为数据科学家解决这个问题。如果我们可以创建一个零 ETL 世界，数据科学家就可以方便地从他们想要的任何地方提取数据，而无需与数据工程师交互。奇怪的是他们跳过了数据工程师，只提到了对数据科学家的影响。

但数据科学家真的不需要数据工程师就可以玩转所有数据吗？

在深入探讨零 ETL 的未来之前先回顾一下 ETL 存在的一些原因。

为什么需要ETL

简单地将数据从 A 点复制到 B 点不是 ETL。如果这就是我们需要做的全部，我们可以只创建复制数据库^[2]。那么为什么要创建复杂的系统并使用像 Airflow 或 Prefect^[3] 这样的工具呢？

为什么要聘请昂贵的数据工程师^[4]？

为什么还要ETL？

我们有 Presto，从技术上讲，它可以直接从 MySQL 源查询大量数据。那么我们需要 ETL 吗？

历史数据：一般来说，大多数运营数据库不跟踪历史数据。具体来说，他们不会跟踪历史上不断变化的实体数据，比如客户居住的地方。

因此当数据被更新或删除时，如果您不使用 CDC（更改数据捕获），您将丢失信息。这就是存在缓慢变化维度概念的原因——帮助跟踪信息以确保如果客户改变状态或员工更换工作，我们可以随着时间的推移准确地反映这一点。

当然可以做的不是传统的 SCD（缓慢变化维^[5]），而是简单地创建一个日期分区并将数据加载到一个不断扩展的表中。Facebook 时常这样做，因为它的设计更简单。

但它也会使分析师和数据科学家更难查询数据。在很多情况下，我必须构建一个辅助表，该辅助表将添加逻辑来跟踪每个日期分区的变化。

因此最终从数据模型中删除缓慢变化维度的概念可能非常棘手。

集成数据：在 Facebook 工作的主要好处之一是数据在应用程序级别的集成程度。 存在一个实体层，任何人在构建新功能时都可以从中提取^[6]，这意味着在应用程序端和分析端都可以轻松地将实体连接在一起。

后面 Facebook 已经将大部分核心管道减少到 30-50 行代码以下，因为它主要只是配置。甚至 SQL 部分也可能被删除。这在很大程度上是因为实体层开发得很好，我们不需要编写复杂的查询来尝试连接数据。

这并非总是如此。许多公司拥有各种形状和大小的数据，因此几乎不可能跨源集成数据，或者需要额外的几百行 SQL 才能跨实体连接。

易于使用：从 MongoDB 或 MySQL 等操作数据库中提取的数据通常以分析师难以处理的方式构建。您能想象将来自 MongoDB 的数据文件交给分析师吗？它嵌套很深并且容易出错。

同样来自传统 MySQL 数据库的高度规范化的数据模型也会带来问题。简单地将数据复制到 Redshift 或 Snowflake 中将迫使分析师编写需要多个连接和可能的业务逻辑的查询。同样容易出错。

对数据所做的大部分工作，无论是标准化命名约定还是完全重塑数据，都是为了让分析师更容易访问数据。不仅仅是将其放入另一个数据库，而是将其视为用户与之交互的产品。

综上所述，我确实相信未来可能会删除 ETL，至少是为了创建核心数据层。

零 ETL 未来需要什么？

实体层

如果更多的公司能够构建在应用层集成的系统，那么在集成数据方面就不会出现任何问题。

这也会让应用程序团队和 SaaS 解决方案承担更多责任。我确实相信这将构成重大挑战，并且将成为阻碍真正的零 ETL 未来发展的主要原因。

命名和数据类型约定

标准化命名和类型约定将节省大量繁琐的工作。我认为可以公平地问......为什么数据工程师仍然需要编写小的“t”转换？归根结底，我们最好都同意开始使用标准化约定来命名所有字段。这将使我们也能够标准化数据类型。当然软件工程师还必须就日期格式达成一致。

生产者所有权

数据仓库或任何独立的纯基础设施层无法解决 SaaS 应用程序的零ETL。只有当 SaaS 供应商负责将数据移动到其客户的 DW 时，才能实现这一愿景。

除了负责移动数据之外，SaaS 供应商和数据生产商还必须确保他们管理所有逻辑和数据更改。

删除 ETL 最困难的部分是 T。而不是一些基本的转换，例如标准化命名约定和数据类型（为什么还没有自动化）。即使添加缓慢变化的维度，也可以说是普遍化的。

任何需要手动管理的业务逻辑或奇怪的枚举器都必须由数据生产者处理，无论是公司应用程序还是 Salesforce。

真相

有些人可能会认为我最初是一名数据工程师，所以想捍卫 ETL，这是我们承担的一项常见任务。然而世界在变，可能不再需要数据工程师来构建ETL？

现在我认为这不会在未来两年内发生^[7]。尤其是在企业层面，对于他们来说，迁移当前解决方案需要两年的时间。因此即使他们今天开始，我们离实现零 ETL 还有很长的路要走。

引用链接

[1] 成本将会降低: [https://www.theseattledataguy.com/reducing-data-analytics-costs-in-2023-doing-more-with-less/#page-content](https://www.theseattledataguy.com/reducing-data-analytics-costs-in-2023-doing-more-with-less/#page-content)
[2] 复制数据库: [https://seattledataguy.substack.com/i/47552632/the-replicant-database](https://seattledataguy.substack.com/i/47552632/the-replicant-database)
[3] Airflow 或 Prefect: [https://seattledataguy.substack.com/p/should-you-use-apache-airflow](https://seattledataguy.substack.com/p/should-you-use-apache-airflow)
[4] 数据工程师: [https://seattledataguy.substack.com/p/different-types-of-data-engineering](https://seattledataguy.substack.com/p/different-types-of-data-engineering)
[5] 缓慢变化维: [https://www.sqlshack.com/implementing-slowly-changing-dimensions-scds-in-data-warehouses/](https://www.sqlshack.com/implementing-slowly-changing-dimensions-scds-in-data-warehouses/)
[6] 存在一个实体层，任何人在构建新功能时都可以从中提取: [https://engineering.fb.com/2013/06/25/core-data/tao-the-power-of-the-graph/](https://engineering.fb.com/2013/06/25/core-data/tao-the-power-of-the-graph/)
[7] 未来两年内发生: [https://movedata.airbyte.com/event/data-contracts-are-so-hot-right-now-because-they-are-just-interfaces](https://movedata.airbyte.com/event/data-contracts-are-so-hot-right-now-because-they-are-just-interfaces)