在做实时数仓时，你认为比较复杂的一个需求是什么？

❌ 错误干燥版（低分示范）

我觉得实时数仓里比较复杂的是多源数据实时关联和精确去重的需求，一般用 Flink 的水位线处理乱序，维表关联做多维度拼接，再用 Bitmap 做去重就可以解决，也没什么特别难的。

如果你这么回答，你就完了！（面试官根本不清楚你在说什么？也不清楚你做的内容是什么？更不清楚你需求的难度！根本体现不了你高超技术的万分之一！）

✅ 叙事式高分版（结合真实项目经历）

要说我遇到过最复杂的实时数仓需求，是去年 618 大促前 3 周接的电商全域用户实时标签构建需求，当时业务方要做实时个性化券推送 + 直播间定向福利发放，要求苛刻到什么程度呢：标签端到端延迟不能超过 2s，要覆盖 APP / 小程序 / 线下 POS / 抖音直播间 4 个渠道的用户行为，和离线数仓 T+1 的用户标签口径误差不能超过 0.5%，还要扛住大促峰值 20 万 / 秒的埋点流量，出一点问题可能就是几百万的营销预算浪费。

当时做的时候踩了特别多坑，核心难点有三个：
第一是多源数据的乱序和一致性问题，不同端的上报延迟差特别大，抖音端的埋点甚至经常有 5 分钟以上的迟到数据，而且重复上报率最高能到 15%，如果直接按普通的实时流程算，标签的准确率根本不达标；
第二是维表实时关联的热点问题，用户的会员等级、活动分组标签存在 MySQL 里，大促前运营会批量给几十万用户打上 “618 活跃用户” 的统一标签，关联的时候这个 key 直接倾斜，压垮了 3 个 SubTask，背压直接把整个作业堵死；
第三是口径对齐问题，业务方之前用了 2 年的离线标签，所有的营销预算核算都是按离线口径来的，要求实时标签的计算逻辑必须和离线完全一致，哪怕是边界场景比如用户凌晨 24 点前后的行为归属，两边算出来的结果差一点都不行。

我们当时的解决方案是：

1. ODS 层统一用 Flink CDC 接所有埋点数据和维表变更数据，用事件时间 + 3 分钟允许迟到 + 侧流输出兜底，每天凌晨自动跑对账任务，把实时侧流输出的迟到数据和离线 ODS 层做对比，保证数据完整性；去重用 RoaringBitmap 存用户行为的唯一标识，比普通的 Set 去重省了 70% 的内存，准确率 100%；
2. 处理维表倾斜的时候，我们把大促期间的热点 key 先做标记，关联的时候给热点 key 加 100 以内的随机前缀打散，聚合完再把前缀去掉合并，直接把倾斜 SubTask 的负载从 100% 降到了 30%；
3. 口径对齐这块我们直接把离线 Hive 里用的 UDF 逻辑重构成了 Flink UDF，两边完全复用同一套计算逻辑，还搭了个小时级的校验任务，只要实时和离线的标签误差超过 0.3% 就立刻报警，提前排除了 17 个边界逻辑的不一致问题。

最后上线的结果也特别好：618 当天峰值到了 27 万 QPS，标签延迟稳定在 1.2s 左右，和离线标签的最终误差只有 0.21%，完全达标，业务方用这个标签推的券转化率比去年高了 18%，算下来省了差不多 210 万的无效营销预算。后来我们把这套方案沉淀成了公司实时标签的通用模板，现在做新的实时标签需求，只要 1 周就能上线，比之前快了 3 倍。

这个需求最复杂的地方其实不是技术实现本身，而是要在极低的延迟、极高的准确性、极端的峰值流量之间做平衡，还要和业务方反复对齐口径，提前预判大促的各种极端故障，做足降级预案，反而比单纯写 SQL 做实时计算要难得多