发表于9小时前| 次阅读| 来源Cloudera| 0 条评论| 作者Sandy Ryza and Saisai (Jerry) Shao 区别常见的Embarrassingly Parallel系统，类似MapReduce和Apache Spark（Apache Hadoop的下一代数据处理引擎）这样的计算引擎主要区别在于对“all-to-all” 操作的支持上。和许多分布式引擎一样，MapReduce和Spark的操作通常针对的是被分片数据集的子分片，很多操作每次只处理单个数据节点，同时这些操作所涉及到的数据往往都只存在于这个数据片内。all-to-all操作必须将数据集看作一个整体，而每个输出结果都可以总结自不同分片上的记录。Spark的groupByKey、sortByKey，还有reduceByKey这些shuffle功能都属于这方面常见的操作。 在这些分布式计算引擎中，shuffle指的是在一个all-to-all操作中将数据再分割和聚合的操作。显而易见，在实践生产中，我们在Spark部署时所发现的大多性能、可扩展性及稳定性问题都是在shuffle过程中产生的。 Spark目前的运作实现模式 MapReduce和Spark的shuffle都使用到了“pull”模式。在每个map任务中，数据被写入本地磁盘，然后在reduce任务中会远程请求读取这些数据。由于shuffle使用的是all-to-all模式，任何map任务输出的记录组都可能用于任意reduce。一个job在map时的shuffle操作基于以下原则：所有用于同一个reduce操作的结果都会被写入到相邻的组别中，以便获取数据时更为简单。 Spark默认的shuffle实现（即hash-based shuffle）是map阶段为每个reduce任务单独打开一个文件，这种操作胜在简单，但实际中却有一些问题，比如说实现时Spark必须维持大量的内存消耗，或者造成大量的随机磁盘I/O。此外，如果M和R分别代表着一个shuffle操作中的map和reduce数量，则hash-based shuffle需要产生总共M*R个数量的临时文件，Shuffle consolidation将这个数量减至C*R个（这里的C代表的是同时能够运行的map任务数量），但即便是经过这样的修改之后，在运行的reducer数量过多时
Read full article from 双倍提升Apache Spark排序性能-CSDN.NET
No comments:
Post a Comment