獨家 | Zero-ETL, ChatGPT以及數據工程的未來（1）

后現代數據堆棧已經到來。我們準備好了嗎？

圖片由作者免費提供

如果你不喜歡改變，數據工程不適合你。在這個領域沒有任何東西能夠保持一成不變。

最近最重要的例子是Snowflake和Databricks，它們顛覆了數據庫的概念，開創了現代數據堆棧時代。

作為此次變化的一部分，Fivetran和dbt從根本上上將數據管道從ETL(Extract, Transform, Load)變為ELT。高接觸中斷軟件即服務(SaaS)以一種將重心轉移到數據倉庫的嘗試席卷了整個世界。蒙特卡洛也加入這場爭論之中，并認為“讓工程師手動編寫單元測試可能并非保證數據質量的最佳方式”。

今天，數據工程師們沿著現代數據堆棧啟蒙的上坡路前進過程中繼續死磕硬編碼管道和企業預置型服務器。而必將到來的兼并與幻滅的低谷已經在尚且稱之為安全的遠處顯現。

所以干擾破壞者的新觀點已經不斷涌現的事實，這貌似看起來不太合理：

• Zero-ETL在自己的視域中有數據攝取

• AI和大型語言模型可以變形

• 數據產品容器將數據表視為數據的核心基本要素

我們要（再一次）重建一切嗎？Hadoop（分布式計算）的時代還沒到完全涼透的程度。

答案是當然的。我們可能會在職業生涯中多次重建我們的數據系統。真正的問題是為什么、何時以及怎樣（以此為序）。

我不會妄稱自己知道所有答案或者擁有能夠預知答案的水晶球。但是本文將會深入分析一些短期內最熱門的觀點，這些觀點可能會成為后現代數據堆棧的組成部分，并對它們對數據工程的潛在影響進行論述。

圖片來自Unsplash上的Tingey Injury Law Firm

現代數據堆棧的出現并非因為它比之前的技術做得更好。權衡就在于此。數據更大、更快，但它也更混亂，管理更差。關于成本效益的審判仍然沒有定論。

現代數據堆棧之所以一騎絕塵，因為它能支持用例并以在從前可能是非同尋常的難度情況下將數據價值釋放出來。機器學習一詞已經從單純的流行語變成了“財富密碼”。而分析和實驗則可以更深入地支持決策更大化。

同樣的情況也適用于以下每一種趨勢。雖然毀譽參半，但是主導采納的是他們或者那些我們還未發現的黑馬們如何解鎖新的方法來利用數據。讓我們進一步來看一下。

它是什么：一則用詞不當;數據管道仍然存在。

如今，數據通常由服務生成并寫入事務數據庫。部署的自動管道不僅將原始數據移動到分析數據倉庫，而且在此過程中對其進行了輕微修改。

例如，API 將以 JSON 格式導出數據，引入管道不僅需要傳輸數據，還需要應用輕度轉換，以確保數據采用可加載到數據倉庫中的表格式。在引入階段完成的其他常見輕量級轉換是數據格式化和重復數據刪除。

雖然您可以通過在 Python 中對管道進行硬編碼來進行更繁重的轉換，并且有些人主張這樣做以將預先建模的數據交付到倉庫，但大多數數據團隊出于權宜之計和可見性/質量原因選擇不這樣做。

Zero-ETL 通過讓事務數據庫在自動將其加載到數據倉庫之前執行數據清理和標準化來更改此引入過程。請務必注意，數據仍處于相對原始的狀態。

目前，這種緊密集成是可能的，因為大多數zero-ETL架構要求事務數據庫和數據倉庫來自同一云提供商。

優點：減少延遲。沒有重復的數據存儲。少一個故障源。

缺點：在引入階段自定義數據處理方式的能力較差。部分供應商鎖定。

誰在推動它：AWS是流行語（Aurora到Redshift）背后的驅動力，但GCP（BigTable到BigQuery）和Snowflake（Unistore）都提供類似的功能。Snowflake（安全數據共享）和Databricks（Delta共享）也在追求它們所謂的“無復制數據共享”。此過程實際上不涉及 ETL，而是提供了對存儲數據的擴展訪問。

實用性和價值釋放潛力：一方面，由于背后的科技巨頭和隨時可用的能力，Zero-ETL的推廣似乎只是時間問題。另一方面，我觀察到數據團隊正在解耦，而非更緊密地集成操作和分析數據庫，以防止意外的架構更改而使整個操作崩潰。

這種創新可能會進一步降低軟件工程師對其服務產生的數據的可見性和責任感。數據在提交代碼后不久就已經在運往倉庫的途中，他們為什么還要關心架構？

隨著流數據和微批量方法滿足了目前對“實時”數據的絕大多數需求，我認為此類創新的主要業務驅動力是基礎設施簡化。雖然無可厚非，但從長遠來看，沒有副本數據共享以消除冗長的安全審查障礙的可能性可能會導致對此種機制報復性使用（盡管需要明確的是，這不是此消彼長的選項）。