小红书数据开发与数据分析岗面经合集：Flink、数仓建模与增长归因

《面试题目》

面经 01 · 小红书数据开发与数据分析岗（2026-09-17）

1. 聊项目，希望了解对业务的理解、建模思路，以及建设过程遇到的问题
2. 聊下 AI 相关项目，实习或者自学过程中的探索实践
3. 平时自己会使用哪些 AI 工具？
4. 你有没有做过有意思的 AI 相关实践？

面经 02 · 小红书数据开发与数据分析岗（2026-01-03）

5. Flink 的窗口触发机制是什么？精确一致性如何保证？触发器实现原理是怎样的？
6. StarRocks 的元数据知道吗？元数据是存在哪个地方？和 Hive 的元数据有啥区别？
7. 实时指标对于时间你这边用的是哪个？对于一个埋点日志，如果需要不同的时间维度你怎么设计这个埋点表，如何实现？

面经 03 · 小红书数据开发与数据分析岗（2025-11-13）

8. 查询最近一年连续登录超过 7 天的用户（限时 10 分钟）
9. 实习中业务项目从数仓建模到落实的每个环节行动
10. 你觉得数仓建设的标准是什么？怎么判断数仓做得好还是不好？
11. 了解一些大数据引擎的原理和源码吗？
12. 讲讲 Spark 的原理

面经 04 · 小红书数据开发与数据分析岗（2025-10-29）

13. 你如何为一次品牌合作（蒲公英下单／先审后发）建立“曝光→互动→搜后→到店／下单”的转化漏斗？关键指标与计算口径如何避免“自然／商业流量”混淆？（可涉及“搜索直达／灵犀”等产品位）
14. 若出现某类目笔记的“完读率与停留时长下降但 CTR 上升”，你如何判断是曝光分配、内容供给还是作弊／违规触发所致？你会落哪些快速验证实验？
15. 在小红书里，搜索已成为用户“带着任务”的关键入口。请设计“搜索→点进笔记→收藏／分享／询单”的评估框架，并说明如何用 query intent（交易／导航／信息）指导内容与流量策略
16. 平台对“品牌合作／商业化”有明确规则（含社区规范与品牌号运营规范）。当品牌要求“弱化广告感知”时，数据侧如何做“标注识别、合规模型与抽检复核”？
17. 面对“引流到站外／刷量／诱导”等违规模式，你如何从数据侧识别异常（会话密度、行为序列、设备／网络指纹）并做在线／离线联动？
18. 在信息流／搜索的高并发实验环境，如何避免实验相互干扰（人／会话／入口聚类随机）、指标被“外溢／串扰”？
19. 一次 8 周种草活动后，品牌质疑“自然声量本就上升”。你如何用倾向得分匹配（PSM）或双重差分（DiD）做效果归因？
20. 描述你会如何用 Python + SQL 建立周更的“品牌经营看板”数据管道（增量抽取、幂等、回灌修复），并在 Excel 输出多视角仪表盘
21. 结合官方流程（定向邀约→多级审核→发布→数据回收），你会如何设计数据表（订单、审核、内容、曝光、互动、交易）与延迟补数机制？
22. 你如何综合“内容质量（完读／二跳／收藏率）+ 商业合作效果（询单／转化）+ 合规风险”对创作者打分？

《参考解析》

Flink 窗口与精确一致性：分三层讲清楚

窗口触发这层要讲到 Watermark 与 Trigger 的配合：事件时间窗口由一个 Watermark 推进，默认的 EventTimeTrigger 在 Watermark 越过窗口末尾时才触发计算；此外还有按条数触发的 CountTrigger、按处理时间触发的 ProcessingTimeTrigger、以及周期性触发的 ContinuousEventTimeTrigger，实际生产中常常是多个触发器组合（比如“早触发但不清理、等到水位线到了再最终计算”）。迟到数据靠 allowedLateness 允许窗口保留一段时间重算，超出允许范围的从侧输出流单独接出来做补偿。

精确一致性要分端到端三段说：Flink 内部靠 Checkpoint 的屏障对齐与状态快照，保证算子状态在故障恢复后不重不漏；但真正决定结果的是 Sink——要么用支持两阶段提交的 Sink（写临时位置再提交，如 Kafka 事务、HDFS 临时文件改名），要么在幂等存储上按主键覆盖写。只做 Checkpoint 而不处理 Sink，重启后照样会重复写。触发器实现原理就落在这几个回调上：onElement 处理每条元素、onEventTime 与 onProcessingTime 处理时间推进，返回 FIRE 触发计算、PURGE 清空窗口状态、CONTINUE 继续等待。

StarRocks 与 Hive 的元数据差异

StarRocks 的元数据由 FE 自己管理：库表结构、分区分桶、副本分布、物化视图、权限等都保存在 FE 的元数据目录里（内存中提供查询、并落盘持久化），BE 只负责数据存储与计算，所以它是自带 catalog 的存算一体架构；如果要用外部数据，就通过 External Catalog（如 Hive Catalog）去对接 HMS，此时表结构仍来自 Hive。

Hive 的元数据不在自己进程里，而是存在一个关系型数据库（常见是 MySQL），由 Hive Metastore 服务统一读写，它描述的是库、表、分区、字段、SerDe 这类“数据在哪、长什么样”的信息，真正的数据在 HDFS 或对象存储上。两者的核心区别就在职责：Hive 的元数据只是目录，不管理数据分布与副本；StarRocks 的元数据同时承担数据分片与副本调度的职责，因此它的元数据规模和变更成本都更敏感（比如分桶数一旦定错，改起来要重建表）。

埋点表的时间维度设计

先分清几个时间：事件时间（客户端实际发生的时刻）、上报或接收时间（服务端收到请求的时刻）、入库或处理时间（真正落到数仓的时刻）。实时链路用事件时间计算业务指标（否则乱序会算错），排查延迟与丢失用接收时间和入库时间，两者差值就是链路延迟。跨时区场景统一用 UTC 存储、查询时按业务时区转换，别在不同环节混用本地时间。

一份埋点日志要支持多个时间维度，正确做法是在明细表里同时保留这几个时间字段并按事件时间做分区（配合小时级分区支持回溯），查询侧按需选择，而不是为每个时间维度各建一张表或把时间展开成多列。乱序与重复靠事件唯一 ID 加去重逻辑处理，业务时间字段（比如笔记发布时间）与发生时间分开存，便于做“行为发生在内容发布后 N 天”这类窗口分析。

SQL 题：最近一年连续登录超过 7 天

标准解法是“日期减去序号”分组：先对用户按登录日期去重（同一天多次登录只算一次），再用 row_number 按用户分区、日期升序编号，用登录日期减去编号得到一个“分组键”，连续登录的日期会得到同一个键，最后按用户加分组键统计天数并筛出大于等于 7 的。这一年范围的过滤要加在日期上，且注意跨年跨月不能用月份参与计算，必须用完整的日期。

限时题先写骨架再补边界：去重用 distinct 还是 group by、是否需要输出连续区间的起止日期、是否要求“最近一年内有任意一段连续 7 天”而非“最近连续 7 天”，这三个问题先问清再动手。写完主动说明索引与扫描量（按日期分区裁剪），以及数据量大时用窗口函数加分组聚合比自连接高效。

数仓建模与 Spark 原理

数仓建设标准可以按三层说：分层清晰（ODS 贴源、DWD 明细、DWS 汇总、ADS 应用，层间只允许单向依赖）、模型规范（维度建模、一致性维度与总线矩阵、缓慢变化维处理）、指标治理（原子指标与派生指标分离，每个指标只有一个口径来源，口径写进指标字典）。判断数仓做得好不好，给三条可验证的判据：贴近业务（业务问题能不能直接查出来）、数据准确（口径一致、能对账、时效达标）、灵活可扩展（新增需求改动面小、不需要重跑全量）。原帖里那位面试者的回答方向是对的，但最好每条都配一个自己项目里的例子。

Spark 原理按四块讲：RDD 的血缘关系构成 DAG，遇到宽依赖（shuffle）切分 Stage；Driver 把 Stage 拆成 Task 交给 Executor 执行，Task 数量由分区数决定；性能瓶颈几乎总在 shuffle，所以要说清 map 端预聚合、分区数设置、数据倾斜的处理（加盐打散、两阶段聚合、广播小表）；上层 SQL 走 Catalyst 做逻辑与物理优化（谓词下推、列裁剪、Join 重排序），运行时还有 AQE 做动态合并分区与倾斜处理。

转化漏斗与口径：自然流量与商业流量必须分开

品牌合作的漏斗（曝光→互动→搜后→到店／下单）第一步是把商业化标识打准：是否蒲公英下单、是否走先审后发、内容是否带品牌组件。有了标识才能把“自然流量”与“商业流量”分开统计，否则商业化带来的曝光会被算作自然增长，品牌方和自己都会看错。“搜后”这个环节最容易出问题，要明确定义（比如曝光后 N 天内是否搜索了品牌词或品类词）、明确归因窗口与去重规则，并说明多触点情况下的分摊方式。

“完读率下降但 CTR 上升”是个典型的信号冲突题，先排除口径与曝光结构变化（推荐位变化、人群变化），再看内容供给（是否涌入了标题党型的低质内容），最后查作弊与违规（机器点击、诱导点击、异常会话）。验证手段要小步快跑：拆分人群与位置的对照实验、把可疑内容做小流量下架、对比作弊识别模型命中前后的指标差异。

归因与实验：PSM、DiD 与串扰处理

品牌质疑“自然声量本就上升”，本质是要求做因果而不是相关。双重差分的前提是有处理组与对照组，并且两者在投放前趋势平行——所以要先把城市或人群分成投放与未投放两组，检查投放前的趋势曲线是否平行，再看投放后两组差值的变化；不平行就要换对照组或改用合成控制。倾向得分匹配解决的是“处理组与对照组本来就不可比”的问题：用特征拟合出每个用户或城市的投放概率，再按得分匹配出可比的对照样本，匹配后再比较，并做匹配前后的平衡性检验。

两个方法经常一起用：先用 PSM 构造可比样本，再做 DiD 估计增量，最后做安慰剂检验（把投放时间提前到未投放期，看是否也能算出“显著”效果）来验证稳健性。报告时给增量的绝对值与置信区间，而不是只给百分比提升。

实验串扰在高并发环境里几乎必然发生，处理办法按干扰来源选：用户维度分流能挡住大部分位置差异干扰，但挡不住社交传播与内容供给侧的相互影响，这时要用聚类随机（按城市或社区）或时间片轮换（switchback）；同时保留全局 holdback 做长期对照，给关键指标设护栏，避免单个实验把大盘生态指标带坏。

项目深挖、看板管道与创作者打分

项目深挖用四段式讲：业务问题是什么、建模与指标口径怎么设计、落地过程遇到什么坑（数据延迟、口径歧义、上游变更）、最后的结果与你的判断。面试官问“建设过程遇到的问题”，想看的是你解决真实工程问题的过程，而不是模型图画得多漂亮。

周更看板管道的关键词是幂等与可回灌：抽取按分区增量拉取并记录水位线，写入按主键覆盖或分区覆盖保证重跑幂等，出错时能按分区回灌修复；调度上加数据质量校验（行数波动、主键唯一性、指标突变）并让失败可见。多视角仪表盘只是最后一层，把不同视角（品牌、内容、人群）整理成同一份口径的宽表再出图。

创作者打分是个多目标问题：内容质量（完读、二跳、收藏率）反映用户认可，商业合作效果（询单、转化）反映客户价值，合规风险是扣分项甚至否决项。合理的做法是先各自归一化再按业务目标定权重，风险项设一票否决或强扣分，并且要防止指标反噬——一旦创作者知道打分权重，就会按权重优化，所以要定期调整权重并保留人工抽检。