- 2008年11月23日
DB人員=資料搬運工？(上)
Dear Duncan:
Long time no see……
在ZDNet看到你所發表「商業智慧(BI)系統是建構在資料倉儲(Dataware, DW)的基礎上」的文章，我深感認同，我們公司在幾年前就感受到決策下達的不易，老闆每下一個決策，我們就要協助準備好多資料，做不完的圖表，算不完的數據，有的資料是從ERP系統產出的，有的資料則是由PIM系統產出的，而有的資料又是由MES系統產出的……等，不同系統的資料都要去撈一下，才有辦法讓老闆心安地下達一個決策。老闆也感受到分析的重要性，所以，前年年底的時候，決定要開始要建置公司內部統籌運作的BI系統。
聽了某資料庫大廠的建議後，我們決定要從資料倉儲(Data Warehouse, DW)開始建起；但DW建置遠比我們想複雜太多，要轉進來的資料好像永遠都轉不完，老闆們想分析的資料越來越多，我們就一直在重新定義資料倉儲中的資料結構，有的還重新轉入。（轉到最後，我們自己常常搞不清楚，那一些資料已經轉過，哪一些沒有轉過）。資料倉儲也越來越大，已經超出我們原先所預期；短短的一年間主機板的數目也從原先的一塊追加到了三塊，Storage 使用量成長的速度更是驚人。為了白天老闆能分析，我們只好趁夜間排程把資料轉到DW中，資訊部門也經常要加班。
辛辛苦苦轉了一年，現在固然已經有一些分析的結果產出，但價格效益比似乎很不划算，我並不覺得我們在做商業分析系統，我們覺得我們不過是一群「資料搬運工」。
經歷過這些事後，我對資料倉儲的建置真的怕到了，我想知道，有沒有可以避過這段困難過程？
祝 商祺
Mxxxxxy
很多企業都知道BI的好處，但是一想到在建置BI前要還要先完成DW的建置，就會望而卻步。一定需要建置DW嗎？有沒有可能躲過這一段？這是很多技術長與資訊長的疑問。
Why Data Warehouse?
在正式進入討論前，依慣例，我們還是先回過頭來看看歷史：為什麼需要DW？DW的存在主要是要解決什麼樣的問題？
●為了不影響企業的維運
首先，企業要分析的資料基本上會儲存在企業內部現行營運系統的資料庫(DB)主機中。例如企業如果要分析ERP系統資料，就會去ERP的資料庫中截取資料進行分析。但是這一些資料庫主機所規劃的承載能力（capability）通常是以滿足企業維運為主，並不會評估其它（像商業智慧系統）的需求（錢就是要用在刀口上）。但偏偏大部份BI系統分析資料時會使用到大量資料庫主機的系統資源。因此，如果直接以原來的資料庫主機為基礎來建置的話，BI系統佔用的資料庫主機系統資源即可能導致營運（ERP）系統運作的不順暢，嚴重時，甚至會影響企業的正常維運。
因此，為了避免分析需求影響企業營運，有一些公司會另外再建置一台資料庫主機作為DW，再把營運系統的資料轉過去，供BI分析使用。當然，由於所有的資料在DW中都會有備份，所以為了保障營運系統的整體服務品質，許多管理者甚至會把營運系統資料庫的歷史資料刪除（data purge），只留下支持營運的資料。
●資料整合上的需求
隨著企業系統建置的複雜化，一個企業中有兩個不同以上的資料庫主機已經是常態。例如：一台 SQL Server 資料庫主機是給 SEM 系統使用，ERP 系統則使用另一台Oracle 資料庫主機，而另一台MySQL資料庫主機支援Call center 系統。因此在商業智慧系統的建置上，我們也常會碰到某些分析比對的資料，來自儲存於不同類型、不同主機的資料庫中。但有資料庫系統程式撰寫經驗的人應該都知道，不同類型、不同主機資料庫內的資料表格（Table）無法直接透過 SQL 語法來做到兩個資料表格的結合（joint）或合併（unite）。當然，其他方式可以解決這個問題，不過也增加了系統管理的複雜度。因此，為了避免上述問題，很多企業便把在各個不同類型、不同主機資料庫上的資料，統統移轉到單一台大型的資料庫–資料倉儲上面，以方便BI分析。
●資料整理的需求
在做BI分析時，我們經常會發現，存放於原始營運系統資料庫中的資料並不一定直接可使用。在資料轉換的過程中，或多或少都要做一定程度的修正。例如：最常看見的就是日期時間格式的問題了，首先對於不同時區的資料庫，就需要先轉換成同一個時區的時間後才能比對分析。
再來，不同的系統，可能會用不同的日期型態來存儲，除了大家常用的日期資料型態（如date、datetime…等）以外，有些系統會將日期轉換成秒後、以數字的資料型態來儲存，甚至，我也看過系統在設計上直接將日期與時間以字串型態儲存在資料表的欄位中。
針對這些不同格式的表示方法，我們都要轉換成相同格式的表示方法，BI才有辦法做一致性的分析管理。日期格式的處理還算是小問題。此外，BI分析之前還有其他工作，像無意義資料的排除、錯誤資料的修正、遺漏資料欄位的補足等，這一些在資料轉移到DW的過程中來整理的動作，我們稱之為ETL（Extract、Transform、Load）。
Data Warehouse 面臨的挑戰
DW 的建立，讓 BI 系統分析可以在儘量不影響營運系統正常維運的情況下進行。但隨企業對分析需求的提升，目前的資料儲的建構方式，也有它需要去面對的瓶頸：
●沒有轉移到 DW 的資料就沒有辦法以BI系統來進行分析
首先，沒有進到 DW 的資料，是沒有辦法由 BI 系統來進行分析的，但是一個資料有無分析的價值，在還沒有進行分析之前是有時候是沒有辦法知道的，這是負責分析的同仁會覺得最麻煩的地方。每次都要等人協助他把資料轉入後，他才可以進行分析。
而相信很多的 DW 管理人員都發生過，分析人員可能會一直請你協助將某些資料倒到 DW 裏。當然身為一個協助者， DW 的管理人員自然不會推卸，但辛辛苦苦地做了資料整理並進行轉移，過了一段時間，發現資料好像只有初期剛轉移完有被讀取，而後來就再也沒有被讀取過。為什麼呢？問了問負責析分同仁，他可能會給了你肯定回答：「是，我目前沒有在用…」（X！害我轉得好辛苦），但是如果問他是不是要刪除掉，他卻沒有辦法那麼肯定了：「因為下次，老闆可能會在其它的需求上，又想要分析這一些資料」（X！你不知道維護垃圾也是要時間的嗎？）。
這都還好，反正資料放著，有機會還是用得到，就是浪費一些資料儲放、resync的系統資源及人員維護的成本而已。最慘的是，資料放久了，放到大家都忘記了，特別是在巨型 DW 環境中，被轉移整合的資料很多，常常轉到最後，已經搞不清楚那些東西有被轉過，哪一些東西沒有被轉過。此時，再一次，資料又要被重新辛辛苦苦地整理後再轉移（堪稱 DW 管理人員的十八道輪迴）。搞不好， DW 已放了一堆重複轉入的歷史資料而沒有人知道。
許多 DW 管理同仁員及負責分析的同仁想問：有沒有可能在確認資料有分析價值後，才進行整理與轉入呢？還是，有沒有可能只做資料整理，而不需要轉入，就讓分析人員先行分析呢？。
(待續)
|
|
|
|
| 
1.王精顯 於 2008/04/21 23:14 回應
先定出 KPI 再來想 BI 罷~