基于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大数据引擎技术原理是什么的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！