快手从ClickHouse到Apache Doris的数百个PB数据、200+集群迁移实践

针对 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 的表组自动生成 Colocati