数据开发笔试复盘：SQL、数据倾斜与数仓建模要点

我当年拿到这套“哔哩哔哩2020校园招聘数据开发方向笔试卷（二）”的时候，第一反应是：这不就是一份SQL加Java的混合卷吗？后来认真刷完才发现，数据开发笔试的考察逻辑和普通后端开发完全不同，它更看重你对“数据是怎么从业务产生、流转到数仓、最终被分析使用的”这条链路的理解。哪怕已经是好几年前的卷子，把它逐题拆开复盘，依然能看到如今所有大厂数据开发面试题的母题。

这篇文章我想以这套B站笔试卷为切入点，按题目背后考察的能力模块来拆解，同时把每个模块的备考思路、实战经验和容易翻车的地方一起讲透。无论你是正在准备数据开发校招，还是刚转行大数据方向，这份复盘都能直接用上。

1. 试卷背后的岗位画像：B站数据开发到底想要什么样的人

1.1 B站业务形态决定了数据开发的技术栈和出题风格

先说一个很多人忽略的点：B站的数据开发笔试卷，和字节、阿里、腾讯的卷子风格差异很大。原因是B站的业务场景有自己的特点——视频内容消费、UP主生态、直播、番剧、游戏，这些都是典型的内容社区型业务。

内容社区的数据链路和我们熟悉的电商、金融行业不一样。电商数据是强交易属性，核心指标是GMV、转化率、客单价；内容社区的数据核心是用户时长、互动率、内容供给和消费匹配效率。这就导致B站数据开发的笔试题里，必然会出现类似“视频推荐场景下的特征统计”“弹幕和评论的实时热度计算”这类偏内容生态的题目，而不会像金融岗位那样考大量风控反欺诈。

我当时做完这套卷子的整体感觉是：B站不指望你什么都会，但要求你具备“把业务问题翻译成数据技术问题”的能力。这份试卷覆盖了四类核心能力：SQL功底、大数据组件原理、业务场景建模能力、算法基础。这四个板块其实对应的是数据开发日常工作中的四种真实场景：写数仓ETL、调优Spark任务、参与业务指标建设、处理数据倾斜和离线任务优化。

1.2 从题型结构反推备考重心

虽然没有官方公开的每题分值分布，但根据我对同类校招笔试的了解和考试后的复盘，试卷结构大致如下：

学校里的课程通常只教SQL写法和基础的Java/Python语法，但企业笔试卷里真正拉开差距的，是Hive和Spark的原理理解，以及业务场景题能不能答得完整、有层次。我见过太多候选人SQL写得飞快，一到“为什么MapReduce会出现数据倾斜”就只说得出“加个随机数”这种结论，完全讲不清底层逻辑。这种“知其然不知其所以然”的状态，在笔试阶段可能还能蒙混过去，到了面试环节就是灾难。

2. SQL与Hive：看似送分，其实是整张试卷的分水岭

2.1 窗口函数已经被默认“人人都会”了

如果要给B站这类数据开发笔试划一条起跑线，那一定是窗口函数。我甚至可以说，窗口函数写不顺溜，这套卷子的SQL大题基本等于没分。为什么？因为数据开发日常工作中，排名、去重、累计求和、同比环比这类需求占比极高，而它们无一例外都需要窗口函数。

典型考法是这样的：给一张用户观看记录表，字段包括user_id、video_id、watch_time、date，然后要求“统计每个用户观看时长最长的前3个视频”。如果不用窗口函数，你得写自连接加子查询，又长又容易错；用row_number()一行搞定：

select user_id, video_id, watch_time, rn from ( select user_id, video_id, watch_time, row_number() over (partition by user_id order by watch_time desc) as rn from watch_log where dt = '2020-08-01' ) t where rn <= 3;

这个答案基本就是标准解法，但笔试真正想考察的不是你会不会写row_number，而是三个更深的点。

第一，能否区分row_number()、rank()和dense_rank()。这是每次笔试必踩的坑。row_number()不管有没有并列，都按顺序给编号，所以名次是1、2、3、4；rank()遇到并列会跳号，比如两个并列第一，下一个就是第三名；dense_rank()并列不跳号，两个并列第一后下一个还是第二名。涉及排行榜、人数统计这种场景，选错函数结果就完全错了。

第二，partition by后面到底该放哪些字段。这里有个常见错误：需要全局排名时忘记去掉partition by，或者需要“按天分组统计”却漏了日期字段。我建议拿到题目先画一下“分组维度”和“排序维度”，再动手写。

第三，窗口函数能不能跟where子句一起用——这是最容易暴露基础不扎实的地方。窗口函数是在where和group by之后才执行的，所以如果你想筛选“排名前3”的记录，不能直接在同一个查询层级里写where rn <= 3，必须包一层子查询。很多人在这一步被扣分，就是因为对SQL各子句的执行顺序没有体系化理解。

这套卷子里还有一种隐形考点：连续问题。比如“统计连续3天登录的用户”。基础解法是用date_sub/date_add配合row_number()，通过日期减行号的差值来分组。这类题在B站笔试里出现过相似的变体，因为登录行为分析本身是内容社区非常关心的指标。

2.2 Hive专项题：数据倾斜才是真正的压轴题

如果说窗口函数是开胃菜，那么数据倾斜就是整个数据开发笔试里最核心的常客。B站的试卷里很少直接问“什么是数据倾斜”，而是喜欢用场景题的方式考察，比如：一个统计视频播放量的SQL任务，跑了一个小时还没结束，你会怎么排查和处理？

这类题的本质是考察你对MapReduce/Spark执行机制的理解。数据倾斜的根因一句话就能说清楚：数据分布不均匀导致某个reduce task处理的数据量远超其他task，整个作业被这个慢节点拖住。常见原因包括：key本身分布不均（比如某个头部视频的UV远高于其他）、空值过多导致所有空值进入同一个reduce、join时小表关联大表的key重复度高。

我推荐一个“先定位再解决”的作答框架，这在笔试和面试中都很讨喜。第一步看是不是key分布问题，用group by或者count一下各个key的数量，确认是否存在倾斜；第二步看是否由空值引起，如果是，可以把空值key用随机数打散；第三步看是否由join引起，小表就做map join，大表倾斜就用两阶段聚合。

两阶段聚合是笔试的高频标准答案，做法是先给key加随机前缀做局部聚合，再去掉前缀做全局聚合。我曾用一段伪代码给面试官展示这个思路：

# 第一阶段：加盐局部聚合 select concat(floor(rand() * 100), '_', key) as salted_key, count(*) as partial_cnt from data group by concat(floor(rand() * 100), '_', key) # 第二阶段：去掉盐值全局聚合 select split(salted_key, '_')[1] as key, sum(partial_cnt) as total_cnt from stage1_table group by split(salted_key, '_')[1]

能把这个方案讲清楚，已经超过九成的候选人。但如果你想拿高分，还需要补充一句：两阶段聚合并不是银弹。如果是count(distinct)类的倾斜，加盐方案就不好使，更合理的方式是改用近似去重算法或者分桶后做局部去重。B站的数据开发笔试里，只要你能说出“不是所有倾斜都能用加盐解决”这个认知层次，考官就会觉得你有真实项目经验。

2.3 刷题之外的硬功夫：学会读执行计划

关于SQL这块，我额外说一个很多人忽略的备考要点：B站的笔试卷主观题占比不低，部分题目会直接贴一段SQL让你写优化建议。这时候光靠背“用分区、避免select *”这类口诀是不够的，你需要能看懂执行计划。

Hive的explain命令会告诉你哪个stage是Map端做、哪个stage是Reduce端做，join的类型是MapJoin还是CommonJoin，有没有出现数据倾斜的风险。我记得这道题当年其实考的就是读执行计划：给了一段慢查询，让考生根据执行计划找出两个job之间的数据倾斜风险点。

我的建议是备考时把explain当成标配技能来练。不只是写对了SQL，而是运行一下explain，逼自己看一遍执行计划，解释每一步在干什么。这样遇到类似的笔试优化题，你才能不止答“加一个distribute by”——而是能指出数据从map端到reduce端的分区逻辑在哪里出了问题。

3. 大数据组件原理题：区分“用过”和“真正懂”的分界线

3.1 HDFS与YARN的高频考点非常固定

B站这份笔试卷的大数据基础选择题，考的范围其实并不偏，HDFS、YARN、ZooKeeper都有涉及。但只要不是只背八股，愿意往原理深挖一层的人，基本都能答对。有意思的是，真正拉开差距的不是选择题，而是简答题里“描述一条数据从接口上报到最终进入Hive表的完整过程”。

这道题表面问的是链路，其实考的是HDFS写流程和YARN任务调度。一个及格的回答是：数据经由Nginx网关、Kafka消息队列，再由Flink或Spark Streaming实时写入HDFS，或者通过调度任务批量刷入Hive分区表。但高分回答必须深入到HDFS写入的细节：客户端先向NameNode请求上传，NameNode返回可用DataNode列表，然后客户端将数据分成packet依次写入DataNode，同时第一个DataNode会复制给第二个、第三个DataNode，形成副本流水线。

面试官真正想听的其实是“副本放置策略”和“故障恢复”这两个点，因为它们在后续做数据开发时和文件存储设计强相关。B站的视频业务会产生海量小文件，如果不懂HDFS的副本机制，就理解不了为什么小文件会严重消耗NameNode内存，也就给不出“用分区合并、用SequenceFile或ORC格式”这类解决方案。

YARN方面的高频考点是容器、资源调度器。笔试里它常以这种形式出现：“一个Spark任务提交后，资源是怎么申请和分配的？”答这个题需要说清AppMaster向ResourceManager注册申请Container，然后NodeManager启动Executor的完整流程。能顺手提一句“FIFO调度器会出现队头阻塞，Capacity调度器适合多租户资源隔离，Fair调度器适合小任务混跑”的，基本就是高分答案，因为这显示你真的明白生产环境为什么要选Capacity或Fair。

3.2 Spark与Flink原理题：核心考点不在API而在执行机制

B站的数据开发笔试卷中，Spark和Flink相关题目占比不低，但并不会让你手写复杂的算子链。它更爱考两类问题：一类是概念辨析，另一类是容错机制。

概念辨析最经典的就是Spark的RDD、DataFrame、Dataset三者区别，以及宽依赖和窄依赖的区别。窄依赖是指父RDD的每个分区最多被子RDD的一个分区使用，比如map、filter；宽依赖是指父RDD的每个分区可能被多个子RDD分区使用，典型场景是groupByKey、reduceByKey。这个考点跟前面的数据倾斜是连在一起的：宽依赖会产生shuffle，shuffle是数据倾斜的最常见根源。

容错机制方面，Spark强调的是血缘关系和checkpoint，Flink强调的是分布式快照，也就是基于Chandy-Lamport算法的checkpoint机制。有一道题我记得特别清楚：问“Spark任务计算过程中某个节点挂了，是如何恢复的？”答案是重新计算丢失的分区，但前提是该分区的父依赖还在。想拿高分可以补充一句：如果血缘链路特别长，重新计算代价很大，可以在关键节点加checkpoint，切断血缘链。

至于Flink，如果试卷里出现“如何保证实时计算的Exactly-Once语义”，建议从Checkpoint配合两阶段提交来答：Kafka作为Source端维护offset，Sink端实现预提交和提交两个阶段，只有所有算子都完成快照后才会真正提交结果。不一定要求你手动实现精确一次，但必须理解这套机制背后的逻辑，因为它在实时数据开发中直接决定了数据准确性。

3.3 自测一下：组件原理能不能讲成一个闭环

我在辅导同学准备数据开发笔试时，经常用一个自测方法：你能不能用一个下午的时间，把“一份用户观看日志从产生到变成报表里的DAU”这个过程，嘴对嘴地完整讲给一个不懂大数据的朋友听？

能讲清楚，说明你对组件原理的理解已经形成了闭环；讲不清楚，说明你还在背概念。我见过很多人背熟了“HDFS存数据、YARN跑任务、Spark算数据”，但被问一句“这个任务运行时，数据是怎么从HDFS到内存再到结果表的？”就哑火了。

这个闭环需要包括：日志采集端通过Flume或Logstash把文件写入Kafka，Kafka按topic分区存储流式数据；实时任务从Kafka消费，做ETL后写入HBase或Redis供在线查询；同时落一份到HDFS作为离线数据源；离线任务通过Hive或Spark读取HDFS上的分区数据，加工后写入结果表。整个链路中，Kafka是数据管道，HDFS是存储底座，YARN是资源管理器，Spark/Flink是计算引擎。笔试时能把这个闭环图用文字描述出来，组件原理题基本就是送分。

4. 业务场景与数据建模：这类题目答得好，基本就锁定offer了

4.1 指标口径题：先定义清楚再写代码

B站这套笔试卷里有一类题让我印象很深，它不是考技术，而是考业务能力。大意是：产品经理给你提了一个需求，要统计“视频的完播率”，让你给出实现方案。看到这道题的第一反应可能是写SQL，但真正被考察的核心是——你如何定义“完播率”。

完整回答至少需要延伸到几个子问题：完播率的分母是播放次数还是播放用户数？分子是播放到百分之百才叫完播，还是播放到90%就算？遇到倍速播放、拖进度条、重复播放、异常退出怎么处理？这些口径不定义清楚，SQL写得再漂亮也得返工。

这种题在现实中非常常见，我称之为“指标口径题”。数据开发的价值百分之八十不在写代码，而在跟业务对齐口径。一个清晰的口径应该这样描述：统计周期、统计维度、指标定义、事件触发条件、异常排除规则。比如：“完播率=播放时长达到视频总时长99%及以上的播放次数，除以统计周期内的总播放次数，排除播放时长小于1秒的无效播放。”这比一上来就写SQL高级得多，而且也是笔试评分的重要参考维度。

B站的笔试卷会在这个基础上增加场景感：UP主上传了一个视频，要求统计该视频发布后24小时内的播放完成情况。这里不仅考察口径，还考察你对时间窗口和事件时序的理解——事件日志里的播放完成事件能否和视频发布时间精确关联上，溢出窗口的数据怎么截断，这些都需要在地理位置和时区这类基础条件之外考虑。

4.2 埋点日志链路题：从上报到入库的完整推演

另一类高频业务题是埋点日志链路设计，B站特别喜欢考，因为B站本身就是强内容平台，各种各样的用户行为事件都需要靠埋点来进行数据采集。

这类题的基本问法是：设计一个用户行为日志系统，支持收集用户播放、点赞、投币、评论等行为，要求给出数据流转链路和核心表结构。

一个可以拿高分的回答思路是这样的：首先是事件埋点设计，每个事件包含事件ID、用户ID、视频ID、事件时间戳、页面来源、设备信息、扩展参数。然后是传输链路，客户端产生事件后先本地缓存，批量上报到服务端；服务端接入Kafka，因为Kafka削峰填谷的能力能够扛住高峰期流量；接着数据从Kafka分别流向实时和离线两条链路：实时链路用Flink做窗口统计，离线链路通过Hive数仓做T+1加工。

这里有一点很容易被忽略但非常加分：小文件问题。如果你在答案里主动提到“实时写入HDFS时要注意控制文件数量，避免产生大量小文件”，面试官会觉得你确实跑过真实任务。这类问题的细节不需要太复杂，但一定要展示出端到端的思维，而不是只管某一个环节。

4.3 数仓建模：维度建模是校招笔试的隐藏高分点

还有一个隐藏高分点在很多人的备考中被直接忽略，那就是数仓建模。B站一些年份的笔试卷里会有简答题问“如果让你构建一个视频观看数仓，你会怎么分层”，这其实就是在考维度建模。

我的建议是，分层的答案可以从ODS、DWD、DWS、ADS四层展开，这个业界通用分层就是最稳妥的答案。但你不能只把分层名字写出来，要结合具体场景：ODS层原样存储埋点日志；DWD层清洗和规范化数据，将事件日志里的用户ID、视频ID映射到维度表；DWS层按天、按视频维度进行汇总，形成视频播放量、完播人数等指标宽表；ADS层面向业务报表输出最终结果。

在维度建模上，推荐记一下星型模型和雪花模型的核心区别。笔试如果考到，不需要长篇大论，能说出“星型模型通过冗余维度字段减少join，雪花模型通过规范化维度减少存储但增加查询复杂度”就够了。如果再补充一句“数据开发中绝大多数场景优先选星型模型”，说明你已经过了理论阶段，有实战判断了。

5. 算法与数据结构：性价比最高的拿分板块

5.1 TopK问题与海量数据处理是数据开发笔试的常客

B站的算法题不会特别难，考的都是比较经典且贴近大数据场景的题目，其中最常出现的，就是TopK和海量数据处理。

TopK问题我建议准备三种解法。第一种是维护一个大小为K的小顶堆，遍历数组，遇到比堆顶大的元素就替换并调整堆，时间复杂度是O(n log K)；第二种是快排partition思路，每次把数组分成两部分，只对包含TopK的那一侧递归处理，平均时间复杂度接近O(n)；第三种是针对海量数据的分布式方案，将数据分片到多台机器分别求TopK，再汇总求全局TopK。

为什么这道题会被数据开发笔试看重？因为它在真实业务中太常用了。举一个场景：每天有上亿条播放事件，需要统计播放时长最长的TOP100视频。单机内存装不下，自然想到分而治之；分完还要合并，合并时要维持全局有序——这整个过程和数据开发日常做的分片计算+归并汇总逻辑一脉相承。

5.2 海量数据去重与概率数据结构是加分项

另一类B站笔试喜欢考的算法题是海量数据去重，比如“给定上亿个用户ID，统计去重后的用户数，内存有限，怎么做”。标准解法是Bitmap，也就是用每一位的0/1来表示一个用户ID是否存在，内存占用极低。

如果题目里再加一个“误差允许在1%之内”，那就要往布隆过滤器方向答了。布隆过滤器是用多个哈希函数映射到一个位数组，判断“一定不存在”和“可能存在”两种结论的结构。我建议备考时一定要把布隆过滤器的原理彻底搞懂，因为数据开发岗位日常处理UV类指标时，经常用到基于近似算法的方案。

我在实际参加过的笔试中遇到的版本是，要求写“用Java或Python实现一个简单的布隆过滤器核心逻辑”。我当时写的伪代码如下：

class BloomFilter: def __init__(self, size, hash_count): self.bit_array = [0] * size self.hash_count = hash_count def add(self, item): for i in range(self.hash_count): index = hash(item + str(i)) % len(self.bit_array) self.bit_array[index] = 1 def might_contain(self, item): for i in range(self.hash_count): index = hash(item + str(i)) % len(self.bit_array) if self.bit_array[index] == 0: return False return True

虽然这个实现只用于演示，不算工业级，但它能清晰展示出“多个哈希函数”“位数组”“允许误判”三个核心特征，这就足够拿分了。如果再补充一句“布隆过滤器不支持删除元素，如果需要删除可以考虑Counting Bloom Filter”，会让阅卷人对你的印象更深。

5.3 手写代码之外的边界条件更考验基本功

除了数据结构和算法本身，B站的笔试算法题还有一个考察重点：代码洁癖和边界条件。比如题目要求写出求中位数的代码，很多人两个堆的思路都会，但一写就容易漏掉“两个堆的元素数量差超过1时需要平衡”这个关键步骤。

我个人的建议是，备考算法题时一定要在纸上或者在IDE里完整写一遍，不要只看思路。B站的在线笔试系统通常不会给你补全提示，也没有很方便的调试工具，所有细节都要一次写对。尤其是链表相关的题目，比如反转链表、判断链表是否有环，这类题不涉及高深算法，但特别容易在指针移动顺序上出错，一错就是编译通过但用例跑不完。

刷题数量上，我不太建议贪多求全。每天坚持两到三道中等难度的题，重点练熟数组、链表、二叉树、HashMap、堆这些核心结构，基本就能覆盖大多数数据开发笔试的算法题范围。真正要啃下来的是常见题型的模板，比如TopK模板、二分查找模板、链表反转模板，这样考场上的思考时间会短很多。

6. 考场策略与笔试到面试的衔接：会做题也要会“秀”会“聊”

6.1 我的做题顺序与时间预算

结合B站这套笔试卷的题型构成，我建议的答题顺序是：先做SQL题，再做算法编程题，然后做大数据组件原理题，最后做业务场景题。理由很简单，SQL题和算法题是客观题，会就是会，不会就是不会，先把能拿的分拿到；组件原理和业务场景题即使不会也能写一些思路，放到后面不影响得分上限。

时间分配上，假设笔试总时长是120分钟，我个人的预算大约如下：

这个时间分配的核心思路是：难题别贪，送分题必须全拿。我看到过太多候选人死磕一道组件原理简答题，最后SQL题没时间写，那才是真正的因小失大。数据开发笔试的通过率并不高，但大多数人的失分点其实都在时间管理和基础题准确率上，而不是在那种需要极强创造力的压轴题上。

另外一个经验是，笔试时把代码写得干净一点，哪怕只是变量命名和注释规范一些。很多公司的校招笔试题目不是机器自动判分之后就完事了，后续面试官会回看你的答题记录。一份排版整齐、思路清晰的答题记录，会在面试官心里的印象分上发挥意想不到的作用，尤其是主观题部分。

6.2 把笔试卷变成“面试弹药库”

我特别想强调一个认知：笔试的结束并不是这批题目的终点，而是面试准备的起点。B站的面试官在约面时大概率会看到你的笔试成绩和答题详情，面试中很可能直接问你“笔试里那道数据倾斜的题，你当时是怎么考虑的？”如果你笔试时只是草草写了个结论，面到这个问题时就很容易接不上。

我的做法是：每考完一套笔试试卷，当天晚上就把所有不会的题目和没把握的知识点整理出来，按“题目、考点、错误原因、正确思路”四个字段记录到一份文档里。这样做的好处有两个：第一，笔试暴露的知识盲区是最高效的复习素材；第二，把笔试中自己答得好的思路整理成文言化表达，面试时可以直接拿来用。

比如笔试里那道“如何统计视频完播率”的业务场景题，如果你在笔试时从口径、埋点、到DWS汇总三层来答，那面试中同样的问题，你就可以直接展开成完整的数仓建模思路，把笔试时没来得及写的细节全部补上。笔试卷的每一道题，本质上都是面试官帮你划的重点，一定要把这些重点吃透，而不是考完就丢。

我在实际备考中还有一个习惯：把笔试里出现过的业务场景题，全部换成一个跟自己生活相关的场景重新做一遍。比如考了视频完播率，我就自己设计一个“统计B站弹幕活跃度”的方案；考了TopK，我就想一个“统计本周最热门100个搜索词”的完整链路。这种举一反三的练习，比单纯刷题更有价值，因为它逼着你把知识点内化成解决问题的能力，而不是只会背模板。

6.3 关于考试环境与细节，别在这些地方翻车

最后说几个笔试时非常实际的注意事项，每一个都是我或身边人踩过的坑。

第一，提前检查浏览器兼容性和网络环境。在线笔试系统有时候对浏览器有要求，比如只支持Chrome或者只支持特定的版本，不提前检查，进去之后才发现白屏或者代码编辑器加载不出来，心态直接崩一半。B站这套卷子当时应该是通过第三方笔试平台开放的，登录之后有多长时间、是否允许切屏、是否支持本地IDE，这些考试规则都要提前看。

第二，注意审题，尤其是SQL题里“去重”“按照某个字段排序”“求每个类别的前N条”这类关键词。我见过不下五个候选人在“每个用户观看时长最长的前3个视频”里漏掉“每个用户”前两个字的限制，写出来的答案没有partition by，直接全局排序。这种错误一旦出现，整个大题都拿不到分，非常可惜。

第三，如果代码没有跑通，不要直接放弃留空。很多笔试平台是按用例通过比例给分的，你写出思路并尽量接近正确答案，可能也能拿到部分分数。我建议每道编程题即使只写出了暴力解，也要提交上去，甚至可以在代码注释里简单写一下“这是在内存和时间条件允许下的暴力解，后续可以升级为堆优化”，让阅卷人看到你的思路层次。

从这套B站2020校园招聘数据开发笔试卷来看，校招笔试已经过了“考基础知识背题型”就能过关的年代了，它越来越像一场开卷的情境模拟：让你在一个限时场景里，展示自己处理真实数据链路问题的潜质和能力。如果你只把它当成一次考试，你就会焦虑；如果你把它当成一次和未来的自己对话，你就会发现，每个考察点背后都藏着这个岗位真正需要的工作方式。