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