1什么是寬表？

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

2為什么要建設寬表？

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

① 可以統一指標口徑

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

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

② 可以提升開發效率

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

③ 可以提升數據質量

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

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

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

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

3如何設計寬表？

① 寬表到底多寬

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

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

② 寬表字段如何設計

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

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

· 深挖日常業務需求；

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

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

· 除了高頻需求之外有哪些常用字段，如地域信息、用戶標簽等信息，豐富寬表屬性；

4寬表的局限性

① 性能不高

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

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

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