Presto项目中TPCH连接器数据生成差异问题分析

在Presto数据库项目中，TPCH连接器在Java实现和Prestissimo实现之间存在数据生成差异的问题。本文将深入分析这一问题的根源、影响范围以及解决方案。

问题现象

当执行特定查询时，Java实现的TPCH连接器和Prestissimo实现返回了不同的结果。以查询select l_quantity, l_orderkey from tpch.sf1.lineitem where l_orderkey = 321030为例：

Java实现返回：

0.04 | 321030
0.17 | 321030
0.04 | 321030
0.04 | 321030
0.48 | 321030

而Prestissimo实现返回：

4.0 | 321030
17.0 | 321030
4.0 | 321030
4.0 | 321030
48.0 | 321030

问题根源

经过技术团队深入调查，发现这一差异源于数据生成阶段的实现问题。具体来说：

1. 数据类型处理差异：Prestissimo实现中使用的decimalToDouble函数在处理小数时存在精度转换问题，导致数值被放大了100倍。

2. 数据生成工具差异：Presto Java实现使用的是符合TPCH规范的数据生成器，而Prestissimo实现基于Velox的TPCH生成器，后者又依赖于DuckDB的dbgen工具。

3. 规范符合性问题：按照TPCH规范，l_quantity等列本应使用Decimal类型，但当前实现中使用了Double类型。

影响范围

这一问题不仅限于l_quantity列，还涉及多个方面：

1. 数据类型影响：主要影响Double/Decimal类型的列
2. 表范围影响：在lineitem表的多个列中都发现了类似问题
3. VARCHAR列问题：部分VARCHAR类型的列（如各种comment字段）也存在数据不一致
4. 规模因子影响：在tiny规模因子下问题更为明显

解决方案

技术团队已经采取了以下措施：

1. 核心数值修复：针对l_quantity列的问题，已提交修复PR，调整了decimalToDouble的实现逻辑，确保与Java实现一致。

2. 后续规划：

   • 对VARCHAR列的问题将单独处理
   • 考虑增强DuckDB的dbgen工具以支持tiny规模因子
   • 研究是否应将Double类型改为Decimal类型以符合规范

技术启示

这一问题给分布式查询引擎的开发提供了几个重要启示：

1. 规范一致性：即使遵循同一规范，不同实现间的细节差异也可能导致问题
2. 测试验证：需要建立更完善的数据验证机制，确保不同实现间的数据一致性
3. 工具链依赖：依赖第三方工具时需要充分验证其与规范的符合性
4. 类型系统设计：应仔细考虑类型选择，特别是数值精度敏感的场景

通过解决这一问题，Presto项目在数据一致性方面又向前迈进了一步，为后续的多引擎协同工作奠定了更坚实的基础。