數倉構建案例:從需求分析到數倉構建全流程
如何解讀從數據需求到數倉構建的整體流程?這篇文章里,作者結合實際案例,從需求分析、可視化看板設計、數據采集、數倉規劃、維度建模等方面進行了描述和拆解,不妨來看一下,或許會對你有做幫助。
一、背景
最近發文章,發現在文章中有插入廣告功能,假設廣告插入為新上線的新功能。
1. Web端鏈路
曝光環節:每次刷新,都會有不同的內容。如下圖所示:
具體落地頁,大家可以自己點擊看看。
2. 業務需求
功能上線一個月后,老板想看看該功能帶來了多少營收?
運營人員希望分析廣告投放、廣告曝光、落地頁曝光、支付頁、支付成功轉化鏈路的轉化情況?
本文以此為背景,從需求分析、可視化看板設計、數據采集、數倉規劃、維度建模等幾個階段去描述數據需求到數倉構建的整體流程。
二、需求分析階段
1. 目的
了解清楚業務問題和目標后,搞清楚數據怎么定義和描述這個問題?列出結果指標和過程指標,確定指標的展現形式。
2. 業務過程調研
需要整體分析各角色之間存在的各類要素流動關系。
3. 需求調研
根據業務調研及業務目標,使用不同的數據分析分析方法列出指標體系,最終大致遵循常用指標分類方式。
需求調研可以從以下角度出發:
1)根據與分析師、業務運營人員的溝通獲知需求。
2)了解以前的報表,對現有報表系統中的報表進行研究分析,了解關鍵性指標。
4. 確定指標
5. 確定指標統計含義及口徑
在篩選指標時,需要考慮指標的數據來源、數據質量、數據可靠性等因素。在此過程中,需要補充數據來源系統,來源表,來源字段,計算方式等。
三、可視化看板設計階段
1. 根據指標需求設計可視化看板
2. 確定展示內容和篩選條件
1)卡片展示內容:指標名稱、統計口徑、指標值、指標單位、統計日期、同比值、環比值、更新時間。
篩選條件:日期、支持選擇今日、昨日、本周、上周、本年、去年、最近7天、最近30天等等。不能選擇今天及以后。
2)支付情況日變動趨勢圖
篩選條件:日期范圍。支持選擇今日、昨日、本周、上周、本年、去年、最近7天、最近30天等等。不能選擇今天及以后,支持按日、按月、按年去對比。
3)下單轉化漏斗
篩選條件:日期范圍,支持選擇今日、昨日、本周、上周、本年、去年、最近7天、最近30天等等。不能選擇今天及以后。
可選統計方式:次數/人數
四、數據采集階段
數據采集前需要考慮以下兩點。
1)熟悉業務數據:明確業務過程與表之間的關系,表與表之間的關系,字段之間的關聯關系。
2)調研數據源情況:是否具備采集條件,數據庫類型,存儲格式,通過什么方式采集。對缺失的用戶行為數據進行埋點。
埋點時需根據不同埋點類型以及業務情況選擇合適的埋點方案和前后端采集方案。
1. 埋點需求分析
2. 自定義埋點方案設計
標準埋點方案一般由 4 張表組成:
- 埋點說明 – 埋點實施參考
- 事件&屬性 – 記錄事及相關信息;
- 用戶屬性 – 記錄用戶與相關信息
- 默認采集事件屬性 – 默認采集的事件屬性說明
公共屬性:
自定義事件&屬性:
在設計埋點前,可做一些埋點文檔和埋點評審的規范定義,方便文檔的維護和工作的開展。
比如:事件命名由 4 部分組成:類型_流程_頁面_功能。
- 類型:點擊、進入、停留、指標
- 流程:事件所屬的業務流程,填寫規則是[流程名稱 +“流程”]
- 頁面:事件所在的頁面,填寫規則是[頁面名稱 + “頁面”]
- 功能:可以是按鈕或功能的名稱
未了保障數據的準確性,需注意觸發時機和規則定義:比如什么樣的曝光是有效的?商品停留時間超過2s,卡片至少漏過50%。商品曝光重復:如果之前已經可見且上報了,那么不做二次上報等規則。
五、數倉規劃階段
在構建數倉前,需要對數倉進行整體規劃,包括:
- 技術架構設計:數據存儲技術的選擇、ETL工具選擇、任務調度工具選擇;
- 分層架構:數倉分層規劃;
- 主題域規劃:主題域確定;
- 數據開發規范指定:命名規范、開發規范、各種流程規范;
- 元數據管理方法等等。
1. 數倉分層規劃
操作數據層:ODS(Operational Data Store):把操作系統數據幾乎無處理地存放在數據倉庫系統中。
事實明細層:DWD(Data Warehouse Detail):DWD 層是在ODS層基礎上,根據業務過程建模出來的事實明細層。
公共匯總層:DWS(Data Warehouse Summary):一般根據維表數據和明細事實數據加工生成,作為通用的數據模型使用。
應用數據層:ADS(Application Data Store):存放數據產品個性化的統計指標,根據明細層、匯總層及維表數據加工生成。
想了解更多數倉分層可查閱上篇文章《帶你輕松理解數倉為啥分層?》http://www.aharts.cn/share/5892372.html
2. 主題域規劃
我們選擇按照業務過程劃分主題域:劃分的前提,先理清業務過程,根據業務過程去抽象出主題,比如瀏覽,曝光,點擊,都屬于用戶行為的業務過程,就可以劃分成流量主題。
想了解更多主題域規劃可查閱《如何理解主題域?》。
六、數倉設計階段
1. 構建業務總線矩陣
在數據倉庫領域中,業務總線矩陣是一種用于設計和組織數據倉庫的業務模型的工具。它是基于業務需求和業務過程的分析,明確業務過程與維度的關系。它幫助將業務需求轉化為數據模型,并指導數據倉庫的建模和設計過程。
從該業務矩陣中,我們可以得知需要建設哪些DIM層維度表,DWD層的事實表。
2. 指標拆分
指標的拆分是運算過程的拆分,維度模型里的指標拆分是一種思路,是模型設計很重要的一環。想了解更多可看《原子指標、派生指標、復合指標》。
原子指標:不可再分的指標。
派生指標:派生指標是由原子指標、時間周期、修飾詞構成,用于反映企業某一業務活動在指定時間周期及目標范圍中的業務狀況。
復合指標:由派生指標直接運算而來,通常是比率型指標。比如最近七天廣告點擊率,他的特點就是產生了新的原子指標。
3. 維度表設計
根據業務總線矩陣,可構建用戶維度表、時間維度表、地理位置維度表等等。
日期維度表示例:
4. 事實表設計
此處拓展事實表構建流程。
事實表說明:
事實表包括:事務型事實表、周期快照事實表、累積快照事實表。
1)選擇業務過程及確定事實表類型
業務過程定義:業務過程是從企業的經營收益、成本出發,價值鏈條上有影響力的用戶需求事情或者事件。而且,這樣的過程非常多,我們要分析當中的核心關鍵過程,不斷細分。
核心內容:企業活動事件、不可拆分原則。
2)聲明粒度:定義事實表的每一行所表示的業務含義,盡量選擇最細級別的原子粒度,以確保事實表的應用具有最大的靈活性。
3)確定維度:選擇能夠描述清楚業務過程所處的環境的維度信息。
4)確定事實:事實有可加性、半可加性、非可加性三種類型 需要將不可加性事實分解為可加的組件。
5)冗余維度:考慮更多的是提高下游用戶的使用效率,降低數據獲取的復雜性,減少關聯的表數量。
文章閱讀事實表:
頁面瀏覽事實表:
下單累計快照事實表:
交易域每日支付匯總表:
流量域每日曝光匯總表:
根據需求,匯總表還需要統計每月、每年、近7天、近30天等數據匯總情況,此處不做過多表格展示。需要注意命名規范以及事實是否可加。
最后:文中涉及很多概念大都一概而過,后續會慢慢分享相關內容。
本文由 @清小墨 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!