岗位
数据工程
这些题与问题库里的是同一批，这里按各自主要考察的能力分组。
453 道问题
本页为第 101–150 题，共 453 题。
A · 专业解题与实现19
- 构建仓库需要清理多年积累的镜像，但线上仍有服务依赖旧版本回滚。你会如何确定保留策略和制品可恢复要求？
- 管理后台需要保留不可随意修改的操作记录，既支持按操作者和对象查询，也要应对数据量逐年增长。你会怎样设计写入、索引和保留策略？
- 消费者处理速度低于生产者，消息队列持续增长，但上游仍显示请求成功。你会怎样确定控制上游发送速度应作用在哪一层，并保护系统恢复能力？
- API 延迟升高时数据库 CPU 很低，但应用日志出现等待连接。你会如何区分连接泄漏、池容量不足和慢事务占用？
- 订单写入数据库后需要发布事件给下游；进程可能在任一步骤崩溃。你会怎样设计持久化发布机制，并说明如何处理重复与顺序？
- 管理后台按创建时间翻页时，新增和删除会让用户看到重复或漏项。你会比较 offset 与游标分页，并定义何种一致性预期？
- 一个 API 部署在多个实例后，单机请求限制使总额度随实例数增加。你会根据突发容忍度、精度和故障策略设计请求速率限制，并说明状态放在哪里？
- 某存储服务从读多写少变成持续高写入，团队在 B 树和 LSM 路线间评估。你会根据哪些负载特征比较两者，并关注哪些读写放大代价？
- 组织要把多个仓库从旧的自动构建与检查平台迁到新平台，但团队不能同时停下交付。你会怎样分批迁移，并判断哪些仓库可以进入下一批？
- 一个服务把工作线程数从 16 提到 256 后，吞吐没有提升，CPU 使用率反而更高。你会怎样解释上下文切换可能造成的影响，并用什么证据验证？
- 数据库字段变更完成后，只有部分下游任务间歇性失败。你会怎样找出仍在使用旧接口约定的消费者，并确定回滚还是兼容修复？
- 对账任务发现同一业务对象的事件时间顺序偶尔倒置，日志又分布在多个区域。你会如何判断是时钟偏差、异步延迟还是业务排序规则的问题？
- 月度汇总与明细报表最初一致，几周后差异逐渐扩大。你会如何把问题缩小到规则变更、迟到数据、重复处理或历史回补？
- 消息积压经常在扩容后下降，几小时后又反弹。你会检查哪些生产者、消费者和消息特征，以判断真正瓶颈在哪里？
- 服务平均耗时基本不变，但最慢 1% 的请求连续一周变慢，投诉集中在少数大客户。你会如何定位问题并决定先验证什么？
- 设计一个供多个业务团队提交“在某个时间之后执行”的任务服务，任务可能被取消、改期或重复提交。你会怎样划分数据模型和执行组件？
- 数百个仓库都锁定了不同版本的第三方依赖，安全团队发现高危漏洞时很难知道影响范围。你会怎样建立依赖更新和风险处置机制？
- 一个缺陷只在线上出现，开发和预发环境都无法复现。你会如何判断问题来自环境差异、流量形态还是数据特征，并改进环境设计？
- 多个服务在请求路径中读取功能开关和分群规则。如何设计控制面与本地求值，让控制服务故障时线上行为仍然可预期？
当前目标在这里暂无匹配题。 ·
B · 业务理解与领域建模31
- 合作伙伴预付额度设有期限，客户在到期前后分批使用或退款。你会怎样表达额度、消耗、过期与退款的结算关系？
- 涉及钱的系统，账务和计费应该怎样设计才能算得清、对得上？账户、流水、冻结、结算和对账分别怎样建模，出现差错时怎样追溯和更正？
- 金额、币种、舍入和时区，在交易和结算的模型里应该怎样表达？哪些做法看上去没问题，其实会在对账时出问题？
- 一笔订单可能同时使用会员折扣、渠道优惠和优惠券，适用商品、地区和合同也有例外。你会怎样设计规则，让金额算得一致、用户看得懂，退款后也能核对？
- 平台与创作者的分成比例随月度流水按阶梯变化。你会怎样表达这条结算规则，使产品、研发和财务三方都能独立核对？
- 业务提出“必须实时”的数据需求，但目前没人能说清楚晚十五分钟会造成什么损失。你会如何判断架构和时效目标？
- 产品、财务和增长团队都在报“活跃用户”，但每个数字都不同。你会先问哪些问题，才能确定要不要统一定义？
- 以订单、合同、结算这类商业概念为例，它们是怎样映射到数据模型里的？哪些概念被拆成了多个实体，哪些被合并了，为什么？
- 一个用户曾同意用于产品分析，后来撤回授权；部分派生指标已进入报表、实验和模型训练数据。你会怎样建模授权状态、用途范围与传播关系？
- 数据生产方准备重命名字段并改变枚举含义，下游有十几个团队依赖当前 schema。你会怎样推动这次变更？
- 业务对象会迁移到不同团队，负责人和组织归属也会变化。审计要求按历史日期还原责任人，日常报表则关注当前归属。你会怎样建模这两种查询？
- 用户要求删除个人数据，但财务审计仍需要保留交易记录。你会怎样划定删除、匿名化和可追溯性的边界？
- 一张行为事件表里，“一行”究竟代表什么？请说明你怎样确定它的粒度，以及粒度不清会让哪些统计出错。
- 月结报告已发送给管理层，几天后收到迟到退款和一笔价格更正。业务希望更新当前数字，财务还需要解释上次报告为何不同。你会如何建模？
- 你们业务内部的模型，和行业或合作方通用的模型是怎样交互的？字段、定义或概念对不上时，你怎么处理？
- 移动端事件可能离线数天后才上传，报表又需要按事件发生时间统计。你会怎样建模和处理迟到、更正及重复事件？
- 同一关键数据集被多个产品和报表复用，却没人能说明它的来源、负责人和敏感字段。你会如何补齐治理信息而不阻断现有使用？
- 客户账户在月中从销售转交客户成功团队，月度绩效既要体现当月结果，也要还原每个时点的负责人。你会怎样定义归属事件和统计规则？
- 费用规则今天修改为新规则，但争议订单发生在旧规则生效期间。你会如何保存规则版本与交易事实，让财务能够重现当时的计算？
- 一家公司购买了 100 个席位，实际使用者分属多个子公司；合同由总部签署，部分子公司要求独立账单和权限管理员。你会怎样区分客户、合同、组织、账号、成员和席位，并确保权限与计费规则一致？
- 客户主数据在 CRM、计费和产品系统中各有一套标识和状态，下游报表因此不一致。你会怎样建立可解释的事实来源？
- 一个质量检查偶尔误报，导致下游任务停摆；取消检查又曾让错误数据进入结算。你会怎样设计分级处置？
- 一个模型特征将停止生产，但多个在线模型和历史报表仍依赖它。你会怎样安排退役与替代？
- 一个在线特征需要每秒更新，但它只影响少量请求，且维护成本持续上涨。你会怎样判断是否继续实时计算？
- 一个风险模型使用后续违约作为训练标签，但许多交易在观察窗口结束前没有最终结果。你会怎样处理标签成熟度、样本纳入和回溯评估？
- 为一个预测用户次日是否流失的模型构造“近 7 天活跃天数”特征。你怎样定义这个特征的时间语义，使训练时和线上预测时拿到的是同一个含义？
- 订单上有一个 status 字段，同时表示履约进度和支付结果，多个团队都在读它。你会怎样把它拆成两个概念，并让旧数据和旧使用方平稳过渡？
- 一个服务资格判断从“当前账户状态”改为“申请时的账户状态加风险审核结果”。客服需要解释历史拒绝原因，审计也要求复现当时的判断。你会怎样演进规则和数据模型，避免新旧结果混为一谈？
- 重复注册导致两个客户实体后来被确认属于同一家公司。合并后报表要统一展示，但历史合同、审批、权限和个人操作仍需保留原始责任。你会怎样设计合并关系？
- 业务规则发生追溯更正，报表需要显示修正后的结果，但决策者还要查看当时依据的旧结果。你会怎样管理两种历史视图？
- 生产者新增一个订单状态后，旧消费者因严格枚举校验拒绝整条消息。团队认为应由消费者更新，但多个消费者由不同组织维护。你会怎样设计兼容性和发布顺序？
当前目标在这里暂无匹配题。 ·