導讀： 美團外賣數據倉庫主要是收集各種用戶終端業務、行爲數據，通過統一口徑加工處理，通過多種數據服務支撐主題報表、數據分析等多種方式的應用。數據組作爲數據基礎部門，支持用戶端、商家端、銷售、廣告、算法等各個團隊的數據需求。本文主要介紹美團外賣離線數倉的歷史發展歷程，在發展過程中碰到的痛點問題，以及針對痛點做的一系列優化解決方案。
01 業務介紹
首先介紹下美團外賣的業務場景， 核心交易鏈路爲：用戶可以通過美團的各種用戶終端（包括美團外賣的APP或者美團 APP、QQ/微信等）下單，然後商家接單、騎手配送，三個階段完成一筆交易。這一系列交易過程，由包括用戶端、商家端、配送平臺、數據組、廣告組等各個系統協同完成。
這裏主要介紹外賣數據組在整個業務中角色。外賣數據組主要是：
- 給用戶端、商家端提供業務需求，
- 給前端提供需要展示的數據，
- 給廣告、算法團隊提供特徵等數據，提高算法效率
- 向城市團隊提供業務開展所需數據
- 前端提供埋點指標、埋點規範相關數據
1. 整體架構介紹
美團外賣整體分爲四層： 數據源層、數據加工層、數據服務層、數據應用層。
數據源層： 包含接入的原始數據，包括客戶端日誌、服務端日誌、業務庫、集團數據、外部數據等。
數據加工層： 使用 Spark、Hive 構建離線數倉、使用 Storm、 Flink 實時數倉。在數倉之上針對服務對象建設各種數據集市，比如：
- 面向總部使用的總部數據集市
- 面向行爲數據的流量數據集市
- 面向線下城市團隊的城市團隊集市
- 面向廣告的廣告集市
- 面向算法的算法特徵
數據服務層： 主要包括存儲介質的使用和數據服務的方式。
- 存儲：主要使用開源組件，如 Mysql, HDFS, HBase, Kylin, Doris, Druid, ES, Tair 等
- 數據服務：對外數據查詢、接口以及報表服務
數據應用層： 主要包括主題報表、自助取數工具、增值產品、數據分析等支撐業務開展，同時依賴公司平臺提供的一些工具建設整體數據應用。
2. ETL on Spark
我們離線計算從 17 年開始從 Hive 遷移到 Spark， 目前大部分任務已經遷移到 Spark 上運行，任務遷移後，相比之前使用 Hive 整體資源節省超過 20%。相比之下 Spark 的主要優勢是：
- 算子豐富，支持更復雜的業務邏輯
- 迭代計算，中間結果可以存內存，相比 MR 充分利用了內存，提高計算效率
- 資源複用，申請資源後重複利用
這裏簡單介紹寫 Spark Sql 的任務解析流程：客戶端提交任務後，通過 Sql 解析先生成語法樹，然後從 Catalog 獲取元數據信息，通過分析得到邏輯執行計劃，進行優化器規則進行邏輯執行的優化，最後轉成物理執行計劃提交到 spark 集羣執行。
02 數倉建設
1. 數據倉庫V1.0
2016 年之前。外賣數據組的情況是：團隊不大，數據量不多，但是市場競品較多（餓了麼、百度等），競爭激烈， 因此當時數據組的目標是：快速響應業務需求，同時做到靈活多變，支撐業務業務決策，基於這種業務背景和實現目標，當時數倉架構設計如圖所示主要分了四層，分別是：ODS層/明細層/聚合層/主題層/應用層（具體如圖示）。
隨着數據量、業務複雜度與團隊規模的增長， 爲更好完成業務需求數據組團隊按照應用做拆分，比如面向總部的總部團隊、面向城市業務的城市團隊，各個團隊都做一份自己的明細數據、指標和主題寬表數據，指標和主題寬表很多出現重疊的情況，這時候就像是”煙囪式“開發。這在團隊規模較小時，大家相互瞭解對方做的事情，基本不會有問題；但是在團隊規模增長到比較大的時候，多團隊“煙囪式”獨立作戰也暴露出了這種架構的問題，主要是：
- 開發效率低
- 數據口徑不統一
- 資源成本高
2. 數據倉庫V2.0
針對上述問題，數據組做了架構的升級，就是數據倉庫V2.0版本。此次升級優化的目標主要是：
- 簡化開發流程，提高開發運維效率
- 明確分層，分主題標準，貫徹執行
完成這個目標的思路如下三個方面：
① 分工標準：
之前面向不同應用建立不同團隊完全縱向切分，會導致可以公用的部分明細數據重複開發。爲改變這種情況將數據團隊改爲：數據應用組和數據建模組。各組職責如下：
- 數據應用組：負責應用指標、應用維度、應用模型，這一組的數據建模特點是：自上而下、面向應用。
- 數據建模組：負責基礎事實、基礎維度、原子指標的數據開發，這一組的數據建模特點是：自下而上、面向業務。
② 分層標準：
在原有分層的基礎上，再次明確各層的職責，比如：明細層用來還原業務過程，輕度彙總曾用來識別分析對象；同時數據加工時考慮數據的共性、個性、時效性、穩定性四個方面的因素，基於以上原則明確數倉各層達到數據本身和應用需求的解耦的目標。具體各層細節在文章接下來的內容會展開來講。
③ 主題標準：
根據數倉每層的特性使用不同的主題劃分方式，總體原則是：主題內部高內聚、不同主題間低耦合。主要有：明細層按照業務過程劃分主題，彙總層按照“實體+活動”劃分不同分析主題，應用層根據應用需求劃分不同應用主題。
2.1 數倉規範
① 數據倉庫建模規範
根據前述三個方面的思路，將數倉分爲以下幾個層次：
- ODS：數據源層，主要職責是接入數據源，並做多數據源的整合
- IDL：數據集成層，主要職責是：業務主題的劃分、數據規範化，比如商家、交易、用戶等多個主題。這一層主要起到緩衝的作用，屏蔽底層影響，儘量還原業務，統一標準。
- CDL：數據組件層，主要職責是劃分分析主題、建設各個主題的基礎指標，比如商家交易、用戶活動等多個主題。這樣針對同一個分析對象統一了指標口徑，同時避免重複計算。
- MDL：數據集市層，主要職責是建設寬表模型、彙總表模型，比如商家寬表、商家時段彙總表等。主要作用是支撐數據分析查詢以及支持應用所需數據。
- ADL：數據應用層，主要職責是建設應用分析、支撐多維分析應用，比如城市經營分析等。
其中 ODS/IDL/CDL，以及部分 MDL 集市由數據基建組來做，另外部分數據集市以及 ADL 應用層由數據應用組支撐，分工標準是涉及一些公共的數據集市由數據基建組來完成；數據應用組會圍繞應用建設應用數據集市，如流量集市、城市經營集市。
② 數據源層
整體建設思路：從數據源落地到 Hive 表，同時與數據來源保持一致，儘量還原業務。主要由四類數據源：業務庫數據、流量日誌、集團數據、三方數據。
- 業務庫數據：主要是將各個客戶端的數據同步 Hive ，主要有用戶端、商家端、運營端，同步方法主要採用 binlog 同步，同步方式有全量同步、增量、快照同步三種方式。同時支持業務庫分庫分表、分集羣等不同部署方式下的數據同步。
- 流量日誌：特點是外賣終端多，埋點質量不一，比如單 C 端分類就超過十種。爲此公司統一了終端埋點 SDK，保證不同終端埋點上報的數據規範一致，同時使用一些配置工具、測試工具、監控工具保證埋點的質量。整理建設思路是：定義埋點規範、梳理埋點流程、完善埋點工具。
- 集團數據：包含集團業務數據、集團公共數據，特點是數據安全要求高。目前公司建立了統一的安全倉，用於存儲跨 BU 的數據，同時定義權限申請流程。這樣對於需要接入的數據，直接走權限申請流程申請數據然後導入業務數倉即可。
- 三方數據：外部渠道數據，特點是外部渠道多、數據格式不統一，對此我們提供了通用接口對於收集或者採買的三方數據在接入數倉前進行了規範化的清洗。
③ 數據集成層
數據集成層主要是明細數據，與上一層數據源層是有對應關係的。數據集成表的整體建設思路爲：
- 抽象業務過程
- 識別實體關係，掛靠業務主題，比如交易過程包括提單、支付等過程，把這些業務行爲涉及的事實表進行關聯，識別出裏面的實體關係
- 兼容數據成本
- 屏蔽業務變化，比如訂單狀態變化
- 統一數據標準，敏感字段脫敏，字段名稱標準化等
如圖中示例爲提單表建設過程。
④ 數據組件層
數據組件層，主要建設多維明細模型、輕度彙總模型。總體建設思路與建設原則爲：
建設思路：
- 識別分析對象，包含分析對象實體以及對象行爲
- 圈定分析邊界
- 豐富對象屬性
建設原則：
數據組件層生成的指標主要是原子指標，原子指標形成數據組件，方便下游的集市層以及應用層拼接數據表。
- 分析對象包括業務實體和業務行爲
- 分析對象的原子指標和屬性的惟一封裝
- 爲下一層提供可共享和複用的組件
多維明細模型：
以商家信息表建設過程爲例：
- 識別分析對象：首先明確分析對象爲商家實體，
- 圈定分析邊界：多維明細不需要關聯實體行爲，只需要識別出實體之後圈定商家屬性信息作爲分析邊界；
- 豐富對象屬性：提取商家屬性信息，比如商家的品類信息、組織結構信息等
以上信息就形成了一個由商家主鍵和商家多維信息組成的商家實體的多維明細模型。
輕度彙總模型：
以商家交易表假設過程爲例：
- 識別分析對象：分析實體是商家，業務行爲是交易，分析對象是商家交易
- 圈定分析邊界：圈定提交表、商家信息表、訂單狀態表、會員表作爲商家交易的邊界
- 豐富對象屬性：將城市、組織結構等維度信息冗餘進來，豐富維度屬性信息
彙總商家粒度、交易額等原子指標最終建立商家交易表。
⑤ 數據集市層
建設思路：
建立寬表模型和彙總模型。兩者區別爲寬表模型是唯一主鍵，基於主鍵拼接各種信息；彙總模型的主鍵類型爲聯合主鍵，根據公共維度關聯生成派生指標，豐富信息。
- 寬表模型：訂單寬表爲例，建設過程爲：選定訂單實體作爲實體對象，然後圈定訂單明細、訂單狀態、訂單活動、訂單收購等分析對現象通過訂單 id 進行關聯。這裏的寬表模型與數據組件層的多維明細模型的區別在於多維明細模型裏的實體對象粒度更細，例如訂單寬表中分析對象：訂單明細、訂單狀態、訂單活動等都是多維明細模型裏的一個個數據組件，這幾個數據組件通過訂單 id 關聯拼接形成了寬表模型。
- 彙總模型：商家時段彙總表爲例，建設過程爲：選定商家、時段維度作爲維度組合，圈定商家和時段維度相關的表，通過公共維度進行關聯、維度冗餘，支持派生指標、計算指標的建設。這裏區別於組件層的輕度彙總模型，在數據組件層建設的是原子指標，而數據集市層建設的是派生指標。
⑥ 數據應用層
建設思路： 根據應用場景選擇合適的查詢引擎
選型考慮因素： OLAP 引擎選型考慮以下 8 個方面的因素：
- 數據規模是否適合
- SQL 語法的支持程度如何
- 查詢速度怎麼樣
- 是否支持明細數據
- 是否支持高併發
- 是否支持數據檢索
- 是否支持精確去重
- 是否方便使用，開發效率如何
技術選型： 早期主要使用 Kylin ，近期部分應用開始遷移 Doris。
模型： 根據不同 OLAP 引擎使用不同數據模型來支持數據應用。基於 Kylin 引擎會使用星型模型的方式構建數據模型，在 Doris 支持聚合模型，唯一主鍵以及冗餘模型。
2.2 數倉 V2.0 的缺點
前面幾小節對數倉 2.0 做了詳細的介紹，在數倉 2.0 版本的建設過程中我們也遇到了一些問題。前面有提到數據集成層與組件層由數據基建組來統一運維，數據應用層是由數據應用組來運維，這樣導致雖然在集成層和組件做了收斂但是在應用層和集市層卻產生了膨脹，缺乏管理。
面對這個問題，我們在 2019 年對數倉進行了新的迭代，即數倉 V3.0，下面將對此做詳細介紹。
3. 數據倉庫V3.0
總體願景： 數倉 3.0 優化思路主要是使用建模工具替代人工開發。
建模工具： 分爲基礎的建模工具和應用層建模工具。
- 基礎層建模工具：主要是在元數據中心記錄維護業務過程、表的關聯關係、實體對象、識別的分析對象，基於維護的信息構建數據組件以供應用層和集市層拼接
- 自助查詢工具：根據數據組件和用戶選取的需要查詢的指標維度信息構建邏輯寬表，根據邏輯寬表匹配最佳模型從而生成查詢語句將查詢出來的數據反饋給用戶。同時根據用戶查詢情況反過來指導建模，告訴我們需要把哪些指標和哪些維度經常會放在一起查詢，根據常用的指標、維度組合建設數據組件
- 應用層建模工具：依賴數據組件，包括數據組件層的多維明細數據、輕度彙總數據以及集市層的寬表等構建構建數據應用。主要過程是獲取所需數據組件，進行數據裁剪，與維表關聯後冗餘維度屬性，按需進行上卷聚合、複合指標的計算，最終把獲取到的多個小模型拼接起來構建數據應用
通過整套工具的使得數據組件越來越完善，應用建模越來越簡單，以上就是數倉 3.0 的整體思路。
03 數據治理
1. 數據開發流程
先說下我們數據開發流程，數據開發流程主要分爲四個階段：需求分析、技術方案設計、數據開發、報表開發&接口開發，具體內容如下：
- 需求分析：在需求分析階段，產品會設計一個需求 PRD 以及列出指標維度矩陣，然後需求評審與需求相關人員進行溝通，做一些數據的探查
- 技術方案設計：完成需求分析之後，形成模型設計的技術方案，同時將方案落地到文檔進行技術方案的評審
- 數據開發：完成技術方案的設計與評審就正式進入了數據開發以及測試階段
- 報表開發&接口開發：數據開發完成之後進入具體應用的開發
在整個數據開發流程中，我們遵循的整體思路是：
- 數據標準化
- 標準系統化
- 系統一體化
即數據符合標準規範，同時將標準規範落地到系統裏，最後系統要和周邊應用打通，形成一體。下面對各個思路做詳細的描述。
① 數據標準化
在數據標準化這塊，數據產品團隊、數據開發團隊、數據分析團隊聯合建立了數據標準化委員會。數據標準委員會制定了《指標標準規範》、《維度標準規範》以及一些新增指標、維度的流程等一系列規範標準，這樣做的好處是：指標維度管理有據可依，指標維度管理有組織保障，保障各業務方指標維度口徑清晰統一。
② 標準系統化
明確了數據標準各項規範，需要將這些標準化規範落地到系統，就是我們的數據治理平臺，我們的數據治理平臺由自建系統 + 集團數據服務構成。這裏面主要有四層： 數據生產工具、集團基礎平臺、元數據層、數據服務層。
- 數據生產工具：數據生產主要依靠平臺的計算能力，包括離線生產平臺、實時生產平臺、調度管理平臺
- 集團基礎平臺：數據生產工具之上是集團基礎平臺，包括數據資產管理、元數據管理、數據質量管理、資源管理以及權限管理
- 元數據層：元數據與數據服務都是美團外賣自己業務做的一些工作，元數據層包括數據模型、表/字段、主題/層級、指標/維度、業務過程、詞根/詞庫
- 數據服務層：服務層包含有數據標準化，前面提到的指標流程、維度流程、認證管理都是在這裏落地；同時把業務管理起來，包括理業務大盤、業務過程、數據域管理；然後還管理我們的數據模型包括指標維度矩陣、事實邏輯模型、維度邏輯模型；同時提供元數據服務，包含業務元數據、技術元數據以及維度服務；還有剛纔提到的一些在線建模工具
圖片右邊展示了我們的元數據模型，從下而上，我們首先維護詞根組成的詞庫，同時詞根、詞庫組成我們的指標和維度，其中維度分爲維表和碼錶，指標在確保唯一性的前提下劃分業務過程，同時區分原子指標、派生指標、計算指標；然後由維度和指標拼接成字段、字段組成表，表再和業務主題、業務過程相關聯，識別出實體、行爲，區分事實表、維度表同時確定表所在的層級，最後由一張張的表組成我們的數據模型，整個過程就是我們的元數據模型。
③ 系統一體化
有了前面的數據信息之後，我們和下游對接就比較方便。使用到數據治理平臺的數據下游有：
- 報表系統：報表展示所需的指標維度信息、模型信息都是來自於數據治理平臺，
- 數據超市：數據超市的自助取數里根據指標、維度、數據組件構建數據查詢，這些信息都是來自數據治理平臺，
- 海豚數據平臺：海豚數據平臺是我們的外賣數據門戶
- 異常分析平臺：對指標維度的波動進行監測分析
- CRM 系統：面向一線城市團隊的數據展示
- 算法平臺：向算法平臺提供標籤、特徵數據的管理
- 畫像平臺：管理畫像平臺的人羣標籤
- 數據 API 服務：對外提供的 API 模型以及接口的信息
- 到家數據檢索：到家業務元數據聯通，統一檢索元數據信息
- 公司元數據平臺：向公司元數據平臺提供元數據信息
通過與各個下游不同形式的對接，數據治理平臺完成了整個下游數據應用的聯通，以及支持數據使用與生產，形成了一體化的系統。
2. 資源優化
資源優化方面，在美團會把覈算單元分成若干個租戶 ，然後把資源分配給各個租戶，在同一個租戶裏各個項目組協調分割分配到資源，項目組由任務和數據組成。
我們把租戶與對應主題進行掛靠，這樣就可讓租戶有對應的接口人管理，比如把外賣覈算單元分爲：數倉租戶、廣告租戶、算法租戶以及其他的業務租戶，讓每個租戶對應一個接口人，與接口人對接資源優化方案、規則，最後由接口人推動。
我們的優化規則主要分爲三個方向：
- 流量：流量方面，主要是對無效 ODS 下線從而降低存儲與傳輸成本；同時埋點數據生命週期減少成本浪費，目前用戶日活幾千萬，上報的流量日誌是有上百億，埋點若不再使用對存儲與傳輸成本浪費較大；另外對日誌進行序列化壓縮處理降低成本
- 存儲：存儲方面我們使用 ORC 進行壓縮，同時對冷熱數據做了生命週期管理，另外也通過模型的優化以及文件的優化把存儲成本控制住
- 計算：計算方面對無效任務進行下線、 ETL 任務優化；同時對數據開發收斂，把業務中公共部分收斂到數據組
有了優化規則，針對規則的運營監控流程爲：首先對賬單分析，賬單主要有離線/實時計算資源、存儲資源、ODS 數據收集使用的資源、日誌中心所使用的資源， 分析帳單後定義運營規則並將規則落地到數據運維平臺，由數據運維平臺將任務推送到相關責任人，責任人收到通知後，在數據資產中心做相關處理，同時數據運維平臺會做成本監控，對超出配額&預算異常進行報警。
這樣我們通過建立統一規則並將規則分發到不同租戶落地執行，完成數據資源優化的目標。
3. 數據安全
數據安全方面主要是對數據脫敏，數據保密等級的設定 (C1~C4)，數據申請做權限控制，審計數據使用的方式，我們分三個階段完成數據安全的治理：
- 事前：包括敏感數據脫敏、數據權限控制。針對事業部內、事業部外使用不同的權限流程控制。
- 事中：包括敏感 SQL 的預警與攔截，針對敏感 SQL 我們進行攔截並由數據安全人員進行審批
- 事後：包括敏感 SQL 審計，操作異常審計。輸出敏感 SQL 審計的月報發到對應的部門負責人，審覈內容主要有敏感 SQL 的查詢、數據操作異常及後續審批還有全量查詢日誌分析。
04 未來規劃
1. 未來規劃思考
最後介紹下，我們對未來的規劃，對未來規劃的思考主要是在業務和技術兩個方面：
- 業務目標：通過數據賦能業務，幫助完成未來實現業務訂單量和收入的高速增長的目標
- 技術目標：提高高效、易用、高質量、低成本的數據服務
這裏面數據價值的具體體現，總結爲以下幾點：
- 基礎的數據能力：保障數據服務的穩定性，以及數據的時效性越來越高，以及數據服務的覆蓋度足夠廣、足夠全，擴大數據服務內容
- 運營決策支持：及時洞察業務變化，直到業務完成運營決策
- 數據商業變現：通過增值型數據產品，把數據進行商業變現
- 業務數據支持：更好的支持對接的各個業務系統，從而提高整體數據價值
- 算法效率提升：針對算法加工特徵所需的數據提供更好的支持，以提高算法模型效率，完成用戶轉化率的提高
- 社會影響力：通過我們的 PR 團隊做一些對外的分析報告，擴大行業影響力
2. 未來規劃實施
針對對未來規劃的思考，我們具體實施措施計劃是：與集團基礎平臺工具共享共建，在數據應用方面更好做到數據賦能業務，然後就是具體的數據建設、數據管理。
數據建設：
數據建設主要圍繞以下幾個方面：
- 數據全：我們希望我們的數據足夠全，包括外賣的數據以及團購、點評的線下數據和外部採買的數據等，只要是外賣需要的數據我們都儘量採集過來
- 效率高：效率提升方面，我們剛剛提到我們的使用建模工具替代人工工作從而提高我們的效率
- 能力強：在足夠全的數據、提升效率的基礎上提高我們的能力，包括服務的穩定性、數據質量
數據管理：
通過完善數據標準規範，並將規範落地到工具以及增強數據治理，另外通過算法的手段發現數據裏隱藏的問題完成數據數據治理。這主要需要我們組織能力建設、標準規範的統一、完善數據治理平臺與數據運營機制、探索智能數據治理，最終達到數據管理的規範化、系統化、智能化的目的。
今天的分享就到這裏，謝謝大家。
作者介紹：
惠明，美團外賣技術專家
惠明，美團外賣數據智能組技術專家，於2014年加入美團外賣，從0到1建設美團外賣數據倉庫，現負責美團外賣數據倉庫和數據應用工作。
本文來自 DataFunTalk
原文鏈接：