帶你瞭解什麼是數倉寬表

1、什麼是寬表?

從字面意義上講就是寬表就是欄位比較多的資料庫表，多應用於DWD層或報表應用層，將很多維度、事實、指標等關聯彙總成一張資料表。區別於DWS層，寬表往往是跨主題的，且欄位較多(寬表之寬)，所以非常適合用來查詢和提升效率，缺點是資料冗餘和儲存要求較高。

2、為什麼要建設寬表?

資料倉儲建模大多數時候是要嚴格遵循建模要求的，星型模型或者雪花模型，而寬表的特點在於跨業務主題，所以很難遵循標準的建模要求和正規化結構，而且寬表建模也沒有嚴格的數倉分層概念，所以對於分層的好處管理方便、問題定位、節約資源等也是比較缺失的，那麼我們建設寬表呢?

① 可以統一指標口徑

這個問題對於大廠來說是非常常見的，大廠的特點是業務廣泛，那對於做資料的同學來說面臨的挑戰就是資料來源多、資料流複雜、口徑統一困難。由於上述種種困難，就會帶來報表口徑不一致這種常見問題，然而這種問題是很難透過口徑統一來去解決的，因為就算口徑統一了，資料流各個環節的處理過程的差異，對於資料產品來說去定位也是很困難的。

如果我們的報表要是都能從寬表出，那麼我們報表上的指標口徑肯定是一樣的，其實這一點很多人都深有體會，同一個指標的口徑不一致，導致我們提供的資料在不同的出口不一樣，是業務部門經常提出的一個問題。所以把核心邏輯下沉到寬表，收斂口徑，這樣可以解決大部分指標口徑不統一的情況。

② 可以提升開發效率

如果報表層的需求都能從寬表處，那麼除了上述統一指標口徑的好處之外，也避免了我們從頭開始計算，如果每一張報表都要從DWD甚至ODS開始加工，那麼不僅開發效率很慢，資料流過於複雜對於問題排查也不是很友好。

③ 可以提升資料質量

寬表的準確性都需要經過邏輯及資料準確性的校驗，對於開發來說人為開發，邏輯錯誤的可能性很小，可以直接使用，要是從頭開發的話，很容易出現因為對業務理解不透徹或者導致取數邏輯有問題，進而導致資料質量問題。

④ 可以建設自助化查詢工具

當上面講了這麼多建設寬表建設的好處，提到對應用層的好處其實不多，或者說更偏向於數倉為了解決各類統計問題給出的解決方案，但是對於資料產品來說應該思考現有的技術架構升級，為了我們資料產品的建設或者提升業務取數效率能夠做些什麼。那麼除了報表層統一口徑，資料產品可以基於寬表規劃一些更多應用類形式，比如自助化查詢工具、自定義生成查詢SQL，自助報表建設等。

這麼做的思想是：將寬表的維度和指標儘量透明化給業務，業務可以自取所需進行分析，這樣就把業務提需給資料產品這種關係，轉變成資料產品提供給業務我們能為你提供什麼樣的分析能力，業務按照自己的需求進行自助分析，這也就是實現了這個環節上資料產品的價值。

3、如何設計寬表?

① 寬表到底多寬

寬表到底要多寬?按照上面介紹的貌似什麼欄位都可以往寬表裡裝，但事實上並不如此，如果什麼欄位都放在寬表，那麼數倉分層貌似也沒什麼意義了，所以這個問題的答案是：要從需求出發。

從需求出發的話，寬表設計雖然可以跨主題，但肯定不會跨域進行分析。可以先按照需求高頻場景進行初版設計，後續慢慢擴充，但擴充並不是無原則擴充，一定要進行合理評估。

② 寬表欄位如何設計

作為資料產品可以從日常需求出發，考慮哪些欄位是常用且高頻使用的，對以下欄位明確口徑和邏輯，這樣就便於數倉進行開發了。最好輸出一個表欄位說明文件，其實也是一個資料產品和數倉對齊業務瞭解的好機會。

具體到設計過程應該如下：

· 深挖日常業務需求;

· 將業務需求進行分類，篩選出高頻需求特點;

· 對高頻需求進行拆解，落實到指標和維度，形成一個初版的表結構文件;

· 除了高頻需求之外有哪些常用欄位，如地域資訊、使用者標籤等資訊，豐富寬表屬性;

4、寬表的侷限性

① 效能不高

因為我們的寬表的計算邏輯往往很複雜，再加上寬表的資料輸入是有大量依賴的，也就是說需要處理的資料量很大，在負載邏輯+大資料量的原因下，導致我們的寬表往往執行很慢，資源佔用很多。

② 開發難度大/維護成本高

我們說了基於寬表做報表開發才是正確的姿勢，但是寬表本身也是我們開發人員開發的，因為本身的邏輯很複雜設計的業務邏輯繁多，所以給我們的開發就帶來了挑戰，而且由於業務邏輯的變更我們也需要去維護著複雜的邏輯，並且如果涉及到資料回溯成本也非常大，所以寬表建設後一般是不做歷史資料回溯的。

作者介紹：@圖圖，BAT資料產品經理，專注資料產品、持續學習中，“資料人創作者聯盟”成員