Lakehouse and federated query

The source notes for this track are currently maintained in Chinese.

预计阅读时间: 55 分钟 前置阅读: doc-01, doc-15, doc-18 下一次阅读: doc-22(可观测与半结构化分析)

1. Doris 为什么进入湖仓场景

Doris 最初强项是内表实时分析, 但现代数据平台通常已经有 Hive、Iceberg、Hudi、Paimon、S3/HDFS 对象存储和外部数据库。湖仓场景下, Doris 的角色变成:

统一 SQL 查询入口
  → 外部 Catalog 元数据
    → 远端文件扫描
      → Doris 优化器与执行引擎
        → Data Cache / 物化视图 / 内表加速

它的价值不是替代所有数据湖计算, 而是把交互式分析、BI、实时宽表和外部湖数据放到同一个查询面里。

参考:

• https://doris.apache.org/docs/4.x/lakehouse/lakehouse-overview/
• https://doris.apache.org/docs/4.x/lakehouse/catalogs/
• https://doris.apache.org/docs/4.x/getting-started/before-you-start-the-poc/

2. External Catalog 的心智模型

External Catalog 让 Doris 不复制数据也能访问外部系统。

关键区别:

3. 湖仓查询为什么慢

内表慢查询常见瓶颈是扫描范围、Join、聚合和资源竞争。湖仓外表多了三类问题:

1. 元数据慢: 分区、文件、Manifest 太多。
2. 远端 I/O 慢: 对象存储和 HDFS 延迟高于本地盘。
3. 小文件慢: Split 数过多, FE 规划和 BE 调度成本高。

POC 时如果只跑一次查询, 往往测到的是冷缓存和远端 I/O, 不是 Doris 稳态能力。

4. 分区裁剪先行

湖表必须让分区裁剪生效。

EXPLAIN
SELECT count(*)
FROM iceberg_catalog.db.event_log
WHERE dt = '2026-07-27'
  AND service_name = 'checkout';

看计划中的 partition 信息:

partition=203/1

如果扫描分区远超预期:

• SQL 条件是否使用了分区列。
• 分区列是否被函数包裹导致不能裁剪。
• 外部表分区元数据是否同步。
• Iceberg/Hive 的分区表达式是否和 SQL 一致。

5. Data Cache

远端存储的 I/O 延迟通常是湖仓查询瓶颈。Data Cache 把外部文件的热数据缓存到 BE 本地磁盘。

适合:

• BI 看板重复查询同一批湖数据。
• POC 中需要测稳态查询性能。
• 热分区远小于湖表总规模。

注意:

• 第一次查询可能仍然慢。
• 第二次或预热后才代表热数据性能。
• 缓存盘容量要和热数据窗口匹配。
• 对小文件过多的表, Cache 也不能完全抵消规划开销。

POC 做法:

1. 跑一次目标 SQL 预热
2. 跑第二次记录稳态耗时
3. 用 Profile 看 Cache 命中和远端读取量
4. 再对比内表或物化视图方案

6. 小文件治理

小文件问题不是 Doris 独有, 但 Doris 查询湖表时会承受结果:

小文件多
  → Split 多
    → FE 规划压力增加
      → BE Scan Task 变碎
        → 网络和调度开销变大

治理优先级:

1. 源头合并: Spark/Flink/Iceberg 写入时控制文件大小。
2. 表格式维护: Iceberg rewrite data files。
3. Doris 限制: 控制最大 Split 数, 避免 FE OOM。
4. 热数据落内表: 对高频交互查询做导入或 MV。

经验目标: 湖表文件尽量保持在百 MB 级别, 不要产生大量 KB/MB 级碎文件。

7. 外表 Join 内表

常见模式:

SELECT d.city, count(*)
FROM iceberg_catalog.dw.fact_order o
JOIN internal.dim_user d ON o.user_id = d.user_id
WHERE o.dt = '2026-07-27'
GROUP BY d.city;

风险:

• 外表扫描大, Join 前过滤不足。
• 内表维表不小, Broadcast 成本高。
• 外表统计信息不足, Join 顺序不合理。

处理:

• 外表先分区裁剪。
• 小维表可考虑 Dictionary 或 Broadcast。
• 大表 Join 考虑异步物化视图或把热分区导入内表。
• 统计信息不准时用 Hint 辅助验证。

8. 什么时候把湖数据导入 Doris 内表

一个常见混合架构:

ODS / DWD 长周期数据留在 Iceberg
  → 最近 7/30 天热数据导入 Doris 内表
    → 高频报表用 MV
      → 历史低频查询走 External Catalog

9. Lakehouse Profile 关注点

湖仓 Profile 重点不同:

专家报告要分清:

• Doris 执行慢。
• 外部存储慢。
• 元数据慢。
• 文件布局慢。
• SQL 没有分区裁剪。

一句话总结:

Doris 湖仓专家的能力, 是知道什么时候直接查湖、什么时候缓存、什么时候物化、什么时候导入内表, 而不是把 External Catalog 当成无限性能的魔法入口。