美團點評營運資料産品化實戰

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

背景

美團點評作為全球最大的生活服務平台，承接超過千萬的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拉取配置，放入緩存，并定時持久化到本地檔案，友善異常中斷或重新開機時手動或自動重新加載配置。

名額字典

公司中的很多營運部門名額定義不清晰或不盡相同，但叫法相同（文案），又或者叫法相同名額口徑不同，出現一些對名額的了解不一緻，含義不清等問題。基于名額字典，不但是名額命名的規範和明确，也是統一計算口徑的落地，接入規則引擎後生成關聯衍生名額，即可自助完成查詢和分析。可見，名額字典的建立，是資料服務平台的基礎。

圖7 名額字典思維導圖

如圖所示，基于數倉中對資料規範的制定，将名額按業務線、類型、基礎、衍生等劃分為不同類别，并對名額名稱、别名、口徑等資訊落地入庫，進行持久化存儲。

規則引擎

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

圖8 規則引擎示意圖

① 資料準備規則

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

② 資料計算規則

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

計算引擎

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

圖9 計算引擎示意圖

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

備忘錄

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

圖10 備忘錄示意圖

資料可視化

面對冰冷的數字，如何将資料組織起來，使其既有吸引力又易于了解？

可視化是解決問題的一種高效的手段，資料是強大的，如果能真正了解其中的内容。

營運專題産品采用了開源的Echarts，通過定制化開發的可視化資料，幫助使用者将資料轉化為可以付諸行動的見解，在提供可視化資料的同時，又為專題資料特定子產品提供特定的降維，對比等線上分析操作。

趨勢對比

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

圖11 産品趨勢對比圖

降維操作

為更好的認識和了解資料，降低複雜度，緩解“資訊豐富、知識貧乏”現狀，提供了降維操作，讓原本稀疏分布在各次元的特征聚斂，将某類特性更直接的表現出來。

圖12 産品降維操作圖

名額對比

将業務人員的線下熱操作簡移到線上，通過将次元壓扁拉伸成縱向名額，進行多元名額的對比，并提供明細。

圖13 産品名額對比圖

多元查詢

為支援更好的OLAP分析，發揮預計算層的作用，還提供了關鍵名額解析和多元查詢的功能，是産品對正常性分析的功能補充。

圖14 産品多元查詢圖

總結

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

資料标準統一：資料名額口徑一緻，各種場景下看到的資料一緻性得到保障，支撐多個團隊；
極大擴充性：服務了内部全營運業務團隊，滿足不同團隊的個性化需求；
統一服務：建立了統一的資料服務和中台服務，支援靈活配置；
計算、存儲、研發成本：增強了名額的複用、模型分層、粒度清晰，精簡了資料表的落地量，通過資料分域、模型分層，節省了研發的時間和精力；
業務支援：豐富的可視化資料，提供多元、降維、對比等多樣的分析操作，多方位全角度支撐業務。

招聘

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

作者簡介

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