CodeWalk

实时数仓架构设计与选型

作者：编译有声 · 2026-05-30 12:55

请介绍实时数仓的典型架构设计，以及在不同延迟和规模要求下的技术选型建议。

回答

编译有声

实时数仓分层架构：

[业务数据]  [日志数据]  [埋点数据]
    ↓           ↓           ↓
[Canal]    [Flume]     [SDK]
    ↓           ↓           ↓
[Kafka] ← 统一数据总线（核心）
    ↓
[Flink] ← 实时ETL（清洗/扩维/聚合）
    ↓
[OLAP引擎] → [应用层]

各层技术选型：

1. 数据接入层： | 场景 | 技术选型 | |------|----------| | MySQL Binlog同步 | Canal + Kafka | | 应用日志 | Flume / Filebeat + Kafka | | 前端埋点 | SDK + Kafka | | 第三方API | HTTP Polling + Kafka |

2. 消息队列层：

  • Kafka： 标准选择，高吞吐、持久化
  • Pulsar： 更低的延迟、更好的多租户隔离
  • RocketMQ： 事务消息支持好（阿里系）

3. 实时计算层： | 需求 | 技术选型 | |------|----------| | 简单ETL/过滤 | Kafka Streams | | 复杂计算/窗口聚合 | Flink | | SQL友好 | Flink SQL / Spark Structured Streaming | | 毫秒级延迟 | Flink | | 秒级延迟 | Flink / Spark Streaming |

4. OLAP存储层： | 引擎 | 延迟 | 查询能力 | 场景 | |------|------|----------|------| | ClickHouse | 秒级 | SQL强，Join弱 | 实时报表、即席分析 | | Doris | 秒级 | SQL强，Join好 | 统一OLAP分析 | | Druid | 秒级 | 时序分析 | 监控、时序指标 | | TiDB | 毫秒级 | SQL完整 | 实时在线服务 | | Elasticsearch | 毫秒级 | 全文检索 | 日志搜索、APM | | HBase | 毫秒级 | Key-Value | 实时查询明细 |

实时数仓典型架构模式：

模式1：实时宽表（Flink维度关联）

  • Flink从Kafka读取事实流，从维度表（HBase/Redis）实时关联维度
  • 输出到ClickHouse/Doris，实现毫秒级OLAP查询

模式2：微批准实时

  • Kafka → Spark Structured Streaming（分钟级）→ Hive/ClickHouse
  • 适合对延迟不敏感的报表

模式3：Lambda + 实时层补充

  • 实时层（Flink + Druid）提供秒级指标
  • 批处理层（Hive + Spark）提供精准T+1报表
  • 服务层合并两者结果