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

首先從企業信息化發展階段時，數據平臺結構的程度來看。個人依照企業信息化，將數據平臺階段劃分為：只有業務數據庫——>中間庫——>完善數據倉庫（DW）——>數據集市（Data Mart），順序與階段并不絕對正確，可能有組合，可能所在階段不完全一致。以下先看各個數據平臺階段特點，再看對應階段數據分析工具選型的考慮吧。

1.業務數據庫

一個企業IT信息化建設最初的階段，業務庫中數據量不大，要分析展示下數據情況啦，不慌，問題不大，這時候OLTP結構下也可以寫寫SQL快速展現，隨便玩玩office工具也沒問題。

?

但是隨著時間的推移，各種問題開始出現：

（1）查詢和寫入頻率越來越高，高頻write和和長時間read沖突越來越嚴重。而數據分析要耗費大量計算資源，不能動不動掛業務系統吧。

（2）數據量越來越大，歷史業務數據啦，新業務數據激增啦，第一要務就是要解決業務應用效率問題了，誰管數據分析里的問題呢。

（3）業務越來越多，表結構越來越復雜。業務系統數量的越來越多，導致數據孤島開始形成。

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

2.中間庫

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

此時就開始考慮可以利用空閑時間的服務器性能來做預先處理呢。右圖這種T+n的預處理離線計算的架構就出現了，引入獨立的任務調度和計算引擎：計算壓力可以交給數據庫處理，也可交給ETL處理，展現性能初步解決。

?

但是這種情況下，數據庫表結構實在太過復雜，每做一個分析，就要理一次業務邏輯、寫一段sql，還沒法進行歷史追溯，以及數據整理成果的復用，so sad。

那有沒有理一次之后，后續能夠省點事的方式呢？這時候數倉的概念就可以使用上了。

3.完善數據倉庫（DW）

把業務庫數據整理成星型結構，保證了事實的積累和維度的追溯。自由選擇需要的維度和相關事實進行篩選計算，麻麻再也不用擔心每次寫sql都要去看“蜘蛛網”了。還有索引、結果表、分區分表等等黑科技來保證每次查旬需掃描的數據量最小，解決數據庫性能問題。

當然這種架構方式的缺點也很明顯，不是企業內一致的數據（多系統，多主題數據不一致），就會產生信息孤島。當然，如果客戶企業就是很小，就一個系統，不用整合，一個數據集市足以的情況下采用這種方式也可以。常見情況是會在各個獨立的DW間建立一些對照表，可實現數據交換。如果多個DW間沒有物理隔絕，也可以形成EDW。

?

4.完善數倉+數據集市（Data Mart）

為了實現各個業務系統取數分析，或者做更多操作，就實現中心數據倉庫EDW從各個源系統收集數據，再將數據提供給各個數據集市和挖掘倉庫使用。這也被稱為企業信息工廠架構（CIF），一般情況下，大型企業會花費許多精力實現這類架構。

?

業務復雜度的提高與數據量級的增大以及對這些數據的應用，促成了各個大數據平臺的繁榮，這個放到另一篇文章陳述。

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

數據分析也很考驗分析工具數據讀取、運算的性能，但擁有大數據量計算引擎的BI分析工具并不多。像FineBI（www.finebi.com）與其高性能數據引擎在以上幾個階段均可在不同程度解決很多場景。

（1）業務數據庫階段，此階段已經陳述過，重點問題就是計算性能影響大，以及數據孤島問題。建立數倉的過程相對敏捷數據集市而言，時間還是久的。這個時候就看看建立個常規意義的數倉和數據展示需求誰更緊急啦，或者可能有的也沒建數據平臺的意識也說不準。此時快速的數據展示需求，就可以通過將數據放到FineBI的數據引擎中支撐實現。

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

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

?

（3）完善數倉+數據集市階段，這種階段數據平臺建設已經很完善了，各業務部門數據量級，業務復雜度都很高。

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

總結

以上是生活随笔為你收集整理的如何选择高性能的数据分析工具，你需要看看数据架构的进化史！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。