資料倉庫部署七大禁忌
Scott Robinson‧陳奭璁整理 2004/04/22
你過去常用的OLTP技術說不定現在反而釀成大錯。
資料倉庫的部署並不是一個簡單的任務，你會發現以前積累下來的豐富經驗，並不適合處理每個資料倉庫的獨特需求。
下面列出的事項是你在部署資料倉庫過程中一定會碰到的問題，其中一些看起來並沒有想像中那麼嚴重，但是你還是應該儘量避免出現類似問題。資料倉庫跟交易系統不同，它沒有一定的標準，也不會部署某個特定的應用，但它本質上是非常有組織性的。總之，每個公司所建立的資料倉庫都是唯一的，並且每一次資料倉庫的部署方法都不是一成不變。在部署資料倉庫時需要注意的不單是「應該如何作」，更要注意「不該如何做」。下面就是我們總結的七大必需重視的重點。
1.不要撰寫自己無法快速修改的程式碼
你所要撰寫的程式主要用於資料分析，而不是處理交易性質的。而你的用戶也並不真正知道他們自己真正想要一個什麼樣的程式。因此你可能得多次往返修改程式碼好幾次，才會明白用戶到底需要一個什麼樣的程式。如果你撰寫的程式具有良好的結構和靈活性，就算需要修改也不會太浪費力氣。反之，你會被自己累死。
2. 不要使用無法修改的資料庫存取API
在過去，你的資料庫可以為大量的客戶提供穩定的資料查詢服務。而如今，你的程式必須能夠應付更多的資料查詢。這使得重新改寫程式好讓得每個查詢請求能得到最大的資料量成為勢在必行的工作，而一般來說這種程式碼修改都不會一次成功，所以只有選擇合適的可以修改的API，才能使程式儘快適應新的需求。
3. 不要設計任何沒有延伸性的東西
在線上交易處理過程（OLTP）應用中，資料分析並不是一個真正的應用程式。實際上，資料分析的關鍵是獲取大量的舊資料，從中萃取資料模型，並以此模型推斷出新的資訊。而你所撰寫的存取潛在資訊的程式碼應該具有可延伸性，可以添增新資料。千萬別在支援資料分析的程式碼中假定資料都是固定格式。
4. 不要在資料與用戶之間加入不必要的功能
一個倉庫要做的是恰到好處的服務，用戶走進倉庫，從貨架上取得自己所需得資訊，僅此而已。由於商業智慧、分析以及規律性的問題都有各自的處理程式，因此你的客戶唯一的需要就是獲取資訊。他們需要一種應用環境，可以讓他們快速的從資料倉庫中取得分析過程所需的資料，而不論這個資料是什麼樣子的。也許你想幫助他們精煉一下獲得的資料，但最好不要這麼做。一定要記住，不要給客戶的資料分析程式添加任何會影響資料存取性能的功能。
5. 不要簡化資料清除和資料源分析的步驟
在部署資料倉庫過程中最應該注意的地方就是為Extract-Transform-Load機制分析資料源，以及為負載而清除資料。安全的做法是假設專案經理在這個階段會需要整個專案資源的一半以上。相反，如果你在這方面進行了簡化，稍後肯定會後悔。所以就算這部分的工作很無趣，也不要簡化清理舊的資料的過程。
6. 不要規避顆粒度(granularity)和分割(partitioning)問題
在資料倉庫設計過程中有兩個最大的資料儲存問題，第一是如何給轉換資料定位一個恰當的顆粒度等級，第二是如何有系統的分割資料。為什麼這兩點問題如此重要呢？因為整個資料倉庫的回應能力受顆粒度影響，並且資料存取的效率直接與資料分割性能有關。因此這是具有關鍵性的工作，不要試圖規避面對這些問題。
7. 不要在沒考慮商業問題前就使用OLAP
用戶在親眼見到程式前通常都不知道自己到底想要個什麼樣的程式。因此他們的觀點有不少錯誤，比如他們希望分析結果會忠實反應效能指標，或者希望程式會使他們部門或公司的業務作業方式有所不同。而你必須跳出自己的職責範圍，從IT管理者的角度考慮用戶部門直至整個企業的運行方式，才能在開發過程中避免這類問題。在通常的OLTP開發中，你可以比較方便的理解商業流程。而在線上交易處理（OLAP）領域，凡事都需經過探索，而在你周圍工作的人也許並不會發現你對商業方面存在的誤解而導致的錯誤。因此，不要自以為已經瞭解了足夠的資訊。不斷的詢問才能使你真正瞭解「商業智慧」中的「商業」到底是什麼樣子的。
fr.: http://taiwan.cnet.com/enterprise/topic/0,2000062938,20089036,00.htm
0 Comments:
Post a Comment
<< Home