考察点
这是 OLAP 方向最经典的系统设计题，面试官想看端到端链路能力：数据怎么进、在哪聚合、怎么扛住大屏的高频刷新、口径怎么保证。关键区分点是「大屏直接查 OLAP 明细」还是「预聚合 + 缓存」，前者说明只做过 demo。追问常考端到端延迟拆解、Exactly-once、降级预案。
参考答案
先明确大屏的真实负载特征
设计前先想清楚负载，很多人栽在这里。大屏的特点是：查询 SQL 高度固定（就那十几个指标）、刷新频率高（前端定时轮询，常见 5-10 秒一次）、并发有限但持续（几块屏加运维人员，几十 QPS）、数据新鲜度要求秒级到分钟级、查询时间范围通常是「今天截至现在」。这个负载画像决定了一个核心原则：绝不能让每次刷新都去扫原始明细，预聚合是不可避免的。
标准链路：四层
第一层接入：埋点/业务日志进 Kafka，按主题分流。量大的埋点 topic 提前做好分区规划，按事件类型或租户散列。
第二层流式预聚合：Flink 消费 Kafka，做两层加工。先 ETL 清洗（过滤脏数据、维度补全——维度数据用 broadcast state 或 lookup join 关联），然后按大屏指标口径做窗口聚合：1 分钟 tumble 窗口输出「每分钟 × 各维度」的聚合结果。窗口大小是新鲜度和数据量的平衡点，1 分钟是常见选择；要求更高的可以 5 秒窗口，但下游压力倍增。状态后端用 RocksDB，checkpoint 间隔对齐下游写入节奏。
第三层存储：聚合结果写 Doris（或 ClickHouse），存分钟级粒度。为什么还存 OLAP 而不是直接推缓存？因为大屏常要「任意时间段回看」「临时加个维度」，OLAP 里存多粒度聚合结果（分钟表、小时表、天表，或者用物化视图自动上卷）保住了灵活性。写 Doris 用 Stream Load 攒批，靠 checkpoint 两阶段提交保证 Exactly-once；写 CK 则客户端攒批 INSERT。
第四层服务与缓存：后端 API 层挡一道 Redis。当前分钟的指标查询结果缓存 3-5 秒——大屏轮询再密，真正打到 OLAP 的 QPS 也被削掉一个量级。历史时间段的结果变化少，缓存时间可以更长。这一层是扛住「领导来了十个人同时开大屏」的关键。
口径与一致性怎么处理
实时大屏最容易被业务挑战的是「数字对不对」。几个实战做法：UV 类去重指标，Flink 里用 RoaringBitmap 状态做窗口内精确去重，输出 bitmap 给 OLAP 合并，别用 count distinct 明细硬算；迟到数据用 allowed lateness 加侧输出流处理，大屏可接受分钟级修正，但口径文档要写清「数据会回补」；和业务库对账，离线层 T+1 重算同一指标，差异超过阈值告警——实时链路必配离线校验，这是数仓的基本修养。
降级与容灾
大屏是给老板看的，挂了影响极大，降级方案是加分项。链路断流时：API 层返回最近一次成功结果并标记数据时间，前端展示「数据截至 xx:xx」；Flink 作业挂了，checkpoint 恢复，中间数据缺口由 OLAP 里存的分钟数据补上；OLAP 挂了，Redis 兜底返回缓存值。再进一步，核心指标可以双链路（实时 + 准实时批）互备。
延迟预算拆一笔账
端到端延迟 = Kafka 排队 + Flink 窗口（1 分钟窗口天然最多 60 秒，可用提前触发优化到秒级）+ 攒批写入（秒级）+ 缓存 TTL（3-5 秒）。做到 10-30 秒端到端是合理的工程目标，宣称「毫秒级实时大屏」的多半没扛过真实流量。面试里主动拆这笔账，比空谈架构图有说服力得多。
可能的追问
- 为什么不让大屏直接查 ClickHouse/Doris 明细？—— 刷新频率 × 并发 × 明细扫描量会把 OLAP 打满，一次全量聚合查询可能扫几亿行。预聚合后每次查询只扫几千行分钟数据，成本降四五个数量级。
- Flink 窗口内的精确 UV 怎么做？—— 状态里维护 RoaringBitmap，用户 ID 经字典编码后进位图，窗口结束输出 bitmap 基数；跨窗口合并由 OLAP 的 bitmap_union 完成，全程精确且可合并。
- 要求秒级新鲜度怎么改？—— 窗口缩到 5-10 秒、开启窗口提前触发（early firing）、攒批间隔和缓存 TTL 同步收紧；代价是下游写入频率上升、存储数据量变大，要评估 OLAP 的小批量写入压力。