实时数仓分层怎么做？Flink+Kafka+Doris的架构设计

Flink手册第 16 题约 4 分钟读完

先说结论

实时数仓的分层和离线类似，但存储介质不同：

ODS层（Kafka）： 原始数据接入，从MySQL Binlog、埋点、第三方API采集

DWD层（Kafka）： Flink做实时清洗：字段标准化、维度关联、过滤异常值

DWS层（Kafka/Doris）： Flink做实时聚合：按时间窗口聚合的指标，写入Kafka或直接写Doris

ADS层（Doris）： 应用层的宽表，直接服务报表和看板

先把这段讲顺；面试官追问时，再展开下面的原理和细节。

详细讲解

实时数仓是近几年大数据面试的热门话题。很多人能说出“Kafka+Flink+OLAP”，但说不清楚“每一层具体做什么、为什么这么分”。我在元宇宙社交App从0搭过一套完整的实时数仓，今天把架构设计的思路和每层的职责讲清楚。

架构图详解

数据源                ODS(Kafka)          DWD(Kafka)          DWS           ADS(Doris)
──────────────────────────────────────────────────────────────────────
MySQL Binlog ──→ ods_order_binlog ─Flink→ dwd_order_detail ─Flink→ dws_gmv_1min ─→ ads_realtime_gmv
埋点SDK   ──→ ods_user_event   ─Flink→ dwd_click_detail ─Flink→ dws_pv_1min  ─→ ads_realtime_pv
广告API   ──→ ods_ad_callback  ─Flink→ dwd_ad_attribution                    ─→ ads_ad_roi

每层的Flink作业具体做什么？

ODS→DWD（清洗作业）：

-- Flink SQL示例：订单明细清洗
INSERT INTO dwd_order_detail
SELECT
o.order_id,
o.user_id,
  u.country,          -- 关联用户维度表
o.amount,
o.currency,
CASE WHEN o.currency = 'USD' THEN o.amount
WHEN o.currency = 'JPY' THEN o.amount * 0.0067
ELSE o.amount * rate.exchange_rate
END AS amount_usd,  -- 统一币种
o.order_time
FROM ods_order_binlog o
LEFT JOIN dim_user FOR SYSTEM_TIME AS OF o.proc_time AS u  -- 维度表Lookup Join
o.user_id = u.user_id
LEFT JOIN dim_exchange_rate FOR SYSTEM_TIME AS OF o.proc_time AS rate
o.currency = rate.currency
WHERE o.status = 'paid' AND o.amount > 0;  -- 过滤异常数据

注意 FOR SYSTEM_TIME AS OF 语法——这是Flink SQL的Temporal Join（时态Join），用于实时关联维度表。它会查询维度表的“当前值”，不需要双流Join。

DWD→DWS（聚合作业）：

-- 每分钟按国家统计GMV
INSERT INTO dws_gmv_1min
SELECT
country,
TUMBLE_START(order_time, INTERVAL '1' MINUTE) AS window_start,
SUM(amount_usd) AS gmv,
COUNT(DISTINCT user_id) AS buyer_count
FROM dwd_order_detail
GROUP BY country, TUMBLE(order_time, INTERVAL '1' MINUTE);

实战经验：为什么中间层用Kafka而不直接写Doris？

我在元宇宙社交App的设计经验：DWD层用Kafka而不是Doris，原因有三个：

解耦： DWD层的数据可能被多个下游消费（不同的DWS聚合作业）。写Kafka可以多个消费者，写Doris只能被查询
缓冲： Kafka可以充当缓冲，即使下游Doris挂了，数据不会丢
回溯： Kafka有保留期，可以回溯重新处理

总结

实时数仓分层：ODS(Kafka)→DWD(Kafka)→DWS(Kafka/Doris)→ADS(Doris)。中间层用Kafka而不是Doris是为了解耦、缓冲、回溯。DWD层用Flink做清洗+Temporal Join关联维度表。DWS层用窗口聚合。面试时能画出架构图、说清楚每层的职责和技术选型理由，就很有架构思维。

下一篇聊一个越来越流行的新方案：Flink CDC直接读MySQL Binlog——替代Canal的新选择。

你们生产环境的实时数仓用的什么架构？评论区聊聊～

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

刷题进度保存在当前浏览器