資料倉已死？未來會屬於資料湖嗎？
前兩天，我詳細剖析了一下這兩天圈內很火的資料建模帖子。指出來帖子裏大廠小哥“只見寬表不見建模”的核心原因是整個資料圈的核心邏輯變了，然後就引起了建模羣裏一幫人在瘋狂吐槽。
為啥吐槽？因為我們知道，這再也不是以前資料至上、工程為先的俄羅斯方塊遊戲了，而是客戶至上、業務為先的神廟逃亡遊戲。
雖然也有大佬高屋建瓴，指點江山，侃侃而談。
但是絕大多數企業的資料倉庫工程師，究竟還是淪落到拉寬表的境地。
玩法變了
早些年，業務變化還沒那麼頻繁，戰略是一年定一次，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 體系，準實時、不用複雜的分層建設、不用擔心任務跑不完、業務要什麼可以快速給出去！
市場變了
你說，這個東西是不是很牛？對你來說是不是很有價值？
——是的，不僅對你有價值，對資本市場也很有價值。美國有個公司叫Snowflake，直接估值過 1000 億美，遠超其他各大獨角獸。
除了 Snowflake 之外，資料湖的老選手亞馬遜 AWS 也是一路狂奔，早就有了自己的 OLAP 產品 AWS Athena ，跟自己的資料湖雙劍合併，推出了“湖倉一體”的概念。阿里早就做了此方面的嘗試，阿里的OSS大家應該都熟悉，但是你可能不知道，阿里基於 OSS 的存儲還整了一個雲原生資料湖體系，其中不僅包括了資料湖，還有基於資料湖的 OLAP 產品 DLA ，原因自然是看重了它的市場潛力
其他選擇也有，目前開源的資料湖有江湖人稱“資料湖三劍客”的 Delta Lake、IceBerg 和 Hudi。
上面的 OLAP、查詢引擎可以用 Kylin、Presto，Spark SQL、Impala等。這裏着重強調一下 Kylin ，不僅是因爲這是中國團隊開源的產品，更重要的是這我們大數據工程師熟，Kylin現在已經不侷限於傳統的Cube，基本上已經把Cube當成Index和存儲了，現在已經支持明細查詢和實時查詢的功能。
爲了幫大家探路，我找到了 Kylin 創始團隊的史少鋒大佬，要來了幾份半公開的資料，大家自己收着就行哈。
雲上資料湖 + Kylin 的這個產品叫 Kyligence Cloud，從上圖可以看到它的位置，就在湖之上，視覺化之下。因爲是直接從湖裏取數建 Cube，然後直接展示。這省了多少事兒啊！
那構建 Cube 不得要時間麼？怎麼說呢，第一次建 Cube，的確要一些時間，但是之後就不需要那麼長時間了，因爲資料可以增量加載。
因爲資料湖的特性，它可以告訴 Kylin 在從上次消費後，有哪些 Partition 發生了修改，這樣 Kylin 只要刷新特定的 Partition 就可以了。而且資料湖可以只拉取變化的資料，使得增量修改 Cube 變得可行。如果有查詢不能被 Cube 滿足，那麼直接下壓查詢資料湖也是支持的，只是性能上會降級到普通水平。
這樣，整個資料流，從產生到展示，基本上能控制在半個小時以內。什麼，還嫌慢？跟 ClickHouse 比起來，的確是慢一些，我也不是過來跟你掰扯那個工具好，誰的併發量高、速度快。
但是咱說句良心話，你真的想成爲一個整天“拉寬表”的 SQL Boy 嗎？我之前也寫過一篇 ClickHouse 的文章，那個快則快矣，小心反噬啊。
我們知道，OLAP 其實基本分爲三個發展方向：MOLAP、ROLAP 和 HOLAP 。Kylin 是 MOLAP，ClikcHouse 是 ROLAP，這兩個產品，猶如倚天屠龍。ClickHouse就是那倚天，追求極致的快，Kylin就是那屠龍，厚重而沉穩。
如果倚天屠龍能合二爲一，各自取長補短，那簡直無敵了！期待Kylin和ClickHouse團隊的合作，推出更牛的產品，讓我們的工作更輕鬆一些。
