Azure Databricks中UNION ALL合并数据集后记录异常过滤问题

核心矛盾点 #

你在Azure Databricks无服务器Notebook里碰到的问题有几个关键特征：

• 两张schema完全一致的表用UNION ALL合并后，SELECT COUNT(*)能算出971,198条符合日期过滤条件的记录，但**SELECT *只返回6,092条**；
• 只要去掉最后12列，SELECT *就能返回全部971,198条记录；
• 试过处理NULL、显式CAST列类型，问题还是没解决。

大概率的原因 #

结合Databricks无服务器的特性和你给出的列类型信息，问题可能出在这几个地方：

1. 无服务器模式的序列化/传输限制
   无服务器Notebook在返回包含大精度decimal（比如col36 decimal(38,2)）、timestamp、长字符串的多列结果时，可能存在隐性的序列化或传输瓶颈。COUNT(*)只统计行数，不需要序列化整行数据，所以结果正常；但SELECT *要把每一列的数据都序列化返回，一旦某行里有无法正常序列化的值（比如超大decimal数、带特殊控制字符的字符串），这行就会被直接丢弃，最终返回的有效行数骤减。

2. 隐性的存储层数据类型不兼容
   虽然你确认两张表的schema完全匹配，但某些列可能在实际存储时有细微差异：

• 比如col31 timestamp：一张表的timestamp带时区，另一张不带？表面schema显示都是timestamp，但实际存储格式不一样，合并后部分行的timestamp列解析失败；
• 比如col36 decimal(38,2)：这是Databricks支持的最大精度decimal，如果某张表中该列存在超出精度的隐性值（比如导入时没严格校验），合并后会导致该行无法正常返回。

3. 查询优化器的异常逻辑
   无服务器模式的查询优化器在处理多列+NULL值的UNION ALL时，可能生成了错误的执行计划——比如错误地把日期过滤的谓词下推到单表扫描阶段，而且因为那12列的存在，过滤逻辑被误触发，导致只有部分行进入合并结果；但COUNT(*)的执行计划不依赖列数据，所以能正确统计所有符合条件的行。

排查和解决步骤 #

• 定位问题列：逐步把那12列添加到SELECT语句里，每次加1-2列就执行查询，看哪一列加进去后记录数突然变少，精准找到引发问题的列。
• 检查问题列的数据：针对定位到的列，分别查两张表的该列数据：
  • decimal列：看有没有超出精度的值，或者奇怪的NULL存储形式；
  • string列：检查是否包含换行、制表符这类特殊控制字符；
  • date/timestamp列：确认有没有无效的日期值（比如格式错误的字符串被存成date类型）。
• 换交互式集群验证：在普通交互式集群（不是无服务器）里跑相同的SELECT *查询，如果结果正常，说明是无服务器的特有限制，这时可以考虑拆分查询分批返回，或者把大精度decimal列截断（比如CAST(col36 AS decimal(30,2))）后再查。
• 对比执行计划：对包含和不包含那12列的查询分别执行EXPLAIN，看执行计划的差异：
  • 谓词下推的位置是不是不一样；
  • 数据扫描阶段有没有额外的过滤逻辑；
  • 合并结果后的处理步骤有没有差异。
• 用临时表替代CTE：把CTE改成临时表试试：

  CREATE OR REPLACE TEMP VIEW combined AS
  SELECT col1, col2, ..., col36 FROM catalog.schema.foo
  UNION ALL
  SELECT col1, col2, ..., col36 FROM catalog.schema.bar;
  
  SELECT * FROM combined WHERE DateCollected = '2025-10-27';
  

  如果临时表查询结果正常，说明是无服务器模式下CTE的优化问题，临时表可以绕过这个限制。

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