【场景面试题】七、搜索、推荐、实验与实时计算（61～70）

文章目录七、搜索、推荐、实验与实时计算617061. 搜索索引如何保证和数据库最终一致具体示例62. 如何设计支持亿级商品或内容的全文搜索系统具体示例63. 推荐系统的召回、粗排、精排、重排如何拆分具体示例64. Online/Offline Feature Store 如何保证训练和线上一致具体示例65. A/B 实验平台怎么设计保证分流稳定且指标可信具体示例66. 推荐如何处理多样性、负反馈和频控具体示例67. 客户端埋点采集系统如何保证不丢、不重、可治理具体示例68. 实时计算如何做到端到端 Exactly-once 或可校正具体示例69. 指标看板遇到迟到数据和口径变更如何保证可信具体示例70. 数据质量和血缘系统怎么设计及时发现坏数据具体示例七、搜索、推荐、实验与实时计算617061. 搜索索引如何保证和数据库最终一致场景与难点。内容创建、修改、删除后搜索结果要尽快变化但搜索引擎通常不是事务库。问题在于 DB 成功但索引失败、索引乱序、删除后旧内容仍可搜到。方案。数据库保存权威状态变更通过 outbox/binlog 进入索引服务。索引消息带 resource_versionES/OpenSearch 更新时只接受更高版本。删除先逻辑删除权威状态搜索结果返回前可做状态兜底索引删除异步重试。定期全量重建用于修复漂移。具体示例具体设定。用户把商品标题从“夏季短袖”改成“秋季卫衣”搜索仍命中旧标题。落地例子。商品表更新version18binlog 事件进入索引队列。索引文档_idsku_id写入时携带version18如果迟到的version17到达索引服务丢弃。搜索结果详情页再读商品状态已下架商品不展示。面试可讲。搜索一致性的核心是权威库、版本化事件和可重建索引。不要把 ES 当唯一真实数据源。62. 如何设计支持亿级商品或内容的全文搜索系统场景与难点。全文搜索要处理分词、召回、排序、过滤、权限和实时更新。用户不仅要搜标题还要按类目、价格、地域、库存、发布时间过滤排序。方案。文档进入索引前做清洗、分词、同义词、实体归一化和字段权重。索引按业务或地域分片倒排索引负责关键词召回列式 doc values 支持过滤排序。热门查询缓存第一页低频查询走搜索集群。搜索排序分为相关性、业务权重和个性化轻量重排。具体示例具体设定。用户搜索“苹果耳机”要召回 AirPods、蓝牙耳机同时过滤“有库存、价格 500 到 1500”。落地例子。索引字段包括title_tokens、brand_id、category_id、price、stock_status、quality_score。查询先分词和同义词扩展再倒排召回过滤库存和价格最后按text_score quality_score sales_score排序。面试可讲。搜索不是 SQL like。高质量答案要说倒排索引、字段建模、过滤排序、热查询缓存和索引更新链路。63. 推荐系统的召回、粗排、精排、重排如何拆分场景与难点。推荐要求低延迟和高效果不能把全库内容都喂给大模型排序。需要分阶段压缩候选百万级内容到千级候选再到几十条展示。方案。召回层从关注、协同过滤、Embedding、热门、同城、内容标签等多路生成候选粗排用轻模型快速打分到几千精排用更复杂特征和模型得到 Top N重排负责多样性、去重、频控、广告混排和安全过滤。每层都要有候选量、耗时预算和降级方案。User ContextMulti-channel RecallMerge DedupeCoarse RankFeature FetchFine RankRe-rank: diversity/frequency/safetyFeed Page具体示例具体设定。首页推荐 20 条视频整体预算 120ms。落地例子。召回层 30ms 取 5000 条候选粗排 20ms 选 800 条特征服务 30ms 批量取用户/视频/交叉特征精排 30ms 得到 100 条重排 10ms 控制同作者不连续出现、广告位置和敏感内容过滤。面试可讲。推荐系统的关键不是“用模型”而是分层候选压缩、特征批量获取、延迟预算和降级。64. Online/Offline Feature Store 如何保证训练和线上一致场景与难点。推荐、风控模型常见问题是训练用一套特征线上服务用另一套特征导致效果漂移。还要处理特征延迟、缺失、版本和回放。方案。特征定义集中管理包含 owner、口径、时间窗口、默认值和版本。离线特征写入 Hive/湖仓用于训练在线特征写入低延迟 KV 用于服务二者来自同一套计算逻辑或共享 DSL。训练样本必须按事件时间做 point-in-time join避免使用未来数据。具体示例具体设定。风控模型用user_pay_count_7d训练准确率高线上效果差。落地例子。检查发现训练按自然日离线统计线上按最近 168 小时实时统计口径不同。修复后把特征定义注册为pay_count_7d_v2离线和实时都从同一个窗口定义生成并监控线上缺失率和分布漂移。面试可讲。Feature Store 的价值是口径复用、版本治理和线上线下一致。只说“把特征放 Redis”是不够的。65. A/B 实验平台怎么设计保证分流稳定且指标可信场景与难点。实验平台不仅是随机分流还要保证同一用户稳定进同一组多个实验互不干扰指标口径可信异常可以快速停止。方案。分流使用hash(user_id experiment_id salt)映射到桶实验层管理互斥域和流量。实验配置包含目标人群、分组比例、开始结束时间、owner 和指标。埋点事件带 experiment exposure分析时只统计曝光后行为。实验变更版本化支持冻结和回滚。具体示例具体设定。新推荐模型只放 5% 用户观察点击率和留存。落地例子。实验feed_rank_exp_202607在首页推荐互斥域占 5% 流量A/B 各 2.5%。用户uid888hash 后稳定进入 B 组服务返回推荐时上报 exposure。看指标时只统计被真实曝光的用户避免把没看到实验的人算进去。面试可讲。A/B 实验要讲稳定分桶、互斥域、曝光归因和指标可信。随机分流只是第一步。66. 推荐如何处理多样性、负反馈和频控场景与难点。只按模型分排序容易让内容越来越单一用户点了“不感兴趣”后还继续出现会严重影响体验。频控、多样性和负反馈通常在重排层处理。方案。重排阶段在 Top N 候选上做规则和轻量优化同作者间隔、同类目比例、广告频控、已看去重、负反馈降权。负反馈事件要实时写用户画像和短期屏蔽集合长期进入训练样本。频控规则按用户、作者、内容、广告主多个维度生效。具体示例具体设定。用户连续刷到 5 条同一个作者的视频并点了“不喜欢健身内容”。落地例子。重排规则限制同作者 10 条内最多出现 1 次负反馈写user_negative_tag:fitness24 小时内召回和排序都降权。已看视频进入短期去重 Bloom/Set避免重复推荐。面试可讲。推荐不只是点击率最大化。体验类约束通常在重排层负反馈要实时生效并进入长期模型闭环。67. 客户端埋点采集系统如何保证不丢、不重、可治理场景与难点。埋点来自移动端、Web、服务端网络不稳定、客户端时钟不准、事件可能重复。数据还要支持实验、推荐、风控和 BI口径必须治理。方案。SDK 本地批量缓存事件带event_id、client_time、server_receive_time、user_id、device_id、app_version、experiment_id。接入层批量写日志队列清洗层做去重、校验、补全和路由。埋点 schema 注册新增字段先灰度非法事件进入隔离流。具体示例具体设定。App 弱网下用户连续点击购买按钮恢复网络后一次性上报 20 条点击事件。落地例子。SDK 为每次点击生成 event_id离线缓存最多 1000 条接入层按 event_id 去重清洗层发现 client_time 比 server_time 早 2 小时仍保留两个时间字段。分析点击漏斗时使用 server_receive_time 做实时看板离线报表再按事件时间校正。面试可讲。埋点系统要同时处理可靠传输、schema 治理、时间语义和去重。不要只说“写 Kafka”。68. 实时计算如何做到端到端 Exactly-once 或可校正场景与难点。流计算常被问 Exactly-once但真实系统里 source、state、sink 必须协同才行。很多场景更实际的是至少一次 幂等 sink 离线校正。方案。Source offset、状态 checkpoint 和 sink 事务要绑定提交。写入外部系统时使用幂等键或两阶段提交。窗口计算用事件时间和 watermark迟到事件进入补偿流。重要报表保留离线重算链路用于修正实时结果。SinkState/CheckpointStream JobSourceSinkState/CheckpointStream JobSourceevents offsetupdate statewrite with tx/batch_idcheckpoint offset statecommit success具体示例具体设定。实时统计直播间每分钟付费人数任务重启后不能重复加。落地例子。每笔支付事件有payment_id。Flink 状态按窗口保存去重集合或 bitmapsink 写入room_minute_uv(room_id, minute, batch_id)同 batch 重放覆盖而不是累加。迟到 10 分钟内修正窗口超过阈值进入离线校正。面试可讲。Exactly-once 不是口号要讲 offset、checkpoint、state、sink 幂等或事务。结算级结果最好还有离线重算兜底。69. 指标看板遇到迟到数据和口径变更如何保证可信场景与难点。实时看板追求快离线报表追求准迟到数据、补数、口径变更都会导致昨天和今天的数字不一致。面试官通常想看你是否能定义数据版本和修正机制。方案。指标定义集中管理包含计算 SQL/DSL、时间口径、去重键、过滤条件和 owner。实时指标标注provisional离线 T1 产出final版本迟到数据在可修正窗口内回写新版本。看板展示数据时间、水位和版本重大口径变更保留双口径对比期。具体示例具体设定。今日 GMV 实时看板 1 小时内显示 1 亿第二天离线报表变成 9800 万。落地例子。实时看板按支付成功事件累计离线报表扣除了退款和风控订单。指标平台把gmv_realtime_v1和gmv_final_v2分开页面标注“实时预估不含退款修正”并在 T1 替换为 final 版本。面试可讲。指标可信不等于实时永远精确而是口径清楚、版本可追踪、迟到可修正。比如策略平台任务周期内时实时数据读实时指标而在任务周期结束后使用离线数据做最终的结算。70. 数据质量和血缘系统怎么设计及时发现坏数据场景与难点。坏数据会污染推荐、风控、报表和活动人群发现越晚成本越高。质量系统要知道数据从哪里来、被谁消费、什么时候异常。方案。每张核心表注册 owner、SLA、上游、下游、分区、主键和质量规则。规则包括行数波动、空值率、唯一性、枚举合法性、分布漂移和跨表一致性。调度系统采集任务血缘异常时按影响范围告警下游并支持阻断发布或切到上一版本。具体示例具体设定。user_tag_active_7d某天行数从 3 亿掉到 300 万活动白名单骤减。落地例子。质量规则发现分区行数环比下降 99%自动阻断标签版本发布活动人群继续使用上一版snapshot_v1。血缘系统显示上游 App 埋点清洗任务失败通知标签 owner 和活动 owner。面试可讲。数据质量要有规则、血缘、SLA、阻断和回滚。只靠人工看报表发现通常已经晚了。