题目重点：建立私密账号与关注请求数据模型，解释不同动作的活跃口径、重复事件、互相关注及双跳好友候选。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练定义“活跃”=业务日内至少一个成功且可计数的指定动作，动作集由题面给定；浏览、创作和互动活跃是不同指标。私密账号可见性与关注审批不能省略。
- 事件粒度为不可变eventId；request有独立requestId与状态历史，accepted关系记录生效区间。所有时间先统一为UTC存储，再按明确业务时区划日。
- SQL示例口径和字段为训练建模；未提供的完整表DDL与业务动作不会声称就是正式接口。
解题路线
- 先分离entities：user、account_privacy_history、follow_request、follow_relation_history、content、interaction_event。请求多次发送是多个请求事实，关系是否有效依据accept/revoke状态，不能把request_created直接join成好友。
- active SQL先按eventId去重到唯一最新有效版本，再过滤success、action_set和事件业务日期；最后按(userId,day)去重计数。需要按当前用户去重还是日活累加必须澄清，跨类型UNION ALL后只求COUNT(*)会重复用户。
- 互相关注用同一snapshot时刻的有效边a→b与b→a自连接，条件a<b只输出一对；私密用户的pending请求不算边，blocked与deleted账户需排除。对双跳推荐从u→v→w扩展，去掉u、现有好友、被屏蔽和无权限候选，按sharedNeighbors去重计分。
- 互动下降先检查埋点、动作口径、隐私设置比例、关系审批漏斗、内容供应和活跃分母；按新老用户/地区/客户端版本切片，再用可检验假设区分用户意愿下降与可见内容减少。
- late event由eventTime归属原业务日，watermark之后走可重放backfill。报表保留runId与数据版本，日终重算受影响的(user,day)键，不能把迟到事件全部塞进到达日。
手动走一遍
同一用户当天like与comment两条事件，like因重试重复上传，活跃用户仍是1。A申请关注私密B但未通过，不构成A→B边；通过后才可能参与双跳候选。A→B、B→C而A已关注C，则C需从候选中剔除。
规模与取舍
E个去重事件做日活聚合约O(E)扫描及分组，索引/分区减少日期范围读取；互相关注自连接规模取决于有效边；双跳展开最坏Σdeg(v)，高出度节点需要上限、采样或预聚合。精确结果与截断策略不能混称。
易错点与追问
容易失分的边界
- 隐私是查询权限约束，推荐候选过滤不能只在客户端显示时再做。
- 当前关注表不能正确回答去年某天的关系；历史分析需要有效区间或快照。
- 把全部事件数量作为活跃人数，会同时受到重复与一个用户多动作的影响。
继续深挖
- active creator与active user如何分开？动作集合包含发布成功才属于creator口径，不能沿用所有互动动作。
- 若新privacy功能改变可见内容，A/B单位应如何考虑社交图干扰？按社区/地区实验或明确外溢假设，不能默认用户随机化完全独立。
- 两跳统计由重复路径还是独立共同好友计分？采用COUNT(DISTINCT intermediaryId)，防止重复边导致虚增。
