在之前的兩篇文章，我們介紹了數據倉庫的基本概念、質量數倉建設過程和使用到的產品。本文將以Bug數據開發設計爲例，通過實戰了解質量數倉建設過程。
數據分層
數據分層，與應用開發中的mvc模式一樣，數據分層的目的是更好的管理數據，對數據能有一個更加清晰的掌控。數據分層使的數據具有清晰的數據結構，便於進行數據血緣追蹤，能夠把複雜問題簡單化，減少重複開發，屏蔽原始數據的異常和業務的影響。每個企業或組織由於各自業務、規範、目標不盡相同，分層的策略可能會有一些區分，通用的數據分層結構如下圖所示。
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所示），確定關心的事實及它們所屬的事實表，也就完成了我們的事實表設計。
數據入倉
在前面的步驟中，我們已經明確了我們需要分析的數據包含哪些，接下來，我們需要梳理業務數據庫，找出所需要的數據在業務庫中的存儲在哪些表當中，它們之間的關係是怎樣的（通常這部分應當由業務庫的開發人員提供，而質量數倉中由於對接的大部分業務系統並沒有對應的開發，所以需要數據開發同學自行梳理、發現）。
在本實例中，我們經過梳理髮現Jira中相關的表有issue記錄表、project記錄表、user記錄表，以及issue優先級、狀態對應關係、版本關聯關係表等，通過datahub平臺的數據同步功能，將Jira數據庫中對應的表同步到數倉的RDB庫中就完成了數據入倉的任務。
數據清洗
接下來要進行數據清洗，數據清洗主要是爲了解決數據質量問題，包括數據的完整性、唯一性、權威性、合法性、一致性。
在Bug數據開發示例中，相關的用戶信息中，部分jira用戶僅有用戶的郵箱前綴，缺乏用戶姓名、郵箱、所屬團隊等信息，在入倉後，我們要通過郵箱前綴，在其他已入倉的表中查找到相關的用戶信息，補充到jira用戶表中，這是解決完整性的問題。
在Bug記錄中，每一個bug都歸屬某一個項目，而這個項目與我們的業務域是無法對應的，因此，如果需要將項目與業務域對應起來，則需要將項目對應到我們cmdb中的服務，所有質量數倉涉及到業務域的數據，都以cmdb的數據爲準，如果業務系統中沒有，則要在清洗時根據映射關係去對應，這是解決權威性問題（要使用最權威可信的數據）。
而數據的唯一性則是指，業務系統中可能存在多條重複記錄，在清洗時，需要以主鍵去重；合法性則是要求字段必須符合一定的規則，如性別必須是“男”、“女”、“保密”中的一種，如出現其他取值，要麼剔除、要麼設置爲默認、要麼報警提醒人工處理，避免數據對分析造成影響；一致性則是指同一個指標（或同一個名稱），在系統各處應是相同的含義、計算口徑。
數據加工
經過前面的步驟，我們已經得到了可靠的源數據，後面則是根據前期需求分析的結果，根據質量數倉的開發規範，建立對應的維度表、事實表（業務入倉的數據表，位於ods庫，清洗後的明細數據位於dwd庫，維度數據位於dim庫，而輕度彙總的數據位於dws庫）；創建任務加工數據寫入對應的表，並設置調度規則。
本文的實例，是最簡單的一些維度表和事實表的設計，除此之外，數倉建設中還有許多進階設計方法等待我們一起去發現。
作者簡介
婧雯，網易嚴選資深測試工程師，2014年畢業於北京理工大學，2017年加入網易。參與數據產品技術部多個重點產品質量保障工作，建設並完善數據產品部質量保障體系，致力於質量保障工作效能得提升。
相關閱讀：