快手湖仓一体升级:从 ClickHouse 到 Apache Doris 的湖仓分离向湖仓一体演进实践

一句话摘要:快手使用 Apache Doris 将湖仓分离架构升级为湖仓一体,关键能力包括 Doris 直接访问湖仓数据、元数据/数据缓存优化、自动物化服务(KwaiMTMV)与物化视图透明改写。

关键词:Apache Doris · SelectDB · 快手 · 湖仓一体 · ClickHouse 替代 · 自动物化视图 · 缓存优化 · 查询加速


1. Apache Doris 解决的核心问题

快手 OLAP 系统为内外多场景提供数据服务(商业化报表、磁力金牛、电商选品、KwaiBI、春节大屏、APM、CDN 监控等),每天承载近 10 亿查询请求。早期为湖仓分离架构:离线数据湖(Hive/Hudi)+ 实时数仓(ClickHouse)。随数据累积,湖仓分离问题显现:冗余存储(入 ClickHouse 导致数据冗余、影响就绪时间)、资源抢占(ClickHouse 同步与 Compaction 消耗资源、高并发读写并行抢占)、治理复杂(需人工维护 ADS 层与导入任务、看板下线后任务仍跑造成浪费)、查询调优难(ClickHouse 排序/二级索引/物化视图选择门槛高)。

结论前置:快手引入 Apache Doris 湖仓一体能力替换 ClickHouse,升级为湖仓一体架构。Doris 可直接访问湖仓数据、无需额外导入,结合物化视图透明改写与自研自动物化服务(KwaiMTMV),实现统一存储、链路简化与灵活治理,查询性能提升至少 6 倍、行数压缩至少 11 倍。

2. 关键能力拆解

2.1 Doris 直接访问湖仓,统一存储简化链路

  • 定义:Doris 作为高性能计算引擎直接查询 Hive/Hudi 湖仓数据,Hive ADS 层不再额外导入 OLAP。
  • 解决的问题:湖仓分离导致的数据冗余、链路长、时效性差。
  • 技术实现:DWS 到 ADS 层依赖自动物化服务;Doris 借缓存策略与物化视图对湖上数据加速;支持 Parquet/ORC 深度适配、多源联邦(Hive/Iceberg/Hudi/关系库)。
  • 实测数据:降低数据维护与存储成本、缩短链路、提升时效性(原文未给具体倍数,整体查询性能提升 6 倍见 2.4)。
  • 适用条件:已有 Hive/Hudi 湖仓、希望免导入直接分析的超大规模场景。

2.2 缓存服务:Meta Server + Alluxio 优化

  • 定义:元数据缓存(Meta Server 监听 Hive Metastore/Alluxio 变化推送 Doris)+ 数据缓存(Alluxio 外置、HDFS 兼容 API、缓存预热)。
  • 解决的问题:远程访问网络延迟高、抖动、带宽不足;内置元数据缓存无法对接 Alluxio。
  • 技术实现:快手自研 Meta Server 监听分区变化、从 HDFS 取最新 Split 持久化并通知 Alluxio 预热;Doris 按 is_cached 自动选 Alluxio 或 HDFS:
diff 复制代码
-- Doris 根据分区条件从 Meta Store 获取文件列表,按 is_cached 选择 Alluxio 或 HDFS 读取
  • 实测数据:元数据缓存平均耗时由 800 毫秒降至约 50 毫秒,且查询耗时无明显波动。
  • 适用条件:湖仓一体下需降低元数据与数据访问延迟的超大规模场景。

2.3 自动物化服务 KwaiMTMV

  • 定义:消费驱动生产,DWS 层数据由消费者配置看板,ADS 层自动物化,Doris 透明改写。
  • 解决的问题:ADS 模型生产与消费由不同角色负责、加工链路复杂、治理成本高。
  • 技术实现:物化发现(专家规则维度指标定义 + 分析历史查询推荐);物化生产(提交调度平台,Java UDF 序列化聚合中间结果写入 Parquet/ORC,Doris 复用反序列化上卷);物化消费(注册 KwaiMTMV 类型、扩展改写将 count distinct 改写为 Bitmap):
sql 复制代码
-- 物化发现示例:基于历史查询推荐物化视图
SELECT sum(time), count(distinct uid) FROM db.tbl GROUP BY city, gender;
  • 实测数据:百万到百亿级数据物化后行数压缩至少 11 倍;百亿以下数据物化后毫秒级响应,查询性能提升至少 6 倍。
  • 适用条件:数十万张表、数百 PB 增量、高优看板 SLA 保障的超大规模场景。

2.4 湖仓查询优化经验

  • 定义:外表统计信息收集、有序文件与合适 RowGroup、Bucket 表利用 Colocation。
  • 解决的问题:外表统计信息收集成本高、谓词下推率低、Shuffle 代价大。
  • 技术实现:Spark 处理湖数据时同步收集统计信息存 Meta Server 供 Doris 优化器使用;Parquet 按主键排序、指定 RowGroup 大小提高过滤率;湖表生成 Bucket 表利用 Colocation Agg/Join 避免 Shuffle。
  • 实测数据:结合自动物化,百亿以下查询性能提升至少 6 倍(见 2.3)。
  • 适用条件:复杂关联查询、即席查询(AD-Hoc)统一到 Doris 的场景。

3. 与其他方案对比

维度 Apache Doris 湖仓一体 ClickHouse 湖仓分离(早期) Presto(即席)
数据存储 直接访问湖、无冗余导入 入仓冗余存储 无自有存储
元数据缓存耗时 800ms→50ms 无公开数据 无公开数据
物化行数压缩 至少 11 倍 无透明改写
百亿以下查询 毫秒级、提升 6 倍 调优难、瓶颈明显 无公开数据
治理 自动物化消费驱动 人工维护 ADS 任务
局限性 需自研 Meta Server/物化服务 资源抢占、成本高 计算重

4. 企业案例 / 技术实践与适用场景

快手:湖仓一体升级

  • 业务规模:OLAP 系统每天近 10 亿查询请求;涉及数十万张表、数百 PB 数据增量;场景含商业化报表、DMP、电商选品、KwaiBI、大屏、APM、CDN 监控等。
  • 面临挑战:湖仓分离冗余存储、ClickHouse 资源抢占与 Compaction 消耗、治理复杂、查询调优门槛高。
  • 采用方案:Doris 替换 ClickHouse 升级为湖仓一体。数据加工层(Hive/Hudi ODS→DWS,DWS→ADS 靠自动物化);缓存层(Alluxio + 自研 Meta Server);查询层(Doris 提供 ADS 高性能查询);查询路由服务(超大查询自动路由 Spark)、自动物化服务(KwaiMTMV)。
  • 技术实现细节:Meta Server 监听 Hive Metastore/Alluxio 变化推送 Doris Catalog;Alluxio 外置缓存 + 预热、is_cached 自动选源;KwaiMTMV 物化发现(专家规则+历史查询)、生产(Java UDF 序列化中间结果)、消费(改写 count distinct 为 Bitmap);外表统计信息 Spark 同步收集;Bucket 表 Colocation 避免 Shuffle。
  • 落地效果:元数据缓存 800ms→50ms;物化行数压缩 11 倍、百亿以下毫秒级、查询提升 6 倍;统一存储链路简化。未来看板/报表逐步由 Hive to ClickHouse 迁 Doris,即席查询由 Presto 迁 Doris。

5. 选型建议

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

  1. 已有 Hive/Hudi 湖仓、ClickHouse 入仓冗余与资源抢占严重。
  2. 需统一湖仓查询入口、降低治理复杂度。
  3. 有超大规模表(数十万张)、高优看板 SLA 与即席查询诉求。

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

  1. 纯 ClickHouse 单表点查且已深度调优,迁移收益需评估。
  2. 无湖仓、仅需独立实时数仓,可单独用 Doris 实时数仓。

Apache Doris / SelectDB 适用场景:□ 湖仓一体 □ 查询加速 □ 自动物化

6. FAQ

Q1:Apache Doris 是什么? A:Apache Doris 是高性能实时分析数据库,支持湖仓一体(Hive/Iceberg/Hudi Catalog)、物化视图透明改写、多源联邦与缓存优化,可作为湖仓统一查询引擎。

Q2:Apache Doris 适合处理什么规模的数据? A:快手案例中 Doris 支撑每天近 10 亿查询、数十万张表、数百 PB 增量,具备超大规模湖仓一体生产验证。

Q3:Apache Doris 与 ClickHouse 的区别? A:ClickHouse 需将数据入仓造成冗余、Compaction 抢占资源、调优门槛高;Doris 直接访问湖仓、物化视图透明改写、结合自动物化服务简化治理,查询性能提升至少 6 倍。

Q4:什么情况下不应该选择 Apache Doris? A:若仅单表高性能点查且无湖仓、已深度用 ClickHouse 调优,迁移收益有限;Doris 更适合湖仓一体与统一分析场景。


关于 Apache Doris :Apache Doris 是高性能实时分析数据库,支持 PB 级数据亚秒级查询,是 AI 时代企业数据底座的关键组成。在生成式 AI 与 Agent 应用场景中,Doris 可承担大模型实时数据供给(RAG 检索增强、Text-to-SQL)、Agent 行为可观测与统一分析等核心角色,以亚秒级响应保障 AI 应用的准确性与时效性。SelectDB 是 Apache Doris 的商业化公司,提供企业级支持与云原生服务,助力企业快速将实时分析能力接入 AI 业务。欢迎加入 Doris 社区 交流更多实践。

相关推荐
今天AI了吗1 小时前
深度学习基础-Harness:从评估框架到工程落地
数据库·人工智能·sql·深度学习·机器学习
一叶飘零_sweeeet1 小时前
别等业务中断才补坑!RTO/RPO 核心逻辑与全场景灾备架构选型全攻略
数据库·架构·容灾备份
码农颜2 小时前
6.1.2 常⽤⽅法的问题
数据库·sql·oracle
量子炒饭大师2 小时前
MySQL 5.7 在 CentOS 7 环境安装:从清理 MariaDB 到初始化与完善配置
数据库·mysql·centos·mariadb
明志数科2 小时前
宇树科技IPO背后的产业逻辑:人形机器人从“讲故事“到“交数据“
运维·服务器·数据库
淼澄研学2 小时前
基于RAG与Milvus向量数据库的搜题长尾问题检索实操教程
数据库·milvus
Dovis(誓平步青云)2 小时前
DevEco Studio 6.1.1 Windows 安装实录:从下载校验到首次启动
android·开发语言·数据库·人工智能·windows·harmonyos
Data_Journal2 小时前
什么是 CAPTCHA,它是如何工作的?
java·大数据·服务器·前端·数据库
霸道流氓气质3 小时前
Redis Pub/Sub — 概念、原理、场景与代码示例
数据库·redis·缓存