註冊 | 登入 | RSS Feeds
ZDNet | Taiwan.CNET.com |

廣告:
資料倉儲的虛擬化

友善列印 | 轉寄朋友 | 加入HEMiDEMi網路書籤 | 加入funP | 加入Google書籤 | 加入Yahoo!奇摩分享書籤 | 3則回應
    
杜奕鋒 2008/04/21 07:45:00 (見前文)

上周我們談到,DB人員常常忙著把資料搬來搬去,但單一Data Warehouse又會有一些問題。本周再繼續:

●無法進行無縫查詢(seamless query)與分析

相信很多的使用者都有這樣的經驗,當企業建置了資料儲存系統後,利用資料儲存系統所產生出來的報表資料會跟實際在維運的系統(例如:ERP 系統)上的報表資料有時間差;一般而言,因為資料庫系統同步(sync)所需要的系統資源會與資料量成正比,所以資料量越小,系統所造成的時間差越短(例如:五到十分鐘),而資料量越大,時間差也越長(例如:一天甚至到一個禮拜)。

如此,過去的歷史資料與現今目前即時在運行的資料就永遠會有一個斷層,讓分析人員永遠少了那一份最關鍵的資料–當下時間點的資料。在過去商業運作沒那麼快的情況下是還好,但隨著這幾年商業節奏的加速,這種時間差著實會破壞商業的「快感」。

●分析介面的一不致

為了避免上述的問題–遺落現在資料。系統架構沒有辦法改善的情況下,一些比較認真的管理者便會辛苦地交叉比兩個不同系統(一個是營運系統;另一個則是BI系統)中所提供的分析或報表資訊,企圖重新建立兩者之間的連續性,以強化商業決策的正確性與完整性。不過,這種做法會增加管理者的負擔,必須在同一個時間點研讀兩個以上的分析介面才有辦法進行商業決策(資料來源多的時候,甚至會多到三個以上的分析介面),商業的營運效率再為之拖延。

●資源的浪費

猜猜看,通常一聽到企業要建置 DW ,那一個類型的IT 廠商會最興奮?資料庫廠商?或是主機廠商呢? DW 系統主機的系統負載取決於BI系統的分析使用量(而不是取決於擁有的資料量),特別是在 DW 系統導入的初期,BI分析使用量還不是很大的時候, DW 系統可能負載(Loading)不太大,但是,「資料的儲存空間」顯然是建置時完全避免不掉的。新建置 DW 系統的儲存空間等於原始資料存放量的總和,例如:ERP系統有200G 、PIM 系統有500G、CRM系統有700G,如此,在針對這三個系統所建置的 DW 系統,我們基本就會先評估個1400G的空間給它(這樣,大家應該就知道那一類型的廠商最高興了吧?)

不單只是儲存媒體的系統資源浪費,資料同步、系統維運(例如電費、冷氣的使用……等),這一些資源的增加,是會隨著資料儲存的建立與成長而成長的。

▲圖 在 DW 的架構下,會有資源的浪費

Data Warehouse Virtualization

不論資料再怎麼轉來轉去(從A轉到 B ,或從C也轉到B,甚至再轉出去),其實原始的資料也就這麼一份而已,然而為了BI分析需求,所有的資料就都會被複製一份出來,放到效能較高的DW系統中。(並不是說DW 不重要;其實,整個BI 的系統架構中,為了確保分析在整個流程中的效能,DW事實上扮演了很重要的角色。)但是一模一樣的資料被重複儲存並不太符合商業效益。所以除非是一家公司「只」有一個或一種資料庫系統(例如ERP),一般會建議系統管理者擴大原來(不論是主機,或是儲存媒體)資料庫的承載量,讓所有的資料可以存放在單一的 DB 系統中,讓所有的使服務與使用者都運用這單一的資料來作業,以節省管理成本與資源支出。

但是,隨著現今企業資訊環境的複雜化,一個企業經常擁有多種應用系統,並伴隨著多種資料庫時,這種方法就不可行了( DW 的出現其實就是為了解決「資料整合」的問題)。

從分析人員的角度來說,在「建立資料分析模型」的時候,是可以不需要實際上有資料的;重點是在了解並且建立資料的關連性。如下圖所示,在系統架構上,我們可以只需將資料的 Meta Data轉儲過來,以方便分析人員從Meta Data中所記錄的關連性來建立資料分析模型。如此就可以避免只為了確認有沒有分析價值。相同地,也可以避免資料本身不斷地被重複轉移而不自知。

▲圖 虛擬化 DW 的概念圖

並且,從上面的圖,我們可以看到,所有的資料實際上「只」被保留一份在原始的資料庫當中,因此能減少重複資料儲存所耗用的系統及管理資源,特別是在儲存媒體上。

再者,若有實際分析需求時,系統又應該怎麼運作呢?在資料庫運作的時候,所有的分析基本上都還是轉換成 SQL 語法來運作。如上圖所示,Query Engine就是負責承接整體 SQL 語法;這樣的整體SQL可能又分成兩(或多)個部份,例如一部份是由SQL Server取得;而另一部份來自Oracle Database,如此,藉由所轉移過來的Meta Data,BI系統中的Query Engine就可以去相對應的資料庫中攫取資料,最後再將資料進行交叉比對,將整合的結果傳送回給最前線的分析人員,以完成整體的分析行為。

今天網路效能已能支援這樣的架構,協助企業快速且即時地將資料從各個實體資料庫中攫取、整合、並分析,提供管理者無間隙查詢與分析,並避免掉上述實體 DW 所產生的問題。

這樣實體上分散、但邏輯上集中的架構概念,我們可以把它視為是虛擬化的 DW (Virtualized Data Warehouse)(不同的產品可能會有不同的名詞),如此一來,企業在規劃或選擇 BI Solution時候,就能在整個架構當中納入考量,讓整體的 IT 架構更有彈性。

至於有了虛擬化 DW ,是不是表示實體資料倉儲就可以不需要了呢?或者,虛擬化資料庫是不是仍有應該要避免的問題呢?我們以後再說。

作者現任CSC集團台灣澳圖美德(AUTOMATED)資訊長。中央大學數學系畢。專精於商業流程設計、資料庫系統維管理及系統整合,並分別在企業及IT業界有過資料庫規劃、ERP系統導入經驗。也曾授課於崑山大學、永達技術學院、關渡基督書院。
加入我的圖書館 訂閱關鍵字
加入網路書籤> 加入HEMiDEMi網路書籤 | 加入funP | 加入Google書籤 | 加入Yahoo!奇摩分享書籤 |
友善列印 | 轉寄朋友


  • 3.maxhung 於 2008/07/09 20:41 回應
    DW非所有DB的總和(容量),DW已經過清洗、整理、去蕪存菁,照理會少於所有DB的總和!
  • 2.路人 於 2008/04/28 22:21 回應
    m...........................
    【Dimensional Modeling】應該也可以算是【分析程過】的一部份吧……
    所以……作者這樣寫應該也沒有錯………
  • 1.王精顯 於 2008/04/21 22:32 回應
    DW 並非只是單純將所有的資料就都會被複製一份出來,放到效能較高的DW系統中. 其中Dimensional Modeling 是很重要的一環, 但作者似乎完全沒有提到...


留下你的意見
會員 * 帳號:
* 密碼:
  1. 欄位可選填,若全不填,則顯示為「匿名」。
  2. 不支援html語法
非會員 姓名:
E-Mail:
Blog:
  重新載入驗證碼
* 驗證碼: 記住我




廣告

名家專欄

更多名家專欄
Sponsored
利用可靠和高效的NonStop刀鋒技術,達成持續不斷的可用性
 
+ 關鍵任務作業專用刀鋒
+ 更輕易管理虛擬化
+ 更有效控管能源,進而降低能源成本

研討會中心

廣告


Sponsored

活動快訊