Malloy项目中DuckDB的row_number()函数问题分析与解决方案

问题背景

在Malloy项目中使用DuckDB作为查询引擎时，开发团队发现了一个关于row_number()窗口函数的异常行为。具体表现为在嵌套查询结构中，row_number()函数返回了预期范围之外的值。

问题复现

问题出现在一个关于航空设施数据的复杂查询中，查询结构包含多级嵌套：

1. 首先按FAA区域(faa_region)分组并计算设施数量
2. 然后为每组分配行号(id)
3. 接着按设施类型(fac_type)进行嵌套分组
4. 在嵌套分组中再次计算设施数量并为每行分配行号(id2)
5. 最后限制结果只返回前两条记录

按照设计，id2列应该只包含1或2这两个值（因为有限制条件limit: 2），但实际查询结果中却出现了其他数值。

技术分析

经过深入分析，发现问题根源在于DuckDB处理嵌套查询时窗口函数的行为。在原始SQL生成中，row_number()函数被应用到了所有分组集(group_set)上，而没有正确限定其作用范围。

具体来说，当使用CROSS JOIN结合GENERATE_SERIES生成多个分组集时，row_number()函数会在所有分组集上计算行号，而不仅仅是当前需要的那一层分组。

解决方案

开发团队提出了一个巧妙的解决方案：通过CASE语句限定row_number()函数的计算范围。具体实现是在计算id2时添加条件判断：

CASE WHEN group_set = 1 THEN 
  ROW_NUMBER() OVER(PARTITION BY group_set, base."faa_region" 
  ORDER BY CASE WHEN group_set=1 THEN COUNT(1) END desc NULLS LAST) 
END as "id2__1"

这种方法确保了row_number()函数只在特定的分组集(group_set=1)上执行计算，从而避免了跨分组集的干扰。

实现效果

修复后的查询能够正确返回预期的结果，id2列现在严格限制在1和2之间，符合limit 2的限制条件。这一修复不仅解决了当前问题，也为Malloy项目中类似复杂嵌套查询的窗口函数使用提供了参考方案。

经验总结

这个案例揭示了在使用DuckDB等分析型数据库时需要注意的几个关键点：

1. 窗口函数在复杂嵌套查询中的行为可能与预期不同
2. 多分组集查询需要特别注意函数的作用范围
3. 使用条件判断可以精确控制函数的计算范围
4. 在生成SQL时，查询引擎需要仔细处理嵌套结构中的计算逻辑

这一问题的解决也展示了Malloy团队对查询引擎行为的深入理解和快速响应能力，确保了项目的稳定性和可靠性。