本文为您介绍在生成物理执行计划阶段产生的编译耗时原因及处理措施。

问题现象

在生成作业的物理执行计划阶段，Logview中SubStatusHistory的状态为1235 SQLTask is splitting data sources或1240 SQLTask is generating execution plan。

编译耗时

产生原因&处理措施

产生该问题的可能原因及对应的处理措施如下。

产生原因描述处理措施
产生原因 描述 处理措施
读取的分区数量太多 MaxCompute在编译作业时，读取的每个分区都需要根据分区信息来决定处理方式，决定拆分的最小计算单元处理的数据量，并且会将这些编译信息写入作业对应的计算执行计划中，所以处理时长较长。 需要优化SQL，减少读取的分区数量。例如，通过分区裁剪方式筛除不需要读取的分区或将大作业拆分为多个小作业。
小文件太多 MaxCompute在编译作业时，会根据分区数据的文件大小决定拆分的最小计算单元处理的数据量，小文件过多会导致拆分过程耗时增加。产生小文件的原因主要有两个：
  • 使用Tunnel上传数据时，操作不正确。例如每上传一条数据就重新新建一个Upload Session。
  • 对分区表执行插入数据操作时，会在对应的分区表存储目录下生成一个新文件。
  • 使用TunnelBufferedWriter接口，可以更简单地完成上传，同时可以避免产生小文件。
  • 在项目空间下执行一次alter table tablename [partition] merge smallfiles;命令，MaxCompute会自动合并表下的小文件。
说明
“太多”指代的数量不是几十、几百个，实际要达到上万或十万级别，才会对生成物理执行计划的时间产生较大影响。