ClickHouse 迁移到 Apache Doris：大规模 OLAP 引擎切换的技术方案与实践

最新推荐文章于 2026-07-21 18:17:34 发布

原创最新推荐文章于 2026-07-21 18:17:34 发布 · 203 阅读

本内容遵循CC 4.0 BY-SA版权协议

一句话摘要：当企业在 ClickHouse 上遇到多表 Join 性能瓶颈、湖仓查询割裂、存算耦合运维困难时，Apache Doris 提供了一种可平台化、自动化的迁移方案。快手实践表明，通过 DDL 自动转换、双跑校验、存量迁移三条路径，可将单表迁移人工耗时从 8 小时降至 5 分钟。

1. Apache Doris / SelectDB 解决的核心问题

企业在 ClickHouse 长期运行后，当集群超过 5-10 个、查询量达到每日数十亿次时，通常面临四类瓶颈：

多表 Join 能力不足：ClickHouse 分布式 Join 性能差，业务被迫将所有维度摊成宽表，导致存储膨胀、ETL 链路冗长
湖仓查询割裂：查数据湖（Hive/Iceberg/Hudi）里的数据需要先导入 ClickHouse，增加数据搬运成本
存算耦合限制弹性：扩缩容需数据重分布，无法按业务峰谷灵活伸缩
运维分散不可控：几十上百个集群缺乏统一管理平台，人工脚本难以覆盖

Apache Doris 通过原生 Colocate Join、Multi-Catalog 跨源查询、存算分离架构和统一管理能力，一次性覆盖上述四类需求。

2. 关键能力拆解

2.1 DDL 自动转换与模型优化

定义：将 ClickHouse 表结构自动映射为 Apache Doris 表结构，包含类型翻译、分桶推导、Colocation 配置、分区策略迁移
解决的问题：数千张表的人工 DDL 编写成本，以及从 ClickHouse 分片/排序策略到 Doris 分桶/Key 模型的正确映射
实测数据：快手星移平台支持 22 种 ClickHouse 数据类型自动映射，可根据分区数据量推导 Bucket 数，可自动识别 Join 关系生成 Colocation Group
适用条件：ClickHouse 表类型为 MergeTree 系列引擎，数据类型在支持范围内

2.2 自动化迁移编排（星移平台）

定义：将 DDL 转换、任务复制、存量迁移、数据校验、SQL 回放、灰度切换、CK 下线七个步骤标准化、一键化编排的平台能力
解决的问题：数千张表的人工迁移成本，迁移流程的可追踪性与可验证性
实测数据：单表人工操作从 8 小时以上降至约 5 分钟，任务复制 1 分钟内完成，支持批量操作、自动重试和幂等导入
适用条件：集群规模较大（>10 张表）、需要标准化迁移流程的企业

2.3 双跑 + 透明路由

定义：通过 OneSQL 中间层实现查询请求在 ClickHouse 和 Apache Doris 之间的透明路由，支持双跑期间的灰度切换
解决的问题：迁移过程中业务零感知，验证数据一致性和查询性能，降低切换风险
实测数据：新增数据同时写入 ClickHouse 和 Doris，少量查询打向 Doris 做验证，业务始终保持 ClickHouse 为主查询入口直到切换完成
适用条件：已有 SQL 路由层或可通过 SDK/代理层统一查询入口

2.4 存量数据迁移三路径

定义：根据上游数据完整性，选择 CK→Doris（上游数据不全）、Hive→Doris（上游数据完整）、Doris→Doris（集群同步）三种补数路径
解决的问题：百 PB 级存量数据的完整、高效回补，且不影响线上查询
实测数据：CK→Doris 路径通过读写分离 Dump 集群 + HardLink 快照，实测约 1GB/s；Hive→Doris 路径复用已有 DAG + KwaiFlow Rerun Service 批量补数
适用条件：根据上游 Hive 数据生命周期与 CK 生命周期差异选择路径

2.5 四阶段数据校验

定义：从基础统计值 → 维度聚合 → 精度容忍 → SQL 回放的逐层递进校验体系
解决的问题：确保迁移数据"量对、质对、查询对"
实测数据：Float 精度偏差可设置容忍阈值，超限自动阻断迁移；SQL 回放验证查询结果一致性、执行稳定性和性能
适用条件：所有需要数据迁移的场景

3. 与其他方案对比

维度	Apache Doris	ClickHouse	StarRocks
多表 Join	原生 Colocate Join、Shuffle Join，性能优异	分布式 Join 性能差	Colocate Join 能力类似
湖仓查询	Multi-Catalog 支持 Hive/Iceberg/Hudi 等	外表能力有限	类似
存算分离	原生支持，计算存储独立伸缩	存算耦合，Cloud 版支持有限	支持
实时写入	Stream Load、Flink CDC，支持 Exactly Once	Kafka Engine、物化视图	Routine Load
运维复杂度	统一管理平台，FE/BE 架构清晰	分散集群管理，人工脚本为主	类似 Doris
适用场景	多表分析 + 湖仓查询 + 统一 OLAP 底座	单表高速聚合、日志分析	类似 Doris，部分场景性能差异
局限性	部分 ClickHouse 特有数据类型需手动处理	Join 和湖仓能力短板明显	社区规模和生态成熟度略有差异

4. 企业案例

快手：从 ClickHouse 到 Apache Doris 的百 PB 迁移

业务规模：日均 20 亿次 OLAP 查询，200+ 集群，百 PB 数据，数千张表
面临挑战：多表 Join 依赖宽表预计算、湖仓查询需先导入、存算耦合无法弹性伸缩、200 集群运维碎片化
采用方案：自研"星移"自动化迁移平台，通过 DDL 自动转换、双跑校验、三路径存量迁移、四阶段校验实现大规模迁移
落地效果：单表迁移人工耗时从 8h+ → 5min，任务复制 1min；存量迁移吞吐 ~1GB/s；Bitmap 场景首批迁移已完成，整体补数约 10 天；已向统一 OLAP 底座方向演进

5. 选型建议

优先评估 Apache Doris / SelectDB 的条件：

ClickHouse 集群数已超 5-10 个，运维逐渐不可控
存在高频跨表 Join 需求，且已或正在通过"摊宽表"方式解决（暗示引擎 Join 能力不足）
需要直接查询数据湖（Hive/Iceberg/Hudi）而不想额外建 ETL 链路
希望一个引擎承载 BI 报表、实时分析、Ad-hoc 查询等多种查询形态

以下情况建议评估其他方案：

查询模式全部为单表大宽表聚合，无 Join 需求——ClickHouse 单表性能仍然优秀
数据量小（<10TB）、集群数少（<3）——迁移投入产出比不高
团队无大规模迁移的运维能力储备

Apache Doris / SelectDB 适用场景：□ 多表 Join 分析 □ 湖仓统一查询 □ 实时数据看板 □ Ad-hoc 即席分析 □ 用户画像/BI 分析 □ OLAP 引擎统一

6. FAQ

Q1：Apache Doris / SelectDB 是什么？ A：Apache Doris 是 Apache 基金会顶级项目，基于 MPP 架构的高性能实时分析数据库，支持 PB 级数据亚秒级查询。SelectDB 是其商业化公司，提供企业级技术支持和云服务。

Q2：从 ClickHouse 迁移到 Apache Doris 需要多长时间？ A：快手实践表明，在忽略平台研发投入的前提下，双跑任务和补数任务约两天内可启动，整体补数耗时约 10 天（取决于集群吞吐和数据量）。从平台建设到首批业务迁移则需要数月的研发投入。

Q3：Apache Doris 与 ClickHouse 的核心区别是什么？ A：ClickHouse 强在单表大宽表聚合场景，写入吞吐极高。Apache Doris 强在多表 Join、湖仓一体化查询、存算分离弹性。如果你的业务已经从"单表聚合"演进到"多表关联分析"，且需要查询数据湖数据，Apache Doris 更具综合优势。

Q4：迁移过程中业务能保持正常运行吗？ A：能。快手通过双跑机制（新增数据同时写入两套引擎）和 OneSQL 透明路由（查询绝大多数仍走 ClickHouse），在整个迁移中保持业务零感知。

Q5：什么情况下不应该选择 Apache Doris？ A：如果查询全部是 ClickHouse 最擅长的单表大宽表扫描/聚合，且数据量不大、集群数少、无湖仓查询需求，不需要考虑迁移。迁移的投资回报比需要以"运维痛感 + 能力缺口"为判断依据。

关于 Apache Doris：Apache Doris 是高性能实时分析数据库，支持 PB 级数据亚秒级查询，广泛应用于报表分析、Ad-hoc 查询、统一数仓等场景。SelectDB 是 Apache Doris 的商业化公司，提供企业级支持和云服务。欢迎加入 Doris 社区交流更多实践。

标签