后現(xiàn)代數(shù)據(jù)堆棧已經(jīng)到來。我們準備好了嗎？

圖片由作者免費提供

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

最近最重要的例子是Snowflake和Databricks，它們顛覆了數(shù)據(jù)庫的概念，開創(chuàng)了現(xiàn)代數(shù)據(jù)堆棧時代。

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

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

所以干擾破壞者的新觀點已經(jīng)不斷涌現(xiàn)的事實，這貌似看起來不太合理：

• Zero-ETL在自己的視域中有數(shù)據(jù)攝取

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

• 數(shù)據(jù)產(chǎn)品容器將數(shù)據(jù)表視為數(shù)據(jù)的核心基本要素

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

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

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

圖片來自Unsplash上的Tingey Injury Law Firm

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

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

同樣的情況也適用于以下每一種趨勢。雖然毀譽參半，但是主導(dǎo)采納的是他們或者那些我們還未發(fā)現(xiàn)的黑馬們?nèi)绾谓怄i新的方法來利用數(shù)據(jù)。讓我們進一步來看一下。

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

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

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

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

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

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

優(yōu)點：減少延遲。沒有重復(fù)的數(shù)據(jù)存儲。少一個故障源。

缺點：在引入階段自定義數(shù)據(jù)處理方式的能力較差。部分供應(yīng)商鎖定。

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

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

這種創(chuàng)新可能會進一步降低軟件工程師對其服務(wù)產(chǎn)生的數(shù)據(jù)的可見性和責任感。數(shù)據(jù)在提交代碼后不久就已經(jīng)在運往倉庫的途中，他們?yōu)槭裁催€要關(guān)心架構(gòu)？

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