數據倉庫基礎

一、數據倉庫定義

數據倉庫，英文名稱為Data Warehouse，可簡寫為DW。

關於數據倉庫概念的標準定義業內認可度比較高的，是由數據倉庫之父比爾·恩門（Bill Inmon）在1991年出版的“Building the Data Warehouse”（《建立數據倉庫》）一書中所提出：

中文定義：數據倉庫是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用於支持管理決策。

英文定義：A data warehouse is a subject-oriented, integrated, nonvolatile, and time-variant collection of data in support of management’s decisions.

二、數據倉庫整體架構

觀點一：

數據倉庫強調分層。主要包含數據採集層、數據存儲層、數據共享層、數據應用層。

觀點二：

數據倉庫的基本架構主要包含的是數據流入流出的過程，可以分為三層——源數據、數據倉庫、數據應用：

　數據倉庫從各數據源獲取數據及在數據倉庫內的數據轉換和流動都可以認為是ETL（抽取Extra, 轉化Transfer, 裝載Load）的過程，ETL是數據倉庫的流水線，也可以認為是數據倉庫的血液，它維繫著數據倉庫中數據的新陳代謝，而數據倉庫日常的管理和維護工作的大部分精力就是保持ETL的正常和穩定。

1. 數據採集

數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。

2.數據存儲與分析

　源數據通過ETL的日常任務調度導出，並經過轉換後以特性的形式存入數據倉庫。其實這個過程一直有很大的爭議，就是到底數據倉庫需不需要儲存細節數據，一方的觀點是數據倉庫面向分析，所以只要存儲特定需求的多維分析模型；另一方的觀點是數據倉庫先要建立和維護細節數據，再根據需求聚合和處理細節數據生成特定的分析模型。我比較偏向後面一個觀點：數據倉庫並不需要儲存所有的原始數據，但數據倉庫需要儲存細節數據，並且導入的數據必須經過整理和轉換使其面向主題。簡單地解釋下：

(1).為什麼不需要所有原始數據？數據倉庫面向分析處理，但是某些源數據對於分析而言沒有價值或者其可能產生的價值遠低於儲存這些數據所需要的數據倉庫的實現和性能上的成本。比如我們知道用戶的省份、城市足夠，至於用戶究竟住哪裡可能只是物流商關心的事，或者用戶在博客的評論內容可能只是文本挖掘會有需要，但將這些冗長的評論文本存在數據倉庫就得不償失；

(2).為什麼要存細節數據？細節數據是必需的，數據倉庫的分析需求會時刻變化，而有了細節數據就可以做到以不變應萬變，但如果我們只存儲根據某些需求搭建起來的數據模型，那麼顯然對於頻繁變動的需求會手足無措；

(3).為什麼要面向主題？面向主題是數據倉庫的第一特性，主要是指合理地組織數據以方面實現分析。對於源數據而言，其數據組織形式是多樣的，像點擊流的數據格式是未經優化的，前臺數據庫的數據是基於OLTP操作組織優化的，這些可能都不適合分析，而整理成面向主題的組織形式才是真正地利於分析的，比如將點擊流日誌整理成頁面（Page）、訪問（Visit或Session）、用戶（Visitor）三個主題，這樣可以明顯提升分析的效率。

3.數據共享

指的是數據分析與計算後的結果存放的地方，其實就是關係型數據庫和NOSQL數據庫

4.數據應用

業務用戶通過BI產品進行應用。

5.實時計算

在海量數據下，依靠傳統數據庫和傳統實現方法基本完成不了，需要的是一種分佈式的、高吞吐量的、延時低的、高可靠的實時計算框架

6.任務調度與監控

任務調度與監控系統，它作為數據倉庫/數據平臺的中樞，負責調度和監控所有任務的分配與運行。

7.元數據管理

元數據（Meta Date），其實應該叫做解釋性數據，或者數據字典，即數據的數據。主要記錄數據倉庫中模型的定義、各層級間的映射關係、監控數據倉庫的數據狀態及ETL的任務運行狀態。一般會通過元數據資料庫（Metadata Repository）來統一地存儲和管理元數據，其主要目的是使數據倉庫的設計、部署、操作和管理能達成協同和一致。

數據倉庫建設步驟：

1.系統分析，確定主題

確定一下幾個因素：

·操作出現的頻率，即業務部門每隔多長時間做一次查詢分析。

·在系統中需要保存多久的數據，是一年、兩年還是五年、十年。

·用戶查詢數據的主要方式，如在時間維度上是按照自然年，還是財政年。

·用戶所能接受的響應時間是多長、是幾秒鐘，還是幾小時。

2.選擇滿足數據倉庫系統要求的軟件平臺

選擇合適的軟件平臺，包括數據庫、建模工具、分析工具等。有許多因素要考慮，如系統對數據量、響應時間、分析功能的要求等，以下是一些公認的選擇標準：

·廠商的背景和支持能力，能否提供全方位的技術支持和諮詢服務。

·數據庫對大數據量（TB級）的支持能力。

·數據庫是否支持並行操作。

·能否提供數據倉庫的建模工具，是否支持對元數據的管理。

·能否提供支持大數據量的數據加載、轉換、傳輸工具（ETT）。

·能否提供完整的決策支持工具集，滿足數據倉庫中各類用戶的需要。

3.建立數據倉庫的邏輯模型

具體步驟如下：

（1）確定建立數據倉庫邏輯模型的基本方法。

（2）基於主題視圖，把主題視圖中的數據定義轉到邏輯數據模型中。

（3）識別主題之間的關係。

（4）分解多對多的關係。

（5）用範式理論檢驗邏輯數據模型。

（6）由用戶審核邏輯數據模型。

4.邏輯數據模型轉化為數據倉庫數據模型

具體步驟如下：

（1）刪除非戰略性數據：數據倉庫模型中不需要包含邏輯數據模型中的全部數據項，某些用於操作處理的數據項要刪除。

（2）增加時間主鍵：數據倉庫中的數據一定是時間的快照，因此必須增加時間主鍵。

（3）增加派生數據：對於用戶經常需要分析的數據，或者為了提高性能，可以增加派生數據。

（4）加入不同級別粒度的彙總數據：數據粒度代表數據細化程度，粒度越大，數據的彙總程度越高。粒度是數據倉庫設計的一個重要因素，它直接影響到駐留在數據倉庫中的數據量和可以執行的查詢類型。顯然，粒度級別越低，則支持的查詢越多；反之，能支持的查詢就有限。

5.數據倉庫數據模型優化

數據倉庫設計時，性能是一項主要考慮因素。在數據倉庫建成後，也需要經常對其性能進行監控，並隨著需求和數據量的變更進行調整。

優化數據倉庫設計的主要方法是：

·合併不同的數據表。

·通過增加彙總表避免數據的動態彙總。

·通過冗餘字段減少表連接的數量，不要超過3~5個。

·用ID代碼而不是描述信息作為鍵值。

·對數據表做分區。

6.數據清洗轉換和傳輸

由於業務系統所使用的軟硬件平臺不同，編碼方法不同，業務系統中的數據在加載到

在設計數據倉庫的數據加載方案時，必須考慮以下幾項要求：

·加載方案必須能夠支持訪問不同的數據庫和文件系統。

·數據的清洗、轉換和傳輸必須滿足時間要求，能夠在規定的時間範圍內完成。

·支持各種轉換方法，各種轉換方法可以構成一個工作流。

·支持增量加載，只把自上一次加載以來變化的數據加載到數據倉庫。

7.開發數據倉庫的分析應用

建立數據倉庫的最終目的是為業務部門提供決策支持能力，必須為業務部門選擇合適的工具實現其對數據倉庫

信息部門所選擇的開發工具必須能夠：

·滿足用戶的全部分析功能要求。數據倉庫中的用戶包括了企業中各個業務部門，他們的業務不同，要求的分析功能也不同。如有的用戶只是簡單的分析報表，有些用戶則要求做預測和趨勢分析。

·提供靈活的表現方式。分析的結果必須能夠以直觀、靈活的方式表現，支持複雜的圖表。使用方式上，可以是客戶機/服務器方式，也可以是瀏覽器方式。

事實上，沒有一種工具能夠滿足數據倉庫的全部分析功能需求，一個完整的數據倉庫系統的功能可能是由多種工具來實現，因此必須考慮多個工具之間的接口和集成性問題，對於用戶來說，希望看到的是一致的界面。

8.數據倉庫的管理

只重視數據倉庫

數據庫管理需要考以下幾個方面：

·安全性管理。數據倉庫中的用戶只能訪問到他的授權範圍內的數據，數據在傳輸過程中的加密策略。

·數據倉庫的備份和恢復。數據倉庫的大小和備份的頻率直接影響到備份策略。

·如何保證數據倉庫系統的可用性，硬件還是軟件方法。

·數據老化。設計數據倉庫中數據的存放時間週期和對過期數據的老化方法，如歷史數據只保存彙總數據，當年數據保存詳細記錄。

然而，元數據管理貫穿於整個系統的建設過程中，元數據是描述數據的數據。在數據採集階段，元數據主要包括下列信息：

·源數據的描述定義：類型、位置、結構。

·數據轉換規則：編碼規則、行業標準。

·目標數據倉庫的模型描述：星型/雪花模型定義，維/事實結構定義。

·源數據到目標數據倉庫的映射關係：函數/表達式定義。

·代碼：生成轉換程序、自動加載程序等。

在數據管理階段，元數據主要包括下列信息：

·彙總數據的描述：彙總/聚合層次、物化視圖結構定義。

·歷史數據存儲規則：位置、存儲粒度。

·多維數據結構描述：立方體定義、維結構、度量值、鑽取層次定義等。

在數據展現階段，元數據主要包括以下信息：

·報表的描述：報表結構的定義。

·統計函數的描述：各類統計分析函數的定義。

·結果輸出的描述：圖、表輸出的定義。

元數據不但是獨立存放，而且對用戶是透明的，標準元數據之間可以互相轉換。

閱讀更多 小可愛100w 的文章

關鍵字: NoSQL 軟件 恩門