小嘗試：基於指標體系的數據倉庫搭建和數據可視化
關於作者：小姬，某知名互聯網公司產品專家，對數據采集、生產、加工有所了解，期望多和大家交流數據知識，以數據作為提出好問題的基礎，發覺商業價值。
0x00 前言
我將整理文章分享數據工作中的經驗，因為業務內容上的差異，可能導致大家的理解不一致，無法體會到場景中的諸多特殊性，不過相信不斷的溝通和交流，可以解決很多問題。前面我們分析了職場基本功、數據指標體系，今天我們來就前面文章中的指標體系，聊一下數據倉庫的搭建和數據可視化。
歷史導讀：
以下，Enjoy：
0x01 為什么基於指標體系搭建數據倉庫
前面文章中我們提到過為什么要搭建指標體系，如果還無法體會指標體系的作用和意義，可以通過歷史導讀重溫前面的2篇文章，或者加入我們的微信群，同大家一起交流。這里簡單的在換2句話描述一下做指標體系的重要性。
- 搭建指標體系實際上是同需求方達成一種協議，可以有效地遏止不靠譜的需求，讓需求變得體系且有條理；
- 數據指標體系是指導數據倉庫搭建的基石，穩定且體系的數據需求，有利於數據倉庫方案優化，效率提升。
沒有數據指標體系的團隊內數據需求經常表現為“膨脹”現象。每個人都有看數據的視角和訴求，然后以非專業的方式創造維度/指標的數據口徑。數據從業人員被海量的數據需求纏住，很難抽離出業務規則設計好的解決方案，最終滾雪球似的搭建難以維護的“煙囪式”數據倉庫。
提供數據可視化方案的過程，依然存在像搭建數據倉庫一樣的問題。數據可視化報表數量膨脹但使用率低，好似再多的數據報表都遠遠不夠滿足數據需求一樣。長久下來維護成本居高不小，效益率不夠高。這讓數據從業者很苦惱，如果大家還有其他苦惱的問題，希望繼續深入的溝通了解，歡迎評論留言或者加入我們的微信群聊共同交流。
0x02 基於指標體系搭建數據倉庫思考
我們簡單回憶下的數據倉庫分層問題，做“又寬又薄”的數據倉庫分層，讓數據能夠有序的流轉。數據全鏈路的整個生命周期只有通過層次才能清洗明確的被使用者感知和消費。任何跨層依賴，循環依賴，多重依賴都會導致數據問題的多發且不可維護。
- 數據倉庫常見分層方式
- 數據倉庫分層和跨層依賴、循環依賴、多重依賴的不同表現形式
因此，我們需要有效的組織和管理數據，讓它更有秩序。
- 每層都有作用域和職責，清晰每層數據的目標定位和理解。
- 規范工作方式，做標准數據分層，開發通用性強（健壯）的數據中間層，避免耦合重復計算問題。
- 提供統一的數據服務，輸出統一認知的數據口徑
- 將復雜的數據任務拆解，標准步驟每層解決場景問題。
從數據倉庫的分層來看，ODS層是貼業務，形態主要依賴業務數據形式；APP層是貼使用場景，取決於數據怎么呈現和消費，DW層是中間層，負責發揮重要的擴展作用，肩負大量的數據加工計算責任。
鑒於以上數據倉庫的分層邏輯，我們不難得出結論。
- ODS層的搭建不需要過多思考，依賴業務庫的表現形式；
- APP層的更多依賴數據最終的場景搭建，考慮場景因素居多，比如多維、速度、口徑。
只有DW層讓數據生產者有極大的發揮空間，如何設計出好的（擴展性強）DW層是數據倉庫的重點標准，相信很多同學在DW層搭建的過程都出現過類似問題“理想很豐滿，現實很殘酷”，搭建的數據“不接地氣，不實用”，還是不能解決數據需求問題，總是跟不上業務的發展變幻。
那么，從現在開始不妨首先建立指標體系，基於指標體系搭建數據倉庫。我們常見的指標體系大致包含以下內容：
- 產品框架
- 數據矩陣
說明：
根據產品框架梳理出可靠的數據矩陣效果最佳，單現實的情況是在產品框架下的不同報表的指標口徑或是計算邏輯可能存在差異，因此數據矩陣可以是根據某個報表單獨針對性小矩陣。
- 數據口徑
說明：同數據矩陣一樣不同的數據報表中，相同的指標名稱可能存在不同的數據口徑或者計算邏輯 ，因此指標的口徑定義方面也可以做一些調整，例如口徑和計算邏輯不同，必須區分出不同的指標名稱，或者是相同的指標名稱，做好指標口徑定義的說明，告知受眾群體差異點在哪里。
0x03 基於指標體系搭建數據倉庫
常見的數據倉庫搭建，實現數據分層大致分為兩種模式：
- A模式：基於業務實體或者數據的應用場景，從應用層向底層推導過程。
- B模式：基於已有的數據，從底層分類整理數據，向應用層逐步搭建。
以底層向應用層搭建數據倉庫，側重在於需求尚且不清晰的情形下開展數據開發工作，首先實現數據預處理，做好數據的采集對接和數據主題分類。以備數據消費場景落地的時候，快速實現功能的開發。這種模式通用型強，使用廣泛，同時也會造成很多冗余和設計不合理，實際響應需求的時候出現擴展性差，重構幾率高的現象。
另一種模式則是在需求明確的前提下，以需求向底層推導數據倉庫建模。通過需求讓參與項目的各方快速理解業務訴求，統一目標的認知。高質量的梳理出業務需求和數據倉庫之間的關系，針對性強的搭建數據倉庫。但是這依然有詬病，就是數據建設容易出現“煙囪式”搭建，滿足場景有限，復用性差。
基於指標體系搭建數據倉庫，主要解決的是“A模式”中的數據場景考慮不全面的問題。如果數據的使用場景考慮不全面就會造成“煙囪式”數據搭建，復用性差。數據需求如果以“點狀”碎片的形式提出，沒有全局的認知和規划，數據倉庫的搭建只能針對性的以“點狀的煙囪式”搭建。如果需求能體系化的產出，梳理出業務場景中所需要的維度、指標。那么就可以最大限度的解決數據建模過程中的“煙囪式”，從而讓數據的搭建“又寬又薄”。
例如，我們有如下數據矩陣
-w505
那么，我們可以選擇的數據倉庫分層建模方式如下
-w713
說明庫.表1：通過APP層的數據表服務數據可視化，數據應用服務，多維查詢；庫.表2：實時明細表，通過與其他的實時表（庫.表3）或者維度表（庫.表4、5）關聯生成APP層的數據表；庫.表6：埋點數據產生的日志表，或者是從業務庫對接過來的業務數據（比如訂單數據）
0x04 數據可視化報表
當然，理想很豐滿現實很殘酷，正如我幾次提到實際工作存在很多不理想，這是很多人遇到的問題，我也在探索新的方式，如果大家有興趣可以加入微信群一起交流。