隨著各個業務系統的不斷增加，以及各業務系統資料量不斷激增，業務使用者的分析訴求越來越多且變化很快，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~

戳進去了解更多