基于Hadoop架構(gòu)下的FineBI大數(shù)據(jù)引擎技術(shù)原理是什么

基于Hadoop架構(gòu)下的FineBI大數(shù)據(jù)引擎技術(shù)原理是什么，相信很多沒有經(jīng)驗(yàn)的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

隨著各個業(yè)務(wù)系統(tǒng)的不斷增加，以及各業(yè)務(wù)系統(tǒng)數(shù)據(jù)量不斷激增，業(yè)務(wù)用戶的分析訴求越來越多且變化很快，IT數(shù)據(jù)支撐方的工作變得越來越復(fù)雜。

1、數(shù)據(jù)來自多個不同的系統(tǒng)，存在需要跨數(shù)據(jù)源分析，需要對接各種不同數(shù)據(jù)源等問題。

2、需要分析的數(shù)據(jù)體量越來越大，并且要快速獲得分析結(jié)果的問題。

3、部分?jǐn)?shù)據(jù)還需要二次加工處理的問題。

供數(shù)支撐方在業(yè)務(wù)系統(tǒng)的前端看起來基本沒有任何操作，但背后的邏輯十分復(fù)雜，實(shí)現(xiàn)難度也很大。就像看得到的是冰山一角，看不到的是海水下絕大部分的支撐。

為了解決日益激增的大數(shù)據(jù)量分析訴求，大部分公司會通過搭建Hadoop、Spark等大數(shù)據(jù)架構(gòu)，配以BI工具做數(shù)據(jù)層面的分析，來搭建這樣一整套大數(shù)據(jù)分析平臺。

大數(shù)據(jù)分析很關(guān)鍵的一個點(diǎn)在于性能：取數(shù)快不快，分析響應(yīng)快不快，能否實(shí)時？

這個問題除了平臺的底層架構(gòu)，BI（商業(yè)智能）的運(yùn)行性能也有很大相關(guān)。

大家可能普遍認(rèn)為的BI，就是一個數(shù)據(jù)展現(xiàn)工具，在前端看起來沒有太多有技術(shù)含量的操作，但背后的邏輯十分復(fù)雜，實(shí)現(xiàn)難度也很大。就像看得到的是冰山一角，看不到的是海水下絕大部分的支撐。

好的BI工具都有與之依賴的數(shù)據(jù)引擎，數(shù)據(jù)引擎的作用一方面是數(shù)據(jù)響應(yīng)的性能（數(shù)據(jù)量、速率），還有很重要的一點(diǎn)是能否適應(yīng)企業(yè)不同業(yè)務(wù)情況的模式/方案。比如小數(shù)據(jù)快速讀取，大數(shù)據(jù)分布式并行運(yùn)算，節(jié)點(diǎn)數(shù)據(jù)實(shí)時展現(xiàn)等等.....

FineBI V5.0版本就是一個可以支撐以上需求的工具，背后依賴的是Spider大數(shù)據(jù)引擎。

Spider高性能引擎可以支撐10億量級數(shù)據(jù)在BI前端快速的拖拽分析和展示，且有高可用架構(gòu)設(shè)計(jì)保證數(shù)據(jù)引擎全年可支撐業(yè)務(wù)分析。

Spider引擎的前世今生

為什么叫Spider引擎呢？聽起來很像爬蟲軟件，和數(shù)據(jù)分析又有什么關(guān)系呢？

一則是字面翻譯過來的意思——蜘蛛，從蜘蛛就很容易聯(lián)想到結(jié)網(wǎng)。從結(jié)網(wǎng)的角度的看，有兩個含義，一是將之前已有的引擎功能全部聯(lián)結(jié)在一起，因?yàn)?.0引擎實(shí)現(xiàn)了實(shí)時數(shù)據(jù)與抽取數(shù)據(jù)的對接與靈活切換；二是5.0數(shù)據(jù)引擎比較重要的分布式模式，這種模式是由各個組件組合起來的架構(gòu)，結(jié)網(wǎng)就是將這些組件聯(lián)結(jié)起來的意思。

二則是諧音法拉利的一款敞篷跑車。跑車嘛，速度快。這款跑車做了加長與加寬設(shè)計(jì)，使其更穩(wěn)定，保持性能且更安全。恰好與我們的數(shù)據(jù)引擎理念不謀而合。

因此，就取名Spider引擎。

再來說說它的發(fā)展史。

FineBI的數(shù)據(jù)引擎從起初做數(shù)據(jù)抽取的cube/FineIndex引擎，發(fā)展到后來開發(fā)了直連引擎/FineDirect引擎。再到2016年開發(fā)，17年到18年迅速擴(kuò)展到60多家客戶使用的分布式引擎。引擎功能與支撐數(shù)據(jù)量都在伴隨著時代的發(fā)展不斷進(jìn)步。然而引擎類別繁多，用戶理解與使用都是問題。

因此，到v5.0版本，將引擎做了大一統(tǒng)，Spider引擎將之前所有引擎功能全部囊括其中，抽取數(shù)據(jù)與實(shí)時數(shù)據(jù)可互相切換，本地模式可根據(jù)數(shù)據(jù)量情況擴(kuò)展為分布式模式，使用與理解上都更加簡單了。

亮點(diǎn)：

（1）引擎支撐前端快速地展示分析，真正實(shí)現(xiàn)億級數(shù)據(jù)，秒級展示。

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

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

（4）合理的引擎系統(tǒng)架構(gòu)設(shè)計(jì)可保證全年無故障，全年可正常使用。

在數(shù)據(jù)源支持上，常規(guī)的數(shù)據(jù)源都可支持，無需擔(dān)心數(shù)據(jù)源支持問題。

3.直連模式（Direct Mode）

Spider引擎的直連模式，可以直接對接數(shù)據(jù)庫做實(shí)時大數(shù)據(jù)分析。將用戶在FineBI前端拖拽分析的操作，實(shí)時地轉(zhuǎn)化為經(jīng)過處理的查詢語言，實(shí)現(xiàn)對企業(yè)數(shù)據(jù)庫的數(shù)據(jù)進(jìn)行實(shí)時分析的效果，在實(shí)時性要求較高，或數(shù)據(jù)庫計(jì)算性能優(yōu)秀的情況下，可以采用這種模式，實(shí)現(xiàn)數(shù)據(jù)的實(shí)時查詢計(jì)算，且充分發(fā)揮數(shù)據(jù)庫計(jì)算性能。

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

底層技術(shù)詳解

那底層詳細(xì)技術(shù)細(xì)節(jié)是怎樣的呢，可詳細(xì)看看下列的介紹：

1.列式數(shù)據(jù)存儲、字典壓縮

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

2.智能位圖索引

位圖索引即Bitmap索引，是處理大數(shù)據(jù)時加快過濾速度的一種常見技術(shù)，并且可以利用位圖索引實(shí)現(xiàn)大數(shù)據(jù)量并發(fā)計(jì)算。

假設(shè)有以下的表：

4.異步數(shù)據(jù)導(dǎo)入

數(shù)據(jù)抽取導(dǎo)入的過程中，JDBC做數(shù)據(jù)抽取的時候就開始執(zhí)行數(shù)據(jù)壓縮工作，壓縮工作不會阻礙抽數(shù)的動作。壓縮的時候，數(shù)據(jù)的分片處理使得因此壓縮量不會太大，資源占用很少。同時獨(dú)立的壓縮線程在抽取的同時進(jìn)行工作，并行處理減少數(shù)據(jù)抽取時間。結(jié)合數(shù)據(jù)存儲的優(yōu)化，使得海量數(shù)據(jù)導(dǎo)入避免了OOM等性能問題。

下圖是一個100列，10億行數(shù)據(jù)表（其中不重復(fù)長字符串表超過1億行）的導(dǎo)入過程，將內(nèi)存控制在4G以下，效果顯著（使用Jprofile記錄資源占用情況的截圖）。

5.分布式文件存儲系統(tǒng)

Spider引擎比較重要的兩大模式（本地模式和分布式模式）是要做數(shù)據(jù)抽取的，因此數(shù)據(jù)存儲介質(zhì)就很重要了。小數(shù)據(jù)量的情況下，為了輕量方便使用，直接使用本地磁盤作為存儲介質(zhì)，數(shù)據(jù)與應(yīng)用在一起，沒有網(wǎng)絡(luò)傳輸時間。

在大數(shù)據(jù)量存儲上，就需要有廉價的存儲方式，能存儲非結(jié)構(gòu)化數(shù)據(jù)，能做分布式計(jì)算。那首先就想到Hadoop中的分布式文件系統(tǒng)——HDFS。HDFS的穩(wěn)定性以及容錯性機(jī)制都比較完善，Hadoop 2.X版本之后實(shí)現(xiàn)對HA的支持，可做到存儲數(shù)據(jù)全年可用。自然，其在大數(shù)據(jù)領(lǐng)域的生態(tài)也比較好的，因此我們引入其作為長期冗余備份的存儲系統(tǒng)。

但是HDFS的存儲還是基于磁盤的，其I/O性能難以滿足流式計(jì)算所要求的延時，頻繁的網(wǎng)絡(luò)數(shù)據(jù)交換進(jìn)一步拖累了計(jì)算處理過程。因此我們引入Alluxio作為分布式存儲系統(tǒng)的核心存儲系統(tǒng)。Alluxio以內(nèi)存為中心的存儲特性使得上層應(yīng)用的數(shù)據(jù)訪問速度比現(xiàn)有常規(guī)方案快幾個數(shù)量級。利用Alluxio的分層存儲特性，綜合使用了內(nèi)存、SSD和磁盤多種存儲資源。通過Alluxio提供的LRU、LFU等緩存策略可以保證熱數(shù)據(jù)一直保留在內(nèi)存中，冷數(shù)據(jù)則被持久化到level 2甚至level 3的存儲設(shè)備上，最下層的HDFS作為長期的文件持久化存儲系統(tǒng)。

6.數(shù)據(jù)本地化計(jì)算

分布式計(jì)算是聯(lián)合多臺機(jī)器計(jì)算，那多臺機(jī)器就必然存在機(jī)器節(jié)點(diǎn)間的數(shù)據(jù)傳輸問題。為了減少網(wǎng)絡(luò)傳輸?shù)南?，避免不必要的shuffle，利用Spark的調(diào)度機(jī)制實(shí)現(xiàn)數(shù)據(jù)本地化計(jì)算。就是在知道每個執(zhí)行任務(wù)所需數(shù)據(jù)位置的前提下，將任務(wù)分配到擁有計(jì)算數(shù)據(jù)的節(jié)點(diǎn)上，節(jié)省了數(shù)據(jù)傳輸?shù)南?，從而使得大量級?shù)據(jù)計(jì)算速度也能達(dá)到秒出的效果。

7.智能緩存

智能緩存更多是為了直連模式（Direct Mode）的情況下，系統(tǒng)也能有效支撐并發(fā)查詢。由于直接對接數(shù)據(jù)庫，性能自然無可避免受到數(shù)據(jù)庫的限制。同時用戶分析查詢會存在針對相同數(shù)據(jù)查詢場景，因此引入encache框架做智能緩存，以及針對返回?cái)?shù)據(jù)之后的操作有多級緩存和智能命中策略，避免重復(fù)緩存，從而大幅提升查詢性能。 如下是首次查詢與二次查詢的對比效果。

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