作為公司的科技部門人員，經常聽到業務部門對自己使用的數據庫各種吐槽：

竟然存放在mongoDB中啊，震驚(ΩДΩ)。

數據庫慢慢熟悉了還好啊，但是現在每天的數據量越來越大，而且還在增加啊，增加大家很開心，然而數據庫并不開心啊，簡單的查詢統計10多分鐘還出不來結果，更不用說有稍微復雜點的統計分析了。

我天天找DBA優化啊，然而并沒有什么水花。

數據量還在不斷增長，到現在都上億啦，全量查詢統計根本出不來結果啊。

......

最終業務人員找到科技部門提需求要弄個BI系統給處理下。

對mongodb瞄了一大通，這就是個業務庫。那直接對接mongodb自然不行，速度慢不說，mongodb掛了，分析系統也癱了。自然就想到了使用中間庫，emmmysqloracle倒是有，可以跑調度抽過來，但是速度依舊不快呢，還要花功夫優化，性價比不高。公司有自己的hadoop平臺，將數據抽過來再對接倒是可以，但是要花很大精力跑調度，而且這個數據庫不能隨意給這個業務部門提供，萬一玩掛了可就得不償失。假設有個具備離線數據存儲功能的BI工具，豈不美哉。

于是將市面上有離線數據存儲功能的BI工具翻了個遍。期望找到個性能好，可以支持大數據量數據分析的BI工具。

Tableau的hyper功能看起來OK，經不起實際使用，數據量過了億，等了好久數據抽不好，pass；

其他某BI工具有mpp離線存儲，看起來很棒，還能橫向擴展，不錯。抱有最大期望的用，結果數據量一上億，直接崩了，崩了，pass；

另一個BI工具去看了看，咦，數據是放在vertica里面的......

后來，找到了FineBI的分布式計算引擎方案，拿的『定制的Alluxio』作為分布式內存存儲框架，內存存儲有數據安全性的擔心，所以持久化層存儲用了HDFS。為了數據分析嘛，自然是列式存儲的。計算核心則以熟知的Spark，加上自研算法來處理的。使用熟知的zookeeper整合框架，并用于調度通信。

分布式嘛，橫向擴展自然不在話下。而列式存儲、并行內存計算、計算本地化加上高性能算法，在FineBI中數據展示速度超快。有意思的是其計算本地化的操作，能減少不必要的shuffle，節省數據傳輸的消耗，提升數據計算速度。

以下記錄利用FineBI4.1工具的系統建設過程。

一、需求分析

針對以上的需求，可以預估到，18年內，常用分析預計最大數據量會達到4.7kw，不常用分析會達到3億到4億（包含淡季），數據總的體量最多會達到100G。后面的情況難以預估，就需要系統可橫向擴展節點。

二、方案描述

1.系統架構

根據官方推薦，將FineBI的web應用端與數據存儲的分布式引擎放在一個機器上（處于安全考慮，也可以分開。這里不涉及太多部門使用，放一起即可）