|
Spider作为数据引擎，在FineBI5.0中扮演着支撑数据分析的角色，强大的数据处理与计算能力为前端的灵活快速应用分析提供强有力的支撑。
一.引擎的三种模式
数据部分，可以做到抽取数据或实时数据。可以分为三种模式，详细解释如下：
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 教育程度 != `本科`
在没有索引的情况下，只能一行一行地进行扫描，判断是否符合过滤条件，符合的加入结果集
现在我们将性别和教育程度中的值建立位图索引，具体如下：
其中的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框架做智能缓存，以及针对返回数据之后的操作有多级缓存和智能命中策略，避免重复缓存，从而大幅提升查询性能。 如下是首次查询与二次查询的对比效果。
| 
