如何架構(gòu)一個(gè)BI系統(tǒng)

申請免費(fèi)試用、咨詢電話：400-8352-114

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

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

第一截：模塊

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

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

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

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

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

第二截：需求

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

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

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

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

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

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

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

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

 鏈接：

架構(gòu)設(shè)計(jì)四項(xiàng)原則：

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