基於Hadoop架構下的FineBI大數據引擎技術原理

隨着各個業務系統的不斷增長，以及各業務系統數據量不斷激增，業務用戶的分析訴求愈來愈多且變化很快，IT數據支撐方的工做變得愈來愈複雜。

一、數據來自多個不一樣的系統，存在須要跨數據源分析，須要對接各類不一樣數據源等問題。

二、須要分析的數據體量愈來愈大，而且要快速得到分析結果的問題。

三、部分數據還須要二次加工處理的問題。

供數支撐方在業務系統的前端看起來基本沒有任何操做，但背後的邏輯十分複雜，實現難度也很大。就像看獲得的是冰山一角，看不到的是海水下絕大部分的支撐。

爲了解決日益激增的大數據量分析訴求，大部分公司會經過搭建Hadoop、Spark等大數據架構，配以BI工具作數據層面的分析，來搭建這樣一整套大數據分析平臺。

大數據分析很關鍵的一個點在於性能：取數快不快，分析響應快不快，可否實時？

這個問題除了平臺的底層架構，BI（商業智能）的運行性能也有很大相關。

你們可能廣泛認爲的BI，就是一個數據展示工具，在前端看起來沒有太多有技術含量的操做，但背後的邏輯十分複雜，實現難度也很大。就像看獲得的是冰山一角，看不到的是海水下絕大部分的支撐。

 

好的BI工具都有與之依賴的數據引擎，數據引擎的做用一方面是數據響應的性能（數據量、速率），還有很重要的一點是可否適應企業不一樣業務狀況的模式/方案。好比小數據快速讀取，大數據分佈式並行運算，節點數據實時展示等等.....

FineBI V5.0版本就是一個能夠支撐以上需求的工具，背後依賴的是Spider大數據引擎。

Spider高性能引擎能夠支撐10億量級數據在BI前端快速的拖拽分析和展現，且有高可用架構設計保證數據引擎整年可支撐業務分析。

Spider引擎的前世此生

爲何叫Spider引擎呢？聽起來很像爬蟲軟件，和數據分析又有什麼關係呢？

一則是字面翻譯過來的意思——蜘蛛，從蜘蛛就很容易聯想到結網。從結網的角度的看，有兩個含義，一是將以前已有的引擎功能所有聯結在一塊兒，由於5.0引擎實現了實時數據與抽取數據的對接與靈活切換；二是5.0數據引擎比較重要的分佈式模式，這種模式是由各個組件組合起來的架構，結網就是將這些組件聯結起來的意思。

二則是諧音法拉利的一款敞篷跑車。跑車嘛，速度快。這款跑車作了加長與加寬設計，使其更穩定，保持性能且更安全。剛好與咱們的數據引擎理念不謀而合。

所以，就取名Spider引擎。

再來講說它的發展史。

FineBI的數據引擎從起初作數據抽取的cube/FineIndex引擎，發展到後來開發了直連引擎/FineDirect引擎。再到2016年開發，17年到18年迅速擴展到60多家客戶使用的分佈式引擎。引擎功能與支撐數據量都在伴隨着時代的發展不斷進步。然而引擎類別繁多，用戶理解與使用都是問題。

所以，到v5.0版本，將引擎作了大一統，Spider引擎將以前全部引擎功能所有囊括其中，抽取數據與實時數據可互相切換，本地模式可根據數據量狀況擴展爲分佈式模式，使用與理解上都更加簡單了。

 

定位和亮點

Spider做爲數據引擎，在BI中使用中扮演着支撐數據分析的角色，強大的數據處理與計算能力爲前端的靈活快速應用分析提供強有力的支撐。

 

亮點：

（1）引擎支撐前端快速地展現分析，真正實現億級數據，秒級展現。

（2）用戶能夠根據數據量、實時性要求、使用頻次等，自由選擇實時或抽取的方式，靈活知足實時數據分析與大數據量歷史數據分析的需求。

（3）抽取數據的高性能增量更新功能，可知足多種數據更新場景，減小數據更新時間，減小數據庫服務器壓力。

（4）合理的引擎系統架構設計可保證整年無端障，整年可正常使用。

在數據源支持上，常規的數據源均可支持，無需擔憂數據源支持問題。

 

功能&優點

數據部分，能夠作到抽取數據或實時數據。能夠分爲三種模式，詳細解釋以下：

1. 本地模式（Local Mode）

Spider引擎的本地模式，能夠將數據抽取到本地磁盤中，以二進制文件形式存放，查詢計算時候多線程並行計算，徹底利用可用CPU資源。從而在小數據量狀況下，展現效果優異。與web應用放在一塊兒，十分輕量方便。

2.分佈式模式（Distributed Mode)

Spider引擎可靈活支撐不一樣數據量級的分析，在數據量激增以後，可橫向擴展機器節點，利用Spider引擎專爲支撐海量大數據分析而生的分佈式方案。

Spider引擎分佈式模式，結合HADOOP大數據處理思路，以最輕量級的架構實現大數據量高性能分析。此分佈式方案集成了ALLUXIO 、SPARK、 HDFS、ZOOKEEPER等大數據組件，結合自研高性能算法，列式存儲、並行內存計算、計算本地化加上高性能算法，解決大數據量分析問題以及在FineBI中快速展現的問題。同時從架構上保證了引擎系統整年可正常使用。

 

3.直連模式（Direct Mode）

Spider引擎的直連模式，能夠直接對接數據庫作實時大數據分析。將用戶在FineBI前端拖拽分析的操做，實時地轉化爲通過處理的查詢語言，實現對企業數據庫的數據進行實時分析的效果，在實時性要求較高，或數據庫計算性能優秀的狀況下，能夠採用這種模式，實現數據的實時查詢計算，且充分發揮數據庫計算性能。

直連模式的實時數據與本地模式以及分佈式模式下的抽取數據能夠靈活轉換，大量歷史數據使用抽取數據，實時性要求較高的數據使用實時數據，兩種方式的數據能夠在前端同一個DashBoard頁展現，便於用戶對數據靈活分析。

底層技術詳解

那底層詳細技術細節是怎樣的呢，可詳細看看下列的介紹：

1.列式數據存儲、字典壓縮

抽取數據的存儲是以列爲單位的， 同一列數據連續存儲，在查詢時能夠大幅下降I/O，提升查詢效率。而且連續存儲的列數據，具備更大的壓縮單元和數據類似性，能夠大幅提升壓縮效率。

 

列式數據存儲的基礎上，同一類數據的數據類型一致，相同值比例較高，將相同值取出來做爲字典，每一個列值直接存儲該值映射的索引便可，以後再作壓縮。這樣，數據壓縮比例大幅提高。以下是原始數據與抽取數據以後的大小對比狀況（數據備份係數是2份），能夠發現，小數據量狀況下，數據大小基本無差別；數據量越大，抽取後壓縮狀況越好，基本能夠達到抽取數據：原始數據=1:1.5的效果。

 

2.智能位圖索引

位圖索引即Bitmap索引，是處理大數據時加快過濾速度的一種常見技術，而且能夠利用位圖索引實現大數據量併發計算。

假設有如下的表：

 

進行以下的查詢：假設有以select下姓名 from table where 性別 = `男` and 教育程度 != `本科`

在沒有索引e狀況下c只能一行一行地進行掃描r判斷是否符合過濾條件d符合`加入結加集入結 們如今咱們將性別和教育程度中的值創建創建位圖索具體以下

 

 

其中的1表明在這一行是對應的值，不然即爲0。

由此，對於性別 = `男`這一過濾條件，咱們能夠快速取得「男」的位圖1010對於教育程度 != `本科`這一過濾條件，咱們能夠快速取得「本科」的位圖1001，而後進行取反操做0110最後，將兩個位圖進行按位AND操做，獲得最終位圖0010，其中只有第三行爲1，所以第三行就是咱們過濾出來的結果

位圖索引是一種典型的空間換時間的思想，因爲其空間佔用較大而數據結構簡單易壓縮，所以作了優化壓縮，使得數據的壓縮作到上述展現的效果。

3.分頁引擎

除上述智能位圖索引，咱們時常會遇到超大分組（返回結果集百萬行以上），雖然在咱們的前端分析展現時，一次性的操做不須要看到這麼大量級的數據。然而在業務分析時候，雖然不需全量一次性加載展現，然而老是有用戶會但願看到一些彙總後內容，以後再作出判斷決定下一步的分析操做。所以一款面向各類類別業務分析師的數據分析工具，必需要能支持這種分析場景。

在分頁引擎誕生以前，類數據庫的流式引擎處理大分組一直是一個難題：

對於select A, B, C, sum(V) group by A, B, C(返回結果行百萬以上)的查詢

一方面，基於HashMap的分組計算，在分組逐漸變大的同時，HashMap的訪問效率也會不斷降低。另外一方面，聚合後返回的數據至關大，加大了序列化和reduce的消耗，過大的結果數據集也會增長內存的壓力。

引入基於樹結構的分頁引擎以後，實現父子節點之間的關係能夠被快速計算出來，關係維護構建成功以後，每一個節點就有各自對應的位圖索引，分別遍歷便可得到計算結果。使得大分組計算再也不是難題。以下圖中是100W大分組之下的展現性能（都是首次計算返回時間，排除緩存因素），單位是s，能夠看到Spider引擎的計算時間基本都在3s左右。相同場能夠看到MPP數據庫的效果。再對比某敏捷BI的數據集市狀況以下所示，其中沒有數據的場景是該產品不支持的功能或者產品崩潰致使沒法記錄測試時長。

 

4.異步數據導入

數據抽取導入的過程當中，JDBC作數據抽取的時候就開始執行數據壓縮工做，壓縮工做不會阻礙抽數的動做。壓縮的時候，數據的分片處理使得所以壓縮量不會太大，資源佔用不多。同時獨立的壓縮線程在抽取的同時進行工做，並行處理減小數據抽取時間。結合數據存儲的優化，使得海量數據導入避免了OOM等性能問題。

下圖是一個100列，10億行數據表（其中不重複長字符串表超過1億行）的導入過程，將內存控制在4G如下，效果顯著（使用Jprofile記錄資源佔用狀況的截圖）。

 

5.分佈式文件存儲系統

Spider引擎比較重要的兩大模式（本地模式和分佈式模式）是要作數據抽取的，所以數據存儲介質就很重要了。小數據量的狀況下，爲了輕量方便使用，直接使用本地磁盤做爲存儲介質，數據與應用在一塊兒，沒有網絡傳輸時間。

在大數據量存儲上，就須要有廉價的存儲方式，能存儲非結構化數據，能作分佈式計算。那首先就想到Hadoop中的分佈式文件系統——HDFS。HDFS的穩定性以及容錯性機制都比較完善，Hadoop 2.X版本以後實現對HA的支持，可作到存儲數據整年可用。天然，其在大數據領域的生態也比較好的，所以咱們引入其做爲長期冗餘備份的存儲系統。

可是HDFS的存儲仍是基於磁盤的，其I/O性能難以知足流式計算所要求的延時，頻繁的網絡數據交換進一步拖累了計算處理過程。所以咱們引入Alluxio做爲分佈式存儲系統的核心存儲系統。Alluxio之內存爲中心的存儲特性使得上層應用的數據訪問速度比現有常規方案快幾個數量級。利用Alluxio的分層存儲特性，綜合使用了內存、SSD和磁盤多種存儲資源。經過Alluxio提供的LRU、LFU等緩存策略能夠保證熱數據一直保留在內存中，冷數據則被持久化到level 2甚至level 3的存儲設備上，最下層的HDFS做爲長期的文件持久化存儲系統。

6.數據本地化計算

分佈式計算是聯合多臺機器計算，那多臺機器就必然存在機器節點間的數據傳輸問題。爲了減小網絡傳輸的消耗，避免沒必要要的shuffle，利用Spark的調度機制實現數據本地化計算。就是在知道每一個執行任務所需數據位置的前提下，將任務分配到擁有計算數據的節點上，節省了數據傳輸的消耗，從而使得大量級數據計算速度也能達到秒出的效果。

 

7.智能緩存

智能緩存更可能是爲了直連模式（Direct Mode）的狀況下，系統也能有效支撐併發查詢。因爲直接對接數據庫，性能天然無可避免受到數據庫的限制。同時用戶分析查詢會存在針對相同數據查詢場景，所以引入encache框架作智能緩存，以及針對返回數據以後的操做有多級緩存和智能命中策略，避免重複緩存，從而大幅提高查詢性能。 以下是首次查詢與二次查詢的對比效果。