[其他] ClickHouse推出pg_clickhouse插件：无缝集成PostgreSQL，加速OLAP查询迁移

从商业视角看，ClickHouse免费为PostgreSQL用户开发pg_clickhouse扩展，其核心战略在于降低用户迁移摩擦，扩大市场占有率，并加速从OLTP/混合数据库向专业OLAP数据库的过渡。

1. 锁定最大潜在用户群，降低迁移成本

这是最直接且关键的原因。PostgreSQL是ClickHouse最主要的迁移来源之一。当用户的分析查询遇到性能瓶颈时，他们是转向ClickHouse的最大目标群体。
数据迁移本身可通过ClickPipes等工具简化，真正的痛点在于应用层：用户在PostgreSQL上积累了多年的分析SQL、ORM、仪表板和业务逻辑。重写这些代码耗时且风险高。pg_clickhouse允许用户几乎无需修改（或仅需调整search_path）即可运行现有查询，极大地降低了技术门槛。

2. 推动工作负载分离与专业化

ClickHouse是一家专注于OLAP的数据库公司。其商业利益在于引导客户将分析工作负载转移到其高性能引擎上。
通过将分析查询透明地从PostgreSQL下推到ClickHouse执行，ClickHouse成功地将自身嵌入客户的数据架构中，成为核心分析层。用户可以继续使用PostgreSQL处理OLTP事务，同时享受ClickHouse在大规模分析上的性能优势。
该插件使PostgreSQL成为一个“分析代理”，用户与熟悉的界面交互，繁重的查询则在ClickHouse中完成，从而强化了ClickHouse作为专业分析后端的定位。

3. 展示技术实力与产品成熟度

一个强大的FDW（外部数据封装器）不仅是集成工具，更是技术能力的体现。
文章重点提到了对聚合函数下推和半连接下推的改进。这些是处理复杂分析查询（如TPC-H基准测试）的关键。如果插件只能处理简单查询，商业价值有限。通过攻克这些复杂查询下推的难题，ClickHouse向市场证明，它能够无缝、高效地接管复杂的分析工作负载。
此外，接手并现代化原有的clickhouse_fdw项目，确保其与最新版本的PostgreSQL和ClickHouse兼容，对商业推广至关重要。

4. 驱动商业模式与未来收入

虽然插件本身开源，但其最终目标是推动如ClickHouse Cloud等商业服务的采用。
该插件让客户能更轻松地试用和采纳ClickHouse Cloud。一旦数据和查询逻辑迁移至ClickHouse生态，客户更倾向于选择官方提供的全托管服务，从而转化为付费用户。
同时，通过pg_clickhouse深度集成分析工作流，也提高了用户切换到其他分析数据库的成本，增强了客户粘性。

总结：一个双赢的战略

pg_clickhouse的开发是一个精明的商业策略：

• 对用户：实现了低代码重写和查询加速，降低了迁移风险和成本。
• 对ClickHouse：扩大了用户群，加速了将庞大的PostgreSQL用户转化为自身客户的过程。
• 对技术架构：促进了工作负载分离，巩固了ClickHouse作为专业高性能OLAP引擎的地位。

---

pg_clickhouse 介绍

在过去一年中，我们注意到迁移至ClickHouse Cloud的客户中存在一个显著模式：PostgreSQL是仅次于自托管ClickHouse的最常见数据源。ClickPipes简化了数据复制和迁移，但用户仍面临将查询和应用代码从PostgreSQL迁移到ClickHouse的巨大挑战。

为此，我们发布了 pg_clickhouse v0.1.0，这是一个采用Apache 2许可证的PostgreSQL扩展，允许直接从PostgreSQL透明地在ClickHouse上执行分析查询。

您可以从以下位置下载：

• PGXN
• GitHub

或通过Docker快速体验：

docker run --name pg_clickhouse -e POSTGRES_PASSWORD=my_pass -d ghcr.io/clickhouse/pg_clickhouse:18

设计目标

设想一个常见场景：一个由PostgreSQL支撑的应用，随着数据量增长，其分析查询开始变慢。开发者可能通过只读副本临时缓解，但最终会考虑迁移到像ClickHouse这样的专业分析数据库。
ClickPipes解决了数据迁移，但针对这些数据的现有PostgreSQL查询（存在于仪表板、ORM和定时任务中）该如何处理？重写这些积累了数年的SQL才是耗时部分。
我们构想的PostgreSQL扩展旨在减少迁移这些查询的需要。用户只需将查询指向新的数据库或模式即可。因此，pg_clickhouse的目标是：

• 提供从PostgreSQL执行ClickHouse查询的能力。
• 允许现有PostgreSQL查询无需修改即可运行。
• 将查询执行下推到ClickHouse。
• 为查询下推的持续演进奠定基础。

项目背景与历史

SQL/MED标准通过外部数据封装器（FDW）来解决此类需求。PostgreSQL自9.3版本起支持FDW。
我们找到了现有的clickhouse_fdw项目，它由Ildus Kurbangaliev开发，支持基础数据访问和部分查询下推。但自2020年底以来，其维护有限，未能受益于PostgreSQL FDW API的最新改进，如高级聚合、半连接和子查询下推等。
在与原开发者沟通后，我们将其大部分功能导入新项目pg_clickhouse，并采用Apache 2许可。

主要改进

我们在clickhouse_fdw的基础上进行了现代化改造、错误修复和功能增强，旨在实现分析查询的通用下推。主要改进包括：

• 采用标准PGXS构建流程。
• 添加预处理INSERT支持，并升级ClickHouse C++客户端库。
• 建立测试和CI工作流，确保支持PostgreSQL 13-18和ClickHouse 22-25。
• 支持基于TLS的连接（ClickHouse Cloud必需）。
• 支持Bool、Decimal和JSON类型。
• 透明的聚合函数下推，包括对percentile_cont()等有序集聚合的支持。
• 半连接（SEMI JOIN）下推。

后两项功能极大提升了FDW对分析数据库的适用性。

聚合函数下推示例

有序集聚合的语法在不同数据库间映射较难。pg_clickhouse能将此类函数透明地重写并下推。例如，一个包含percentile_cont()的PostgreSQL查询：

SELECT
   type,
   round(min(price)) + 100 AS min,
   round(max(price)) AS max,
   round(percentile_cont(0.5) WITHIN GROUP (ORDER BY price)) AS median
FROM uk.uk_price_paid
GROUP BY type

会被重写为ClickHouse的quantile()函数并完全下推执行：

SELECT
   type,
   (round(min(price)) + 100),
   round(max(price)),
   round(quantile(0.5)(price))
FROM uk.uk_price_paid
GROUP BY type

同样，PostgreSQL的FILTER (WHERE)表达式会被转换为ClickHouse的-If组合器，避免海量数据回传。

半连接下推的效果

我们使用TPC-H基准测试进行验证。在添加半连接下推支持前，许多包含EXISTS子查询的查询效率低下。
以TPC-H查询4为例，启用半连接下推后，查询被完全下推为一个高效的LEFT SEMI JOIN，执行时间从超时（>1分钟）降至约67毫秒。
下表对比了在TPC-H SF1数据集上，使用原生PostgreSQL表、早期pg_clickhouse（无半连接下推）和当前版本（支持半连接下推）的查询性能（✅表示完全下推）：

查询	Postgres 运行时	原始运行时	SEMI JOIN运行时
1	4478ms	✅ 82ms	✅ 73ms
3	1454ms	✅ 74ms	✅ 74ms
4	650ms	-	✅ 67ms
6	740ms	✅ 33ms	✅ 42ms
...	...	...	...

可见，支持半连接下推后，绝大多数查询性能得到显著提升。

未来规划

我们目前的开发重点是在添加DML功能前，完善对分析工作负载的下推覆盖。路线图包括：

• 优化剩余未下推的TPC-H查询计划。
• 测试并修复ClickBench查询的下推问题。
• 支持所有PostgreSQL聚合函数和标量函数的透明下推。
• 实现全面的子查询下推。
• 支持通过CREATE SERVER/USER设置ClickHouse配置。
• 支持所有ClickHouse数据类型。
• 支持轻量级DELETE/UPDATE和批量插入。
• 添加执行任意ClickHouse查询并返回结果集的函数。
• 支持UNION查询下推。