上一篇文章介绍了快手在 AB 场景中实现 145 倍性能提升的实践，重点解析了从 Spark 迁移至 Apache Doris 的加速路径。本文将进一步系统梳理快手在 OLAP 分析引擎领域从 ClickHouse 向 Apache Doris 迁移的实践过程。
针对 ClickHouse 在 Join 能力、湖仓一体、存算分离和运维复杂度等方面的局限，快手基于 Apache Doris 引入了更完善的多表 Join、湖仓查询、 存算分离等能力，建设自动化迁移平台“星移”，将 DDL 转换、任务复制、存量数据迁移等流程平台化、自动化。
通过这套体系，支撑了百 PB 级数据、 200+集群、数千张表的平滑迁移，在保障业务无感切换的同时，缩短了复杂数据加工链路，降低了集群运维和业务使用成本，也为统一内部 OLAP 分析底座打下基础。
本文整理自快手数据平台部数据引擎技术中心严炜琦在 Apache Doris × 快手北京线下 Meetup 上的演讲。
为什么要从 ClickHouse 迁移至 Apache Doris？
在快手内部，ClickHouse 曾长期作为主力分析引擎，承载了商业化、电商、AB、KwaiBI 等多个业务线的大量 OLAP 查询场景。随着业务规模增长，快手 OLAP 查询量已经达到日均 20 亿次以上，同时内部存在 200 多个集群、百 PB 级数据量，以及数千张表的数据规模。
在这样的背景下，继续依赖 ClickHouse，逐渐面临复杂分析、湖仓查询、资源弹性和集群运维等方面的问题。快手希望通过迁移至 Apache Doris / Bleem，在承接现有查询负载的同时，进一步简化数据链路和平台运维，逐步建设统一的 OLAP 分析底座。
注：Bleem 是快手内部基于 Apache Doris 的发行版，下文统一使用 Doris / Bleem 表述。
从架构层面来看，迁移主要解决以下四类问题：
百 PB 数据迁移面临哪些核心挑战？
从业务和实施层面来看，从 ClickHouse 迁移至 Doris / Bleem，并不是简单的数据导出和导入。快手内部业务规模大、数据链路复杂，整个迁移过程主要面临以下五方面挑战：
- 数据类型和表类型复杂。ClickHouse 支持大量数据类型，也包含聚合表、Replacing 表等多种表类型。迁移时需要将这些数据类型和表类型完整映射到 Doris / Bleem 上。
- 表数量多。ClickHouse 在快手长期作为主力分析引擎，业务内部已有数千张表。如果每张表都需要独立处理 DDL、任务复制、任务校验和数据校验，人工成本会非常高。
- 查询量大。快手是数据驱动型公司，OLAP 日均查询量超过 20 亿次。迁移过程中必须保证业务零感知，不能影响线上查询稳定性。
- 业务覆盖广。ClickHouse 覆盖商业化、电商、AB、KwaiBI 等多个核心业务线，迁移过程需要兼顾不同业务场景的差异化诉求。
- 数据规模大。快手内部存在 200 多个集群，累计数据规模达到百 PB 级，存量数据迁移链路必须具备高吞吐、可扩展和低影响能力。
这些挑战决定了迁移不能依赖人工脚本和单点经验，而必须通过平台化方式，将流程标准化、自动化并实现全链路可追踪。同时，目标引擎也需要具备完善的数据模型、导入机制和集群管理能力，以承接持续写入和大规模历史补数。
整体迁移架构如何设计？
快手内部业务通过 SDK 接入查询，并通过 OneSQL SQL 层实现透明路由。OneSQL 可以将查询透明转发到 ClickHouse 或 Doris / Bleem 集群，为迁移过程中的双跑、校验和灰度切换提供基础。
在 Doris / Bleem 侧，集群提供三种存储模式供业务选择：内表磁盘、内表 S3 和外表。通过不同的数据存储与访问方式，Doris / Bleem 可以根据查询时效、性能和成本要求承载不同类型的数据，逐步将原本分散在 ClickHouse 和其他分析链路中的能力统一到同一套查询体系中。
从迁移阶段来看，整体可以分为迁移前、迁移中和迁移后三个阶段。
迁移前：ClickHouse 承载线上业务
业务查询通过 OneSQL 路由到 ClickHouse。ClickHouse 的数据导入主要有两条链路：Hive to ClickHouse 主要用于离线覆盖，通常是 T+1 或小时级数据覆盖；Kafka to ClickHouse 主要提供近实时能力，达到分钟级数据可见性。
迁移中：ClickHouse 与 Doris / Bleem 双跑
迁移过程中，平台会先创建 Doris / Bleem 表，并复制 Hive to ClickHouse、Kafka to ClickHouse 两类导入任务，使新增数据同时写入 ClickHouse 和 Doris / Bleem。同时，通过 OneSQL 将部分查询打到 ClickHouse，部分查询打到 Doris / Bleem，用于验证数据一致性和查询性能。此时业务仍然主要在 ClickHouse 上运行，对业务侧保持无感知。
迁移后，业务查询全部切换至 Doris / Bleem
当数据校验、性能验证和灰度切换完成后，业务查询最终切换到 Doris / Bleem，并开始作为业务统一的 OLAP 查询入口，承接实时分析、多表 Join、看板查询和湖上数据分析等场景。随后逐步下线 ClickHouse 集群、ClickHouse 表以及 ClickHouse 导入任务。
如何通过“星移”平台实现迁移自动化？
针对表结构复杂、任务数量多、存量数据大和校验难等问题，快手将迁移流程拆成 8 个步骤，并通过内部“星移”平台进行自动编排：DDL 转换、任务复制、存量数据迁移、数据校验、SQL 回放、灰度切换和 ClickHouse 下线。
其中，DDL 转换、任务复制、存量数据迁移和数据校验是迁移前中期的核心环节，后文也将基于这几个环点介绍。
星移平台不仅负责迁移流程自动化，也负责将 ClickHouse 中的表结构、导入任务和查询模式转换为更适合 Doris / Bleem 的实现方式。整体主要承担两类能力：
- 自动编排迁移流程。平台将七个步骤标准化、一键化，支持迁移任务自动管理、批量操作、自动重试和幂等导入。
- 对接外部基础设施。平台依赖 SeaTunnel、KwaiFlow 调度平台和 OneSQL 查询路由等组件。其中，SeaTunnel 用于 ETL 任务处理，KwaiFlow 用于离线任务调度，OneSQL 则承担查询透明路由和迁移灰度能力。
在效率方面，星移平台将大量依赖人工的流程自动化。具体到单张表，人工操作时间可以从原来的 8 小时以上降低到约 5 分钟；任务复制可以在 1 分钟内完成；迁移过程中的分区导入也具备幂等和失败自动重试能力。
接下来，重点看几个核心环节。
DDL 转换：自动完成表结构映射
ClickHouse 与 Doris / Bleem 在表类型、分桶策略、Colocation 和 Key 策略上存在差异。星移平台会自动解析 ClickHouse 表结构，它支持 ClickHouse 的 22 种数据类型转换，并可根据分区数据量推导 Doris / Bleem 的 bucket 数，在查询性能和 FE 元数据压力之间取得平衡。
同时，平台会从 Order By、Primary Key、Hash Column 等信息中推导分桶 Key，并根据可能发生 Join 的表组自动生成 Colocation Group，减少后续查询中的 Shuffle 开销。
因此，DDL 转换并不只是语法翻译，也包含面向 Doris 的模型适配和局部优化。平台会将 ClickHouse 中依赖人工设计的分片、排序和本地 Join 策略，转换为 Doris 的分桶、Key 模型和 Colocation 设计。
任务复制：一键启动导入双跑
平台会将原有 Hive to ClickHouse、Kafka to ClickHouse 任务复制为 Hive to Doris、Kafka to Doris 任务，并启动双跑。新增数据同时写入 ClickHouse 和 Doris / Bleem，业务查询仍保持在 ClickHouse 上，等数据一致性和性能验证通过后再灰度切换。
离线任务依赖 KwaiFlow API 调度，历史数据可通过 Rerun Service 回刷；实时链路则通过 SeaTunnel、Stream Load 以及 Flink Engine 完成写入。为了保障可靠性，平台还支持 Exactly Once、分区级 overwrite 等特殊机制，避免重复写入。
通过 Doris 的 Stream Load、分区覆盖写入和批流导入能力，平台能够将离线与实时数据统一接入 Doris，同时保持迁移期间数据持续更新，避免因全量迁移造成长时间停写。
存量数据迁移：按场景选择补数链路
存量数据迁移是整个迁移过程中最关键的部分之一。快手主要设计了三条链路。
- ClickHouse to Doris：适用于上游 Hive 数据不完整的场景。例如 ClickHouse 表生命周期是 365 天，但 Hive 只保留 30 天数据，此时缺失的历史数据需要从 ClickHouse 侧补齐。
- Doris to Doris：适用于 Doris 集群之间的主备同步，或小表快速迁移。
- 离线补数：适用于上游 Hive 数据完整的场景，可以直接复用 Hive to Doris DAG，通过 KwaiFlow 的 Rerun Service 在 Spark 上完成历史数据补齐。
对于最关键的 ClickHouse to Doris 链路，快手没有直接从线上 ClickHouse 大表导出，而是基于读写分离架构构建 Dump 集群，将导出压力与线上查询隔离，并通过 HardLink 方式快速获得源集群数据视图。实测可达到约 1GB/s，Doris 侧则通过并行导入、分区级写入和弹性计算资源承接大规模补数，使存量迁移与实时数据写入可以并行推进，且业务查询无感知。
数据校验：保证迁移结果可信
快手采用四阶段校验机制：先做基础数据量和统计值校验，再做核心维度聚合校验；对于 Float 等存在精度偏差的字段设置容忍阈值，超过阈值则由平台阻断迁移；最终，校验结果、任务状态、补数进度和异常信息都在星移平台统一展示。
除了验证数据本身，后续 SQL 回放还用于确认同一查询在 Doris / Bleem 上的结果一致性、执行稳定性和性能表现，从而验证 Doris 对原有业务查询的完整承接能力。
通过这套流程，迁移从人工经验驱动转变为平台化、可验证、可追踪的标准流程。
结束语
在迁移进展方面，快手已率先完成 Bitmap 业务场景的首批迁移，已迁移集群数据规模达到 PB 级。在不计算平台研发投入的情况下，双跑任务和补数任务均可在约两天内启动，整体补数耗时主要取决于集群吞吐，约为 10 天。
总体而言，Doris / Bleem 在这次演进中承担了三重角色：首先，它是 ClickHouse 工作负载的承接引擎，保证存量业务平滑迁移；其次，它通过更强的 Join、索引和湖仓查询能力，帮助业务减少宽表与数据搬运；最后，它作为统一 OLAP 底座，推动快手将分散的查询、存储和集群运维能力逐步平台化。
长期来看，快手希望以 Doris / Bleem 为基础，打造统一的多模湖仓查询引擎，打通实时、离线与湖上数据，减少数据在不同引擎之间的搬运。在此基础上，平台将承载指标查询、即席分析、向量检索以及面向 Agent 的自然语言数据分析等多样化负载，为业务提供高性能、低延迟的数据查询服务。
