最近打算閱讀一下數據倉庫相關的書籍,百度了一下,有兩本必讀書《數據倉庫工具箱》和《數據倉庫》。簡單介紹一下,《數據倉庫》這本書更像是一本教材,裏面的內容很經典;《數據倉庫工具箱》看書名是一本單純的工具書,其實裏面都是實戰。兩本書各有千秋,我決定主要閱讀《數據倉庫工具箱》,今天分享第一章的內容,之後會作系列分享。安全
第一章主要介紹了維度建模的好處,Kimball的歷史和技術架構,以及與其餘相似架構的優劣,但其核心議題是:「如何作好數據倉庫?」架構
說實話這個議題很沒意思,有些枯燥,但是若是你遇到:「如何才能作好數據?爲何需求一直作不完?數據的價值到底有多大?」那麼這下面全是乾貨。工具
上面7點是數據倉庫設計的目標,不太重點是最後兩點網站
這個是核心,我剛開始作數據倉庫的時候,設定的目標是:知足業務查詢數據的需求。結果我在這個目標上不斷的奔跑,差點累死。暫且不提幾十個維度作笛卡爾積的查詢可否實現,就算作出來了,價值是什麼哪?爲公司帶來了多少收益?若是本身的價值不能量化,那麼結果是能夠想象的。因此必定要數據倉庫必定要支持決策,而且知道本身支持了哪些決策。下面是書中原文:spa
數據倉庫須要正確的信息以支持決策制定。DW/BI系統最重要的輸出是基於分析證據所產生的決策。這些決策體現了數據倉庫的影響和價值。早期用於表示DW/BI系統的稱謂--決策支持系統,仍可做爲開展系統設計的最好描述。
技術方案不重要,落地才重要,這裏我想說的是:能夠不用那些高大上的技術方案,可是不能不知道它的原理。要即知道它的優勢,也知道它的不適用。設計
是否使用最佳組合產品或平臺來構建您的體面的解決方案其實並不重要。若是業務羣體不能接受DW/BI環境並積極使用它,就難言成功。對操做型系統來講,用戶沒法對其加以選擇,只能使用新系統,而對DW/BI系統來講,與操做型系統不一樣的是,它是可選的。
只有當DW/BI系統真正成爲用於構建可付諸實現的信息的"簡單快捷"的資源時,用戶纔會接受它。
這裏的責任大都是如何知足用戶的需求,知足用戶的需求不等於他提的需求都能知足,而是充分理解他的kpi,理解他的目標,從這個方面入手知足他的需求,下面是原文:code
1、理解業務用戶 1.1 理解他們的工做責任、目標和任務。 1.2 肯定商業用戶在制定哪些決策時須要DW/BI系統的幫助。 1.3 識別出那些制定出高效率、高影響的決策的"最佳"用戶。 1.4 發現潛在的新用戶,並讓他們意識到DW/BI系統可以給他們帶來什麼能力。 2、對業務用戶發佈高質量、相關的、可訪問的信息和分析 2.1 選擇最健壯的、可操做的數據放入DW/BI系統中,從組織機構的各類數據源中仔細選擇 2.2 簡化用戶接口和應用,採用模板驅動方式,與用戶的認知過程輪廓匹配 2.3 確保數據精確、可信,使其標識在整個企業具備一致性。 2.4 不間斷地監控數據和分析的準確性。 2.5 適應用戶不斷變化的思惟方式、需求和業務優先級,及新數據源的可用性。 3、維護DW/BI環境 3.1 採用DW/BI系統制定的成功的業務決策,驗證人員配置及要投入的開支。 3.2 按期對DW/BI系統進行更新。 3.3 保持業務用戶的信任。 3.4 保持業務用戶、執行贊助商和IT管理層滿意度。
上面都是一些概念,下面說一下本身理解的如何作好數據倉庫?blog
首先要充分理解業務過程,舉例一家旅遊網站,那麼用戶行爲的簡化過程就是:接口
用戶訪問首頁 -> 用戶搜索 -> 用戶到list頁面 -> 用戶到detail頁面 -> 下單 -> 成單 -> 利潤
若是是管理層看用戶行爲數據,那麼必定是看關鍵路徑的指標,好比:u2b、u2o,通常不會看每一個路徑的轉化,由於他的kpi是提高總體的收入或者總體的新用戶數,不必看這麼仔細,發現問題找下面的人處理就行了,因此知足他的需求就是快速的給它這些指標便可資源
若是是負責用戶行爲的產品看數據,那麼必定是看每一個路徑的轉化指標,由於他的kpi就是提高總體的轉化,細化以後就是每一個關鍵節點的轉化率
若是是某個大區的如責任看數據,那麼必定看這個大區的u2b、u2o、利潤等等,由於他的kpi就是這個大區
業務過程有不少,關鍵指標更多,如何作好數據倉庫?就是如何指導業務,就是理解他們的工做責任、任務和目標,幫助他們找到關鍵指標,指導決策