Spark与缓存

预期成果

1.1   当前问题

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

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. 采用新方案对比原方案，性能损耗尽量小，最好达到无损耗

1.2   预期成果

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.一、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. 方案1、2、三对比，采用序列化会有性能损耗，kryo序列化耗时是java序列化的1/2，与以前测试基本一致，采用kryo序列化112GB数据耗时4-5秒
3. 对比方案2、方案四以及方案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秒的损耗，但内存消耗可能会有所减小）