什麼是數據倉庫
數據倉庫,最先由比爾·恩門（Bill Inmon）於1990年提出,主要功能是將組織或企業裏面的聯機事務處理(OLTP)所累積的大量數據，透過數據倉庫理論所特有的儲存架構，進行系統的分析整理，以利於各類分析方法如聯機分析處理(OLAP)、數據挖掘(Data Mining)的進行，並進而支持如決策支持系統(DSS)、主管信息系統(EIS)的建立, 幫助決策者能快速有效的從大量數據中分析出有價值的信息。前端
目前, 被普遍接受的數據倉庫的定義是由Bill Inmon在1991年出版的 "Building the Data Warehouse"一書中所提出的，其定義以下: 數據倉庫(Data Warehouse)是一個面向主題的(Subject Oriented)、集成的(Integrated)、反映歷史變化(Time Variant)、相對穩定的(Non-Volatile)的數據集合，用於支持管理決策(Decision Making Support)。算法
其實，在大數據時代，隨着機器學習和人工智能的興起，這個定義須要作一些補充：數據倉庫不僅是用於構建支持管理決策的商業智能BI的基礎, 也是大量的機器學習和人工智能算法的底層基礎之一。數據庫
那麼該如何理解上面的抽象定義呢？主要包括如下幾個關鍵詞：安全
- 面向主題
數據倉庫是用來分析特定的主題域的，好比用戶、交易、流量等等，主題域的劃分也是構建數倉總線矩陣的基礎。關於主題的劃分，是創建在深刻理解業務的基礎之上的，並無一個統一的標準，一個基本的原則是：主題域要儘可能涵蓋全部的表。能夠將主題理解爲業務的概括，屬於一個大的分類，有了明確的主題劃分，數倉的建設纔不至於混亂。 - 集成
咱們知道，數據倉庫之因此稱之爲倉庫，是由於其集成了多種OLTP的數據源，將不一樣的數據源彙總至數倉的過程就是集成，數據源A和數據源B多是識別某個產品的不一樣的方向，可是在數據倉庫中，僅有一個方式來識別某個產品, 對於同一產品中分散在不一樣的數據源中的不一樣信息，數據倉庫須要進行數據抽取、清洗、整合;對於分散在不一樣的數據源中的同一冗餘信息則須要消除不一樣數據源的不一致性，以保證數據倉庫內的信息是關於整個企業/業務/主題的一致的全局信息。 - 反應歷史變化
這一點很好理解，簡單講就是包含歷史的全部數據。這點是相對數據庫而言, 由於後者一般保持是是最近一段時間的數據。例如:咱們能夠從數據倉庫中獲取3個月, 6個月，12個月甚至10年的訂單數據; 而數據庫裏可能只能獲取最近3年的訂單數據。 - 相對穩定
一個數據一旦進入數據倉庫，則不可改變。數據倉庫的歷史數據是不該該被更新的。這裏須要強調的是：一是歷史一旦造成，不可更改。幾乎全部的數據倉庫產品都不支持更新修改操做，可是是支持重載操做，因此是相對的，而非絕對不可更改。
數據倉庫不是什麼
初學者對於數據倉庫最多見的誤解：網絡
- 是一個產品
與不少產品提供商所聲稱的相反，你不能直接買到一個數據倉庫，數據倉庫包含了數據集成，數據ETL，維度模型、元數據管理、數據質量管理、數據的可視化等等，沒有一個單一的產品能完成數據倉庫的所有過程。另外，數倉的構建是強依賴與業務的，對於不一樣的業務而言，其數倉的形態也是不盡相同的。值得注意的是，數倉是隨着業務的變化而不斷迭代的，因此沒有畢其功於一役的方法，這也註定了數倉是在不斷的變化中趨於完善的。 - 一個項目
成功的企業級數據倉庫一般是以可管理的數據集市開始的，每一個數據集市均可當作是單獨的項目，帶有本身的項目週期和預算。關鍵因 素在於每一個數據集市帶有一致的維度和標準的事實表，這樣便於將單個的數據集市集成到一個緊密的單元——企業級數據倉庫中。隨着各個數據集市項目的完成，企業級數據倉庫將最終發展起來。所以，思考數據倉庫更好的方法是將它當作一個過程，而非一個項目。 - 一個數據模型
簡單講，數倉是由一堆數據模型和數據構成的，數據模型是數倉的基礎。可是數倉是多個過程的集合，並不僅僅指數據模型，還包括上面提到的各個環節。 - oltp系統的一套備份
這是一個很常見的誤解，認爲將業務系統的數據備份一份並在此基礎之上創建報表系統就算是構建了數倉，其實否則，只完成數據遷移過程而不重構數據模型也不能構成數據倉庫。
數據倉庫系統體系結構
數據源->ETL->數據倉庫存儲與管理->OLAP->BI工具。架構
- 數據源：一般包括各類業務系統數據、日誌數據、外部數據；
- ETL（extract/transformation/load）:整合數據並將它們裝入數據倉庫的過程。將業務系統的數據通過抽取、清洗轉換以後加載到數據倉庫的過程，目的是將分散、零亂、標準不統一的數據整合到一塊兒，爲決策提供分析的依據；
- 數據的存儲與管理：數據的存儲和管理是整個數據倉庫的關鍵。數據倉庫的組織管理方式決定了它有別於傳統數據庫，同時也決定了其對外部數據的表現形式。數據倉庫按照數據的覆蓋範圍能夠分爲企業級數據倉庫和部門級數據倉庫（一般稱爲數據集市）；
- OLAP（On-Line Analysis Processing）:從數據倉庫中抽取詳細數據的一個子集並通過必要的彙集存儲到OLAP存儲器中供前端分析工具讀取。OLAP系統按照數據存儲格式能夠分爲關係OLAP（RelationalOLAP，簡稱ROLAP）、多維OLAP（MultidimensionalOLAP，簡稱MOLAP）和混合型OLAP（HybridOLAP，簡稱HOLAP）三種類型；
- 前端工具:查詢工具、數據分析工具、數據挖掘工具、種報表工具等。
數倉的必要性機器學習
- 數據孤島
由於每一個人基於本身的業務場景建設數據，豎起了一根根的煙囪，相互之間數據不互通，致使不管是中間數據仍是結果數據，可能只能被本身使用。也不知作別的場景有哪些數據，有的數據是否適合本身的場景。 - 解決問題範圍有限
由於數據不互通，對一個系統或業務的理解有限，沒法最大化應用數據的價值。 - 效率不足
煙囪數據每次都穿透使用貼源數據，沒有公共數據沉澱，沒法高效複用。每次都要重複開發，費時費力。
成本不可控
由於大量重複建設，在計算和存儲方面都有大量浪費。尤爲在海量的監控數據，由於沒有沉澱，不知道存儲週期設定多久合適，「那就存越久越好，萬一之後要用到呢」。價值發揮有限，反而花費大量實際成本。工具
數倉建模
維度建模5步驟
維度建模從分析決策的需求出發構建模型，爲分析需求服務，所以 它重點關注用戶如何更快速地完成需求分析，同時具備較好的大規模復 雜查詢的響應性能。其典型的表明是星形模型，以及在一些特殊場景下 使用的雪花模型。其設計分爲如下幾個步驟。性能
- 選擇須要進行分析決策的業務過程。
業務過程能夠是單個業務事件，好比交易的支付、退款等;也能夠是某個事件的狀態，好比當前的帳戶餘額等;還能夠是一系列相關業務事件組成的業務流程，具體須要看咱們分析的是某些事件發生狀況，仍是當前狀態， 或是事件流轉效率。學習
- 選擇粒度。
在事件分析中，咱們要預判全部分析須要細分的程度，從而決定選擇的粒度。粒度是維度的 一個組合。值得注意的是，在一個事實表中不要混用多種不一樣的粒度。
- 識別維表。
選擇好粒度以後，就須要基於此粒度設計維表，包括維度屬性，用於分析時進行分組和篩選。從who、what、when、where、why、how等方面描述。
選擇事實。肯定分析須要衡量的指標 。好比子訂單商品的數量、金額等等。
- 冗餘維度
維度設計基礎
維度基本概念
- 維度
維度是維度建模的基礎和靈魂。在維度建模中，將度量稱爲「事實」 ， 將環境描述爲「維度」，維度是用於分析事實所須要的多樣環境。例如， 在分析交易過程時，能夠經過買家、賣家、商品和時間等維度描述交易 發生的環境。 - 維度屬性
維度所包含的表示維度的列，稱爲維度屬性。維度屬性是查詢約束 條件、分組和報表標籤生成的基原本源，是數據易用性的關鍵。例如， 在查詢請求中，獲取某類目的商品、正常狀態的商品等，是經過約束商品類目屬性和商品狀態屬性來實現的，那麼類目和商品狀態就是維度屬性。 - 如何獲取
維度的做用通常是查詢約束、分類彙總以及排序等。如何獲取維度或維度屬性?如上面所提到的，一方面，能夠在報表 中獲取;另外一方面，能夠在和業務人員的交談中發現維度或維度屬性。由於它們常常出如今查詢或報表請求中的「按照」( by)語句內。例如， 用戶要「按照」月份和產品來查看銷售狀況，那麼用來描述其業務的自 然方法應該做爲維度或維度屬性包括在維度模型中。 - 總線矩陣
用於設計並與企業數倉總線架構交互的基本工具，矩陣的行表明業務過程、矩陣的列表明維度，點表示維度於給定的業務過程是否存在關係。
維度建模的基本設計方法
方法
維度的設計過程就是肯定維度屬性的過程，如何生成維度屬性，以 及所生成的維度屬性的優劣，決定了維度使用的方便性，成爲數據倉庫 易用性的關鍵。正如 Kimball 所說的，數據倉庫的能力直接與維度屬性 的質量和深度成正比。
- 第一步:選擇維度或新建維度。做爲維度建模的核心，在企業級數 據倉庫中必須保證維度的惟一性
- 第二步:肯定主維表。此處的主維表通常是 ODS 表，直接與業務 系統同步。
- 第三步:肯定相關維表。數據倉庫是業務源系統的數據整合，不一樣業務系統或者同 一業務系統中的表之間存在 關聯性。
- 第四步 :肯定維度屬性 。本步驟主要 包括兩個階段，其中第 一 個階 段是從主維表 中選擇維度屬性或生成新的維度屬性;第 二個階段是從相 關維表中選擇維度屬性或生成新 的維度屬性。
注意點 - 儘量生成豐富的維度屬性
儘量多地給出包括一些富有意義的文字性描述，通常是編碼和文字同時存在，好比商品維度中的商品 ID 和商品標題、 類目 ID 和 類目名稱等。ID 一 般用於不一樣表之間的關聯，而名稱通常用 於報表標籤。
- 區分數值型屬性和事實
數值型宇段是做爲事實仍是維度屬性，能夠參考字段的通常用途。若是一般用於查詢約束條件或分組統計，則是做爲維度屬性;若是一般 用於參與度量的計算， 則是做爲事實
- 儘可能沉澱出通用的維度屬性
有些維度屬性獲取須要進行比較複雜的邏輯處理，有些須要經過多表關聯獲得，或者經過單表 的不一樣宇段混合處理獲得，或者經過對單表 的某個字段進行解析獲得。此時，須要將盡量多的通用的維度屬性進行沉澱。
事實表
事實表做爲數據倉庫維度建模的核心，牢牢圍繞着業務過程來設 計，經過獲取描述業務過程的度量來表達業務過程，包含了引用的維度 和與業務過程有關的度量。
事實表中一條記錄所表達的業務細節程度被稱爲粒度。一般粒度可 以經過兩種方式來表述:一種是維度屬性組合所表示的細節程度:一種 是所表示的具體業務含義。
事實表有三種類型 : 事務事實表、週期 快照事實表和累積快照事實表。
數據模型設計
模型目標
- 口徑一致
- 避免重複計算
- 易於數據服務
- 充分支持業務
數據模型涉及的幾個方面 - 數倉分層
- 業務主題
- 維表/事實表
- 命名規範
如何規劃數倉
良好的模型抽象和清晰的層次劃分能保障支持各類複雜的數據業務接入並較好的支撐數據業務，這是大部分規劃數倉時會重點關注的問題。其實，不一樣時期來考衡標準是不同的，初期可能主要考慮的把業務支撐好，中後期可能主要重心在模型和數據治理上，經過不一樣階段將數據業務價值最大化同時保障數據建設健康發展。
初期
- 管理方便性：0
- 模型通用性：0.1
- 數據治理：0.1
- 安全保障：0.1
- 業務支持：0.7
中後期 - 管理方便性：0.1
- 模型通用性：0.2
- 數據治理：0.3
- 安全保障：0.2
- 業務支持：0.2
在數據倉庫建設初期，因爲倉庫數據沉澱少，大量的業務數據須要處理，是暫緩業務數據需求開發待倉庫建設好全力支撐業務？仍是全力保障業務支持逐步來建設數據倉庫建設？這兩個問題可能也困擾着不少人，我的以爲仍是先run起來，先解決一些業務問題，即先產出一些價值，這樣會更容易推動後面的工做。若是一上來就大而全，一方面產出價值少被老闆挑戰，另外一方面實施週期長，很容易成爲一個較大的成本中心。在快速發展的互聯網行業像這種建設方式顯然不太合適，經過數據支持保障業務快速發展是咱們首要考慮的問題。值得注意的是：先run起來並非意味着不聽從任何的規範，只不過首要的問題的支持業務。等到數倉建設到中後期，這個時候就須要考慮數據治理的問題，而不是一味的去知足需求，好比考慮主題數據的中間層數據資產沉澱、模型優化、任務優化、存儲與計算成本優化等等，從而使得數倉逐漸趨於完善。
如何評價數倉
- 需求響應敏捷 數據倉庫建設不是需求驅動的，可是數據倉庫的根本目的仍是面向決策的。在現實中，數據倉庫團隊承擔着不少數據查詢分析的職責，常常會收到業務方的數據需求。一個好的數據倉庫模型，能預知業務方的數據需求，足夠靈活擴展。能作到這一點，首先須要創建元數據管理工具，從而能夠方便快速查找數據的基本信息。其次，還須要有大量的數據中間層，有預先算好的數據指標。此外，數據自助提取工具也是快速響應數據需求的必備工具。
- 數據質量可靠 在數據開發過程當中，不少人可能會遇到這種狀況，開發時間只用了1周，數據測試和校驗用了2周甚至更長時間。測試校驗時間長，每每不是因爲計算邏輯複雜，而是上游數據不規範，不可靠，不可信，須要花很大的代價本身作校驗和數據探查，這在必定層面上也反映出模型的設計有問題。
- 可擴展 數據倉庫常常會面對業務的變化，好比業務方拿到一個結果後，常常會與更多的維度交叉分析，或者粒度上作上卷或下鑽，還有對統計口徑作特別的限定。數據倉庫在要能覆蓋這些不可預知的變化的需求。更麻煩的是，業務規則會發生變化。良好的數據倉庫設計要能兼容這些變化，不然之前積累的數據都將變成垃圾。
- 穩定性 數據倉庫還要穩定地保障數據的產出，服務於業務系統，不要常常掉鏈子。形成不穩定的因素每每是機器網絡等硬件因素，可是良好的數據倉庫設計能在硬件故障後快速恢復數據，不會形成連鎖的災難。