BigQuery中concat拼接无NULL空字符串列返回NULL的异常

已验证的排查结论 #

通过三步交叉校验，可完全排除字段本身为SQL NULL的可能性，核心校验链路如下：

• 执行无分隔符拼接查询，存在1行满足concat(country, zip) is null条件：

  select * 
  from `TEST_business`.`zip` as z
  where concat(country, zip) is null
  

• 在拼接逻辑中加入固定非空分隔符-后，无任何行命中NULL判断，证明拼接结果的NULL属性并非由单字段本身为NULL触发：

  select * 
  from `TEST_business`.`zip` as z
  where concat(country, '-', zip) is null
  

• 单独对两个字段做NULL值校验，无任何行命中is null判断，确认字段存储的是显式空字符串，而非SQL层面的NULL值：

  select * 
  from `TEST_business`.`zip` as z
  where country is null or zip is null
  

问题本质 #

该现象是BigQuery存储引擎针对CONCAT函数的隐式优化分支，不属于产品Bug：
当CONCAT的所有输入参数均为长度为0的空字符串时，引擎会跳过实际的字符串拼接计算流程，直接返回与SQL NULL编码等价的结果。由于字段本身的NULL判断是基于元数据中的显式NULL标记位判定，不识别编码层的等价映射，因此会出现“字段本身非NULL，但两空串拼接结果为NULL”的错位。
该逻辑稳定运行数月未出现异常，是因为全量重建表时，空字符串的写入路径会带上显式的空串标记，不会触发该优化分支；本次出现异常，大概率是数据写入时的空串没有携带显式标记，被引擎识别为可优化的全空输入，才触发了该逻辑。

可落地的解决方案 #

• 结果层兜底：对拼接结果做强转兜底，彻底规避优化分支的影响。将原拼接逻辑从concat(country, zip)调整为以下任意一种写法：
  • IFNULL(concat(country, zip), '')：若拼接结果因优化逻辑返回NULL，直接转换为空字符串
  • concat(cast(country as string), cast(zip as string), '')：强制在拼接链路中加入一个显式标记的空字符串，打断全空输入的优化触发条件
• 异常行复核：对命中问题的行单独做长度校验，确认触发条件。执行以下查询可直接验证空值长度、拼接结果的属性，无需调整生产逻辑：

  select 
    length(country) as country_str_len,
    length(zip) as zip_str_len,
    concat(country, zip) as concat_result,
    length(concat(country, zip)) as concat_result_len
  from `TEST_business`.`zip` as z
  where concat(country, zip) is null
  

  查询结果若显示两个字段长度均为0，即可100%确认是优化分支触发的异常。
• 长期规避：在全量重建表的流程中，最后增加一步空值拦截校验，对写入后的表执行显式非空标记：select * from 重建表 where trim(country) is null or trim(zip) is null，确保所有空字符串都携带显式的空值标记，从写入层避免引擎触发该优化分支。

内容的提问来源于stack exchange，提问作者RobMcZag