文：大資料架構師
源：數倉已死？資料湖當立！

前兩天，我詳細剖析了一下這兩天脈脈上很火的資料建模帖子。指出來帖子裡百度小哥“只見寬表不見建模”的核心原因是整個資料圈的核心邏輯變了。

然後就引起了建模群裡一幫人在瘋狂吐槽。

也有大廠的數倉大佬高屋建瓴，指點江山，侃侃而談。

為啥吐槽？因為我們知道，這再也不是以前資料至上、工程為先的俄羅斯方塊遊戲了，而是客戶至上、業務為先的神廟逃亡遊戲。

但是絕大多數企業的資料倉儲工程師，究竟還是淪落到拉寬表的境地。

玩法變了

早些年，業務變化還沒那麼頻繁，戰略是一年定一次，KPI 政策是一年釋出一次。

我們有充足的時間去規劃、業務建模、領域建模、邏輯建模、物理建模、驗證模型。如同那時候的愛情，車馬慢，一生只夠愛一人。

那時候行業的玩法基本一致，所以也有了 FSLDM 這種經典資料模型可以套用。一個模型搞定一個行業有沒有？

但是現在，誰家的玩法跟別人一毛一樣？沒有！就算是短影片界的兩個直接競爭對手--抖音和快手，都是那麼迥然不同的邏輯：

一個偏向演算法推薦，一個偏向社交關係。

更不用說現在火熱的社群團購，都在搶佔市場，業務模式每天都在變。

我自己都不敢相信，我會建設一個能夠支援 KPI 政策一個月一調整的 KPI 數倉+核算體系！

玩法真的變了！這世道變了！

建模變了

在這種邊開飛機邊換髮動機的時代，傳統數倉規規矩矩建設的邏輯就不好使了，開始朝著非常詭異的方向發展。

一個方向 ，是規模大、技術強、業務趨於穩定的企業，如阿里、美團的固有業務，他們開始嘗試一種全新的建模理念。

他們的主題域劃分根本不遵循老一套的“中性、通用”，而是“ 個性、專用 ”。所以他們採用的是按業務流程劃分主題域，因為這樣才能更方便地支撐上面的業務指標體系。這樣弄，上哪提煉一個通用的模型去啊？

在建模的時候，傳統建模，DWD 層必須是正規化建模，而且一般不對外提供服務。如果各部門需要明細資料，則各自建立 DM 解決。

而現在這些大廠的建模方式，則是儘可能壓縮正規化建模的範圍，擴大維度建模的深度。以結構化指標體系開道，用維度模型向下不斷穿透，直到 DWD 層。

是的，DWD 層也是維度建模。所有 ID 統一、程式碼轉換、資料打平的事情放在哪裡做？ETL 裡做。

哦，不！應該改叫 ELT 了。先 Load ，再 Transformation 。因為超大量的資料輸入，我們必須首先解決資料吞吐量的問題。

另一個方向 ，是那些創業公司或者大公司的新業務。這類場景的特點是業務一直在變，產品功能也在變，業務資料庫也在變。

在這種場景中傳統資料倉儲建設的邏輯完全失效。因為根本不可能有人能在這麼短的時間內，設計出一個能適應 2 週一次的迭代速度的資料倉儲模型。

所以他們選擇了簡單粗暴的拉寬表！

這就是脈脈上百度小哥瘋狂吐槽的根本原因。不是不去建模，而是根本 沒時間、沒條件給你建模 。

數倉已死？

那種業務趨於穩定的大廠畢竟是少數，更多的情況是創業公司、業務不斷試錯、調整的小廠。

在業務 1 個月變一次方向、產品 2 周迭代一次、業務資料庫不斷更新還沒人告訴你的地獄模式下，基本上宣告了資料倉儲的死亡！

這就像是在玩遊戲。

以前是玩俄羅斯方塊，我們得精心設計好，每一塊磚都要放在合理的地方，壘得整整齊齊，等待那一根棍子的到來。

而現在，是在玩神廟逃亡，操作方式同樣都是上下左右，但是你根本沒辦法想合理、結構、佈局，稍微遲疑一些，就被怪獸咬到屁股了。

而對於那些業務日趨穩定的大廠，資料倉儲同樣也有巨大的困擾。就像新能源汽車車主總有里程焦慮一樣，幾乎所有的離線數倉工程師都害怕任務失敗。

任務失敗就意味著報表出不來，就意味著運營的白眼和扣績效。

另外，我們的增量入庫方案，由於資料遲到、業務邏輯複雜等各種原因，慢慢地變得越來越複雜。以至於一些小公司乾脆直接每天全量，這導致資料延遲更加嚴重。

貌似一切正常的離線數倉 T+1 延遲，成為壓死數倉的最後一根稻草。因為業務部門已經不能滿足於看昨天的資料了。

“我們並沒有做錯什麼,但不知為什麼,我們輸了”，諾基亞 CEO 的聲音彷彿縈繞耳邊。

什麼？你說 Lambda 架構可以滿足？是，這樣是能出數，但是你拿實時和離線兩個結果對比一下試試看？

你現在告訴我，拿什麼拯救已然過了 網際網路淘汰年齡 的資料倉儲？

資料湖當立

當網際網路 HR 對著年齡超限的資料倉儲拿出辭退信的時候，另一個 HR 給一個 09 年才出生的小娃娃發出了 Offer 。

它就是 資料湖 。

它爹是 Pentaho 的 CTO James Dixon。James 創造它的時候，也沒想到這傢伙能變得這麼牛掰。他當初只是想把磁帶上儲存的所有資料統統倒進一個地方，方便任意探索。

而現在的資料湖，已經成長為一個巨無霸！憑藉著基於快照的設計方式、滿足快照隔離、優秀的原子性、新後設資料等巧妙設計，資料湖擁有了支援批流一體、完美增量入庫、入庫即可計算等特性。

這些特性意味著什麼？

對於 ETL 工程師來說，意味著資料湖沒有 T+1 ！太令人興奮了！

但是更興奮的是大資料架構師，資料湖不僅意味著什麼資料都往裡扔，更意味著一種 新架構的誕生 ！

一個萬能的架構，能夠滿足演算法工程師隨意淘換原始資料的架構，能夠滿足大資料工程師隨時拉一張準實時寬表出來的架構，能夠滿足準實時資料增量接入和即時分析的架構，能夠讓大資料工程師不用早起看任務是否失敗的架構。

架構變了

Kappa 架構中，最無奈的其實是 Kafka ，生把一個 MQ 整成了資料庫。這也直接導致了 Kappa 架構無法儲存海量資料的弊端。

但是這個弊端，資料湖可以解決啊。把 Kafka 改成資料湖之後，問題解決了。 Kafka 也終於歇了口氣，可以卸下莫名其妙得到的“資料庫”頭銜。

而傳統數倉的“資料孤島問題，在資料湖面前，瞬間蕩然無存。因為資料湖本來就是大雜燴，什麼都往裡裝呀！

而且現在已經有各種元件與資料湖產品進行對接了。資料湖真的變成了一個湖！

這個架構簡直了！

你可以用資料處理元件，從湖裡抽數出來，抽完直接做成寬表扔給運營。

也可以寫一個 DAG ，資料規整、打通之後扔其他資料庫裡。

對資料非常瞭解的人，可以利用查詢元件，直接到資料湖裡查資料。

演算法工程師同樣可以直接對接資料湖，從湖裡撈原始資料投餵給演算法，訓練模型。

最關鍵的一點，OLAP 引擎也能直接對接資料湖！

這個就厲害了！換句話說，我們可以依據這個構建一個超級無敵的 OLAP 體系，準實時、不用複雜的分層建設、不用擔心任務跑不完、業務要啥可以快速給出去！

唉，你以為我在聳人聽聞，卻不知已然是事實。數倉人的前路該往哪個方向？

說實話，這個問題我不知道怎麼回答。時代在變遷，技術在進步，跟不上就必然會淘汰。

唉，數倉不知道死沒死，但是資料湖已經來了。大家努力吧，加油！

你怎麼看？