DuckDB窗口函数中列表聚合排序问题的分析与解决

在DuckDB数据库系统中，用户报告了一个关于窗口函数中列表聚合(list aggregate)行为不一致的问题。这个问题主要出现在处理小行组(parquet row groups)时，表现为结果中出现NULL值或无序列表，且问题在不同版本和硬件环境下表现不一。

问题现象

当使用窗口函数对数据进行列表聚合时，期望结果应该是一个有序的列表，且不应包含NULL值。然而在某些情况下，特别是当处理小行组的Parquet文件时，会出现以下两种异常情况：

1. 结果列表中出现NULL值
2. 聚合后的列表元素未按预期顺序排列

这个问题在DuckDB 1.0.0版本中不存在，但在1.2.0和1.2.1版本中出现，并且在1.2.1版本中表现更为严重。

问题根源

经过分析，这个问题与DuckDB的查询优化机制有关。具体来说：

1. 常量聚合优化问题：DuckDB使用了"常量聚合"优化技术，即对于每个分区只计算一次聚合结果。这个优化在处理有序聚合时存在缺陷。

2. 隐式排序传播不足：虽然聚合函数能够处理显式的ORDER BY参数，但没有正确传播窗口函数中的隐式排序要求。

3. 线程安全问题：问题的机器依赖性表明可能存在线程同步问题，特别是在并行处理小行组数据时。

解决方案

DuckDB开发团队通过以下方式解决了这个问题：

1. 修复常量聚合优化：确保在常量聚合优化中正确处理有序聚合的情况。

2. 显式处理隐式排序：修改代码使窗口函数中的隐式排序能够正确传播到聚合函数中。

3. 版本兼容性：修复同时适用于1.1.3及更高版本，包括对早期版本中列表聚合ORDER BY语法的支持。

使用建议

对于需要使用窗口函数进行列表聚合的场景，建议：

1. 使用最新版本的DuckDB(1.2.2及以上)以获得最稳定的行为。

2. 对于关键业务场景，可以显式指定排序方式，如使用list(value order by value)而不仅仅是list(value)，虽然这不是根本解决方案，但可以提高代码的明确性。

3. 当处理小数据集或需要精确控制并行度时，可以考虑调整DuckDB的并行处理设置。

技术细节

这个问题的修复涉及DuckDB查询执行引擎的多个层面：

1. 聚合处理器：对于不同的窗口框架(如UNBOUNDED PRECEDING TO CURRENT ROW vs UNBOUNDED PRECEDING TO UNBOUNDED FOLLOWING)，DuckDB使用不同的聚合处理技术(如段树)。

2. 排序传播：确保窗口函数中的ORDER BY子句能够正确影响聚合函数的行为，即使聚合函数本身没有显式指定排序。

3. 内存管理：优化了小行组数据处理时的内存分配和线程同步机制。

这个问题展示了数据库系统中查询优化与正确性之间的微妙平衡，也体现了DuckDB团队对这类边界条件的持续关注和改进。