如何架構一個BI系統

       剛開始接觸軟件工程的時候，知道其中一個步驟叫做“總體設計”，做這項工作的人就叫“軟件設計師”。當時覺得這個名稱比軟件開發工程師酷多了。到了現在，又開始流行“架構師”（Architect）  ，這個名稱 聽起來比軟件設計師又酷了幾分。  
       如今，如果你偶爾遇到一個年輕人，也就是二十出頭、三十不到的樣子，卻客客氣氣地給你遞上一張注明“數據倉庫資深架構師”的名片。這個時候，你千萬不要詫異。說來也不奇怪，

BI在國內剛  發展起來沒幾年，在這個領域干個四五年就足以混個資深的名頭了。 
       不過，話說回來，拿著“資深架構師”的名頭去忽悠是一回事，但架構師究竟該干什么，架構設計究竟怎么進行，如何架構一個BI系統？的確是需要認真研究一番的！ 

第一截：模塊  
       BI系統（或者說數據倉庫系統）也同樣需要架構，它作為一種軟件系統，是符合一般架構原則的。首先，我們來看看架構設計中包括那些內容。 架構的重點是描述系統的結構，以及它們之間的  關聯、交互接口。  
       BI系統可以劃分成業務模型、元數據、數據質量、接口平臺、報表集市、指標庫等若干模塊?？梢钥闯觯谶@里，這些模塊的命名都是靜態的名詞，而不是動詞（例如業務建模、數據質量管理等）  。之所以如此，是因為這是在描述系統的結構而非功能。 

       具體來講，業務模型是存放業務數據的結構，可以再往下細分，并有不同的分層方法。例如可以分成ODS、EDW、DM等層，也有的會根據業務復雜度或數據量考慮，舍棄ODS層。業務模型是支撐  業務分析需求的，例如報表、儀表盤、OLAP、專題應用等。  
       元數據為整個系統數據的形態和數據流動的過程起到支撐作用，也就是說，數據從源頭開始，到最終用戶眼前，其來龍去脈，每個環節的狀態都需要掌握。還有人將它比喻成模塊之間的粘合  劑，但我更愿意將它稱作是“數據”之間的粘合劑，因為模塊之間自有它們的交互接口規格來粘合。數據質量模塊為衡量數據源質量、ETL 過程處理質量提供支撐。  
       接口平臺是處于源系統和數據倉庫系統之間的玩意兒，作用在于可以更方便地明確界定雙方職責。當然，通常有很多系統似乎并不大愿意將職責搞得過于明確了倒寧愿糊涂一些。糊涂
一些的  好處在于一開始省了好多事，但在以后扯皮的事情就少不了了。此外，報表集市為報表應用提供支持，指標庫為績效管理需求提供支持。其實，這兩者還可以歸入業務模型一類，因為它們都是  服務于分析需求的。 

第二截：需求  
       之所以分成若干模塊，是為了讓架構清晰，降低這些模塊之間的耦合，這符合“分離變化”的原則。那么，這一結構到底是否合理呢？還得看這個架構面臨的需求到底是什么。做好這一步，就需  要把系統的用戶分為兩大類角色：一是系統運營角色，他們對系統的正常運行、維護負責；二是業務分析角色，他們需要從這個系統得到數據分析的功能。 

       顯然，第二種角色的分析數據來源都將來自業務模型模塊，而第一種角色將從剩余模塊中滿足自己的需要，而不直接和業務模型這個模塊打交道。在架構設計中，重點應該放在如何滿足系統  管理用戶的需求上面。當然，只是"重點"，而非舍棄業務分析角色，畢竟在業務模型模塊中，還需要根據業務、數據量、分析應用等方面的特點，來進一步細化。  
       就筆者個人經驗認為，架構設計應該是與具體業務關系不大的，這種架構應該是半通用的。之所以是半通用，是因為在系統功能上面，BI項目大同小異，而在業務需求上面，架構只需要對客戶  的業務、分析需求分成幾個大類，例如按行業為業務模型分類，按OLAP、報表來為分析應用分類，不需要太過細致。 

下面，讓我們來看看系統運營角色的需求。  
       首先，我們可以把這類角色再細分成兩類：一是開發設計及實施者。之所以將開發者作為系統的用戶，是因為數據倉庫項目應該看作一個過程，而不是產品，因此在開發階段，其實其架構最  重要的用戶就是開發者，當然要為之提供便利。二是系統管理員。系統交付之后，如何監控系統運行、發現數據質量問題、應付新的分析需求等，當然都是系統管理員的分內之事。 
那么，對于開發實施人員，他需要進行系統部署、ETL的開發調試、質量的稽核；對于設計人員，則需要進行模型的變更、系統調優、系統一致性分析等；而系統管理員則需要監控ETL過程、監控系統運行、響應系統警報、接口數據管理等。這些都可以看作是用例。  
       這些用例就是架構設計的"需求"，如何滿足他們，并且保持良好的體系和清晰的結構，能夠易于維護且能夠滿足日后肯定會增加的業務需求等等，這些都是架構師們仔細斟酌的事情。 
最后，看一下分析人員的需求。舉個例子來講，某銷售總監說：“我需要了解近半年來東區和西區的銷售量、收入、成本對比”，這可以算是一個用例。對這個需求，架構師該如何做呢？正確做法是，在架構中不能考慮東區、西區這些業務概念，那樣就太過于細致，而是應當將這種需求抽象成一種分析應用，例如 “即席查詢”。如此，架構師所著重考慮的事情就是如何滿足這一類需求，而非這一個需求。 

鏈接： 
架構設計四項原則： 
1、架構設計主要面向系統用戶為主；
2、架構設計的內容主要包括：系統功能需求、分析需求分類；支持這兩者的后臺結構，對結構進行粗略劃分，以讓其內部能夠保持簡單的交互方式；
3、架構設計中不要包含過于細致的業務術語（除非為了說明方便），要盡可能保持架構的復用；
4、如果架構設計確實包含不能被其他項目復用的地方，將這部分獨立出去。(網界網-CCW)