浩鲸科技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核心考点集合、并发与JVM2.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) { MapString, Integer countMap new HashMap(); for (String ip : ips) { countMap.put(ip, countMap.getOrDefault(ip, 0) 1); } // 使用优先队列维护大小为n的最小堆 PriorityQueueMap.EntryString, Integer heap new PriorityQueue((a, b) - a.getValue() - b.getValue()); for (Map.EntryString, 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.EntryString, Integer entry heap.poll(); System.out.println(entry.getKey() : entry.getValue()); } }这个解法比直接全排序好时间复杂度是O(nlogk)k是5而且展示了你对TopN问题的理解。面试官看到这个答案会觉得你不是只会写业务代码的人。3. Hadoop生态核心考点原理、机制与调优3.1 MapReduce执行流程必须说透MapReduce流程是笔试题里的必考大题几乎每个公司都会问。浩鲸科技也不例外我记得这套题里有一道简答题就是描述一个MapReduce作业从提交到完成的完整过程。答题要分几个层级客户端提交作业到YARNResourceManager分配ApplicationMasterAM向RM申请容器跑MapTaskMap阶段做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、使用AQESpark 3.0的动态分区裁剪。5. SQL与离线数仓考察要点5.1 窗口函数必考核心技能SQL题是2019校招大数据笔试里占比最大的题型之一浩鲸科技的卷子里至少有3道SQL大题。核心考点就是窗口函数。窗口函数的经典场景分组TopN、连续登录天数、同比环比、累计求和。其中row_number 分组取TopN是出现频率最高的。举一个典型例题有一个用户订单表ordersuser_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发到KafkaKafka做缓冲削峰分区数至少和下游消费并行度匹配。数据处理用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生态的天下现在实时计算、数据湖、云原生数据库这些新方向都在快速发展。保持学习的节奏才不会被淘汰。最后分享一个我的个人习惯不管笔试还是面试结束后我都会把试题回忆版整理出来。一方面方便自己复盘另一方面分享给别人也可以攒人品。这个习惯帮我积累了很多题目素材也帮我养成了结构性思维的习惯。如果你也在准备校招建议你也试试这么做。