实时项目怎么讲才能展示深度——实时项目表达模板
先说结论
实时项目讲三个核心点：① 为什么需要实时（业务驱动不是技术驱动——'运营需要5分钟内看到投放效果'而不是'我们想用Flink'）；② 架构怎么设计（数据流向+每个组件的选型原因）；③ 难点怎么解决（Exactly-Once/延迟/乱序/反压——至少讲一个你实际解决过的）。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
实时项目是面试的加分大项——因为实时架构比离线复杂得多，能讲好实时项目说明你有架构能力和技术深度。但很多人讲实时项目就是念技术栈：'我们用Kafka做消息队列、Flink做实时计算、Doris做OLAP查询'——这和背PPT没区别。面试官想听的是：为什么要做实时、架构怎么设计的、遇到了什么难点、延迟多少、怎么保证数据不丢不重。
实时项目的STAR模板
S：'在某元宇宙社交公司负责实时数据平台。业务是虚拟礼物交易——用户在App里送虚拟礼物，涉及充值、消费、提现。之前数据是T+1的——运营第二天才能看到昨天的交易数据，发现异常（比如某个礼物被刷单）已经晚了。'
T：'我的任务是搭建实时数仓，把交易数据的时效从T+1提升到分钟级，支撑实时大盘和实时风控。'
A：'我从0设计了Flink+Kafka+Doris的实时数仓架构：① Kafka作为数据总线——App的埋点数据和交易日志实时推送到Kafka（日均5000万条）；② Flink做实时ETL——清洗、维度关联、指标聚合（Event Time+Watermark处理乱序、Checkpoint保证Exactly-Once）；③ Doris做实时查询层——Flink聚合后的结果实时写入Doris，运营在Metabase上查看实时大盘。分层设计：Kafka是实时ODS，Flink输出到Doris的实时DWD/DWS。'
R：'端到端延迟从T+1降到5分钟以内。实时大盘支撑了运营/产品/风控三个团队的日常监控。发现了3次刷单异常——之前T+1时已经损失了几万元，实时后5分钟内就能发现并封禁。'
架构图怎么画/怎么讲
面试时面试官可能让你画架构图。画图不要画得太复杂——抓住数据流向，每个组件标明输入输出：
# 实时数仓架构图（面试画白板版）
#
# App埋点/交易日志
# ↓ （实时推送）
# Kafka（消息队列/实时ODS）
# ↓ （Flink消费）
# Flink（实时ETL）
# ├── 清洗+维度关联 => Doris（实时DWD）
# ├── 窗口聚合 => Doris（实时DWS）
# └── 规则匹配 => 风控系统（实时告警）
# ↓
# Doris（实时OLAP查询）
# ↓
# Metabase（实时大盘）
#
# 画完后讲三件事：
# 1. 数据流向（从左到右或从上到下）
# 2. 每个组件的选型原因（为什么选Doris不选ClickHouse）
# 3. 你在哪个环节做了什么（不是每个环节都讲，讲你负责的）实时项目面试官必追问的问题
| 追问 | 标准回答 | 我的实际回答 |
|---|---|---|
| 延迟多少？ | 端到端延迟+各环节延迟 | '端到端5分钟，Kafka到Flink 200ms，Flink处理2秒，写入Doris 1秒' |
| 怎么保证不丢数据？ | Kafka ACK+Flink Checkpoint | 'Kafka acks=all + Flink Checkpoint间隔60秒 + Exactly-Once' |
| 乱序数据怎么处理？ | Event Time+Watermark | 'Watermark设30秒延迟，超过的数据走侧输出流' |
| 反压怎么处理？ | 监控+扩容+优化 | 'Flink Web UI看反压节点，通常是下游写入慢，加Doris并发' |
| 为什么选Doris不选CK？ | 对比+场景匹配 | '多表JOIN多选Doris，我们有用户维度表需要JOIN' |
实时项目最能展示深度的三个话题
话题一：Exactly-Once的实现——'Flink的Checkpoint+Kafka的事务性Producer+Doris的两阶段提交实现了端到端的Exactly-Once。Checkpoint间隔设60秒是在数据一致性和性能之间的trade-off——间隔太短Checkpoint频繁影响吞吐，太长故障恢复丢的数据多。'
话题二：数据倾斜的处理——'有一个热门礼物的交易量是其他礼物的100倍，Flink的keyBy(gift_id)导致一个SubTask处理了90%的数据。用两阶段聚合解决——先按gift_id+随机后缀keyBy做局部聚合，再按gift_id做全局聚合。处理时间从5分钟降到30秒。'
话题三：State管理——'用户在线状态需要维护在Flink State中。选了RocksDB State Backend——因为用户量500万，HashMap State Backend会把State全放堆内存导致Full GC。RocksDB把State存在本地磁盘，堆内存只做缓存，GC压力大幅降低。'
面试高频追问
追问一：实时和离线数据不一致怎么办？
这是实时数仓的经典问题。我的做法是'实时为主，离线对账'——实时数据用于日常监控和即时决策，离线每天跑一次全量校验对比实时和离线的差异。如果差异超过1%就排查原因（通常是乱序数据或Flink重启导致的短暂数据丢失）。绝对精确的场景（财务对账）以离线数据为准。
追问二：Flink作业挂了怎么恢复？
从最近的Checkpoint恢复——Flink重启后自动加载Checkpoint中的State和Kafka Offset，从上次的位置继续消费。恢复时间通常在1-2分钟。如果Checkpoint损坏就从Savepoint恢复（我们每天手动触发一次Savepoint做备份）。最坏情况从Kafka的earliest重新消费，但这会产生重复数据——靠下游的幂等性或去重处理。
追问三：你觉得这个实时架构有什么可以改进的？
两个改进方向：① Doris的实时写入用的是Stream Load，高频小批量写入导致Compaction压力大（第9篇Doris系列讲过），可以改成Flink攒批后再写入减少写入频率；② 目前实时和离线是两套独立的链路，可以考虑用Paimon/Iceberg做流批一体，一套代码同时支撑实时和离线。
总结
实时项目表达讲三核心：① 为什么需要实时（业务驱动——T+1发现异常已经损失几万元，实时5分钟发现）；② 架构怎么设计（数据流向+组件选型原因，画图讲清楚）；③ 难点怎么解决（Exactly-Once/乱序/倾斜/State管理至少讲一个有深度的）。面试官最爱追问延迟数字和Exactly-Once实现——这两个一定要准备好。
下一篇聊调优项目怎么讲：SQL从6小时优化到40分钟怎么在面试中体现你的价值？
你面试讲实时项目时面试官追问最多的是什么？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长