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

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

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

?

?

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

?

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

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

玩法變了

早些年，業務變化還沒那么頻繁，戰略是一年定一次，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 體系，準實時、不用復雜的分層建設、不用擔心任務跑不完、業務要啥可以快速給出去！

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

?

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

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

你怎么看？

總結

以上是生活随笔為你收集整理的数据仓库被淘汰了？都怪数据湖的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。