獨家 | Zero-ETL, ChatGPT以及數(shù)據(jù)工程的未來(1)
后現(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ù)性使用(盡管需要明確的是,這不是此消彼長的選項)。
*博客內(nèi)容為網(wǎng)友個人發(fā)布,僅代表博主個人觀點,如有侵權(quán)請聯(lián)系工作人員刪除。