資料湖還沒玩明白，就別想著湖倉一體了！

資料湖的熱還沒褪去，湖倉一體就被炒起來了，有人問要不要入局湖倉一體，我的觀點：先把自家的資料湖玩明白了再說吧，事實上，大多數的資料湖用得名不副實，更別提湖倉一體了。

為什麼這麼說呢?

判斷一個技術對自己有沒有用，我還是喜歡追溯下技術的源頭，很多技術被產品化後，夾雜了太多的私貨。

在說明我的觀點之前，先做一個資料技術的穿越，從資料庫、資料倉儲、資料湖再到湖倉一體。

1、簡單可用階段：資料庫(DataBase)

早在1980年代初中期，是沒有專門面向資料分析場景的產品。當時還是以面向事務交易場景為主，資料分析僅作為附帶提供的場景。主要是面對管理層提供固定報表，滿足宏觀管理決策。作為底層資料庫，透過標準SQL提供資料分析能力。

這一架構在面對資料分析場景的缺點很明顯，整合水平低，擴充套件性差，很難支援大規模資料分析，效能也無法滿足需求。這也催生專門解決資料分析的產品出現，即後面出現的資料倉儲。

2、 規範標準階段：數倉(Data Warehouse)

到了1980年代中後期，為解決資料庫面對資料分析的不足，孕育出新一類產品資料倉儲。讓我們先來看下資料倉儲的定義，資料倉儲(Data Warehouse)是一個面向主題的、整合的、相對穩定的、反映歷史變化的資料集合，用於支援管理決策和資訊的全域性共享。

上圖是資料倉儲的應用架構，從中可見其做了若干階段劃分，簡單可分為資料整合(裝載)、資料加工(ETL)、資料匯聚、資料展示及挖掘。資料經過這一過程，被抽取到資料倉儲中，並嚴格按照預先定義的模式被裝載進來，經過多層加工形成資料集市，並最終提供給終端應用或進一步供挖掘使用，主要場景包括編制報表、釋出下游資料集市(Data Marts)，以及支援自助式商業智慧等。

在技術實現上，主流採用MPP無共享儲存架構，基於標準X86伺服器，可實現數百節點的擴充套件。其對外提供標準的SQL能力和ACID特性，整體計算效能可在一定程度上隨節點擴充套件可提升。

當然，隨著資料在企業內角色愈發重要，對其分析的要求不斷提高，例如，隨著資料規模擴大，對資料承載能力(容量、算力)的要求也不斷增大，數倉架構的擴充套件能力面臨考驗，規模的擴充套件會面臨大量資源的投入，但硬體資源缺乏彈性，會導致高峰時資源不足，低谷時資源閒置浪費問題。針對資料型別，也不再侷限於結構化資料，更多半結構化、非結構化資料需要被利用起來，傳統的資料倉儲架構面臨諸多的挑戰，只能擴充套件上百節點的MPP架構快撐不住了。

3.、開放自由階段：資料湖(Data Lake)

相比於資料倉儲，資料湖是一種不斷演進中、可擴充套件的大資料儲存、處理、分析的基礎設施。它就像一個大型倉庫，可以儲存任何形式(包括結構化和非結構化)和任何格式(包括文字、音訊、影片和影像)的原始資料，資料湖通常更大，儲存成本也更為廉價，結合先進的資料科學與機器學習技術，能提供預測分析、推薦模型等能力。

資料倉儲中，資料儲存的結構與其定義的schema是強匹配的，也就是先建模再使用，簡單點說，資料倉儲就像是一個大型圖書館，裡面的資料需要按照規範放好，你可以按照類別找到想要的資訊，儲存在倉庫中都是結構化資料，可以直接消費。

而資料湖儲存其中的資料不需要滿足特定的schema，資料湖也不會嘗試去將特定的schema施行其上，任何格式的資料都可以扔進資料湖。資料使用通常會在讀取資料的時候解析schema(schema-on-read)，當處理相應的資料時，將轉換施加其上，也就是說，資料湖對於入湖的資料不做任何規範和約束，只有在於使用時才定義儲存格式以便分析使用。

下面這張圖形象的表達了資料倉儲和資料湖的區別，資料倉儲有點像“計劃經濟”，而資料湖則是“市場經濟”。

基於以上的特點，業界一般都會認為資料倉儲成長性較好，適合於成熟規模型企業使用，因為規範化講究的是一個規模效益。資料湖靈活性較好，更適用於初創型企業使用，如下圖所示：

可以看到，資料湖和資料倉儲都有各自的優勢和不足，但不難發現，二者在某些層面是非常互補的，於是乎，2020年，大資料DataBricks公司首次提出了湖倉一體(Data Lakehouse)概念，希望將資料湖和資料倉儲技術合而為一。

此概念一出各路雲廠商紛紛跟進，2021年，這個概念爬上了Gartner曲線，在國內火了起來，各種湖倉一體的產品也冒出來了，無論是國外的，阿里的，華為的，開源的等等。

無論是資料湖，還是湖倉一體，看起來都很美好，不可否認它們代表了一種技術趨勢，但這些老外傳過來的東西，其宣揚的那些特性，對你的企業真的有用嗎?

“不要說湖倉一體了，就連資料湖技術，大多企業也沒怎麼玩明白，即使你已經擁有了它。” 這是我當前給出的答案。

為什麼要這麼說?

2年前自己去參加一個展會，有人在那介紹資料湖的產品，我就問講解員資料湖相對資料倉儲帶來了什麼增益價值?能否舉個讓人信服的例子?然後講解員巴拉巴拉的說了幾個例子，我問這不是傳統資料倉儲乾的事情嗎?然後他就說，這是hadoop，它就是資料湖。

Hadoop就是資料湖?

有人解釋國外習慣把hadoop叫做資料湖，而我們國內一般叫做大資料平臺，雖然名字不一樣，但其實說得是同一回事，因此其實我們早就一步走上了技術巔峰，可能連我們自己都不知道呢?

不知道什麼時候開始，很多企業的PPT裡開始把大資料平臺改稱了資料湖，也許資料湖這個名字比較通俗易懂吧，老闆們也喜歡用，似乎是一瞬間，大家的大資料平臺一下全部升級成為了資料湖。

遺憾的是，雖然大多企業的hadoop從技術角度來講可以叫作資料湖，但從業務的角度講，只是披著資料湖外衣的更大型的資料倉儲而已。

大多企業從來沒有像谷歌、網際網路大廠一樣發揮出過hadoop蘊含的資料湖的那些獨特價值，比如將非結構化資料，結構化資料，半結構化資料全部扔到hdfs上統一管理，然後資料科學家能夠所見即所得的進行分析使用。

事實上，大多企業只是把hadoop的hive當成了一個能處理海量資料的廉價資料倉儲，用以替代跑不動的可能還貴得要死的MPP，但我們還在用MPP時代使用資料倉儲的方式使用著資料湖，從來沒有變更過，好比我雖然買了一輛具備自動駕駛的汽車但從來沒有使用過自動駕駛功能一樣。

下面這張表說明了一切，你可以看看資料湖相對資料倉儲的11個方面的不同，然後想想我們家的hadoop資料湖跟這裡提到的資料湖是不是同一個物種?

那麼，造成這種現象的深層次原因是什麼呢?

我想主要跟使用者的背景和業務有關，跟技術無關。

第一是原生資料的問題。資料湖緣起網際網路，強調從非結構化資料中挖掘價值，比如谷歌使用MR計算引擎來處理非結構化的網頁，而現在使用Hadoop的企業大多可是傳統行業，本身沒有什麼非結構化資料，或者利用非結構化資料的業務驅動還不夠，大家只是希望利用資料湖的分散式計算框架來提升海量結構化資料的處理能力，這讓資料湖喪失了獨特價值。

第二是生產關係的問題。雖然不少企業擁有各種型別的資料，但要匯聚這些資料到統一資料湖首先得打破資料孤島，這對很多企業是巨大的挑戰，因為企業資料治理體系不是那麼容易建立。

理論上講，一個公司有搞綜合的，有搞財務的，有搞人力的，也有搞供應鏈的，不可能不需要儲存和使用非結構化資料，但現實情況是，即使企業有了資料湖，很多領域對各種非結構資料的儲存和處理其實還在用豎井的方式解決，比如構建獨立的文件庫，大家並沒有什麼入湖共享的意識。

前段時間我寫過一篇資料編織的文章，提到獲取完整的後設資料是資料編織的前提，但如果連連線各個資料來源的後設資料權力都沒有，談何資料編織，而資料湖的困境也是一樣的。

下面這張圖體現出資料湖是一個生態，但生態的打造不是在一個空地上挖一個池子就可以的。

有人說資料湖的核心問題是資料太多缺乏治理導致變成了資料沼澤，我說你太杞人憂天了，資料湖的核心問題是湖水太少了，資料治理首先要解決的是有沒有水、能不能把水引進來的問題。

第三是資料應用的問題。資料湖的最大推動者是亞馬遜等一眾網際網路大廠，這些網際網路的數字原生企業，其本身的數字化水平是非常高的，面對激烈的市場競爭，早就不再滿足於資料倉儲那種按部就班的單一資料的供給模式，網際網路大廠的資料科學傢俱備足夠的能力從資料湖中獲取原始資料、解析資料、處理資料直到挖掘資料，所見即所得是資料科學家探索資料所需要的。

但在傳統企業裡，資料分析師能夠基於資料倉儲提供的結構化資料進行自助取數、分析和挖掘已經是非常牛逼了，大多還是處於被動的資料供給模式，資料湖所倡導的靈活性對他們來說是沒有什麼意義的，這是由企業的性質和所處的階段決定的。

由此可以看到，資料湖相對資料倉儲擁有的那些獨特優勢，無論是對於非結構資料的儲存處理還是分析的靈活性等等，在大多企業是沒有條件執行的，或者說沒有足夠的業務驅動力，大多企業的使用者眼裡只有支援SQL的HIVE資料倉儲，資料湖對他們來講就是更大號的資料倉儲，比如企業90%的資料都是以HIVE表的形式存在的，所有的需求都不需要用到資料湖的獨特技術。

現在，hadoop這種資料湖技術已經逐步不能滿足網際網路大廠的要求了，因為hadoop實時性太差，無法滿足資料湖“對於業務系統中的資料都會儲存一份“一模一樣”的完整複製”的保真性要求。

這意味著資料寫入資料湖的時候要保證ACID，要高效支援upsert /delete歷史資料，要能容忍資料頻繁匯入檔案系統上產生的大量的小檔案，顯然hadoop這種資料湖技術不夠看了，在這種背景下，Delta、iceberg和hudi等新技術逐漸冒出來了，但它們到底是屬於資料倉儲的升級，還是屬於資料湖的升級，那就見仁見智了，我們既可以說資料倉儲需要支撐實時資料，也可以說資料湖需要確保所有的資料能及時的扔進資料湖且跟原系統一模一樣。

但脫離了hadoop體系的新資料湖技術，大多企業估計也很難買單，一方面實時技術有很多替代品，即使不是那麼完美，另一方面也有保護原有投資的需要。

明白了這一點，我們再回過頭來分析湖倉一體，自然會得到你需要的答案，我不否認湖倉一體是很好的技術，代表了某種趨勢，但回到每個企業每個個體，我們還是要回到業務原點去思考問題，雖然技術可以適當領先業務半步，但步子不要一下子邁得太大，還得因地制宜，諸如阿里提供的湖倉一體解決方案應該也有市場，因為能解決異構資料平臺的資料共享和同步問題，至少能保護企業的原有投資，但賣點不在湖倉一體本身。

最後一句話總結：資料倉儲永不過時，資料湖任重而道遠，湖倉一體就先讓子彈飛一會兒吧。

參考文獻：

【1】 韓鋒頻道 湖倉一體2.0：終局之選!