論資料倉儲架構前需要考慮的問題

:

[@more@]

論資料倉儲架構前需要考慮的問題

除掉滿足需求以外，一個好的資料倉儲需要考慮的是使用（應用）是否方便，維護是否方便，擴充套件是否方便，開發是否方便。

使用:
好的系統首先解決的是使用問題，如果最好的操作人員不滿意的話，通常應用效果都會比較差的，所以很多公司很注重使用者場景的設計，我曾經和微軟的同事有過一段時間的接觸，發現他們很注重一般企業不注重的問題，比如我們在查詢時，選擇條件，有的是大於，有的是小於，有的是大於等於等等，通常這樣的情況，在事先沒有統一的要求和規定，但是他們對於每一個使用者場景的描述都很清晰，首先按照業務上的應用，其次按照固定的使用者習慣.這就是為什麼微軟的東西總是被稱為傻瓜式的，其實我個人覺得MS的場景真的可以當作傻瓜式來操作，基本上按照他們給的help就可以學會基本的東西了。說回來，我們BIDW需要這樣的嗎？回答是肯定的，我們有固定報表，有分析型報表，有圖表，ad-hoc，還有KPI等dashboard等等，那麼我們有研究過或者指定一些規定來描述嗎？什麼樣的情況需要用固定報表，什麼樣的需要分析性的，什麼樣的用線性圖，什麼樣的用柱狀圖，圖和表的排列應該是怎麼樣的，報表的名字應該怎麼取，格式和大小是怎麼樣，等等等，我想我們BIDW的很多同仁都沒有好好的去思考這樣的問題，其實如果我們有這樣的前臺展現的規定，而且執行下去，將來企業就算不斷的換維護人員，升級系統，都可以比較方便。

維護：
說到維護，我想很多甲方的同仁都深有感觸，維護，我們平時都維護什麼了？報表的修改，報表的增加，臨時統計老闆需要的資料，ETL，系統升級，資料庫的清理，歷史資料的轉接與轉存。這就帶來我們需要去維護資料庫，增加新的表，有的時候我們不清楚原系統的業務邏輯，還要另外來一套表或者報表，一個個的維護人員的更迭，倒是同型別的表很多，同型別的資料很多，比如原來的表叫做T_Sales，現在不清楚邏輯，就吧就夠稍微改一下，變成T_Sales_new或者其他的名字，這樣的資料庫，資料倉儲的模型非常非常的多，到了後來大家都是過一天是一天，只要不出問題，到了最後沒有辦法，又得重新來。如果儘量的避免這樣的問題了，我的經驗是可以從幾個方面去考慮：
1：文件。現在就算比較清晰的文件一般也是在系統開始建設的時候描述的比較清晰，但是一旦開始維護系統了，文件慢慢的也就失去維護的價值了，到了最後，也許和系統的關係就不是很大了，但是我們還是要清楚的描述它，因為就算系統的更迭，以後的維護者還是可以按照最初的文件看出一些道道來，我最近就遇到這樣的問題了。感覺文件還是非常的寶貴。一定要清楚的描述原系統的業務範圍，源表，ETL還有ODS，DW，report等幾者的關係，最好這樣的資料能放到資料庫裡面，而且專門為這些後設資料做一些報表，設定一些檢查的rule，這樣我們就可透過檢視report來檢查我們是否在更新系統後是否更新了文件，是否更新了後設資料。
2：資料字典。我們經常在資料倉儲中遇到A B C D這樣的字母表示的業務意義，這些東西其實業務人員大多都很清楚的，但是IT的就不一定了，這給我們和業務人員之間的溝通造成了一些不方便，其實這樣的型別 代號，一般的企業也只有不到50個型別，通常使用的也只有10-20種，我們可以在建模或者在分析資料的時候，取得這些資料，然後建立一張資料字典，我們的更改刪除等操作都可以用資料的狀態欄位來表示。而且還有很多將來可以直接轉化為維表。
3：培訓材料。業務人員和IT的維護人員，都有換人的時候，他們不懂的可能經常會問，而我們也會經常去給他們講解。如果我們還怕麻煩的話，我們可以製作一下簡單的，簡易的操作手冊或者比較容易理解的影片檔案，提供給他們，最好我們把前期維護的內容都記下來，把問題分類，簡單的一點的，比如系統字元的一些設定等等的，都可以寫下來，放到網上去，做一個Q&A,這樣可以減少很多的工作量。

擴充套件：
擴充套件這個範疇就比較抽象了，我們具體一點的來說，為什麼要擴充套件，就是系統滿足不了新的業務要求，業務在變化，管理在變化，我們如何去考慮改變系統去適應這些變化。主要有下面幾個方面：
模型：我們無論是關係模型還是多維模型或者混合的模型，我們都需要考慮將來，如果原系統發生變化了，或者說原系統的表結構發生變化了，系統是否很方便的去修改和維護。比如我們的財務系統，會計法或者稅法，或者相關的法律發生變化，我們的財務報表就有可能發生變化，那邊對於的財務模型是否需要發生變化了，如果要變化，是否可以輕易的修改了。其實我們說到這裡，都覺得應該的，但是現在的問題是我們怎麼去考慮模型的建設。如果我們在建模的時候有domain（ERWin和powerdesigner都有這個概念）的話，那就最好，我們可以很方便的修改型別。可以方便的修改結構，而且還可以檢視系統的一些相關的變化。如果沒有domain了，特別是大型的企業，而且業務複雜，一般沒有自己的企業資料元，如果資料倉儲是純多維模型的話，我建議我們的ODS採用關係模型去搭建，這樣發生變化的時候，我們也不會對DW有太大的影響。
ETL：我個人比較喜歡採用ELT的方式，將資料轉換放到SP中，因為可以用一個總的SP去適應所以的ETL，然後在設定一些和功能對應的子SP，這樣既可以採用事務去管理，也好透過ETL package的編號去維護。對於一般的insert，delete和update的修改都表容易，特別是異構資料庫的之間的資料傳遞。當時於特殊的ETL，我們可以特殊考慮。
BI，這裡的BI其實就是指的是我們終端使用者操作的介面，一般都是web的，有report，adhoc，dashboard等等，這裡通常都是一些需求的變化。如何的擴充套件更多的還是要取決於我們的使用平臺。最好在設計之前考慮webservice這個功能，因為這個功能是跨平臺的，我們可以從不同的系統互動資料。

開發：
最後我們談談開發，其實BIDW的開發的難度以此為ETL，data model，report展現。ETL的工作量基本上要佔40-60%，而它又在data model之後，所以我們需要考慮的還是在data model怎麼樣為ETL提供方便，首先我們可以在見表的時候用schema來區分表，用固定的name convertion來標示欄位，比如code 用CD，name用NM等等，如果ODS和DW有多層的話，建議用同樣的表，同樣的名稱。這樣很多ETL工具在mapping的時候，就可以自動的匹配出來。
對於ETL的開發，我建議在ETL前，先分析ETL流程，然後開發1-2個通用的package，以後就已這連個為模板，不斷的copy和修改，這樣可以節省很大的工作量。如果能採用package和subpackage的話，那就更好，可以團隊寫作去開發了。