在之前的文章視頻中講到了BI自助分析和建模的關(guān)系，我們介紹到了建模在BI分析中本身就是維度和指標(biāo)的組合，這個過程沒有什么很特殊的。只是大家一想到自助分析，就不應(yīng)該通過預(yù)設(shè)模型來限制模型中維度和指標(biāo)的選擇，這個理解就是錯誤的。

不管什么樣的模型都可以理解為一種預(yù)設(shè)，比如像一張大寬表，它的維度和指標(biāo)在大寬表中就是固定的，只是維度列多一些，指標(biāo)多一些，給了用戶更多的一種組合維度和指標(biāo)的可能，并不是說就沒有模型的概念。

在理解了這個概念之后，我們再來講下什么是商業(yè)智能BI的前端建模和后端建模，它們有什么區(qū)別和聯(lián)系。

商業(yè)智能BI的前端建模

商業(yè)智能BI的前端建?？梢岳斫鉃槲覀兺ㄟ^BI的前端可視化分析工具來完成數(shù)據(jù)分析的建模過程。

一種方式是加載一些文本文件比如常用的EXCEL表，可以將文本類型的字段自動轉(zhuǎn)化成分析的維度Dimension，將數(shù)值類型的自動轉(zhuǎn)化為被分析的數(shù)據(jù)就是度量Measure，用戶就可以通過BI分析工具自由的拖拉拽完成維度和度量的組合，進(jìn)行數(shù)據(jù)的可視化展示或者分析，這種維度和度量的這種組合就構(gòu)成了一個最簡單的分析模型。

第二種方式是通過BI前端分析工具連接到一個數(shù)據(jù)源數(shù)據(jù)庫上，選擇相關(guān)的表，通過表與表之間的字段進(jìn)行左關(guān)聯(lián)、右關(guān)聯(lián)、內(nèi)連接等等，實際上就是在商業(yè)智能BI的前端將數(shù)據(jù)表加載出來，完成了SQL的基本關(guān)聯(lián)查詢操作，由多張表形成了一個關(guān)聯(lián)視圖。

同樣的道理，文本類的字段轉(zhuǎn)化為維度，數(shù)值類的轉(zhuǎn)化為指標(biāo)度量，當(dāng)然還可以做一些基礎(chǔ)的、簡單的數(shù)據(jù)清洗工作。如果是直連到業(yè)務(wù)系統(tǒng)數(shù)據(jù)源，通過表關(guān)聯(lián)構(gòu)建分析模型，這也是一種建模的方式，但這種場景一定是基于單系統(tǒng)的、非常簡單的、小型的BI分析應(yīng)用場景，否則沒有辦法適應(yīng)日益增長的業(yè)務(wù)分析需求，包括新的業(yè)務(wù)系統(tǒng)的納入。

如果是直連到已經(jīng)建好的數(shù)據(jù)倉庫，就是底層的數(shù)據(jù)已經(jīng)經(jīng)過非常規(guī)范的清洗、治理和整合，這種方式就沒有問題。前端BI分析工具就可以利用在數(shù)據(jù)倉庫上已有的維度和事實表來構(gòu)建各種維度和事實表的關(guān)聯(lián)，形成一個高度可擴(kuò)展的分析模型。

所以，簡單總結(jié)下基于BI可視化工具的前端建模主要有兩種分類，三種形態(tài)。第一種分類就是我們經(jīng)常講到的個人和部門級的臨時的文件類的數(shù)據(jù)分析，Ad-hoc Report，臨時類的基本分析報表，不依賴于任何的業(yè)務(wù)系統(tǒng)，就是個人臨時性的快速驗證類的數(shù)據(jù)分析。

第二種分類就是連接到數(shù)據(jù)庫，一種形態(tài)是直連到業(yè)務(wù)數(shù)據(jù)源，但往往不能夠做太深入的分析，因為業(yè)務(wù)系統(tǒng)數(shù)據(jù)源的數(shù)據(jù)也一些業(yè)務(wù)分析場景下是要經(jīng)過一系列復(fù)雜的清洗才能達(dá)到使用要求。并且直連數(shù)據(jù)源查詢分析的分析模型不可復(fù)用，大類的聚合查詢對業(yè)務(wù)系統(tǒng)本身也是一種很大的壓力，涉及到跨系統(tǒng)查詢就更加不適合企業(yè)的BI項目。第二種形態(tài)就是直連到數(shù)據(jù)倉庫的數(shù)據(jù)庫，這種方式更加合理。

所以，在企業(yè)級的商業(yè)智能BI項目架構(gòu)設(shè)計中，除了這種個人的、臨時性的驗證性的臨時分析可以考慮做前端建模外，如果是以連接數(shù)據(jù)庫的形式做前端建模就一定是連接數(shù)據(jù)倉庫數(shù)據(jù)庫，而非直接連接業(yè)務(wù)系統(tǒng)數(shù)據(jù)源數(shù)據(jù)庫。

商業(yè)智能BI的后端建模

那么在數(shù)據(jù)倉庫中建模的方式就叫后端建模，就是在數(shù)據(jù)倉庫中預(yù)先把維度表Dimension Table和事實表Fact Table 先處理好存儲起來，這些維度表和事實表本身就可以通過維度字段的關(guān)聯(lián)形成星型和雪花型模型。

在構(gòu)成維度表和事實表之前，底層的ETL要做大量的數(shù)據(jù)抽取、轉(zhuǎn)化和加載的工作，這也是整個BI項目建設(shè)的核心，開發(fā)工作量最大的一部分，差不多要占到項目開發(fā)80%左右的時間和精力。

比如從原始業(yè)務(wù)系統(tǒng)數(shù)據(jù)源、文件數(shù)據(jù)源等多業(yè)務(wù)系統(tǒng)把數(shù)據(jù)加載到ODS層，再統(tǒng)一清洗、處理形成各種維度表和事實表形成標(biāo)準(zhǔn)的DW層，有些為了聚合查詢的方便也會匯總出一部分聚合表放入到數(shù)據(jù)集市Data Mart層。

像上面提到的數(shù)據(jù)倉庫建模是使用Kimball的維度建模方式，基本上要做到公共指標(biāo)下沉和基本的維度和指標(biāo)邏輯關(guān)聯(lián)關(guān)系。不管從哪些角度分析，前端引用這些維度和事實表指標(biāo)的時候都不需要做太多數(shù)據(jù)處理，就直接可以拿出來分析，達(dá)到分析維度和指標(biāo)的高度可復(fù)用性，這個就是商業(yè)智能BI的后端建模。

商業(yè)智能BI的后端建模做的好，前端BI可視化分析工具在連接到數(shù)據(jù)倉庫數(shù)據(jù)源的時候，基本上直接訪問這些維度和事實表就可以了，通過簡單的拖拉拽操作形成基本的星型或者雪花型分析模型，文本字段變成維度，數(shù)值類型變成度量，這樣就可以快速的選擇相應(yīng)的維度和度量（指標(biāo)）進(jìn)行組合，可視化圖表根據(jù)組合的結(jié)果就形成了各種各樣的分析結(jié)果。

商業(yè)智能BI項目架構(gòu)

所以，一個企業(yè)級的、完整的最佳實踐的BI項目架構(gòu)應(yīng)該是什么樣的？就是利用BI數(shù)據(jù)倉庫的建模，即后端建模將大部分的、標(biāo)準(zhǔn)的、高度可復(fù)用的分析模型預(yù)先設(shè)計好沉淀出來，形成標(biāo)準(zhǔn)的維度和事實表存儲起來。

之后再通過BI前端可視化分析工具來連接到數(shù)據(jù)倉庫數(shù)據(jù)庫，訪問這些可以構(gòu)成各種分析模型的表，進(jìn)行可視化分析。遇到特別的分析場景，底層數(shù)據(jù)倉庫的后端模型不能夠滿足分析場景需要的時候，就可以借助商業(yè)智能BI可視化工具的前端建模能力來擴(kuò)展一些分析模型，完成前端建模和可視化分析的工作。

但通常情況下，我們盡量要避免使用商業(yè)智能BI的前端建模，盡量使用商業(yè)智能BI后端建模的方式，前端直接基于已經(jīng)建好的模型拖拉拽做分析就可以了。為什么要避免商業(yè)智能BI的前端建模？之后的更新我們會來講一個新的概念，叫指標(biāo)爆炸。

好的，今天的分享就到這里，喜歡我們內(nèi)容的朋友，歡迎關(guān)注點贊收藏支持，謝謝大家。