58同城使用者行為數倉建設及實踐

轉載：https://mp.weixin.qq.com/s?__biz=MzA5MTc0NTMwNQ==&mid=2650726003&idx=2&sn=47fc58e55321b85c36058a57a52bb8b8&chksm=887dc305bf0a4a131ed74b4af0e6d9417bfcaaf364191a2b56084f7ffe4299b15e30534621f4&scene=126&sessionid=1607916712&key=7699cc7e7be7dcfc4df92b489d2eb24d431389067f5914fef18081ec350258bcd42bb12f47e13c654047eaa1c0220a33743d94fab6463c5e49c614e39b99abd1b33c19bb3564b35a354565435f07a9499aee58de576bd0223891ba4e4b3ad67dbc56ff67bc2c9d16ccca522321f5a0b233a3a1d97f65aef1435e727f5a070aef&ascene=1&uin=MjU3MjY2MzkwNA%3D%3D&devicetype=Windows+10+x64&version=62090523&lang=zh_CN&exportkey=AUIrhd4hCz0ztR56SqFJZDI%3D&pass_ticket=2giLqav8zTXBKZAxT55LVi4h9%2BpMh38M4yOwRrkPcJZ7rI3%2B%2FtLnwqCjNpqH0gfq&wx_header=0

背景

隨著58業務體系的不斷建設與發展，資料分析與應用需求越來越豐富，給資料倉儲的建設工作帶來了很大的挑戰。

全站行為資料倉儲建設過程中，我們總結的問題包括如下幾點：

(1) 資料體系架構已經無法支援業務的快速迭代，資料整合的開發、維護成本高；

(2) 資料業務知識散亂，資料分析與應用成本高；

(3) 資料質量定義模糊，缺乏有效統一的資料質量監控體系；

(4) 缺失資料建設規範，資料開發、表結構定義不統一，資料任務、資料表維護成本高。

綜上，全站行為資料倉儲的建設，需要在現有的大資料平臺基礎上，借鑑網際網路行業通用的維度建模方法論，構建架構合理，分層清晰，具有統一資料規範的全站行為資料倉儲。

 

大資料領域建模綜述

1. 為什麼需要資料建模

資料倉儲是一個面向主題的、整合的、時變的、非易失的資料集合。資料倉儲中的資料需要進行有序、有結構地分類組織和儲存。通過建立適合業務和基礎資料儲存環境的模型，可以帶來以下優點：

(1) 效能：快速查詢資料，減少資料的I/O吞吐；

(2) 成本：減少資料冗餘，計算結果複用；

(3) 效率：改善使用者的使用資料體驗，提高使用資料效率；

(4) 質量：改善資料統計口徑的不一致性，減少資料計算錯誤的可能性。

 

2. 典型的資料倉儲建模方法論

行業內，典型的資料倉儲建模方法論主要分為以下幾種：

(1) ER模型——全企業的高度設計一個3NF模型，描述企業業務。

a) 高層模型：高度抽象，主要的主題以及主題間的關係

b) 中層模型：細化主題的資料項

c) 物理模型：基於效能和平臺特點進行物理屬性的設計，如表合併，分割槽設計

(2) 維度模型——為分析決策需求服務

a) 選擇需要進行分析決策的業務過程；

b) 選擇粒度；

c) 識別維表；

d) 選擇事實。

(3) Data Vault模型——ER模型的衍生，實現資料整合。

a) Hub：企業核心業務實體；

b) Link：Hub之間的關係。Hub的代理鍵、裝載時間、資料來源組成；

c) Satellite：Hub的詳細描述內容。

(4) Anchor模型——k-v結構化模型

a) Anchors：類似Hub，只有主鍵；

b) Attributes：類似Satellite,規範化，全部k-v結構化；

c) Ties：描述Anchors的關係。單獨用表來描述；

d) Knots：可能在多個Anchors中公用的屬性的提煉。

全站行為資料倉儲落地建設實踐過程中，參考網際網路行業內採用廣泛的維度建模方法論，結合58商業自身特點，分析業務環境構造資料倉儲底層資料基礎，再按照實際的應用需求構造資料倉儲上層資料的方式進行資料倉儲的建設。

 

全站行為資料倉儲建設實踐

下圖為資料倉儲中全站行為資料部分資料倉儲體系架構圖：

_

_

_

_

圖1 全站行為資料架構圖

1. 全站行為資料概述

全站行為資料是指在主站資料內，一次帖子檢索過程，對應的使用者瀏覽、點選、互動行為資料集合。其中使用者行為是指：

(1) 主站列表頁主列表--> 使用者瀏覽；

(2) 主站詳情頁展現-->使用者點選；

(3) 收藏、撥打電話、投遞簡歷-->使用者互動|效果。

目前全站行為資料規模明細資料日均2.5T。

 

2. 全站行為資料倉儲構建原則

全站行為資料倉儲建設中，逐步借鑑和沉澱的資料倉儲構建原則如下：

(1) 底層業務的資料驅動為導向同時結合業務需求驅動。

(2) 便於資料分析。

a) 遮蔽底層複雜業務；

b) 簡單、完整、整合的將資料暴露給分析層；

(3) 底層業務變動與上層需求變動對模型衝擊最小化。

a) 業務系統變化削弱在運算元據層；

b) 結合自上而下的建設方法削弱需求變動對模型的影響；

c) 資料水平層次清晰化。

(4) 高內聚鬆耦合。

a) 主題之內資料高內聚；

b) 主題之間資料鬆耦合。

(5) 構建倉庫基礎資料層

a) 使得底層業務資料整合工作與上層應用開發工作相隔離，為倉庫大規模開發奠定基礎；

b) 倉庫層次更加清晰，對外暴露資料更加統一。

 

3. 資料倉儲架構分層思想

資料倉儲構建過程中，採用的分層思想，各層的功能及建模方式和原則介紹如下。

(1) ODS層

    功能：

a) ODS層是資料倉儲準備區；

b) 為DWD層提供基礎原始資料；

c) 減少對業務系統影響；

   建模方式及原則：

a) 資料保留時間根據實現業務需求而定；

b) 資料清洗轉換，統一資料定義；

c) 按主題邏輯劃分；

d) 源系統以增量方式經過ETL到ODS；

e) 可以分表進行週期儲存，儲存週期不長。

(2)  DWD層

    功能：

a) 為APP層提供來源明細資料；

b) 提供業務系統細節資料的長期沉澱；

c) 為未來分析類需求的擴充套件提供歷史資料支撐；

d) 可以是一些寬表，滿足特定查詢、資料探勘應用。

    建模方式及原則

a) 保持粒度一致；

b) 指標事實與ODS基本保持一致。

(3)  APP層

    功能：

a) 對接資料分析需求，提供快速查詢、支援。

    建模方式及原則：

a) 面向業務、面向分析；

b) 保持資料量小，快速查詢、分析；

c) 維度建模，維度+指標彙總；

d) 支援資料重跑；

e) 不分表儲存。

 

4. 模型實施過程

全站行為資料倉儲建設過程，整體資料建設模型實施過程如下：

(1) 充分的業務調研和需求分析，決定後續資料倉儲模型構建過程的正確性。

(2) 資料總體架構設計，構建統一、合理、清晰的資料倉儲架構。

(3) 詳細設計。抽象資料需求，保證資料需求&問題解決的完備性。

(4) 程式碼開發和測試。

(5) 資料DIFF。

a) 模型迭代-欄位DIFF，對迭代過程中，模型中非迭代的每個欄位的正確性做迭代前後DIFF，保證欄位級資料質量；

b) 模型構建-指標DIFF，對模型構建中，模型中的業務資料指標進行DIFF，保證構建過程符合業務邏輯。

(6) 資料驗收。從業務邏輯與模型構建方法過程保證資料模型落地的正確性。

a) 欄位填充率；

b) 使用者行為串聯率；

c) 資料邏輯驗證。

(7) 編寫Wiki，構建統一的業務、資料知識體系，降低後續資料使用、維護成本。

(8) 資料上線；

a) 資料作業運維；

b) SLA質量保證。資料產出時效性、關鍵業務邏輯指標驗證，保證資料可用性、穩定性。

 

5. 資料倉儲建設規範

全站行為資料建設過程中，從表規範、編碼規範來減低模型後續開發、維護成本。

1) 表規範

1、表命名規範如下：

(1) 表命名格式：[層次]_[主題][_表內容]_[分表規則]；

(2) 表命名格式：T_[層次]_[主題][_表內容]；

(3) 臨時表命名格式：[tmp]_所屬程式名_[自定義序號1…10]或[temp]_[操作者縮寫]_YYYYMMDD_[表內容]；

(4) 檢視命名格式：View_[表名]_[表內容]。

2、表命名解釋如下：

(1) 層次：ODS，DWD，APP；

(2) 表內容

a) 表名、檢視名總長度不超過64字元；

b) 儘量詳盡說明表具體內容。

(3) 分表規則

a) 日表YYYYMMDD；

b) 月表YYYYMM；

c) 日彙總DS，月彙總MS，日累計DT，月累計MT。

3、欄位規範：

(1) 命名規範

a) 必須使用小寫字母,並採用下劃線分割；

b) 欄位名禁止超過 32 個字元；

c) 欄位名必須見名知意。命名與業務、產品線等相關聯；

d) 欄位名禁止使用 HIVE 保留字。

(2) 型別規範

a) 區分使用 TINYINT、SMALLINT、INT、BIGINT 資料型別,；建議使用 TINYINT 代替 BOOLEAN, 提高擴充套件性和型別轉換相容性；儘量使用低儲存資料型別以提高執行效率；

b)  金額欄位統一使用DECIMAL，時間欄位(精確到十分秒)欄位統一使用TIMESTAMP以提升比較效率， 分割槽欄位及日期欄位（沒有時分秒）使用 String（格式統一為 yyyyMMdd）。

2) 編碼規範

1、程式程式碼：每層一個程式碼目錄，用於存放對應層的模型開發工程。

2、HQL程式碼：

(1) 使用 left semi join 代替 in/exists；

(2) join 時小表儘量放在左邊，如小表足夠小可使用 map join，hive 已支援自動判斷大小表；

(3) 排序儘量使用 distribute+sort 組合，避免全表 order by；

(4) 儘量使用靜態分割槽，提升執行效率；例行補數建議使用動態分割槽簡化程式碼；

(5) 慎用笛卡爾積 join，卡歷史資料建議使用日期維度表作笛卡爾積，以並行迴圈操作；

(6) 儘量使用視窗函式、udf 簡化 sql 邏輯，提升程式碼可讀性；

(7)  join/group by/distinct 注意處理 NULL 值，儘量避免資料傾斜；

(8) union 會去重, 不用去重時使用 union all；

(9) 表查詢如果是分割槽表, 儘量加上分割槽限制。

 

總結和展望

在全站行為資料建設過程中，

(1) 初步構建相對合理的資料體系結構，能夠快速支援資料的整合，降低了業務迭代變化對資料模型的衝擊；

(2) 業務知識體系初步建立，降低資料使用成本；

(3) 資料質量監控體系初步建立，能夠對核心欄位和資料指標進行監控，基本覆蓋核心資料應用分析場景。

後續將圍繞以下幾點繼續進行資料建設：

(1) 資料完整性：推進曝光資料覆蓋範圍，持續整合效果資料，提高全站行為資料內容豐富度；

(2) 資料質量：圍繞資料產出穩定性與時效性，持續優化已有資料作業。