题目重点：为租车业务领导层设计仪表盘，从决策频率倒推指标粒度与数据更新。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 先确定领导层要做选址、车队配置、收入运营中的哪类决策，日/周/月频率与责任人；并非把所有数据放同一页。
解题路线
- 访谈stakeholders形成决策清单与可行动阈值，再定义指标合同：收入gross/net、出租率分母、预约/实际取车、取消和跨店订单口径。每个指标要owner、数据源、刷新时间与已知延迟。
- 数据建模按rental事实、car/车型/location日期维度，订单与租赁天数粒度不可混加。refund/late returns修正有版本，历史维表支持当时门店归属。
- ETL验证源记录完整性、unique keys、日期边界与对账，语义层复用公式，dashboard不各自写不同denominator。异常和新鲜度显示出来，空数据与真实0区分。
- 页面先给整体趋势/目标差距，提供城市/车型/门店分解与贡献，不用几十个pie chart掩盖变化。异常可以钻到原因维度但涉及用户明细要权限限制。
- 试用用真实管理问题验能否得到行动，再迭代；监测刷新失败与使用反馈。不要把“有dashboard”当成功，需要检验决策效率、信任与数据争议减少。
手动走一遍
领导看到出租率下降，按city/size拆发现新投放20辆尚未可租却进入分母。指标应区分fleet总量、可租库存和实际租出，并显式显示维护/调拨，而不是图表直接标需求下滑。
规模与取舍
聚合按day×location×carSize通常远小于事件表，刷新成本由增量变化决定；历史修正需重算受影响分区。权限与公式集中减少重复维护，技术延迟预算依据决策周期。
易错点与追问
容易失分的边界
- 先做可视化再问决策，往往生成无法行动的漂亮图。
- 不同页面以不同库存分母比较出租率，失去可信度。
继续深挖
- 实时运营与月度财务数据延迟不同，怎样展示provisional/final？
- 指标定义变更时如何版本化避免历史曲线突然断裂？
