Databricks NG 面试竟然也考 system design?

原本以为 Databricks 的 NG 面试只会问coding和BQ，但其实 system design 是必考的一项。这对很多ng同学来说绝对是意料之外。下面我整理了几道近期出现过的题目，全都是贴近 Databricks 核心业务场景的真题。

最近有人遇到的第一道题，是让你 设计一个 Query Execution Service for Databricks Notebooks。场景就是用户通过 notebook 提交 SQL 查询，系统要能做扩展、保证公平调度，还得容错和记录元数据。这题其实就是 Databricks SQL 的简化版。如果你光谈 Spark Driver + Executor 的执行机制肯定不够，还要能画出一个调度层，把多租户隔离、公平队列和 metadata service 融合进去。面试官会追问如果 executor 节点挂了怎么办，或者查询结果要怎么缓存出来给用户低延迟展示。

另一道题考的是 Delta Lake Metadata Service。这题就是在考 Databricks 的护城河。要求你设计一个服务来追踪 schema 演化、事务日志和version control。重点是要体现 ACID 语义，以及 append-only log + snapshot + checkpoint 的组合拳。如果你只停留在“我用 MySQL 存 metadata 就好”这种答案，那基本上会被面试官摇头。更好的回答是能谈到如何处理并发写入冲突、如何做 schema evolution，以及怎么降低 transaction log 读取成本。

还有一道让我印象很深的题是 设计一个 ML Model Serving Platform。Databricks MLflow 本来就是行业内的标配，所以他们就会考你如何支持大规模模型部署。题目要求既能做 batch inference，又要支持 real-time inference，还要有版本管理和 A/B 测试能力。这里如果你能讲到 API Gateway、模型加载和缓存、GPU/CPU 资源调度、metrics 上报与监控，再顺带提一下如何做自动回滚，基本就能拿下面试官的认可。

第四道题其实比较偏平台侧：设计一个 Job Orchestration Service for ETL Pipelines。Databricks 的调度器和 Airflow 类似，考点就在于 DAG 的执行、任务依赖、失败重试和补偿机制。面试官会让你描述 scheduler 如何存储状态、如何处理长时间运行的作业、以及如何避免单点瓶颈。如果你能结合 checkpoint、幂等性和并发调度策略来讲，答案就会很有说服力。

最后一道题和协作有关：设计一个 Collaborative Notebook System。Databricks Notebook 最大的亮点之一就是多人协作，面试官会让你想办法设计一个能支持多人同时编辑、实时同步和版本管理的系统。这里的难点在于冲突解决机制（比如 OT 或 CRDT），以及 notebook 的版本存储和权限控制。如果你能结合实际场景讲到“多个人同时改一行 SQL，该怎么 merge”，那基本就是面试官想要的思路。

总结下来，这几道题全都是真实出现在最近 Databricks NG 面试里的 system design 环节。和传统的“设计一个URL Shortener”不同，这些题都深深绑定在 Databricks 的核心产品线上。准备这类面试时，除了掌握系统设计的通用套路（扩展性、容错性、一致性、调度），更要带着数据平台的 lens 去思考。