浩鲸科技2019校招大数据研发类笔试题，先说下背景。浩鲸科技这家公司，前身是中兴软创，在电信行业BSS/OSS系统里做得比较深，后来被阿里投资，整体技术栈和业务方向都往云计算、大数据、智慧城市这些方向靠。2019年校招那会儿，大数据岗位的笔试基本反应了当时行业内对大数据研发工程师的能力预期：Java基础要扎实、Hadoop生态要熟悉、SQL要写得溜、实时计算刚起步但已经进入考察范围。我当年也是校招大军里的一员，刷过不少类似的题，所以这篇把这类笔试题的考点、解题思路和踩坑点拆开讲讲。
先说一下这篇内容的定位。如果你是正在准备大数据校招的同学，这篇能帮你快速梳理笔试的核心考察范围；如果你已经工作了一两年，这篇也能帮你复盘一下基础知识有没有漏洞。内容围绕Java、Hadoop、Spark、SQL、实时计算几个模块展开，每个模块会讲到真题长什么样、背后的考点是什么、答题的思路是什么，尽量做到可以直接拿去用。
1. 笔试题型结构与考察思路拆解
1.1 整体题型分布
2019年校招大数据研发类笔试，基本逃不出这个框架：选择题（单选多选混合）、简答题、编程题、SQL题、系统设计题。浩鲸科技的这套题也是这个路子，整体难度在行业里属于中等偏上，比BAT的稍微友好一点，但比普通传统企业的要扎实不少。
选择题大概占40到50分，覆盖Java基础、JVM、并发编程、Hadoop核心组件、Hive常用函数、Spark核心概念。这些题考得很细，比如HashMap的put流程、HDFS的读写机制、MapReduce的shuffle过程、Spark宽窄依赖的判断，全是基础但必须记牢的知识点。
简答题一般是2到3道，常见的有：MapReduce执行流程描述、数据倾斜的原因和解决方案、Hive和传统数据库的区别。这类题考察的是系统理解能力，光背概念不够，要能把整个流程说得清晰有条理。
编程题通常是1到2道，用Java或Scala实现，难度不算高，主要考察JVM内存模型理解、集合类使用、多线程处理这类基础编码能力。
SQL题占了很大比重，这个和大数据开发实际工作强相关。常考窗口函数（尤其row_number排序）、分组聚合、行列转换、连续登录问题这类经典场景。SQL写得好不好，基本决定了这部分的得分。
系统设计题最后压轴，常见的是设计一个日志分析系统，或者实现一个大数据量下的去重方案。这类题没标准答案，考察的就是你的工程思维和知识面。
1.2 命题背后的岗位画像
从这套题的构成来看，浩鲸科技大数据研发岗的画像很清晰：不需要你是算法专家，但要求你懂数据链路、会写数据任务、能处理生产环境的问题。
笔试考Java而不只考大数据组件，是因为大数据框架的底层基本都是Java（或JVM系语言），不懂JVM和并发，出了问题根本定位不了。考SQL是因为离线数仓是日常工作的重头戏，Hive SQL写不好，数据任务就推不下去。考Hadoop、Spark原理是因为生产环境调优必须理解源码层面的机制，而不是只当API调用工。
说白了，这个岗位要的是懂原理的实践者：既能写得了代码，也能看得懂数据跑得慢的原因，还能在集群出问题的时候有排查思路。
2. Java核心考点：集合、并发与JVM
2.1 HashMap底层原理必考题
HashMap在大数据笔试里出现频率极高。2019年的卷子里有一道选择题考了HashMap的put流程，选项包括：先计算hash、判断是否需要resize、发生hash冲突时用链表还是红黑树、什么时候转红黑树。看似简单，但错的人不少。
完整流程要记清楚：先对key做hash计算（高位参与运算，减少碰撞），然后定位到数组桶位。如果桶为空，直接放入；如果桶非空且第一个元素key相同，直接覆盖；如果是红黑树节点，走树的插入逻辑；如果是链表，遍历查找，找到相同key就覆盖，找不到就尾插。插入完成后判断链表长度是否超过8且数组长度超过64，满足条件就转红黑树。最后判断size是否超过threshold，超过就resize扩容。
有个容易被忽略的点：扩容阈值不是数组长度，而是数组长度乘以负载因子（默认0.75）。也就是说初始容量16的HashMap，存到第13个元素时就会触发扩容，不是等数组填满才扩。
注意：JDK 1.7的头插法和1.8的尾插法是高频考点。头插法在并发扩容时会形成环形链表，导致get死循环，这也是为什么面试官总爱追问HashMap为何线程不安全。
2.2 并发编程与锁机制
大数据岗位必须懂并发，因为MapReduce和Spark的并行模型本质都是多线程/多进程并发。笔试里常考的是synchronized和ReentrantLock的区别、volatile的可见性和禁止指令重排、CAS的ABA问题。
volatile这个知识点考得尤其多。一句话概括：volatile保证可见性和有序性，但不保证原子性。很多人在这块丢分，是因为把可见性和原子性混淆了。可以用一个计数器例子来理解：两个线程同时对volatile变量做a++操作，结果可能小于预期值，因为a++不是原子操作，先读取再写入的过程中有可能丢失更新。
CAS的ABA问题也会考：线程1读取到A，线程2把值改成B又改回A，线程1的CAS操作仍然成功，但实际数据已经被修改过。解决方案就是加版本号，Java里的AtomicStampedReference就是干这个的。
2.3 笔试中的Java代码题实战
题目场景一般是：有一个日志文件，每行是一个IP地址，统计出现次数最多的前5个IP。
这个题有双重考察意图：一是Java基础编码能力，二是对MapReduce思想的理解。如果笔试时间充裕，可以按下面这个思路写：
public static void topNIPs(String[] ips, int n) { Map<String, Integer> countMap = new HashMap<>(); for (String ip : ips) { countMap.put(ip, countMap.getOrDefault(ip, 0) + 1); } // 使用优先队列维护大小为n的最小堆 PriorityQueue<Map.Entry<String, Integer>> heap = new PriorityQueue<>((a, b) -> a.getValue() - b.getValue()); for (Map.Entry<String, Integer> entry : countMap.entrySet()) { if (heap.size() < n) { heap.offer(entry); } else if (entry.getValue() > heap.peek().getValue()) { heap.poll(); heap.offer(entry); } } // 输出结果 while (!heap.isEmpty()) { Map.Entry<String, Integer> entry = heap.poll(); System.out.println(entry.getKey() + ": " + entry.getValue()); } }这个解法比直接全排序好，时间复杂度是O(nlogk)，k是5，而且展示了你对TopN问题的理解。面试官看到这个答案，会觉得你不是只会写业务代码的人。
3. Hadoop生态核心考点：原理、机制与调优
3.1 MapReduce执行流程必须说透
MapReduce流程是笔试题里的"必考大题"，几乎每个公司都会问。浩鲸科技也不例外，我记得这套题里有一道简答题就是"描述一个MapReduce作业从提交到完成的完整过程"。
答题要分几个层级：客户端提交作业到YARN，ResourceManager分配ApplicationMaster，AM向RM申请容器跑MapTask，Map阶段做split和map处理，然后进入shuffle，最后Reduce阶段汇总输出。
shuffle是重点，里面细节点多：map端先写入环形缓冲区（默认100MB），达到80%阈值就spill到磁盘，spill前做partition和sort，如果配置了combiner就提前做一次本地聚合；reduce端拉取属于自己的分区数据，做merge sort，然后分组喂给reduce函数。
注意：环形缓冲区的阈值比例是可以调的，mapreduce.map.sort.spill.percent默认0.8。如果调大这个值，可以减少spill次数，但增加了内存OOM风险，生产环境一般不建议动。
3.2 数据倾斜：笔试和面试都躲不开的话题
数据倾斜是MapReduce和Spark里最经典的实战问题，笔试必考。经典问法是"数据倾斜的原因是什么，怎么解决"。
原因要从几个角度答：一是key分布不均，比如大量相同key的用户ID；二是业务数据本身有热点，比如某个商家的订单量特别大；三是分区函数选得不合理，比如用某个字段hash但该字段值大量重复。
解决方案也要分场景说：有单独处理热点key的（加随机前缀打散再做二次聚合），有提高reduce并行度的，有把小表转成broadcast的，有调整combiner提前聚合的。如果你能把"加盐"这个思路说透，基本就是满分答案。加盐的思路我用一个简单例子讲：假设订单表里上海的数据占80%，其他城市占20%，按城市聚合时上海这个key就会把所有数据压到同一个reduce上。解决方法是给上海的key加上随机后缀，比如上海_0、上海_1、上海_2，让它们分散到多个reduce处理，最后再合并一次上海_0、上海_1、上海_2的结果。
3.3 YARN调度器：不用背太深但要懂区别
YARN调度器的题出现的频率稍低一些，但一旦出现就是拉分项。三种调度器：FIFO、Capacity Scheduler、Fair Scheduler。重点考Capacity和Fair的区别。
Capacity Scheduler是队列资源预分配机制，每个队列有最小资源保证，队列内部又是FIFO或层级队列。适合多租户稳定使用。Fair Scheduler是动态公平分配，任务多时每个任务分到的资源减少，任务少时单个任务可以吃满集群资源。
一句话总结：Capacity是"保证下限"，Fair是"动态均衡"。答题时如果能提一句"生产环境多数用Capacity"并说明原因——稳定性更好、资源隔离更强，会显得你有实际经验。
4. Spark核心考点与性能优化
4.1 RDD、DAG与血缘机制
Spark部分的考察重点是概念理解。RDD的特性、DAG的构建、血缘（lineage）机制、checkpoint的作用。
RDD的五大特性要记清楚：分区列表、计算函数、依赖关系、分区器（可选）、首选位置（可选）。这五个特性对应了Spark能够实现容错和并行计算的基础。
DAG构建流程是高频题：RDD通过transformation操作形成依赖关系，Spark根据依赖关系划分Stage。宽依赖会划分Stage，窄依赖不会。因为宽依赖意味着shuffle，数据要在节点间传输，所以要等父Stage所有任务完成才能开始子Stage。
血缘机制用来做故障恢复：某个分区的数据丢失时，可以根据血缘关系重新计算，不需要全量重跑。但血缘链太长时恢复成本高，这时就要用checkpoint把中间结果持久化到可靠存储（比如HDFS），切断血缘链。
4.2 宽窄依赖与Stage划分
这个概念是Spark里的分水岭，懂了它，spark作业运行机制就懂了一半。窄依赖：父RDD每个分区最多被子RDD一个分区使用，典型操作是map、filter、union。宽依赖：父RDD一个分区被子RDD多个分区使用，典型操作是groupByKey、reduceByKey、join。
Stage划分规则很简单：遇到宽依赖就断开，前后各为一个Stage。一个Stage内的所有任务可以并行执行，不需要等待其他Stage的数据。
注意：join不一定都是宽依赖。如果两个RDD都做了相同的分区器（比如都按key做了hash分区），join时如果分区一致，就是窄依赖，不需要shuffle。这个点只有源码看过的人才能答出来，你说了面试官会眼前一亮。
4.3 Spark调优：笔试里的"加分项"
Spark调优的题通常不会单独考，而是在系统设计题或者面试环节出现。但笔试选择题里偶尔会考：reduceByKey和groupByKey的区别、为什么reduceByKey性能更好、如何解决Spark数据倾斜。
reduceByKey vs groupByKey是送分题。reduceByKey在map端先做本地聚合，然后才shuffle，传输的数据量大大减少；groupByKey直接全量shuffle，不做任何预聚合。能用reduceByKey的场合就不用groupByKey，这是基本常识。
Spark数据倾斜的解决方案和MapReduce类似：加盐打散。另外Spark特有的方案包括：调整并行度（spark.sql.shuffle.partitions）、广播小表（broadcast join）、使用AQE（Spark 3.0+的动态分区裁剪）。
5. SQL与离线数仓考察要点
5.1 窗口函数：必考核心技能
SQL题是2019校招大数据笔试里占比最大的题型之一，浩鲸科技的卷子里至少有3道SQL大题。核心考点就是窗口函数。
窗口函数的经典场景：分组TopN、连续登录天数、同比环比、累计求和。其中row_number + 分组取TopN是出现频率最高的。
举一个典型例题：有一个用户订单表orders（user_id, order_date, amount），求每个用户下单金额最高的前3笔订单。
select user_id, order_date, amount from ( select user_id, order_date, amount, row_number() over(partition by user_id order by amount desc) as rn from orders ) t where rn <= 3;这里考察两个知识点：一是row_number()的用法和分区排序逻辑，二是子查询嵌套的写法。如果你能用rank()或dense_rank()代替row_number()，并说明它们之间的区别（并列排名时的处理方式），这道题就是满分。
5.2 数仓分层模型：维度建模基本概念
笔试选择或简答题偶尔会考数仓分层：ODS、DWD、DWS、ADS四层模型，每一层做什么要说得清楚。
- ODS（操作数据存储层）：原始数据落地，保持原样，不做过多的清洗加工。
- DWD（数据明细层）：清洗、去重、维度退化，做成明细事实表。
- DWS（数据服务层）：按主题汇总，比如用户主题、商品主题的轻度聚合。
- ADS（应用数据层）：面向业务应用的结果表，数据量小，查询快。
答题时如果能补充一句"分层的核心目的是复用和统一，避免烟囱式开发"，会显得你对数仓有整体认知。
5.3 SQL笔试题的常见陷阱
SQL题丢分很多时候不是不会写，而是没看清楚题目要求。几个常见的坑我列出来：
- 题目要求去重，你忘了distinct或row_number去重。
- 题目要求按日期排序取最近N条，你忘了加order by的排序方向。
- 分组聚合时select的字段没包含在group by里，这在MySQL里可能不报错但结果不对。
- 关联查询时忘了考虑null值。null和任何值关联都匹配不上。如果业务上需要用null匹配，要用<=>操作符或者做特殊处理。
- 日期函数用错，比如date_sub和date_add的方向搞反。
这类陷阱其实是好事，刷一道巩固一个知识点。笔试考场上哪怕只是提醒自己"先看要求再看数据，写完先跑边界条件"，就能避开一半的坑。
我当时刷题的习惯是：每道题写完后，在结果里人为构造一些边界数据，比如今天是月初、跨年、某个用户没有订单、所有数据都是同一天，跑一遍看结果是否合理。这个习惯帮我在真实笔试里查出了好几个低级错误。
6. 实时计算与系统设计题
6.1 Flink基础概念：2019年的新趋势
2019年Flink已经在大厂开始流行了，虽然很多公司的校招笔试还没纳入Flink，但浩鲸科技这类跟阿里系走得近的公司已经开始出相关题目了。选择题里考了Flink的窗口类型和状态管理。
Flink窗口三种类型：滚动窗口（Tumbling）、滑动窗口（Sliding）、会话窗口（Session）。要能说出区别：滚动窗口时间不重叠、首尾相接；滑动窗口有重叠区域，可能一条数据同时属于多个窗口；会话窗口根据数据活跃时间划分，空闲超时自动关闭。
状态管理方面，常考的是Flink的checkpoint机制。Flink通过周期性生成分布式快照来实现精确一次（exactly-once）语义。答题时要点出：checkpoint是异步的，通过Barrier机制实现，Barrier对齐时数据不会乱序。
6.2 系统设计题答题方法论
笔试最后一道系统设计题，通常是：设计一个实时日志分析系统，要求每秒处理百万级日志，支持按用户IP、访问URL、时间维度统计。这类题没有标准答案，但答题思路有套路。
我的框架是四个步骤：数据接入、数据处理、数据存储、数据展示。
数据接入：日志采集用Flume或Filebeat发到Kafka，Kafka做缓冲削峰，分区数至少和下游消费并行度匹配。
数据处理：用Flink消费Kafka，做清洗、过滤、聚合计算。如果没有实时需求，也可以走Spark Streaming。如果要支持秒级延迟，必须用Flink。
数据存储：统计数据分两类。指标类（如QPS、PV）可以存Redis或Druid；明细类存ES或HBase；离线分析结果可以落到Hive/ClickHouse。
数据展示：前端图表用报表工具或自研平台，后端提供查询API。查询性能优化可以用预聚合 + 缓存（比如Redis缓存最近一小时的统计结果）。
答题时体现"为什么这样选"是拿高分的关键。比如Kafka的分区数，要说明和下游Flink并行度的关系——分区数是消费并行度的上限，分区太少了并行度提不上去，太多了增加管理开销。再比如存储选型，要根据查询模式和数据量来判断：支持多维分析的用Druid/ClickHouse，支持秒级查询的用ES，支持事务更新的用MySQL。
注意：设计题不是考你选什么组件，而是考你的思路是否清晰。哪怕用的技术栈很常规，只要逻辑自洽、考虑到了容量规划和容灾设计，分数都不会低。
7. 备考建议与实战经验分享
7.1 考前一个月的复习重点
离笔试还有一个月时，复习策略要有优先级。我自己的经验是：先把高频考点过一遍，刷题在精不在多。
优先级最高的模块是Java集合和并发、Hadoop核心机制、SQL窗口函数、Spark RDD概念。这四个模块占了笔试60%以上的分数，性价比最高。
其次是Hive常用函数和数据倾斜方案、YARN调度、Flink基础概念。这些属于"背了就有分"的内容。
最后才是系统设计题，这部分短期提升有限，主要靠平时的知识积累，但要把答题框架记熟，至少能保证不慌。
7.2 笔试答题的时间分配建议
2019年这类笔试总时长一般在90到120分钟，题量大概8到12道大题加选择题。我的时间分配策略是：
选择题控制在15到20分钟内，不会的先跳过做个标记。SQL题每道10到15分钟，这类题只要会做就能拿全分，值得花时间仔细写。简答题每道8到10分钟，用要点式回答，别写长篇大论。编程题20到25分钟，留足调试时间。设计题15分钟，用框架式思路快速展开。
有个小技巧：笔试系统如果支持本地IDE编译，务必先把代码在本地跑通了再粘贴上去。很多在线笔试环境不提供编译反馈，直接把有语法错误的代码贴上去等于白做。
7.3 我踩过的坑和复盘心得
写这个部分主要想让大家少走弯路。
第一个坑是过度关注大数据组件，忽略了Java基础。我当年花了很多时间看Spark源码解析和Flink原理，结果笔试选择题里好几道Java的题答得模棱两可。后来复盘发现，大数据笔试里的Java题往往是最基础的，但正因为基础，很多人反而没复习到位。
第二个坑是SQL题写得不够规范。笔试批卷有时候会人工看，字段命名不清晰、没有加注释、代码排版混乱，都会影响最终得分。我当时写SQL不太在意缩进和注释，后来养成了用格式化工具整理SQL再加注释的习惯。
第三个坑是简答题答得太散。MapReduce流程这种题，最好用"第一步、第二步"的方式按顺序写，把关键术语和技术名词用准确。人工阅卷时，踩点给分，要确保核心术语都在答案里。
第四个坑是不做总结和复盘。笔试结束后很多人对完答案就不管了，其实每一道错题都值得分析和记录。我当时专门建了一个错题文档，把错题按考点分类标注，考前一个月集中复习错题文档，效率比从头刷一遍题库高得多。
7.4 后续扩展的方向
大数据这个方向，笔试只是起点。如果你想在这个行业长期发展，我觉得有几个方向值得持续投入：
第一是源码阅读。Hadoop、Spark、Flink的源码虽然庞杂，但不需要全读。从一个核心类的核心方法入手，比如Spark的TaskScheduler、Flink的CheckpointCoordinator，读明白一个再扩展，理解会越来越深。
第二是实战项目。笔试考的是知识，工作考的是解决问题。自己搭一套离线数仓或者实时计算链路，从环境搭建到数据开发到调优，做完一个完整项目，比刷十套题更有用。
第三是拓宽视野。数据技术栈更新很快，前几年是Hadoop生态的天下，现在实时计算、数据湖、云原生数据库这些新方向都在快速发展。保持学习的节奏，才不会被淘汰。
最后分享一个我的个人习惯：不管笔试还是面试，结束后我都会把试题回忆版整理出来。一方面方便自己复盘，另一方面分享给别人也可以攒人品。这个习惯帮我积累了很多题目素材，也帮我养成了结构性思维的习惯。如果你也在准备校招，建议你也试试这么做。
