作者：Barr Moses
翻譯：陳超校對：歐陽錦
本文約3800字，建議閱讀12分鐘本文将會深入分析一些短期内最熱門的觀點，這些觀點可能會成為後現代資料堆棧的組成部分，并對它們對資料工程的潛在影響進行論述。 後現代資料堆棧已經到來。我們準備好了嗎？
圖檔由作者免費提供
如果你不喜歡改變，資料工程不适合你。在這個領域沒有任何東西能夠保持一成不變。
最近最重要的例子是Snowflake和Databricks，它們颠覆了資料庫的概念，開創了現代資料堆棧時代。
作為此次變化的一部分，Fivetran和dbt從根本上上将資料管道從ETL(Extract, Transform, Load)變為ELT。高接觸中斷軟體即服務(SaaS)以一種将重心轉移到資料倉庫的嘗試席卷了整個世界。蒙特卡洛也加入這場争論之中，并認為“讓工程師手動編寫單元測試可能并非保證資料品質的最佳方式”。
今天，資料工程師們沿着現代資料堆棧啟蒙的上坡路前進過程中繼續死磕寫死管道和企業預置型伺服器。而必将到來的兼并與幻滅的低谷已經在尚且稱之為安全的遠處顯現。
是以幹擾破壞者的新觀點已經不斷湧現的事實，這貌似看起來不太合理：
- Zero-ETL在自己的視域中有資料攝取
- AI和大型語言模型可以變形
- 資料産品容器将資料表視為資料的核心基本要素
我們要（再一次）重建一切嗎？Hadoop（分布式計算）的時代還沒到完全涼透的程度。
答案是當然的。我們可能會在職業生涯中多次重建我們的資料系統。真正的問題是為什麼、何時以及怎樣（以此為序）。
我不會妄稱自己知道所有答案或者擁有能夠預知答案的水晶球。但是本文将會深入分析一些短期内最熱門的觀點，這些觀點可能會成為後現代資料堆棧的組成部分，并對它們對資料工程的潛在影響進行論述。
實踐性和權衡
圖檔來自Unsplash上的Tingey Injury Law Firm
現代資料堆棧的出現并非因為它比之前的技術做得更好。權衡就在于此。資料更大、更快，但它也更混亂，管理更差。關于成本效益的審判仍然沒有定論。
現代資料堆棧之是以一騎絕塵，因為它能支援用例并以在從前可能是非同尋常的難度情況下将資料價值釋放出來。機器學習一詞已經從單純的流行語變成了“财富密碼”。而分析和實驗則可以更深入地支援決策更大化。
同樣的情況也适用于以下每一種趨勢。雖然毀譽參半，但是主導采納的是他們或者那些我們還未發現的黑馬們如何解鎖新的方法來利用資料。讓我們進一步來看一下。
Zero-ETL
它是什麼：一則用詞不當;資料管道仍然存在。
如今，資料通常由服務生成并寫入事務資料庫。部署的自動管道不僅将原始資料移動到分析資料倉庫，而且在此過程中對其進行了輕微修改。
例如，API 将以 JSON 格式導出資料，引入管道不僅需要傳輸資料，還需要應用輕度轉換，以確定資料采用可加載到資料倉庫中的表格式。在引入階段完成的其他常見輕量級轉換是資料格式化和重複資料删除。
雖然您可以通過在 Python 中對管道進行寫死來進行更繁重的轉換，并且有些人主張這樣做以将預先模組化的資料傳遞到倉庫，但大多數資料團隊出于權宜之計和可見性/品質原因選擇不這樣做。
Zero-ETL 通過讓事務資料庫在自動将其加載到資料倉庫之前執行資料清理和标準化來更改此引入過程。請務必注意，資料仍處于相對原始的狀态。
目前，這種緊密內建是可能的，因為大多數zero-ETL架構要求事務資料庫和資料倉庫來自同一雲提供商。
優點：減少延遲。沒有重複的資料存儲。少一個故障源。
缺點：在引入階段自定義資料處理方式的能力較差。部分供應商鎖定。
誰在推動它：AWS是流行語（Aurora到Redshift）背後的驅動力，但GCP（BigTable到BigQuery）和Snowflake（Unistore）都提供類似的功能。Snowflake（安全資料共享）和Databricks（Delta共享）也在追求它們所謂的“無複制資料共享”。此過程實際上不涉及 ETL，而是提供了對存儲資料的擴充通路。
實用性和價值釋放潛力：一方面，由于背後的科技巨頭和随時可用的能力，Zero-ETL的推廣似乎隻是時間問題。另一方面，我觀察到資料團隊正在解耦，而非更緊密地內建操作和分析資料庫，以防止意外的架構更改而使整個操作崩潰。
這種創新可能會進一步降低軟體工程師對其服務産生的資料的可見性和責任感。資料在送出代碼後不久就已經在運往倉庫的途中，他們為什麼還要關心架構？
随着流資料和微批量方法滿足了目前對“實時”資料的絕大多數需求，我認為此類創新的主要業務驅動力是基礎設施簡化。雖然無可厚非，但從長遠來看，沒有副本資料共享以消除冗長的安全審查障礙的可能性可能會導緻對此種機制報複性使用（盡管需要明确的是，這不是此消彼長的選項）。
OBT和大型語言模型
它是什麼：目前，業務利益相關者需要向資料專業人員表達他們的需求、名額和邏輯，然後資料專業人員将其全部轉換為 SQL 查詢甚至儀表闆。該過程需要時間，即使資料倉庫中已存在所有資料也是如此。更不用說在資料團隊最喜歡的活動清單中，臨時資料請求的排名介于根管和文檔之間。
有一群初創公司旨在利用像 GPT-4 這樣的大型語言模型的力量，通過讓消費者在平滑的界面中“查詢”自然語言中的資料來自動化該過程。
至少在我們的新機器人霸主使二進制成為新的官方語言之前
這将從根本上簡化自助式分析過程，并進一步使資料大衆化，但考慮到更進階分析的資料管道的複雜性，除了基本的“名額擷取”之外，該問題很難解決。
但是，如果通過将所有原始資料填充到一個大表中來簡化這種複雜性呢？
這是本恩·斯坦西爾（Benn Stancil）提出的想法，他是資料領域最優秀和有遠見的作家/創始人之一。沒有人比他更能預見現代資料堆棧的消亡。
作為一個概念，它并非那麼遙不可及。一些資料團隊已經開始使用褒貶不一的（one big table, OBT）政策了。
利用大型語言模型似乎可以克服使用OBT的最大挑戰之一，即在發現和模式識别方面的困難以及其完全缺乏組織性。對于人類來說，為他們的故事提供一個目錄和标記良好的章節是十分有用的，但人工智能并不在乎。
優點：也許可以最終兌現自助式資料分析的承諾；快速獲得見解；使資料團隊能夠将更多時間用于釋放資料價值和建構，減少響應即席查詢的時間。
缺點：是否自由過度？資料專業人員熟悉資料令人痛苦的怪癖（時區！什麼是“帳戶”？），而在某種程度上，大多數業務利益相關者對此卻并不熟悉。我們是否受益于代議制而不是直接的資料民主？
誰在推動它：Delphi和 GetDot.AI 等超級早期創業公司。像Narrator這樣的初創公司。更成熟的參與者正在做一些這樣的版本，如Amazon QuickSight，Tableau Ask Data或ThoughtSpot。
實用性和價值釋放潛力：令人耳目一新的是，這不是一項尋找用例的技術。價值和效率是顯而易見的，但技術挑戰也是顯而易見的。這一願景仍在建構中，需要更多的時間來制定。也許采用的最大障礙将是所需的基礎設施中斷，這對于更成熟的組織來說可能風險太大。
資料産品容器
它是什麼：資料表是建構資料産品的資料的建構基塊。事實上，許多資料上司者将生産表視為他們的資料産品。但是，要将資料表視為産品，需要對許多功能進行分層，包括通路管理、發現和資料可靠性。
容器化已成為軟體工程中微服務運動不可或缺的一部分。它們增強了可移植性、基礎架構抽象，并最終使組織能夠擴充微服務。資料産品容器概念設想了資料表的類似容器化。
資料産品容器可能被證明是使資料更加可靠和可治理的有效機制，特别是如果它們可以更好地呈現與資料基礎單元關聯的語義定義、資料沿襲和品質名額等資訊。
優點：資料産品容器似乎是更好地打包和執行四個資料網格原則（聯合治理、資料自助服務、将資料視為産品、域優先基礎結構）的一種方式。
缺點：這個概念會讓組織更容易還是更難擴充其資料産品？對于許多這些未來資料趨勢，另一個基本問題是，資料管道的副産品（代碼、資料、中繼資料）是否包含值得資料團隊保留的價值？
誰在推動它：Nextdata，由資料網格建立者Zhamak Dehgahni創立的創業公司。Nexla也一直在這個領域發揮作用。
實用性和價值釋放潛力：雖然Nextdata最近才從隐身中脫穎而出，資料産品容器仍在不斷發展，但許多資料團隊已經看到了資料網格實施的成熟結果。資料表的未來将取決于這些容器的确切形态和執行。
資料生命周期的無盡想象重構
圖檔來自Unsplash, zero
為了窺探資料的未來，我們需要回顧過去和現在的資料。過去、現在、未來——資料基礎設施處于不斷中斷和重生的狀态（盡管我們可能需要更多的混亂）。
資料倉庫的含義與 Bill Inmon 在 1990 年代引入的術語相比發生了巨大變化。ETL 管道現在是 ELT 管道。資料池不像兩年前那樣無固定的形狀。
随着現代資料堆棧帶來的這些創新，資料工程師在決定資料如何移動以及資料消費者如何通路資料方面仍然發揮着核心的技術作用。但有些變化比其他變化更大、更可怕。
Zero-ETL這個術語似乎很有威脅，因為它（不準确地）暗示了管道的消亡，如果沒有管道，我們需要資料工程師嗎？
盡管 ChatGPT 生成代碼的能力背後大肆宣傳，但這個過程仍然掌握在技術資料工程師手中，他們仍然需要審查和調試。大型語言模型的可怕之處在于它們如何從根本上扭曲資料管道或我們與資料消費者的關系（以及如何向他們提供資料）。
然而，這個未來，如果它成為現實，仍然強烈依賴資料工程師。
自古以來一直存在的是資料的一般生命周期。它被放出，它被塑造，它被使用，然後它被存檔（最好避免在這裡糾纏于我們自己的消亡）。
雖然底層基礎設施可能會發生變化，自動化會将時間和注意力轉移到右邊或左邊，但在可預見的未來，人類資料工程師将繼續在從資料中提取價值方面發揮關鍵作用。
這并不是因為未來的技術和創新無法簡化當今複雜的資料基礎設施，而是因為我們對資料的需求和使用将繼續增加複雜性和規模。
大資料已經并且永遠是一個來回擺動的鐘擺。我們在能力上向前飛躍，然後我們同樣迅速地找到一種方法來達到這些邊界，直到需要下一次飛躍。在這個循環中得到安慰——被需要是件好事。
Shane Murray是這篇文章的合著者。請訂閱以将他的故事發送到您的收件箱。
對資料品質的未來感興趣，請聯系蒙特卡洛團隊！
原文标題：
Zero-ETL, ChatGPT, And The Future of Data Engineering
原文連結：
https://towardsdatascience.com/zero-etl-chatgpt-and-the-future-of-data-engineering-71849642ad9c