数据工程师面试题，按轮次划分

你可能一直在按照软件工程师面试的方式准备，想知道数据工程师面试有什么不同。本节梳理这些面试反复出现的轮次，让你把精力放在真正拉开候选人差距的两个环节上。技术筛选环节很少是拿不到offer的原因。

• SQL。窗口函数、去重和查询性能，通常是现场手写。
• 数据建模。为给定的业务场景设计表结构，并为你选择的粒度做辩护。
• 管道与ETL设计。一个聚焦于数据流转的开放式系统设计轮次。
• 分布式处理。某个框架实际是如何执行你的任务的，以及它为什么变慢。
• 编码。Python或Scala，通常比软件工程轮次要轻。
• 行为面试。值班事故、坏掉的仪表盘，以及昨天就想要结果的相关方。

这些职位头衔与分析工程和平台类岗位高度重叠，因此考察内容会有所不同。相关的分角色题库见按角色划分的面试问题枢纽页。

SQL

• 对一张表去重，每个键只保留最新的一行。
• 写一个查询，用30分钟不活跃间隔来计算每个用户的会话数。
• 在一个查询里同时计算累计总和与环比变化。
• 找出昨天快照中存在、但今天快照中缺失的行。
• QUALIFY是做什么用的？如果不用它，你会怎么写？
• 这个查询扫描了十亿行数据，耗时二十分钟。你会如何诊断？
• 解释分区（partitioning）和聚簇（clustering）的区别，以及各自适用的场景。

数据建模

• 为一个在线交易市场的订单历史设计表结构。你的事实表粒度是什么？
• 解释星型模式，以及你什么时候会主动进一步反规范化。
• 什么是缓变维度？你会如何实现二型？
• 某相关方希望历史报表反映客户当前所在的地区。这会导致什么问题？
• 你会如何为一个乱序到达的事件流建模？
• 什么时候你会选择宽表而不是规范化模型？

建模轮次奖励的是敢于确定一种粒度并为之辩护的人。那些描述了三种可能设计却始终没有做出选择的候选人，得分通常低于选定一个合理设计并指出其弱点的候选人。

管道与ETL设计

• 设计一个将每日交易数据加载到数据仓库以供报表使用的管道。
• 上游数据源把昨天的数据又发了一遍。你的任务会发生什么？
• 你会如何让一个管道具备幂等性？这对重跑为什么重要？
• 你会如何在不打断每日加载的情况下回填两年的历史数据？
• 某个分区已经关闭三天后，延迟到达的数据才出现。你会怎么做？
• 你会如何检测出一个管道运行成功了，但产出的数据是错误的？
• 你会监控什么指标？凌晨三点会因为什么而呼叫你？

分布式处理与流处理

• 什么会导致shuffle？为什么它的代价很高？
• 你的任务运行很慢，其中一个task耗时远超其他task。发生了什么？
• 解释数据倾斜（data skew），以及两种应对方法。
• 什么时候你会选择流处理而不是定时批处理任务？
• 「恰好一次」处理到底保证了什么？在哪些情况下它并不成立？
• 在窗口聚合中，水位线（watermark）是如何处理乱序事件的？

请注意，这些问题里很少要求你说出一个具体工具的名字。说出工具名只是回答的开始，而不是答案本身。后续追问永远是为什么，以及会出什么问题。

阅读这些题目列表能建立识别能力。而设计轮次考察的是另一种能力：在有人不断用故障场景打断你的情况下，仍能把整个系统装在脑子里。这种能力只能通过大声说出你的设计来获得。

• 用十五分钟画出并讲述一个管道。数据源、落地、转换、服务，加上每个环节可能如何失败。
• 攻击你自己的设计。每次练习结束后，问自己：重跑会怎样？延迟数据会怎样？schema变更会怎样？
• 准备好一个规模数字。每天的行数、数据大小、延迟预算。先说出你假设的规模会加分。
• 手写SQL。现场轮次常常只给一个没有自动补全、也不能执行的纯文本编辑器。
• 认真演练一个事故故事。出了什么问题、你是怎么发现的、你做了什么改动让它不再发生。

一位在批处理管道上有六年经验的数据工程师，准备时复习了框架内部原理，却在「上游数据源重新发送了昨天的文件」这个问题上卡住了，因为她过去只是手动处理过，从没有把它讲清楚过。知识是有的，但口头表达没有跟上。带着追问练习设计轮次，正是模拟面试模式存在的意义。