《資料虛拟化：商務智能系統的資料架構與管理》一 2.10 傳統商務智能系統的劣勢

基于這一章所闡述的概念，商務智能系統已經發展了很多年。正如預想的一樣，這些系統中的大多數都是基于一個鍊式資料存儲和轉換過程，此外，很多資料存儲還包括衍生資料。圖2-15是一個普通的商務智能系統的例子，它基于這樣一個包含了資料中轉區、ODS、資料倉庫、大量的資料集市和一些PDS的結構。在這個系統中，資料從一個存儲區被複制到另一個存儲區，直到它存儲在一個可以被報告工具通路的區為止。因為這些複制，資料倉庫、資料集市和PDS中都包含了相當大數目的派生資料。事實上，這樣一種結構其内部所有的資料，例如一個資料集市，是由資料倉庫衍生而來的。

我們把有這種類型結構的系統叫作傳統商務智能系統。如此多的系統以這種模式發展的原因與過去20年中硬體和軟體的狀況相關。這些技術在性能和擴充性方面有各自的局限性，是以，一方面，報告和分析的工作負擔分散在多個資料存儲區中，另一方面，轉換和清洗不得不分解到衆多的步驟中。

但是技術與解決方案一如既往，不管被引進的時候多麼有價值，它們都有失效日期。就像那些強大的三桅杆船一樣，它們在幾百年前成功地用來發現了新大陸。不管它們以前如何有影響力，最終還是被輪船取代了。它跟馬最終被汽車取代是一個道理，這樣的例子還有好多。

傳統系統的一些缺陷漸漸明顯了。

缺陷1—重複資料：第一個缺陷與系統記憶體儲的大量重複資料相關。大多數資料存儲區包括從其他資料存儲區派生來的資料。例如，一個資料集市的内容是從資料倉庫中派生來的，那麼資料集市中的資料100%是備援的。同樣，複制導緻PDS中裝滿備援的資料。甚至是資料中轉區和資料倉庫也将會有大量重疊的資料。另外，在一個資料存儲區内部，大量的重複資料會被存儲。這些重複資料中的大多數存儲起來，用于提高查詢、報告和ETL腳本的性能，這些重複資料以索引、物化查詢表、彙總資料的圖表和中轉區等方式隐藏。

資料倉庫占用了大量的存儲空間—事實上，是TB，有時候甚至是PB。但是究竟有多少原始資料呢？基于英國現狀的分析師Nigel Pendse做了一項大規模的實驗，表明了在最大的商務智能應用中實際可通路的網絡資料報告量近似是原始資料中的5GB（見文獻［34］）。這是資料中的中位數。這個資料聽起來是真實的，但是其他很多研究表明資料倉庫的平均大小是10TB（或者更多），這兩者又是如何比對的？如果這些都是原始資料，那麼根據Pendse的研究，為了得到10TB的資料，2000個不同的且其中沒有重複資料元素的商務智能應用将是必須的，這幾乎是不可能的。衆所周知，資料倉庫有時候會包括商務智能應用不能通路到的資料，例如原始細節資料、索引等，但是這還不足以解釋它所占用的巨大資料空間的原因。是以，這些資料清楚地說明了大量的重複存儲的資料是人們可感覺的。

顯然，存儲這些重複資料是有原因的，這個原因就是性能。為了加速查詢，我們需要那些索引、物化查詢表、彙總資料的列和派生的資料存儲區等。

存儲不再是那麼昂貴了，那麼問題是什麼呢？問題就是靈活性。重複資料存儲得越多，結構的靈活性就越差。每一個修改都要求對重複資料進行額外的操作。保持重複資料的同步也需要很大的花費。存儲重複資料将會導緻資料的不一緻。通過移除大多數的備援資料，商務智能系統能夠被大大簡化。

缺陷2—非共享的中繼資料規範：傳統系統的第二個缺陷可以用非共享的中繼資料規範來形容。許多報告和分析的工具允許我們使用特定方式，使得報告更加獨立于資料資源。例如，在SAP的Business Objects體系的概念中，我們可以定義确定的術語和表格間關系。這對于所有使用這個工具所作的報告來說是完美的，但是如果我們想生成其他的報告，例如用Excel或者用IBM/Cognos的工具，又會是怎樣呢？這意味着這些中繼資料規範必須複制到那些工具中。

總之，很多導入到工具中的規範不是共享的。企業中往往會建立各種各樣的環境，在這個環境中，不同的工具用于不同的任務，是以這需要可共享規範的存在。這一不可共享規範的例子與報告和分析工具相關，但是其他的不可共享規範的例子也存在于ETL工具和資料庫伺服器中。不可共享的中繼資料規範降低了靈活性，難以管理，将會導緻不一緻的報告結果。

缺陷3—靈活局限性：關于靈活性的一個重要的弱點。軟體工程領域已經教會我們，如果我們設計了一個系統，就需要把記憶體結構和應用結構分開，因為如果能把它們清晰地分開，存儲結構的改變就不會總是需要應用結構的改變，反之亦然。這對于保持性和靈活性都有好處。就像1.5.1節所述的一樣，David L. Parnas是首先認識到資訊隐藏（别名封裝）和抽象化的重要性的人之一。随後，這些概念成為其他概念，諸如面向對象、基于元件的開發、面向服務的體系結構等的基礎。

每一個軟體工程師都把抽象化和封裝視作非常基本的概念，但是似乎商務智能專家不是這樣。大多數商務智能系統完全沒有基于這兩個概念。幾乎所有的報告都與一個特别的資料庫服務技術相聯系。我們來看一個簡單的例子：設想我們都使用報告工具，可以寫出自己的SQL語句來通路資料庫，我們使用所有的所有權的鐘聲和資料庫服務的口哨來獲得最佳的性能。如果我們想要用另一個支援略有不同的SQL語言的資料庫服務來代替這個資料庫服務将會發生什麼呢？或者我們想要選擇一個基于MDX的資料庫服務呢？或者也許我們想要通路一個外部資料庫，它不會傳回一個表格而是一個XML檔案呢？在所有這些可能的情形中，我們需要極大程度地改變報告的定義。

在商務智能系統中采用抽象化和封裝的概念，對于提高自身的靈活性、更容易地實作改變和采納新的工程技術非常重要。

缺陷4—資料品質的下降：當各種相同資料的副本存在時，資料就會有不一緻性的風險。換句話說，存儲複制資料，正如我們所想的一樣，在傳統商務智能系統中廣泛存在，就包含了資料品質的風險。David Loshin将它規定如下（見文獻［35］）：

每次複制資料時，它也受限于資料轉換的次數，它們都可能會導緻資料錯誤。越後來的副本與原始的資料相差越大。複制的資料隻會導緻熵和不一緻性。

在每一個商務智能系統中，目标之一應當是最小化資料的複制以達到最小化資料品質的風險。

缺陷5—有局限的營運報告支援：另一個與營運報告和分析相關聯的缺陷。越來越多的企業對支援這些新的商務智能的挑戰形式感興趣。營運的商務智能系統決定着報告必須包括最新的資料。每天更新一次資料資源對他們來說是不夠的。非常接近商務程序的決策者，像營運經理，尤其需要100%全新的資料。但是這如何做到呢？一個人不需要成為技術巫師也可以了解，如果為了從生産資料庫中擷取資源到報告中，一個資料必須從一個存儲區内複制4～5次到達另一個存儲區，在幾微秒内完成這些工作幾乎是不可能的。大多數商務智能系統沒有按照營運報告與營運資料相關聯的方式來設計。我們不得不簡化結構來支援營運的商務智能系統。最根本的是，可以通過移除資料存儲區和最少化複制步驟來簡化結構。

缺陷6—基于無結構的外部資料的報告支援的局限性：在無結構化的外部的資料的分析和報告上日益增加的興趣導緻了最後一個缺陷。大多數的資料倉庫中都裝着來自生産資料庫中的結構化資料，但是我們很少在裡面找到無結構化的外部的資料。為了允許使用新的資料資源報告，許多專家提議用與内部産生資料相同的處理方式來處理這兩種資料：如果它是無結構的，則使其結構化并把它複制到資料倉庫中，它就可以被分析和報告所使用。換言之，這一提議是基于複制資料。他們想要改造這些資料資源使其适應傳統的商務智能結構。

但是為什麼不直接分析無結構化資料資源和外部資料資源本身呢？在某種程度上，那是網際網路風格的解決方案。如果在網際網路上搜尋某些東西，我們不會首先将需要的所有的網頁都複制到自己的資料庫中。不，資料就在它原本的地方。是以，越來越多的檔案管理系統将允許我們直接分析他們的資料庫，減少了将資料複制到資料倉庫中這種需求。不幸的是，許多商務智能工具不支援通路他們的系統。至于外部資料，在網際網路上做有關外部資料的商務智能，在今天可以運用混搭的工具以複雜的方式完成（見1.13節）。

注意：我們想強調的是這一節提到的涉及商務智能系統的不足之處，并不是結構本身。例如，很多商務智能系統基于CIF（企業資訊工廠）已經得到了發展，其中資料集市用實體的資料存儲區來實作。CIF沒有控制這些，但是因為軟體和硬體技術的可行性，許多企業開始實作這些。資料虛拟化使得虛拟資料集市成為可能（見7.5.2節和7.6.2節）。一個商務智能系統以這種方式發展對于支援CIF仍然是合格的。