# Databricks FDE 面试：Spark、Unity Catalog，以及把模糊目标变成系统的那一轮

> 最值得准备的一轮，考的不是你熟悉多少 API。面试官给出一个模糊的业务目标，看你在大约一小时内怎样把它设计成一套系统。

原文: https://fdetimes.net/zh/guides/databricks-fde-interview-spark-unity-catalog/

设想面试官开场只说一句话：“一家零售连锁想用 AI 留住客户，请设计一下。”没有表结构，没有数字，也没人提截止时间。

根据 Aced.io 的一份面试指南，Databricks 的拆解轮就是这个样子：用大约 60 分钟，从一个仍然模糊的业务目标出发设计一套系统。

这一轮难，是因为它很像真实的工作。Databricks 的高级前线部署工程师（Sr. FDE，Fullstack）岗位描述写道，工程师要与客户一起构建解决其数据和 AI 问题的方案，并推向生产环境。职责部分说得很直白：FDE 负责主导技术项目，交付生产级系统。

所以只刷 LeetCode 是不够的。真正考察的有三项：对 Spark 的深入理解，对 Unity Catalog 治理的掌握，以及把模糊需求转化为架构的能力。下面每一节都附有一个可以自己动手练的例子。

## 五轮面试，其实只考三项能力

Aced.io 的指南描述了五轮流程：30 分钟的招聘方沟通、技术初筛、在 notebook 中写代码的一轮、拆解轮和领导力轮。这是第三方描述，并非官方文档，顺序和时长可能因招聘团队而异。

更可靠的是岗位描述本身列出的要求。首尔岗位要求候选人拥有丰富的 Apache Spark 分布式计算经验，并了解 Spark 的运行时内部机制。

它还要求候选人理解并使用 MLOps、ML/AI 模型和 AI API，并能用多种语言写代码。苏黎世的高级岗位赋予 FDE 架构决策权，前提是方案安全且可扩展。

把这两个来源放在一起看：notebook 轮考 Spark，拆解轮考架构与治理，领导力轮考你如何与客户协作。围绕这三项能力准备，不要把时间平均分给五轮。

## Spark 问题考的是 API 之下的东西

“运行时内部机制”这个说法意味着，面试官希望你能解释作业为什么跑得慢，而不只是写出一个 `join`。经典例子是数据倾斜。

假设你用 `customer_id` 把 `orders` 表和 `customers` 表做 join，Spark 在 shuffle 之后把数据分成 200 个分区。如果某个批发客户占了 `orders` 中 40% 的行，这 40% 会全部落进同一个分区。结果是：199 个任务几秒内跑完，整个作业却在等一个承担了近一半工作量的任务。

好的回答分三步。首先是发现：在 Spark UI 里，同一 stage 中某个任务的运行时间远长于其他任务。其次是原因：shuffle 会把同一个 key 的所有行发往同一处。

最后是解决办法：广播小表以避免 shuffle；给倾斜的 key 加“盐”，把它打散到多个分区；或者开启自适应查询执行，让 Spark 自行拆分过大的分区。

不要只看不练。在 notebook 里造一张倾斜的表，分别记录修复前后作业的耗时。面试时用自己测出的数字来讲，远比背定义有说服力。

## Unity Catalog 是给关心安全的人的答案

Databricks 文档把 Unity Catalog 定义为内置于平台的数据与 AI 统一治理层。被问到时，有两点必须能脱口而出。

第一是三级命名空间 `catalog.schema.object`。在上面的零售问题中，客户特征表可以命名为 `retail.churn.customer_features`。在白板上把名字写清楚，说明你考虑过数据放在哪里、谁可以访问。

第二是血缘。Unity Catalog 会自动追踪数据和 AI 资产如何流动、如何关联，从源数据一直到模型、服务和仪表盘。好处很具体：市场总监问仪表盘上某个数字从哪来时，你不用读代码就能追溯到源表。

**要点:** 治理应当出现在第一版草图里，而不是等别人问起才补上。

## 前十分钟决定拆解轮的成败

Aced.io 的指南建议把开头几分钟用来澄清目标，因为这一轮模拟的是一次真实的客户会议。针对“留住客户”这个需求，可以按这个顺序提问：

“留存怎么衡量：90 天内复购的客户占比，还是平均客单价？”“谁使用输出结果：每周发优惠的市场团队，还是门店员工？”“交易数据现在存在哪里，多久更新一次？”“有没有只允许部分人查看的个人数据？”

假设得到的回答是：市场团队每周发一次活动，数据每晚更新，客户手机号属于敏感信息。在这些条件下，架构几乎自己就成形了。

数据每晚加载到 `retail` catalog，Spark 计算特征，模型给流失可能性打分，结果写入市场团队可读的表。手机号这一列只对活动运营组开放。

画出架构图只完成了一半，另一半是解释为什么选这个方案而不是别的。比如，选择批处理而不是流处理，是因为活动按周进行，实时打分只会增加成本，不会增加价值。

加入 MLOps 式的模型监控，是因为购物行为会随季节变化。指出血缘，是为了说明系统可以审计。

## 投递之前，先选对岗位

Databricks 的三个 FDE 岗位侧重点明显不同，简历应当针对每个岗位分别撰写。

| | FDE（首尔） | Sr. FDE – Fullstack（苏黎世） | AI Engineer – FDE |
|---|---|---|---|
| 侧重点 | Spark 分布式计算，运行时内部机制 | 生产级系统，架构决策 | GenAI 应用 |
| 需要展示的经验 | 深入的 Spark；MLOps、ML/AI 模型、AI API；多语言编程 | 6 年以上数据工程、数据平台与分析或软件工程经验 | RAG、多智能体系统、Text2SQL、微调 |
| 与客户的节奏 | — | 主导客户的技术项目 | 视需要每 4–8 周拜访客户 |

无论申请哪个岗位，简历中的每一条都应写清三件事：一套你推上生产环境的系统、一个实测数字、你如何处理访问控制或数据血缘。例如，“通过修复倾斜把 join 耗时从 X 降到 Y”，分量远远超过“精通 Spark”。

## 让强候选人栽跟头的错误

最常见的错误是一听完需求就开始画架构。面试官扮演的是客户，跳过澄清问题，就相当于面对真实客户时跳过了需求调研。

第二个错误是在 API 层面回答 Spark 问题，而首尔岗位明确要求运行时知识。第三个错误是只有被追问时才提治理，而高级 Fullstack 岗位要求方案从设计阶段就保证安全。

在领导力轮，“我很擅长团队合作”这类泛泛的故事，比不过一个有具体客户、具体冲突、由你拍板做决定的故事。

你不需要把 Databricks 的每个功能都背下来。你需要让面试官相信：如果明天派你带着一个模糊需求去见客户，你会问对问题，选对架构，并留下一套别人能追溯的系统。

**本周动手试试:**

- 在 Spark notebook 中创建一张 orders 表，让某个 key 占 40% 的行，把它和 customers 表做 join，打开 Spark UI 查看每个任务的耗时，再分别尝试 broadcast join 和加盐，对比结果。
- 以“一家零售连锁想用 AI 留住客户”为题，给自己计时 60 分钟：前 10 分钟只写澄清问题，后 50 分钟画数据流，并按 catalog.schema.object 格式给每张表命名。
- 按这个模式改写一条简历：一套你推上生产环境的系统、一个 Spark 性能数字，以及你如何处理访问控制或血缘。

## 信源

- [Sr. Forward Deployed Engineer - FDE (Fullstack) - Databricks](https://www.databricks.com/company/careers/professional-services-operations/sr-forward-deployed-engineer---fde-fullstack-8782216002)

- [Forward Deployed Engineer - Databricks (Seoul)](https://www.databricks.com/company/careers/professional-services-operations/forward-deployed-engineer-8540455002)

- [AI Engineer - FDE (Forward Deployed Engineer) - Databricks](https://www.databricks.com/company/careers/professional-services-operations/ai-engineer---fde-forward-deployed-engineer-8546367002)

- [What is Unity Catalog?](https://docs.databricks.com/aws/en/data-governance/unity-catalog)

- [Databricks Forward Deployed Engineer Interview Guide](https://www.aced.io/guides/databricks-forward-deployed-engineer-interview)