用TPC-DS公平对比云数据引擎性价比

为什么厂商基准测试不可靠？

云厂商的基准测试通常经过精心优化，以展示其产品最佳性能。但问题在于，这些测试条件往往由厂商自己选择，可能使用特定数据布局、调整内存或缓存参数，甚至只展示有利的负载规模。对于大型数据团队，这种偏差会导致决策失误——不同团队用不同配置跑出的结果根本无法直接比较。

选择TPC-DS作为统一标准

TPC-DS是业界标准的决策支持基准，模拟零售场景，包含99个SQL查询，覆盖趋势分析、客户细分、报表等典型分析模式。选择它的关键原因是中立性：所有引擎必须处理相同数据和查询，结果可重复。我在测试中使用了多个数据规模（如1GB、10GB、100GB），因为引擎性能随数据量变化显著——小数据上表现好的引擎可能在大数据下成本飙升。

测试方法：确保公平性

1. 数据存储：所有引擎使用外部列式存储（如Parquet），避免引擎自带格式带来的偏差。
2. 查询执行：逐条运行查询，而非并发，减少资源竞争干扰。
3. 重复测试：每个查询重复多次，取中位数或平均值，降低随机波动影响。
4. 保持配置一致：不针对特定引擎调优，使用默认配置或明确记录的参数。

价格性能比：不只是速度

单纯比较运行时间会误导决策。云环境下成本至关重要，我采用价格性能比 = 总运行时间 × 单位时间成本。例如，引擎A运行快但每小时费用高，可能不如稍慢但便宜一半的引擎B。这种计算方式让工程和财务团队能基于同一标准对话，避免"快但贵"或"慢但省"的争论。

实际应用建议

• 适用场景：适合需要评估多个云数据仓库（如Snowflake、Redshift、BigQuery）或数据湖引擎（如Presto、Spark）的团队。
• 实施步骤：先确定业务典型查询集（可参考TPC-DS查询），再按上述方法测试，最后计算性价比并考虑扩展性。
• 注意事项：不要忽略数据加载和转换时间，它们也影响总体成本。

结论

TPC-DS不是完美基准，但它的标准化特性让跨引擎比较变得可信。通过记录数据规模、查询集和成本模型，你可以获得一个可重复的评估框架，帮助做出基于数据而非幻灯片的技术选型。