我面临一个独特的问题，希望在这里提出您的意见。
我有一个传统的map-reduce应用程序，其中多个map-reduce作业按顺序运行，中间数据来回写入HDFS。由于向HDFS写入了中间数据，因此具有小数据的作业所损失的不仅仅是获得HDFS功能所带来的 yield ，而且所花费的时间也要比非Hadoop所花费的时间要多得多。最终，我计划将我所有的 map 缩小工作转换为Spark DAG，但这是一个巨大的变化，因此我很拖延。
作为短期解决方案，我真正想要的是更改存储层，以使我继续受益于map-reduce并行性，但不必为存储层付出太多代价。在这个方向上，我正在考虑将Spark用作存储层，其中map-reduce作业将通过Spark Context将其输出存储在Spark中，并且将再次读取输入(通过创建Spark输入拆分，每个拆分将拥有自己的Spark上下文中的Spark RDD)。
这样，我将能够以内存速度进行中间数据读/写操作，从理论上讲，这将大大提高我的性能。
我的问题是，这种架构方案有意义吗？有没有人遇到过这样的情况？我是否遗漏了一些重要的东西，即使在解决方案的这个初始阶段我也应该考虑？
提前致谢!
最佳答案
没有。 Spark没有独立的存储层，因此您无法在此处使用任何内容。如果它的核心还不够，那就是使用标准的Hadoop输入格式来读写数据。
如果要减少存储层的开销，则应该考虑加速加速存储(例如Alluxio)或内存网格(例如Ignite Hadoop Accelerator)。