我就點(diǎn)個(gè)外賣，竟然經(jīng)歷了如此硬核的離線數(shù)倉迭代……
時(shí)間：2021-09-06 15:20:10
手機(jī)看文章
掃描二維碼
隨時(shí)隨地手機(jī)看文章
[導(dǎo)讀]導(dǎo)讀：美團(tuán)外賣數(shù)據(jù)倉庫主要是收集各種用戶終端業(yè)務(wù)、行為數(shù)據(jù)，通過統(tǒng)一口徑加工處理，通過多種數(shù)據(jù)服務(wù)支撐主題報(bào)表、數(shù)據(jù)分析等多種方式的應(yīng)用。數(shù)據(jù)組作為數(shù)據(jù)基礎(chǔ)部門，支持用戶端、商家端、銷售、廣告、算法等各個(gè)團(tuán)隊(duì)的數(shù)據(jù)需求。本文主要介紹美團(tuán)外賣離線數(shù)倉的歷史發(fā)展歷程，在發(fā)展過程中碰到...
導(dǎo)讀：美團(tuán)外賣數(shù)據(jù)倉庫主要是收集各種用戶終端業(yè)務(wù)、行為數(shù)據(jù)，通過統(tǒng)一口徑加工處理，通過多種數(shù)據(jù)服務(wù)支撐主題報(bào)表、數(shù)據(jù)分析等多種方式的應(yīng)用。數(shù)據(jù)組作為數(shù)據(jù)基礎(chǔ)部門，支持用戶端、商家端、銷售、廣告、算法等各個(gè)團(tuán)隊(duì)的數(shù)據(jù)需求。本文主要介紹美團(tuán)外賣離線數(shù)倉的歷史發(fā)展歷程，在發(fā)展過程中碰到的痛點(diǎn)問題，以及針對痛點(diǎn)做的一系列優(yōu)化解決方案。
一、業(yè)務(wù)介紹
首先介紹下美團(tuán)外賣的業(yè)務(wù)場景， 核心交易鏈路為：用戶可以通過美團(tuán)的各種用戶終端（包括美團(tuán)外賣的APP或者美團(tuán) APP、QQ/微信等）下單，然后商家接單、騎手配送，三個(gè)階段完成一筆交易。這一系列交易過程，由包括用戶端、商家端、配送平臺(tái)、數(shù)據(jù)組、廣告組等各個(gè)系統(tǒng)協(xié)同完成。
這里主要介紹外賣數(shù)據(jù)組在整個(gè)業(yè)務(wù)中角色。外賣數(shù)據(jù)組主要是：
- 給用戶端、商家端提供業(yè)務(wù)需求
- 給前端提供需要展示的數(shù)據(jù)
- 給廣告、算法團(tuán)隊(duì)提供特征等數(shù)據(jù)，提高算法效率
- 向城市團(tuán)隊(duì)提供業(yè)務(wù)開展所需數(shù)據(jù)
- 前端提供埋點(diǎn)指標(biāo)、埋點(diǎn)規(guī)范相關(guān)數(shù)據(jù)
1. 整體架構(gòu)介紹
美團(tuán)外賣整體分為四層：數(shù)據(jù)源層、數(shù)據(jù)加工層、數(shù)據(jù)服務(wù)層、數(shù)據(jù)應(yīng)用層。
數(shù)據(jù)源層：包含接入的原始數(shù)據(jù)，包括客戶端日志、服務(wù)端日志、業(yè)務(wù)庫、集團(tuán)數(shù)據(jù)、外部數(shù)據(jù)等。
數(shù)據(jù)加工層：使用? Spark、Hive 構(gòu)建離線數(shù)倉、使用 Storm、 Flink 實(shí)時(shí)數(shù)倉。在數(shù)倉之上針對服務(wù)對象建設(shè)各種數(shù)據(jù)集市，比如：
- 面向總部使用的總部數(shù)據(jù)集市
- 面向行為數(shù)據(jù)的流量數(shù)據(jù)集市
- 面向線下城市團(tuán)隊(duì)的城市團(tuán)隊(duì)集市
- 面向廣告的廣告集市
- 面向算法的算法特征
數(shù)據(jù)服務(wù)層：主要包括存儲(chǔ)介質(zhì)的使用和數(shù)據(jù)服務(wù)的方式。
- 存儲(chǔ)：主要使用開源組件，如 Mysql, HDFS, HBase, Kylin, Doris, Druid, ES, Tair 等
- 數(shù)據(jù)服務(wù)：對外數(shù)據(jù)查詢、接口以及報(bào)表服務(wù)
數(shù)據(jù)應(yīng)用層：主要包括主題報(bào)表、自助取數(shù)工具、增值產(chǎn)品、數(shù)據(jù)分析等支撐業(yè)務(wù)開展，同時(shí)依賴公司平臺(tái)提供的一些工具建設(shè)整體數(shù)據(jù)應(yīng)用。
2. ETL on Spark
我們離線計(jì)算從 17 年開始從 Hive 遷移到 Spark， 目前大部分任務(wù)已經(jīng)遷移到 Spark 上運(yùn)行，任務(wù)遷移后，相比之前使用 Hive 整體資源節(jié)省超過 20%。相比之下 Spark 的主要優(yōu)勢是：
- 算子豐富，支持更復(fù)雜的業(yè)務(wù)邏輯
- 迭代計(jì)算，中間結(jié)果可以存內(nèi)存，相比 MR 充分利用了內(nèi)存，提高計(jì)算效率
- 資源復(fù)用，申請資源后重復(fù)利用
這里簡單介紹寫 Spark Sql 的任務(wù)解析流程：客戶端提交任務(wù)后，通過 Sql 解析先生成語法樹，然后從 Catalog 獲取元數(shù)據(jù)信息，通過分析得到邏輯執(zhí)行計(jì)劃，進(jìn)行優(yōu)化器規(guī)則進(jìn)行邏輯執(zhí)行的優(yōu)化，最后轉(zhuǎn)成物理執(zhí)行計(jì)劃提交到 spark 集群執(zhí)行。
二、數(shù)倉建設(shè)
1. 數(shù)據(jù)倉庫V1.0
2016 年之前。外賣數(shù)據(jù)組的情況是：團(tuán)隊(duì)不大，數(shù)據(jù)量不多，但是市場競品較多（餓了么、百度等），競爭激烈， 因此當(dāng)時(shí)數(shù)據(jù)組的目標(biāo)是：快速響應(yīng)業(yè)務(wù)需求，同時(shí)做到靈活多變，支撐業(yè)務(wù)業(yè)務(wù)決策，基于這種業(yè)務(wù)背景和實(shí)現(xiàn)目標(biāo)，當(dāng)時(shí)數(shù)倉架構(gòu)設(shè)計(jì)如圖所示主要分了四層，分別是：ODS層/明細(xì)層/聚合層/主題層/應(yīng)用層（具體如圖示）。
隨著數(shù)據(jù)量、業(yè)務(wù)復(fù)雜度與團(tuán)隊(duì)規(guī)模的增長， 為更好完成業(yè)務(wù)需求數(shù)據(jù)組團(tuán)隊(duì)按照應(yīng)用做拆分，比如面向總部的總部團(tuán)隊(duì)、面向城市業(yè)務(wù)的城市團(tuán)隊(duì)，各個(gè)團(tuán)隊(duì)都做一份自己的明細(xì)數(shù)據(jù)、指標(biāo)和主題寬表數(shù)據(jù)，指標(biāo)和主題寬表很多出現(xiàn)重疊的情況，這時(shí)候就像是”煙囪式“開發(fā)。這在團(tuán)隊(duì)規(guī)模較小時(shí)，大家相互了解對方做的事情，基本不會(huì)有問題；但是在團(tuán)隊(duì)規(guī)模增長到比較大的時(shí)候，多團(tuán)隊(duì)“煙囪式”獨(dú)立作戰(zhàn)也暴露出了這種架構(gòu)的問題，主要是：
- 開發(fā)效率低
- 數(shù)據(jù)口徑不統(tǒng)一
- 資源成本高
2. 數(shù)據(jù)倉庫V2.0
針對上述問題，數(shù)據(jù)組做了架構(gòu)的升級，就是數(shù)據(jù)倉庫V2.0版本。此次升級優(yōu)化的目標(biāo)主要是：
- 簡化開發(fā)流程，提高開發(fā)運(yùn)維效率
- 明確分層，分主題標(biāo)準(zhǔn)，貫徹執(zhí)行
完成這個(gè)目標(biāo)的思路如下三個(gè)方面：
① 分工標(biāo)準(zhǔn)
之前面向不同應(yīng)用建立不同團(tuán)隊(duì)完全縱向切分，會(huì)導(dǎo)致可以公用的部分明細(xì)數(shù)據(jù)重復(fù)開發(fā)。為改變這種情況將數(shù)據(jù)團(tuán)隊(duì)改為：數(shù)據(jù)應(yīng)用組和數(shù)據(jù)建模組。各組職責(zé)如下：
- 數(shù)據(jù)應(yīng)用組：負(fù)責(zé)應(yīng)用指標(biāo)、應(yīng)用維度、應(yīng)用模型，這一組的數(shù)據(jù)建模特點(diǎn)是：自上而下、面向應(yīng)用。
- 數(shù)據(jù)建模組：負(fù)責(zé)基礎(chǔ)事實(shí)、基礎(chǔ)維度、原子指標(biāo)的數(shù)據(jù)開發(fā)，這一組的數(shù)據(jù)建模特點(diǎn)是：自下而上、面向業(yè)務(wù)。
② 分層標(biāo)準(zhǔn)
在原有分層的基礎(chǔ)上，再次明確各層的職責(zé)，比如：明細(xì)層用來還原業(yè)務(wù)過程，輕度匯總曾用來識(shí)別分析對象；同時(shí)數(shù)據(jù)加工時(shí)考慮數(shù)據(jù)的共性、個(gè)性、時(shí)效性、穩(wěn)定性四個(gè)方面的因素，基于以上原則明確數(shù)倉各層達(dá)到數(shù)據(jù)本身和應(yīng)用需求的解耦的目標(biāo)。具體各層細(xì)節(jié)在文章接下來的內(nèi)容會(huì)展開來講。
③ 主題標(biāo)準(zhǔn)
根據(jù)數(shù)倉每層的特性使用不同的主題劃分方式，總體原則是：主題內(nèi)部高內(nèi)聚、不同主題間低耦合。主要有：明細(xì)層按照業(yè)務(wù)過程劃分主題，匯總層按照“實(shí)體 活動(dòng)”劃分不同分析主題，應(yīng)用層根據(jù)應(yīng)用需求劃分不同應(yīng)用主題。
1）數(shù)倉規(guī)范
① 數(shù)據(jù)倉庫建模規(guī)范
根據(jù)前述三個(gè)方面的思路，將數(shù)倉分為以下幾個(gè)層次：
- ODS：數(shù)據(jù)源層，主要職責(zé)是接入數(shù)據(jù)源，并做多數(shù)據(jù)源的整合。
- IDL：數(shù)據(jù)集成層，主要職責(zé)是：業(yè)務(wù)主題的劃分、數(shù)據(jù)規(guī)范化，比如商家、交易、用戶等多個(gè)主題。這一層主要起到緩沖的作用，屏蔽底層影響，盡量還原業(yè)務(wù)，統(tǒng)一標(biāo)準(zhǔn)。
- CDL：數(shù)據(jù)組件層，主要職責(zé)是劃分分析主題、建設(shè)各個(gè)主題的基礎(chǔ)指標(biāo)，比如商家交易、用戶活動(dòng)等多個(gè)主題。這樣針對同一個(gè)分析對象統(tǒng)一了指標(biāo)口徑，同時(shí)避免重復(fù)計(jì)算。
- MDL：數(shù)據(jù)集市層，主要職責(zé)是建設(shè)寬表模型、匯總表模型，比如商家寬表、商家時(shí)段匯總表等。主要作用是支撐數(shù)據(jù)分析查詢以及支持應(yīng)用所需數(shù)據(jù)。
- ADL：數(shù)據(jù)應(yīng)用層，主要職責(zé)是建設(shè)應(yīng)用分析、支撐多維分析應(yīng)用，比如城市經(jīng)營分析等。
其中 ODS/IDL/CDL，以及部分 MDL 集市由數(shù)據(jù)基建組來做，另外部分?jǐn)?shù)據(jù)集市以及 ADL 應(yīng)用層由數(shù)據(jù)應(yīng)用組支撐，分工標(biāo)準(zhǔn)是涉及一些公共的數(shù)據(jù)集市由數(shù)據(jù)基建組來完成；數(shù)據(jù)應(yīng)用組會(huì)圍繞應(yīng)用建設(shè)應(yīng)用數(shù)據(jù)集市，如流量集市、城市經(jīng)營集市。
② 數(shù)據(jù)源層
整體建設(shè)思路：從數(shù)據(jù)源落地到 Hive 表，同時(shí)與數(shù)據(jù)來源保持一致，盡量還原業(yè)務(wù)。主要由四類數(shù)據(jù)源：業(yè)務(wù)庫數(shù)據(jù)、流量日志、集團(tuán)數(shù)據(jù)、三方數(shù)據(jù)。
- 業(yè)務(wù)庫數(shù)據(jù)：主要是將各個(gè)客戶端的數(shù)據(jù)同步 Hive ，主要有用戶端、商家端、運(yùn)營端，同步方法主要采用 binlog 同步，同步方式有全量同步、增量、快照同步三種方式。同時(shí)支持業(yè)務(wù)庫分庫分表、分集群等不同部署方式下的數(shù)據(jù)同步。
- 流量日志：特點(diǎn)是外賣終端多，埋點(diǎn)質(zhì)量不一，比如單 C 端分類就超過十種。為此公司統(tǒng)一了終端埋點(diǎn) SDK，保證不同終端埋點(diǎn)上報(bào)的數(shù)據(jù)規(guī)范一致，同時(shí)使用一些配置工具、測試工具、監(jiān)控工具保證埋點(diǎn)的質(zhì)量。整理建設(shè)思路是：定義埋點(diǎn)規(guī)范、梳理埋點(diǎn)流程、完善埋點(diǎn)工具。
- 集團(tuán)數(shù)據(jù)：包含集團(tuán)業(yè)務(wù)數(shù)據(jù)、集團(tuán)公共數(shù)據(jù)，特點(diǎn)是數(shù)據(jù)安全要求高。目前公司建立了統(tǒng)一的安全倉，用于存儲(chǔ)跨 BU 的數(shù)據(jù)，同時(shí)定義權(quán)限申請流程。這樣對于需要接入的數(shù)據(jù)，直接走權(quán)限申請流程申請數(shù)據(jù)然后導(dǎo)入業(yè)務(wù)數(shù)倉即可。
- 三方數(shù)據(jù)：外部渠道數(shù)據(jù)，特點(diǎn)是外部渠道多、數(shù)據(jù)格式不統(tǒng)一，對此我們提供了通用接口對于收集或者采買的三方數(shù)據(jù)在接入數(shù)倉前進(jìn)行了規(guī)范化的清洗。
③ 數(shù)據(jù)集成層
數(shù)據(jù)集成層主要是明細(xì)數(shù)據(jù)，與上一層數(shù)據(jù)源層是有對應(yīng)關(guān)系的。數(shù)據(jù)集成表的整體建設(shè)思路為：
- 抽象業(yè)務(wù)過程
- 識(shí)別實(shí)體關(guān)系，掛靠業(yè)務(wù)主題，比如交易過程包括提單、支付等過程，把這些業(yè)務(wù)行為涉及的事實(shí)表進(jìn)行關(guān)聯(lián)，識(shí)別出里面的實(shí)體關(guān)系
- 兼容數(shù)據(jù)成本
- 屏蔽業(yè)務(wù)變化，比如訂單狀態(tài)變化
- 統(tǒng)一數(shù)據(jù)標(biāo)準(zhǔn)，敏感字段脫敏，字段名稱標(biāo)準(zhǔn)化等
如圖中示例為提單表建設(shè)過程。
④ 數(shù)據(jù)組件層
數(shù)據(jù)組件層，主要建設(shè)多維明細(xì)模型、輕度匯總模型?？傮w建設(shè)思路與建設(shè)原則為：
- 建設(shè)思路：
- 識(shí)別分析對象，包含分析對象實(shí)體以及對象行為
- 圈定分析邊界
- 豐富對象屬性
- 建設(shè)原則：
數(shù)據(jù)組件層生成的指標(biāo)主要是原子指標(biāo)，原子指標(biāo)形成數(shù)據(jù)組件，方便下游的集市層以及應(yīng)用層拼接數(shù)據(jù)表。
- 分析對象包括業(yè)務(wù)實(shí)體和業(yè)務(wù)行為
- 分析對象的原子指標(biāo)和屬性的惟一封裝
- 為下一層提供可共享和復(fù)用的組件
- 多維明細(xì)模型：
以商家信息表建設(shè)過程為例：
- 識(shí)別分析對象：首先明確分析對象為商家實(shí)體
- 圈定分析邊界：多維明細(xì)不需要關(guān)聯(lián)實(shí)體行為，只需要識(shí)別出實(shí)體之后圈定商家屬性信息作為分析邊界；
- 豐富對象屬性：提取商家屬性信息，比如商家的品類信息、組織結(jié)構(gòu)信息等
以上信息就形成了一個(gè)由商家主鍵和商家多維信息組成的商家實(shí)體的多維明細(xì)模型。
- 輕度匯總模型：
以商家交易表假設(shè)過程為例：
- 識(shí)別分析對象：分析實(shí)體是商家，業(yè)務(wù)行為是交易，分析對象是商家交易
- 圈定分析邊界：圈定提交表、商家信息表、訂單狀態(tài)表、會(huì)員表作為商家交易的邊界
- 豐富對象屬性：將城市、組織結(jié)構(gòu)等維度信息冗余進(jìn)來，豐富維度屬性信息
匯總商家粒度、交易額等原子指標(biāo)最終建立商家交易表。
⑤ 數(shù)據(jù)集市層
- 建設(shè)思路：
建立寬表模型和匯總模型。兩者區(qū)別為寬表模型是唯一主鍵，基于主鍵拼接各種信息；匯總模型的主鍵類型為聯(lián)合主鍵，根據(jù)公共維度關(guān)聯(lián)生成派生指標(biāo)，豐富信息。
- 寬表模型：訂單寬表為例，建設(shè)過程為：選定訂單實(shí)體作為實(shí)體對象，然后圈定訂單明細(xì)、訂單狀態(tài)、訂單活動(dòng)、訂單收購等分析對現(xiàn)象通過訂單 id 進(jìn)行關(guān)聯(lián)。這里的寬表模型與數(shù)據(jù)組件層的多維明細(xì)模型的區(qū)別在于多維明細(xì)模型里的實(shí)體對象粒度更細(xì)，例如訂單寬表中分析對象：訂單明細(xì)、訂單狀態(tài)、訂單活動(dòng)等都是多維明細(xì)模型里的一個(gè)個(gè)數(shù)據(jù)組件，這幾個(gè)數(shù)據(jù)組件通過訂單 id 關(guān)聯(lián)拼接形成了寬表模型。
- 匯總模型：商家時(shí)段匯總表為例，建設(shè)過程為：選定商家、時(shí)段維度作為維度組合，圈定商家和時(shí)段維度相關(guān)的表，通過公共維度進(jìn)行關(guān)聯(lián)、維度冗余，支持派生指標(biāo)、計(jì)算指標(biāo)的建設(shè)。這里區(qū)別于組件層的輕度匯總模型，在數(shù)據(jù)組件層建設(shè)的是原子指標(biāo)，而數(shù)據(jù)集市層建設(shè)的是派生指標(biāo)。
⑥ 數(shù)據(jù)應(yīng)用層
- 建設(shè)思路：根據(jù)應(yīng)用場景選擇合適的查詢引擎
- 選型考慮因素：OLAP 引擎選型考慮以下 8 個(gè)方面的因素：
- 數(shù)據(jù)規(guī)模是否適合
- SQL 語法的支持程度如何
- 查詢速度怎么樣
- 是否支持明細(xì)數(shù)據(jù)
- 是否支持高并發(fā)
- 是否支持?jǐn)?shù)據(jù)檢索
- 是否支持精確去重
- 是否方便使用，開發(fā)效率如何
- 技術(shù)選型：早期主要使用 Kylin ，近期部分應(yīng)用開始遷移 Doris。
- 模型：根據(jù)不同 OLAP 引擎使用不同數(shù)據(jù)模型來支持?jǐn)?shù)據(jù)應(yīng)用。基于 Kylin 引擎會(huì)使用星型模型的方式構(gòu)建數(shù)據(jù)模型，在 Doris 支持聚合模型，唯一主鍵以及冗余模型。
2）數(shù)倉 V2.0 的缺點(diǎn)
前面幾小節(jié)對數(shù)倉 2.0 做了詳細(xì)的介紹，在數(shù)倉 2.0 版本的建設(shè)過程中我們也遇到了一些問題。前面有提到數(shù)據(jù)集成層與組件層由數(shù)據(jù)基建組來統(tǒng)一運(yùn)維，數(shù)據(jù)應(yīng)用層是由數(shù)據(jù)應(yīng)用組來運(yùn)維，這樣導(dǎo)致雖然在集成層和組件做了收斂但是在應(yīng)用層和集市層卻產(chǎn)生了膨脹，缺乏管理。
面對這個(gè)問題，我們在 2019 年對數(shù)倉進(jìn)行了新的迭代，即數(shù)倉 V3.0，下面將對此做詳細(xì)介紹。
3. 數(shù)據(jù)倉庫V3.0
總體愿景：數(shù)倉 3.0 優(yōu)化思路主要是使用建模工具替代人工開發(fā)。
建模工具：分為基礎(chǔ)的建模工具和應(yīng)用層建模工具。
- 基礎(chǔ)層建模工具：主要是在元數(shù)據(jù)中心記錄維護(hù)業(yè)務(wù)過程、表的關(guān)聯(lián)關(guān)系、實(shí)體對象、識(shí)別的分析對象，基于維護(hù)的信息構(gòu)建數(shù)據(jù)組件以供應(yīng)用層和集市層拼接
- 自助查詢工具：根據(jù)數(shù)據(jù)組件和用戶選取的需要查詢的指標(biāo)維度信息構(gòu)建邏輯寬表，根據(jù)邏輯寬表匹配最佳模型從而生成查詢語句將查詢出來的數(shù)據(jù)反饋給用戶。同時(shí)根據(jù)用戶查詢情況反過來指導(dǎo)建模，告訴我們需要把哪些指標(biāo)和哪些維度經(jīng)常會(huì)放在一起查詢，根據(jù)常用的指標(biāo)、維度組合建設(shè)數(shù)據(jù)組件
- 應(yīng)用層建模工具：依賴數(shù)據(jù)組件，包括數(shù)據(jù)組件層的多維明細(xì)數(shù)據(jù)、輕度匯總數(shù)據(jù)以及集市層的寬表等構(gòu)建構(gòu)建數(shù)據(jù)應(yīng)用。主要過程是獲取所需數(shù)據(jù)組件，進(jìn)行數(shù)據(jù)裁剪，與維表關(guān)聯(lián)后冗余維度屬性，按需進(jìn)行上卷聚合、復(fù)合指標(biāo)的計(jì)算，最終把獲取到的多個(gè)小模型拼接起來構(gòu)建數(shù)據(jù)應(yīng)用
通過整套工具使得數(shù)據(jù)組件越來越完善，應(yīng)用建模越來越簡單，以上就是數(shù)倉 3.0 的整體思路。
三、數(shù)據(jù)治理
1. 數(shù)據(jù)開發(fā)流程
先說下我們數(shù)據(jù)開發(fā)流程，數(shù)據(jù)開發(fā)流程主要分為四個(gè)階段：需求分析、技術(shù)方案設(shè)計(jì)、數(shù)據(jù)開發(fā)、報(bào)表開發(fā)
下載文檔
