hive中shuffle 与 spark shuffle 中的异同

由于目前的项目有强制的资源限制，hive任务不能满足要求，需要将hiveSQL 改成spark 的scala脚本运行，但是再过程中遇到了很多坑，这里记录一下可能涉及到的原理问题。

由于hive SQL 是使用SQL实现，再逻辑非常复杂的情况下，只能将任务分成多个阶段，同时尽量减少job数 来提高效率。在这种情况下，有可能出现复算以及计算无效数据的情况，需要衡量计算无效数据的效率以及避免计算而出现的额外job所花费的时间开销。

当数据量较大的时候（我的任务是千万亿级）的任务，我的建议还是尽量减少job数，开启mr任务的时间开销以及合并文件，统计等时间开销非常大。

由于是第一次接触spark 以及 scala，最开始使用Dataframe 将hiveSql直接照搬下来，但是发现以前可以跑通的sql 再spark下总是会出现 lost shuffle 0 等异常。查询之后发现是shuffle write 以及 shuffle read 数据量非常大。

之后根据业务逻辑使用java rdd 进行部分步骤的处理，尽量减少shuffle过程，情况有所好转，但是还是感觉spark非常的不稳定。由于分布式数据处理不可避免的会出现shuffle问题。因此对于hive的shuffle以及spark的shuffle，进行了简单的研究。

首先是Hive 的shuffle 过程

hive任务本质是将sql优化成map reduce 任务进行处理，因此shuffle过程就是mr任务的shuffle 过程，而shuffle的过程主要是将数据从 map task端拉往 reduce task 端。

1. 在跨节点拉取数据时，尽量减少对带宽的不必要消耗，同时减少磁盘io对task执行的影响。
2. 买一个map task 都有一个内存缓冲区，存储着map的输出结果，当该缓冲区快要写满时（默认配置为0.8）将之前已有的80%缓冲区锁定，将该部分以临时文件的形式写入磁盘 ，同时新的输出结果存入剩余的20%缓冲区。因此，在整个map task执行过程中，一个节点可能出现很多临时文件，在map task 执行