基于Hadoop架構下的FineBI大數據引擎技術原理是什么

基于Hadoop架構下的FineBI大數據引擎技術原理是什么，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

隨著各個業務系統的不斷增加，以及各業務系統數據量不斷激增，業務用戶的分析訴求越來越多且變化很快，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引擎將之前所有引擎功能全部囊括其中，抽取數據與實時數據可互相切換，本地模式可根據數據量情況擴展為分布式模式，使用與理解上都更加簡單了。

亮點：

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

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

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

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

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

3.直連模式（Direct Mode）

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

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

底層技術詳解

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

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

抽取數據的存儲是以列為單位的， 同一列數據連續存儲，在查詢時可以大幅降低I/O，提高查詢效率。并且連續存儲的列數據，具有更大的壓縮單元和數據相似性，可以大幅提高壓縮效率。

2.智能位圖索引

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

假設有以下的表：

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框架做智能緩存，以及針對返回數據之后的操作有多級緩存和智能命中策略，避免重復緩存，從而大幅提升查詢性能。 如下是首次查詢與二次查詢的對比效果。

看完上述內容，你們掌握基于Hadoop架構下的FineBI大數據引擎技術原理是什么的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！