销魂美女一区二区在线观看,电影限制中文字幕在线一区二区,欧美一区二区凹凸

[導讀]導讀：美團外賣數(shù)據(jù)倉庫主要是收集各種用戶終端業(yè)務、行為數(shù)據(jù)，通過統(tǒng)一口徑加工處理，通過多種數(shù)據(jù)服務支撐主題報表、數(shù)據(jù)分析等多種方式的應用。數(shù)據(jù)組作為數(shù)據(jù)基礎部門，支持用戶端、商家端、銷售、廣告、算法等各個團隊的數(shù)據(jù)需求。本文主要介紹美團外賣離線數(shù)倉的歷史發(fā)展歷程，在發(fā)展過程中碰到...

導讀：美團外賣數(shù)據(jù)倉庫主要是收集各種用戶終端業(yè)務、行為數(shù)據(jù)，通過統(tǒng)一口徑加工處理，通過多種數(shù)據(jù)服務支撐主題報表、數(shù)據(jù)分析等多種方式的應用。數(shù)據(jù)組作為數(shù)據(jù)基礎部門，支持用戶端、商家端、銷售、廣告、算法等各個團隊的數(shù)據(jù)需求。本文主要介紹美團外賣離線數(shù)倉的歷史發(fā)展歷程，在發(fā)展過程中碰到的痛點問題，以及針對痛點做的一系列優(yōu)化解決方案。

一、業(yè)務介紹

首先介紹下美團外賣的業(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ù)服務層：主要包括存儲介質的使用和數(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)化，最后轉成物理執(zhí)行計劃提交到 spark 集群執(zhí)行。

二、數(shù)倉建設

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ù)應用需求劃分不同應用主題。

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ù)同步。

流量日志：特點是外賣終端多，埋點質量不一，比如單 C 端分類就超過十種。為此公司統(tǒng)一了終端埋點 SDK，保證不同終端埋點上報的數(shù)據(jù)規(guī)范一致，同時使用一些配置工具、測試工具、監(jiān)控工具保證埋點的質量。整理建設思路是：定義埋點規(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）數(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 的整體思路。

三、數(shù)據(jù)治理

1. 數(shù)據(jù)開發(fā)流程

先說下我們數(shù)據(jù)開發(fā)流程，數(shù)據(jù)開發(fā)流程主要分為四個階段：需求分析、技術方案設計、數(shù)據(jù)開發(fā)、報表開發(fā)