快手：从 Clickhouse 到 Apache Doris，实现湖仓分离向湖仓一体架构升级

导读：快手 OLAP 系统为内外多个场景提供数据服务，每天承载近 10 亿的查询请求。原有湖仓分离架构，由离线数据湖和实时数仓组成，面临存储冗余、资源抢占、治理复杂、查询调优难等问题。通过引入 Apache Doris 湖仓一体能力，替换了 Clickhouse ，升级为湖仓一体架构，并结合 Doris 的物化视图改写能力和自动物化服务，实现高性能的数据查询以及灵活的数据治理。

作者｜快手大数据架构师 李振炜、曾斯维、周思闽

在当今这个数据洪流的信息时代下，数据已跃升为企业不可或缺的核心资产。深度挖掘并提炼数据内在价值，成为支撑企业战略决策的重要依据。在此背景下，快手建立了 OLAP 系统，该系统在快手应用极为广泛，每天承载近 10 亿的查询请求，为内外多个业务场景提供数据服务。具体场景包括：

• ToB 系统：商业化报表引擎、商业化 DMP、商业化磁力金牛、电商选品等

• 内部系统：KwaiBI、春节/活动大屏、APP 分析、数据同步、用户理解中心、APM、CDN 监控、雷达监控系统等

存在的问题

最初，快手 OLAP 系统整体技术架构由离线数据湖和实时数仓这两部分组成，离线数据湖核心引擎为 Hive/Hudi，实时数仓核心引擎为 ClickHouse。OLAP 系统数据源种类非常丰富，全面覆盖结构化、半结构化、非结构化的数据类型，这些数据同步到到数据湖进行 ODS 、 DWD、DWS、ADS 层处理，处理后的数据同步至实时数仓，由数仓对外提供 BI、报表、查询等数据服务。

虽然这套架构已在快手内部稳定运行许久，但随着需求的变化、数据的不断累积，湖仓分离这一架构带来的问题逐渐显现：

• 冗余存储：虽然将数据入仓到 ClickHouse 能够提高查询性能，但同时导致了数据冗余存储，影响数据就绪时间和存储效率。
• 资源占用： to ClickHouse 过程也会占用 ClickHouse 集群资源，不仅体现在 Clickhouse 中数据同步系统的资源消耗，且在数据写入后，ClickHouse 内部也有 Compaction 等计算资源的消耗，在高并发查询的时候，并行读写带来更显著的资源抢占问题，可能影响其他查询任务的执行效率和集群的整体性能。
• 治理复杂：数据工程师需要投入大量人力建立 ADS 层模型，以支持 to ClickHouse 导入工作，并需要投入额外的精力维护导入任务。此外，当报表看板下线后，对应 ADS 层和 to ClickHouse 任务还在运行，造成计算和存储资源的不必要浪费，大部分情况下需要依赖人工介入判断并终止这些任务，这无疑增加了运维管理的复杂度。

此外，随着 ClickHouse 在业务中使用越来越深，查询性能出现瓶颈。排序字段、二级索引、物化视图以及哈希字段的选择和创建对 Clickhouse 查询性能有显著影响，但局限于 Clickhouse 的语言、系统适配性等因素，开发人员的学习及操作门槛都比较高，查询调优的难度比较高。

升级目标及选型

在上述问题驱使下，快手希望引入湖仓一体架构来解决上述问题，希望数仓可直接分析湖中数据，而不需要进行繁琐复杂的数据传输，避免传输及传输过程中引发的数据问题。在该目标的指引下，快手快速锁定 Apache Doris，尽管 Apache Doris 定位于实时数据仓库，但在过去版本中 Apache Doris 一直不拘于数据仓库的能力边界，在湖仓一体方向进行了诸多探索，逐步形成了湖仓一体解决方案：

• 极致分析性能、助力湖仓查询加速 ： 借助强大的分布式 SQL 查询引擎，Apache Doris 对 Parquet、ORC 等开发