1.3 數據倉庫架構

前面兩個小節介紹了數據倉庫、操作型系統、分析型系統等概念，也指出了分析型系統的數據源一般來自數據倉庫，而數據倉庫的數據來自于操作型系統。本小節從技術角度討論數據倉庫的組成和架構。

1.3.1 基本架構

“架構”是什么？這個問題從來就沒有一個準確的答案。在軟件行業，一種被普遍接受的架構定義是指系統的一個或多個結構。結構中包括軟件的構建（構建是指軟件的設計與實現），構建的外部可以看到屬性以及它們之間的相互關系。這里參考此定義，把數據倉庫架構理解成構成數據倉庫的組件及其之間的關系，那么就有了如圖1-1所示的數據倉庫架構圖。

下面詳細說明圖1-1中的各個組件及其所起的作用。

圖中顯示的整個數據倉庫環境包括操作型系統和數據倉庫系統兩大部分。操作型系統的數據由各種形式的業務數據組成，這其中可能有關系數據庫、TXT或CSV文件、HTML或XML文檔，還可能存在外部系統的數據，比如網絡爬蟲抓取來的互聯網數據等，數據可能是結構化、半結構化、非結構化的。這些數據經過抽取、轉換和裝載（ETL）過程進入數據倉庫系統。

這里把ETL過程分成了抽取和轉換裝載兩個部分。抽取過程負責從操作型系統獲取數據，該過程一般不做數據聚合和匯總，但是會按照主題進行集成，物理上是將操作型系統的數據全量或增量復制到數據倉庫系統的RDS中。轉換裝載過程并將數據進行清洗、過濾、匯總、統一格式化等一系列轉換操作，使數據轉為適合查詢的格式，然后裝載進數據倉庫系統的TDS中。傳統數據倉庫的基本模式是用一些過程將操作型系統的數據抽取到文件，然后另一些過程將這些文件轉化成MySQL或Oracle這樣的關系數據庫的記錄。最后，第三部分過程負責把數據導入進數據倉庫。

RDS（RAW DATA STORES）是原始數據存儲的意思。將原始數據保存到數據倉庫里是個不錯的想法。ETL過程的bug或系統中的其他錯誤是不可避免的，保留原始數據使得追蹤并修改這些錯誤成為可能。有時數據倉庫的用戶會有查詢細節數據的需求，這些細節數據的粒度與操作型系統的相同。有了RDS，這種需求就很容易實現，用戶可以查詢RDS里的數據而不必影響業務系統的正常運行。這里的RDS實際上是起到了操作型數據存儲（ODS）的作用，關于ODS相關內容本小節后面會有詳細論述。

TDS（TRANSFORMED DATA STORES）意為轉換后的數據存儲。這是真正的數據倉庫中的數據。大量的用戶會在經過轉換的數據集上處理他們的日常查詢。如果前面的工作做得好，這些數據將被以保證最重要的和最頻繁的查詢能夠快速執行的方式構建。

這里的原始數據存儲和轉換后的數據存儲是邏輯概念，它們可能物理存儲在一起，也可能分開。當原始數據存儲和轉換后的數據存儲物理上分開時，它們不必使用同樣的軟硬件。傳統數據倉庫中，原始數據存儲通常是本地文件系統，原始數據被組織進相應的目錄中，這些目錄是基于數據從哪里抽取或何時抽取建立（例如以日期作為文件或目錄名稱的一部分）；轉換后的數據存儲一般是某種關系數據庫。

自動化調度組件的作用是自動定期重復執行ETL過程。不同角色的數據倉庫用戶對數據的更新頻率要求也會有所不同，財務主管需要每月的營收匯總報告，而銷售人員想看到每天的產品銷售數據。作為通用的需求，所有數據倉庫系統都應該能夠建立周期性自動執行的工作流作業。傳統數據倉庫一般利用操作系統自帶的調度功能（如Linux的cron或Windows的計劃任務）實現作業自動執行。

數據目錄有時也被稱為元數據存儲，它可以提供一份數據倉庫中數據的清單。用戶通過它應該可以快速解決這些問題：什么類型的數據被存儲在哪里，數據集的構建有何區別，數據最后的訪問或更新時間等。此外還可以通過數據目錄感知數據是如何被操作和轉換的。一個好的數據目錄是讓用戶體驗到系統易用性的關鍵。

查詢引擎組件負責實際執行用戶查詢。傳統數據倉庫中，它可能是存儲轉換后數據的（Oracle、MySQL等關系數據庫系統內置的）查詢引擎，還可能是以固定時間間隔向其導入數據的OLAP立方體，如Essbase cube。

用戶界面指的是最終用戶所使用的接口程序?？赡苁且粋€GUI軟件，如BI套件的中的客戶端軟件，也可能就是一個瀏覽器。

1.3.2 主要數據倉庫架構

在數據倉庫技術演化過程中，產生了幾種主要的架構方法，包括數據集市架構、Inmon企業信息工廠架構、Kimball數據倉庫架構和混合型數據倉庫架構。

1．數據集市架構

數據集市是按主題域組織的數據集合，用于支持部門級的決策。有兩種類型的數據集市：獨立數據集市和從屬數據集市。

獨立數據集市集中于部門所關心的單一主題域，數據以部門為基礎部署，無須考慮企業級別的信息共享與集成。例如，制造部門、人力資源部門和其他部門都各自有他們自己的數據集市。獨立數據集市從一個主題域或一個部門的多個事務系統獲取數據，用以支持特定部門的業務分析需要。一個獨立數據集市的設計既可以使用實體關系模型，也可以使用多維模型。數據分析或商業智能工具直接從數據集市查詢數據，并將查詢結果顯示給用戶。一個典型的獨立數據集市架構如圖1-2所示。

因為一個部門的業務相對于整個企業要簡單，數據量也小得多，所以部門的獨立數據集市具有周期短、見效快的特點。如果從企業整體的視角來觀察這些數據集市，你會看到每個部門使用不同的技術，建立不同的ETL的過程，處理不同的事務系統，而在多個獨立的數據集市之間還會存在數據的交叉與重疊，甚至會有數據不一致的情況。從業務角度看，當部門的分析需求擴展，或者需要分析跨部門或跨主題域的數據時，獨立數據市場會顯得力不從心。而當數據存在歧義，比如同一個產品，在A部門和B部門的定義不同時，將無法在部門間進行信息比較。

另外一種數據集市是從屬數據集市。如Bill Inmon所說，從屬數據集市的數據來源于數據倉庫。數據倉庫里的數據經過整合、重構、匯總后傳遞給從屬數據集市。從屬數據集市的架構如圖1-3所示。

建立從屬數據集市的好處主要有：

● 性能：當數據倉庫的查詢性能出現問題，可以考慮建立幾個從屬數據集市，將查詢從數據倉庫移出到數據集市。

● 安全：每個部門可以完全控制他們自己的數據。

● 數據一致：因為每個數據集市的數據來源都是同一個數據倉庫，有效消除了數據不一致的情況。

Inmon企業信息工廠架構

Inmon企業信息工廠架構如圖1-4所示，我們來看圖中的組件是如何協同工作的。

● 應用系統：這些應用是組織中的操作型系統，用來支撐業務。它們收集業務處理過程中產生的銷售、市場、材料、物流等數據，并將數據以多種形式進行存儲。操作型系統也叫源系統，為數據倉庫提供數據。

● ETL過程：ETL過程從操作型系統抽取數據，然后將數據轉換成一種標準形式，最終將轉換后的數據裝載到企業級數據倉庫中。ETL是周期性運行的批處理過程。

● 企業級數據倉庫：是該架構中的核心組件。正如Inmon數據倉庫所定義的，企業級數據倉庫是一個細節數據的集成資源庫。其中的數據以最低粒度級別被捕獲，存儲在滿足三范式設計的關系數據庫中。

● 部門級數據集市：是面向主題數據的部門級視圖，數據從企業級數據倉庫獲取。數據在進入部門數據集市時可能進行聚合。數據集市使用多維模型設計，用于數據分析。重要的一點是，所有的報表工具、BI工具或其他數據分析應用都從數據集市查詢數據，而不是直接查詢企業級數據倉庫。

2. Kimball數據倉庫架構

Kimball數據倉庫架構如圖1-5所示。

對比上一張圖可以看到，Kimball與Inmon兩種架構的主要區別在于核心數據倉庫的設計和建立。Kimball的數據倉庫包含高粒度的企業數據，使用多維模型設計，這也意味著數據倉庫由星型模式的維度表和事實表構成。分析系統或報表工具可以直接訪問多維數據倉庫里的數據。在此架構中的數據集市也與Inmon中的不同。這里的數據集市是一個邏輯概念，只是多維數據倉庫中的主題域劃分，并沒有自己的物理存儲，也可以說是虛擬的數據集市。

3．混合型數據倉庫架構

混合型數據倉庫架構如圖1-6所示。

所謂的混合型結構，指的是在一個數據倉庫環境中，聯合使用Inmon和Kimball兩種架構。從架構圖可以看到，這種架構將Inmon方法中的數據集市部分替換成了一個多維數據倉庫，而數據集市則是多維數據倉庫上的邏輯視圖。使用這種架構的好處是，既可以利用規范化設計消除數據冗余，保證數據的粒度足夠細；又可以利用多維結構更靈活地在企業級實現報表和分析。

1.3.3 操作數據存儲

操作數據存儲又稱為ODS，是Operational Data Store的簡寫，其定義是這樣的：一個面向主題的、集成的、可變的、當前的細節數據集合，用于支持企業對于即時性的、操作性的、集成的全體信息的需求。對比1.1節中數據倉庫的定義不難看出，操作型數據存儲在某些方面具有類似于數據倉庫的特點，但在另一些方面又顯著不同于數據倉庫。

● 像數據倉庫一樣，是面向主題的。

● 像數據倉庫一樣，其數據是完全集成的。

● 數據是當前的，這與數據倉庫存儲歷史數據的性質明顯不同。ODS具有最少的歷史數據（一般是30天到60天），而盡可能接近實時地展示數據的狀態。

● 數據是可更新的，這是與靜態數據倉庫又一個很大的區別。ODS就如同一個事務處理系統，當新的數據流進ODS時，受其影響的字段被新信息覆蓋。

● 數據幾乎完全是細節數據，僅具有少量的動態聚集或匯總數據。通常將ODS設計成包含事務級的數據，即包含該主題域中最低粒度級別的數據。

● 在數據倉庫中，幾乎沒有針對其本身的報表，報表均放到數據集市中完成；與此不同，在ODS中，業務用戶頻繁地直接訪問ODS。

在一個數據倉庫環境中，ODS具有如下幾個作用：

● 充當業務系統與數據倉庫之間的過渡區。數據倉庫的數據來源復雜，可能分布在不同的數據庫，不同的地理位置，不同的應用系統之中，而且由于數據形式的多樣性，數據轉換的規則往往極為復雜。如果直接從業務系統抽取數據并做轉換，不可避免地會對業務系統造成影響。而ODS中存放的數據從數據結構、數據粒度、數據之間的邏輯關系上都與業務系統基本保持一致，因此抽取過程只需簡單的數據復制而基本不再需要做數據轉換，大大降低了復雜性，同時最小化對業務系統的侵入。

● 轉移部分業務系統細節查詢的功能。某些原來由業務系統產生的報表、細節數據的查詢能夠在ODS中進行，從而降低業務系統的查詢壓力。

● 完成數據倉庫中不能完成的一些功能。用戶有時會要求數據倉庫查詢最低粒度級別的細節數據，而數據倉庫中存儲的數據一般都是聚合或匯總過的數據，并不存儲每筆交易產生的細節數據。這時就需要把細節數據查詢的功能轉移到ODS來完成，而且ODS的數據模型是按照面向主題的方式組織的，可以方便地支持多維分析。即數據倉庫從宏觀角度滿足企業的決策支持要求，而ODS層則從微觀角度反映細節交易數據或者低粒度的數據查詢要求。