网易2020大数据开发提前批笔试复盘：考点与备考策略

先说明一下，这篇是基于网易2020校招提前批大数据开发工程师岗位的笔试复盘。我当年是参加了这场笔试的，后来也帮学弟学妹梳理过很多次考点，对这套题的风格和考察逻辑比较熟。2020年那场试卷整体难度在互联网大厂校招笔试里属于中等偏上，没有什么偏题怪题，胜在覆盖面广、考察细致，很容易暴露知识盲区。这篇内容会比较长，主要围绕这套题背后的考点逻辑来展开，不一定逐题复现，但会把题型结构、核心知识点、答题思路和备考策略都拆开讲清楚，希望对你准备同类岗位的笔试有实际帮助。

1. 这场笔试的底细：提前批不是"简单版"正式批

网易提前批笔试和正式批笔试在岗位匹配上基本一致，但有一个关键区别：提前批的笔试成绩直接关联面试优先级，考得好的人会被优先安排面试，甚至在正式批开始前就拿到意向书。所以提前批的笔试不是"试试水"，它本质上是一轮前置筛选，成绩决定了你的简历被推进到哪个面试官手里。

1.1 试卷结构与时间压力

2020年这场大数据开发工程师提前批笔试，总时长120分钟，题目类型大致如下：

时间分配上，前面30道选择很容易花掉50分钟，编程题两道又得留出40分钟，留给最后那道设计题的时间其实很紧张。我当时就是选择题在多选的几道题上纠结太久，差点没时间写设计题，这个后面细说。

1.2 大数据岗位笔试的"质量线"在哪里

热搜词里有句话讲得很到位：对于大数据而言，最基本、最重要的要求就是减少错误、保证质量。这句话放在笔试里同样成立。网易这场笔试的题目设计明显不是想难倒你，而是想看你在"全链路"视角下能不能做到不犯错——从数据采集、存储、计算到调度，每个环节都有对应的题，每道题都在验证你对某个环节的理解是否准确。

所以准备这场笔试，不能只刷算法题，也不能只背组件八股文，而是要建立一条完整的知识链路：数据从哪来（采集）、放哪（存储）、怎么算（计算引擎）、怎么调度（调度系统）、怎么保证一致性（事务与容错）。理解了这条链路，选择题里很多看似零散的考点就能串起来。

1.3 这场笔试真正筛选的能力

通过复盘，我认为网易这场笔试主要考察三种能力：

第一种是基础知识的准确性。Java集合、并发、JVM、操作系统、网络这些基础不要求你有多深的源码功底，但要求你用词准确、概念清晰。比如考的HashMap在JDK 1.8里链表转红黑树的阈值是8，很多人会记成6，这种细节就是区分度。

第二种是大数据组件原理的理解深度。不是让你背"HDFS是分布式文件系统"这种定义，而是让你理解写流程中副本放置策略的原理、MapReduce Shuffle为什么要排序、Spark宽窄依赖怎么划分Stage。这类题占了多选和简答的大头，也是最有区分度的部分。

第三种是工程设计与场景分析能力。设计题通常给你一个业务场景，让你设计数据链路或排查问题。这类题没有标准答案，但阅卷人有明确偏好：完整度、合理性和边界意识。

2. Java语言基础：不是八股，是写大数据代码的地基

网易大数据开发岗笔试对Java的考察比重相当高，这和大数据生态的实际情况直接相关。Hadoop、Spark、Flink这些主流框架都是JVM系语言写的，生产环境里写UDF、调优、排查问题都离不开Java功底。

2.1 集合框架的考察套路

选择题里最常见的集合考点是ArrayList和HashMap。ArrayList考扩容机制：默认容量10，扩容时新容量是旧容量的1.5倍，也就是oldCapacity + (oldCapacity >> 1)。这个计算方式在JDK 1.8里是int newCapacity = oldCapacity + (oldCapacity >> 1)，注意是右移一位而不是除以2的常规写法，考的是你对源码细节的熟悉度。

HashMap的考点更多，而且每年必考。核心包括：

• 默认初始容量16，负载因子0.75，扩容阈值是容量乘负载因子
• 哈希策略：(n - 1) & hash而不是hash % n，因为位运算更快，且前提是容量必须是2的幂
• 链表转红黑树的条件：链表长度超过8且数组长度大于等于64，两个条件缺一不可
• 红黑树退化为链表的条件：节点数小于等于6

很多人在"为什么转红黑树的阈值是8"这个问题上答不好。源码注释里提到，泊松分布下，负载因子0.75时桶内链表长度达到8的概率已经极低（约千万分之六），设置8是为了在时间和空间上取平衡。这类源码级的细节，正是笔试单选题里容易出也容易错的地方。

2.2 并发与线程池：必考但容易踩坑

并发这部分，网易喜欢考线程池参数和并发工具类。ThreadPoolExecutor的七个参数必须背熟而且理解到位：核心线程数、最大线程数、空闲存活时间、时间单位、阻塞队列、线程工厂、拒绝策略。关键考点是任务提交后的执行顺序：

1. 当前线程数小于核心线程数时，新建线程执行任务
2. 当前线程数大于等于核心线程数时，任务进入阻塞队列
3. 队列满且线程数小于最大线程数时，新建非核心线程执行任务
4. 队列满且线程数达到最大线程数时，触发拒绝策略

这里有个常见的混淆点：很多人以为"核心线程数满了就创建新线程到最大线程数"，实际上中间还隔着一层阻塞队列。生产环境里有个调优口诀：CPU密集任务核心线程数设为CPU核数 + 1，IO密集任务设为2 * CPU核数，虽然笔试不一定会考这么细，但理解这个逻辑有助于做对线程池相关的场景题。

ConcurrentHashMap也是高频考点，重点在于JDK 1.8之后它放弃了分段锁，改用CAS + synchronized锁桶头节点。put流程大致是：计算hash定位桶，桶为空则用CAS插入，桶不为空则锁住桶头节点再插入，扩容时支持多线程协助迁移。这个设计演进过程反映了从"锁粒度粗"到"锁粒度细"的思路，笔试喜欢考"JDK 1.7和1.8的区别"这种对比题。

2.3 JVM考点：GC与内存区域

JVM在一场大数据岗笔试里的地位，有点像足球场上的中场——不是最出彩的，但必不可少。网易考JVM主要围绕两个方向：内存区域划分和GC机制。

内存区域题通常是给一段代码判断对象分配在哪个区域，或者判断哪个区域会抛出OutOfMemoryError。必须清楚：堆存放对象实例、栈存放局部变量与栈帧、方法区存放类元信息与常量、本地方法栈服务native方法、程序计数器记录字节码执行位置。

GC题则喜欢考可达性分析、GC Roots有哪些、Minor GC和Full GC的触发条件、常见垃圾收集器的适用场景。这里我想提醒一个容易忽略的点：G1收集器在JDK 9之后成为默认垃圾收集器，它的核心设计是"Region化内存布局 + 可预测停顿时间"，它把堆分成一个个Region，通过维护优先列表来回收价值最大的Region。这个"价值最大化"的思路和很多大数据调度算法的思想是共通的，理解它对后面理解YARN的调度策略也有帮助。

2.4 语言基础题的复习建议

说实话，Java基础部分我见过太多人花大量时间刷源码解析视频，结果笔试依然错在细节上。我的建议是：不要追求源码逐行读，而是抓住"面试官最爱问的20个知识点"逐个击破，比如HashMap的put流程、ConcurrentHashMap的线程安全实现、线程池的执行流程、四大拒绝策略的区别、类加载的双亲委派模型等。每个知识点用"概念 + 场景 + 易错点"三要素来准备，比泛泛看源码效率高得多。

3. 大数据组件原理题：拉开分差的主战场

如果说Java基础决定了你的笔试能不能及格，那大数据组件的原理题就决定了你能不能进面试。网易2020这场笔试的大数据部分，不夸张地说占了半壁江山，单选、多选、简答都有涉及。以下按组件逐个拆解高频考点。

3.1 HDFS：读写流程与副本策略

HDFS相关题目基本围绕读写流程和副本放置策略展开。NameNode负责元数据管理，DataNode负责数据存储，这个基础概念不用多说，容易失分的是细节。

HDFS写流程的完整链路是：客户端调用DistributedFileSystem.create() → 联系NameNode检查权限并创建文件元数据 → 返回DFSOutputStream → 客户端将数据切分成packet（默认64KB） → 放入DataQueue → DataStreamer向第一个DataNode发送请求 → 建立Pipeline（按副本数建立DataNode链路） → 数据包沿Pipeline传输，同时每个DataNode保存后向下游转发 → 每个DataNode发送ACK响应，沿Pipeline反向传回 → 所有ACK确认后从AckQueue移除 → 关闭输出流，通知NameNode写入完成。

笔试里常考的点是副本放置策略。默认副本数为3，策略是：第一个副本放在客户端所在节点（如果客户端不在集群内则随机选一个节点），第二个副本放在与第一个副本不同机架的节点，第三个副本放在与第二个副本相同机架的不同节点。这个策略的目的很明确：保证机架级容灾（一个机架宕机还有别的机架有副本），同时兼顾写入性能（同机架传输快）。

还有一个高频选择题：HDFS在小文件场景下为什么性能差？答案是每个文件、目录、数据块在NameNode内存中对应一条元数据记录，一条记录大约占150字节，大量小文件会占用大量NameNode内存，且MapReduce处理小文件时每个文件至少需要一个Map任务，导致任务数爆炸。这个知识点也经常和后面的MapReduce结合考。

3.2 MapReduce：Shuffle是永恒的考点

MapReduce部分，Shuffle阶段是绝对的核心考点。Shuffle发生在Map输出之后、Reduce输入之前，包含完整的过程链：Map端输出 → 分区（Partitioner，默认按key的hash值对Reduce数量取模） → 环形缓冲区（默认100MB，达到80%阈值触发溢写） → 溢写前按key排序 → 溢写文件合并（Merge，合并时做归并排序） → 可选Combiner（在Map端做局部合并，减少网络传输） → 拉取（Reduce端从Map端拉取属于自己的分片数据） → 归并排序 → 分组 → Reduce函数处理。

笔试经常考环形缓冲区溢写比例是0.8，以及排序发生在溢写之前而不是之后。还有一个常考判断题：Combiner和Reducer的区别。Combiner是Map端的局部聚合，不能改变最终结果的数据类型和语义，比如求平均值就不能用Combiner，因为局部平均再平均不等于全局平均。这类细节是判断题的经典素材。

3.3 Spark：宽窄依赖、Stage划分、内存管理

Spark在大数据岗笔试里的地位越来越高，2020年网易的笔试题里Spark部分所占比例已经和Hadoop持平。高频考点包括RDD的宽窄依赖、Stage划分规则、Spark运行架构、持久化策略。

宽窄依赖的判断标准：父RDD的每个分区最多被子RDD的一个分区使用，则是窄依赖；父RDD的每个分区可能被子RDD的多个分区使用，则是宽依赖。典型的窄依赖有map、filter、union，典型的宽依赖有groupByKey、reduceByKey。笔试常考的是：为什么宽依赖需要Shuffle？因为宽依赖意味着父子RDD分区之间存在数据交叉，必须在集群范围内重新分配数据，这个过程中父RDD分区的数据需要被拉取到多个子RDD分区所在节点，就产生了Shuffle。

Stage划分规则必须记牢：从触发Action的RDD开始，向前回溯，遇到宽依赖就划分一个新的Stage；遇到窄依赖则归入当前Stage。换句话说，窄依赖是Stage内部的管道，宽依赖是Stage之间的边界。这个划分的目的是减少Shuffle次数，把可以管道化执行的计算链放在同一个Stage里。

Spark内存管理也常考。执行内存（Execution Memory）和存储内存（Storage Memory）的默认比例是0.3和0.5（统一内存管理，剩余0.2为保留内存），两者之间可以互相借用，但借用时如果对方需要可以强制回收。这个机制和笔试里的一个常见判断题相关："Spark执行内存和存储内存有严格的边界，互不干扰"，这个说法是错的。

3.4 Hive、Kafka、Flume、Zookeeper

这几个组件在选择题里出现频率也很高。Hive考的是SQL底层转换逻辑，比如一条SELECT ... GROUP BY语句底层会转换成MapReduce任务，GROUP BY对应Reduce阶段的聚合操作，JOIN的三种实现方式（MapJoin、Common Join、SMB Join）之间的区别和适用场景。还有一个细节容易考：Hive中分区分桶的区别，分区对应目录（partitioned by），分桶对应文件（clustered by），分桶能做更细粒度的数据划分和采样。

Kafka考的是消息投递语义、副本机制、消费者组。消息投递语义有三个级别：At Most Once、At Least Once、Exactly Once，笔试常考"如何实现Exactly Once"——需要生产者端开启幂等或事务，消费者端结合幂等消费或事务消息。副本同步有一个常见概念：ISR（In-Sync Replicas），即与Leader保持同步的副本集合，当Leader挂了之后，从ISR中选举新的Leader。这个知识点经常以场景题出现："某个Kafka分区Leader宕机，系统如何恢复读写？"

Flume考的是Source、Channel、Sink三类组件的职责，以及Channel的两种主要类型Memory Channel和File Channel的区别。Memory Channel读写快但数据可能丢失，File Channel慢但数据可靠。一句话总结就是：Flume的Channel选型是"速度与可靠性的权衡"，这正好呼应热搜词里提到的"减少错误、保证质量"。

Zookeeper则喜欢考它的应用场景：分布式锁、服务注册发现、集群元数据管理。经典题目是：Zookeeper实现分布式锁的原理，核心是临时顺序节点 + watch监听机制。创建临时顺序节点，判断自己是否是最小序号节点，是则获得锁，否则监听前一个节点。这个思路在HBase的Region分配、Kafka的Controller选举中也都有应用，理解一次就能举一反三。

3.5 高频考点速查表

4. 算法与数据结构的考察：TopK、分治、海量数据处理

网易大数据岗的编程题有一个显著特点：它不考纯竞赛向的难题，而是考"工程中真实会用到的算法"。2020年提前批的两道编程题都在海量数据处理的范畴内，本质上是把面试中常问的TopK问题、数据去重问题以编码形式呈现。

4.1 第一道编程题的典型解法：TopK的堆实现

给定一个包含海量整数的文件，找出其中最大的100个数。最直接的思路是全排序然后取前100，复杂度O(n log n)。但在海量数据场景下，全排序会面临内存不足的问题，更合适的方案是维护一个大小为100的最小堆：遍历每个数，如果数比堆顶大，则替换堆顶并调整堆。这样时间复杂度是O(n log 100)，近似O(n)，空间复杂度O(100)。

笔试要求写代码时，我建议直接用Java的PriorityQueue实现，代码简洁不容易出错：

public List<Integer> topK(int[] nums, int k) { PriorityQueue<Integer> minHeap = new PriorityQueue<>(k); for (int num : nums) { if (minHeap.size() < k) { minHeap.offer(num); } else if (num > minHeap.peek()) { minHeap.poll(); minHeap.offer(num); } } List<Integer> result = new ArrayList<>(minHeap); Collections.sort(result, Collections.reverseOrder()); return result; }

注意一个细节：PriorityQueue默认是小顶堆，如果要求最大的K个数，直接用默认实现即可。最后返回结果前如果要求降序排列，需要再排一次，否则输出顺序是堆内顺序，不是降序。这个细节虽然不影响正确性，但可能影响部分用例的比对方式。

如果数据量更大、连单机都放不下，那就需要分治：把大文件拆成多个小文件，每个文件分别用堆或排序找出局部TopK，最后做多路归并。这个思路在后面系统设计题里也会用到，属于大数据工程师的基本功。更极端的情况还有位图法（Bitmap）和布隆过滤器（Bloom Filter），但这道题用堆就已经够了。

4.2 海量数据的TopK问题，还有哪些变体

TopK最常见的变体是"求中位数"或"求第K大的数"。海量数据求中位数的经典做法是分桶法：先对数据做一次采样或直方图统计，确定中位数所在的范围，再在范围内精确计算。还有一个思路是两个堆——一个大顶堆存较小的一半，一个小顶堆存较大的一半，保持两个堆大小平衡，堆顶就是中位数或接近中位数。这个思路在笔试里如果时间充裕，可以作为一种优化解法写出来，能体现你对数据结构的灵活运用。

另一个高频变体是"海量数据去重后统计"：给定一个文件包含几十亿个URL，统计去重后还剩多少条。这个问题的标准答案是布隆过滤器（Bloom Filter），它的原理是用多个哈希函数把元素映射到一个位数组，查询时判断所有哈希位置是否都为1。布隆过滤器可以有误判（判断存在时可能误判，判断不存在时一定准确），但空间效率极高。笔试里如果只是问思路，答出"布隆过滤器 + 预计内存大小"就足够，如果要求代码实现，那么实现一个基本的布隆过滤器并不复杂。

4.3 刷题策略：真题比题海重要

很多同学准备笔试时一头扎进LeetCode刷了几百道题，但到了大数据岗的笔试现场发现题型和自己练的不太一样——考题更偏向"海量数据 + 分布式 + 复杂业务场景"的组合。我建议刷题顺序是：

1. 先掌握基础数据结构与算法的核心题：数组、链表、栈、队列、二叉树、堆、哈希表、排序、二分查找、快慢指针
2. 再重点突破高频考题：TopK、LRU缓存、手写单例、生产者消费者、多线程交替打印
3. 最后练海量数据专题：位图、布隆过滤器、分治、外排序、哈希分片

这样练下来，笔试遇到编程题大概率能快速定位到"它想考什么"。提前批真题数量有限，不用疯狂刷模拟题，把每个考点吃透比题海战术有效。

5. 简答与设计题：链路设计是"送分题"还是"送命题"

2020年笔试的最后一道简答/设计题，我记得是关于埋点日志分析链路的。题目大概是：某业务每天产生TB级别的埋点日志，需要设计一套离线分析系统，支持次日产出报表，并考虑数据延迟、数据倾斜、任务失败恢复等问题。这道题没有标准答案，但考察维度很清晰。

5.1 离线链路设计的基本框架

面对这类系统设计题，最容易丢分的情况是只写"用HDFS + Hive + 定时调度"一句话就结束。阅卷人想看的是你的完整链路设计能力和对细节的把控。我的答题框架是四层：

数据采集层：埋点日志通过Flume或Logstash采集到Kafka，Kafka作为数据缓冲层，解决大量日志并发写入对HDFS造成压力的问题。这里要写到Kafka的Topic分区策略和副本数设置。

数据存储层：Kafka数据经过Flink或Spark Streaming做实时清洗后写入HDFS，按天或按小时做分区，存储格式上关注列式存储（Parquet或ORC）与压缩算法（Snappy或Zstd）。这一步要写清楚为什么选列式存储——OLAP场景下查询只需要读取相关列，减少IO。

数据计算层：使用Hive或Spark SQL进行离线ETL和报表计算。调度上使用Azkaban或Apache DolphinScheduler编排任务依赖。这里要特别写清楚任务失败的处理机制：失败自动重试、重试次数限制、失败告警、数据回填。

数据服务层：计算结果写入MySQL、ClickHouse或Kudu，供报表系统查询。如果报表数据量大，要考虑预聚合和结果表分层。这里要提到数据质量监控：每天产出后对数据总量、关键指标波动做校验，超过阈值则告警。

5.2 数据倾斜与延迟：设计题里必须回答的细节

设计题最容易拉开分差的点，是你在链路中主动识别了哪些风险并给出了方案。我就以数据倾斜为例。埋点日志中90%的流量可能集中在几个热门页面，这会导致对应的Reduce任务处理时间远大于其他任务，整体任务卡在长尾上，这就是数据倾斜。

数据倾斜的解决方案要写全：

• 过滤异常Key：先把导致倾斜的Key单独拎出来，统计其数据量，确认是脏数据就过滤掉
• 加盐（Salting）：给倾斜Key加随机前缀，让数据分散到多个Reduce任务，再对结果做二次聚合
• 调整并行度：增大Reduce数量，但要注意这只在"数据量大但Key分布不均匀"的情况下有效
• 使用两阶段聚合：Map端先做局部聚合，Reduce端再做全局聚合，减少Shuffle数据量

另一个必须回答的点是数据延迟。日志数据的到达天然有延迟，可能出现某天的数据在第二天凌晨才完全到达的情况。设计时要明确"数据迟到如何处理"：是用事件时间窗口还是处理时间窗口，如果任务跑完后又有迟到数据到达，是触发数据回刷还是放弃。这些边界条件的处理，比链路本身更能反映你的工程经验。

5.3 实时链路：一个通用的"加分答案"

如果笔试时间充裕，设计题还可以写一段实时链路的补充方案。埋点日志除了离线分析，还需要实时监控核心指标，比如实时用户数、实时订单量。这时候链路变成：Flume采集 → Kafka → Flink做窗口聚合 → 结果写入Redis或ClickHouse → 前端大屏展示。

Flink的核心概念在实时链路设计题里经常要用到：

• 事件时间、水位线（Watermark）如何解决乱序数据问题
• 窗口类型的选择：滚动窗口、滑动窗口、会话窗口
• 状态后端的选择：RocksDB还是堆内存，各有什么利弊
• Checkpoint机制如何保证精确一次语义（Exactly Once）

把离线链路和实时链路都答出来，设计题基本可以拿到很高的分，因为这说明你脑子里有一个完整的数据架构，而不是只会背组件。

5.4 写设计题的三个习惯

第一，先画出数据流向再动笔。在草稿纸上标清楚每个组件之间的数据流向和接口，再落笔写正文，保证逻辑不混乱。第二，主动写出"为什么"，比如"选择Kafka作为缓冲层是因为它具备高吞吐、数据可回溯、可多消费者订阅的特点"，这种解释比单纯列组件名有说服力得多。第三，预留一个"如果数据量翻10倍怎么做"的扩展段，这说明你有水平扩展的思维，是面试官非常看重的工程素养。

6. 关于这套题的备考路线与注意事项

最后想分享几个备考过程中的实际经验，特别是针对"如何在有限时间内最高效地准备这套题"。

6.1 三轮复习法

我见过太多人备考校招笔试时，第一轮就抱着源码开始啃，结果一个HashMap的源码看了三天，最后什么都记不住。我更推荐三轮复习法：

第一轮（约2周）：提纲挈领，建立知识地图。把Java核心、Hadoop、Spark、Hive、Kafka、Zookeeper每个组件的高频考点列成清单，做一个思维导图或Excel表格，做到"看到题目立刻知道它考哪个知识点"。

第二轮（约2周）：逐点击破，按专题刷题。针对每个考点找3-5道真题或模拟题练习。遇到答错的题不要只看答案解析，要回到原理层面重新理解。比如你答错了"MapReduce的排序发生在哪个阶段"，不要只看答案是"溢写前排序"，要重新理解整个Shuffle流程。

第三轮（约1周）：全真模拟，卡时间做套题。严格按照120分钟完成一套题，模拟真实考试的压力环境。特别要注意多选的时间控制，三道多选如果都拿不准，建议先凭第一直觉选完，标记出来，回头再检查，不要卡在中间耗掉后面编程题的时间。

6.2 多选和简答的"保分策略"

多选是这套笔里最坑的一部分，因为少选不得分，多选也不得分，只有完全选对才算对。这意味着你不仅要掌握"正确选项为什么对"，还要掌握"错误选项为什么错"。一个实用的方法是给每个选项标注"知识点关键词"，而不是仅仅选ABCD。比如选项是"Spark的窄依赖包括map、filter、reduceByKey"，你要能立刻反应过来reduceByKey是宽依赖，这个选项就是错的。这种标注能力需要平时的刻意练习。

简答题则要遵循"宁可多写不要少写"的原则，但多写不是堆废话，而是多写有信息量的内容。比如问"HDFS的副本放置策略"，除了写三个副本的放置规则，还可以写"这个策略兼顾了可靠性（跨机架容灾）与性能（同机架传输快）"，这句"设计意图"是采分点。

6.3 最后一周的考前重点

考前最后一周，不建议再学新知识了，重点是查漏补缺和保持手感。我会把之前整理的知识地图再过一遍，把每个考点的"核心概念+易错点+常见问法"说给自己听，像讲课一样，能讲清楚说明真正掌握了。同时每天保持做1-2道编程题热身，保持代码手感。

还有个容易忽略的点是：提前批笔试前一定要确认好考试平台和网络环境，有些平台要求摄像头监控，有些要求共享屏幕，提前调试好设备比多背一个知识点更重要。我当年就有同学因为考试环境调试失败，笔试开始半小时才进入系统，直接影响了状态。

6.4 笔试结束后的动作

笔试结束后不要干等结果。第一时间把考场上没做出来的题复盘一遍，尤其是那些"好像知道但写不出来"的知识点，这正是面试前查漏补缺的最好线索。把每道题对应的知识点整理成一份"笔试复盘文档"，在面试前重点回顾。我当时的经验是：笔试中暴露的每一个薄弱点，几乎都对应着面试官在后续面试中会追问的方向，早点补上，面试时就能从容应对。

对于网易这种大厂的提前批，笔试只是第一道关卡，后面还有三轮左右的面试，但笔试成绩直接决定了面试的优先级。如果你想投递的是大数据开发工程师岗，建议把上面提到的知识链路整体过一遍，不要心存侥幸，毕竟每年都有大量候选人因为基础不扎实倒在笔试环节。扎实地把每个知识点过一遍，到了面试阶段你会感谢现在的自己。