[[174642]]

對于傳統企業內部，更多的應該是使用了大數據技術的傳統BI平臺，或者是融合了傳統BI+大數據的混合平臺，而不能單純說是大數據平臺。在談大數據平臺的時候，一味去否定傳統BI是不合適的。

在沒有和互聯網打通的傳統企業內部，更多接觸的仍然是結構化數據，優先要解決的是圍繞企業核心價值鏈的數據建模和企業戰略，各業務域KPI體系的建立，決策支持和分析這些內容。在整個數據建模和分析過程中，還要考慮去解決數據不一致性，重復等問題，建立數據管控和治理體系。36大數據(http://www.36dsj.com/)

傳統BI平臺在發展過程中會遇到問題和瓶頸，使用傳統的技術架構無法解決，需要我們在傳統BI技術架構的構建中引入大數據相關技術和工具，從這意義上更多應該叫使用了大數據技術的傳統BI平臺。36大數據(http://www.36dsj.com/)

使用了大數據技術的傳統BI平臺

在數據存儲和查詢效率層面，傳統BI遇到瓶頸，可以看到在大量的上千萬即上億數據量的結構化數據表中，要進行查詢統計分析輸出KPI指標性能下降非常明顯。為了解決查詢效率問題，有兩個思路，一個是引入了MPP數據庫來解決，一個則是引入Hadoop平臺進行存儲，雖然是結構化數據但是仍然引入Hadoop平臺，重點是解決分布式存儲和查詢性能問題。36大數據(http://www.36dsj.com/)

其次，雖然傳統企業以結構化數據為主，但是仍然出現對大數據量的非結構化數據的采集和處理，這個時候我們可能引入了Hadoop平臺，將數據采集，清理存儲后最終還是再導入我們的結構化數據倉庫。可以看到在這個過程中大數據技術解決了對非結構化數據的處理和整合問題。36大數據(http://www.36dsj.com/)

融合傳統BI能力的大數據平臺

對于原來沒有規劃建設BI系統的企業，在構建BI系統的時候更多考慮的就是直接構建大數據平臺同時完全融合傳統BI應該具備的能力。即既保留了傳統BI，又實現了遠期對大數據平臺和應用的擴展能力。

數據采集層-》數據存儲層-》數據處理層-》數據整合層-》數據分析層-》數據展現層

數據采集：大數據在傳統ETL基礎上增加了對HDFS，非結構化數據，流數據，互聯網數據的支持能力

數據存儲：增加了HDFS，HBASE等數據存儲方式

數據處理：傳統BI在ETL過程中可以完成清洗，大數據平臺是存采集不處理，處理用單獨定制腳本。

數據整合：整合了結構化+非結構化數據，提供統一數據開放接口

數據分析：HIVE+Impala+Spark，大批量和即席交互查詢能力并存

數據展現：傳統的BI報表功能仍然適用，也可以引入大數據可視化技術

可以看到要融合傳統BI能力，則數據整合層需要能夠整合結構化數據和非結構化數據，同時提供統一的大數據開放能力服務接口。盡量讓前端報表通過大數據服務接口獲取數據以隔離底層大數據平臺的數據源。即數據展現層和數據整合層通過服務層進行解耦和隔離。

如果企業已有傳統BI平臺，那么底層的BI平臺可以共存，即可以將底層BI平臺的ODS庫或EDW數據導入到大數據平臺進行存儲和整合。大數據平臺存儲一定是混合存儲模式，即有些通過Hadoop平臺處理后的中間結果數據我們仍然導入到結構化數據庫進行存儲，遵從傳統BI數據建模技術構建星型模型，方便后續對數據進行維度分析和上鉆下鉆。對于self service BI，我們仍然開放Hadoop平臺原始數據接口能力。

一開始就構建大數據目標平臺

如果企業在構建平臺的時候，一開始目標就很明確是大數據類分析和應用，如采集海量的互聯網數據進行某行業的客戶行為分析，用戶畫像，同時結合企業內部經營數據進行針對性營銷的輔助決策。那么一開始構建就會以Hadoop平臺為主，同時兼容能夠采集企業已有的結構化數據。

這類平臺在構建過程中可以看到不會是傳統BI數據建模和分析那套方法，而更多是新的大數據分析和挖掘技術，則完全可能是以Impala+Hive+Hdfs為主線，以Tableau，Qlic View為前段展現，通過R語言或KNIME進行數據挖掘和分析等。即脫離傳統BI，大數據整套框架仍然是完整的。但是弱化了傳統BI中的數據建模，數據質量管理，數據治理等方面的能力。