[[405173]]

本文轉載自微信公眾號「大數據技術與數倉」，作者西貝。轉載本文請聯系大數據技術與數倉公眾號。

什么是數據倉庫

數據倉庫,最早由比爾·恩門(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周甚至更長時間。測試校驗時間長，往往不是由于計算邏輯復雜，而是上游數據不規范，不可靠，不可信，需要花很大的代價自己做校驗和數據探查，這在一定層面上也反映出模型的設計有問題。
• 可擴展 數據倉庫經常會面對業務的變化，比如業務方拿到一個結果后，經常會與更多的維度交叉分析，或者粒度上做上卷或下鉆，還有對統計口徑做特別的限定。數據倉庫在要能覆蓋這些不可預知的變化的需求。更麻煩的是，業務規則會發生變化。良好的數據倉庫設計要能兼容這些變化，否則以前積累的數據都將變成垃圾。
• 穩定性 數據倉庫還要穩定地保障數據的產出，服務于業務系統，不要經常掉鏈子。造成不穩定的因素往往是機器網絡等硬件因素，但是良好的數據倉庫設計能在硬件故障后快速恢復數據，不會造成連鎖的災難。