报错信息及解决方案

• 问题描述。
  • MaxCompute1.0不会进行除法常量折叠，在MaxCompute1.0中如下语句对应的物理执行计划如下：

    EXPLAIN
    SELECT IF(FALSE, 0/0, 1.0)
    FROM dual;
    In Task M1_Stg1:
        Data source: meta_dev.dual
        TS: alias: dual
            SEL: If(False, Divide(UDFToDouble(0), UDFToDouble(0)), 1.0)
                FS: output: None

    可以看出IF和Divide函数仍然保留，运行时因为IF第一个参数为FALSE，第二个参数Divide表达式不需要求值，所以不会出现除零异常。

  • MaxCompute2.0支持除法常量折叠，所以在MaxCompute2.0中如下语句会报错。

    SELECT IF(FALSE, 0/0, 1.0)
    FROM dual; 
    --报错
    FAILED: ODPS-0130071:[1,19] Semantic analysis exception - encounter runtime exception while evaluating function /, detailed message: DIVIDE func result NaN, two params are 0.000000 and 0.000000

  • 除了上述的问题，还可能遇到Overflow错误，如下所示。

    SELECT IF(FALSE, 1/0, 1.0)
    FROM dual; 
    --报错
    FAILED: ODPS-0130071:[1,19] Semantic analysis exception - encounter runtime exception while evaluating function /, detailed message: DIVIDE func result overflow, two params are 1.000000 and 0.000000

• 解决方案。

  建议去掉/0用法，换成合法常量。

• 问题描述。
  CASE WHEN常量折叠也有类似问题，例如CASE WHEN TRUE THEN 0 ELSE 0/0语句，在MaxCompute2.0中常量折叠时所有子表达式都会求值，导致除0错误。CASE WHEN可能涉及如下更复杂的优化场景。

  SELECT CASE WHEN key = 0 THEN 0 ELSE 1/key END
  FROM (
  SELECT 0 AS key FROM src
  UNION ALL
  SELECT key FROM src) r;

  优化器会将除法下推到子查询中，转换成类似如下命令，运行后报错。

  SELECT c1 END
  FROM (
  SELECT CASE WHEN 0 = 0 THEN 0 ELSE 1/0 END c1 FROM src
  UNION ALL
  SELECT CASE WHEN key = 0 THEN 0 ELSE 1/key END c1 FROM src) r;
  -- 报错
  FAILED: ODPS-0130071:[0,0] Semantic analysis exception - physical plan generation failed: java.lang.ArithmeticException: DIVIDE func result overflow, two params are 1.000000 and 0.000000

  其中UNION ALL第一个子句常量折叠报错。
• 解决方案。
  建议将SQL中的CASE WHEN命令写到子查询中，并去掉/0用法和无用的CASE WHEN命令，如下所示。

  SELECT c1 END
  FROM (
  SELECT 0 c1 END FROM src
  UNION ALL
  SELECT CASE WHEN key = 0 THEN 0 ELSE 1/key END) r;

如果MapJoin不是期望行为，建议去掉MapJoin Hint。

建议避免STRING分区列和INT类型常量比较，将INT类型常量改成STRING类型。

建议根据需求，删除不存在的表。

建议在Having中尽量不要使用SELECT子句中新生成的列别名。

建议使用合法的分区值，MaxCompute分区值说明请参见表操作。

• 问题描述。

  select  * from fake_table where  partition_key = 20220702;

  在如上命令中，partition_key是fake_table表的String类型的分区列，但是在where语句中对partition_key和数字作比较，并且partition_key的值不是数字类型，会报如下错误。

  Illegal type cast - in function cast, value '2020-01-01 01:01:01' cannot be casted from String to Double

  在partition_key和20220702比较过程中会将这两个值用cast转换成Double类型再做比较，而partition_key中的一些值没有办法从String转换为Double的类型。
• 解决方案。
  建议将分区列的比较值改为字符串，如下所示。

  select  * from fake_table where  partition_key = '20220702';

• 问题描述。

  select to_date(fake_date, 'yyyymmdd') from fake_table;

  在如上命令中，使用了to_date函数将fake_date列的字符串转换为日期类型，但是字符串的格式不正确，会报如下错误。

  string does not match datetime string - in function to_date, datetime string value is '' and format string is 'yyyymmdd'

  报错是因为空字符串没有办法按照yyyymmdd去解析而导致的。
• 解决方案。

  建议检查作为参数的列的值，避免函数出现格式异常。

• 问题描述。

  select REGEXP_EXTRACT(fake_string,'xxxx(.*?)',2) from fake_table;

  在如上命令中，使用了REGEXP_EXTRACT函数来提取字符串，但是由于正则表达式和后面的group id不匹配，会报如下错误。

  Argument value out of range - Regex group count is 1, but the specified group index is 2

• 解决方案。
  建议检查作为参数正则表达式和其他参数是否匹配，如下所示。

  select REGEXP_EXTRACT(fake_string,'xxxx(.*?)',1) from fake_table;

• 问题描述。

  select from_unixtime(fake_time/1000) from fake_table;

  在如上命令中，使用了from_unixtime，将Unix时间日期值转换为Datetime类型，但是由于换算错误，导致传入的值并不是秒数，数字过大不合法，会报如下错误。

  millisecond delta overflow, delta = 1648800491041000

• 解决方案。

  建议检查from_unixtime的参数是否换算出错导致过大。

检查group by子句并且删除重复的Key，重复的Key在实际运行中没有任何作用。

建议在UDF、UDTF、UDAF中指定Annotation并且重新实现Resolve方法。