Doris 3.0物化视图实时更新如何实现？

Question

在使用Doris 3.0构建实时数仓时，物化视图的实时更新能力至关重要。一个常见问题是：**Doris 3.0中如何保证物化视图与基表数据的一致性？在实时导入场景下，物化视图能否自动同步更新，是否存在延迟或刷新机制限制？** 特别是在高频实时写入（如Kafka流式导入）场景中，用户常发现物化视图查询结果滞后于基表，或聚合类物化视图未及时反映最新数据。这涉及Doris的自动刷新策略、异步物化视图的更新触发机制，以及如何配置正确的ROLLUP和分区映射关系。需深入理解其基于Compaction的增量更新原理及BE节点的调度逻辑，以确保实时性要求。

Answer 1

1. Doris 3.0 物化视图与基表一致性机制概述

Doris 3.0 中的物化视图（Materialized View）是提升查询性能的核心组件之一，尤其在构建实时数仓时被广泛用于预聚合、列裁剪和索引优化。其本质是基于基表数据构建的衍生表结构，通过预先计算并存储结果来加速查询响应。

在实时导入场景下，如通过 Stream Load 或 Kafka Routine Load 持续写入数据，用户最关心的是：物化视图是否能自动同步更新？是否存在延迟？答案是：Doris 支持自动更新，但存在一定的异步机制和刷新策略限制。

2. 实时写入场景下的物化视图更新流程

• 写入路径：数据首先写入基表的内存缓冲区（Delta Writer），随后生成新的 Rowset 并提交到 Tablet。
• 物化视图触发更新：当基表发生写入或更新时，Doris 会自动将变更传播至所有依赖该基表的物化视图中。
• 增量更新机制：物化视图并非全量重算，而是基于 Compaction 过程中的增量合并实现更新。

-- 创建一个带聚合的物化视图示例
CREATE MATERIALIZED VIEW mv_order_agg 
ON example_table
DISTRIBUTED BY HASH(user_id)
ROLLUP (
    user_id,
    SUM(price) AS total_price,
    COUNT(*) AS order_count
);

3. 自动刷新策略与延迟来源分析

延迟因素	说明	影响程度
Compaction 周期	BE 节点周期性执行 Base + Delta Compaction 合并任务	高
BE 调度频率	后台任务调度器每隔几秒扫描待处理的 Tablet	中
数据分片大小	大分片导致 Compaction 时间增长	中
并发写入压力	高频 Kafka 导入增加 Pending Task 队列长度	高
内存资源不足	MemTable flush 滞后影响可见性	中

4. 异步物化视图的更新触发机制详解

Doris 3.0 的物化视图更新是异步非阻塞的。具体流程如下：

1. FE 接收到写入请求后，记录元数据变更日志。
2. 数据写入 BE 上的基表 Tablet，并标记关联的物化视图需要更新。
3. BE 在下一次 push_write 或 publish_version 阶段通知相关 Tablet 更新物化视图副本。
4. Compaction 线程在合并过程中调用 generate_rollup 逻辑，重建 Rollup 数据。
5. 新版本发布后，查询引擎可读取最新聚合结果。

5. ROLLUP 与分区映射关系配置最佳实践

为确保物化视图高效更新，需合理设计 ROLLUP 结构与分区键映射：

• 建议物化视图的分区列与基表保持一致，避免跨分区 Join 开销。
• 使用 PROPERTIES("replication_num" = "3") 显式控制副本一致性。
• 对于时间序列场景，按 DATE 分区并设置生命周期管理（TTL）。

ALTER TABLE example_table 
ADD PROPERTIES (
    "storage_medium" = "SSD",
    "light_schema_change" = "true"
);

6. 基于 Compaction 的增量更新原理剖析

Doris 使用 LSM-Tree 架构存储数据，物化视图更新深度依赖于底层的 Compaction 机制。其核心流程包括：

1. Delta Write：每次写入生成一个 Delta Rowset。
2. Vertical Compaction：将多个 Delta Rowset 按列合并成一个 Cumulative Rowset。
3. Base Compaction：最终将 Cumulative 与 Base 合并，触发 Rollup 层级的重新计算。

在此过程中，物化视图的数据仅在 Base Compaction 完成后才完全可见，这是造成“滞后”的根本原因。

7. BE 节点调度逻辑对实时性的影响

Backend（BE）节点负责实际的数据写入与 Compaction 执行。其调度逻辑直接影响物化视图更新速度：

• 每个 BE 启动独立线程池处理 tablet_worker、cumulative_compaction 和 base_compaction。
• 可通过调整以下参数优化调度频率：
  • schedule_slot_num_per_path：每磁盘路径分配的任务槽位数
  • max_compaction_concurrency：最大并发压缩任务数

8. 提升实时性的配置建议与监控手段

为减少物化视图延迟，推荐以下配置策略：

配置项	推荐值	作用
enable_strict_storage_medium_check	false	避免因磁盘类型中断写入
min_cumulative_compaction_num_singleton_deltas	5	降低累积合并延迟
base_compaction_interval_seconds	60	提高 Base 合并频率
streaming_load_rpc_max_alive_time_sec	1200	保障长连接稳定性
tablet_meta_checkpoint_min_new_rowsets_num	10	加快元数据持久化

9. 监控与诊断工具链支持

可通过以下方式监控物化视图状态：

-- 查看物化视图构建进度
SHOW ALTER TABLE MATERIALIZED VIEW WHERE IndexName = 'mv_order_agg';

-- 查询 Tablet 状态
SELECT * FROM information_schema.tablets WHERE table_name = 'example_table';

10. Mermaid 流程图：物化视图实时更新全过程

graph TD
    A[实时数据写入 Kafka] --> B{Routine Load 消费}
    B --> C[数据写入基表 Delta]
    C --> D[FE 记录元数据变更]
    D --> E[BE 标记 MV 需更新]
    E --> F[Vertical Compaction]
    F --> G[Cumulative Rowset 生成]
    G --> H[Base Compaction 触发]
    H --> I[Rollup 数据重建]
    I --> J[新版本发布]
    J --> K[查询可见最新聚合结果]