网易2018实习生招聘笔试题——大数据开发实习生这份题我印象挺深。当时投的是杭州研究院的大数据开发岗位笔试一共两个小时题量不算小涉及 Java 基础、数据结构与算法、大数据生态组件Hadoop、Spark、Hive、Kafka、数据库原理和几道场景设计题。说实话这套题放在今天来看依然很有参考价值因为大数据开发岗位的底层能力要求并没有本质变化——不光是你会不会调 API而是你能不能理解分布式计算的核心逻辑能不能用工程化的方式处理海量数据。很多准备校招的同学来找我聊都问大数据开发到底考什么、怎么准备。我的看法很直接刷题只是底线更重要的是建立一套完整的知识体系。今天我就以这份网易 2018 实习笔试题为线索把每个考点背后的知识点、我当时是怎么答的、以及现在复盘后觉得应该怎么准备一条条拆给大家看。1. 笔试全貌题量、题型与时间分配的底层逻辑1.1 这套题考了什么四大模块的能力映射网易大数据开发的笔试题目大致可以分成四块编程基础与算法、大数据技术栈、数据库与 SQL、分布式系统基础。如果你做过其他大厂的笔试题会发现这个框架出奇地一致。原因很简单大数据开发实习生日常要面对的活儿就是写数据处理逻辑、调优 Spark job、维护 Hive 表、跟 Kafka 消息打交道偶尔还要处理数据倾斜和任务失败的问题。这些工作对应到笔试自然就落在了上述四块上。第一块编程基础主要用来筛掉写不了代码的人。网易比较偏爱 Java也会让你用 Python 写简单的脚本逻辑。考的是字符串处理、集合类、基础算法和简单的时间/空间复杂度分析。第二块大数据技术栈主要围绕 Hadoop 生态展开MapReduce 原理、Spark 的 RDD 和算子、Hive 的底层执行流程、Kafka 的消息模型这些都是高频出题点。第三块数据库与 SQL重点在索引、事务隔离级别、SQL 查询优化偶尔会给一张表让你写统计 SQL。第四块分布式系统基础则是考验你对 CAP 理论、一致性哈希、网络协议的理解因为大数据系统本身就是分布式系统不懂这些很难真正调优。1.2 时间分配与答题策略我当时的实战做法两个小时听起来不算短但如果题量有 20 道以上再加上一道手写代码和一道 SQL 大题时间就非常紧张。我当时的策略是先把有把握的题做完再回头啃难题。具体来说选择题部分控制在 40 分钟内编程题单独留 30 分钟数据库和场景设计题留 40 分钟剩下 10 分钟检查。这里有个特别容易踩的坑很多人在选择题上死磕一道拿不准的题浪费大量时间最后编程题没写完。面试官看的不是你某一道题的对错而是整体得分。一道选择题最多 2 分而一道编程题或场景题可能占 15 到 20 分分值权重完全不同。所以调整好节奏比多做对一道选择题划算得多。2. 编程基础题解析Java 与算法功底是敲门砖2.1 手写代码题字符串反转的核心思路与变体网易笔试的编程题里出现过这样一道经典题目输入一个由单词组成的字符串按单词反转输出。比如输入 Hello World输出 World Hello输入 I am a student输出 student a am I。这道题看起来简单但实际写起来有不少细节。很多人第一反应是先把整个字符串反转再把每个单词反转回来。比如 Hello World 整体反转变成 dlroW olleH然后再对每个单词反转得到 World Hello。思路没问题但如果你用 Java 写要注意字符串是不可变的频繁拼接会浪费大量内存最好用StringBuilder或StringBuffer。我当时写的版本大致是先去掉首尾空格然后把整个字符串按空格拆分成数组再倒序遍历数组用StringBuilder拼接每个单词中间加一个空格最后输出。需要注意如果原字符串连续多个空格split( )会产生空字符串导致输出多个空格。更好的做法是用split(\\s)正则或者先trim()再处理。边界条件包括空字符串、只含一个单词、单词间有多个空格等。这道题考察的不仅是你能不能写出正确逻辑还有你考虑问题是否全面。我在笔试时专门把边界情况列了出来比如空字符串直接返回空字符串字符串首尾有空格时先去除连续多个空格时按一个空格处理。这些细节加在一起就算代码不是最优解也能给面试官留下考虑周全的好印象。2.2 循环与进制转换常见的笔试题类型除了字符串网易还比较喜欢考进制转换和基础的循环逻辑题。比如给你一个十进制整数要求转换成二进制字符串输出或者反过来给一个二进制字符串求十进制值。这种题考的就是基本的除 2 取余法和循环迭代但有个坑在于负数如何处理。我当时准备的时候把这类题总结成了一个小模板如果是十进制转二进制就用一个循环不断n % 2收集余数然后n / 2最后反转字符串如果是二进制字符串转十进制就用一个循环从前往后遍历result result * 2 (char - 0)。对于负数Java 里可以用Integer.toBinaryString()直接得到补码形式但这个函数返回的是二进制补码表示可能你期望的是普通的二进制位表示这个要根据题目要求判断。这里我想多说一句进制造题在笔试中出现并不是因为你以后真的会天天写进制转换而是考察你对循环、分支和基本运算的掌握程度。真正的数据处理工作中你可能会遇到 IP 地址转整数、十进制 ID 转短链接等场景底层用的都是类似的思路。把基本功打牢遇到变种题才不会慌。2.3 时间与空间复杂度分析算法题中的隐性考点在选择题和简答题中经常会问你某个算法的时间复杂度。比如快速排序平均复杂度是多少、哈希表查找复杂度是多少、在有序数组中二分查找的复杂度是多少。这些概念看起来基础但在大数据场景下有着直接应用二分查找的思路就是分而治之MapReduce 的思想也是分而治之哈希表在海量数据去重、分组、Join 中有着广泛的应用。网易的题目里有一道比较典型的给定一个包含 1 亿个整数的文件如何找出其中重复次数最多的 10 个整数这是个典型的 TopN 问题。最简单的方法是直接用哈希表统计每个数字的频率然后排序取前 10但 1 亿个整数在内存中可能占几百 MB如果内存受限就需要用分治加小顶堆来处理。具体做法是把大文件拆分成多个小文件分别统计每个小文件内每个数字的频次得到局部统计结果后再合并用一个小顶堆维护全局出现频次最高的 10 个数字。这种做法的时间复杂度是 O(n)空间复杂度取决于分片数量和堆的大小。面试官出这道题表面上是考 TopN实际上是在考你能否将大数据问题分解成可处理的小块这正是分布式计算的核心思想。3. 大数据技术栈核心考点Hadoop、Spark、Hive 一个不能少3.1 Hadoop 核心机制不只是“会部署”而已先说说 HDFS。笔试里通常会考 HDFS 的文件读写流程、副本机制和块大小。网易的题目里有过类似的问题一个 200MB 的文件存入 HDFS块大小是 128MB会分成几个块答案是一个 128MB 的块加一个 72MB 的块共两个块。副本数默认是 3所以物理上会占用 600MB 的存储空间但逻辑上文件还是 200MB。这里有个容易混淆的概念HDFS 的块大小是 64MB 还是 128MB如果你看不同版本的 Hadoop默认值确实不一样。Hadoop 2.x 之后默认变成 128MB但如果你的集群配置了不同的块大小那就要以配置为准。笔试题目里通常会明确说明块大小所以读题要仔细。另外为什么 HDFS 块要设计这么大因为大数据场景下单个文件非常大如果块太小NameNode 要管理的元数据太多会成为瓶颈块越大NameNode 压力越小但块太大又会影响 MapReduce 的任务并行度所以需要权衡。MapReduce 的流程也是高频考点。一个典型的问题MapReduce 中 Shuffle 阶段的作用是什么答案是把 map 输出的数据按照 key 进行排序、分区、归并然后传输到对应的 reduce 节点。这里要注意Shuffle 是 MapReduce 性能调优的重点因为大量的网络传输和磁盘读写都发生在这个阶段。我当时复习时把 Shuffle 总结成四步分区Partition、排序Sort、溢写Spill和合并Merge其中溢写会触发 Combiner 做局部聚合以减少传输数据量。3.2 Spark 与 MapReduce 的对比为什么 Spark 更快网易笔试中对 Spark 的考查也占了不小的比重尤其是 Spark 和 MapReduce 的对比。这个问题其实可以一句话概括MapReduce 每个 job 都会从磁盘读取中间结果并写回磁盘产生大量磁盘 I/O而 Spark 尽可能在内存中保存中间结果只有内存不够时才溢写到磁盘。所以 Spark 在迭代计算和交互式查询上明显占优。更深一层的问题是 Spark 的 RDD 设计。RDD 是不可变的分布式对象集合支持两种操作转换操作Transformation和行动操作Action。转换操作是惰性的不会立即执行而是记录血缘关系Lineage只有行动操作触发时Spark 才根据血缘关系以流水线方式真正执行计算。这个设计的好处是容错代价低如果某个分区数据丢失只需按血缘重新计算而不需要做数据复制。笔试中还可能出现一道 Spark 算子的题reduceByKey和groupByKey的区别是什么。reduceByKey会在 Map 端先做一次聚合然后再传输到 Reduce 端做最终聚合传输数据量大大减少groupByKey则把所有相同 key 的数据都传输到同一个节点再处理没有 Map 端预聚合如果数据量大很容易造成网络拥塞和 OOM。所以能用reduceByKey的地方尽量不要用groupByKey。具体到大数据的应用场景统计网站每个页面的访问量reduceByKey就是最优选的算子。3.3 Hive 与数据仓库SQL 背后的 MapReduce 逻辑Hive 的核心思想是“把 SQL 翻译成 MapReduce现在也可以翻译成 Spark 或 Tez”让分析师用 SQL 的方式操作 HDFS 上的海量数据。笔试题里经常考一条 Hive 的 JOIN 语句底层 MapReduce 是怎么执行的常见的有三种实现方式Map Join、Reduce Join 和 SMB Join。Map Join 适用于大表 Join 小表把小表加载到内存中Map 端直接查内存完成关联不需要 Reduce 阶段速度非常快。Reduce Join 是通用方案map 端把关联字段作为 key 输出reduce 端收到所有相同 key 的数据后做笛卡尔积能处理任意规模的表但数据量大会有性能压力。笔试中可能会问两个大表 Join 时哪种方式更合适答案是 Reduce Join 或优化的 SMB Join因为小表没办法完全加载到内存。还有一个高频概念Hive 内部表和外部表的区别。内部表的元数据和数据都由 Hive 管理删除表时物理数据一并删除外部表只记录元数据删除表不会删除 HDFS 上的真实数据。这一点的实际意义是如果一份原始数据要被多个任务复用应该建外部表如果只是临时中间结果用内部表就够了。网易的笔试题目里考了一道场景判断日志数据定期传入 HDFS每次传入后需要被清洗、统计并保留原始数据问应该用内部表还是外部表。答案显然是外部表因为原始日志不能因为误删表而丢失。4. 数据库与 SQL考察方式和实战准备4.1 索引原理与优化为什么索引能加速查询很多大数据岗位的笔试都会包含数据库基础题网易也不例外。索引部分几乎必考尤其是 B 树索引为什么适合数据库场景。B 树的非叶子节点不存储数据、只存储索引键所以每个节点能容纳更多的键树的高度更低查询时 I/O 次数更少同时叶子节点通过链表串联非常适合范围查询。把 B 树和朴素二分查找、哈希索引对比起来理解答题会更清楚。更贴近实际的是联合索引最左前缀原则。有一道经典题目表 T 上有索引a, b, c问查询条件为where b1 and c2时能否用到这个索引答案是不能除非数据库做了优化因为跳过了最左列 a不满足最左前缀。这个知识点在写 SQL 时非常实用我见过不少同事在慢查询优化时就是因为建了联合索引但条件顺序不对导致索引完全失效。对于大数据开发来说索引的理解还要延伸到 Hive、HBase 等组件上。Hive 的索引并不像传统数据库那样高效HBase 的索引是利用 RowKey 的字典序来实现快速定位这些都是在笔试中区分你跟其他候选人的加分点。4.2 经典 SQL 笔试题演练窗口函数与分组统计网易笔试中必有一道 SQL 大题的风格通常是给你几张表让你写出统计结果。比如有一张用户订单表user_id, order_date, amount要求统计每个用户最近一笔订单的日期和金额。这道题用传统 GROUP BY 也能做但需要嵌套子查询用窗口函数就非常直接ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date DESC)取第一行即可。我当时备战的时候把窗口函数的几种典型用法都练了一遍ROW_NUMBER、RANK、DENSE_RANK、SUM OVER、LAG/LEAD。这些函数在实际的大数据 SQL 开发中使用频率极高尤其在做用户行为分析、留存分析、漏斗分析时几乎离不开。练习窗口函数不要光看教程一定要自己写一遍因为PARTITION BY和ORDER BY的结合方式很容易弄混。另一个高频考点是等值 JOIN 与 LEFT JOIN 的区别。笔试常见的陷阱题A 表有 10 条数据B 表有 5 条数据A LEFT JOIN BA 中有 3 条能在 B 中匹配到问结果有多少条答案是 10 条A 表中没有匹配的行B 的列填 NULL。这类题很简单但很多人临场一紧张就容易选错。我当时的方法是把 JOIN 想象成“以左表为基准逐行去右表找匹配”所以结果行数至少是左表行数。4.3 事务与 ACID大数据场景下也有对应物关于事务笔试题喜欢考 ACID 四个特性以及隔离级别。四个特性分别是原子性Atomicity、一致性Consistency、隔离性Isolation和持久性Durability。隔离级别从低到高分别是读未提交、读已提交、可重复读、串行化。网易出过一个判断题MySQL 默认的隔离级别是什么答案是可重复读Repeatable Read。这里其实隐藏着一个坑MySQL 在可重复读级别下通过 MVCC 实现了快照读所以能部分避免幻读但如果是当前读加了锁的 SELECT还是可能出现幻读。大数据组件里HBase 也提供了行级的事务语义Kafka 在 0.11 版本后支持跨分区的事务写入消息可以做到原子性。这些在大数据实时计算场景中是关键能力因为在 Flink 写入 Kafka 再到下游时端到端一致性依赖的都是这些底层机制。笔试时如果能把传统数据库事务和大数据组件的事务机制联系起来会显得你对工程的理解很完整。5. 分布式与通信基础TCP、消息队列与一致性5.1 TCP/UDP 网络模型大数据组件都逃不开的底层协议大数据开发虽然是做数据处理的但分布式系统之间必然需要网络通信。笔试中考查 TCP 和 UDP 的区别几乎是标配。例如TCP 是面向连接的、可靠的、流式传输UDP 是无连接的、不可靠的、报文传输。HDFS 的 DataNode 与 Client 通信、Kafka 的 Producer 与 Broker 通信底层都走 TCP所以 TCP 的三次握手、四次挥手、流量控制和拥塞控制你必须能够清晰表达。网易曾考过一道题三次握手为什么需要三次而不是两次答案是为了防止已经失效的连接请求报文段突然又传到服务器端从而产生错误。如果只握手两次服务器端在收到一个延期到达的旧 SYN 报文后会误以为新连接已经建立白白分配资源。两次握手会造成资源的浪费三次握手能够确认双方的接收和发送能力。大数据组件里NameNode 与 DataNode 的心跳机制本质上就是一种网络通信的可靠保障理解了 TCP 的状态机再看这些组件的源码会轻松很多。5.2 Kafka 的消息模型分区与消费者组是核心Kafka 是大数据实时计算里的核心组件网易笔试对 Kafka 的考查主要集中在消息模型上。Kafka 的消息是按 Topic 组织的每个 Topic 可以分成多个 Partition每个 Partition 内部消息有序。Producer 发消息时可以根据 key 的哈希值来决定写入哪个 Partition从而保证相同 key 的消息进入同一个 Partition下游消费时就能保证局部有序。消费者组Consumer Group的机制也很常考一个 Partition 的每条消息只能被同一个消费者组内的一个消费者消费但不同消费者组可以各自独立消费同一份数据。这个设计使得 Kafka 能够同时支撑多种下游场景比如一个数据流既被用于实时告警又被用于数据清洗两个不同的消费者组各取所需。笔试中经常考的题目是Topic 有 4 个 Partition消费者组里有 3 个消费者问每个消费者分别消费几个 Partition。答案是其中一个消费者消费 2 个 Partition另外两个消费者各消费 1 个 Partition。如果消费者数量大于分区数量则会有消费者空闲。5.3 一致性哈希与数据分布分布式系统的关键设计在大数据系统中数据如何分片、如何分布、节点变化时如何迁移是不可避免的问题。一致性哈希Consistent Hashing在笔试题中频繁出现。传统的哈希取模比如hash(key) % N在节点数量变化时会导致几乎所有 key 的映射都发生变化需要大规模迁移数据。一致性哈希将哈希值空间组织成一个环每个节点映射到环上某个位置数据落在环上有序存储到下一个节点节点增加或减少时只需要迁移环上对应位置附近的数据。举个例子一个缓存集群有 3 个节点使用一致性哈希后第 4 个节点的加入只会影响大约 1/4 的缓存数据而传统的取模哈希会导致 3/4 的数据失效。这在 HDFS 的副本放置策略、Cassandra 的数据分布、Redis Cluster 的槽位分配中都有体现。笔试中可能会让你画图说明一致性哈希的工作原理也可能问引入虚拟节点有什么作用。虚拟节点是为了解决节点数较少时数据分布不均的问题让每个物理节点对应多个虚拟节点使得负载更均匀。我自己复习的时候把“一致性哈希的价值”总结成一句话降低节点变化带来的数据迁移成本这个亮点在面试回答中很提分。6. 从笔试题看大数据开发实习生的能力模型与长期成长6.1 考点背后的岗位核心技能矩阵我把网易 2018 这套笔试题的考点汇总成了一个技能矩阵方便你照着自查。这套矩阵不只在网易适用放在大多数互联网公司的数据团队里也一样成立。技能维度高频考点对应的日常工作编程基础字符串、集合、进制、复杂度编写数据清洗逻辑、实现 UDF离线计算MapReduce、Spark RDD/算子、Hive SQL离线报表生成、 T1 数据仓库建设实时计算Kafka、Flink/Spark Streaming实时数仓、实时风控、数据通道存储与调度HDFS、HBase、Yarn数据存储设计、任务调度与资源管理数据库与 SQL索引、事务、窗口函数、JOIN业务取数、SQL 优化、数据验证分布式基础TCP、一致性哈希、CAP排查任务失败、数据倾斜调优单独刷题是不够的因为这些考点最终都会落实到真实业务中。大厂面试官普遍更喜欢能讲清楚“为什么”的候选人而不是只背答案的候选人。比如你回答 Spark 的reduceByKey比groupByKey快时如果能补充一句“因为 Map 端做了预聚合减少了 Shuffle 数据量”就比只默写结论要强得多。6.2 笔试题之外的加分项项目经验与思考深度笔试只是第一关但笔试成绩会影响你后续的面试安排。网易这类大厂通常笔试通过后会有两到三轮技术面现场会深挖你的项目经历。所以准备笔试不能只看题还要准备好“如何把笔试里的知识点串成项目经验”。我当时准备了一个基于 Spark SQL 的用户行为分析项目项目里用到 Hive 建表、Spark 清洗、Kafka 传输、最后落到 MySQL 供报表展示。面试官问“数据倾斜怎么解决”时我回答了三个层次第一通过加盐Salted Key打散大 key第二先过滤空值和无意义数据第三针对倾斜 key 单独处理再做 union。这些方案不复杂但需要你真正写过、调过才能讲出细节。再比如 Hadoop 参数调优面试官喜欢问你的 MapReduce 任务跑得很慢你会从哪些方面排查你可以答检查 map 和 reduce 的数量、查看是否发生了数据倾斜、检查是否开启了 Combiner、观察 Shuffle 阶段的网络 I/O、确认 HDFS 小文件是否过多。每个点展开讲就能聊很久。6.3 大数据开发技术栈的演进2018 到现在的变与不变既然是复盘 2018 年的题目有件事必须说清楚从 2018 年到今天大数据技术栈发生了不少变化。Flink 逐渐取代 Spark Streaming 成为实时计算的主流数据湖技术Iceberg、Hudi、Delta Lake也日益普及云原生架构让很多中小企业开始用云上的托管大数据服务。但笔试里的基础考点没有变Java、SQL、分布式原理、Hadoop/Spark 生态依然是核心中的核心。原因很简单这些是底层方法论只要你在做分布式数据处理就离不开它们。所以不要因为题目出得早就觉得没有参考价值。恰恰相反现在的大数据岗位笔试其实在数据结构、SQL、组件原理上的考查更深入了。建议大家把这份 2018 年的题目当作一份“知识地图”对照自己哪些板块已经掌握、哪些还需要补强。我当时用的方法是先按大块知识点过一遍基础再找 3 套左右不同公司的真题模拟真实考试时间做一遍最后把错题和模糊的知识点整理成笔记反复翻看。这个方法对我自己非常奏效。最后说一个细节答题时不要只写答案尽量简单写出推导过程或思路。如果是机试代码风格要规范变量命名要清晰关键逻辑可以加注释如果是手写卷字迹工整、分点作答会让阅卷人更容易抓重点。大数据开发这个岗位说到底不只是跟数据打交道也是在跟团队协作、跟系统架构打交道。让面试官从笔试卷上看出你的思路清晰、基础扎实、考虑全面你就已经赢了一大半。