展開
 找回密碼
 立即注冊

QQ登錄

只需一步,快速開始

門戶 消費品 IT服務 查看內容
  • QQ空間
  • 回復
  • 收藏

數據倉庫被淘汰了?都怪數據湖

一任浮萍風吹雨 2021-3-29 02:50 879人圍觀 IT服務

文:大數據架構師
源:數倉已死?數據湖當立!

前兩天,我詳細剖析了一下這兩天脈脈上很火的數據建模帖子。指出來帖子里百度小哥“只見寬表不見建?!钡暮诵脑蚴钦麄€數據圈的核心邏輯變了。

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

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

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

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

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

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

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

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

你怎么看?


鮮花

握手

雷人

路過

雞蛋
?