DeepSeek总结的用Parquet从 ClickHouse 迁移至 CedarDB查询

原文地址：https://cedardb.com/blog/ski_parquet/

以 Parquet 为"滑雪缆车"：从 ClickHouse 迁移至 CedarDB

结合 Stack Overflow 数据集与 Parquet 格式，本文旨在阐明当查询复杂性超出 ClickHouse 能力范围时，迁移至 CedarDB 的过程是多么顺畅。

作者：Michael Goddard

CedarDB 新近支持的 Parquet 功能大幅简化了数据交换过程。
为何选择 Stack Overflow 数据集？
实验概览
我们将提出的问题
结果与观察
我的总结
附录：滑雪后的技术细节

CedarDB 新近支持的 Parquet 功能大幅简化了数据交换过程。

我最近在领英上发布的帖子（如下，有细微调整）促成了本文更深入的技术探讨：

近来的大雪又让我想起了滑雪（老生常谈了），也让我想到了数据和数据库。我读到一篇题为"使用 ClickHouse 分析 Stack Overflow 数据"的文章，觉得很有意思，特别是想到他们刚刚筹集了 4 亿美元。在实践了他们文章中的示例后，我意识到，尽管过程很有趣，但那里的 SQL 查询都非常简单。用滑雪的行话来说，我可能会把它们比作适合初学者的绿色雪道。

随着滑雪者水平的提高，他们会转向蓝色的中级雪道，然后可能会大胆地去尝试黑色钻石级别的雪道。这正是我使用 Stack Overflow 数据集后前进的方向。ClickHouse 提供了一个便捷的 Parquet 导出功能，我利用这个功能，结合 CedarDB 的 Parquet 导入功能，将在 ClickHouse 中使用过的数据集加载到了我的 CedarDB 实例中。我在我的 m7a.8xlarge（32 vCPU，128 GB RAM，每小时 1.85 美元）EC2 节点上，通过 Docker 分别部署了这两个数据库，并依次运行它们。通过与 ChatGPT 进行一些结对编程，我们共同设计了一组七个有趣的查询。我在每个数据库上运行这些查询，丢弃首次运行的时间，并记录了五次运行的平均耗时。

为何选择 Stack Overflow 数据集？

Stack Overflow 数据集对我们有诸多吸引力，首要原因是许多人都能与之产生共鸣，毕竟多年来我们都使用过这个网站。其他一些原因包括：

它是一个真实世界的数据集，其模式跨越了多个相互关联的表。
真实数据通常是杂乱无章的，因此它是对数据库系统的绝佳测试。数据的导入/导出很困难（涉及空值、转义符号等），查询也常常很慢（正如本文中 ClickHouse 在处理复杂连接时所表现出的挣扎）。
ClickHouse 选择发表了一篇关于它的文章，这为比较 ClickHouse 与 CedarDB 提供了一个很好的起点。
该数据集既提供了编写针对单表进行聚合计算的简单 SQL 查询的机会（如您在此处所见，摘自 ClickHouse 的帖子）：

sql 复制代码

SELECT
  arrayJoin(arrayFilter(t -> (t != ''), splitByChar('|', Tags))) AS Tags,
  count() AS c
FROM stackoverflow.posts
GROUP BY Tags
ORDER BY c DESC
LIMIT 10

......同时也提供了通过连接多表的 SQL 查询来探索更复杂关系的机会；例如，以下查询列出了自 2019 年以来拥有已采纳答案的 10 个最新问题，并显示了问题标题和提问者、已采纳答案的 ID 和回答者，以及（如果有）属于该回答者的徽章名称：

sql 复制代码

SELECT
  q."Id"        AS question_id,
  q."Title"     AS question_title,
  qu."DisplayName" AS question_owner,
  a."Id"        AS answer_id,
  au."DisplayName" AS answer_owner,
  b."Name"      AS answerer_badge
FROM posts q
JOIN posts a
  ON a."Id" = q."AcceptedAnswerId"
JOIN users qu
  ON qu."Id" = q."OwnerUserId"
JOIN users au
  ON au."Id" = a."OwnerUserId"
LEFT JOIN badges b
  ON b."UserId" = au."Id"
WHERE q."AcceptedAnswerId" IS NOT NULL
  AND q."Title" <> ''
  AND q."CreationDate" >= TIMESTAMP '2019-01-01'
ORDER BY q."CreationDate" DESC
LIMIT 10;

由于 ClickHouse 在其帖子中已经涵盖了简单的查询，因此本文的重点将放在像上面这样更复杂的查询上，也就是那些"黑道"级别的查询。这正是促使我们考虑使用 Parquet 将工作负载迁移到 CedarDB 的原因。

那么，这个 Parquet 迁移过程在实践中是怎样的呢？其核心操作如下：

sql 复制代码

-- Clickhouse:
ip-10-0-1-175.us-east-2.compute.internal :) SELECT *
:-] FROM votes
:-] INTO OUTFILE 'votes.parquet'
:-] FORMAT Parquet;

-- CedarDB:
postgres=# CREATE TABLE votes AS SELECT * FROM '/var/lib/cedardb/data/ext/votes.parquet';
SELECT 238984011
Time: 46287.163 ms (00:46.287)

实验概览

详细的分步操作步骤请参考下面的"附录：滑雪后的技术细节"。

使用此 CloudFormation 模板在 us-east-2 区域部署了一个 EC2 实例。
在 Docker 中启动 ClickHouse。
加载 Stack Overflow 数据集。
运行七个 SQL 查询，收集运行时的监控数据。
将数据以 Parquet 格式导出到本地文件系统。
关闭 ClickHouse。
在 Docker 中启动 CedarDB。
从 Parquet 文件加载数据集。
重复查询运行和计时收集。

我们将提出的问题

以下是我们的 SQL 查询将要提出的问题，其编号与实验中使用的文件编号以及下方结果表中的条目相对应。要查看某个查询的 SQL 语句，请点击其编号旁的右箭头符号。

Q1: 在高声誉用户（声望 ≥ 100,000）中，找出被授予次数最多的前 10 种徽章类型。仅考虑那些在 2018 年 1 月 1 日之后创建过帖子，并且这些帖子至少有一条评论的用户。
Q2: 找出社区意见严重分歧的帖子------那些同时获得大量顶和踩的帖子------并突出显示那些意见分歧最均匀的帖子，特别是那些引发了大量讨论的帖子。
Q3: 列出自 2019 年以来拥有已采纳答案的 10 个最新问题，并显示：(1) 问题标题和提问者，(2) 已采纳答案的 ID 和回答者，(3) 以及（如果有）属于该回答者的一个徽章名称。
Q4: 突出显示那些被"社区触及"（被其他人编辑过）的热门帖子，并根据总投票数进行排名，使用评论数作为并列排序的依据。
Q5: 显示自 2020 年以来最新的 10 条帖子间链接，包括链接双方的帖子标题和作者。
Q6: 突出显示那些随时间推移被"反复雕琢"最多的帖子，并指出这些工作主要来自单个编辑者还是一群广泛的贡献者。
Q7: 确定哪些标签组合总体上能产生最多的答案，以及这些答案更可能来自高声誉还是低声誉的贡献者。

结果与观察

AWS EC2 实例类型: m7a.8xlarge (32 vCPU, 128 GB RAM, 每小时 $1.85)
部署方式: Docker 为这两个数据库引擎提供了简单的部署手段。
CedarDB 版本: v2026-02-03
ClickHouse 服务器版本: 26.1.2.11
关键助力 - Parquet: Parquet 支持扮演了"缆车"的角色，将我们从初级的 SQL 查询（ClickHouse）带到了高级的查询（CedarDB）。
数据加载: 在 CedarDB 中，除了一个例外，我们都是使用 CREATE TABLE ... AS SELECT ... 语句从 Parquet 数据创建表的。
交互界面: psql 命令行是我们与两个系统交互的主要工具，除了从 ClickHouse 导出 Parquet 数据时。
性能对比: CedarDB 在所有七个查询上的表现都优于 ClickHouse，速度提升从约 1.5 倍到 11 倍不等。

下表总结了实验结果：

查询 #	ClickHouse 耗时 (ms)	CedarDB 耗时 (ms)	速度比 (ClickHouse / CedarDB)
1	22432.234	3036.361	7.388
2	1726.711	423.479	4.077
3	13251.638	1146.439	11.559
4	5601.891	943.241	5.939
5	803.491	163.510	4.914
6	2752.464	1836.822	1.498
7	1374.796	695.075	1.978
几何平均加速比			4.363

我的总结

CedarDB 新近对 Parquet 数据格式的支持，使得摄入 Parquet 数据变得非常简单（而且，使用 Docker 部署也很容易）。
如下面的"显示实验笔记"所示，ClickHouse 要求您预先提供相当多的数据信息：
- CreationDate DateTime64(3, 'UTC')：相比之下，CedarDB（和 Postgres）中只需 TIMESTAMPTZ。
- Id Int32 CODEC(Delta(4), ZSTD(1))：您需要指定压缩策略。
- ContentLicense LowCardinality(String)：您需要手动启用存储优化（例如字典编码）。
- ENGINE = MergeTree ORDER BY (CreationDate, PostId)：您需要提供关于如何最佳组织数据的提示。
如果您在使用 ClickHouse 进行涉及复杂连接的查询时遇到了挑战，那么 CedarDB 可以立即缓解这些问题。
同样值得指出的是，与 ClickHouse 不同，CedarDB 能够同时处理您的 OLAP 和 OLTP 工作负载，并且它看起来就像 Postgres，因此您可以在最新数据上运行分析查询，实现零复制延迟和更简单的数据架构。
Parquet 并不在乎您使用哪个数据库引擎。它只是把您送到山顶。而下山途中的表现，则完全取决于数据库本身。

感谢您加入我的这次冬日冒险之旅！

如果您希望与我们讨论您遇到的数据挑战，我们很乐意听取您的意见。