将我们的数仓迁出 DuckDB

原文 ↗ Hacker News 讨论 ↗

PostHog 作为分析公司，频繁迁移数据库和数仓方案，引发了关于规划、可扩展性测试，以及 LLM 驱动的“轻松重写”对工程决策影响的质疑。评论者围绕 DuckDB、ClickHouse、Trino 以及数据湖/表格式在多租户、大规模工作负载中的适用性展开争论，同时批评 PostHog 关于迁出 DuckDB 的博客缺乏具体性能数据和清晰的技术论证。许多人认为，这种快速更换技术栈更像是简历驱动开发和薄弱架构纪律的表现，而不是经过严谨衡量的演进。

范围和架构说明

  • 这次变更涉及的是面向客户提供的数仓产品，而不是主分析数据库。
  • ClickHouse 仍然支撑核心分析；DuckDB 只是用于一个独立的、面向少量客户的试点数仓方案。
  • 新设计是基于 Trino 的分布式查询引擎，运行在自定义表格式（“HogLake”）之上，主要面向长时间运行的建模和 ETL，而不是低延迟查询。

DuckDB 的使用体验与扩展限制

  • DuckDB 在功能上可用，但为了处理真实客户查询，需要非常大的 Pod（大约 ~46 个 vCPU 和数百 GB 内存），其中一些查询会运行 12 小时以上。
  • 在多租户负载下（同一客户发出许多重查询），这种方案在经济上不可行。
  • 按查询估算 CPU/内存使用量很困难。文中提到 DuckDB 的客户端/服务器协议（Quack）并不支持真正的分布式查询。

选择 Trino + 类数据湖架构的原因

  • Trino 被认为能提供更灵活的分布式资源分配，更适合这种突发且重载的工作负载。
  • DuckDB 被赞为优秀的单机引擎，但在这种云环境、多租户场景下并不匹配。
  • Iceberg/Delta 也被评估过，但由于写入较慢以及其他对该用例不利的因素而被否决。

批评：规划、反复折腾与方法论

  • 很多评论者认为，短短几个月内从 ClickHouse → DuckDB → Trino/HogLake 的切换说明规划不佳或“反复折腾”，前期规模测试不足。
  • 有些人将其描述为简历驱动或“agent/LLM 驱动”的开发模式，即不断更换技术，而不是深入调优某一套方案。
  • 也有人为这种试验辩护，认为真实的大规模行为往往只有在自然产生的工作负载下才会显现。

希望看到更多技术细节和社区参与

  • 多位评论者希望看到关于容量预测和测试的具体指标、失败模式和方法论，并更清楚地解释为什么需要自定义格式。
  • 有人认为，在规模化场景下维护分支并把改进回馈上游是正常做法，并希望看到关于补丁和协作的更多细节。
  • 从讨论中仍不清楚新的 Trino/HogLake 方案是否已经彻底解决了原先的问题。

其他反应

  • 有人批评公司营销博客的风格和网站设计；也有人觉得它们很有辨识度或颇具吸引力。
  • 更广泛的话题还包括：在缺乏深厚专业知识时选择数据库的困难、领导层模式识别失误，以及频繁重写基础架构的风险。