研究論文

數據倉庫構建之行為模式分析

蔣彬 余肖生 王東娟 姜艷靜 趙美林

（三峽大學計算機與信息學院，湖北 宜昌443002）

摘要 數據倉庫ETL程序的構建與維護在數據倉庫的建設與使用中占有舉足輕重的地位。傳統上的ETL之構建方法分為水平式和垂直式。實踐證明，這兩種傳統方式都沒能有效地解決ETL構建過程中生產效率、軟件質量、文檔質量等方面的問題。通過數據倉庫構建的行為模式分析，發現數據倉庫構建中可以區分出域通用知識和特殊對象知識。其中，域通用知識是可以重復使用的，在數據倉庫構建過程中只需處理一次。據此，ETL程序的生產效率、軟件質量、文檔質量等可以得到實質性提高。

關鍵詞 數據倉庫構建，ETL，行為模式

中圖分類號 TP311

1 引言

數據倉庫ETL（提取、轉換、加載）機制是一組從源數據集提取數據的程序，它將這些數據轉換并加載到數據倉庫的目標表中，以用于隨后的分析。對滿足數據倉庫的三個主要功能而言，即數據的整合、積累及準備，它是數據倉庫的關鍵器官。此外，對于數據倉庫之運行，其重要性可與我們的心血管系統相比。設計、開發、測試、維護及擴展ETL是數據倉庫構建的主要挑戰，這一點在當今快速變化的世界中尤為突出。在這個意義上我們可以說，如能有效地構建ETL機制，原則上我們也就同時解決了數據倉庫構建的問題。換言之，此二挑戰本質上是同一的。

在過去的30年里，人們嘗試過幾乎所有能夠想得到的辦法，這包括不同的方法、體系結構、模型、工具等。然而，效果仍不盡如人意：費用昂貴，構建運作耗時，政治上高風險。對于為改善績效而采用數據倉庫技術的企業組織來說，該情形還有一個心理抑制的效應。他們不能也不愿意想得足夠遠大，因為他們所知道的和所經歷的使他們認為，他們怎么也無法有效地做得那么大。

然而，作為一個程序集，ETL機制通常可以用兩種方式來給予觀察：

（1）水平方式。程序集中每個程序都只負責單個目標表的相應提取、轉換和加載。

（2）垂直方式。整個程序集包括三個子集。第一個負責所有表的提取；第二個負責所有表的轉換；第三個負責所有表的加載。

換言之，對所有目標表而言，所需構建的是非常相似但又不完全相同的程序。這是ETL機制的特點，也是數據倉庫構建的特別之處。

本文首先分析現有的、一般的機制構建方法，指出其對數據倉庫構建的不足。接著再分析、觀察實驗室環境下數據倉庫構建之行為模式，由此引入域通用知識和特殊對象知識的概念。以此為據，再對現實生活中數據倉庫構建之行為模式進行分析。這些觀察、分析及概念將為后面新構建方法的引入打下基礎。

2 阿基米德及亨利·福特的ETL機制構建方法

我們先看看古代最偉大的工程師阿基米德（約前287年—前212年）及汽車工程師的先驅和裝配線生產技術的發起者亨利·福特（1863—1947年）將如何構建對付1000個目標表的ETL機制。假設，該任務必須在極短的時間內完成，譬如在一天之內。另外，可調用的程序開發人員數量不限。

2.1 阿基米德的構建方法

在錫拉丘茲的圍攻戰中（約前214—前212年），阿基米德曾試用“阿基米德熱射”進行火攻以摧毀敵艦，即用數百個高度拋光的青銅或黃銅盾牌作為反射鏡，將陽光聚焦到駛近的敵船，使其著火，如圖1所示[1]。

依此原理，阿基米德有可能把對應每個目標表的ETL程序看作一副盾牌鏡。由此將程序開發人員劃分為小型的開發小組。根據提取、轉換、加載等功能要求，每一小組將對一小數量的目標表的ETL程序進行全功能開發。

2.2 亨利·福特的構建方法

如圖2所示[2]，福特可能會采取汽車生產裝配線的方法。他可能會將整個構建ETL的任務分成更小的子任務，如提取、轉換和加載，把它們看作工作步驟類型，并把每一步驟類型分配給一專門的、獨立的開發團隊。換句話說，每個開發團隊將只處理整個工作步驟鏈中的一個固定的小部分，對所有的目標表的處理均如此。

2.3 兩種構建方法對比及討論

總之，阿基米德會水平地劃分任務，而福特卻是垂直劃分。每個阿基米德的程序開發員都能在整體上了解自己的ETL程序，由此他們在此都是全能手。而且，他們會以其工作為樂，因為產生的程序并不要求完全相同，而且簡明的設計任務書允許得到單獨的、創造性的、因而不同的、富有個性的詮釋。然而，程序的生產會因此變得昂貴、費時、低效。因為程序的差別相當大，團隊之間的成員也不便交換[3]。

由于同一團隊生產的所有程序都幾乎相同，福特的開發人員對于既定的小任務都是訓練有素的專家。因此，他們能高效地生產高質量的產品。然而，他們不會真正地關注全局。因此，他們的工作會顯得單調無聊。

當然，現實生活中的數據倉庫ETL機制并不像我們上述的那么簡單。我們已經確認了二十多個ETL機制的功能任務類型。其中有些相當復雜，具有挑戰性。此外，其適用性與數據源的狀況及企業組織對其數據倉庫的具體要求密切相關。后者本身往往也會很復雜和具有挑戰性。此外，某些任務類型可能還會有多種變體。

在過去的30年里，我們通常都是用阿基米德法來構建數據倉庫的。由于有詮釋的自由，這工作給我們帶來許多樂趣。然而，這樂趣常常變成了瑪麗·雪萊（Mary Shelley）之噩夢[4]。換言之，對我們而言，阿基米德法已被證明是不當的。福特沒有給予其員工任何詮釋的自由。他的方法基于一簡單的觀察，即分配給每個團隊的工作可以絕對相同地完成。然而，ETL程序雖然非常的相似，但它們還是不完全相同，即對我們而言，亨利·福特的方法也不合適。存在一個有效適用的方法嗎？下面，我們將分析構建ETL機制時會出現的問題，借以給此問題一個明確的答復。

3 實驗室環境下數據倉庫構建之行為模式分析[5]

為找到高效的數據倉庫構建方法，下面，我們首先對ETL機制構建中的典型編程過程進行分析。為了便于對討論的理解，我們要考慮每位數據倉庫構建者幾乎每天都會面對的基本任務，即為接收新提取的源數據做準備。盡管這項任務本身微不足道，但它卻包含了所有下面將給予詳盡考察的基本概念元素。

假設我們的數據庫“my_db”含1000個表，如“tab_adfhkfha”、“tab_lkeas”、…、“tab_dajpgh”。我們想清空這些表。我們知道，符合SQL（結構化查詢語言）語法“DELETE FROM <數據庫名>.<表名>; ”的語句適合于這一任務。我們如何完成這一任務呢？一種可能是寫下下面這1000個非常相似，但又不盡相同的語句，然后執行它們：

        DELETE FROM my_db.tab_adfhkfha；
        DELETE FROM my_db.tab_lkeasr；
        ...
        DELETE FROM my_db.tab_dajpgh；

為此，你可能會復制用于刪除第一個表的語句，再將其粘貼999次。然后，一個個調整這每一粘貼語句的某些部分，如表名。當然，調整之后你還須驗證這些調整是否正確。現在的問題是，你需要多少時間才能完成這些表的清空呢？如果你不太走運，它將使你度過好幾個乏味的時辰。

讓我們來仔細看看上面的過程。在這里，最突出的應是重復。這里有兩種類型的重復。

（1）內容重復。如上述完整的SQL語句中的短語“DELETE FROM my_db”。

（2）操作重復。即為產生后續的999個刪除（DELETE）語句的編輯操作：“復制（第1個語句）—粘貼（999次）—搜索（表名999次）—替換（用新的表名替換舊的表名999次）—調整（如有必要的話，999次）—驗證（驗證結果語句是否正確999次）”。

3.1 內容重復

為什么會有第一種類型的重復呢？這是因為對于以上所有刪除語句而言，上述的SQL-語法要求是通用的。由于SQL-語法，或由于編程風格的約定，它必須看起來是這個樣子，比如，所有SQL保留字必須大寫。對于相關的開發團隊而言，其他任何形式的語句可能不合適，或很難看。我們將這樣重復的內容看做“域通用知識”（domain-generic knowledge）的載體。這里所謂的“域”是指一個予已考慮的、有限的活動區域。

與此相應的問題是，哪些內容不重復呢？在清空的例子里，表名是完全不重復的。每個語句含有其唯一的、特殊的表名。我們稱這樣的事物為“對象特殊知識”（obj ect-specific knowledge）的載體。在我們的例子中，一個表就是一個對象。

基于以上概念，對于內容重復可簡言為：域通用知識的載體重復，而“對象特殊知識”的載體則不重復。

事實上，福特的流水線法是基于這樣的觀察：許多汽車組件是完全相同的——用我們的術語來說，它們是某種通用知識的載體，從而可以簡單地“復制和粘貼”，即重復相同的生產或制造。通過他的流水線法，福特使汽車構建達到了革命性的高效率。另外，他不能恰當處理對象特殊知識。而這正是ETL機制的特點。因此，他的方法還不能直接移植到我們的數據倉庫構建上來。

3.2 操作重復

第二類重復見于用得極多的編輯操作鏈，或最常見的現代行為模式：“復制—粘貼—搜索—取代—調整—驗證”。

對于提高生產率而言，使用計算機編輯工具對所有相關事物進行“復制 &粘貼”可能是自幾千年前發明印刷術以來最為偉大和最具影響力的發明之一。基于數據倉庫的特點，我們這些數據倉庫構建者充分地利用它來快速地生產ETL程序。（若沒能意識到這一點，那我們可能還沒開始就已經失敗了）另一方面，將被開發的ETL程序通常雖極其相似，但并非完全相同。因此，我們必須“查找”——同“替換”一道組成另一偉大且極具影響力的發明——應該含有其他內容的地方。然后用新的內容自動地“替換”那些舊的內容。如果所涉及的程序并非十分相似，那么通常有必要在一定的程度上手工“調整（修改/改變/優化/等）”新程序。無論如何，“驗證”結果的正確性是不可或缺的。

為什么需要“復制 &粘貼”呢？這是因為基于其顯著的相似性，舊的和新的程序應該有一個相當的部分可以共享。換句話說，應存在相當分量雙方共有的部分。如果共有的部分分量不夠，則沒必要采用“復制 &粘貼”。為什么能自動“搜索 &替換”呢？這是因為我們準確地知道什么能夠區分它們。換言之，我們知道這些單個程序有一些有規律的、特殊的東西。為什么必須手工“調整”生成的程序呢？這是因為存在其他的、特殊的、不是那么容易簡單地通過“搜索 &替換”予以處理的東西。如果我們不能感知或確定兩個程序之間存在明顯的、可利用的相似性，無論是“復制 &粘貼”，還是“搜索 &替換”，都將不便于用來構建新程序。在這種情形下，長操作鏈退化成一個短鏈，即“調整 &驗證”。換言之，我們將會像福特一百多年前所做的那樣，用古典的打字機，或像阿基米德兩千多年前那樣，用羽毛筆構建我們的ETL程序。為什么需要單個地“驗證”這些程序呢？這是因為“搜索 &替換”可能做一些超越期望的事。此外，任何手工操作都可能出錯。我們估計，亨利·福特和他的設計團隊在設計他們的生產線之前也對其員工的生產行為進行了類似的分析。

這里有一些關系需要說一下：

（1）因為存在著一些明顯的、可利用的相似性或共性，內容重復引發操作重復。

（2）由于不完全相同的或特殊的成分的存在，操作重復中的所有四個后續操作是由其前兩個操作，即“復制 &粘貼”，所引發的。

簡言之，存在一些有相當分量的共有成分對這種處理行為模式是有決定性意義的。而ETL程序中確確實實存在許多這種成分。

3.3 更論操作

操作對“復制 &粘貼”威力無比。只要其應用范圍選擇恰當，“粘貼”則是最悍猛的操作。福特非常漂亮地利用了它來構建汽車，最終導致工業革命。另一方面，實際中一些具體要求限制了其總體效果。首先是其副本不可隨后單獨更改。如果做不到這點，一個方便便宜的工業化生產問題將變成一個煩瑣昂貴的工匠生產問題。這也就是為什么只有在交付給用戶的相機或筆記本電腦沒被客戶打開或自行修改的前提下，供應商才提供保修的原因。另一問題是，原件或設計必須是完美無瑕的。如果它包含任何錯誤、缺陷，或諸如此類，超猛的“粘貼”將無情地散發它們。被“復制”的部分“粘貼”得越頻繁，上述紕漏則散發得越廣泛。由于“原型”/“設計”上的一些缺陷，我們時常見到要召回某型號的被“粘貼”的汽車的告示。當一些分散了的缺陷由客戶自己單獨更改或以無控的方式得以“糾正”時，災難也就發生了。

如果一個復制品的共同的部分（即某通用知識的載體）通過所謂的“調整”被單獨地改變了，那它就不再是原件的副本了。它成了，或者至少似乎是，一些新的特殊知識的載體。“調整”運用得越頻繁，存在于你的ETL程序集的（新的）特殊知識就越多；存在于你的ETL程序集中的特殊知識越多，你的ETL程序集也就越像一個工藝品的集合。通常，工藝品是昂貴的，并且處理它們是煩瑣的。在這個意義上我們說，“調整”是有害的。雖然在一切都剛開始時你的ETL程序集可通過“復制 &粘貼”（像福特生產他的汽車那樣）及“搜索 &替換”（這是福特做不到的，因為他沒有相應的操作對）等方式進行工業化生產。但最終由于“調整”，你不再能夠區分什么是通用的，什么是特殊的，因為一切都混在了一起。白天，它是一套精美的工藝品，但晚上它可能是瑪麗·雪萊噩夢的主題。

4 現實生活中數據倉庫構建之行為模式分析[6][7]

為了對本質性的東西有清晰深刻的理解，上面，我們在一個分離的、極其簡化了的條件下，對ETL機制構建中的典型編程過程進行了詳盡的分析。下面，我們將用由此獲得的基本認識來考察現實生活中數據倉庫構建之行為。

如果我們只用操心于少量的、單個的、手工制造的ETL程序的話，如同對待通常的應用程序那樣，我們的生活應是相當高枕無憂的。然而，在任一中等規模的企業組織里，其企業數據倉庫就可能有幾十個源應用系統，且每個源應用系統可能提供幾十上百個源表。因此，整個ETL機制可能含有數以千計的ETL程序，且其中某些部分還可能相當復雜。這是ETL機制的另一個主要特征，即量性特征。與上面談到的質性特征一樣，我們可以說，企業數據倉庫的ETL機制通常是由大量的、極其相似，但又不完全相同的程序所組成。

存在于這些程序中的大量的相似性可以用來提高構建效率。與此同時，這大量的程序使得數據倉庫建設成為真正的挑戰。這是因為除了煩瑣的編程外，所有這些程序都必須經歷設計、指定、測試、記錄以及維護的過程。這龐大的工作量不可能由一個人在短期內完成。相反，這通常需要大型的設計及開發團隊在一段很長的時間里完成。

4.1 大型的開發團隊

動用大批的開發人員將給數據倉庫構建帶來挑戰。這些開發人員每個人都有自己的把握和理解力，習慣于不同的思維和工作方式，他們掌握開發工具和輔助設備的水平不同并且駕馭數據庫管理系統、SQL的程度也不一樣。因此，雖然是根據相同或相似的設計說明書加以開發，但是，開發人員甲開發的程序并非總能被開發人員乙直接理解和維護，即使該程序運行正常。簡言之，這些程序里包含有太多個性的東西。換言之，設計說明書中隱含的通用知識可以由不同的開發人員通過編程以不同的方式，但又完全正確地給予詮釋。在這種情況下，實際存在的通用性難以識別，會被認作為某種特異性，我們稱之為偽特異性。更具體地說，某通用知識的載體，譬如由某一開發人員開發的某程序的一部分，對其他開發人員而言顯得像是某些特殊知識的載體。由此，這些開發人員也只能這樣特殊地處理這些載體了。

4.2 很長的開發時間段

長時期開發意味著，即使程序是由相同的開發人員但在不同的時間點開發的，該開發人員應用的布局、隱含的風格、采用的技巧以及融入的個人習慣都可能會發生變化，哪怕這變化來得緩慢。某一開發人員難于理解他兩年前開發的程序的現象很常見。由于時間在記憶上的作用，常常發生標準、協議或指南被遺忘或被誤解的現象。如哲學家們早在幾千年前就已經注意到的，今天的開發人員和兩年前的他已是大不一樣了。同理，對于相同的設計說明書，他今天的“詮釋”也和他兩年前的詮釋不太一樣了。在這個意義上，假設我們的一個團隊事實上有10個開發人員，他們在兩年的年初和年尾面對同樣的設計說明書。那么我們在實際效果上將會有20～30個不同的、提交詮釋的開發人員。這是一個應該值得注意的維的值的轉換：從一時間維的值，轉換到一物質維（即人員）的值。

事實上，時間因素的影響不僅如此。隨著時間的流逝

（1）業務要求和技術環境在變化；

（2）利益相關者（贊助者、管理人員、架構師、設計師、開發人員、測試人員等）在流動；

（3）老的數據源被廢棄，新的數據源被開發；

（4）副本程序的原本，即“通用知識”之源，可能被修改、調整、改進、優化，甚至重新設計及重新制作。

如果副本保持不變，情況還不至于太糟糕。因為原件的任何變化都可采用受控的“搜索—替換—調整—驗證”重新復制并重新粘貼到現有的副本上。然而實踐一再表明，這些副本本身也有可能出于某種原因被單獨地修改、調整、改進、優化及擴展。

在一切剛開始的時候，什么是共有的、通用的，什么是個別的、特殊的，可能很清楚。因此，我們能夠通過神力無比的操作鏈以產業化方式高效地工作。這時，原件和副本之間的關系是明確無誤的。然而，在最后結束時，所有東西都混淆在一起了。沒有人知道它們之間曾有過一個“原件-副本”的密切關系。現在，它們一個個都像孤兒一樣孤苦伶仃。因此，所有其后而來的變動不得不單獨地、直接地在副本上進行。

4.3 不限于編程

事實上，上述觀察對一個龐大的設計團隊的不同設計師在很長一段時間內的設計過程及由他們交付的設計說明書來說同樣有效。實際上，前面細述的編輯行為模式不僅局限于程序與編程、說明書與說明，它們同樣也廣泛地存在于文檔編制與文檔之中。此外，只要程序在開發或維修期間發生變化，那些原來通過運用我們駕輕就熟的編輯操作鏈產生的文檔則應馬上得到相應的更新。就像上面描述和討論的那樣，隨著時間的推移，這將變得越來越困難。此外還有一個原因，程序文檔的及時更新雖然對于維護和推廣的成效至關重要，但對于程序本身的正常運行并非絕對必要。顯而易見，若無相當的努力，所有這些程序最終至少在心理上被認為是無文檔程序。

突然間，我們發現我們身處阿姆斯特丹跳蚤市場：一大堆單一手工制作的，無文檔記錄說明的，其維護和擴展需要不成比例的時間和金錢的工藝品。這就是當今數據倉庫構建人的生活及工作現實的真實寫照。最后，但同樣重要且必須明白無誤說明的是，所有這一切觀察都與是否采用某種ETL工具或輔助設施無關。

事實上，這里的主要問題是對存在于ETL機制中的通用知識之載體的處理方式不恰當。由于上面討論的種種原因，它們的形式發生了變化以至于它們所攜帶的通用知識不能夠被感知并得到利用。這樣，通用知識同特殊知識混雜在一起，以至于通用知識也被視為特殊知識。對個別的、單一的、特殊的事物的處理幾乎總是更昂貴，更麻煩。這就是我們的數據倉庫構建悲劇的真正原因所在。

5 小結

· 通常的企業數據倉庫的ETL機制包含大量相當類似，但又不完全相同的程序。

· 由于這種顯著的相似性，ETL機制中存在大量的域通用知識。

· 無論是否使用工具或輔助設施，采用當今流行的構建方法，這類通用知識不知不覺地、不受控制地被分散在每一程序之中。

· 由于ETL程序數量大，加之數據倉庫的長壽性及動態性，這些程序不可避免地會經受大量變化。

· 這些變化最終導致通用知識與特殊知識的載體成為一種不可分離的混合物。而這又使一切顯得都是某種特殊知識的載體。

· 特殊知識必須特殊、單獨地加以處理。過去幾十年的數據倉庫構建經驗告訴我們，這種處理是極其昂貴、耗時、高風險的。

· 為避免偽特殊知識載體的產生，通用知識不應被分散。用管理學的話說，對通用知識只允許唯一的詮釋。這就是一個全新的、高效的數據倉庫構建方法的核心思想所在。

參考文獻

[1] Archimedes[EB/OL].[2012-12-18].http://en.wikipedia.org/wiki/Archimedes.

[2] Henry Ford[EB/OL].[2012-12-18].http://en.wikipedia.org/wiki/Henry_Ford.

[3] Jiang B.Data Warehouse Construction:How Would Great Engineers Have Done It? [EB/OL].[2012-12-25]. http://www.b-eye-network.com/view/16285.

[4] Inmon B.Whatever happened to Code Maintenance? [EB/OL].[2012-12-25].http://www.b-eye-network.com/view/15863.

[5] Jiang B.Data Warehouse Construction:Behavior Pattern Analysis[EB/OL].[2012-12-25].http://www.b-eye-network.com/view/16390.

[6] Jiang B.Data Warehouse Construction:The Real Life[EB/OL].[2012-12-25].http://www.b-eye-network.com/view/16473.

[7] Jiang B.Constructing Data Warehouses with Metadata-driven Generic Operators and More[M].Switzerland:DBJ Publishing,2011.

Behavior Pattern Analysisin Data Warehouse Construction

JIANG Bin, YU Xiaosheng, WANG Dongjuan, JIANG Yanjing, ZHAO Meilin

（College of Computer and Information, Three Gorges University, Yichang 443002, Hubei, China）

Abstract Construction and maintenance of ETL programs are of decisive importance for data warehouse construction and application.Traditionally, ETL programs are treated in horizontal or vertical ways.It is showed that both traditional approaches are not effective regarding development productivity, software quality and documentation quality for constructing and maintaining ETL programs.Through analyzing behavior patterns in constructing ETL programs, it is observed that the knowledge involved can be divided into domain-generic knowledge and object-specific knowledge. Domain-generic knowledge repeats and can thus be treated only once.Based on this observation, the development productivity, software and documentation quality of ETL programs can be improved significantly.

Key words Data Warehouse Construction, ETL, Behavior Pattern

作者簡介

蔣彬（1955—），男，三峽大學計算機與信息學院，博士，教授。研究方向：數據倉庫構建。E-mail:bin.jiang@bluewin.ch。

余肖生（1973—），男，三峽大學計算機與信息學院，博士，副教授。研究方向：商務智能與信息管理。E-mail:yuxiaosheng_2005@163.com。

王東娟（1977—），女，三峽大學計算機與信息學院，講師。研究方向：商務智能與信息管理。E-mail:wdj@ctgu.edu.cn。

姜艷靜（1978—），女，三峽大學計算機與信息學院，講師。研究方向：商務智能與信息管理。E-mail:49699671@qq.com。

趙美林（1979—），女，三峽大學計算機與信息學院，講師。研究方向：商務智能與信息管理。E-mail:1530870472@qq.com。