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