點擊藍字訂閱，不錯過下一篇好文章

背景

美團點評作為全球最大的生活服務平臺，承接超過千萬的POI，服務于數量龐大的活躍用戶。在海量數據的前提下，定位運營業務、準確找到需要數據的位置，并快速提供正確、一致、易讀的數據就變得異常困難，這些困難主要體現在以下方面：

• 取數門檻高，找不到切合的數據，口徑復雜不易計算，對運營人員有一定的技能要求，人力成本增大；

• 數據處理非常耗時，缺少底層離線數倉模型建設和預計算支撐，Ad-hoc平臺查詢緩慢；

• 數據不一致，不同渠道口徑不一致，缺少對雜亂指標的統一管理；

• 數據反饋形式不友好，缺少數據可視化的形式，無法呈現趨勢，繼而影響業務人員對多維、降維、對比等情況的進一步分析操作。

因此團隊提出將運營專題數據產品化，首先分析面臨的一些問題和挑戰。

挑戰

① 服務業務能力

數據模式是需求驅動導向，這就導致數據最初只支持了少數團隊，而更多有個性化需求的業務團隊就無法被支持。

② 存儲、計算、研發成本

沒有統一的規范標準管理，造成了重復計算的資源浪費；數據的層次和粒度不清晰，使得重復存儲嚴重；同時，工程師需要了解研發流程的整個細節，對研發的時間和精力成本造成浪費。

③ 數據標準不統一

業務指標繁雜，即使同樣的命名，但定義口徑也會不一致。例如，支付用戶數就有多種定義，由此帶來的問題是，都是支付用戶數，應該用哪個？為什么數據都不一樣？

④ 業務分析響應能力

即使擁有健壯的數倉模型支撐，但最終能否快速響應多維計算，進行對比分析，同時做到數據可讀，都是對產品交互和服務能力的一種挑戰。

針對以上的問題和挑戰，開始制定建設方案。

方案

首先，構建了一個針對境內旅游運營側全域的公共底層數據，將不同平臺促銷系統的數據按業務整合到一起，同時劃分不同活動主題，按事件再向上聚合，做專題的數據支撐，統一數據出口。然后通過多維預計算引擎對事實數據進行預計算，構建數倉與應用的管道，從而節省計算成本，并且提升了數據互通和消費的效率，最后建設統一的數據服務中臺，搭配不同端的Web應用。通過豐富的可視化效果，及多樣的分析對比操作，快速、全面地支撐運營業務。

以下為整個產品的功能模塊圖：

圖1 運營專題整體功能模塊圖

如圖所示，運營專題數據的產品化，根據需要解決的問題劃分了多個不同的層次，每一層除其需要面對的核心問題外，還有其領域內其它功能模塊的抽象和擴展，下面將會按照層次劃分逐一介紹各個模塊。

數據倉庫層

數據生產和消費的基礎平臺，是整個數據產品化過程中最核心的角色。數據倉庫的模型建設，不但影響產品化的難易程度及可行性，更是數據一致性等關鍵問題的直接因素，所以為降低使用門檻、統一數據標準、支撐上層更合理的架構，模型的選取就變得尤為重要。

領域內常見的建模方法

① 3NF模型

3NF模型（又叫“范式模型”）是數據倉庫之父Inmon提出的，它用實體加關系的數據模型描述業務架構，在范式理論上符合3NF，是站在全局角度面向主題的抽象。它更多的是面向數據的一致性治理。3NF模型最基本的要素是實體、屬性和關系：

• 實體：相同特征和性質的屬性抽象，用抽象的實體名和屬性名集合共同刻畫的邏輯實體；

• 關系：實體之間的關系；

• 屬性：實體的某種特性，一般實體具有多個屬性。

② 維度模型

維度模型是Kimball提出的。維度模型多為分析和決策提供服務，因此它重點解決快速完成分析，同時提供大規模復雜查詢的響應性能（預聚合），更直接地面向業務。例如熟知的星形模型，以及特殊場景的雪花模型。維度建模最基本的要素是事實和維度：

• 事實表：一般由兩部分組成，緯度和指標，通常理解為“某人在某時間某地點通過某手段做了什么事情”的事實記錄，它體現了業務流程的核心內容；

• 維度表：看待事實的角度，用以描述和還原事實發生的場景，比如通過地址、時間等維度還原業務場景。

③ DV模型（DataVault）

DataVault是Dan Linstedt發起的，是一種介于3NF和維度建模之間的建模方法。它的設計主要是滿足靈活性、可擴展性、一致性和對需求的適應性。它強調建立一個可審計的基礎數據層，主要包括Hub（核心實體）、Link（關系）、Satellite（實體屬性）三個要素。

④ Anchor模型

Anchor模型由Lars. R?nnb?ck提出，是DataVault模型的進一步范式化處理，核心思想是只添加、不修改的可擴展模型，Anchor模型構建的表極窄，類似于K-V結構化模型。它主要包括Anchors（實體且只有主鍵），Atributes（屬性），Ties（關系），Knots（公用枚舉屬性)）。Anchor是應用中比較少的建模方法，只有傳統企業和少數幾家互聯網公司有應用，例如：螞蜂窩等。

運營專題數據如何構建？

隨著促銷系統不斷發展，平臺趨于穩定，再結合各活動類型，及對需求的整理和進一步產品化，選擇了3NF+維度建模為基礎的模型方法論，對數據進行合理劃分和整合，構建了運營專題數據體系。

① 數據規范制定

數據規范的制定也是指標字典和服務層規則引擎抽象的基礎。首先同業務達成共識，制定數據一致性標準，統一口徑。同時將核心指標和個性化指標進行抽象，抽取統一規范定義，例如：月初到月末的整體交易類GMV和補貼類GMV，其原子指標是GMV，其它要素都屬于指標的修飾。

圖2 數據規范抽象示意圖

② 數倉模型架構

將數據分為ODS層、BAS層、FACT層、TOPIC層。

ODS層主要功能：從分布式消息隊列中消費Binlog和Click-log，并對埋點數據進行清洗和業務庫數據還原，并根據需要增量或全量同步到Hive，同時積累歷史數據并保存。

BAS層主要功能：采用3NF建模方法，對整體業務進行概念抽象及適當冗余，在保證數據一致的同時將同屬性實體歸納整合到同一邏輯域。BAS層主要是為了減少數據的不一致，減少存儲空間，響應業務系統的變化，避免更新異常。

FACT層主要功能：采用維度建模方法，根據活動特點及事實場景，對代金券、現金券、促銷等的事件進一步整合。經過對維度的預處理，在使用信息的時候，不但減少時間成本、提高數據的提取效率，又為用戶在Ad-Hoc平臺查詢提供很好的支撐，同時它成為了上層數據應用的關鍵出口。

TOPIC層主要功能：該層建設不是必須的，是針對業務中個性化訴求，根據需要建設專題數據。服務小范圍業務群體和用戶，用來支撐核心業務指標外的某一塊個性化指標和應用。

圖3 數據倉庫模型圖

如圖所示，數倉模型整體架構圖。通過構建運營專題的底層數據，針對數據一致性等問題，在數倉層面上得到了很好的解決，同時在數據提取效率上有很大的提升。數倉建設為接下來的業務支撐打好了充分的基礎。

多維預計算層

預計算層是連接數據和應用之間的管道，是應用層垂直模塊的專項支持。它是在Fact層數據之上的預聚合，強依賴于數倉模型中事實和維度的構建以及預關聯。預計算采用Kylin引擎構建Cube聚合組，來解決取數門檻和數據處理耗時等問題，同是提供多維分析的能力，不但提供了新的Ad-Hoc(Query Engine)平臺，在提高查詢響應的同時，又能為產品帶來更流暢的交互，增強用戶體驗。例如：創建一個交易數據cube，它包含日期（datakey）、用戶（userid）、付款方式（paytype）、購買城市（city）。為滿足不同消費方式在不同城市的應用情況和查看用戶在不同城市的消費行為，建立以下兩個聚合組，包含的維度和方式如圖所示：

圖4 構建cube示例圖

中臺服務層

數據預計算之后，需要分別對PC和移動端提供計算和裝載，并且要針對不同端的特定模塊做特定的開發，為了應對多變的業務邏輯，以及未來的可擴展能力，需要提供可插拔的、統一的服務層，該層主要可以解決如下問題：

• 服務與預計算數據同步，數據模型的修改只影響到預計算層，同時服務層還可以完全感知預計算數據的變化，不需要對服務做開發調整，實現數據變更的同步響應；

• 服務與端解耦，針對不同端產品提供統一數據服務，避免重復開發，同時產品的迭代升級與服務層隔離，應對多變的業務發展和增長；

• 服務擴展能力增強，支持服務的橫向擴展，不影響正常業務的同時提高服務能力，同時在該層實現可抽象通用操作以及規范管理。

總體架構

圖5 運營專題產品架構圖

整個服務由獨立的Web應用端發起請求，通過權限驗證后對中臺發起調用，然后讀取配置中心的配置，由計算引擎對數據進行并行計算，同時規則引擎按業務線和指標修飾詞等生產衍生指標，然后將引擎完成的數據按周期進行快照，存入備忘錄，同時關聯指標字典將數據與文案返回前臺，最后按功能再對數據做可視化處理。下面分別對服務中交互的幾個模塊做簡單的介紹。

配置中心

把系統的各類資源（比如：數據庫、服務地址、緩存等）以及多個環境和具體業務邏輯（比如：業務線、平臺、指標類型），按功能特性抽取出公共的控制的線頭，在需要調整的時候，人為的控制系統。

圖6 配置中心示意圖

如圖所示，用戶通過單獨的配置入口，將系統配置、優化條件判斷、業務線個性化指標配置等信息提交到Server，運行時Client會到Server拉取配置，放入緩存，并定時持久化到本地文件，方便異常中斷或重啟時手動或自動重新加載配置。

指標字典

公司中的很多運營部門指標定義不清晰或不盡相同，但叫法相同（文案），又或者叫法相同指標口徑不同，出現一些對指標的理解不一致，含義不清等問題?；谥笜俗值?#xff0c;不但是指標命名的規范和明確，也是統一計算口徑的落地，接入規則引擎后生成關聯衍生指標，即可自助完成查詢和分析。可見，指標字典的建立，是數據服務平臺的基礎。

圖7 指標字典思維導圖

如圖所示，基于數倉中對數據規范的制定，將指標按業務線、類型、基礎、衍生等劃分為不同類別，并對指標名稱、別名、口徑等信息落地入庫，進行持久化存儲。

規則引擎

運營業務的特點是運營活動規則的多變，需要很多個性化配置。為解決復雜和復合的計算問題（維度和事實的交叉）并降低維護成本，將邏輯從“硬編碼”中將規則抽離，然后根據不同業務線特點按修飾詞進行隔離，提高應用靈活性，簡化架構。

圖8 規則引擎示意圖

① 數據準備規則

在應用數據計算之前把外部數據引入作為規則匹配運算的算子或數據集，例如某活動針對全部用戶做發紅包活動，而在活動中針對新用戶發x面額的紅包，而針對老用戶發y面值的紅包。其規則條件為：紅包金額大于小于等于，且使用地點為上海北京全部；

② 數據計算規則

實現對業務規則的變量和參數化，按指標字典中的指標定義，轉化為計算表達式，使得規則執行的結果作為其他規則條件的計算因子，生成衍生指標。

計算引擎

計算引擎（core模塊）在對數據進行處理時對數據進行了分片，分桶等優化操作，在面對多維度大范圍數據查詢時一定程度上提升了查詢性能，計算模塊的抽取實現了與業務邏輯的解耦，它只負責任務的處理和執行，可僅對性能進行維護和升級，甚至可以維護不同處理方式的多個計算引擎，無需關心業務邏輯。

圖9 計算引擎示意圖

如圖所示，當引擎接收一個時間跨度較大，維度較多的數據時，會先按照時間進行橫向切分，然后將切分的數據按維度組合進行縱向切割，每一組都交由一個線程進行處理，并對該結果數據進行tag標記，然后根據標記在前臺進行整合。

備忘錄

備忘錄是按時間周期對數據計算完成裝載后狀態的快照歷史，是對值和計算規則的持久化。通過備忘錄可以為用戶提供橫向，縱向等對比分析功能，幫助用戶分析趨勢。簡化示意圖如下：

圖10 備忘錄示意圖

數據可視化

面對冰冷的數字，如何將數據組織起來，使其既有吸引力又易于理解？
可視化是解決問題的一種高效的手段，數據是強大的，如果能真正理解其中的內容。
運營專題產品采用了開源的Echarts，通過定制化開發的可視化數據，幫助用戶將數據轉化為可以付諸行動的見解，在提供可視化數據的同時，又為專題數據特定模塊提供特定的降維，對比等線上分析操作。

趨勢對比

通過維度的篩選切換，業務不同視角的核心指標趨勢一目了然，不僅提供不同時間粒度同環比的縱向比對，還提供同級指標的橫向比對，努力做到多角度、全方位的數據呈現。

圖11 產品趨勢對比圖

降維操作

為更好的認識和理解數據，降低復雜度，緩解“信息豐富、知識貧乏”現狀，提供了降維操作，讓原本稀疏分布在各維度的特征聚斂，將某類特性更直接的表現出來。

圖12 產品降維操作圖

指標對比

將業務人員的線下熱操作簡移到線上，通過將維度壓扁拉伸成縱向指標，進行多維指標的對比，并提供明細。

圖13 產品指標對比圖

多維查詢

為支持更好的OLAP分析，發揮預計算層的作用，還提供了關鍵指標解析和多維查詢的功能，是產品對常規性分析的功能補充。

圖14 產品多維查詢圖

總結

在運營專題數據產品化的過程中，將技術轉化為價值，提煉數據內容、為業務賦能是真正的發力點，為發揮數據的最大價值以及帶給用戶更好的體驗，投入了大量的思考與實踐，最終產品的生產投入為現階段帶來了以下收益：

• 數據標準統一：數據指標口徑一致，各種場景下看到的數據一致性得到保障，支撐多個團隊；

• 極大擴展性：服務了內部全運營業務團隊，滿足不同團隊的個性化需求；

• 統一服務：建立了統一的數據服務和中臺服務，支持靈活配置；

• 計算、存儲、研發成本：增強了指標的復用、模型分層、粒度清晰，精簡了數據表的落地量，通過數據分域、模型分層，節省了研發的時間和精力；

• 業務支持：豐富的可視化數據，提供多維、降維、對比等多樣的分析操作，多方位全角度支撐業務。

招聘

團隊長期招聘數據倉庫、數據開發工程師，歡迎對大數據領域感興趣的同學投遞簡歷到yangguang09#meituan.com，期待您的加入。

作者簡介

吉喆，美團點評系統開發工程師，曾就職于新浪，美團，阿里巴巴從事系統開發及數據開發工作，2017年加入美團點評，負責數據倉庫建設和產品開發相關工作。

熱門

大數據

美團點評基于Storm的實時數據處理實踐
美團點評酒旅數據倉庫建設實踐

美團點評

技術團隊

http://tech.meituan.com

長按二維碼關注我們

更多技術博客：美團點評技術博客。

總結

以上是生活随笔為你收集整理的美团点评运营数据产品化实战的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。