Categories
程式開發

嚴選質量數倉建設(三)—— 數倉開發實例


在之前的兩篇文章,我們介紹了數據倉庫的基本概念、質量數倉建設過程和使用到的產品。本文將以Bug數據開發設計為例,通過實戰了解質量數倉建設過程。

數據分層

數據分層,與應用開發中的mvc模式一樣,數據分層的目的是更好的管理數據,對數據能有一個更加清晰的掌控。數據分層使的數據具有清晰的數據結構,便於進行數據血緣追踪,能夠把複雜問題簡單化,減少重複開發,屏蔽原始數據的異常和業務的影響。每個企業或組織由於各自業務、規範、目標不盡相同,分層的策略可能會有一些區分,通用的數據分層結構如下圖所示。

嚴選質量數倉建設(三)—— 數倉開發實例 1

ODS層

數據存儲操作層,是最接近數據源中數據的一層,數據源中的數據經過ETL之後裝入本層,一般來講,為了追溯數據的問題,因此,本層數據一般不做過多的數據清洗工作,原封不動的接入原始數據即可。

DWD層

數據明細層,該層一般保持和ODS層一樣的數據粒度,並且提供一定的數據質量保證(統一業務過程、基於業務過程清洗數據,完備數據)。同時,為了提高數據明細層的易用性,該層會將一些維度冗餘到事實表中,減少事實表和維度的關聯,提高查詢效率。

DWS層

數據服務層,按照業務劃分,基於DWD層的數據,做一些聚合操作,生成字段比較多的寬表,提升公共指標的複用性,減少重複加工,用於提供後續的業務查詢。

DM層

數據集市層,基於DW層數據,根據業務需求實現數據模型,一般會跨多個主題域,主要提供給數據產品和數據分析使用的數據,一般存儲在ES、Redis、HBase等存儲中,供線上系統使用。

DIM層

維表層,維表層就是所有維度表的集合。

質量數倉開發實例

選擇業務過程

業務過程是由組織完成的微觀活動,包含以下公共特徵:

  • 業務過程通常用行為動詞表示,因為他們通常表示業務執行的活動;
  • 業務過程通常由某個操作型系統支撐;
  • 業務過程建立或獲取關鍵性能度量;
  • 業務過程通常由輸入激活,產生輸出度量。

第一個數倉項目應該選擇最為關鍵的、最易實現(包括數據可用性與質量,以及準備工作等)的業務過程。

在質量數倉建設中,bug提報及處理是與質量最直接相關的業務過程,數據質量較高,這份數據使用戶能夠分析已提報的bug數據,它們是在何時、由誰、在哪個項目中發現的,嚴重程度如何,處理花費了多長時間等。

聲明粒度

聲明粒度意味著精確定義某個事實表的每一行表示什麼。事實度量越詳細,就越能獲得更確定的事實,原子數據能夠提供最佳的分析靈活性,維度模型中的細節數據可與i適應用戶比較隨意的查詢請求。設計開發的維度模型應該表示由業務過程獲取的最詳細的原子信息。

也可以定義匯總粒度來表示對原子數據的聚集,但是,較高級別的粒度會限制更細節維度的可能性,無法實現用戶下鑽細節的需求。

在bug提報與處理的業務過程中,最細粒度的數據是JIRA用戶提報的單個bug。選擇最細粒度的原子信息作為粒度,也能夠更容易的檢查數據質量。

確定維度

維度要解決的問題是“業務人員如何描述來自業務過程度量事件的數據?”在選擇每個維度時,應該列出所有具體的、文本類型的屬性以充實每個維度表。

詳細的粒度說明確定了事實表的主要維度。在bug提報與處理的業務過程中,Bug的提報日期、解決日期、創建人、所屬產品、優先級等都是需要包含的維度屬性。

確定事實

設計的最後一步是確認應該將哪些事實放到事實表中。確定事實就是回答“過程的度量是什麼”,典型事實是可加性數值,明顯屬於不同粒度的事實必須放在不同的事實表中。

設計的最後一步是確認應該將哪些事實放到實施表中。事實必須與粒度相吻合,Jira系統中收集到的有bug數量、bug修復時長。

此外,還有一些通過計算得到的事實,如在時間維度上進行匯總後得到的每月新增的總bug數、每月bug的平均修復時長等;這些計算得到的事實,也應該存儲在數倉系統當中,避免用戶自行計算使用時產生錯誤的可能性。

而部分只能通過計算得到的不可加事實,如P0級bug率,只能通過P0級bug數量除以所有bug數量得到,這種不能從任何維度被匯總的事實,稱為非可加事實,只能通過BI工具計算獲得,一般不存儲數倉系統數據庫中。

上述提到的bug數量、bug修復時長是原子粒度上的事實,屬於一個事實表,如下圖1所示,而計算事實每月新增bug數、每月新增bug平均修復時長等,則屬於在時間週期上的匯總粒度,應屬於另一個事實表,除此之外,我們還關心,各個優先級的bug佔比、修復時長、關閉率等(如下圖2所示),確定關心的事實及它們所屬的事實表,也就完成了我們的事實表設計。

嚴選質量數倉建設(三)—— 數倉開發實例 2

數據入倉

在前面的步驟中,我們已經明確了我們需要分析的數據包含哪些,接下來,我們需要梳理業務數據庫,找出所需要的數據在業務庫中的存儲在哪些表當中,它們之間的關係是怎樣的(通常這部分應當由業務庫的開發人員提供,而質量數倉中由於對接的大部分業務系統並沒有對應的開發,所以需要數據開發同學自行梳理、發現)。

在本實例中,我們經過梳理髮現Jira中相關的表有issue記錄表、project記錄表、user記錄表,以及issue優先級、狀態對應關係、版本關聯關係表等,通過datahub平台的數據同步功能,將Jira數據庫中對應的表同步到數倉的RDB庫中就完成了數據入倉的任務。

數據清洗

接下來要進行數據清洗,數據清洗主要是為了解決數據質量問題,包括數據的完整性、唯一性、權威性、合法性、一致性。

在Bug數據開發示例中,相關的用戶信息中,部分jira用戶僅有用戶的郵箱前綴,缺乏用戶姓名、郵箱、所屬團隊等信息,在入倉後,我們要通過郵箱前綴,在其他已入倉的表中查找到相關的用戶信息,補充到jira用戶表中,這是解決完整性的問題。

在Bug記錄中,每一個bug都歸屬某一個項目,而這個項目與我們的業務域是無法對應的,因此,如果需要將項目與業務域對應起來,則需要將項目對應到我們cmdb中的服務,所有質量數倉涉及到業務域的數據,都以cmdb的數據為準,如果業務系統中沒有,則要在清洗時根據映射關係去對應,這是解決權威性問題(要使用最權威可信的數據)。

而數據的唯一性則是指,業務系統中可能存在多條重複記錄,在清洗時,需要以主鍵去重;合法性則是要求字段必須符合一定的規則,如性別必須是“男”、“女”、“保密”中的一種,如出現其他取值,要么剔除、要么設置為默認、要么報警提醒人工處理,避免數據對分析造成影響;一致性則是指同一個指標(或同一個名稱),在系統各處應是相同的含義、計算口徑。

數據加工

經過前面的步驟,我們已經得到了可靠的源數據,後面則是根據前期需求分析的結果,根據質量數倉的開發規範,建立對應的維度表、事實表(業務入倉的數據表,位於ods庫,清洗後的明細數據位於dwd庫,維度數據位於dim庫,而輕度匯總的數據位於dws庫);創建任務加工數據寫入對應的表,並設置調度規則。

本文的實例,是最簡單的一些維度表和事實表的設計,除此之外,數倉建設中還有許多進階設計方法等待我們一起去發現。

作者簡介

婧雯,網易嚴選資深測試工程師,2014年畢業於北京理工大學,2017年加入網易。參與數據產品技術部多個重點產品質量保障工作,建設並完善數據產品部質量保障體系,致力於質量保障工作效能得提升。

相關閱讀:

網易嚴選質量數倉建設(一)—— 數據倉庫基本概念

網易嚴選質量數倉建設(二)—— 質量數倉項目建設及管理