導讀：本文是OPPO商業數據研發負責人&技術專家邱盛昌老師帶來的“OPPO商業化數據體系建設實踐”的分享。整體內容圍繞著下圖中垂直劃分的六個部分展開，分別為：數據平臺、數據接入、數據開發、數據治理、數據應用和數據分析，這個圖也概括了典型的數據體系的所有內容。

--

01 數據平臺

數據平臺由公司提供，商業數據研發作為平臺使用方，首要職責是基於公司級的數據平臺下構建商業化數據體系。平臺與業務兩個團隊的分界遵循如下原則：“有則用，不等待，願遷移，可貢獻”。

在實踐中，這個原則在最大程度保證了團隊工程效率的同時，也讓商業數據和數據平臺之間做到了良性互動。

我們會優先利用平臺的已有能力；如果沒有，且無法及時提供，我們堅決自己做；要是後期平臺有了相應的能力，我們也會把業務遷移到平臺；或者把我們的能力提交貢獻給平臺。

1. 開發效率類工具包

開發效率是數據工程團隊優先要保證的目標，為此我們把開發同學日常工作中高頻操作動作抽象成工具來提升開發效率。比如連接登陸計算引擎（Hive、Spark等）、獲取hive表的最大分區、批量操作分區等等。

把這些動作工具化後有以下好處：

• 減少開發過程中機械操作部分，提升開發體驗和效率；
• 減少人工出錯的情況，保證數據安全和質量；
• 工具中統一了操作行為的元數據，方便數據審計和許可權治理等工作。
• 上圖演示了登陸輔助工具：有統一的入口訪問引擎，同時工具提供了自動載入工號和密碼填充，工具在統一記錄審計信息的同時保證了每張表都有歸屬人信息，這在以後的元數據管理中起到巨大的作用。

2. 數據校驗類工具包

數據需求不管是在開發中還是任務上線後，為了保證數據的完整性、一致性、正確性，都需要對數據進行比對驗證和波動監控等數據校驗工作。上圖例子展示了“兩表核對數據”工具在數據波動等問題後自動告警的信息。此類工具設計的重點是將異常定位標識展示完整，將責任人和影響的業務模塊展示清晰，方便相關負責同學評估異常影響和及時排查問題，否則問題就會隱藏在數據中，引起用戶投訴。

3. 可視化輔助工具包

郵件和公司的即時通訊工具TT，是數據觸達用戶的兩個重要通道，用戶隨時隨地可以通過這兩種方式瞭解關註的業務數據。我們開發了可視化輔助工具包來加強數據觸達用戶的效率和可視化能力。TT也擁有類似微信的公眾號、訂閱號、機器人的功能。

首先我們申請了一批公眾號，有針對質量管理的、收入監控的、商業智能和決策支持的，不同角色的用戶關註不同的公眾號就可以收到數據的消息推送。用戶選擇關註不同的訂閱號，可以隨時隨地掌握自己感興趣的主題，比如老闆上班前或假期中就可以看到最新核心指標推送消息。

另外我們將一批機器人賬號放在各類型的TT群中自動發佈公告或者專門告知某個負責人處理相關數據問題，比如負責營銷平臺數據的機器人在每天掃完數據後就會群里發送結果，讓負責的同學去處理。

輔助工具在上述過程中將部分工作流程自動化，比如簡單通過幾個參數配置就可以完成一個郵件數據的可視化圖表配置等。

4. UDF開發原則

公司的數據平臺提供了一些通用的UDF工具包，但是個性化需求的工具包我們會自己研發。我們部門在開發UDF過程中總結出了幾條原則如上圖。對於第一條，使用臨時函數的好處是發佈簡單、影響範圍小，所以能夠快速上線。另外，開發數據的UDF要避開“後端思維”，比如碰到數據異常，要返回NULL而不是把異常拋出去阻斷了程式運行，保障數據質量放在數據校驗步驟來做，而不是UDF來做，如果因為幾條臟數據阻斷了程式運行，會極大影響到任務的SLA，非常不值得。

--

02 數據接入

數據接入的最終形態是全面配置化、中間件化，最好做到流批一體。數據接入可以根據需求在流式和批處理之間自由配置。

1. 出入庫強制校驗數據量

數據鏈路要在源頭入庫時做基本的數據校驗。例如數據量強制校驗，如果導入後不做校驗直接跑數，常會導致後續處理問題頻發。如果一個表導入後為空，會導致後邊的任務在執行時候全部被掛起，或者數據量不正確，後邊任務產出的數據全部是錯的，影響範圍巨大，恢復起來也慢。

2. 欄位儘量全部接入

如果只接入單個需求所需欄位，那麼後續需求要用到此表其他欄位的時候就需要重新再做一次來加欄位，這樣效率會低很多，且容易出錯。

3. 歷史要保留

每天抽取導入的數據可能不一樣，所以歷史分區在緩衝層要保留一段時間，而更長時間的歷史保留應當放在ODS層。抽數一定要做分區表，最好每天一個分區。

4. 數據接入情況介紹

上圖是按照導入導出的SRC和DST分為四類的數據出入倉方式。

--

03 數據開發

數據開發涉及到的內容比較多，本節會圍繞數倉架構展開來講：

• 構建基於維度建模理論的離線數據倉庫系統
• 構建服務於收入監控/實驗/策略/廣告引擎的實時系統

1. 數倉架構

數據源層接入兩大塊數據：廣告行為埋點數據、三品牌OS行為和APP行為埋點數據。三品牌的OS行為，這是廠商特有的數據，比如用戶在手機上安裝了哪些應用，啟動卸載應用等信息；還有一些app行為信息，比如瀏覽器、軟體商店等都會接入。

圖中倉庫層的左邊數據建模的過程，可以分為不同主題。不同業務對主題的劃分也不一樣，但是總體都會分成圖中的4層：接入層、基礎層、模型層和應用層。

倉庫層還會做一些數據治理的動作，包括數據質量、元數據管理、資產管理，都屬於數倉的範疇。針對這些我們做了大量的工作用於資源管控、成本優化和質量規範監控。

還有一些偏底層的數據服務也屬於數倉的範疇，包括定向標簽、排序召回、廣告策略需要的特征數據，數倉負責算好提供給應用方。結算系統因為數據量太大，也只能在數倉進行結算。

模型層和應用層還會以介面的形式提供數據服務，對於廣告特別重要的OCPX也在這裡。

2. 指標體系

主題域的劃分、指標體系建設因不同的業務而採用不同的方法。例如，廣告會按照效果廣告和品牌廣告去劃分，同時結合廣告行業的特點做應用分發、搜索、信息流等的主題建設。圖中展示了廣告的轉化指標建設，整個流程有很多業務過程，會產生大量的數據。數據倉庫模型層一開始只會開發基礎指標，而對於業務KPI相關的業務我們會按照OSM模型來建設指標體系，比如找到業務的北極星指標。

3. 維度建模

維度建模的實踐，我們將它歸納為三個核心觀點，如下圖所示：

比如 “品牌合約模型”的廣告主維度，如果換一個模型也有廣告主維度的話，兩個模型需要使用相同的維度來保證一致性，而且需要取廣告的信息只能從這個表出，而不是再去關聯其他更多的表，這就是一致性維度的簡單理解。一致性事實會保證不同模型之間事實數據可以交叉探查，而且需要保證指標的口徑統一。從圖中的模型也可以看出我們主要採用的是維度建模中的星形模型，這也是最常用的模型。

4. ETL鏈路優化

ETL鏈路開發優化中散佈著很多痛點。針對鏈路優化，為了讓數據高效高質量地跑出來，我們總結了一些經驗，如下圖：

圖中右邊是數據鏈路建設的三種方案。

第一種可以看到不同的報表有各自獨立的基礎模型表。優點是效率高，缺點是實現非常複雜，且不易維護。
第二種是將報表的模型層統一，優點是結構簡單，缺點是不同的模型數據會互相影響，造成跑數時不必要的相互等待。
第三種方案結合前兩種的優點，把模型層中有外部依賴和沒有外部依賴的做解耦單獨建模，另外將比較大的慢表也和其他模型分開做解耦，這樣方案最大程度上保證了較低的複雜度和較好的出數效率。

5. 商業化數據倉庫的評估

按上圖所示，我們通過穩定性、高效性、準確性、維護性和創新性這幾個維度來評估數倉建設的成熟度。

--

04 數據治理

1. 元數據分類

業務元數據主要是業務數據知識，我們把這些業務元數據組織成圖中的四類，來滿足各種角色對於這些知識的使用需求。

技術元數據非常有用，這是做數據治理的前提，比如用於構建應用、影響分析、問題排查等。

2. 各類元數據的用途

下麵三張圖介紹了三類元數據在OPPO的主要用途和部分應用的實例：

Hive和DB的元數據可以用於規範檢查，從表的誕生開始就應該進入了元數據質量監控的範圍， 這是實現治理常態化的重要手段。

調度管理在數倉中是非常重要的一環，調度的質量管控需要通過調度元數據來實現。調度中通常會有複雜的依賴和異常處理，是問題的多發區。提前發現調度問題是保障數據產出的實效性和質量的重要手段。

例子中的研發年報如果要人工統計，對於大的數倉幾乎是不可能完成的任務，因為表的數量龐大。我們利用元數據提升了代碼交付質量、支持技術運營統計。

3. 數據質量管理實施方案

數倉必須自己保證數據質量，不能只靠平臺提供的能力，因為平臺往往不會考慮和業務強相關的內容，可以適當利用平臺的工具來輔助完成數據質量的管理。下圖是我們的質量監控體系。

其中波動監控是一個難點，我們總結了一套方法論，後文會展開來講。下邊的例子展示了質量管理方案實施原則和應用案例，包含了未發佈監控、依賴缺失監控等。

4. SLA準點率提升監控

準點率是數倉交付質量非常核心的一個要求，也是數據開發經常要處理的問題。在實踐中我們形成了一套方法論，這套方法論主要是對報表分級然後採取不同的保證策略。

例子中的核心報表會在凌晨1點就啟動監控，每個整點會發送任務執行進度情況，對於沒有及時完成的任務，24小時值班運維會打電話叫醒負責人，負責人收到報警後及時處理以保證準點率；如果沒有核心報表運行，並且完成時間在合理時間內，負責人則不會被叫醒。

對於需要保證的報表，如何精確地報警很重要。這要求我們需要較為準確地評估預計完成時間。上圖展示如何精確預估完成時間。如果我們預估的完成時間趕不上業務要求的交付時間，24小時值班運維就會通知負責人介入來保證按時交付，哪怕在凌晨。

上圖是非保證的報表的例子。雖然不需要保證在精確的時間點前交付，我們也需要知道執行情況，並且把執行情況通知到負責人，這樣負責人可以隨時隨地掌握這些重要的信息，負責人看到後根據實際情況靈活處理即可。

--

05 數據應用

數據波動監控和廣告歸因是業務中的兩個難點和業務價值高地。

1. 解決波動監控的三大痛點

最大痛點：告警太多，泛濫後容易麻木，相當於沒有告警
第二痛點：準確率不高，誤報、漏報很常見
第三痛點：閾值設置困難，一個閾值不能適用於所有場景，全部個性化閾值又太多
我們結合商業化數據的特點，形成了一套波動監控體系和方法論。

廣告位的波動監控能夠發現一些廣告播放系統的bug，這塊我們做的也比較多。

按應用監控方面，因為每個廣告主的投放計劃不一樣，所以波動經常是合理的，比如客戶不想投了、賬戶沒錢了等，會造成數據波動，這種波動監控意義不大，發現也無法採取措施。

但是提前發現有動作的節點是有價值，為此我們抽象出三個可以監控的東西：撞線、啟投、改價，這些報警可以指導業務動作，比如餘額快沒了，銷售就會提前聯繫廣告主充值。競價被打敗沒有拿到流量，及時報警出來通知廣告主改價。

上面提到我們對廣告位波動做了很多事情，形成了一套有效的識別波動的方法。通過環比上個周期、同比昨天、同比上周，這三個條件組合判斷後，會非常準確地識別有效波動。另外，閾值設定要按照金額分級，例如圖中的例子，小廣告主波動閾值會大；100W以上的大廣告主的閾值會小一些。通過這套方法論和金額分級經驗，很好地解決了波動監控的三大痛點。

下圖是關於撞線、啟投、改價的例子：

這類告警確定性很強，很容易就可以判斷，往往不需要反覆調閾值。

2. 廣告歸因服務

廣告歸因是廣告業務特有的內容，對OPPO非常重要。上圖是歸因服務的整體架構。

圖中右邊是轉化數據，左邊是廣告數據，中間是歸因中台。轉化加廣告數據作為我們歸因中台的輸入數據，歸因中台的作用就是怎麼把轉化歸因到廣告的數據中，比如這一次付費是哪一次廣告點擊帶來的，有可能歸因出來是上個月1號的那次點擊下載APP帶來的。歸因中台從下到上分為三層：數據層、策略層、服務層。

數據層是準確歸因的底層基礎，ID-Mapping負責把互聯網中的用戶映射成一個實體用戶，口徑標準化提升統一口徑提升數據質量，反作弊模塊會從流量中刨除作弊流量。

策略層是歸因的邏輯層。歸因策略圍繞著廣告點位、歸因周期和歸因規則來組織，以求做到歸因結果儘量準確。策略主要來自行業經驗，比如不同的點位和流量的歸因周期應該是多少等等都會在這一層管理。

服務層對外提供標準化口徑的實時和離線歸因服務，支撐了對各方的歸因和運營服務。

--

06 數據分析

1. 數據提取

通過培訓來賦能業務，讓更多的人有能力自助完成數據提取和簡單的分析工作。這樣也能節省數倉開發團隊的工作負載，讓開發團隊能聚焦在建設高質量的數據模型上。

2. 微型分析報告

例子中的日報，內容不多但是非常豐富，收入情況和效率指標都算好了，同時分析了波動情況，業務負責人隨時隨地可以看到這個報告，並且馬上可以判斷業務健康情況採取決策行動。

--

07 精彩問答

Q：cdm建模規範中派生指標和泛化指標構建數據集的時候有沒有約束性的規範？

A：有命名的約束，另外我們通過id唯一確定一個指標。命名也要唯一，防止它有多個人來構建同一個指標。唯一性之外我們還會約束如何命名：我們有系統告訴你應該怎麼命名，有一些經驗在這裡面，它會提供一些詞根，或者是歷史的統計信息，也就是大多數人如何命名某個指標。

Q：我們的流批一體用的是一套還是兩套引擎？

A：我們當前只在接入層實現了流批一體，是公司的數據平臺提供的這個能力，也就是mysql到hive，這裡可以做到流批一體，只有一套程式，再往後的流批一體我們還在探索，沒有實現。

Q：我們平臺有沒有代碼掃描類似的功能？

A：其實這個取決於你自己的規則。我們的代碼可以存在hive中的一個欄位值中，所以我們可以根據規則去做正則，比如掃一下這裡邊的中文是不是太少了，說明註釋可能太少會導致業務含義缺失等，也可以檢查有沒有做空值處理，根據自己的規則來做處理就好。

今天的分享就到這裡，謝謝大家。
本文首發於微信公眾號“DataFunTalk”。