题目重点：围绕已知的金融领域 sales pitch 要求，组织客户问题、最小数据路径、可运行演示、风险边界与时间控制。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 以下以金融机构‘日内交易风险可见性’作为演练场景，不宣称为原题指定客户或 Databricks 产品承诺；真实 panel 应先以收到的题目/JD/可用环境替换。
- Demo 使用脱敏或合成数据，不放真实客户信息；以一个端到端价值闭环为最小目标，不试图一小时展示全平台。
解题路线
- 先用 1 页说明客户当前问题、决策人、成功指标与不能妥协的安全/合规边界。例如交易事件延迟、数据质量与审计追踪；若客户未给数值，以‘需确认’标注，不说成已达标。
- 架构只画 MVP 必要路径：批/流摄入→原始保留→清洗/校验→可查询表→风险指标/仪表盘；每条箭头说明 schema、重放/幂等、权限和数据水位。把增量更正、迟到与删除如何进入指标讲清楚。
- Demo 选一个能稳定运行的故事：导入小型合成交易集，展示一条脏数据被隔离、一条更正事件被正确计入，以及分析查询/图表随数据更新。事前固定输入、准备备用截图/录屏，网络失败时仍可解释验证结果。
- 销售叙事要把功能对应可衡量结果：更快发现风险、减少人工对账或缩短分析等待，而非堆功能名。列出试点范围、验收指标、费用/资源假设、数据治理与下一步扩展。
- 时间安排按价值倒排：开场目标→架构→关键 demo→风险/取舍→问题。Panel 中途追问先回答与主线的关系，再标记稍后深入；若时间紧，优先保住一个完整 demo 闭环和可核成果，而非所有幻灯片。
手动走一遍
演练用 1000 条合成交易：一条缺 currency 的事件进隔离表，一条撤销交易用稳定 transaction_id 抵消原额，仪表盘只展示截至 watermark 的净额。Panel 若问为什么实时结果与账务系统不完全同步，应展示延迟水位与对账机制，而不承诺不存在的强一致。
规模与取舍
这不是单一算法题；MVP 数据规模、事件速率和查询 SLA 未给，容量设计应根据实际 panel 输入估算。时间预算可把 demo 控在约 10–15 分钟作为练习建议，非题目硬性要求。
易错点与追问
容易失分的边界
- 捏造客户痛点或产品功能承诺。
- 只有架构图没有可运行/可解释的最小演示。
- demo 依赖真实敏感数据。
- 忽略迟到、更正与审计，金融指标不可信。
- 时间全花在背景介绍，来不及展示价值闭环。
继续深挖
- 如何证明 PoC 的业务价值？
- 脏数据、撤销交易与迟到事件如何影响指标？
- 客户只给两周试点时间，删掉什么？
- 如何估算平台成本与验收门槛？
- Demo 当场失败怎么继续说明设计？
