在数据技术飞速演进的今天数据基础设施的架构升级已成为大型互联网公司必须面对的战略课题。快手作为日活数亿的短视频平台其数据系统承载着远超常规想象的规模和压力。本文将完整还原快手从ClickHouse到Apache Doris的百PB级数据迁移历程揭示这一庞大工程背后的技术决策、实施细节与经验教训。这不是一次普通的版本升级或集群扩容而是一场涉及两百多个集群、百PB级数据、数千个业务应用的系统性架构重塑。其间的技术考量、工程挑战与组织协同对于任何面临数据基础设施升级的团队都具有深远的参考价值。一、迁移背景与动因分析1.1 原有架构的辉煌与隐忧快手的数据分析体系在过去数年经历了指数级的增长。ClickHouse作为核心的OLAP引擎凭借其卓越的查询性能和优秀的列式存储设计在快手数据服务的发展历程中扮演了不可替代的角色。高峰时期快手的ClickHouse集群规模超过两百个数据总量达到百PB级别每日承载的查询请求数以亿计。然而随着业务场景的持续丰富和数据规模的进一步膨胀原有架构的隐忧逐渐浮出水面。运维复杂度失控是最为迫切的现实问题。两百多个独立集群意味着两百多套需要独立维护、监控、升级和故障处理的数据系统。集群间的数据同步、资源调配和版本管理构成了一张日益复杂的运维网络DBA团队的人力被大量消耗在重复性的日常维护工作中难以抽出精力进行架构层面的优化和创新。数据冗余与一致性困境同样严峻。在多集群架构下同一份数据往往因为查询性能或隔离性的考虑而被复制到多个集群中。这不仅造成了存储资源的巨大浪费更棘手的是数据一致性问题——不同集群间的数据副本可能因为同步延迟或失败而出现不一致业务方难以确定哪个集群的数据是可信的。资源利用率的峰谷失衡是另一个难以忽视的问题。各集群独立规划资源导致部分集群在业务高峰期资源吃紧而另一些集群在低谷期资源大量闲置。缺乏统一调度能力的架构使得全局资源利用率始终处于不理想的水平。1.2 新架构选型的技术考量在决定对数据湖仓架构进行重构之后技术团队展开了广泛的选型调研。候选方案包括继续在ClickHouse生态内演进、迁移至其他开源OLAP引擎以及采用云原生数据仓库等不同路线。经过多轮技术评审和POC验证Apache Doris最终成为快手的战略选择。这一决策背后是多个维度的综合权衡。统一存储架构是Doris最打动快手团队的特性之一。Doris支持多种数据模型和存储格式的统一管理能够同时支撑高并发点查询、复杂分析报表和批量ETL等多种负载类型。这意味着快手有望用一套存储系统替代原先分散在多处的数据副本从根本上解决数据冗余和一致性问题。极简运维体验是另一个关键加分项。Doris的分布式架构设计使得集群的扩缩容、节点替换和版本升级操作极为简便大量运维工作可以通过SQL命令而非复杂的脚本和配置文件完成。这对于长期承受ClickHouse多集群运维压力的快手团队而言无疑是一种解脱。生态友好性方面Doris兼容MySQL协议这意味着快手内部大量基于MySQL生态开发的工具和应用可以几乎零成本地接入Doris大大降低了生态迁移的阻力。查询性能的持续优化是Doris团队给予快手的信心保证。在同等硬件配置和数据集规模下Doris在多表关联查询、精确去重计算和高并发点查等典型场景中展现出不逊于甚至优于ClickHouse的性能表现。二、迁移工程的规模与挑战2.1 工程量级的全景描述这次迁移工程的规模足以列入业界数据基础设施升级的经典案例。从集群数量来看超过两百个ClickHouse集群需要被逐步下线或迁移每个集群承载着不同的业务线和数据服务等级要求。从数据量来看百PB级别的数据迁移意味着网络带宽、存储介质和迁移窗口都需要精密规划。从业务覆盖来看几乎涉及快手内部所有依赖数据分析的团队和产品线包括推荐系统、用户增长、商业化、内容生态、风控安全等核心业务域。如此体量的迁移不可能通过一次性割接完成必须制定分阶段、分批次、可回退的稳妥方案。2.2 技术挑战的多维度剖析数据一致性保障是迁移过程中最敏感的问题。在迁移期间源端ClickHouse集群仍在持续接收新的数据写入如何确保目标端Doris集群能够无缝追上这些增量数据并在切换时刻保持绝对一致是技术团队必须解决的核心难题。迁移期间的双轨运行带来资源消耗的显著增加。在完成所有业务切换之前源端和目标端系统需要并行运行这意味着计算资源和存储资源在相当长的时间内都是双倍消耗。如何在有限的预算约束下完成迁移需要精密的资源调度策略。查询语义的兼容性是另一项隐蔽但影响广泛的挑战。尽管Doris兼容MySQL协议但其SQL方言和优化器行为与ClickHouse存在诸多细节差异。业务方的大量既有查询语句和报表逻辑需要在迁移后进行适配和验证这一过程的工作量往往被低估。业务切换的平滑性直接关系到用户体验。对于快手这种量级的平台任何数据延迟或查询错误都可能影响到数百万用户的内容推荐和互动体验。迁移过程必须做到对业务方透明对终端用户无感。三、迁移方案设计与技术架构3.1 整体迁移策略面对如此规模的迁移工程快手技术团队确立了分阶段推进、按业务线切分、可灰度验证、能快速回滚的四大指导原则。分阶段推进意味着整个迁移被划分为多个时间窗口明确的阶段每个阶段有清晰的目标和验收标准阶段间设有缓冲期用于问题总结和方案调整。按业务线切分是指以业务团队为单位组织迁移批次同一业务线下的所有数据源和应用系统集中迁移便于业务方集中精力度过适配期。可灰度验证要求每批次迁移完成后保留充足的观察期将真实业务流量逐步切换到新系统而非一次性全量切换。能快速回滚是最后的防线。迁移方案中必须包含完备的回滚预案一旦发现新系统在灰度阶段出现严重问题能够迅速将流量切回旧系统将影响控制在最小范围。3.2 数据迁移管道设计数据迁移管道的设计是整个工程的技术核心。全量迁移阶段使用分布式数据导出导入工具将ClickHouse中的历史数据以高效压缩格式导出并加载至Doris集群。这一阶段的关键挑战在于迁移速度与源端负载之间的平衡过快的导出速度可能影响ClickHouse的正常查询服务过慢则拉长整个迁移周期。增量同步阶段是保障数据一致性的关键机制。快手团队构建了基于日志解析的增量数据捕获管道实时监听ClickHouse的写入变更并同步至Doris。这使得在迁移切换的最终时刻两个系统的数据差异能够控制在秒级以内。数据校验环节贯穿迁移全程。每个批次的数据迁移完成后自动化校验程序会对源端和目标端的数据进行全量和抽样比对涵盖行数一致性、字段值一致性和聚合结果一致性等多个层面。3.3 双轨运行与流量切换双轨运行是迁移期间的特殊状态也是风险最高的阶段。在此阶段源端ClickHouse继续作为主服务系统运行目标端Doris作为影子系统接收同步数据并承载部分验证查询。流量切换遵循循序渐进的策略。首先切换的是内部测试流量和低敏感度的离线分析任务用以验证Doris在真实负载下的稳定性。随后切换部分非核心业务的线上查询流量进一步扩大验证范围。最后在确认系统表现符合预期后依次完成核心业务线的切换。每次切换都伴随着全面的性能对比测试和业务回归验证。技术团队与业务方共同制定验证用例集确保切换后业务指标无异常波动查询响应时间不劣化。四、迁移实施的核心技术细节4.1 数据模型的适配与优化ClickHouse和Doris在数据模型和存储格式上存在差异直接将原有数据模型照搬到Doris会导致性能无法充分发挥。快手团队对每张核心表的数据模型进行了重新审视和优化。在Doris的三种数据模型中Duplicate模型适合需要保留原始明细数据的场景Unique模型适合需要主键去重和更新的场景Aggregate模型适合需要预聚合的指标统计场景。团队根据不同业务表的访问模式和更新特征为每张表选择了最适合的数据模型。分区和分桶策略的调整是迁移优化的重点。Doris的分区裁剪和分桶并行能力对查询性能影响显著团队根据查询条件中的常用过滤字段重新设计了分区键和分桶键使查询能够精准命中少量数据分片大幅减少扫描数据量。4.2 查询性能的调优实践迁移过程中最令业务方担忧的就是查询性能的退化。快手团队在迁移前期进行了大规模的性能压测和SQL调优。Doris的查询优化器基于代价模型进行执行计划选择准确的统计信息是优化器做出正确决策的前提。团队在数据导入后主动执行统计信息收集命令确保优化器掌握最新的数据分布特征。对于部分复杂查询团队利用Doris的物化视图功能预先计算和存储中间结果将原本需要扫描全表并执行复杂计算的查询转化为对物化视图的简单查询响应时间从数十秒降至毫秒级。SQL方言的转换也是性能调优的重要环节。部分ClickHouse特有的语法和函数在Doris中需要用不同的表达方式实现团队开发了自动化的SQL转换工具辅助业务方完成查询语句的迁移和验证。4.3 资源管理与负载隔离Doris的多租户资源隔离能力是快手选择它的重要原因之一。通过资源组和资源标签的配置团队能够在同一个Doris集群中为不同优先级、不同负载类型的业务分配独立的计算资源。高并发的在线查询被分配到专用的资源组确保响应时间稳定。资源消耗较大的离线ETL任务使用独立的资源组运行避免影响在线查询。导入任务同样拥有独立的资源配额防止大批量数据导入时挤占查询资源。这种精细化的资源管理使得快手能够用更少的集群承载更多的业务负载从根本上解决了原先ClickHouse多集群架构中资源碎片化和利用不均的问题。五、迁移过程中的挑战与应对5.1 数据一致性问题的攻坚在增量同步过程中技术团队遇到了若干数据不一致的棘手情况。部分场景下ClickHouse的分布式表写入因网络抖动导致部分分片写入成功而部分失败这种不一致状态被增量同步管道捕获后导致目标端Doris中的数据和源端不完全一致。团队通过在同步管道中引入事务边界感知机制解决了这一问题。同步程序不再逐条处理写入日志而是按照ClickHouse的写入事务粒度进行批量同步确保一个分布式写入操作要么全部同步成功要么全部回滚重试。对于已经出现数据偏差的表团队开发了修复工具能够在不中断同步的情况下对差异数据进行订正。5.2 性能回退的排查与解决迁移过程中最令人紧张的时刻莫过于某批次切换后发现查询性能回退。在一次核心业务表的迁移后几个关键报表的查询时间从ClickHouse下的数百毫秒退化到Doris下的数秒。排查过程从执行计划分析入手。Doris的Profile工具详细展示了查询各阶段的耗时分布团队发现性能瓶颈出现在一个多表关联操作上优化器选择的连接顺序导致了大量数据被提前扫描。通过调整该表的分布键使关联字段的数据在节点间合理分布并创建了针对该查询模式的物化视图最终将查询性能恢复到优于ClickHouse的水平。5.3 业务适配的协同推进迁移不只是技术团队的事业务方的配合和理解同样不可或缺。快手设立了专门的迁移支持小组为业务方提供一对一的迁移咨询和技术支持。迁移手册详细列出了常见问题的解决方案和性能调优的最佳实践。定期举办的迁移进度沟通会保持各方信息同步业务方能够及时了解迁移计划和切换时间表提前安排自身的工作节奏。技术团队也能从业务方那里获得第一手的反馈及时发现和解决迁移中的体验问题。六、迁移成果与性能收益6.1 架构简化的直接收益迁移完成后快手的数据湖仓架构发生了根本性的变化。两百多个ClickHouse集群被整合为十余个Doris集群集群数量减少超过百分之九十。运维复杂度随之大幅降低原先需要维护两百多套独立系统的DBA团队现在可以将主要精力投入到集群性能调优、数据治理和业务支持等高价值工作中。数据冗余问题得到根本性改善。原先分散在多处的数据副本现在统一存储在Doris中同一份数据不再需要为了隔离性而复制多份。存储成本因此降低了约四成。6.2 性能提升的具体数据在完成全量迁移和深度调优后Doris在快手的生产环境中展现出了令人满意的性能表现。在典型的多表关联查询场景中Doris的查询响应时间相比ClickHouse平均缩短约两成。在需要精确去重的用户指标计算场景中Doris的性能优势更为明显部分查询提速达到三倍以上。高并发点查询场景是Doris的强项。得益于其分区裁剪和索引机制Doris在每秒数千次并发查询的压力下依然保持毫秒级的平均响应时间。数据导入的吞吐能力同样获得提升。Doris的批量导入机制能够高效处理高频写入在同等资源条件下导入性能是ClickHouse的一点五倍左右。6.3 资源利用率的优化统一调度能力使全局资源利用率达到新的高度。原先各集群间的资源峰谷互补成为可能繁忙集群可以临时借用空闲集群的计算能力整体资源利用率从不足五成提升至七成以上。存储格式的优化和压缩算法的改进进一步降低了存储开销。Doris的列式存储和自适应压缩算法在快手的数据集上表现出优于ClickHouse的压缩比存储空间占用额外节省约一成。七、经验总结与未来展望7.1 迁移工程的宝贵经验回顾整个迁移历程快手团队总结出若干可复用的经验。充分的准备和验证是成功迁移的前提。大规模迁移之前团队用数月时间搭建了与生产环境对等的测试集群完成了全量数据的迁移演练和性能摸底将绝大多数潜在问题在测试阶段暴露并解决。分批次、可回退的策略是风险控制的法宝。任何一次看似完美的迁移计划都可能遇到预料之外的问题保留回退能力意味着即使出现问题也有退路团队可以更加从容地解决问题而非在压力下匆忙决策。工具链的建设和自动化程度直接决定迁移效率。快手开发了一系列辅助工具涵盖数据校验、SQL转换、性能对比和监控告警等功能这些工具将大量重复性工作自动化使迁移团队能够集中精力处理真正有挑战的技术难题。业务方的早期参与和持续沟通是顺利切换的保障。迁移不是技术团队的单方面行动业务方的信任和配合直接影响迁移节奏和最终效果。让业务方从一开始就参与选型评估和性能测试有助于建立对新系统的信心。7.2 未来演进方向完成这次大规模迁移后快手的湖仓架构演进并未停止。实时数据分析能力的深化是下一个重点方向。Doris对实时数据导入和高并发查询的良好支持为快手构建更加实时的数据驱动决策系统奠定了基础。与AI工作负载的融合正在探索中。随着大语言模型在内容推荐和用户理解等场景的应用深化数据系统需要同时支撑传统SQL分析和向量检索两种负载Doris在此方向上的能力拓展值得期待。湖仓一体的架构演进将继续推进。将数据湖中的海量原始数据与Doris中的结构化数据更紧密地整合实现冷热数据分层管理和统一查询是进一步提升数据效率和降低成本的重要方向。结语快手从ClickHouse到Apache Doris的百PB级数据迁移不仅是一次技术组件的替换更是一次数据基础设施架构理念的升级。从两百多个独立集群到十余个统一集群从分散管理到统一调度从被动应对复杂运维到主动优化资源效率这一转变所体现的是快手技术团队对数据系统本质的深刻理解和对技术演进的审慎把握。这次迁移的成功证明了一个重要的技术哲学在面对系统性的架构困境时与其在既有路径上持续修补不如以更开阔的视野审视根本问题选择能够从根本上改变现状的技术路线。Doris之所以能够在快手的严苛场景中落地并发挥价值既得益于其自身架构设计的先进性也离不开快手团队在迁移过程中展现出的专业能力和工程素养。对于所有面临数据基础设施升级挑战的技术团队而言快手的实践经验提供了一份宝贵的参考。数据系统的架构演进从来都不是一蹴而就的工程它需要清晰的技术愿景、稳健的实施方案、充分的团队协同以及面对未知问题时的冷静应对。这正是数据工程师在大数据时代最值得珍视的核心能力。