獨(dú)家 | Zero-ETL, ChatGPT以及數(shù)據(jù)工程的未來(lái)（1）

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

圖片由作者免費(fèi)提供

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

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

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

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

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

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

• AI和大型語(yǔ)言模型可以變形

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

我們要（再一次）重建一切嗎？Hadoop（分布式計(jì)算）的時(shí)代還沒(méi)到完全涼透的程度。

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

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

圖片來(lái)自Unsplash上的Tingey Injury Law Firm

現(xiàn)代數(shù)據(jù)堆棧的出現(xiàn)并非因?yàn)樗戎暗募夹g(shù)做得更好。權(quán)衡就在于此。數(shù)據(jù)更大、更快，但它也更混亂，管理更差。關(guān)于成本效益的審判仍然沒(méi)有定論。

現(xiàn)代數(shù)據(jù)堆棧之所以一騎絕塵，因?yàn)樗苤С钟美⒁栽趶那翱赡苁欠峭瑢こ５碾y度情況下將數(shù)據(jù)價(jià)值釋放出來(lái)。機(jī)器學(xué)習(xí)一詞已經(jīng)從單純的流行語(yǔ)變成了“財(cái)富密碼”。而分析和實(shí)驗(yàn)則可以更深入地支持決策更大化。

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

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

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

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

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

Zero-ETL 通過(guò)讓事務(wù)數(shù)據(jù)庫(kù)在自動(dòng)將其加載到數(shù)據(jù)倉(cāng)庫(kù)之前執(zhí)行數(shù)據(jù)清理和標(biāo)準(zhǔn)化來(lái)更改此引入過(guò)程。請(qǐng)務(wù)必注意，數(shù)據(jù)仍處于相對(duì)原始的狀態(tài)。

目前，這種緊密集成是可能的，因?yàn)榇蠖鄶?shù)zero-ETL架構(gòu)要求事務(wù)數(shù)據(jù)庫(kù)和數(shù)據(jù)倉(cāng)庫(kù)來(lái)自同一云提供商。

優(yōu)點(diǎn)：減少延遲。沒(méi)有重復(fù)的數(shù)據(jù)存儲(chǔ)。少一個(gè)故障源。

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

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

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

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

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