我根据Cloudera文档1和2启用了Hive on Spark。现在，我发现减速器编号的行为异常。我希望有人能提供详细的文档或解释。
据我所知，Hive on MR根据数据量和hive.exec.reducers.bytes.per.reducer计算还原器数量，这意味着每个还原器进程的字节数，因此可以自动调整作业并行性。但是Hive on Spark似乎对该参数进行了不同的处理。尽管将其设置为非常低的数字（<1K）确实会增加减速机的数量，但是没有通用的规则可以应用于不同的作业。
以下是Cloudera tuning documentation for parallelism中的细分。
调整hive.exec.reducers.bytes.per.reducer以控制每个reducer处理多少数据，并且Hive根据可用的执行程序，执行程序内存设置以及为属性设置的值来确定最佳分区数，以及其他因素。实验表明，只要生成足够多的任务以使所有可用执行者保持忙碌状态，Spark对您为hive.exec.reducers.bytes.per.reducer指定的值的敏感性就不如MapReduce
我还了解到，当内存不足时，Spark中的RDD会在磁盘上溢出数据。如果是这样，Hive在Spark作业上发出的以下错误消息确实使我感到困惑。
Job aborted due to stage failure: Task 0 in stage 7.0 failed 4 times, most recent failure: Lost task 0.3 in stage 7.0 (TID 146, fuxi-luoge-105, executor 34): ExecutorLostFailure (executor 34 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 6.2 GB of 6.0 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
答案 0 :(得分：0)
在Hive on Spark的上下文中，MR框架的传统映射器和化简器概念都转换为Spark执行者处理的任务。 HoS设计（HIVE-7292的pdf附件）提供了很好的深入说明。因此，如您引用的文档所述，hive.exec.reducers.bytes.per.reducer设置仅间接影响Spark中RDD分区的数量。
就您得到的错误而言，Spark确实从执行器的存储区域（由Spark“管理”的总内存的一部分）溢出了缓存的数据，而您的YARN容器用完了由于spark.yarn.executor.memoryOverhead设置所占用的“非托管”内存部分的利用率很高，因此无法存储。来自Spark configuration：
spark.executor.memoryOverhead
默认值：executorMemory * 0.10，最小值为 384（MB）
说明：每位执行者要分配的堆外内存量，以MiB为单位 除非另有规定。这是占事物的内存 如VM开销，内部字符串，其他本机开销等。 往往随着执行者的规模而增长（通常为6-10％）。这个选项是 目前在YARN和Kubernetes上受支持。