隨著各個業務系統的不斷增加，以及各業務系統數據量不斷激增，業務用戶的分析訴求越來越多且變化很快，IT數據支撐方的工作變得越來越復雜。

1、數據來自多個不同的系統，存在需要跨數據源分析，需要對接各種不同數據源等問題。

2、需要分析的數據體量越來越大，并且要快速獲得分析結果的問題。

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

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

為了解決日益激增的大數據量分析訴求，大部分公司會通過搭建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框架做智能緩存，以及針對返回數據之后的操作有多級緩存和智能命中策略，避免重復緩存，從而大幅提升查詢性能。 如下是首次查詢與二次查詢的對比效果。

最后，整體方案還是基于FineBI的，感興趣的可以先戳↓↓↓體驗FineBI~

戳進去了解更多

總結

以上是生活随笔為你收集整理的基于Hadoop架构下的FineBI大数据引擎技术原理的全部內容，希望文章能夠幫你解決所遇到的問題。

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