实时数仓架构：Kafka分层还是OLAP引擎直出

📋 面试题

你们的实时数仓是怎么架构的？和离线数仓有什么区别？为什么这样设计？

两大经典架构

Lambda架构（离线+实时双跑）

           ┌── 离线链路（Hive/Spark）── 离线报表（T+1）
数据源 ──→│
           └── 实时链路（Flink/Kafka）── 实时大屏（秒级）

问题：两套逻辑、两套代码、两个结果可能对不上

Kappa架构（只保留实时链路）

数据源 → Kafka → Flink → OLAP/数仓

历史数据重跑：Kafka保留足够长（7天/30天），
需要回溯时从Kafka重新消费

我们当前项目用的是改良版Lambda：实时链路做秒级大屏和告警，离线链路做T+1的精准对账。两套数据用离线结果做基准进行对比校验。

实时数仓分层

ODS层（Kafka）
  原始数据，一个Topic一个数据源
    ↓ Flink ETL（清洗、去重、打宽）
DWD层（Kafka）
  明细数据，已关联维度、已规范化
    ↓ Flink 聚合
DWS层（Kafka/OLAP）
  汇总数据，如每分钟UV、每小时GMV
    ↓
ADS层（OLAP引擎）
  应用层，直接给报表/API

Kafka分层 vs OLAP直出

方案	说明	优点	缺点
Kafka分层	DWD/DWS都用Kafka Topic	可复用、可回溯	链路长、排查难
OLAP直出	ODS清洗后直接写Doris	简单、链路短	复用性差

我在元宇宙社交公司搭的实时数仓用了完整的Kafka分层：ODS→DWD→DWS都是Kafka Topic。好处是DWD层可以被多个下游复用。但链路长了之后排查问题很痛苦，一个数据异常要从ADS追到DWS追到DWD追到ODS。

当前短剧出海公司因为团队只有3个人，用了OLAP直出：ODS Kafka→Flink清洗→直接写Hologres。简单粗暴但够用。

技术选型

层级	推荐技术	原因
消息队列	Kafka	生态最好，Flink深度集成
计算引擎	Flink（SQL为主）	实时计算事实标准
OLAP引擎	Doris/StarRocks/Hologres	实时写入+高并发查询
元数据	Atlas/自建	血缘追踪很重要

面试回答模板

「我们的实时数仓是改良版Lambda架构，实时链路做秒级指标和告警，离线链路做T+1精准对账。

实时分层用了ODS(Kafka)→DWD(Flink清洗+Kafka)→ADS(Doris)的结构。DWD层通过Kafka中间层实现数据复用。

技术选型：Kafka做消息队列，Flink SQL做计算，Doris做OLAP查询。选Doris是因为它支持实时写入+高并发查询+UPSERT语义，天然适合实时数仓。」

📌 总结

记忆点	内容
Lambda	离线+实时双跑，结果可能不一致
Kappa	只保留实时，Kafka回溯历史
实时分层	ODS→DWD→DWS→ADS，和离线类似
Kafka分层	可复用可回溯，但链路长
OLAP直出	简单但复用差，小团队适用

▶ 下一篇预告：DAY 14 Flink+Kafka最佳实践

Wood聊大数据 | 9年大数据老兵，聊技术、聊职场、聊成长

小红书正文

实时数仓到底怎么架构？两种主流方案各有取舍。

Kafka分层（ODS→DWD→DWS都用Kafka Topic）：DWD可以被多个下游复用，能回溯。但链路长排查痛苦。

OLAP直出（Kafka→Flink→直接写Doris）：简单链路短。但复用性差。

我两种都用过。在元宇宙公司搭了完整Kafka分层，当前出海公司3个人用OLAP直出。没有银弹，团队规模和业务复杂度决定选哪种。

架构选型核心：小团队选简单的，大团队选可复用的。