预期成果

当前以图搜图应用存在的问题：

1. 当前使用spark RDD方案无法达到数据实时加载（每10分钟加载一次，虽然可配，但太短可能会有问题）
2. Spark RDD内存会被分为两部分，一部分用来缓存数据一部分用来计算，Spark默认配置只有差不多50%的内存用于缓存（也就是说executor配了100G，只有50多G可以被用来做缓存），虽然比例可以进行配置，但增加缓存内存比例后，是否会影响计算性能有待测试。
3. 当前数据全缓存到spark jvm内存中，GC时间较长会导致影响计算性能
4. 当前加载的RDD只有自身context才能使用，无法做到应用间共享
5. 当driver端服务宕掉后，缓存的数据也会丢失
6. 期望能将增量数据加载时间缩小到足够小达到准实时，或者直接能够达到实时
7. 职责分明，缓存有分布式缓存做，Spark只负责计算
8. 缓存数据不占用Spark jvm内存，减少GC对计算的影响
9. 加载到内存的数据可以被其他应用使用
10. Driver端服务宕掉后，缓存数据不会丢失，其他driver段仍可使用
11. 采用新方案对比原方案，性能损耗尽可能小，最好达到无损耗

2       技术选型

根据上述问题和预期成果，期望选择一款与Spark结合较好的分布式内存缓存计算，从而将缓存工作从spark中抽离出来，让spark专注于计算。

2.1.1  Apache Ignite

Apache Ignite内存数据组织是高性能的、集成化的以及分布式的内存平台，他可以实时地在大数据集中执行事务和计算，和传统的基于磁盘或者闪存的技术相比，性能有数量级的提升。

选择预研该技术最大的原因为，Ignite实现了一个可共享的Spark RDD，可实现增量数据实时在比对中体现。

2.1.2  Alluxio（原Tachyon）

Alluxio在1.0版本后由原来的Tcahyon更名。Alluxio与Spark结合较好，Spark1.5后增加的缓存方式：OFF_HEAP（堆外缓存）当前只支持tachyon。

不过Alluxio和Spark RDD一样都不可变，缓存文件一旦写入就不能修改，且在完成写入之前缓存数据是无法读取的，这样就服务达到增量数据的实时性，但可以实现尽可能缩短增量加载时间来达到准实时性。

3       阶段性结论

性能测试采用上述两种技术三个版本（apache-ignite-fabric-1.5.0.final、alluxio-1.0.1、tachyon-0.7.1-hadoop2.6-build）八种方案:

1. 直接采用Spark RDD缓存，且缓存数据不做序列化
2. 直接采用Spark RDD缓存，缓存数据使用java序列化方式
3. 直接采用Spark RDD缓存，缓存数据使用kryo序列化方式
4. 采用Spark RDD OFF_HEAP模式（即缓存数据到tachyon），缓存数据使用java序列化方式
5. 采用Spark RDD OFF_HEAP模式（即缓存数据到tachyon），缓存数据使用kryo序列化方式
6. 使用tachyon缓存数据（调用saveAsObjectFile，直接将数据序列化成文件写到tachyon中），saveAsObjectFile使用java序列化方式
7. 使用Alluxio缓存数据（调用saveAsObjectFile，直接将数据序列化成文件写到Alluxio中），saveAsObjectFile使用java序列化方式
8. 使用ignite缓存数据，使用IgniteRDD进行统计

下面为三台256G内存集群，58727000条数据，Spark分配36核，测试结果如下：

缓存方式

内存配置

是否序列化

序列化实现

检索耗时(s)

内存空间(GB)

Spark RDD

executor:150GB*3

否

11.527

112.8

Spark RDD

executor:150GB*3

是

java

20.09

56.4

Spark RDD

executor:150GB*3

是

kryo

16.275

51.8

Spark RDD + tachyon

executor:20GB*3 tachyon:100GB*3

是

java

21.771

51.56

Spark RDD + tachyon

executor:20GB*3 tachyon:100GB*3

是

kryo

17.772

51.83

tachyon

executor:20GB*3 tachyon:100GB*3

是

java

32.719

53.03

Alluxio

executor:20GB*3 alluxio:100GB*3

是

java

26.988

53.03

ignite

executor:20GB*3 ignite:10GB*3(数据保存在堆外，不使用jvm内存)

是

java

333.228

由上表分析如下：

1. 检索耗时最短为方案一，直接缓存到spark jvm中且不做序列化，但该方案占用内存也较多(目前是其他方案的两倍)，不过当前以图搜图框架中数据结构采用map，所以较占内存
2. 方案一、二、三对比，采用序列化会有性能损耗，kryo序列化耗时是java序列化的1/2，与之前测试基本一致，采用kryo序列化112GB数据耗时4-5秒
3. 对比方案二、方案四以及方案三、方案五，从tachyon拉数据到spark进行计算耗时为1秒左右，但由于存储到tachyon必须序列化，所以得加上序列化的耗时，最少的性能损耗也差不多5-6秒
4. 直接调用saveAsObjectFile保存数据到tachyon或者Alluxio，性能损耗较大，分别为22秒和14秒，初步估计性能损耗由于：（1）saveAsObjectFile采用java序列化方式，性能损耗将近9秒；（2）saveAsObjectFile内部实现使用的是hadoop api，tachyon能够兼容这些api，但可能有部分性能损耗;（3）spark可能对tachyon存储做过一定优化
5. 由表格可以看出ignite结合spark性能很差，估计原因可能为：（1）可能修改某些配置后可以优化性能，但iginte资料非常少，特别是跟spark结合这块，基本没有什么资料；（2）ignite本身不单单包含存储功能，还有检索、计算等功能，所以它与spark本身也存在竞争关系

结论如下：

1. ignite如需优化性能需要深入源码，且没有对比数据，具体最后能到什么程度无法预估，且当前基本没有什么已知公司使用该技术与Spark结合

Alluxio（Tachyon）性能优化需要看Spark缓存代码，但是该方法最终能够达到的性能指标基本能够预估（较现有方案有5-6秒的损耗，但内存消耗可能会有所减少）