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)