剛開始接觸軟件工程的時候，知道其中一個步驟叫做“總體設計”，做這項工作的人就叫“軟件設計師”。當時覺得這個名稱比軟件開發(fā)工程師酷多了。到了現(xiàn)在，又開始流行“架構(gòu)師”（Architect），這個名稱聽起來比軟件設計師又酷了幾分。

如今，如果你偶爾遇到一個年輕人，也就是二十出頭、三十不到的樣子，卻客客氣氣地給你遞上一張注明“數(shù)據(jù)倉庫資深架構(gòu)師”的名片。這個時候，你千萬不要詫異。說來也不奇怪，BI在國內(nèi)剛發(fā)展起來沒幾年，在這個領域干個四五年就足以混個資深的名頭了。
不過，話說回來，拿著“資深架構(gòu)師”的名頭去忽悠是一回事，但架構(gòu)師究竟該干什么，架構(gòu)設計究竟怎么進行，如何架構(gòu)一個BI系統(tǒng)？的確是需要認真研究一番的！

第一截：模塊

BI系統(tǒng)（或者說數(shù)據(jù)倉庫系統(tǒng)）也同樣需要架構(gòu)，它作為一種軟件系統(tǒng)，是符合一般架構(gòu)原則的。首先，我們來看看架構(gòu)設計中包括那些內(nèi)容。架構(gòu)的重點是描述系統(tǒng)的結(jié)構(gòu)，以及它們之間的關聯(lián)、交互接口。

BI系統(tǒng)可以劃分成業(yè)務模型、元數(shù)據(jù)、數(shù)據(jù)質(zhì)量、接口平臺、報表集市、指標庫等若干模塊。可以看出，在這里，這些模塊的命名都是靜態(tài)的名詞，而不是動詞（例如業(yè)務建模、數(shù)據(jù)等）。之所以如此，是因為這是在描述系統(tǒng)的結(jié)構(gòu)而非功能。

具體來講，業(yè)務模型是存放業(yè)務數(shù)據(jù)的結(jié)構(gòu)，可以再往下細分，并有不同的分層方法。例如可以分成ODS、EDW、DM等層，也有的會根據(jù)業(yè)務復雜度或數(shù)據(jù)量考慮，舍棄ODS層。業(yè)務模型是支撐業(yè)務分析需求的，例如報表、儀表盤、OLAP、專題應用等。

元數(shù)據(jù)為整個系統(tǒng)數(shù)據(jù)的形態(tài)和數(shù)據(jù)流動的過程起到支撐作用，也就是說，數(shù)據(jù)從源頭開始，到最終用戶眼前，其來龍去脈，每個環(huán)節(jié)的狀態(tài)都需要掌握。還有人將它比喻成模塊之間的粘合劑，但我更愿意將它稱作是“數(shù)據(jù)”之間的粘合劑，因為模塊之間自有它們的交互接口規(guī)格來粘合。數(shù)據(jù)質(zhì)量模塊為衡量數(shù)據(jù)源質(zhì)量、ETL過程處理質(zhì)量提供支撐。

接口平臺是處于源系統(tǒng)和數(shù)據(jù)倉庫系統(tǒng)之間的玩意兒，作用在于可以更方便地明確界定雙方職責。當然，通常有很多系統(tǒng)似乎并不大愿意將職責搞得過于明確了倒寧愿糊涂一些。糊涂一些的好處在于一開始省了好多事，但在以后扯皮的事情就少不了了。此外，報表集市為報表應用提供支持，指標庫為需求提供支持。其實，這兩者還可以歸入業(yè)務模型一類，因為它們都是服務于分析需求的。

第二截：需求

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

顯然，第二種角色的分析數(shù)據(jù)來源都將來自業(yè)務模型模塊，而第一種角色將從剩余模塊中滿足自己的需要，而不直接和業(yè)務模型這個模塊打交道。在架構(gòu)設計中，重點應該放在如何滿足系統(tǒng)管理用戶的需求上面。當然，只是"重點"，而非舍棄業(yè)務分析角色，畢竟在業(yè)務模型模塊中，還需要根據(jù)業(yè)務、數(shù)據(jù)量、分析應用等方面的特點，來進一步細化。

就筆者個人經(jīng)驗認為，架構(gòu)設計應該是與具體業(yè)務關系不大的，這種架構(gòu)應該是半通用的。之所以是半通用，是因為在系統(tǒng)功能上面，BI項目大同小異，而在業(yè)務需求上面，架構(gòu)只需要對客戶的業(yè)務、分析需求分成幾個大類，例如按行業(yè)為業(yè)務模型分類，按OLAP、報表來為分析應用分類，不需要太過細致。

下面，讓我們來看看系統(tǒng)運營角色的需求。

首先，我們可以把這類角色再細分成兩類：一是開發(fā)設計及實施者。之所以將開發(fā)者作為系統(tǒng)的用戶，是因為數(shù)據(jù)倉庫項目應該看作一個過程，而不是產(chǎn)品，因此在開發(fā)階段，其實其架構(gòu)最重要的用戶就是開發(fā)者，當然要為之提供便利。二是系統(tǒng)管理員。系統(tǒng)交付之后，如何監(jiān)控系統(tǒng)運行、發(fā)現(xiàn)數(shù)據(jù)質(zhì)量問題、應付新的分析需求等，當然都是系統(tǒng)管理員的分內(nèi)之事。

那么，對于開發(fā)實施人員，他需要進行系統(tǒng)部署、ETL的開發(fā)調(diào)試、質(zhì)量的稽核；對于設計人員，則需要進行模型的變更、系統(tǒng)調(diào)優(yōu)、系統(tǒng)一致性分析等；而系統(tǒng)管理員則需要監(jiān)控ETL過程、監(jiān)控系統(tǒng)運行、響應系統(tǒng)警報、接口數(shù)據(jù)管理等。這些都可以看作是用例。

這些用例就是架構(gòu)設計的"需求"，如何滿足他們，并且保持良好的體系和清晰的結(jié)構(gòu)，能夠易于維護且能夠滿足日后肯定會增加的業(yè)務需求等等，這些都是架構(gòu)師們仔細斟酌的事情。

最后，看一下分析人員的需求。舉個例子來講，某銷售總監(jiān)說：“我需要了解近半年來東區(qū)和西區(qū)的銷售量、收入、成本對比”，這可以算是一個用例。對這個需求，架構(gòu)師該如何做呢？正確做法是，在架構(gòu)中不能考慮東區(qū)、西區(qū)這些業(yè)務概念，那樣就太過于細致，而是應當將這種需求抽象成一種分析應用，例如“即席查詢”。如此，架構(gòu)師所著重考慮的事情就是如何滿足這一類需求，而非這一個需求。

鏈接：

架構(gòu)設計四項原則：

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