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