從美團(tuán)外賣的數(shù)據(jù)倉(cāng)庫(kù)建設(shè)中，我學(xué)到了什么？
點(diǎn)擊藍(lán)色“有關(guān)SQL”關(guān)注我喲
加個(gè)“星標(biāo)”，天天與10000人一起快樂(lè)成長(zhǎng)
圖 | Lenis | Wagas
前兩天，轉(zhuǎn)載了美團(tuán)外賣的兩篇數(shù)據(jù)倉(cāng)庫(kù)文章。第一篇講他們的實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)建設(shè)，第二篇講離線數(shù)據(jù)倉(cāng)庫(kù)。兩篇文章都發(fā)人深思。于是，我花了點(diǎn)時(shí)間，拆解了各自的項(xiàng)目實(shí)現(xiàn)。
這是第二篇拆解，針對(duì)離線數(shù)據(jù)倉(cāng)庫(kù)，美團(tuán)外賣講述了他們的玩法。這篇感覺(jué)更接地氣，和傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)項(xiàng)目，貼合得更緊。換句話說(shuō)，這次的離線倉(cāng)庫(kù)，不僅對(duì)互聯(lián)網(wǎng)行業(yè)具有借鑒意義，對(duì)非互聯(lián)網(wǎng)行業(yè)，同樣也具有參考價(jià)值。
傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)，數(shù)據(jù)基建包括了 ETL, 建模和可視化。從數(shù)倉(cāng)范疇的概念上入手，美團(tuán)外賣的離線數(shù)倉(cāng)，也同樣是這些。但形式、落地與邏輯，稍有些擴(kuò)展。
比如，做傳統(tǒng)行業(yè)的數(shù)倉(cāng)工程師，都知道數(shù)據(jù)的組織與存儲(chǔ)，以關(guān)系型結(jié)構(gòu)化數(shù)據(jù)為基準(zhǔn)，以維度模型為擴(kuò)展。強(qiáng)烈的二維屬性已經(jīng)刻在我們腦子里。即使在二維中硬生生增加多維的擴(kuò)展模型，本質(zhì)上還是二維存儲(chǔ)。
但在互聯(lián)網(wǎng)業(yè)務(wù)中，比如美團(tuán)外賣。很多業(yè)務(wù)數(shù)據(jù)開(kāi)始有了離散的結(jié)構(gòu)。就好比日志。一個(gè)用戶的訂單，來(lái)來(lái)回回有多種增刪菜品的組合。這樣的行為數(shù)據(jù)，需要入庫(kù)，對(duì)于關(guān)系型數(shù)據(jù)庫(kù)，極為不便處理。
再舉一個(gè)例子，用戶與商家，用戶與用戶之間的評(píng)論，又是離散的。這樣一個(gè)主題帖，就像一棵樹(shù)結(jié)構(gòu)，最好的辦法就是將整棵樹(shù)都存起來(lái)。
綜合美團(tuán)外賣的業(yè)務(wù)，可以將數(shù)據(jù)分為兩部分，一部分是事務(wù)性關(guān)系型業(yè)務(wù)數(shù)據(jù)；另一部分是離散結(jié)構(gòu)，半結(jié)構(gòu)化的業(yè)務(wù)數(shù)據(jù)，比如評(píng)論，用戶行為日志等。
架構(gòu)
與上篇實(shí)時(shí)數(shù)倉(cāng)一樣，這次的離線數(shù)倉(cāng)，也是先從業(yè)務(wù)架構(gòu)入手分析。
美團(tuán)的業(yè)務(wù)圖，做得十分清爽。每個(gè)業(yè)務(wù)鏈路，規(guī)劃的都很明晰，一目了然。從用戶下單，商戶上單，騎手接單配送，銷售運(yùn)營(yíng)，方方面面都考慮在了數(shù)據(jù)這條生態(tài)鏈上。
業(yè)務(wù)架構(gòu)清晰了，數(shù)據(jù)架構(gòu)自然也就跟上來(lái)了。
在四個(gè)數(shù)據(jù)層，層與層之間的數(shù)據(jù)交互，都有不同的工具實(shí)現(xiàn)。正因工具多變，監(jiān)控這些工具的數(shù)據(jù)流是否正常，也是大事。所以，數(shù)據(jù)流及其流監(jiān)控手段，還需要加在這幅全景圖中。比如 Sqoop, Flume, 以及傳統(tǒng)的 ETL 工具。
這里值得關(guān)注的是，美團(tuán)將大量的 Hive ETL 工作都轉(zhuǎn)移到了 Spark 上面。由此可見(jiàn)，將來(lái)的趨勢(shì)，必將給與 Spark 更多機(jī)會(huì)。那么 Spark 與 Hive 相比，會(huì)有哪些明顯的優(yōu)勢(shì)呢？文中指出，至少有 3 個(gè)：
算子豐富，如果是用 Spark 計(jì)算庫(kù)來(lái)說(shuō)，那是真的豐富。比如機(jī)器學(xué)習(xí)算法，HQL 毫無(wú)優(yōu)勢(shì)。
緩存中間集，不用像 Hive一樣，每次都利用硬盤來(lái)緩存，是 Spark 最大的優(yōu)勢(shì)。
資源復(fù)用，申請(qǐng)的計(jì)算資源可以重復(fù)利用。這先按下不表，因?yàn)槲乙矝](méi)理解，這優(yōu)勢(shì)的本質(zhì)，在哪里。
轉(zhuǎn)型
美團(tuán)從傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)過(guò)度到現(xiàn)代互聯(lián)網(wǎng)主流數(shù)據(jù)倉(cāng)庫(kù)設(shè)計(jì)，經(jīng)歷了很長(zhǎng)的路程。那么在這些歷程中，哪些是關(guān)鍵點(diǎn)，為什么會(huì)做出如此的技術(shù)選型？看看美團(tuán)怎么說(shuō)。
剛開(kāi)始，2016年以前，美團(tuán)業(yè)務(wù)量不大，但競(jìng)爭(zhēng)激烈。為了配合業(yè)務(wù)，堆人完成開(kāi)發(fā)。造成的局面一度尷尬：整體開(kāi)發(fā)效率低；統(tǒng)計(jì)口徑不一；垂直切分技術(shù)資源，造成人力浪費(fèi)。
來(lái)看下當(dāng)時(shí)的美團(tuán)技術(shù)架構(gòu)：
分層也很明晰：ODS\明細(xì)\聚合\主題\應(yīng)用。?
ODS層, 這里特別說(shuō)明下。從各個(gè)數(shù)據(jù)源匯總過(guò)來(lái)的數(shù)據(jù)，都會(huì)先落在ODS層，有一定的清洗，意味著數(shù)據(jù)有篩選，更干凈，更符合標(biāo)準(zhǔn)格式。
可以看到美團(tuán)數(shù)倉(cāng)1.0的分層，是以總部+城市來(lái)展開(kāi)的。這種分層，造成的重復(fù)計(jì)算是毋庸置疑的。很多計(jì)算指標(biāo)都是重合的，總部和城市本身就是地區(qū)維度的上下層級(jí)關(guān)系，完全沒(méi)必要分開(kāi)。所以這種分層必須按照業(yè)務(wù)重新劃分。
于是美團(tuán) 2.0 時(shí)代就改變了：
這回，就徹底把分層做足了。按照應(yīng)用來(lái)劃分層次，并且在每個(gè)層次上又再分層。
其實(shí)這里有個(gè)很重要的轉(zhuǎn)型時(shí)間點(diǎn)。并不是一上來(lái)就要精細(xì)化開(kāi)發(fā)，把每個(gè)主題都安排的妥妥當(dāng)當(dāng)。還要看業(yè)務(wù)發(fā)展的勢(shì)態(tài)。
業(yè)務(wù)早期，穩(wěn)定性和持久性，還沒(méi)有突破，過(guò)早進(jìn)入精細(xì)化數(shù)倉(cāng)建設(shè)，是不合理的。此時(shí)要做的事情，完全是輔助業(yè)務(wù)的開(kāi)展，在沒(méi)有準(zhǔn)確供給業(yè)務(wù)所需數(shù)據(jù)時(shí)，就要上一些高大上的數(shù)倉(cāng)指標(biāo)體系建設(shè)，那是浪費(fèi)資源。
所以，數(shù)倉(cāng)的建設(shè)還要圍繞著業(yè)務(wù)去開(kāi)展，強(qiáng)烈關(guān)注業(yè)務(wù)的開(kāi)展?fàn)顟B(tài)。
一旦業(yè)務(wù)穩(wěn)定，勢(shì)態(tài)良好，那么應(yīng)用就會(huì)越來(lái)越多，這個(gè)時(shí)候開(kāi)展數(shù)倉(cāng)的分層設(shè)計(jì)，就會(huì)順理成章。
分層
一切圍繞業(yè)務(wù)應(yīng)用而生，而業(yè)務(wù)應(yīng)用，也再一次的分層：業(yè)務(wù)引導(dǎo)（數(shù)據(jù)挖掘，推薦）主題；分析（運(yùn)營(yíng)分析，財(cái)務(wù)分析）主題；業(yè)務(wù)主題（以事實(shí)業(yè)務(wù)過(guò)程為基礎(chǔ)的分析）。
總的來(lái)說(shuō)，這一層指導(dǎo)和鋪墊了底層數(shù)據(jù)的分層建設(shè)，該層也叫主題標(biāo)準(zhǔn)。
這些主題標(biāo)準(zhǔn)切分開(kāi)來(lái)了，但實(shí)現(xiàn)這些主題切分的人，還沒(méi)有定義出來(lái)。到底是業(yè)務(wù)架構(gòu)，還是技術(shù)架構(gòu)兼任？
不管是誰(shuí)來(lái)做，這樣的融合必定是不可少的。懂技術(shù)的，并不一定懂業(yè)務(wù)，懂業(yè)務(wù)的，不一定懂技術(shù)。所以必須有人來(lái)雙向融合。這大概就是架構(gòu)師要做的事情。
主題區(qū)分開(kāi)來(lái)了，技術(shù)的定型也就確定了。以前大家都是拿一塊業(yè)務(wù)，還有可能是同一塊業(yè)務(wù)，垂直的在各自造煙囪?？瓷先ゴ蠹叶际侨珬＃瑢?shí)則浪費(fèi)資源。
此時(shí)，將人力資源分層，做建模，做數(shù)據(jù)應(yīng)用，團(tuán)隊(duì)的資源就不會(huì)浪費(fèi)在同一塊地方。比如之前，數(shù)據(jù)組的每個(gè)人都在做商家統(tǒng)計(jì)，不同的是一組在處理總部來(lái)的需求，二組則在處理每個(gè)城市來(lái)的需求。其實(shí)有些共性的部分，大家可以放在一個(gè)模塊來(lái)完成，不必各自為政。之前的這種團(tuán)隊(duì)劃分，稱之為垂直劃分。
而美團(tuán)數(shù)倉(cāng)2.0，則更多橫向劃分。從建模到應(yīng)用，每個(gè)段切分，專人專做整個(gè)鏈路的某一段。
從主題到最終的物理層實(shí)現(xiàn)，需要兩組人馬不停的融合。一組人負(fù)責(zé)不停的處理業(yè)務(wù)需求建模，另一組人負(fù)責(zé)物理數(shù)據(jù)的建模。這兩組人一定需要在某個(gè)點(diǎn)上達(dá)成一致。所以分工標(biāo)準(zhǔn)就出來(lái)了，數(shù)據(jù)應(yīng)用組和數(shù)據(jù)建模組。
剛才美團(tuán)數(shù)倉(cāng)1.0，數(shù)據(jù)分成了四層：ODS/明細(xì)/聚合/應(yīng)用?，F(xiàn)在需要將數(shù)據(jù)分得更細(xì)，做更多的解耦。
其實(shí)也可以用接單的stage1,stage2,stage3來(lái)劃分。但每一層做些什么，當(dāng)然還是要了然于胸。
比如stage1,整合多數(shù)據(jù)源的一致性建模，完成數(shù)據(jù)維度，事實(shí)組合。stage2，用來(lái)完成聚合匯總，進(jìn)一步按照粒度劃分，完成年月日級(jí)的聚合。至此，一個(gè)中央數(shù)據(jù)倉(cāng)庫(kù)就完成了。stage3,按照業(yè)務(wù)單元，做數(shù)據(jù)集市。比如營(yíng)運(yùn)，銷售。這樣提供給數(shù)據(jù)應(yīng)用層，就有了完整的數(shù)據(jù)源。
在數(shù)據(jù)整合層，要注重排查的兩個(gè)概念，一是寬表，二是聚合表。寬表與 kimball 的 fact table 不一樣，我們通常所說(shuō)的fact table，實(shí)際上僅僅是明細(xì)表的統(tǒng)稱，而寬表，則是把相關(guān)的事實(shí)表，都整合到一起，這樣的好處，一是加快速度，二是一次查詢更加全面。
舉個(gè)例子說(shuō)明下大寬表的定義：選定實(shí)體對(duì)象（比如訂單），圈定分析對(duì)象（比如訂單頭，明細(xì)，狀態(tài)，訂單召回等），構(gòu)建寬表模型（通過(guò)訂單id，將這些表關(guān)聯(lián)到一張表）。
最終的應(yīng)用層，會(huì)簡(jiǎn)單很多。主要是選型，也就是針對(duì)業(yè)務(wù)數(shù)據(jù)應(yīng)用，會(huì)選擇哪些數(shù)據(jù)庫(kù)技術(shù)，分析引擎技術(shù)，還有報(bào)表計(jì)算。歸納起來(lái)，離不開(kāi)存儲(chǔ)，計(jì)算，可視化。
缺陷
美團(tuán)數(shù)據(jù)倉(cāng)庫(kù)2.0，還是有很多缺點(diǎn)。如下圖：
在數(shù)據(jù)集市層，會(huì)過(guò)度膨脹。因?yàn)閷优c層之間一旦分割，便會(huì)有不同的想法。今天她要這個(gè)指標(biāo)，明天他又要那個(gè)指標(biāo)，其實(shí)他倆指標(biāo)都差不太多，但就是要設(shè)計(jì)兩套，最終導(dǎo)致數(shù)據(jù)集市層膨脹。而數(shù)據(jù)倉(cāng)庫(kù)3.0就是來(lái)解決這樣的問(wèn)題。
說(shuō)實(shí)話，這是我從來(lái)沒(méi)有想到過(guò)的一層。使用建模工具替代人工開(kāi)發(fā)。因?yàn)檫@套玩法，我從來(lái)沒(méi)用過(guò)啊。這大概就是美團(tuán)外賣的先進(jìn)之處。
文章還提到另一個(gè)數(shù)據(jù)倉(cāng)庫(kù)方向是數(shù)據(jù)治理。它分享了三個(gè)小點(diǎn)：數(shù)據(jù)開(kāi)發(fā)流程，數(shù)據(jù)安全管理，資源優(yōu)化。這一塊也是我的弱項(xiàng)，下回，我就來(lái)盤它！
往期精彩：
我在面試數(shù)據(jù)庫(kù)工程師候選人時(shí)，常問(wèn)的一些題
零基礎(chǔ) SQL 數(shù)據(jù)庫(kù)小白，從入門到精通的學(xué)習(xí)路線與書(shū)單