數(shù)倉(cāng)已死？數(shù)據(jù)湖當(dāng)立！

前言

前兩天，我詳細(xì)剖析了一下這兩天脈脈上很火的數(shù)據(jù)建模帖子。指出來(lái)帖子里百度小哥“只見(jiàn)寬表不見(jiàn)建模”的核心原因是整個(gè)數(shù)據(jù)圈的核心邏輯變了。

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

也有大廠的數(shù)倉(cāng)大佬高屋建瓴，指點(diǎn)江山，侃侃而談。

為啥吐槽？因?yàn)槲覀冎?，這再也不是以前數(shù)據(jù)至上、工程為先的俄羅斯方塊游戲了，而是客戶至上、業(yè)務(wù)為先的神廟逃亡游戲。

但是絕大多數(shù)企業(yè)的數(shù)據(jù)倉(cāng)庫(kù)工程師，究竟還是淪落到拉寬表的境地。

大清都亡了，你上哪找辮子去啊？

玩法變了

我們有充足的時(shí)間去規(guī)劃、業(yè)務(wù)建模、領(lǐng)域建模、邏輯建模、物理建模、驗(yàn)證模型。如同那時(shí)候的愛(ài)情，車(chē)馬慢，一生只夠愛(ài)一人。

那時(shí)候行業(yè)的玩法基本一致，所以也有了 FSLDM 這種經(jīng)典數(shù)據(jù)模型可以套用。一個(gè)模型搞定一個(gè)行業(yè)有沒(méi)有？

但是現(xiàn)在，誰(shuí)家的玩法跟別人一毛一樣？沒(méi)有！就算是短視頻界的兩個(gè)直接競(jìng)爭(zhēng)對(duì)手--抖音和快手，都是那么迥然不同的邏輯：

一個(gè)偏向算法推薦，一個(gè)偏向社交關(guān)系。

更不用說(shuō)現(xiàn)在火熱的社區(qū)團(tuán)購(gòu)，都在搶占市場(chǎng)，業(yè)務(wù)模式每天都在變。

我自己都不敢相信，我會(huì)建設(shè)一個(gè)能夠支持 KPI 政策一個(gè)月一調(diào)整的 KPI 數(shù)倉(cāng)+核算體系！

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

建模變了

在這種邊開(kāi)飛機(jī)邊換發(fā)動(dòng)機(jī)的時(shí)代，傳統(tǒng)數(shù)倉(cāng)規(guī)規(guī)矩矩建設(shè)的邏輯就不好使了，開(kāi)始朝著非常詭異的方向發(fā)展。

一個(gè)方向，是規(guī)模大、技術(shù)強(qiáng)、業(yè)務(wù)趨于穩(wěn)定的企業(yè)，如阿里、美團(tuán)的固有業(yè)務(wù)，他們開(kāi)始嘗試一種全新的建模理念。

他們的主題域劃分根本不遵循老一套的“中性、通用”，而是“個(gè)性、專用”。所以他們采用的是按業(yè)務(wù)流程劃分主題域，因?yàn)檫@樣才能更方便的支撐上面的業(yè)務(wù)指標(biāo)體系。這樣弄，上哪提煉一個(gè)通用的模型去啊？

在建模的時(shí)候，傳統(tǒng)建模，DWD 層必須是范式建模，而且一般不對(duì)外提供服務(wù)。如果各部門(mén)需要明細(xì)數(shù)據(jù)，則各自建立 DM 解決。

而現(xiàn)在這些大廠的建模方式，則是盡可能壓縮范式建模的范圍，擴(kuò)大維度建模的深度。以結(jié)構(gòu)化指標(biāo)體系開(kāi)道，用維度模型向下不斷穿透，直到 DWD 層。

是的，DWD 層也是維度建模。所有 ID 統(tǒng)一、代碼轉(zhuǎn)換、數(shù)據(jù)打平的事情放在哪里做？ETL 里做。

哦，不！應(yīng)該改叫 ELT 了。先 Load ，再 Transformation 。因?yàn)槌罅康臄?shù)據(jù)輸入，我們必須首先解決數(shù)據(jù)吞吐量的問(wèn)題。

另一個(gè)方向，是那些創(chuàng)業(yè)公司或者大公司的新業(yè)務(wù)。這類場(chǎng)景的特點(diǎn)是業(yè)務(wù)一直在變，產(chǎn)品功能也在變，業(yè)務(wù)數(shù)據(jù)庫(kù)也在變。

在這種場(chǎng)景中傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)建設(shè)的邏輯完全失效。因?yàn)楦静豢赡苡腥四茉谶@么短的時(shí)間內(nèi)，設(shè)計(jì)出一個(gè)能適應(yīng)?2 周一次的迭代速度的數(shù)據(jù)倉(cāng)庫(kù)模型。

所以他們選擇了簡(jiǎn)單粗暴的拉寬表！

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

數(shù)倉(cāng)已死？

那種業(yè)務(wù)趨于穩(wěn)定的大廠畢竟是少數(shù)，更多的情況是創(chuàng)業(yè)公司、業(yè)務(wù)不斷試錯(cuò)、調(diào)整的小廠。

在業(yè)務(wù) 1 個(gè)月變一次方向、產(chǎn)品 2 周迭代一次、業(yè)務(wù)數(shù)據(jù)庫(kù)不斷更新還沒(méi)人告訴你的地獄模式下，基本上宣告了數(shù)據(jù)倉(cāng)庫(kù)的死亡！

這就像是在玩游戲。

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

而現(xiàn)在，是在玩神廟逃亡，操作方式同樣都是上下左右，但是你根本沒(méi)辦法想合理、結(jié)構(gòu)、布局，稍微遲疑一些，就被怪獸咬到屁股了。

而對(duì)于那些業(yè)務(wù)日趨穩(wěn)定的大廠，數(shù)據(jù)倉(cāng)庫(kù)同樣也有巨大的困擾。就像新能源汽車(chē)車(chē)主總有里程焦慮一樣，幾乎所有的離線數(shù)倉(cāng)工程師都害怕任務(wù)失敗。

任務(wù)失敗就意味著報(bào)表出不來(lái)，就意味著運(yùn)營(yíng)的白眼和扣績(jī)效。

另外，我們的增量入庫(kù)方案，由于數(shù)據(jù)遲到、業(yè)務(wù)邏輯復(fù)雜等各種原因，慢慢的變得越來(lái)越復(fù)雜。以至于一些小公司干脆直接每天全量，這導(dǎo)致數(shù)據(jù)延遲更加嚴(yán)重。

貌似一切正常的離線數(shù)倉(cāng) T+1 延遲，成為壓死數(shù)倉(cāng)的最后一根稻草。因?yàn)闃I(yè)務(wù)部門(mén)已經(jīng)不能滿足于看昨天的數(shù)據(jù)了。

“我們并沒(méi)有做錯(cuò)什么,但不知為什么,我們輸了”，諾基亞 CEO 的聲音仿佛縈繞耳邊。

什么？你說(shuō) Lambda 架構(gòu)可以滿足？是，這樣是能出數(shù)，但是你拿實(shí)時(shí)和離線兩個(gè)結(jié)果對(duì)比一下試試看？

你現(xiàn)在告訴我，拿什么拯救已然過(guò)了互聯(lián)網(wǎng)淘汰年齡的數(shù)據(jù)倉(cāng)庫(kù)？

數(shù)據(jù)湖當(dāng)立

當(dāng)互聯(lián)網(wǎng) HR 對(duì)著年齡超限的數(shù)據(jù)倉(cāng)庫(kù)拿出辭退信的時(shí)候，另一個(gè) HR 給一個(gè) 09 年才出生的小娃娃發(fā)出了 Offer 。

它就是數(shù)據(jù)湖。

它爹是 Pentaho 的 CTO James Dixon。James 創(chuàng)造它的時(shí)候，也沒(méi)想到這家伙能變得這么牛掰。他當(dāng)初只是想把磁帶上存儲(chǔ)的所有數(shù)據(jù)統(tǒng)統(tǒng)倒進(jìn)一個(gè)地方，方便任意探索。

而現(xiàn)在的數(shù)據(jù)湖，已經(jīng)成長(zhǎng)為一個(gè)巨無(wú)霸！憑借著基于快照的設(shè)計(jì)方式、滿足快照隔離、優(yōu)秀的原子性、新元數(shù)據(jù)等巧妙設(shè)計(jì)，數(shù)據(jù)湖擁有了支持批流一體、完美增量入庫(kù)、入庫(kù)即可計(jì)算等特性。

這些特性意味著什么？

對(duì)于 ETL 工程師來(lái)說(shuō)，意味著數(shù)據(jù)湖沒(méi)有 T+1 ！太令人興奮了！

但是更興奮的是大數(shù)據(jù)架構(gòu)師，數(shù)據(jù)湖不僅意味著什么數(shù)據(jù)都往里扔，更意味著一種新架構(gòu)的誕生！

一個(gè)萬(wàn)能的架構(gòu)，能夠滿足算法工程師隨意淘換原始數(shù)據(jù)的架構(gòu)，能夠滿足大數(shù)據(jù)工程師隨時(shí)拉一張準(zhǔn)實(shí)時(shí)寬表出來(lái)的架構(gòu)，能夠滿足準(zhǔn)實(shí)時(shí)數(shù)據(jù)增量接入和即時(shí)分析的架構(gòu)，能夠讓大數(shù)據(jù)工程師不用早起看任務(wù)是否失敗的架構(gòu)。

架構(gòu)變了

Kappa 架構(gòu)中，最無(wú)奈的其實(shí)是 Kafka ，生把一個(gè) MQ 整成了數(shù)據(jù)庫(kù)。這也直接導(dǎo)致了 Kappa 架構(gòu)無(wú)法存儲(chǔ)海量數(shù)據(jù)的弊端。

但是這個(gè)弊端，數(shù)據(jù)湖可以解決啊。把 Kafka 改成數(shù)據(jù)湖之后，問(wèn)題解決了。?Kafka 也終于歇了口氣，可以卸下莫名其妙得到的“數(shù)據(jù)庫(kù)”頭銜。

而傳統(tǒng)數(shù)倉(cāng)的“數(shù)據(jù)孤島問(wèn)題，在數(shù)據(jù)湖面前，瞬間蕩然無(wú)存。因?yàn)閿?shù)據(jù)湖本來(lái)就是大雜燴，什么都往里裝呀！

而且現(xiàn)在已經(jīng)有各種組件與數(shù)據(jù)湖產(chǎn)品進(jìn)行對(duì)接了。數(shù)據(jù)湖真的變成了一個(gè)湖！

這個(gè)架構(gòu)簡(jiǎn)直了！

你可以用數(shù)據(jù)處理組件，從湖里抽數(shù)出來(lái)，抽完直接做成寬表扔給運(yùn)營(yíng)。

也可以寫(xiě)一個(gè) DAG ，數(shù)據(jù)規(guī)整、打通之后扔其他數(shù)據(jù)庫(kù)里。

對(duì)數(shù)據(jù)非常了解的人，可以利用查詢組件，直接到數(shù)據(jù)湖里查數(shù)據(jù)。

算法工程師同樣可以直接對(duì)接數(shù)據(jù)湖，從湖里撈原始數(shù)據(jù)投喂給算法，訓(xùn)練模型。

最關(guān)鍵的一點(diǎn)，OLAP 引擎也能直接對(duì)接數(shù)據(jù)湖！

這個(gè)就厲害了！換句話說(shuō)，咱可以依據(jù)這個(gè)構(gòu)建一個(gè)超級(jí)無(wú)敵的 OLAP 體系，準(zhǔn)實(shí)時(shí)、不用復(fù)雜的分層建設(shè)、不用擔(dān)心任務(wù)跑不完、業(yè)務(wù)要啥可以快速給出去！

市場(chǎng)變了

你說(shuō)，這個(gè)東東是不是很牛？對(duì)你來(lái)說(shuō)是不是很有價(jià)值？

是的，不僅對(duì)你有價(jià)值，對(duì)資本市場(chǎng)也很有價(jià)值。美國(guó)有個(gè)公司叫Snowflake，好家伙，直接估值過(guò) 1000 億美金！??！PS 遠(yuǎn)超其他各大獨(dú)角獸。

除了 Snowflake 之外，數(shù)據(jù)湖的老選手亞馬遜 AWS 也是一路狂奔，早就有了自己的 OLAP 產(chǎn)品 AWS Athena ，跟自己的數(shù)據(jù)湖雙劍合并，推出了“湖倉(cāng)一體”的概念。

當(dāng)然，這里面肯定也少不了中國(guó)隊(duì)的身影，首當(dāng)其沖的就是阿里系了。阿里的 OSS 大家應(yīng)該都挺熟悉的，這個(gè)存儲(chǔ)便宜的要死。

但是你可能不知道，阿里基于 OSS 的存儲(chǔ)還整了一個(gè)云原生數(shù)據(jù)湖體系，其中不僅包括了數(shù)據(jù)湖，還有基于數(shù)據(jù)湖的 OLAP 產(chǎn)品 DLA ！

當(dāng)然啊，這個(gè)價(jià)錢(qián)嘛，嘿嘿，你懂的。

其他選擇也有哈。目前開(kāi)源的數(shù)據(jù)湖有江湖人稱“數(shù)據(jù)湖三劍客”的 Delta Lake、IceBerg 和 Hudi。

上面的 OLAP、查詢引擎可以用 Kylin、Presto，Spark SQL、Impala等。

這里著重強(qiáng)調(diào)一下 Kylin 哈，不僅是因?yàn)檫@是中國(guó)團(tuán)隊(duì)開(kāi)源的產(chǎn)品，更重要的是這玩意我們大數(shù)據(jù)工程師熟啊~~~

而且，就算你不是大數(shù)據(jù)工程師，是傳統(tǒng)數(shù)倉(cāng)工程師，學(xué)習(xí)起來(lái)也不要太簡(jiǎn)單了！因?yàn)檫@玩意你可以理解為大數(shù)據(jù)環(huán)境下的 Cube。這不就是我們天天在干的活兒么？

當(dāng)然，Kylin現(xiàn)在已經(jīng)不局限于傳統(tǒng)的Cube，基本上已經(jīng)把Cube當(dāng)成Index和存儲(chǔ)了。之前分享過(guò)，Kylin現(xiàn)在已經(jīng)支持明細(xì)查詢和實(shí)時(shí)查詢的功能。

為了幫大家探路，我厚著臉皮找到了 Kylin 創(chuàng)始團(tuán)隊(duì)的史少鋒大佬，要來(lái)了幾份半公開(kāi)的資料。大家自己收著就行哈。

云上數(shù)據(jù)湖 + Kylin 的這個(gè)產(chǎn)品叫 Kyligence Cloud，從上圖可以看到它的位置，就在湖之上，可視化之下。因?yàn)槭侵苯訌暮锶?shù)建 Cube，然后直接展示。這省了多少事兒啊！

有哥們問(wèn)了，那構(gòu)建 Cube 不得要時(shí)間么？咋說(shuō)呢，第一次建 Cube，的確要一些時(shí)間。但是之后就不需要那么長(zhǎng)時(shí)間了，因?yàn)閿?shù)據(jù)可以增量加載。

因?yàn)閿?shù)據(jù)湖的特性，它可以告訴 Kylin 在從上次消費(fèi)后，有哪些 Partition 發(fā)生了修改。這樣 Kylin 只要刷新特定的 Partition 就可以了。而且數(shù)據(jù)湖可以只拉取變化的數(shù)據(jù)，使得增量修改 Cube 變得可行。如果有查詢不能被 Cube 滿足，那么直接下壓查詢數(shù)據(jù)湖也是支持的，只是性能上會(huì)降級(jí)到普通水平。

這樣，整個(gè)數(shù)據(jù)流，從產(chǎn)生到展示，基本上能控制在半個(gè)小時(shí)以內(nèi)。啥？你還嫌慢？

嗯，的確，跟 ClickHouse 比起來(lái)，的確是慢一些，我也不是過(guò)來(lái)跟你掰扯那個(gè)工具好，誰(shuí)的并發(fā)量高、速度快。

但是，哥們，咱說(shuō)句良心話，你真的想成為一個(gè)整天“拉寬表”的 SQL Boy 嗎？我之前也寫(xiě)過(guò)一篇 ClickHouse 的文章，那個(gè)快則快矣，但是小心反噬啊。

我們知道，OLAP 其實(shí)基本分為三個(gè)發(fā)展方向：MOLAP、ROLAP 和 HOLAP 。Kylin 是 MOLAP，ClikcHouse 是 ROLAP，這兩個(gè)產(chǎn)品，猶如倚天屠龍。ClickHouse就是那倚天，追求極致的快，Kylin就是那屠龍，厚重而沉穩(wěn)。

如果倚天屠龍能合二為一，各自取長(zhǎng)補(bǔ)短，那簡(jiǎn)直無(wú)敵了！期待Kylin和ClickHouse團(tuán)隊(duì)的合作，推出更牛的產(chǎn)品，讓我們的工作更輕松一些。

不過(guò)現(xiàn)在么，單純的 ClickHouse 只能算是辟邪。辟邪雖好，必先自宮啊。ClickHouse 用的多了，那咱練就的一手建模技巧，恐怕就要廢了！

你問(wèn)問(wèn)那些吐槽天天拉寬表的哥們，就知道其實(shí)哥們很悲觀。

結(jié)語(yǔ)

唉，你以為我在聳人聽(tīng)聞，卻不知已然是事實(shí)。數(shù)倉(cāng)人的前路該往哪個(gè)方向？

這是群里兄弟私信我的問(wèn)題。說(shuō)實(shí)話，這個(gè)問(wèn)題我不知道怎么回答。時(shí)代在變遷，技術(shù)在進(jìn)步，跟不上就必然會(huì)淘汰。

前幾天我在跑步機(jī)上看了《百鳥(niǎo)朝鳳》，人們喜歡西洋樂(lè)隊(duì)更甚于傳統(tǒng)的嗩吶。最后焦師傅賭氣吐血吹嗩吶，宛若鳳凰絕唱的時(shí)候，我心都碎了。

我是個(gè)老數(shù)倉(cāng)人。05 年實(shí)習(xí)的時(shí)候就在做建倉(cāng)建模的事情，真心覺(jué)得這是個(gè)手藝活兒。所以不管怎地，我都得找來(lái) Kylin 的資料，分享給大家。相比起其他工具，Kylin 還是更親近我們數(shù)倉(cāng)人一些的。

感興趣的可以戳【原文】直接去試用一下，反正又不要錢(qián)，領(lǐng)導(dǎo)問(wèn)起來(lái)也好解釋，研究新技術(shù)么。好歹給自己簡(jiǎn)歷上多寫(xiě)一句話啊。

唉，數(shù)倉(cāng)不知道死沒(méi)死，但是數(shù)據(jù)湖已經(jīng)來(lái)了。大家努力吧，加油！

擴(kuò)展閱讀：【6份數(shù)據(jù)湖資料+4份Kylin內(nèi)部解決方案、案例】，公眾號(hào)“大數(shù)據(jù)架構(gòu)師”后臺(tái)回復(fù)“數(shù)據(jù)湖”，轉(zhuǎn)發(fā)即可下載。

感謝閱讀，本次分享的內(nèi)容就結(jié)束了。本公眾號(hào)目前保持日更3000字，為你提供優(yōu)秀的數(shù)據(jù)領(lǐng)域的分享。

點(diǎn)擊名片關(guān)注大數(shù)據(jù)架構(gòu)師