數據倉庫體系規划及實施流程


一、前言

數倉規划是數倉建設的藍圖,涵蓋從需求分析開始到最終的數倉評估驗收整個環境;數倉規划之所以重要,是因為它是描述了數據流動的概念性框架,為元數據管理奠定了基礎,對數據加工過程的理解、數倉建設的交流分享、數據的使用和問題排查、數倉健康度的評估都提供了極大的幫助。

需要強調的是本節是從宏觀上描述數倉的框架,具體到數據模型的細節對比、存儲選型和管理、接入數據源管理等數倉建設的周邊在本節不涉及。通過本節的閱讀,你將了解到以下知識:

  • 從業務矩陣的設計(宏觀、微觀)、橫向的分層、縱向的分線到主題划分等角度解構數倉;

  • 數倉建設的實施流程。

二、規划

1、矩陣

分宏觀和微觀來看,宏觀的是公司的整體業務布局,微觀的是產品的業務過程布局和業務過程的維度分解交叉信息。

2、宏觀矩陣

宏觀矩陣描述的是公司的業務線和對應的數據狀況,其行和列一般分別對應着業務主題和數據主題。

1)業務主題對應着公司的業務線布局,比如電商、游戲、視頻、應用商店、新聞資訊、瀏覽器等。

2)數據主題根據抽象的程度和視角有不同的取法:

  • 一般取業務線中用戶對內容的消費或者相關行為,比如曝光、點擊、消費、播放、分享等,對這些行為的划分又可分為原生行為主題(通用和業務相關)、衍生行為主題(留存、活躍、流失等),這種划分方法更多的取自數據的底層和公共層,因為高層的數據都是多行為的匯總。

  • 對數據主題的另外划分方式參加分主題部分,這種划分方法更多的取自數據的高層。

太完整了!無懈可擊的數據倉庫體系規划及實施流程

引自《數據倉庫實踐之業務數據矩陣的設計-木東居士》

3、微觀矩陣

微觀矩陣描述的是主題和對應的維度關系,下面以常見的內容消費和用戶主題兩個維度來看微觀矩陣的規划。

太完整了!無懈可擊的數據倉庫體系規划及實施流程

-w698

業務過程描述的一般是對內容的消費抽象,可以是原子的,也可以是抽象的,比如卡片曝光維度的划分可以從以下兩個大方向入手:

  • 通用標識維度(版本、機型、渠道、網絡、時間等);

  • 業務過程維度:消費者等級、消費位置、消費路徑、其它等。

4、分層

ODS->DW->DM->DA(ADS)層是如何划分的,分層的原因(引自《一種通用的數據倉庫分層方法-木東居士》):

  • 清晰數據結構:每一個數據分層都有它的作用域和職責,在使用表的時候能更方便地定位和理解;

  • 減少重復開發:規范數據分層,開發一些通用的中間層數據,能夠減少極大的重復計算;

  • 統一數據口徑:通過數據分層,提供統一的數據出口,統一對外輸出的數據口徑;

  • 復雜問題簡單化:將一個復雜的任務分解成多個步驟來完成,每一層解決特定的問題。

5、層划分

一個完整數倉分層演示圖如下:

太完整了!無懈可擊的數據倉庫體系規划及實施流程

一個典型的數倉分層樣例:

太完整了!無懈可擊的數據倉庫體系規划及實施流程

-w730

6、分層依據

分層的依據在ods、da、dim層一般無歧義,關鍵在dw層的分層依據,也是數據倉庫分層建設的核心。

太完整了!無懈可擊的數據倉庫體系規划及實施流程

每層划分的依據如下:

  • ods層:存放原始數據信息,原則上不進行任何的數據清晰,和數據源保持一致;

  • dw層:數據公共層,是數倉建設的重點,一般是日志子表和一些寬表,主要完成數據的清洗、轉換等;

  • dm層:數據集市層,是最直接體系數據資產的層,一般是匯總數據,現在已經逐步弱化,面向挖掘、數據分析等;

  • da層:數據應用層,高度匯總數據,主要用於報表展示。

7、分線

分線也分宏觀和微觀,宏觀的是整體的業務線,比如應用分發線、商業智能線、游戲運營線、廣告流量線等;微觀的是某個app或者某個具體的線,本節介紹的是app的數據線。分線和分主題有很多相似的地方,只是看待數據的角度不同,分主題是從數據內容分類和對外服務的角度看,類似商品分類;而分線是從數據生產加工過程的角度來看,類似業務生產流水線。

8、用戶主線

反映整個app的用戶規模,比如整個app的活躍、累積活躍、新增、留存、回流、流失。

9、用戶群線

滿足某些行為的用戶群的追蹤,目的是為了進行個性化的運營等活動,該線的升華擴展是用戶畫像。

10、內容消費

提供的消費實體的曝光、點擊、生成、轉化等,以及內容的累積消費、消費排行等都屬於內容線。

11、狀態線

一般會作為輔線存在,相當於維表的存在,狀態線一般又分為以下幾種:

  • 天表全量用戶狀態,會加入一些修正,以及基於天全量的累積表的快照;

  • 全量用戶信息維表;

  • 開關操作狀態線;

  • 記錄開關狀態變更記錄,得到當前用戶的開關狀態快照,是多態記錄的一種特殊情況;

  • 添加刪除狀態線;

  • 記錄用戶的添加刪除等操作,得到當前用戶操作結果的保有快照;

  • 其它,比如登錄狀態、用戶等級等。

12、商業化線

商業化線相關的與收入相關的,比如cp合作、廣告位、推廣位、訂單、會員充值等。

需要說明的是本系列的數倉的主要介紹的是流量型產品形態、更多的是關注用戶規模,所以主線是是關於用戶的,而對於其它的產品形態,比如購物類、充值消費類的則主線可能是商業化線等。此外作為用戶流量型產品,還隱藏着另外一個更加常用的線:自查線,每個主題的自查明細表,基於event_id或者參數的展開,但是沒有參數值的組合過濾。(自查線這個似乎沒有必要)

下圖是一張數倉的分線演示圖,每個框是一張表,不同顏色的框串聯成各自的數倉線。

太完整了!無懈可擊的數據倉庫體系規划及實施流程

13、分主題

在進行分矩陣設計的時候牽涉到分行和列的業務主題,此處詳細介紹下數據主題的設計,本部分的設計是從高層次上的。

主題划分的一些依據:業務過程(或子過程,比如訂單)、ER中的E(或者R,比如商品主題)、數據服務的對象(運營主題)、數據的用途(比如商業);分主題也即數據集市,根據業務形態的不同,會衍生出不同的主題,但以下主題在app中廣泛存在:

  • 用戶主題(也即大盤:新增活躍、留存);

  • 內容主題(具體提供的服務形式,也可以理解為產品主題,含曝光、點擊、分享等用戶消費傳播行為);

  • 運營主題(可能合並到某個內容主題上,比如活動、通知、彈窗、授權、分享等);

  • 商業化主題(廣告、訂單等通常用於結算);

  • 技術主題(故障率、崩潰率、准確率等衡量技術指標)。

備注:

  • 社交主題可以合並到內容主題也可以合並到運營主題,需要視app的具體特性和重視程度確定;

  • 數倉的分主題主要體現在數據集市層,而數據集市層可能會因為使用比如kylin等多維分析工具被弱化。

14、用戶主題

用戶主題是產品的盤子,就像家店鋪,多少人使用就像多少顧客。基於用戶主題的常見統計有整體的新增、活躍、累積活躍、新增留存、活躍留存等大盤數據,以及對某些關鍵行為的用戶的后續追蹤,還有某些核心過程的PUV、轉化漏斗等。

15、內容主題

內容主題是盤子里東西的消費狀況,就像提供的菜單,每個菜被多少人點了。基於內容主題的常見統計有針對內容(文章、視頻、商品等)的各種消費行為(曝光、點擊、購買、下載等)的次數、人數、時長、金額等按不同維度的度量統計。常見的維度拆分有時間拆分、地域拆分、位置(人貨場模型中的場)拆分、畫像拆分、渠道拆分等,對度量的統計又有累積、非累積、TopN等。

16、運營主題

廣告、促銷、活動等一切由於運營活動相關本身的數據統計,以及運營活動對其它主題數據的影響衡量。

17、營收主題

營收的來源主要分為以下幾種:

1)流量廣告

  • 商務合作;

  • 優惠券。

2)充值消費

  • 會員充值;

  • 訂單、打賞等。

流量廣告的數據主要產生於用戶行為,而充值消費的數據主要來自業務庫相關。

以上四個主題是在常見應用上通用的主題,其它的主題比如技術主題,在某些有明顯的技術指標對比的產品上會占主要的地位,比如文字識別類應用的識別准確率、搜索類產品的搜索滿意度、語音智能助理類的會話完成率等。這些產品上技術指標和用戶的體驗密切相關,是產品未來發展重要的參考方向,因此會強化出來做數據主題。另外如引流類或者與其他app有頻繁的引流拉起等應用的數據體系建設上,也會單獨拿出跳轉對接數據做主題分析。總之,主題的划分並不是確定不變的,需要根據業務的具體形態和重點度量的指標等進行建設。

以上的矩陣、分層、分線、分主題的規划只是從不同的角度來看數據框架,本質都是對數據流圖的一種拆解,差異在拆解的數據視角。

太完整了!無懈可擊的數據倉庫體系規划及實施流程

三、實施

1、需求分析

了解業務過程,每個業務過程的參與實體和各實體可能的分析維度等信息; 了解數據源組成,有哪些數據源、數據的更新周期;預構建指標體系,了解指標的分類,分析維度、時效性要求;了解可能的擴展需求,比如畫像寬表。需求分析階段是建立數倉的概念模型,明白數倉要支持的大致需求,雖然數倉建設並不要完全滿足業務需求,在建設的過程中肯定要有取舍,但第一步進行需求分析能保證在數倉建設過程中不致於偏離目標太多,避免建設爛尾或者好看不好用的綉花枕頭。

2、指標體系

此部分會另外開專題介紹,指標體系一般分為三類:

  • 用戶增長體系

  • 流量體系

  • 營收體系

每個體系內分析數據的維度、更新周期等。指標體系的建立是需求分析環節需要重點完成的一步。

3、模型選擇

模型選擇環節要根據需求分析階段的結論,在ER模型、維度建模等基本的建模思想中選擇一種建模思想,比如說選擇了維度建模,要進一步根據需求分析中相關的業務過程和維度視角,在星型模型、雪花模型、星座模型中選擇一種模式。這個過程要充分的結合業務的實際狀況、開發人力和成本、各模型的優缺點等因素進行綜合分析,是關系到建模是否成功的關鍵環節。需要說明的是,在快速迭代的互聯網行業,業務規則可能經常變化,而對於不同粒度水平進行度量和監控,進而快速響應的需求卻基本保持不變,比如層級的時間粒度(年、月、周、日、小時)、層級的地理粒度(大區、省、市、區縣、商圈)以及基於產品自身屬性的層級粒度(大類、子類)。基於這種特性,互聯網行業中廣泛采用維度建模的思想,同時為了使用的方便,又以星型模型和雪花模型較多。

4、標准規划

標准規划是對數倉建設過程各階段中涉及的對象、屬性、關系、鍵、交付物等進行規范定義,同時制定標准落地方式或者檢查的方式。比如表命名規范、字段命名規范、任務命名規范、調度依賴規范、代碼開發規范等。需求強調的是,這一步看似無關緊要,也往往直接被忽略跳過,但好的標准規划能為建設高質量數倉的保駕護航,對數倉質量、健康度的保持都大有裨益。

5、開發部署

包含表設計、代碼開發、調度開發和告警開發等,對應本系列的第三節和第四節。

1)事實表和維表設計

  • 維表設計

2)代碼開發

  • 流程、審核機制、回退機制

3)調度開發

  • 依賴任務的配置

  • 回跑機制

  • 任務權限管理

4)告警開發:

  • 數據量異常,某些細分維度、字段值、計算指標異常的告警措施

  • 任務失敗、等待超時、執行超時、上下線、上游重跑等告警措施

開發部署階段完成了數倉建設的邏輯模型和物理模型設計階段,是數倉建設的主要工作內容。

6、評估驗收

對應的問題包含在相關問題介紹部分,需要進一步思考數倉開發的交付物是什么。

  • 數據字典

  • 指標口徑的定義

  • 核心表和其用途

  • 數據流圖和重要指標的出口

  • 業務變動對數倉的影響,比如某些手工維護的維表需要根據業務變動進行相應的更新

四、總結

本篇從業務矩陣、分層、分線和分主題等方面對數倉的規划做了簡要的描述。這些方面的差異只在於剖析數倉的角度,其目的是一致的,即為了清晰地梳理數據體系、洞察數據狀態、以及更好地規划未來數據地圖,從而更好的服務於各個業務需求方(BI報表、數據分析、用戶畫像等);本節最后簡要的介紹了數倉開發的基本流程。

進一步思考:

  • 數倉規划帶來的好處,方便傳承和交流,便於快速洞察數倉的健康狀態;

  • 數倉健康度的概念和計算方式。

 

Reference:

https://www.toutiao.com/a6777813068706480647/


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM