數據挖掘、數據倉庫，近些年在國內越來越熱、越來越流行，需求比較多，應用也比較廣泛，它們常服務于商務智能活動。通俗地概括來講，我們可將它們統稱作數據分析、數據計算。

數據挖掘、數據倉庫，近些年在國內越來越熱、越來越流行，需求比較多，應用也比較廣泛，它們常服務于商務智能活動。通俗地概括來講，我們可將它們統稱作數據分析、數據計算。

我們介紹數據倉庫在商業應用，主要涉及有兩個方面，一個是有關數據倉庫的常用技術，另一個是有關數據倉庫的應用案例。同時也涉及數據倉庫的兩個背景，在我們經歷的北美項目中，一個主要方面屬于實際的商業應用項目，另一方面屬于高校的學術研究領域的項目。兩者在很多方面有明顯的區別。我們這里主要介紹數據倉庫的商業應用，因為商業應用經驗存在比較大的價值。

數據倉庫的商業應用技術之一：異構數據集成技術

數據倉庫是集成的，數據倉庫的要素包括本身是集成的、面向主題的、只讀的、歷史變化的。

如下圖1：

例如，應用Oracle作為數據倉庫的支撐環境，它有很多數據源，是由業務生產系統源源不斷產生的，可能包括DB2、SQL Server、MY SQL等等不同的源數據。

異構數據集成的方法有很多，主要包括：

1. 如果Oracle作為數據倉庫是基于Windows環境的，通過MS ODBC開放數據庫互聯;第三方ODBC開放數據庫互聯，如Data Direct Connect for ODBC;專用數據網關，如Transpatent Gateway;

2. 如果Oracle作為數據倉庫是基于Unix或Linux環境的，通過Unix ODBC開放數據庫互聯;專用數據網關等。

3. 通過外部文件到數據庫的導出和導入。

數據挖掘、數據倉庫，近些年在國內越來越熱、越來越流行，需求比較多，應用也比較廣泛，它們常服務于商務智能活動。通俗地概括來講，我們可將它們統稱作數據分析、數據計算。

數據倉庫的商業應用技術之二：數據的ETL抽取、變換、載入技術

1. 三層ETL體系

我們將數據的抽取、變換、載入技術稱為ETL技術。ETL技術中，按要素分為三層，即元數據層、數據操縱層、數據存儲層，三層交互作用。ETL工作首先需要在元數據層定義和構建，同時也涉及到有關數據存儲的方式定義;基于元數據層的對象，ETL工作在數據操縱層對數據進行實際操作，并把數據載入到數據存儲層;ETL工作還需要在數據存儲層做一些必要的數據管理和優化工作。這就形成了ETL數據操縱的三層體系，如下圖。

元數據 -> 數據操作層 -> 數據存儲層。

2. ETL遞進式數據演變

ETL數據變換在實際項目中有很多的方法，很多階段，在此我們根據經驗分為4個階段為：

LANDING：抽取數據到Landing層中。

STAGING：根據我們業務的要求進行數據變換到Staging層中。

DATA CENTER：再根據需求設計放在Data Center層(也是EDW企業級數據倉庫)中。

DATA MART：最后根據主題存放在Data Mart層中，如下圖。

3. 并行ETL架構

并行處理技術也是數據庫的一項核心技術，它可以提高ETL過程中在數據層處理的執行效率，將大量的查詢過程分布到多個節點上同時執行。一個并行處理體系結構的數據倉庫系統，不僅應該確保底層硬件平臺的所有資源都得充分利用，而且應該能夠將這些資源適當分配給多個并發請求，以提高數據層的并發處理能力，如下圖。

4. ETL任務調度及備份

ETL任務調度(Scheduling Tasks)很重要，需要實時的備份。常用的ETL任務調度工具(Scheduling Tools)有：

Unix scripts：Corn有比較穩定的可靠性。

Database Management Tool：Oracle Enterprise Manager

Third Party Tool：Control-M專用工具，專門為數據倉庫完成任務，主要做ETL的Scheduling。

ETL任務調度備份方法有很多，如：

Scheduling Backup：Control-M as Master,

Unix Corn as Backup.

這樣，相當于做了兩個Scheduling設計，互為備份。

數據挖掘、數據倉庫，近些年在國內越來越熱、越來越流行，需求比較多，應用也比較廣泛，它們常服務于商務智能活動。通俗地概括來講，我們可將它們統稱作數據分析、數據計算。

數據倉庫的商業應用技術之三：數據倉庫的架構技術

1. 多層次企業級數據倉庫：DataMart-> EDW

在這個數據倉庫架構的模型中，左邊的是數據源通過變換到數據集市中，然后從數據集市再到企業級數據倉庫(EDW)中，最后直接給終端用戶使用。多層次主要體現在ETL和數據集成上，這個方法的優點在于建立了多個數據集市，它體現了一個分布式集成的概念，很大程度降低了企業級數據倉庫建設的風險，更減少了資源投入，如下圖。

2. 多層次企業級數據倉庫： EDW -> DataMart

這個模型一開始就設計它的企業級數據倉庫(EDW)，這種方法針對于一些涵蓋了多個業務系統、面向不同用戶的需求、針對數據平臺也不一樣的企業，例如：銀行。用這個方法，把所有的業務系統考慮入內，通常考慮整體設計，然后再分發出去。DataMart劃分方法有很多種。它的優點是集成度比較好，總體設計一開始就把所有的數據源都放到企業級數據倉庫。缺點是風險高，投入也相對很高，如下圖。

通常來說，實際項目中采用第一種方法的比較多。

3. 近實時的數據倉庫

數據倉庫是動態的，是隨時間變化的。應用數據倉庫，我們可以每天、每個月、每年分段來調取數據，如下圖。

近實時(Near Real Time)的要求是比較高的，例如我們建立了一個數據倉庫是全球性的，數據倉庫中心在多倫多，數據源分布在很多地方如北美、歐洲，它需要一個近實時的操作系統。近實時的概念是操作系統和業務系統產生的數據，在一小時之內完成所有ETL任務，最后進入數據倉庫。它對數據源的業務系統有比較高的要求，如數據的穩定性、可靠性、網絡傳輸速率等，同時也涵蓋了很多方面的專門技術來解決實時性。

4. 后復合數據集市

由于業務的擴展，企業增加了一個新的生產系統，從而誕生了新的數據源。我們需要建立一個新的數據源(New Data Source)通過ETL工作集成到數據集市(DMART)中，并與企業級數據倉庫(EDW)結合到一起，最后提供給終端用戶，如下圖。

內容導航

數據倉庫的商業應用技術之四：數據倉庫的優化技術

數據倉庫優化包括很多內容，包括數據庫實例優化、數據庫的設計優化、數據倉庫設計(建模)優化、數據存儲優化、存儲過程優化、中間層支持優化、應用支持優化(智能報表、即時查詢、數據挖掘等應用)。

數據倉庫的客戶有兩個常見要求，一個要求是快，還有一個要求是穩定。快有很多方面，在核心的數據庫，有太多的因素影響速度，所以優化時要各個方面都要考慮。

1. 數據倉庫設計(建模)優化

在設計的時候有很多的情況發生，在這里重點提一點，數據倉庫還要考慮一個時間的因素，有的時候開始設計的時候性能非常好，但隨著系統長時間的運行，發生了很多無法解決的、由設計造成的問題，如性能問題。曾經有歐洲的一家汽車企業，設計師對數據倉庫的模型設計想法非常好，但是不適宜一個長時間的運行，數據增長以后性能大幅下降，數據運行可能會非常的慢，到了無法容忍的地步，結果導致運行兩年以后就不行了。想要再進行結構修改也不可行了，必須要全部重來。

2. 數據存儲優化

數據存儲優化主要是如何盡量減小存儲空間和提升性能。這點很重要，數據倉庫往往都是犧牲空間來提升速度。但是也需要優化，很多問題在一些小的數據倉庫系統可能都不存在，但是在比較大型的數據倉庫系統中就會出現了。數據倉庫數據不斷增加，當使用時間比較長之后就會造成數據量過大、性能會大幅下降，為了避免這樣的情況，我們在開始設計時，就要考慮到后續的使用，需要進行數據存儲優化，主要包括：

Data Block Design：基本存儲單位的設計。

Table Spacing：表空間的設計。

Table Partitioning：表空間的優化。

Indexing：索引的設計。

Index Partitioning：索引優化。

Data Compressing：數據壓縮(同時會犧牲一些性能)。

3. 存儲過程優化：就是后臺的一些存儲過程的優化。

4. 中間層支持優化：WEB SERVER之類的系統優化。

5. 應用支持優化：主要有智能報表、即時查詢、數據挖掘等應用，也就是前臺的一些應用也是需要優化的。一個REQUEST發出去，返回的RESULT，這個過程是有很多的步驟，也是需要進行優化處理的。

另外，還需要在一些方面對數據倉庫進行優化，如：異構數據庫互聯優化。異構數據庫互聯，做數據倉庫第一步就會碰到，數據倉庫肯定有很多不同的數據源。具體如下圖所示。

上述例子就比較復雜，既有不同數據庫，又有不同操作系統。異構數據庫互聯優化的案例：

A、文件導出導入 -〉開放數據庫互聯

由文件導出導入方案改為開放數據庫互聯方案，可優化異構數據庫互聯的性能。例如：Windows ODBC, Unix ODBC，性能和可控性上肯定會比較好一點，但是有的時候并不是這樣簡單的要求，還需要考慮數據安全性的要求。例如某些情況下，條件不允許做數據庫的互聯。還有業務系統的健壯性能也要考慮。

B、通用ODBC -〉第三方專用ODBC

由ODBC方案改為第三方專用ODBC方案，可優化異構數據庫互聯的性能。例如： MS ODBC -> Data Direct ODBC。

C、開放數據庫互聯-〉專用數據網關

由ODBC方案改為專用數據網關方案，可優化異構數據庫互聯的性能。例如： MS ODBC -> Transparent Gateway。