ETL學習心得：探求數據倉庫關鍵環節ETL的本質
做數據倉庫系統，ETL是關鍵的一環。說大了，ETL是數據整合解決方案，說小了，就是倒數據的工具。回憶 一下工作這麼些年來，處理數據遷移、轉換的工作倒還真的不少。但是那些工作基本上是一次性工作或者很小數據量，使用access、DTS或是自己編個小程 序搞定。可是在數據倉庫系統中，ETL上升到了一定的理論高度，和原來小打小鬧的工具使用不同了。究竟什麼不同，從名字上就可以看到，人家已經將倒數據的 過程分成3個步驟，E、T、L分別代表抽取、轉換和裝載。
其實ETL過程就是數據流動的過程，從不同的數據源流向不同的目標數據。但在數據倉庫中，ETL有幾個特點，一是數據同步，它不是一次性倒完數據就拉到， 它是經常性的活動，按照固定週期運行的，甚至現在還有人提出了實時ETL的概念。二是數據量，一般都是巨大的，值得你將數據流動的過程拆分成E、T和L。
現在有很多成熟的工具提供ETL功能，例如datastage、powermart等，且不說他們的好壞。從應用角度來說，ETL的過程其實不是非常復 雜，這些工具給數據倉庫工程帶來和很大的便利性，特別是開發的便利和維護的便利。但另一方面，開發人員容易迷失在這些工具中。舉個例子，VB是一種非常簡 單的語言並且也是非常易用的編程工具，上手特別快，但是真正VB的高手有多少？微軟設計的產品通常有個原則是“將使用者當作傻瓜”，在這個原則下，微軟的 東西確實非常好用，但是對於開發者，如果你自己也將自己當作傻瓜，那就真的傻了。ETL工具也是一樣，這些工具爲我們提供圖形化界面，讓我們將主要的精力 放在規則上，以期提高開發效率。從使用效果來說，確實使用這些工具能夠非常快速地構建一個job來處理某個數據，不過從整體來看，並不見得他的整體效率會 高多少。問題主要不是出在工具上，而是在設計、開發人員上。他們迷失在工具中，沒有去探求ETL的本質。
可以說這些工具應用了這麼長時間，在這麼多項目、環境中應用，它必然有它成功之處，它必定體現了ETL的本質。如果我們不透過表面這些工具的簡單使用去看 它背後蘊涵的思想，最終我們作出來的東西也就是一個個獨立的job，將他們整合起來仍然有巨大的工作量。大家都知道“理論與實踐相結合”，如果在一個領域 有所超越，必須要在理論水平上達到一定的高度
探求ETL本質之一
ETL的過程就是數據流動的過程，從不同異構數據源流向統一的目標數據。其間，數據的抽取、清洗、轉換和裝載形成串行或並行的過程。ETL的核心還是在於 T這個過程，也就是轉換，而抽取和裝載一般可以作爲轉換的輸入和輸出，或者，它們作爲一個單獨的部件，其複雜度沒有轉換部件高。和OLTP系統中不同，那 裏充滿這單條記錄的insert、update和select等操作，ETL過程一般都是批量操作，例如它的裝載多采用批量裝載工具，一般都是DBMS系 統自身附帶的工具，例如Oracle SQLLoader和DB2的autoloader等。
ETL本身有一些特點，在一些工具中都有體現，下面以datastage和powermart舉例來說。
1、靜態的ETL單元和動態的ETL單元實例；一次轉換指明瞭某種格式的數據如何格式化成另一種格式的數據，對於數據源的物理形式在設計時可以不用指定， 它可以在運行時，當這個ETL單元創建一個實例時才指定。對於靜態和動態的ETL單元，Datastage沒有嚴格區分，它的一個Job就是實現這個功 能，在早期版本，一個Job同時不能運行兩次，所以一個Job相當於一個實例，在後期版本，它支持multiple instances，而且還不是默認選項。Powermart中將這兩個概念加以區分，靜態的叫做Mapping，動態運行時叫做Session。
2、ETL元數據；元數據是描述數據的數據，他的含義非常廣泛，這裏僅指ETL的元數據。主要包括每次轉換前後的數據結構和轉換的規則。ETL元數據還包 括形式參數的管理，形式參數的ETL單元定義的參數，相對還有實參，它是運行時指定的參數，實參不在元數據管理範圍之內。
3、數據流程的控制；要有可視化的流程編輯工具，提供流程定義和流程監控功能。流程調度的最小單位是ETL 單元實例，ETL單元是不能在細分的ETL過程，當然這由開發者來控制，例如可以將抽取、轉換放在一個ETL單元中，那樣這個抽取和轉換隻能同時運行，而 如果將他們分作兩個單元，可以分別運行，這有利於錯誤恢復操作。當然，ETL單元究竟應該細分到什麼程度應該依據具體應用來看，目前還沒有找到很好的細分 策略。比如，我們可以規定將裝載一個表的功能作爲一個ETL單元，但是不可否認，這樣的ETL單元之間會有很多共同的操作，例如兩個單元共用一個Hash 表，要將這個Hash表裝入內存兩次。
4、轉換規則的定義方法；提供函數集提供常用規則方法，提供規則定義語言描述規則。
5、對數據的快速索引；一般都是利用Hash技術，將參照關係表提前裝入內存，在轉換時查找這個hash表。Datastage中有Hash文件技術，Powermart也有類似的Lookup功能。
探求ETL本質之二（分類）
昨在IT-Director上閱讀一篇報告，關於ETL產品分類的。一般來說，我們眼中的ETL工具都是價格昂貴，能夠處理海量數據的傢伙，但是這是其中的一種。它可以分成4種，針對不同的需求，主要是從轉換規則的複雜度和數據量大小來看。它們包括
1、交互式運行環境，你可以指定數據源、目標數據，指定規則，立馬ETL。這種交互式的操作無疑非常方便，但是隻能適合小數據量和複雜度不高的ETL過 程，因爲一旦規則複雜了，可能需要語言級的描述，不能簡簡單單拖拖拽拽就可以的。還有數據量的問題，這種交互式必然建立在解釋型語言基礎上，另外他的靈活 性必然要犧牲一定的性能爲代價。所以如果要處理海量數據的話，每次讀取一條記錄，每次對規則進行解釋執行，每次在寫入一條記錄，這對性能影響是非常大的。
2、專門編碼型的，它提供了一個基於某種語言的程序框架，你可以不必將編程精力放在一些周邊的功能上，例如讀文件功能、寫數據庫的功能，而將精力主要放在 規則的實現上面。這種近似手工代碼的性能肯定是沒話說，除非你的編程技巧不過關（這也是不可忽視的因素之一）。對於處理大數據量，處理複雜轉換邏輯，這種 方式的ETL實現是非常直觀的。
3、代碼生成器型的，它就像是一個ETL代碼生成器，提供簡單的圖形化界面操作，讓你拖拖拽拽將轉換規則都設定好，其實他的後臺都是生成基於某種語言的程 序，要運行這個ETL過程，必須要編譯才行。Datastage就是類似這樣的產品，設計好的job必須要編譯，這避免了每次轉換的解釋執行，但是不知道 它生成的中間語言是什麼。以前我設計的ETL工具大挪移其實也是歸屬於這一類，它提供了界面讓用戶編寫規則，最後生成C++語言，編譯後即可運行。這類工 具的特點就是要在界面上下狠功夫，必須讓用戶輕鬆定義一個ETL過程，提供豐富的插件來完成讀、寫和轉換函數。大挪移在這方面就太弱了，規則必須手寫，而 且要寫成標準c++語法，這未免還是有點難爲最終用戶了，還不如做成一個專業編碼型的產品呢。另外一點，這類工具必須提供面向專家應用的功能，因爲它不可 能考慮到所有的轉換規則和所有的讀寫，一方面提供插件接口來讓第三方編寫特定的插件，另一方面還有提供特定語言來實現高級功能。例如Datastage提 供一種類Basic的語言，不過他的Job的腳本化實現好像就做的不太好，只能手工繪製job，而不能編程實現Job。
4、最後還有一種類型叫做數據集線器，顧名思義，他就是像Hub一樣地工作。將這種類型分出來和上面幾種分類在標準上有所差異，上面三種更多指ETL實現 的方法，此類主要從數據處理角度。目前有一些產品屬於EAI（Enterprise Application Integration），它的數據集成主要是一種準實時性。所以這類產品就像Hub一樣，不斷接收各種異構數據源來的數據，經過處理，在實施發送到不同 的目標數據中去。
雖然，這些類看似各又千秋，特別在BI項目中，面對海量數據的ETL時，中間兩種的選擇就開始了，在選擇過程中，必須要考慮到開發效率、維護方面、性能、學習曲線、人員技能等各方面因素，當然還有最重要也是最現實的因素就是客戶的意象。
探求ETL本質之三（轉換）
ETL探求之一中提到，ETL過程最複雜的部分就是T，這個轉換過程，T過程究竟有哪些類型呢？
一、宏觀輸入輸出
從對數據源的整個宏觀處理分，看看一個ETL過程的輸入輸出，可以分成下面幾類：
1、大小交，這種處理在數據清洗過程是常見了，例如從數據源到ODS階段，如果數據倉庫採用維度建模，而且維度基本採用代理鍵的話，必然存在代碼到此鍵值 的轉換。如果用SQL實現，必然需要將一個大表和一堆小表都Join起來，當然如果使用ETL工具的話，一般都是先將小表讀入內存中再處理。這種情況，輸 出數據的粒度和大表一樣。
2、大大交，大表和大表之間關聯也是一個重要的課題，當然其中要有一個主表，在邏輯上，應當是主表Left Join輔表。大表之間的關聯存在最大的問題就是性能和穩定性，對於海量數據來說，必須有優化的方法來處理他們的關聯，另外，對於大數據的處理無疑會佔用 太多的系統資源，出錯的機率非常大，如何做到有效錯誤恢復也是個問題。對於這種情況，我們建議還是儘量將大表拆分成適度的稍小一點的表，形成大小交的類 型。這類情況的輸出數據粒度和主表一樣。
3、站着進來，躺着出去。事務系統中爲了提高系統靈活性和擴展性，很多信息放在代碼表中維護，所以它的“事實表”就是一種窄表，而在數據倉庫中，通常要進 行寬化，從行變成列，所以稱這種處理情況叫做“站着進來，躺着出去”。大家對Decode肯定不陌生，這是進行寬表化常見的手段之一。窄表變寬表的過程主 要體現在對窄表中那個代碼字段的操作。這種情況，窄表是輸入，寬表是輸出，寬表的粒度必定要比窄表粗一些，就粗在那個代碼字段上。
4、聚集。數據倉庫中重要的任務就是沉澱數據，聚集是必不可少的操作，它是粗化數據粒度的過程。聚集本身其實很簡單，就是類似SQL中Group by的操作，選取特定字段（維度），對度量字段再使用某種聚集函數。但是對於大數據量情況下，聚集算法的優化仍是探究的一個課題。例如是直接使用SQL的 Group by，還是先排序，在處理。
二、微觀規則
從數據的轉換的微觀細節分，可以分成下面的幾個基本類型，當然還有一些複雜的組合情況，例如先運算，在參照轉換的規則，這種基於基本類型組合的情況就不在此列了。ETL的規則是依賴目標數據的，目標數據有多少字段，就有多少條規則。
1、直接映射，原來是什麼就是什麼，原封不動照搬過來，對這樣的規則，如果數據源字段和目標字段長度或精度不符，需要特別注意看是否真的可以直接映射還是需要做一些簡單運算。
2、字段運算，數據源的一個或多個字段進行數學運算得到的目標字段，這種規則一般對數值型字段而言。
3、參照轉換，在轉換中通常要用數據源的一個或多個字段作爲Key，去一個關聯數組中去搜索特定值，而且應該只能得到唯一值。這個關聯數組使用Hash算法實現是比較合適也是最常見的，在整個ETL開始之前，它就裝入內存，對性能提高的幫助非常大。
4、字符串處理，從數據源某個字符串字段中經常可以獲取特定信息，例如身份證號。而且，經常會有數值型值以字符串形式體現。對字符串的操作通常有類型轉 換、字符串截取等。但是由於字符類型字段的隨意性也造成了髒數據的隱患，所以在處理這種規則的時候，一定要加上異常處理。
5、空值判斷，對於空值的處理是數據倉庫中一個常見問題，是將它作爲髒數據還是作爲特定一種維成員？這恐怕還要看應用的情況，也是需要進一步探求的。但是 無論怎樣，對於可能有NULL值的字段，不要採用“直接映射”的規則類型，必須對空值進行判斷，目前我們的建議是將它轉換成特定的值。
6、日期轉換，在數據倉庫中日期值一般都會有特定的，不同於日期類型值的表示方法，例如使用8位整型20040801表示日期。而在數據源中，這種字段基 本都是日期類型的，所以對於這樣的規則，需要一些共通函數來處理將日期轉換爲8位日期值、6位月份值等。
7、日期運算，基於日期，我們通常會計算日差、月差、時長等。一般數據庫提供的日期運算函數都是基於日期型的，而在數據倉庫中採用特定類型來表示日期的話，必須有一套自己的日期運算函數集。
8、聚集運算，對於事實表中的度量字段，他們通常是通過數據源一個或多個字段運用聚集函數得來的，這些聚集函數爲SQL標準中，包括sum,count,avg,min,max。
9、既定取值，這種規則和以上各種類型規則的差別就在於它不依賴於數據源字段，對目標字段取一個固定的或是依賴系統的值。
探求ETL本質之四（數據質量）
“不要絕對的數據準確，但要知道爲什麼不準確。”
這是我們在構建BI系統是對數據準確性的要求。確實，對絕對的數據準確誰也沒有把握，不僅是系統集成商，包括客戶也是無法確定。準確的東西需要一個標準， 但首先要保證這個標準是準確的，至少現在還沒有這樣一個標準。客戶會提出一個相對標準，例如將你的OLAP數據結果和報表結果對比。雖然這是一種不太公平 的比較，你也只好認了吧。
首先在數據源那裏，已經很難保證數據質量了，這一點也是事實。在這一層有哪些可能原因導致數據質量問題？可以分爲下面幾類：
1、數據格式錯誤，例如缺失數據、數據值超出範圍或是數據格式非法等。要知道對於同樣處理大數據量的數據源系統，他們通常會捨棄一些數據庫自身的檢查機 制，例如字段約束等。他們儘可能將數據檢查在入庫前保證，但是這一點是很難確保的。這類情況諸如身份證號碼、手機號、非日期類型的日期字段等。
2、數據一致性，同樣，數據源系統爲了性能的考慮，會在一定程度上舍棄外鍵約束，這通常會導致數據不一致。例如在帳務表中會出現一個用戶表中沒有的用戶ID，在例如有些代碼在代碼表中找不到等。
3、業務邏輯的合理性，這一點很難說對與錯。通常，數據源系統的設計並不是非常嚴謹，例如讓用戶開戶日期晚於用戶銷戶日期都是有可能發生的，一個用戶表中存在多個用戶ID也是有可能發生的。對這種情況，有什麼辦法嗎？
構建一個BI系統，要做到完全理解數據源系統根本就是不可能的。特別是數據源系統在交付後，有更多維護人員的即興發揮，那更是要花大量的時間去尋找原因。 以前曾經爭辯過設計人員對規則描述的問題，有人提出要在ETL開始之前務必將所有的規則弄得一清二楚。我並不同意這樣的意見，倒是認爲在ETL過程要有處 理這些質量有問題數據的保證。一定要正面這些髒數據，是丟棄還是處理，無法逃避。如果沒有質量保證，那麼在這個過程中，錯誤會逐漸放大，拋開數據源質量問 題，我們再來看看ETL過程中哪些因素對數據準確性產生重大影響。
1、規則描述錯誤。上面提到對設計人員對數據源系統理解的不充分，導致規則理解錯誤，這是一方面。另一方面，是規則的描述，如果無二義性地描述規則也是要 探求的一個課題。規則是依附於目標字段的，在探求之三中，提到規則的分類。但是規則總不能總是用文字描述，必須有嚴格的數學表達方式。我甚至想過，如果設 計人員能夠使用某種規則語言來描述，那麼我們的ETL單元就可以自動生成、同步，省去很多手工操作了。
2、ETL開發錯誤。即時規則很明確，ETL開發的過程中也會發生一些錯誤，例如邏輯錯誤、書寫錯誤等。例如對於一個分段值，開區間閉區間是需要指定的，但是常常開發人員沒注意，一個大於等於號寫成大於號就導致數據錯誤。
3、人爲處理錯誤。在整體ETL流程沒有完成之前，爲了圖省事，通常會手工運行ETL過程，這其中一個重大的問題就是你不會按照正常流程去運行了，而是按照自己的理解去運行，發生的錯誤可能是誤刪了數據、重複裝載數據等。
探求ETL本質之五（質量保證）
上回提到ETL數據質量問題，這是無法根治的，只能採取特定的手段去儘量避免，而且必須要定義出度量方法來衡量數據的質量是好還是壞。對於數據源的質量， 客戶對此應該更加關心，如果在這個源頭不能保證比較乾淨的數據，那麼後面的分析功能的可信度也都成問題。數據源系統也在不斷進化過程中，客戶的操作也在逐 漸規範中，BI系統也同樣如此。本文探討一下對數據源質量和ETL處理質量的應對方法。
如何應對數據源的質量問題？記得在onteldatastage列表中也討論過一個話題－"-1的處理"，在數據倉庫模型維表中，通常有一條-1記錄，表 示“未知”，這個未知含義可廣了，任何可能出錯的數據，NULL數據甚至是規則沒有涵蓋到的數據，都轉成-1。這是一種處理髒數據的方法，但這也是一種掩 蓋事實的方法。就好像寫一個函數FileOpen(filename)，返回一個錯誤碼，當然，你可以只返回一種錯誤碼，如-1，但這是一種不好的設計， 對於調用者來說，他需要依據這個錯誤碼進行某些判斷，例如是文件不存在，還是讀取權限不夠，都有相應的處理邏輯。數據倉庫中也是一樣，所以，建議將不同的 數據質量類型處理結果分別轉換成不同的值，譬如，在轉換後，-1表示參照不上，-2表示NULL數據等。不過這僅僅對付了上回提到的第一類錯誤，數據格式 錯誤。對於數據一致性和業務邏輯合理性問題，這仍有待探求。但這裏有一個原則就是“必須在數據倉庫中反應數據源的質量”。
對於ETL過程中產生的質量問題，必須有保障手段。從以往的經驗看，沒有保障手段給實施人員帶來麻煩重重。實施人員對於反覆裝載數據一定不會陌生，甚至是 最後數據留到最後的Cube，才發現了第一步ETL其實已經錯了。這個保障手段就是數據驗證機制，當然，它的目的是能夠在ETL過程中監控數據質量，產生 報警。這個模塊要將實施人員當作是最終用戶，可以說他們是數據驗證機制的直接收益者。
首先，必須有一個對質量的度量方法，什麼是高質什麼是低質，不能靠感官感覺，但這卻是在沒有度量方法條件下通常的做法。那經營分析系統來說，聯通總部曾提 出測試規範，這其實就是一種度量方法，例如指標的誤差範圍不能高於5%等，對系統本身來說其實必須要有這樣的度量方法，先不要說這個度量方法是否科學。對 於ETL數據處理質量，他的度量方法應該比聯通總部測試規範定義的方法更要嚴格，因爲他更多將BI系統看作一個黑盒子，從數據源到展現的數據誤差允許一定 的誤差。而ETL數據處理質量度量是一種白盒的度量，要注重每一步過程。因此理論上，要求輸入輸出的指標應該完全一致。但是我們必須正面完全一致只是理 想，對於有誤差的數據，必須找到原因。
在質量度量方法的前提下，就可以建立一個數據驗證框架。此框架依據總量、分量數據稽覈方法，該方法在高的《數據倉庫中的數據稽核技術》一文中已經指出。作爲補充，下面提出幾點功能上的建議：
1、提供前端。將開發實施人員當作用戶，同樣也要爲之提供友好的用戶界面。《稽核技術》一文中指出測試報告的形式，這種形式還是要依賴人爲判斷，在一堆數 據中去找規律。到不如用OLAP的方式提供界面，不光是加上測試統計出來的指標結果，並且配合度量方法的計算。例如誤差率，對於誤差率爲大於0的指標，就 要好好查一下原因了。
2、提供框架。數據驗證不是一次性工作，而是每次ETL過程中都必須做的。因此，必須有一個框架，自動化驗證過程，並提供擴展手段，讓實施人員能夠增加驗 證範圍。有了這樣一個框架，其實它起到規範化操作的作用，開發實施人員可以將主要精力放在驗證腳本的編寫上，而不必過多關注驗證如何融合到流程中，如何展 現等工作。爲此，要設計一套表，類似於DM表，每次驗證結果數據都記錄其中，並且自動觸發多維分析的數據裝載、發佈等。這樣，實施人員可以在每次裝載，甚 至在流程過程中就可以觀察數據的誤差率。特別是，如果數據倉庫的模型能夠統一起來，甚至數據驗證腳本都可以確定下來，剩下的就是規範流程了。
3、規範流程。上回提到有一種ETL數據質量問題是由於人工處理導致的，其中最主要原因還是流程不規範。開發實施人員運行單獨一個ETL單元是很方便的， 雖然以前曾建議一個ETL單元必須是“可重入”的，這能夠解決誤刪數據，重複裝載數據問題。但要記住數據驗證也是在流程當中，要讓數據驗證能夠日常運作， 就不要讓實施者感覺到他的存在。總的來說，規範流程是提高實施效率的關鍵工作，這也是以後要繼續探求的。
探求ETL本質之六（元數據漫談）
對於元數據（Metadata）的定義到目前爲止沒有什麼特別精彩的，這個概念非常廣，一般都是這樣定義，“元數據是描述數據的數據（Data about Data）”，這造成一種遞歸定義，就像問小強住在哪裏，答，在旺財隔壁。按照這樣的定義，元數據所描述的數據是什麼呢？還是元數據。這樣就可能有元元 元...元數據。我還聽說過一種對元數據，如果說數據是一抽屜檔案，那麼元數據就是分類標籤。那它和索引有什麼區別？
元數據體現是一種抽象，哲學家從古至今都在抽象這個世界，力圖找到世界的本質。抽象不是一層關係，它是一種逐步由具體到一般的過程。例如我->男人 ->人->哺乳動物->生物這就是一個抽象過程，你要是在軟件業混會發現這個例子很常見，面向對象方法就是這樣一種抽象過程。它對世界 中的事物、過程進行抽象，使用面向對象方法，構建一套對象模型。同樣在面向對象方法中，類是對象的抽象，接口又是對類的抽象。因此，我認爲可以將“元”和 “抽象”換一下，叫抽象數據是不是好理解一些。
常聽到這樣的話，“xx領導的講話高屋建瓴，給我們後面的工作指引的清晰的方向”，這個成語“高屋建瓴”，站在10樓往下到水，居高臨下，能砸死人，這是 指站在一定的高度看待事物，這個一定的高度就是指他有夠“元”。在設計模式中，強調要對接口編程，就是說你不要處理這類對象和那類對象的交互，而要處理這 個接口和那個接口的交互，先別管他們內部是怎麼幹的。
元數據存在的意義也在於此，雖然上面說了一通都撤到哲學上去，但這個詞必須還是要結合軟件設計中看，我不知道在別的領域是不是存在Metadata這樣的 叫法，雖然我相信別的領域必然有類似的東東。元數據的存在就是要做到在更高抽象一層設計軟件。這肯定有好處，什麼靈活性啊，擴展性啊，可維護性啊，都能得 到提高，而且架構清晰，只是彎彎太多，要是從下往上看，太複雜了。很早以前，我曾看過backorifice的代碼，我靠，一個簡單的功能，從這個類轉到 父類，又轉到父類，很不理解，爲什麼一個簡單的功能不在一個類的方法中實現就拉到了呢？現在想想，還真不能這樣，這雖然使代碼容易看懂了，但是結構確實混 亂的，那他只能幹現在的事，如果有什麼功能擴展，這些代碼就廢了。
我從98年剛工作時就開始接觸元數據的概念，當時叫做元數據驅動的系統架構，後來在QiDSS中也用到這個 概念構建QiNavigator，但是現在覺得元數據也沒啥，不就是建一堆表描述界面的元素，再利用這些數據自動生成界面嗎。到了數據倉庫系統中，這個概 念更強了，是數據倉庫中一個重要的部分。但是至今，我還是認爲這個概念過於玄乎，看不到實際的東西，市面上有一些元數據管理的東西，但是從應用情況就得 知，用的不多。之所以玄乎，就是因爲抽象層次沒有分清楚，關鍵就是對於元數據的分類（這種分類就是一種抽象過程）和元數據的使用。你可以將元數據抽象成0 和1，但是那樣對你的業務有用嗎？必須還得抽象到適合的程度，最後問題還是“度”。
數據倉庫系統的元數據作用如何？還不就是使系統自動運轉，易於管理嗎？要做到這一步，可沒必要將系統抽象到太極、兩儀、八卦之類的，業界也曾定義過一些元數據規範，向CWM、XMI等等，可以借鑑，不過俺對此也是不精通的說，以後再說。
===================================================
九大數據倉庫方案特點比較
IBM、Oracle、Sybase、CA、NCR、Informix、Microsoft、和SAS等有實力的公司相繼（通過收購或研發的途徑）推出了 自己的數據倉庫解決方案，BO和Brio等專業軟件公司也在前端在線分析處理工具市場上佔有一席之地。下面針對這些數據倉庫解決方案的性能和特點做分析和 比較。
IBM IBM公司提供了一套基於可視數據倉庫的商業智能（BI）解決方案，包括：Visual Warehouse（VW）、Essbase/DB2 OLAP Server 5.0、IBM DB2 UDB，以及來自第三方的前端數據展現工具（如BO）和數據挖掘工具（如SAS）。其中，VW是一個功能很強的集成環境，既可用於數據倉庫建模和元數據管 理，又可用於數據抽取、轉換、裝載和調度。Essbase/DB2 OLAP Server支持“維”的定義和數據裝載。Essbase/DB2 OLAP Server不是ROLAP（Relational OLAP）服務器，而是一個（ROLAP和MOLAP）混合的HOLAP服務器，在Essbase完成數據裝載後，數據存放在系統指定的DB2 UDB數據庫中。
嚴格說來，IBM自己並沒有提供完整的數據倉庫解決方案，該公司採取的是合作伙伴戰略。例如，它的前端數據展現工具可以是Business Objects的BO、Lotus的Approach、Cognos的Impromptu或IBM的Query Management Facility；多維分析工具支持Arbor Software的Essbase和IBM（與Arbor聯合開發）的DB2 OLAP服務器；統計分析工具採用SAS系統。
Oracle Oracle數據倉庫解決方案主要包括Oracle Express和Oracle Discoverer兩個部分。Oracle Express由四個工具組成：Oracle Express Server是一個MOLAP (多維OLAP)服務器，它利用多維模型，存儲和管理多維數據庫或多維高速緩存，同時也能夠訪問多種關係數據庫；Oracle Express Web Agent通過CGI或Web插件支持基於Web的動態多維數據展現；Oracle Express Objects前端數據分析工具（目前僅支持Windows平臺）提供了圖形化建模和假設分析功能，支持可視化開發和事件驅動編程技術，提供了兼容 Visual Basic語法的語言，支持OCX和OLE；Oracle Express Analyzer是通用的、面向最終用戶的報告和分析工具（目前僅支持Windows平臺）。Oracle Discoverer即席查詢工具是專門爲最終用戶設計的，分爲最終用戶版和管理員版。
在Oracle數據倉庫解決方案實施過程中，通常把彙總數據存儲在Express多維數據庫中，而將詳細數據存儲在Oracle關係數據庫中，當需要詳細 數據時，Express Server通過構造SQL語句訪問關係數據庫。但目前的Express還不夠靈活，數據倉庫設計的一個變化往往導致數據庫的重構。另外，目前的 Oracle 8i和Express 之間集成度還不夠高，Oracle 8i和Express之間需要複製元數據，如果Oracle Discoverer（或BO）需要訪問彙總數據，則需要將彙總數據同時存放在Oracle和Express中，系統維護比較困難。值得注意的是，剛剛問 世的Oracle 9i把OLAP和數據挖掘作爲重要特點。
Sybase Sybase提供的數據倉庫解決方案稱爲Warehouse Studio，包括數據倉庫的建模、數據抽取與轉換、數據存儲與管理、元數據管理以及可視化數據分析等工具。其中，Warehouse Architect是PowerDesigner中的一個設計模塊，它支持星形模型、雪花模型和ER模型；數據抽取與轉換工具包括PowerStage、 Replication Server、Carleton PASSPORT，PowerStage是Sybase提供的可視化數據遷移工具。
Adaptive Server Enterprise是Sybase企業級關係數據庫，Adaptive Server IQ是Sybase公司專爲數據倉庫設計的關係數據庫，它爲高性能決策支持系統和數據倉庫的建立作了優化處理，Sybase IQ支持各種流行的前端展現工具（如Cognos Impromptu、Business Objects、Brio Query等）；數據分析與展現工具包括PowerDimensions、EnglishWizard、InfoMaker、PowerDynamo 等，PowerDimensions是圖形化的OLAP分析工具，它支持SMP和多維緩存技術，能夠集成異構的關係型數據倉庫和分佈式數據集市，從而形成 單一的、新型的多維模式；數據倉庫的維護與管理工具包括Warehouse Control Center、Sybase Central、Distribution Director，其中Warehouse Control Center是爲數據倉庫開發人員提供的元數據管理工具。
Sybase提供了完整的數據倉庫解決方案Quick Start DataMart，具有良好的性能，並支持第三方數據展現工具。從Quick Start DataMart的名稱不難看出，它尤其適合於數據集市應用。另外，Sybase可以提供面向電信、金融、保險、醫療保健這4個行業的客戶關係管理 （CRM）產品，在這4個產品中，有80％的功能是共性的，有20％的功能需要Sybase與合作伙伴針對不同需求共同開發。
Informix Informix於1998和1999年相繼收購了國際上享有盛譽的數據倉庫供應商Red Brick System和數據管理軟件供應商Ardent，並提供了完整、集成的數據倉庫解決方案。該解決方案還包括一個“快速啓動”諮詢服務，能夠幫助用戶快速完 成數據倉庫或數據集市的開發。Informix產品能夠集成Microsoft IIS或Netscape Enterprise/FastTrack服務器，從而支持基於Web的數據倉庫應用。
Informix沒有提供自己的報表和數據挖掘工具，但他們與Brio和SAS公司建立了戰略聯盟，並推出了“Informix商務智能聯盟計劃”。該計 劃以Informix爲主，結合Brio的前端數據分析和報表功能，以及SAS的數據挖掘功能，形成了一個“BI中心”打包方案。
（今年4月Informix Software已被IBM公司收購，此舉將給IBM公司數據庫及數據倉庫產品，從技術和市場佔有率上帶來極大的提升。）
CA CA於1999年收購了Platinum Technology公司後，得到了完整的數據倉庫解決方案，包括：Erwin數據倉庫設計工具、InfoPump數據轉換與抽取工具、 InfoBeacon ROLAP服務器、Forest＆Trees前端數據展現工具、Provision系統監視與作業調度工具和DecisionBase元數據管理工具等。
與Informix解決方案相似，CA解決方案也提供了數據倉庫建模、元數據管理、數據抽取與轉換、基於關係數據庫的在線分析服務器、系統監視與作業調 度、前端數據展現等功能，同時還支持Web應用。不同之處是Informix提供了專門爲數據倉庫設計的高性能目標數據庫（Red Birck），而CA解決方案則提供ODBC接口，並將數據存儲在第三方關係數據庫(如Oracle、Sybase、SQL Server、Informix和IBM DB2等)中，其性能要打一些折扣，但開放性要好些。另外，CA的OLAP服務器目前只能與Microsoft的IIS Web服務器集成。
NCR Teradata NCR Teradata是高端數據倉庫市場最有力的競爭者，主要運行在NCR WorldMark SMP硬件的Unix操作系統平臺上。1998年，該公司也提供了基於Windows NT的Teradata，試圖開拓數據集市（Data Mart）市場。總的來看，NCR的產品性能很好，Teradata數據倉庫在100GB、300GB、1TB和3TB級的TPC D指標測試中均創世界紀錄。但是，NCR產品的價格相對較高，中小企業用戶難以接受。
Microsoft Microsoft將OLAP功能集成到Microsoft SQL Server 7.0中，提供可擴充的基於COM的OLAP接口。它通過一系列服務程序支持數據倉庫應用。數據傳輸服務DTS（Data Transformation Services）提供數據輸入/輸出和自動調度功能，在數據傳輸過程中可以完成數據的驗證、清洗和轉換等操作，通過與Microsoft Repository集成，共享有關的元數據；Microsoft Repository存儲包括元數據在內的所有中間數據；SQL Server OLAP Services支持在線分析處理；PivotTable Services提供客戶端OLAP數據訪問功能，通過這一服務，開發人員可以用VB或其他語言開發用戶前端數據展現程序，PivotTable Services還允許在本地客戶機上存儲數據；MMC（Microsoft Management Console）提供日程安排、存儲管理、性能監測、報警和通知的核心管理服務；Microsoft Office 2000套件中的Access和Excel可以作爲數據展現工具，另外SQL Server還支持第三方數據展現工具。
SAS SAS公司在20世紀70年代以“統計分析”和“線性數學模型”而享譽業界，90年代以後，SAS公司也加入了數據倉庫市場的競爭，並提供了特點鮮明的數 據倉庫解決方案，包括30多個專用模塊。其中，SAS/WA（Warehouse Administrator）是建立數據倉庫的集成管理工具，包括定義主題、數據轉換與彙總、更新彙總數據、元數據管理、數據集市的實現 等；SAS/MDDB是SAS用於在線分析的多維數據庫服務器；SAS/AF提供了屏幕設計功能和用於開發的SCL（屏幕控制語言）；SAS /ITSV（IT Service Vision）是IT服務的性能評估和管理的軟件，這些IT服務包括計算機系統、網絡系統、Web服務器和電話系統等。SAS系統的優點是功能強、性能 高、特長突出，缺點是系統比較複雜。
Business Objects Business Objects（BO）是集查詢、報表和OLAP技術爲一身的智能決策支持系統。它使用獨特的“語義層”技術和“動態微立方”技術來表示數據庫中的多維數 據，具有較好的查詢和報表功能，提供鑽取(Drill)等多維分析技術，支持多種數據庫，同時它還支持基於Web瀏覽器的查詢、報表和分析決策。雖然BO 在不斷增加新的功能，但從嚴格意義上說，BO只能算是一個前端工具。也許正因爲如此，幾乎所有的數據倉庫解決方案都把BO作爲可選的數據展現工具。
雖然國內有很多大學和研究機構從事數據倉庫技術的研究，但到目前爲止，國內基本上沒有成熟的數據倉庫解決方案。