近期看到很多企業(yè)在設(shè)計(jì)自己的數(shù)據(jù)平臺(tái)，以及選型一些數(shù)據(jù)分析工具，正好拜讀了數(shù)據(jù)倉庫之父的《數(shù)據(jù)架構(gòu)：大數(shù)據(jù)、數(shù)據(jù)倉庫以及Data Vault》一書，有些許感觸，就來聊一下個(gè)人思考吧。

首先從企業(yè)信息化發(fā)展階段時(shí)，數(shù)據(jù)平臺(tái)結(jié)構(gòu)的程度來看。個(gè)人依照企業(yè)信息化，將數(shù)據(jù)平臺(tái)階段劃分為：只有業(yè)務(wù)數(shù)據(jù)庫——>中間庫——>完善數(shù)據(jù)倉庫(DW)——>數(shù)據(jù)集市(Data Mart)，順序與階段并不絕對(duì)正確，可能有組合，可能所在階段不完全一致。以下先看各個(gè)數(shù)據(jù)平臺(tái)階段特點(diǎn)，再看對(duì)應(yīng)階段數(shù)據(jù)分析工具選型的考慮吧。

1.業(yè)務(wù)數(shù)據(jù)庫

一個(gè)企業(yè)IT信息化建設(shè)最初的階段，業(yè)務(wù)庫中數(shù)據(jù)量不大，要分析展示下數(shù)據(jù)情況啦，不慌，問題不大，這時(shí)候OLTP結(jié)構(gòu)下也可以寫寫SQL快速展現(xiàn)，隨便玩玩office工具也沒問題。

但是隨著時(shí)間的推移，各種問題開始出現(xiàn)：

(1)查詢和寫入頻率越來越高，高頻write和和長時(shí)間read沖突越來越嚴(yán)重。而數(shù)據(jù)分析要耗費(fèi)大量計(jì)算資源，不能動(dòng)不動(dòng)掛業(yè)務(wù)系統(tǒng)吧。

(2)數(shù)據(jù)量越來越大，歷史業(yè)務(wù)數(shù)據(jù)啦，新業(yè)務(wù)數(shù)據(jù)激增啦，第一要?jiǎng)?wù)就是要解決業(yè)務(wù)應(yīng)用效率問題了，誰管數(shù)據(jù)分析里的問題呢。

(3)業(yè)務(wù)越來越多，表結(jié)構(gòu)越來越復(fù)雜。業(yè)務(wù)系統(tǒng)數(shù)量的越來越多，導(dǎo)致數(shù)據(jù)孤島開始形成。

這種情況下，企業(yè)面臨數(shù)據(jù)展示與數(shù)據(jù)平臺(tái)建設(shè)的階段了要怎么處理。這種情況下要做數(shù)據(jù)分析就麻煩了，要人為去各個(gè)系統(tǒng)取數(shù)，人力是一個(gè)方面。各個(gè)系統(tǒng)口徑命名啥都有差異，人為的處理出錯(cuò)率高就是另一方面。

2.中間庫

由于上述問題，就要引入中間庫來處理。左圖結(jié)構(gòu)解決了高頻write和read沖突問題，以及單數(shù)據(jù)庫服務(wù)器性能問題，順手也搞定了數(shù)據(jù)備份。這種情況下呢簡(jiǎn)單查詢還是可以的，但是在轉(zhuǎn)換聚合等需要多表關(guān)聯(lián)、以及大數(shù)據(jù)量等業(yè)務(wù)復(fù)雜度高的情況下，其處理性能就不容樂觀了。

此時(shí)就開始考慮可以利用空閑時(shí)間的服務(wù)器性能來做預(yù)先處理呢。右圖這種T+n的預(yù)處理離線計(jì)算的架構(gòu)就出現(xiàn)了，引入獨(dú)立的任務(wù)調(diào)度和計(jì)算引擎：計(jì)算壓力可以交給數(shù)據(jù)庫處理，也可交給ETL處理，展現(xiàn)性能初步解決。

但是這種情況下，數(shù)據(jù)庫表結(jié)構(gòu)實(shí)在太過復(fù)雜，每做一個(gè)分析，就要理一次業(yè)務(wù)邏輯、寫一段sql，還沒法進(jìn)行歷史追溯，以及數(shù)據(jù)整理成果的復(fù)用，so sad。

那有沒有理一次之后，后續(xù)能夠省點(diǎn)事的方式呢?這時(shí)候數(shù)倉的概念就可以使用上了。

3.完善數(shù)據(jù)倉庫(DW)

把業(yè)務(wù)庫數(shù)據(jù)整理成星型結(jié)構(gòu)，保證了事實(shí)的積累和維度的追溯。自由選擇需要的維度和相關(guān)事實(shí)進(jìn)行篩選計(jì)算，麻麻再也不用擔(dān)心每次寫sql都要去看“蜘蛛網(wǎng)”了。還有索引、結(jié)果表、分區(qū)分表等等黑科技來保證每次查旬需掃描的數(shù)據(jù)量最小，解決數(shù)據(jù)庫性能問題。

當(dāng)然這種架構(gòu)方式的缺點(diǎn)也很明顯，不是企業(yè)內(nèi)一致的數(shù)據(jù)(多系統(tǒng)，多主題數(shù)據(jù)不一致)，就會(huì)產(chǎn)生信息孤島。當(dāng)然，如果客戶企業(yè)就是很小，就一個(gè)系統(tǒng)，不用整合，一個(gè)數(shù)據(jù)集市足以的情況下采用這種方式也可以。常見情況是會(huì)在各個(gè)獨(dú)立的DW間建立一些對(duì)照表，可實(shí)現(xiàn)數(shù)據(jù)交換。如果多個(gè)DW間沒有物理隔絕，也可以形成EDW。

4.完善數(shù)倉+數(shù)據(jù)集市(Data Mart)

為了實(shí)現(xiàn)各個(gè)業(yè)務(wù)系統(tǒng)取數(shù)分析，或者做更多操作，就實(shí)現(xiàn)中心數(shù)據(jù)倉庫EDW從各個(gè)源系統(tǒng)收集數(shù)據(jù)，再將數(shù)據(jù)提供給各個(gè)數(shù)據(jù)集市和挖掘倉庫使用。這也被稱為企業(yè)信息工廠架構(gòu)(CIF)，一般情況下，大型企業(yè)會(huì)花費(fèi)許多精力實(shí)現(xiàn)這類架構(gòu)。

業(yè)務(wù)復(fù)雜度的提高與數(shù)據(jù)量級(jí)的增大以及對(duì)這些數(shù)據(jù)的應(yīng)用，促成了各個(gè)大數(shù)據(jù)平臺(tái)的繁榮，這個(gè)放到另一篇文章陳述。

無論是以什么架構(gòu)存在，數(shù)據(jù)展示的需求都必不可少。分析工具選擇必不可少，要在以上階段以一款工具涵蓋，那必然需要一款既可以做敏捷數(shù)據(jù)集市建模，又可以做數(shù)據(jù)展示分析的工具來處理。這種工具可對(duì)業(yè)務(wù)數(shù)據(jù)進(jìn)行簡(jiǎn)單、快速整合，實(shí)現(xiàn)敏捷建模節(jié)省時(shí)間，并且可以大幅度提升數(shù)據(jù)的展示速度，可對(duì)接前端的數(shù)據(jù)分析展示層，實(shí)現(xiàn)自由數(shù)據(jù)展示與OLAP分析，典型如各類BI分析工具。

數(shù)據(jù)分析也很考驗(yàn)分析工具數(shù)據(jù)讀取、運(yùn)算的性能，但擁有大數(shù)據(jù)量計(jì)算引擎的BI分析工具并不多。像FineBI與其高性能數(shù)據(jù)引擎在以上幾個(gè)階段均可在不同程度解決很多場(chǎng)景。

(1)業(yè)務(wù)數(shù)據(jù)庫階段，此階段已經(jīng)陳述過，重點(diǎn)問題就是計(jì)算性能影響大，以及數(shù)據(jù)孤島問題。建立數(shù)倉的過程相對(duì)敏捷數(shù)據(jù)集市而言，時(shí)間還是久的。這個(gè)時(shí)候就看看建立個(gè)常規(guī)意義的數(shù)倉和數(shù)據(jù)展示需求誰更緊急啦，或者可能有的也沒建數(shù)據(jù)平臺(tái)的意識(shí)也說不準(zhǔn)。此時(shí)快速的數(shù)據(jù)展示需求，就可以通過將數(shù)據(jù)放到FineBI的數(shù)據(jù)引擎中支撐實(shí)現(xiàn)。

(2)中間庫與完善數(shù)倉階段，此階段其實(shí)主要就是計(jì)算性能問題了，用戶的數(shù)據(jù)量級(jí)也一定挺大了。正好借助于FineBI的分布式引擎，完成數(shù)據(jù)加速計(jì)算工作。此引擎屬hadoop生態(tài)，核心計(jì)算引擎利用的spark，借助了alluxio作為內(nèi)存加速計(jì)算，處理了大數(shù)據(jù)計(jì)算問題，也很好闡釋了“大數(shù)據(jù)”。這個(gè)在接下來的文章中也會(huì)說到，這里先埋個(gè)伏筆，暫不贅述。

此階段呢，肯定有一些響應(yīng)時(shí)間要求較高的展示需求，多次作業(yè)同步可能帶來延遲影響。而FineBI的引擎擴(kuò)展了kettle的插件，實(shí)現(xiàn)數(shù)據(jù)可以直接load到引擎中，倒是將麻煩的作業(yè)處理工作解決了。

(3)完善數(shù)倉+數(shù)據(jù)集市階段，這種階段數(shù)據(jù)平臺(tái)建設(shè)已經(jīng)很完善了，各業(yè)務(wù)部門數(shù)據(jù)量級(jí)，業(yè)務(wù)復(fù)雜度都很高。

底層技術(shù)上雖然數(shù)據(jù)集市是建立在集成的中心數(shù)據(jù)倉庫EDW上，但是這些數(shù)據(jù)集市之間還是不能進(jìn)行數(shù)據(jù)交換的，大家建立的方法和ETL程序都會(huì)不同，各個(gè)數(shù)據(jù)集市之間的數(shù)據(jù)不見得的是一致，且平臺(tái)架構(gòu)超級(jí)復(fù)雜，擴(kuò)展以及再為各業(yè)務(wù)部門設(shè)計(jì)計(jì)算層結(jié)果表之類都相對(duì)麻煩。此時(shí)可考慮部分需整合數(shù)據(jù)放到敏捷數(shù)據(jù)集市處理，可直接對(duì)接的再直接對(duì)接處理。FineBI的引擎恰好都滿足這樣的場(chǎng)景需求，前端OLAP分析恰好也有，簡(jiǎn)單處理整合展示一站式解決。

在不久的將來，多智時(shí)代一定會(huì)徹底走入我們的生活，有興趣入行未來前沿產(chǎn)業(yè)的朋友，可以收藏多智時(shí)代，及時(shí)獲取人工智能、大數(shù)據(jù)、云計(jì)算和物聯(lián)網(wǎng)的入門知識(shí)和資訊信息，讓我們一起攜手，引領(lǐng)人工智能的未來