Evidence项目处理全NULL日期列时出现Parquet文件损坏错误的分析与解决

问题背景

在使用Evidence项目进行数据源处理时，当查询结果中包含全部为NULL值的日期类型列时，系统会抛出"Parquet file is likely corrupted"的错误，导致整个构建过程失败。这个问题主要出现在使用MySQL数据源的情况下，但通过测试发现DuckDB连接器也存在类似问题。

错误现象

当执行npm run sources命令处理包含以下特征的查询时会出现错误：

• 查询结果中至少有一列的数据类型为日期(date)
• 该日期列的所有值都为NULL
• 数据量较大(测试案例中约12000行)

系统会抛出具体的错误信息："IO Error: Parquet file is likely corrupted, cannot have dictionary offsets without seeing a non-empty dictionary first."

技术分析

这个问题的根源在于Evidence内部使用的Parquet文件处理机制。Parquet作为一种列式存储格式，在处理字典编码时有一定的要求：

1. 字典编码机制：Parquet会对重复值较多的列使用字典编码来优化存储。对于日期类型列，通常会采用这种编码方式。

2. 全NULL列的特殊情况：当一列所有值都为NULL时，Parquet的字典编码器无法确定该列的数据类型特征，导致无法正确构建字典索引结构。

3. 日期类型的特殊性：日期类型在Parquet中有特定的编码方式，与其他数据类型相比有更严格的格式要求。当遇到全NULL列时，这种严格性可能导致编码过程失败。

复现步骤

1. 创建一个包含日期类型列的数据表
2. 确保该日期列的所有值都为NULL
3. 在Evidence项目中创建对应的源查询
4. 运行npm run sources命令处理该查询

测试用例(使用DuckDB连接器)：

select 
    *, 
    null::date as null_date
from orders

解决方案

对于这个问题的临时解决方案包括：

1. 修改查询语句：避免在结果集中返回全NULL的日期列
2. 数据类型转换：将日期类型转换为字符串类型后再处理
3. 默认值替换：使用COALESCE函数为NULL值提供默认日期值

长期来看，Evidence项目团队需要在其Parquet处理逻辑中增加对全NULL日期列的特殊处理，确保编码过程能够正常完成。

影响范围

这个问题主要影响以下场景：

• 使用MySQL数据源且包含全NULL日期列的情况
• 数据量较大的表(数千行以上)
• 使用日期类型(datetime/date)的列

其他数据类型或小规模数据可能不会触发此错误。

最佳实践建议

为避免此类问题，建议在数据建模阶段：

1. 为日期类型列设置合理的默认值，避免全NULL情况
2. 在ETL过程中对NULL值进行适当处理
3. 对于确实需要保留NULL语义的情况，考虑使用特殊标记值而非NULL

Evidence项目团队已确认此问题，并将在后续版本中提供修复方案。