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.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秒的损耗,但内存消耗可能会有所减少)

    原文作者:spark
    原文地址: https://www.cnblogs.com/warmingsun/p/6950717.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞