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舉例來講。
 
    一、靜態的ETL單元和動態的ETL單元實例。 一次轉換指明瞭某種格式的數據如何格式化成另外一種格式的數據，對於數據源的物理形式在設計時能夠不用指定，它能夠在運行時，當這個ETL單元建立一個實例 時才指定。對於靜態和動態的ETL單元，Datastage沒有嚴格區分，它的一個Job就是實現這個功能，在早期版本，一個Job同時不能運行兩次，所 以一個Job至關於一個實例，在後期版本，它支持multiple instances，並且還不是默認選項。Powermart中將這兩個概念加以區分，靜態的叫作Mapping，動態運行時叫作Session。
 
    二、ETL元數據。元數據是描述數據的數據，他的含義很是普遍，這裏僅指ETL的元數據。主要包括每次轉換先後的數據結構和轉換的規則。ETL元數據還包括形式參數的管理，形式參數的ETL單元定義的參數，相對還有實參，它是運行時指定的參數，實參不在元數據管理範圍以內。

 

    三、 數據流程的控制。 要有可視化的流程編輯工具，提供流程定義和流程監控功能。流程調度的最小單位是ETL單元實例，ETL單元是不能在細分的ETL過程，固然這由開發者來控 制，例如能夠將抽取、轉換放在一個ETL單元中，那樣這個抽取和轉換隻能同時運行，而若是將他們分做兩個單元，能夠分別運行，這有利於錯誤恢復操做。當 然，ETL單元究竟應該細分到什麼程度應該依據具體應用來看，目前尚未找到很好的細分策略。好比，咱們能夠規定將裝載一個表的功能做爲一個ETL單元， 可是不能否認，這樣的ETL單元之間會有不少共同的操做，例如兩個單元共用一個Hash表，要將這個Hash表裝入內存兩次。

 

    四、 轉換規則的定義方法。提供函數集提供經常使用規則方法，提供規則定義語言描述規則。
 
    五、對數據的快速索引。通常都是利用Hash技術，將參照關係表提早裝入內存，在轉換時查找這個hash表。Datastage中有Hash文件技術，Powermart也有相似的Lookup功能。

 

 

探求ETL本質之二(分類) 

 

    昨在IT-Director上閱讀一篇報告，關於ETL產品分類的。通常來講，咱們眼中的ETL工具都是價格昂貴，可以處理海量數據的傢伙，可是這是其中的一種。它能夠分紅4種，針對不一樣的需求，主要是從轉換規則的複雜度和數據量大小來看。它們包括:

 

    一、 交互式運行環境。 你能夠指定數據源、目標數據，指定規則，立馬ETL。這種交互式的操做無疑很是方便，可是隻能適合小數據量和複雜度不高的ETL過程，由於一旦規則複雜 了，可能須要語言級的描述，不能簡簡單單拖拖拽拽就能夠的。還有數據量的問題，這種交互式必然創建在解釋型語言基礎上，另外他的靈活性必然要犧牲必定的性 能爲代價。因此若是要處理海量數據的話，每次讀取一條記錄，每次對規則進行解釋執行，每次在寫入一條記錄，這對性能影響是很是大的。

 

    二、 專門編碼型的。 它提供了一個基於某種語言的程序框架，你能夠沒必要將編程精力放在一些周邊的功能上，例如讀文件功能、寫數據庫的功能，而將精力主要放在規則的實現上面。這 種近似手工代碼的性能確定是沒話說，除非你的編程技巧不過關（這也是不可忽視的因素之一）。對於處理大數據量，處理複雜轉換邏輯，這種方式的ETL實現是 很是直觀的。

 

    三、 代碼生成器型的。 它就像是一個ETL代碼生成器，提供簡單的圖形化界面操做，讓你拖拖拽拽將轉換規則都設定好，其實他的後臺都是生成基於某種語言的程序，要運行這個ETL 過程，必需要編譯才行。Datastage就是相似這樣的產品，設計好的job必需要編譯，這避免了每次轉換的解釋執行，可是不知道它生成的中間語言是什 麼。之前我設計的ETL工具大挪移其實也是歸屬於這一類，它提供了界面讓用戶編寫規則，最後生成C++語言，編譯後便可運行。這類工具的特色就是要在界面 上下狠功夫，必須讓用戶輕鬆定義一個ETL過程，提供豐富的插件來完成讀、寫和轉換函數。大挪移在這方面就太弱了，規則必須手寫，並且要寫成標準c++語 法，這未免仍是有點難爲最終用戶了，還不如作成一個專業編碼型的產品呢。另一點，這類工具必須提供面向專家應用的功能，由於它不可能考慮到全部的轉換規 則和全部的讀寫，一方面提供插件接口來讓第三方編寫特定的插件，另外一方面還有提供特定語言來實現高級功能。例如Datastage提供一種類Basic的 語言，不過他的Job的腳本化實現好像就作的不太好，只能手工繪製job，而不能編程實現Job。

 

    四、最後還有一種類型叫作 數據集線器。顧名思義，他就是像Hub同樣地工做。將這種類型分出來和上面幾種分類在標準上有所差別，上面三種更多指ETL實現的方法，此類主要從數據處理角度。目前有一些產品屬於EAI（Enterprise Application Integration），它的數據集成主要是一種準實時性。因此這類產品就像Hub同樣，不斷接收各類異構數據源來的數據，通過處理，在實施發送到不一樣的目標數據中去。
雖然，這些類看似各又千秋，特別在BI項目中，面對海量數據的ETL時，中間兩種的選擇就開始了，在選擇過程當中，必需要考慮到開發效率、維護方面、性能、學習曲線、人員技能等各方面因素，固然還有最重要也是最現實的因素就是客戶的意象。

 

 

探求ETL本質之三(轉換) 

 

    ETL探求之一中提到，ETL過程最複雜的部分就是T，這個轉換過程，T過程究竟有哪些類型呢？

 

    1、宏觀輸入輸出

 

    從對數據源的整個宏觀處理分，看看一個ETL過程的輸入輸出，能夠分紅下面幾類：

 

    一、大小交。 這種處理在數據清洗過程是常見了，例如從數據源到ODS階段，若是數據倉庫採用維度建模，並且維度基本採用代理鍵的話，必然存在代碼到此鍵值的轉換。若是 用SQL實現，必然須要將一個大表和一堆小表都Join起來，固然若是使用ETL工具的話，通常都是先將小表讀入內存中再處理。這種狀況，輸出數據的粒度 和大表同樣。

 

    二、 大大交。 大表和大表之間關聯也是一個重要的課題，固然其中要有一個主表，在邏輯上，應當是主表Left Join輔表。大表之間的關聯存在最大的問題就是性能和穩定性，對於海量數據來講，必須有優化的方法來處理他們的關聯，另外，對於大數據的處理無疑會佔用 太多的系統資源，出錯的概率很是大，如何作到有效錯誤恢復也是個問題。對於這種狀況，咱們建議仍是儘可能將大表拆分紅適度的稍小一點的表，造成大小交的類 型。這類狀況的輸出數據粒度和主表同樣。

 

    三、 站着進來，躺着出去。 事務系統中爲了提升系統靈活性和擴展性，不少信息放在代碼表中維護，因此它的"事實表"就是一種窄表，而在數據倉庫中，一般要進行寬化，從行變成列，因此 稱這種處理狀況叫作"站着進來，躺着出去"。你們對Decode確定不陌生，這是進行寬表化常見的手段之一。窄表變寬表的過程主要體如今對窄表中那個代碼 字段的操做。這種狀況，窄表是輸入，寬表是輸出，寬表的粒度一定要比窄表粗一些，就粗在那個代碼字段上。

 

    四、 彙集。 數據倉庫中重要的任務就是沉澱數據，彙集是必不可少的操做，它是粗化數據粒度的過程。彙集自己其實很簡單，就是相似SQL中Group by的操做，選取特定字段（維度），對度量字段再使用某種彙集函數。可是對於大數據量狀況下，彙集算法的優化還是探究的一個課題。例如是直接使用SQL的 Group by，仍是先排序，在處理。

 

     2、微觀規則 

 

    從數據的轉換的微觀細節分，能夠分紅下面的幾個基本類型，固然還有一些複雜的組合狀況，例如先運算，在參照轉換的規則，這種基於基本類型組合的狀況就不在此列了。ETL的規則是依賴目標數據的，目標數據有多少字段，就有多少條規則。

 

    一、 直接映射。原來是什麼就是什麼，原封不動照搬過來，對這樣的規則，若是數據源字段和目標字段長度或精度不符，須要特別注意看是否真的能夠直接映射仍是須要作一些簡單運算。

 

    二、 字段運算。數據源的一個或多個字段進行數學運算獲得的目標字段，這種規則通常對數值型字段而言。

 

    三、 參照轉換。在轉換中一般要用數據源的一個或多個字段做爲Key，去一個關聯數組中去搜索特定值，並且應該只能獲得惟一值。這個關聯數組使用Hash算法實現是比較合適也是最多見的，在整個ETL開始以前，它就裝入內存，對性能提升的幫助很是大。

 

    四、 字符串處理。從數據源某個字符串字段中常常能夠獲取特定信息，例如身份證號。並且，常常會有數值型值以字符串形式體現。對字符串的操做一般有類型轉換、字符串截取等。可是因爲字符類型字段的隨意性也形成了髒數據的隱患，因此在處理這種規則的時候，必定要加上異常處理。

 

    五、 空值判斷。 對於空值的處理是數據倉庫中一個常見問題，是將它做爲髒數據仍是做爲特定一種維成員？這恐怕還要看應用的狀況，也是須要進一步探求的。可是不管怎樣，對於 可能有NULL值的字段，不要採用「直接映射」的規則類型，必須對空值進行判斷，目前咱們的建議是將它轉換成特定的值。

 

    六、 日期轉換。在數據倉庫中日期值通常都會有特定的，不一樣於日期類型值的表示方法，例如使用8位整型20040801表示日期。而在數據源中，這種字段基本都是日期類型的，因此對於這樣的規則，須要一些共通函數來處理將日期轉換爲8位日期值、6位月份值等。

 

    七、 日期運算。基於日期，咱們一般會計算日差、月差、時長等。通常數據庫提供的日期運算函數都是基於日期型的，而在數據倉庫中採用特定類型來表示日期的話，必須有一套本身的日期運算函數集。

 

    八、 彙集運算。對於事實表中的度量字段，他們一般是經過數據源一個或多個字段運用匯集函數得來的，這些彙集函數爲SQL標準中，包括sum,count,avg,min,max。

 

    九、 既定取值。這種規則和以上各類類型規則的差異就在於它不依賴於數據源字段，對目標字段取一個固定的或是依賴系統的值。

 

 

探求ETL本質之四(數據質量) 

 

    「不要絕對的數據準確，但要知道爲何不許確。」

 

    這 是咱們在構建BI系統是對數據準確性的要求。確實，對絕對的數據準確誰也沒有把握，不只是系統集成商，包括客戶也是沒法肯定。準確的東西須要一個標準，但 首先要保證這個標準是準確的，至少如今尚未這樣一個標準。客戶會提出一個相對標準，例如將你的OLAP數據結果和報表結果對比。雖然這是一種不太公平的 比較，你也只好認了吧。
 

    首先在數據源那裏，已經很難保證數據質量了，這一點也是事實。在這一層有哪些可能緣由致使數據質量問題？能夠分爲下面幾類：

 

    一、數據格式錯誤。 例如缺失數據、數據值超出範圍或是數據格式非法等。要知道對於一樣處理大數據量的數據源系統，他們一般會捨棄一些數據庫自身的檢查機制，例如字段約束等。 他們儘量將數據檢查在入庫前保證，可是這一點是很難確保的。這類狀況諸如身份證號碼、手機號、非日期類型的日期字段等。

 

    二、 數據一致性。一樣，數據源系統爲了性能的考慮，會在必定程度上舍棄外鍵約束，這一般會致使數據不一致。例如在賬務表中會出現一個用戶表中沒有的用戶ID，在例若有些代碼在代碼表中找不到等。

 

    三、 業務邏輯的合理性。這一點很難說對與錯。一般，數據源系統的設計並非很是嚴謹，例如讓用戶開戶日期晚於用戶銷戶日期都是有可能發生的，一個用戶表中存在多個用戶ID也是有可能發生的。對這種狀況，有什麼辦法嗎？

    構 建一個BI系統，要作到徹底理解數據源系統根本就是不可能的。特別是數據源系統在交付後，有更多維護人員的即興發揮，那更是要花大量的時間去尋找緣由。以 前曾經爭辯過設計人員對規則描述的問題，有人提出要在ETL開始以前務必將全部的規則弄得一清二楚。我並不一樣意這樣的意見，卻是認爲在ETL過程要有處理 這些質量有問題數據的保證。必定要正面這些髒數據，是丟棄仍是處理，沒法逃避。若是沒有質量保證，那麼在這個過程當中，錯誤會逐漸放大，拋開數據源質量問 題，咱們再來看看ETL過程當中哪些因素對數據準確性產生重大影響。

 

    一、 規則描述錯誤。 上面提到對設計人員對數據源系統理解的不充分，致使規則理解錯誤，這是一方面。另外一方面，是規則的描述，若是無二義性地描述規則也是要探求的一個課題。規 則是依附於目標字段的，在探求之三中，提到規則的分類。可是規則總不能老是用文字描述，必須有嚴格的數學表達方式。我甚至想過，若是設計人員可以使用某種 規則語言來描述，那麼咱們的ETL單元就能夠自動生成、同步，省去不少手工操做了。

 

    二、 ETL開發錯誤。即時規則很明確，ETL開發的過程當中也會發生一些錯誤，例如邏輯錯誤、書寫錯誤等。例如對於一個分段值，開區間閉區間是須要指定的，可是經常開發人員沒注意，一個大於等於號寫成大於號就致使數據錯誤。

 

    三、 人爲處理錯誤。在總體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數據處理質量度量是一種白盒的度量，要注重每一步過程。所以理論上，要求輸入輸出的指標應該徹底一致。可是咱們必須正面徹底一致只是理想， 對於有偏差的數據，必須找到緣由。

 

    在質量度量方法的前提下，就能夠創建一個數據驗證框架。此框架依據總量、份量數據稽覈方法，該方法在高的《數據倉庫中的數據稽覈技術》一文中已經指出。做爲補充，下面提出幾點功能上的建議：

 

    一、 提供前端。 將開發實施人員看成用戶，一樣也要爲之提供友好的用戶界面。《稽覈技術》一文中指出測試報告的形式，這種形式仍是要依賴人爲判斷，在一堆數據中去找規律。 到不如用OLAP的方式提供界面，不光是加上測試統計出來的指標結果，而且配合度量方法的計算。例如偏差率，對於偏差率爲大於0的指標，就要好好查一下原 因了。

 

    二、 提供框架。 數據驗證不是一次性工做，而是每次ETL過程當中都必須作的。所以，必須有一個框架，自動化驗證過程，並提供擴展手段，讓實施人員可以增長驗證範圍。有了這 樣一個框架，其實它起到規範化操做的做用，開發實施人員能夠將主要精力放在驗證腳本的編寫上，而沒必要過多關注驗證如何融合到流程中，如何展示等工做。爲 此，要設計一套表，相似於DM表，每次驗證結果數據都記錄其中，而且自動觸發多維分析的數據裝載、發佈等。這樣，實施人員能夠在每次裝載，甚至在流程過程 中就能夠觀察數據的偏差率。特別是，若是數據倉庫的模型可以統一塊兒來，甚至數據驗證腳本均可以肯定下來，剩下的就是規範流程了。

 

    三、 規範流程。 上回提到有一種ETL數據質量問題是因爲人工處理致使的，其中最主要緣由仍是流程不規範。開發實施人員運行單獨一個ETL單元是很方便的，雖然之前曾建議 一個ETL單元必須是"可重入"的，這可以解決誤刪數據，重複裝載數據問題。但要記住數據驗證也是在流程當中，要讓數據驗證可以平常運做，就不要讓實施者 感受到他的存在。總的來講，規範流程是提升實施效率的關鍵工做，這也是之後要繼續探求的。

 

 

探求ETL本質之六(元數據漫談) 

 

    對於元數據(Metadata)的定義到目前爲止沒有什麼特別精彩的，這個概念很是廣，通常都是這樣定義，「元數據是描述數據的數據(Data about Data)」，這形成一種遞歸定義，就像問小強住在哪裏，答，在旺財隔壁。按照這樣的定義，元數據所描述的數據是什麼呢？仍是元數據。這樣就可能有元元元...元數據。我還據說過一種對元數據，若是說數據是一抽屜檔案，那麼元數據就是分類標籤。那它和索引有什麼區別？

    元 數據體現是一種抽象，哲學家從古至今都在抽象這個世界，力圖找到世界的本質。抽象不是一層關係，它是一種逐步由具體到通常的過程。例如我->男人 ->人->哺乳動物->生物這就是一個抽象過程，你要是在軟件業混會發現這個例子很常見，面向對象方法就是這樣一種抽象過程。它對世界 中的事物、過程進行抽象，使用面向對象方法，構建一套對象模型。一樣在面向對象方法中，類是對象的抽象，接口又是對類的抽象。所以，我認爲能夠將「元」和 「抽象」換一下，叫抽象數據是否是好理解一些。

 

    常 聽到這樣的話，「xx領導的講話高屋建瓴，給咱們後面的工做指引的清晰的方向」，這個成語「高屋建瓴」，站在10樓往下倒水，居高臨下，能砸死人，這是指 站在必定的高度看待事物，這個必定的高度就是指他有夠「元」。在設計模式中，強調要對接口編程，就是說你不要處理這類對象和那類對象的交互，而要處理這個 接口和那個接口的交互，先別管他們內部是怎麼幹的。

 

    元 數據存在的意義也在於此，雖然上面說了一通都扯到哲學上去，但這個詞必須仍是要結合軟件設計中看，我不知道在別的領域是否是存在Metadata這樣的叫 法，雖然我相信別的領域必然有相似的東東。元數據的存在就是要作到在更高抽象一層設計軟件。這確定有好處，什麼靈活性啊，擴展性啊，可維護性啊，都能獲得 提升，並且架構清晰，只是彎彎太多，要是從下往上看，太複雜了。很早之前，我曾看過backorifice的代碼，我靠，一個簡單的功能，從這個類轉到父 類，又轉到父類，很不理解，爲何一個簡單的功能不在一個類的方法中實現就拉到了呢？如今想一想，還真不能這樣，這雖然使代碼容易看懂了，可是結構確是混亂 的，那他只能幹如今的事，若是有什麼功能擴展，這些代碼就廢了。

 

    我 從98年剛工做時就開始接觸元數據的概念，當時叫作元數據驅動的系統架構，後來在QiDSS中也用到這個概念構建QiNavigator，可是如今以爲元 數據也沒啥，不就是建一堆表描述界面的元素，再利用這些數據自動生成界面嗎。到了數據倉庫系統中，這個概念更強了，是數據倉庫中一個重要的部分。可是至 今，我仍是認爲這個概念過於玄乎，看不到實際的東西，市面上有一些元數據管理的東西，可是從應用狀況就得知，用的很少。之因此玄乎，就是由於抽象層次沒有 分清楚，關鍵就是對於元數據的分類（這種分類就是一種抽象過程）和元數據的使用。你能夠將元數據抽象成0和1，可是那樣對你的業務有用嗎？必須還得抽象到 適合的程度，最後問題仍是「度」。

 

    數據倉庫系統的元數據做用如何？還不就是使系統自動運轉，易於管理嗎？要作到這一步，可不必將系統抽象到太極、兩儀、八卦之類的，業界也曾定義過一些元數據規範，向CWM、XMI等等，能夠借鑑，不過俺對此也是不精通的說，之後再說。