作者介紹
水大人,數據開發(fā)小哥,愛折騰、愛記筆記,熱衷方法論提煉和效率提升。雖然半路出家,但致力于全棧遠景。《七天數據埋點之旅》系列作者。
一、前言
數倉規(guī)劃是數倉建設的藍圖,涵蓋從需求分析開始到最終的數倉評估驗收整個環(huán)境;數倉規(guī)劃之所以重要,是因為它是描述了數據流動的概念性框架,為元數據管理奠定了基礎,對數據加工過程的理解、數倉建設的交流分享、數據的使用和問題排查、數倉健康度的評估都提供了極大的幫助。
需要強調的是本節(jié)是從宏觀上描述數倉的框架,具體到數據模型的細節(jié)對比、存儲選型和管理、接入數據源管理等數倉建設的周邊在本節(jié)不涉及。通過本節(jié)的閱讀,你將了解到以下知識:
- 從業(yè)務矩陣的設計(宏觀、微觀)、橫向的分層、縱向的分線到主題劃分等角度解構數倉;
- 數倉建設的實施流程。
二、規(guī)劃
1、矩陣
分宏觀和微觀來看,宏觀的是公司的整體業(yè)務布局,微觀的是產品的業(yè)務過程布局和業(yè)務過程的維度分解交叉信息。
2、宏觀矩陣
宏觀矩陣描述的是公司的業(yè)務線和對應的數據狀況,其行和列一般分別對應著業(yè)務主題和數據主題。
1)業(yè)務主題對應著公司的業(yè)務線布局,比如電商、游戲、視頻、應用商店、新聞資訊、瀏覽器等。
2)數據主題根據抽象的程度和視角有不同的取法:
- 一般取業(yè)務線中用戶對內容的消費或者相關行為,比如曝光、點擊、消費、播放、分享等,對這些行為的劃分又可分為原生行為主題(通用和業(yè)務相關)、衍生行為主題(留存、活躍、流失等),這種劃分方法更多的取自數據的底層和公共層,因為高層的數據都是多行為的匯總。
- 對數據主題的另外劃分方式參加分主題部分,這種劃分方法更多的取自數據的高層。
引自《數據倉庫實踐之業(yè)務數據矩陣的設計-木東居士》
3、微觀矩陣
微觀矩陣描述的是主題和對應的維度關系,下面以常見的內容消費和用戶主題兩個維度來看微觀矩陣的規(guī)劃。
-w698
業(yè)務過程描述的一般是對內容的消費抽象,可以是原子的,也可以是抽象的,比如卡片曝光維度的劃分可以從以下兩個大方向入手:
- 通用標識維度(版本、機型、渠道、網絡、時間等);
- 業(yè)務過程維度:消費者等級、消費位置、消費路徑、其它等。
4、分層
ODS->DW->DM->DA(ADS)層是如何劃分的,分層的原因(引自《一種通用的數據倉庫分層方法-木東居士》):
- 清晰數據結構:每一個數據分層都有它的作用域和職責,在使用表的時候能更方便地定位和理解;
- 減少重復開發(fā):規(guī)范數據分層,開發(fā)一些通用的中間層數據,能夠減少極大的重復計算;
- 統(tǒng)一數據口徑:通過數據分層,提供統(tǒng)一的數據出口,統(tǒng)一對外輸出的數據口徑;
- 復雜問題簡單化:將一個復雜的任務分解成多個步驟來完成,每一層解決特定的問題。
5、層劃分
一個完整數倉分層演示圖如下:
一個典型的數倉分層樣例:
-w730
6、分層依據
分層的依據在ods、da、dim層一般無歧義,關鍵在dw層的分層依據,也是數據倉庫分層建設的核心。
每層劃分的依據如下:
- ods層:存放原始數據信息,原則上不進行任何的數據清晰,和數據源保持一致;
- dw層:數據公共層,是數倉建設的重點,一般是日志子表和一些寬表,主要完成數據的清洗、轉換等;
- dm層:數據集市層,是最直接體系數據資產的層,一般是匯總數據,現在已經逐步弱化,面向挖掘、數據分析等;
- da層:數據應用層,高度匯總數據,主要用于報表展示。
7、分線
分線也分宏觀和微觀,宏觀的是整體的業(yè)務線,比如應用分發(fā)線、商業(yè)智能線、游戲運營線、廣告流量線等;微觀的是某個App或者某個具體的線,本節(jié)介紹的是app的數據線。分線和分主題有很多相似的地方,只是看待數據的角度不同,分主題是從數據內容分類和對外服務的角度看,類似商品分類;而分線是從數據生產加工過程的角度來看,類似業(yè)務生產流水線。
8、用戶主線
反映整個app的用戶規(guī)模,比如整個app的活躍、累積活躍、新增、留存、回流、流失。
9、用戶群線
滿足某些行為的用戶群的追蹤,目的是為了進行個性化的運營等活動,該線的升華擴展是用戶畫像。
10、內容消費
提供的消費實體的曝光、點擊、生成、轉化等,以及內容的累積消費、消費排行等都屬于內容線。
11、狀態(tài)線
一般會作為輔線存在,相當于維表的存在,狀態(tài)線一般又分為以下幾種:
- 天表全量用戶狀態(tài),會加入一些修正,以及基于天全量的累積表的快照;
- 全量用戶信息維表;
- 開關操作狀態(tài)線;
- 記錄開關狀態(tài)變更記錄,得到當前用戶的開關狀態(tài)快照,是多態(tài)記錄的一種特殊情況;
- 添加刪除狀態(tài)線;
- 記錄用戶的添加刪除等操作,得到當前用戶操作結果的保有快照;
- 其它,比如登錄狀態(tài)、用戶等級等。
12、商業(yè)化線
商業(yè)化線相關的與收入相關的,比如cp合作、廣告位、推廣位、訂單、會員充值等。
需要說明的是本系列的數倉的主要介紹的是流量型產品形態(tài)、更多的是關注用戶規(guī)模,所以主線是是關于用戶的,而對于其它的產品形態(tài),比如購物類、充值消費類的則主線可能是商業(yè)化線等。此外作為用戶流量型產品,還隱藏著另外一個更加常用的線:自查線,每個主題的自查明細表,基于event_id或者參數的展開,但是沒有參數值的組合過濾。(自查線這個似乎沒有必要)
下圖是一張數倉的分線演示圖,每個框是一張表,不同顏色的框串聯成各自的數倉線。
13、分主題
在進行分矩陣設計的時候牽涉到分行和列的業(yè)務主題,此處詳細介紹下數據主題的設計,本部分的設計是從高層次上的。
主題劃分的一些依據:業(yè)務過程(或子過程,比如訂單)、ER中的E(或者R,比如商品主題)、數據服務的對象(運營主題)、數據的用途(比如商業(yè));分主題也即數據集市,根據業(yè)務形態(tài)的不同,會衍生出不同的主題,但以下主題在app中廣泛存在:
- 用戶主題(也即大盤:新增活躍、留存);
- 內容主題(具體提供的服務形式,也可以理解為產品主題,含曝光、點擊、分享等用戶消費傳播行為);
- 運營主題(可能合并到某個內容主題上,比如活動、通知、彈窗、授權、分享等);
- 商業(yè)化主題(廣告、訂單等通常用于結算);
- 技術主題(故障率、崩潰率、準確率等衡量技術指標)。
備注:
- 社交主題可以合并到內容主題也可以合并到運營主題,需要視app的具體特性和重視程度確定;
- 數倉的分主題主要體現在數據集市層,而數據集市層可能會因為使用比如kylin等多維分析工具被弱化。
14、用戶主題
用戶主題是產品的盤子,就像家店鋪,多少人使用就像多少顧客。基于用戶主題的常見統(tǒng)計有整體的新增、活躍、累積活躍、新增留存、活躍留存等大盤數據,以及對某些關鍵行為的用戶的后續(xù)追蹤,還有某些核心過程的PUV、轉化漏斗等。
15、內容主題
內容主題是盤子里東西的消費狀況,就像提供的菜單,每個菜被多少人點了。基于內容主題的常見統(tǒng)計有針對內容(文章、視頻、商品等)的各種消費行為(曝光、點擊、購買、下載等)的次數、人數、時長、金額等按不同維度的度量統(tǒng)計。常見的維度拆分有時間拆分、地域拆分、位置(人貨場模型中的場)拆分、畫像拆分、渠道拆分等,對度量的統(tǒng)計又有累積、非累積、TopN等。
16、運營主題
廣告、促銷、活動等一切由于運營活動相關本身的數據統(tǒng)計,以及運營活動對其它主題數據的影響衡量。
17、營收主題
營收的來源主要分為以下幾種:
1)流量廣告
- 商務合作;
- 優(yōu)惠券。
2)充值消費
- 會員充值;
- 訂單、打賞等。
流量廣告的數據主要產生于用戶行為,而充值消費的數據主要來自業(yè)務庫相關。
以上四個主題是在常見應用上通用的主題,其它的主題比如技術主題,在某些有明顯的技術指標對比的產品上會占主要的地位,比如文字識別類應用的識別準確率、搜索類產品的搜索滿意度、語音智能助理類的會話完成率等。這些產品上技術指標和用戶的體驗密切相關,是產品未來發(fā)展重要的參考方向,因此會強化出來做數據主題。另外如引流類或者與其他app有頻繁的引流拉起等應用的數據體系建設上,也會單獨拿出跳轉對接數據做主題分析。總之,主題的劃分并不是確定不變的,需要根據業(yè)務的具體形態(tài)和重點度量的指標等進行建設。
以上的矩陣、分層、分線、分主題的規(guī)劃只是從不同的角度來看數據框架,本質都是對數據流圖的一種拆解,差異在拆解的數據視角。
三、實施
1、需求分析
了解業(yè)務過程,每個業(yè)務過程的參與實體和各實體可能的分析維度等信息; 了解數據源組成,有哪些數據源、數據的更新周期;預構建指標體系,了解指標的分類,分析維度、時效性要求;了解可能的擴展需求,比如畫像寬表。需求分析階段是建立數倉的概念模型,明白數倉要支持的大致需求,雖然數倉建設并不要完全滿足業(yè)務需求,在建設的過程中肯定要有取舍,但第一步進行需求分析能保證在數倉建設過程中不致于偏離目標太多,避免建設爛尾或者好看不好用的繡花枕頭。
2、指標體系
此部分會另外開專題介紹,指標體系一般分為三類:
- 用戶增長體系
- 流量體系
- 營收體系
每個體系內分析數據的維度、更新周期等。指標體系的建立是需求分析環(huán)節(jié)需要重點完成的一步。
3、模型選擇
模型選擇環(huán)節(jié)要根據需求分析階段的結論,在ER模型、維度建模等基本的建模思想中選擇一種建模思想,比如說選擇了維度建模,要進一步根據需求分析中相關的業(yè)務過程和維度視角,在星型模型、雪花模型、星座模型中選擇一種模式。這個過程要充分的結合業(yè)務的實際狀況、開發(fā)人力和成本、各模型的優(yōu)缺點等因素進行綜合分析,是關系到建模是否成功的關鍵環(huán)節(jié)。需要說明的是,在快速迭代的互聯網行業(yè),業(yè)務規(guī)則可能經常變化,而對于不同粒度水平進行度量和監(jiān)控,進而快速響應的需求卻基本保持不變,比如層級的時間粒度(年、月、周、日、小時)、層級的地理粒度(大區(qū)、省、市、區(qū)縣、商圈)以及基于產品自身屬性的層級粒度(大類、子類)。基于這種特性,互聯網行業(yè)中廣泛采用維度建模的思想,同時為了使用的方便,又以星型模型和雪花模型較多。
4、標準規(guī)劃
標準規(guī)劃是對數倉建設過程各階段中涉及的對象、屬性、關系、鍵、交付物等進行規(guī)范定義,同時制定標準落地方式或者檢查的方式。比如表命名規(guī)范、字段命名規(guī)范、任務命名規(guī)范、調度依賴規(guī)范、代碼開發(fā)規(guī)范等。需求強調的是,這一步看似無關緊要,也往往直接被忽略跳過,但好的標準規(guī)劃能為建設高質量數倉的保駕護航,對數倉質量、健康度的保持都大有裨益。
5、開發(fā)部署
包含表設計、代碼開發(fā)、調度開發(fā)和告警開發(fā)等,對應本系列的第三節(jié)和第四節(jié)。
1)事實表和維表設計
- 維表設計
2)代碼開發(fā)
- 流程、審核機制、回退機制
3)調度開發(fā)
- 依賴任務的配置
- 回跑機制
- 任務權限管理
4)告警開發(fā):
- 數據量異常,某些細分維度、字段值、計算指標異常的告警措施
- 任務失敗、等待超時、執(zhí)行超時、上下線、上游重跑等告警措施
開發(fā)部署階段完成了數倉建設的邏輯模型和物理模型設計階段,是數倉建設的主要工作內容。
6、評估驗收
對應的問題包含在相關問題介紹部分,需要進一步思考數倉開發(fā)的交付物是什么。
- 數據字典
- 指標口徑的定義
- 核心表和其用途
- 數據流圖和重要指標的出口
- 業(yè)務變動對數倉的影響,比如某些手工維護的維表需要根據業(yè)務變動進行相應的更新
四、總結
本篇從業(yè)務矩陣、分層、分線和分主題等方面對數倉的規(guī)劃做了簡要的描述。這些方面的差異只在于剖析數倉的角度,其目的是一致的,即為了清晰地梳理數據體系、洞察數據狀態(tài)、以及更好地規(guī)劃未來數據地圖,從而更好的服務于各個業(yè)務需求方(BI報表、數據分析、用戶畫像等);本節(jié)最后簡要的介紹了數倉開發(fā)的基本流程。
進一步思考:
- 數倉規(guī)劃帶來的好處,方便傳承和交流,便于快速洞察數倉的健康狀態(tài);
- 數倉健康度的概念和計算方式。
>>>>參考資料
- 《一種通用的數倉分層方法》——數據茶水間
- 《業(yè)務數據矩陣的設計》——數據茶水間
作者丨水大人
來源丨木東居士(ID:Data_Engineering)
dbaplus社群歡迎廣大技術人員投稿,投稿郵箱:[email protected]
2020年9月11日,北京,Gdevops全球敏捷運維峰會將開啟年度首站!重點圍繞數據庫、智慧運維、Fintech金融科技領域,攜手阿里、騰訊、螞蟻金服、中國銀行、平安銀行、中郵消費金融、建設銀行、工商銀行、農業(yè)銀行、民生銀行、58到家、中國聯通大數據、浙江移動、新炬網絡等技術代表,展望云時代下數據庫發(fā)展趨勢、破解運維轉型困局。
編輯
Gdevops全球敏捷運維峰會北京站:https://www.bagevent.com/event/6243820?bag_track=dbaplus