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