[[405173]]

本文轉(zhuǎn)載自微信公眾號「大數(shù)據(jù)技術(shù)與數(shù)倉」，作者西貝。轉(zhuǎn)載本文請聯(lián)系大數(shù)據(jù)技術(shù)與數(shù)倉公眾號。

什么是數(shù)據(jù)倉庫

數(shù)據(jù)倉庫,最早由比爾·恩門(Bill Inmon)于1990年提出,主要功能是將組織或企業(yè)里面的聯(lián)機事務(wù)處理(OLTP)所累積的大量數(shù)據(jù)，透過數(shù)據(jù)倉庫理論所特有的儲存架構(gòu)，進行系統(tǒng)的分析整理，以利于各種分析方法如聯(lián)機分析處理(OLAP)、數(shù)據(jù)挖掘(Data Mining)的進行，并進而支持如決策支持系統(tǒng)(DSS)、主管信息系統(tǒng)(EIS)的創(chuàng)建, 幫助決策者能快速有效的從大量數(shù)據(jù)中分析出有價值的信息。

目前, 被廣泛接受的數(shù)據(jù)倉庫的定義是由Bill Inmon在1991年出版的 "Building the Data Warehouse"一書中所提出的，其定義如下: 數(shù)據(jù)倉庫(Data Warehouse)是一個面向主題的(Subject Oriented)、集成的(Integrated)、反映歷史變化(Time Variant)、相對穩(wěn)定的(Non-Volatile)的數(shù)據(jù)集合，用于支持管理決策(Decision Making Support)。

其實，在大數(shù)據(jù)時代，隨著機器學(xué)習(xí)和人工智能的興起，這個定義需要做一些補充：數(shù)據(jù)倉庫不只是用于構(gòu)建支持管理決策的商業(yè)智能BI的基礎(chǔ), 也是大量的機器學(xué)習(xí)和人工智能算法的底層基礎(chǔ)之一。

那么該如何理解上面的抽象定義呢?主要包括以下幾個關(guān)鍵詞：

• 面向主題

數(shù)據(jù)倉庫是用來分析特定的主題域的，比如用戶、交易、流量等等，主題域的劃分也是構(gòu)建數(shù)倉總線矩陣的基礎(chǔ)。關(guān)于主題的劃分，是建立在深入理解業(yè)務(wù)的基礎(chǔ)之上的，并沒有一個統(tǒng)一的標準，一個基本的原則是：主題域要盡量涵蓋所有的表?？梢詫⒅黝}理解為業(yè)務(wù)的歸納，屬于一個大的分類，有了明確的主題劃分，數(shù)倉的建設(shè)才不至于混亂。

• 集成

我們知道，數(shù)據(jù)倉庫之所以稱之為倉庫，是因為其集成了多種OLTP的數(shù)據(jù)源，將不同的數(shù)據(jù)源匯總至數(shù)倉的過程就是集成，數(shù)據(jù)源A和數(shù)據(jù)源B可能是識別某個產(chǎn)品的不同的方向，但是在數(shù)據(jù)倉庫中，僅有一個方式來識別某個產(chǎn)品, 對于同一產(chǎn)品中分散在不同的數(shù)據(jù)源中的不同信息，數(shù)據(jù)倉庫需要進行數(shù)據(jù)抽取、清洗、整合;對于分散在不同的數(shù)據(jù)源中的同一冗余信息則需要消除不同數(shù)據(jù)源的不一致性，以保證數(shù)據(jù)倉庫內(nèi)的信息是關(guān)于整個企業(yè)/業(yè)務(wù)/主題的一致的全局信息。

• 反應(yīng)歷史變化

這一點很好理解，簡單講就是包含歷史的所有數(shù)據(jù)。這點是相對數(shù)據(jù)庫而言, 因為后者通常保持是是最近一段時間的數(shù)據(jù)。例如:我們可以從數(shù)據(jù)倉庫中獲取3個月, 6個月，12個月甚至10年的訂單數(shù)據(jù); 而數(shù)據(jù)庫里可能只能獲取最近3年的訂單數(shù)據(jù)。

• 相對穩(wěn)定

一個數(shù)據(jù)一旦進入數(shù)據(jù)倉庫，則不可改變。數(shù)據(jù)倉庫的歷史數(shù)據(jù)是不應(yīng)該被更新的。這里需要強調(diào)的是：一是歷史一旦形成，不可更改。幾乎所有的數(shù)據(jù)倉庫產(chǎn)品都不支持更新修改操作，但是是支持重載操作，所以是相對的，而非絕對不可更改。

數(shù)據(jù)倉庫不是什么

初學(xué)者對于數(shù)據(jù)倉庫最常見的誤解：

• 是一個產(chǎn)品

與很多產(chǎn)品提供商所聲稱的相反，你不能直接買到一個數(shù)據(jù)倉庫，數(shù)據(jù)倉庫包含了數(shù)據(jù)集成，數(shù)據(jù)ETL，維度模型、元數(shù)據(jù)管理、數(shù)據(jù)質(zhì)量管理、數(shù)據(jù)的可視化等等，沒有一個單一的產(chǎn)品能完成數(shù)據(jù)倉庫的全部過程。另外，數(shù)倉的構(gòu)建是強依賴與業(yè)務(wù)的，對于不同的業(yè)務(wù)而言，其數(shù)倉的形態(tài)也是不盡相同的。值得注意的是，數(shù)倉是隨著業(yè)務(wù)的變化而不斷迭代的，所以沒有畢其功于一役的方法，這也注定了數(shù)倉是在不斷的變化中趨于完善的。

• 一個項目

成功的企業(yè)級數(shù)據(jù)倉庫通常是以可管理的數(shù)據(jù)集市開始的，每個數(shù)據(jù)集市都可看成是單獨的項目，帶有自己的項目周期和預(yù)算。關(guān)鍵因 素在于每個數(shù)據(jù)集市帶有一致的維度和標準的事實表，這樣便于將單個的數(shù)據(jù)集市集成到一個緊密的單元——企業(yè)級數(shù)據(jù)倉庫中。隨著各個數(shù)據(jù)集市項目的完成，企業(yè)級數(shù)據(jù)倉庫將最終發(fā)展起來。因此，思考數(shù)據(jù)倉庫更好的方法是將它看成一個過程，而非一個項目。

• 一個數(shù)據(jù)模型

簡單講，數(shù)倉是由一堆數(shù)據(jù)模型和數(shù)據(jù)構(gòu)成的，數(shù)據(jù)模型是數(shù)倉的基礎(chǔ)。但是數(shù)倉是多個過程的集合，并不單單指數(shù)據(jù)模型，還包括上面提到的各個環(huán)節(jié)。

• oltp系統(tǒng)的一套備份

這是一個很常見的誤解，認為將業(yè)務(wù)系統(tǒng)的數(shù)據(jù)備份一份并在此基礎(chǔ)之上建立報表系統(tǒng)就算是構(gòu)建了數(shù)倉，其實不然，只完成數(shù)據(jù)遷移過程而不重構(gòu)數(shù)據(jù)模型也不能構(gòu)成數(shù)據(jù)倉庫。

數(shù)據(jù)倉庫系統(tǒng)體系結(jié)構(gòu)

數(shù)據(jù)源->ETL->數(shù)據(jù)倉庫存儲與管理->OLAP->BI工具。

• 數(shù)據(jù)源：通常包括各種業(yè)務(wù)系統(tǒng)數(shù)據(jù)、日志數(shù)據(jù)、外部數(shù)據(jù);
• ETL(extract/transformation/load):整合數(shù)據(jù)并將它們裝入數(shù)據(jù)倉庫的過程。將業(yè)務(wù)系統(tǒng)的數(shù)據(jù)經(jīng)過抽取、清洗轉(zhuǎn)換之后加載到數(shù)據(jù)倉庫的過程，目的是將分散、零亂、標準不統(tǒng)一的數(shù)據(jù)整合到一起，為決策提供分析的依據(jù);
• 數(shù)據(jù)的存儲與管理：數(shù)據(jù)的存儲和管理是整個數(shù)據(jù)倉庫的關(guān)鍵。數(shù)據(jù)倉庫的組織管理方式?jīng)Q定了它有別于傳統(tǒng)數(shù)據(jù)庫，同時也決定了其對外部數(shù)據(jù)的表現(xiàn)形式。數(shù)據(jù)倉庫按照數(shù)據(jù)的覆蓋范圍可以分為企業(yè)級數(shù)據(jù)倉庫和部門級數(shù)據(jù)倉庫(通常稱為數(shù)據(jù)集市);
• OLAP(On-Line Analysis Processing):從數(shù)據(jù)倉庫中抽取詳細數(shù)據(jù)的一個子集并經(jīng)過必要的聚集存儲到OLAP存儲器中供前端分析工具讀取。OLAP系統(tǒng)按照數(shù)據(jù)存儲格式可以分為關(guān)系OLAP(RelationalOLAP，簡稱ROLAP)、多維OLAP(MultidimensionalOLAP，簡稱MOLAP)和混合型OLAP(HybridOLAP，簡稱HOLAP)三種類型;
• 前端工具:查詢工具、數(shù)據(jù)分析工具、數(shù)據(jù)挖掘工具、種報表工具等。

數(shù)倉的必要性

• 數(shù)據(jù)孤島

因為每個人基于自己的業(yè)務(wù)場景建設(shè)數(shù)據(jù)，豎起了一根根的煙囪，相互之間數(shù)據(jù)不互通，導(dǎo)致不論是中間數(shù)據(jù)還是結(jié)果數(shù)據(jù)，可能只能被自己使用。也不知道別的場景有哪些數(shù)據(jù)，有的數(shù)據(jù)是否適合自己的場景。

• 解決問題范圍有限

因為數(shù)據(jù)不互通，對一個系統(tǒng)或業(yè)務(wù)的理解有限，無法最大化應(yīng)用數(shù)據(jù)的價值。

• 效率不足

煙囪數(shù)據(jù)每次都穿透使用貼源數(shù)據(jù)，沒有公共數(shù)據(jù)沉淀，無法高效復(fù)用。每次都要重復(fù)開發(fā)，費時費力。

• 成本不可控

因為大量重復(fù)建設(shè)，在計算和存儲方面都有大量浪費。尤其在海量的監(jiān)控數(shù)據(jù)，因為沒有沉淀，不知道存儲周期設(shè)定多久合適，“那就存越久越好，萬一以后要用到呢”。價值發(fā)揮有限，反而花費大量實際成本。

數(shù)倉建模

維度建模5步驟

維度建模從分析決策的需求出發(fā)構(gòu)建模型，為分析需求服務(wù)，因此 它重點關(guān)注用戶如何更快速地完成需求分析，同時具有較好的大規(guī)模復(fù) 雜查詢的響應(yīng)性能。其典型的代表是星形模型，以及在一些特殊場景下 使用的雪花模型。其設(shè)計分為以下幾個步驟。

• 選擇需要進行分析決策的業(yè)務(wù)過程。

業(yè)務(wù)過程可以是單個業(yè)務(wù)事件，比如交易的支付、退款等;也可以是某個事件的狀態(tài)，比如當(dāng)前的賬戶余額等;還可以是一系列相關(guān)業(yè)務(wù)事件組成的業(yè)務(wù)流程，具體需要看我們分析的是某些事件發(fā)生情況，還是當(dāng)前狀態(tài)， 或是事件流轉(zhuǎn)效率。

• 選擇粒度。

在事件分析中，我們要預(yù)判所有分析需要細分的程度，從而決定選擇的粒度。粒度是維度的 一個組合。值得注意的是，在一個事實表中不要混用多種不同的粒度。

• 識別維表。

選擇好粒度之后，就需要基于此粒度設(shè)計維表，包括維度屬性，用于分析時進行分組和篩選。從who、what、when、where、why、how等方面描述。

選擇事實。確定分析需要衡量的指標 。比如子訂單商品的數(shù)量、金額等等。

• 冗余維度

維度設(shè)計基礎(chǔ)

維度基本概念

• 維度

維度是維度建模的基礎(chǔ)和靈魂。在維度建模中，將度量稱為“事實” ， 將環(huán)境描述為“維度”，維度是用于分析事實所需要的多樣環(huán)境。例如， 在分析交易過程時，可以通過買家、賣家、商品和時間等維度描述交易 發(fā)生的環(huán)境。

• 維度屬性

維度所包含的表示維度的列，稱為維度屬性。維度屬性是查詢約束 條件、分組和報表標簽生成的基本來源，是數(shù)據(jù)易用性的關(guān)鍵。例如， 在查詢請求中，獲取某類目的商品、正常狀態(tài)的商品等，是通過約束商品類目屬性和商品狀態(tài)屬性來實現(xiàn)的，那么類目和商品狀態(tài)就是維度屬性。

• 如何獲取

維度的作用一般是查詢約束、分類匯總以及排序等。如何獲取維度或維度屬性?如上面所提到的，一方面，可以在報表 中獲取;另一方面，可以在和業(yè)務(wù)人員的交談中發(fā)現(xiàn)維度或維度屬性。因為它們經(jīng)常出現(xiàn)在查詢或報表請求中的“按照”( by)語句內(nèi)。例如， 用戶要“按照”月份和產(chǎn)品來查看銷售情況，那么用來描述其業(yè)務(wù)的自 然方法應(yīng)該作為維度或維度屬性包括在維度模型中。

• 總線矩陣

用于設(shè)計并與企業(yè)數(shù)倉總線架構(gòu)交互的基本工具，矩陣的行代表業(yè)務(wù)過程、矩陣的列代表維度，點表示維度于給定的業(yè)務(wù)過程是否存在關(guān)系。

維度建模的基本設(shè)計方法

方法

維度的設(shè)計過程就是確定維度屬性的過程，如何生成維度屬性，以 及所生成的維度屬性的優(yōu)劣，決定了維度使用的方便性，成為數(shù)據(jù)倉庫 易用性的關(guān)鍵。正如 Kimball 所說的，數(shù)據(jù)倉庫的能力直接與維度屬性 的質(zhì)量和深度成正比。

• 第一步:選擇維度或新建維度。作為維度建模的核心，在企業(yè)級數(shù) 據(jù)倉庫中必須保證維度的唯一性
• 第二步:確定主維表。此處的主維表一般是 ODS 表，直接與業(yè)務(wù) 系統(tǒng)同步。
• 第三步:確定相關(guān)維表。數(shù)據(jù)倉庫是業(yè)務(wù)源系統(tǒng)的數(shù)據(jù)整合，不同業(yè)務(wù)系統(tǒng)或者同 一業(yè)務(wù)系統(tǒng)中的表之間存在 關(guān)聯(lián)性。
• 第四步 :確定維度屬性 。本步驟主要 包括兩個階段，其中第 一 個階 段是從主維表 中選擇維度屬性或生成新的維度屬性;第 二個階段是從相 關(guān)維表中選擇維度屬性或生成新 的維度屬性。

注意點

• 盡可能生成豐富的維度屬性
• 盡可能多地給出包括一些富有意義的文字性描述，一般是編碼和文字同時存在，比如商品維度中的商品 ID 和商品標題、 類目 ID 和 類目名稱等。ID 一 般用于不同表之間的關(guān)聯(lián)，而名稱一般用 于報表標簽。
• 區(qū)分數(shù)值型屬性和事實

數(shù)值型宇段是作為事實還是維度屬性，可以參考字段的一般用途。如果通常用于查詢約束條件或分組統(tǒng)計，則是作為維度屬性;如果通常 用于參與度量的計算， 則是作為事實

• 盡量沉淀出通用的維度屬性

有些維度屬性獲取需要進行比較復(fù)雜的邏輯處理，有些需要通過多表關(guān)聯(lián)得到，或者通過單表 的不同宇段混合處理得到，或者通過對單表 的某個字段進行解析得到。此時，需要將盡可能多的通用的維度屬性進行沉淀。

事實表

事實表作為數(shù)據(jù)倉庫維度建模的核心，緊緊圍繞著業(yè)務(wù)過程來設(shè) 計，通過獲取描述業(yè)務(wù)過程的度量來表達業(yè)務(wù)過程，包含了引用的維度 和與業(yè)務(wù)過程有關(guān)的度量。

事實表中一條記錄所表達的業(yè)務(wù)細節(jié)程度被稱為粒度。通常粒度可 以通過兩種方式來表述:一種是維度屬性組合所表示的細節(jié)程度:一種 是所表示的具體業(yè)務(wù)含義。

事實表有三種類型 : 事務(wù)事實表、周期 快照事實表和累積快照事實表。

數(shù)據(jù)模型設(shè)計

模型目標

• 口徑一致
• 避免重復(fù)計算
• 易于數(shù)據(jù)服務(wù)
• 充分支持業(yè)務(wù)

數(shù)據(jù)模型涉及的幾個方面

• 數(shù)倉分層
• 業(yè)務(wù)主題
• 維表/事實表
• 命名規(guī)范

如何規(guī)劃數(shù)倉

良好的模型抽象和清晰的層次劃分能保障支持各種復(fù)雜的數(shù)據(jù)業(yè)務(wù)接入并較好的支撐數(shù)據(jù)業(yè)務(wù)，這是大部分規(guī)劃數(shù)倉時會重點關(guān)注的問題。其實，不同時期來考衡標準是不一樣的，初期可能主要考慮的把業(yè)務(wù)支撐好，中后期可能主要重心在模型和數(shù)據(jù)治理上，通過不同階段將數(shù)據(jù)業(yè)務(wù)價值最大化同時保障數(shù)據(jù)建設(shè)健康發(fā)展。

初期

• 管理方便性：0
• 模型通用性：0.1
• 數(shù)據(jù)治理：0.1
• 安全保障：0.1
• 業(yè)務(wù)支持：0.7

中后期

• 管理方便性：0.1
• 模型通用性：0.2
• 數(shù)據(jù)治理：0.3
• 安全保障：0.2
• 業(yè)務(wù)支持：0.2

在數(shù)據(jù)倉庫建設(shè)初期，由于倉庫數(shù)據(jù)沉淀少，大量的業(yè)務(wù)數(shù)據(jù)需要處理，是暫緩業(yè)務(wù)數(shù)據(jù)需求開發(fā)待倉庫建設(shè)好全力支撐業(yè)務(wù)?還是全力保障業(yè)務(wù)支持逐步來建設(shè)數(shù)據(jù)倉庫建設(shè)?這兩個問題可能也困擾著很多人，個人覺得還是先run起來，先解決一些業(yè)務(wù)問題，即先產(chǎn)出一些價值，這樣會更容易推進后面的工作。如果一上來就大而全，一方面產(chǎn)出價值少被老板挑戰(zhàn)，另一方面實施周期長，很容易成為一個較大的成本中心。在快速發(fā)展的互聯(lián)網(wǎng)行業(yè)像這種建設(shè)方式顯然不太合適，通過數(shù)據(jù)支持保障業(yè)務(wù)快速發(fā)展是我們首要考慮的問題。值得注意的是：先run起來并不是意味著不遵從任何的規(guī)范，只不過首要的問題的支持業(yè)務(wù)。等到數(shù)倉建設(shè)到中后期，這個時候就需要考慮數(shù)據(jù)治理的問題，而不是一味的去滿足需求，比如考慮主題數(shù)據(jù)的中間層數(shù)據(jù)資產(chǎn)沉淀、模型優(yōu)化、任務(wù)優(yōu)化、存儲與計算成本優(yōu)化等等，從而使得數(shù)倉逐漸趨于完善。

如何評價數(shù)倉

• 需求響應(yīng)敏捷 數(shù)據(jù)倉庫建設(shè)不是需求驅(qū)動的，但是數(shù)據(jù)倉庫的根本目的還是面向決策的。在現(xiàn)實中，數(shù)據(jù)倉庫團隊承擔(dān)著很多數(shù)據(jù)查詢分析的職責(zé)，經(jīng)常會收到業(yè)務(wù)方的數(shù)據(jù)需求。一個好的數(shù)據(jù)倉庫模型，能預(yù)知業(yè)務(wù)方的數(shù)據(jù)需求，足夠靈活擴展。能做到這一點，首先需要建立元數(shù)據(jù)管理工具，從而可以方便快速查找數(shù)據(jù)的基本信息。其次，還需要有大量的數(shù)據(jù)中間層，有預(yù)先算好的數(shù)據(jù)指標。此外，數(shù)據(jù)自助提取工具也是快速響應(yīng)數(shù)據(jù)需求的必備工具。
• 數(shù)據(jù)質(zhì)量可靠 在數(shù)據(jù)開發(fā)過程中，很多人可能會遇到這種情況，開發(fā)時間只用了1周，數(shù)據(jù)測試和校驗用了2周甚至更長時間。測試校驗時間長，往往不是由于計算邏輯復(fù)雜，而是上游數(shù)據(jù)不規(guī)范，不可靠，不可信，需要花很大的代價自己做校驗和數(shù)據(jù)探查，這在一定層面上也反映出模型的設(shè)計有問題。
• 可擴展 數(shù)據(jù)倉庫經(jīng)常會面對業(yè)務(wù)的變化，比如業(yè)務(wù)方拿到一個結(jié)果后，經(jīng)常會與更多的維度交叉分析，或者粒度上做上卷或下鉆，還有對統(tǒng)計口徑做特別的限定。數(shù)據(jù)倉庫在要能覆蓋這些不可預(yù)知的變化的需求。更麻煩的是，業(yè)務(wù)規(guī)則會發(fā)生變化。良好的數(shù)據(jù)倉庫設(shè)計要能兼容這些變化，否則以前積累的數(shù)據(jù)都將變成垃圾。
• 穩(wěn)定性 數(shù)據(jù)倉庫還要穩(wěn)定地保障數(shù)據(jù)的產(chǎn)出，服務(wù)于業(yè)務(wù)系統(tǒng)，不要經(jīng)常掉鏈子。造成不穩(wěn)定的因素往往是機器網(wǎng)絡(luò)等硬件因素，但是良好的數(shù)據(jù)倉庫設(shè)計能在硬件故障后快速恢復(fù)數(shù)據(jù)，不會造成連鎖的災(zāi)難。