Spark--insert overwrite插入目标表慢/读取orc表执行时间比较长解决

• 有个任务最近速度突然变的很慢，排查下来发现两个耗时的stage，其中一个比较有代表性（insert overwrite 比较慢），记录一下
  • 27min → 1.9min

一、问题

• 有个任务insert overwrite 的时候很慢，整整27min。。。。
• 查看 web ui
  • 分区数很少
  • 执行时间很长

stage：

stage详细：

• 说明该任务每个分区上的input比较大，单个task计算量较大甚至引起spill导致任务执行慢。

二、解决

• 如果任务读取的源数据是orc文件，建议设置一下参数，重试任务
  • 设置参数hive.exec.orc.split.strategy
    • 参数控制在读取ORC表时生成split的策略:
    • BI策略以文件为粒度进行split划分；
      • 由于读orc文件时默认按文件划分task(BI模式), 有数据倾斜的表（这里的数据倾斜指大量stripe存储于少数文件中）的情况并发可能不够, 影响执行效率. 可以改成ETL模式
    • ETL策略会将文件进行切分，多个stripe组成一个split；
      • 对于一些较大的ORC表，可能其footer（用于描述整个文件的基本信息、表结构信息、行数、各个字段的统计信息以及各个Stripe的信息）较大，ETL策略可能会导致其从hdfs拉取大量的数据来切分split，甚至会导致driver端OOM，因此这类表的读取建议使用BI策略。
    • HYBRID策略当文件的平均大小大于hadoop最大split值（默认256M）时使用ETL策略，否则使用BI策略。
  • spark.sql.files.maxPartitionBytes=128M是平台默认值，可适当减小该值
    • 增加spark的并行度

set hive.exec.orc.split.strategy=ETL;
set spark.sql.files.maxPartitionBytes=32M;

三、查看结果

四、拓展

• 这个case 其实还可以拓展到splill溢出的问题
• stage发生spill不是失败，只是task想要的内存量比较大，由于内存不足发生写磁盘，故发生spill任务一定会变慢。

--conf spark.executor.memory=32g
--conf spark.executor.cores=4