作者：惠明，美團外賣資料智能組技術專家，2014年加入美團外賣，從0到1建設美團外賣資料倉庫，現負責美團外賣資料倉庫和資料應用工作。
導讀：美團外賣資料倉庫主要是收集各種使用者終端業務、行為資料，通過統一口徑加工處理，通過多種資料服務支撐主題報表、資料分析等多種方式的應用。資料組作為資料基礎部門，支援使用者端、商家端、銷售、廣告、算法等各個團隊的資料需求。
本文主要介紹美團外賣離線數倉的曆史發展曆程，在發展過程中碰到的痛點問題，以及針對痛點做的一系列優化解決方案。
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. 未來規劃實施
針對對未來規劃的思考，我們具體實施措施計劃是：與集團基礎平台工具共享共建，在資料應用方面更好做到資料賦能業務，然後就是具體的資料建設、資料管理。
資料建設：
資料建設主要圍繞以下幾個方面：
- 資料全：我們希望我們的資料足夠全，包括外賣的資料以及團購、點評的線下資料和外部采買的資料等，隻要是外賣需要的資料我們都盡量采集過來
- 效率高：效率提升方面，我們剛剛提到我們的使用模組化工具替代人工工作進而提高我們的效率
- 能力強：在足夠全的資料、提升效率的基礎上提高我們的能力，包括服務的穩定性、資料品質
資料管理：
通過完善資料标準規範，并将規範落地到工具以及增強資料治理，另外通過算法的手段發現資料裡隐藏的問題完成資料資料治理。這主要需要我們組織能力建設、标準規範的統一、完善資料治理平台與資料營運機制、探索智能資料治理，最終達到資料管理的規範化、系統化、智能化的目的。
↘好文推薦：
圍棋大師阿裡，産品經理騰訊
“百億補貼”真的能拯救一切嗎？
以叮咚買菜為例，看生鮮電商的春天是否已經到來？
點個“在看”吧