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执行的影响