随着各个业务系统的不断增加，以及各业务系统数据量不断激增，业务用户的分析诉求越来越多且变化很快，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框架做智能缓存，以及针对返回数据之后的操作有多级缓存和智能命中策略，避免重复缓存，从而大幅提升查询性能。如下是首次查询与二次查询的对比效果。