数据工程面试：一个「活跃会员」怎么算，比报五个框架名有用

《面试题目》

1. 在 AI 应用服务商做数据工程，你具体干过什么？
2. 「活跃会员」这个指标怎么算？
3. 同一个指标，市场部、会员部、运营各有一套算法，怎么统一？
4. 一张上游表出问题，怎么在十分钟内说清影响了哪些指标和报表？
5. 数据质量怎么管？你怎么知道数据错了、错了多久才发现？

《参考解析》

指标口径：所谓口径，就是把分子、分母、时间窗、去重键、排除条件五项写在同一处，谁都不许另写一遍。落到工程上是把每个指标做成一条结构化记录——指标编号、定义、所属域、负责人、版本、生效时间，报表只引编号，由指标引擎按版本拼 SQL。改口径等于发新版本，而不是去改十几张报表里的 SQL。字段名可以乱，指标编号不能乱；口径变更要带影响面清单，否则改一个定义会静默打断下游所有看板。面试里被追问「为什么三个部门三个数」，答「因为口径没落到一处、每个人在自己 SQL 里重写了一遍」比答「沟通问题」有说服力。

数据血缘：表级血缘不够用。一张两百个字段的宽表，表级血缘只会告诉你它被三十个报表引用，回答不了「哪个字段坏了、哪些指标会空」。要做列级映射：同步任务写出时登记字段对应关系（源表.字段 → 目标表.字段 → 指标编号 → 报表/智能体 → 任务上下游），动态 SQL 解析不出来的用运行时读写补上。索引分四层，从任意一层进入都能在十分钟内出清单：表到字段、字段到指标、指标到报表、任务到上下游。反查必须是常驻服务，不能临时写脚本——真出故障的时候没人有时间写脚本。

数据质量：重点不是「数据对不对」，而是「错了多久被发现」。月度抽检发现的是上个月的问题，要管的是发现时延。落地做法是每日异常检测：核心指标留六十到九十天基线，按星期几分桶（周末和工作日的量级本来就不一样），波动超过若干倍标准差就报。阈值三倍在促销期误报太多，四到五倍或改用分位数更稳；告警条数本身也要当指标管，一天超过五条就去调阈值，否则人会开始无视告警。再叠三条硬规则兜底：主键重复、空值率突增、枚举值冒出新值。所有预警挂在指标上而不是挂在表上，这样一条告警能直接指到业务区域和日期。

先后顺序：先口径、再血缘、质量第三。没有血缘，告警响了只能挨个问下游；没有口径，血缘告诉你「影响三个报表」，但说不清影响的是什么业务含义。适用边界也要能讲清：只做报表不做治理的团队会退化成取数工，表少于一百张的团队做血缘是过度设计。面试里被问到做过什么，能说清一个指标从定义到报表的完整链路，比报五个框架名有用。