“触宝科技2017秋季校招笔试后端大数据第二批”这个标题放在今天看可能有些年头了但经历过那几年校招的人再回头看会发现这类试卷的命题逻辑其实非常稳定。它基本代表了一批产品型移动互联网公司在招后端大数据方向应届生时的主流考察标准Java基础和并发、网络与数据库这些后端基本功要扎实Hadoop生态、Spark、Kafka这些大数据组件要真正理解同时还不能是个只会背概念的选手。这篇文章就把这类笔试从考察思路、核心考点、典型题目到避坑经验完整拆一遍正在准备后端或大数据方向校招的同学可以参考工作后想系统复盘自己技术体系的人也能从这套试卷结构里看出一些门道。我没办法给你还原当年的每道原题但这类校招笔试题的题型和考点高度稳定本质上是在用一套固定的框架筛选“来了就能干活”的人。下面所有内容都是基于这类试卷的考察逻辑做的梳理和还原结合的是行业里通用的笔试复盘经验你可以把它当成一套完整的备考地图来用。1. 笔试整体考察思路拆解1.1 移动互联网公司校招笔试到底想筛什么样的人先说一个很多人容易搞错的点企业笔试不是ACM竞赛目的不是为难你而是快速筛掉“基础不牢”的候选人。就拿触宝这种产品型公司来说后端大数据岗位的日常工作很具体维护数据采集链路、跑离线任务、优化实时计算作业、响应业务方的取数需求。笔试要考察的就是你能不能胜任这些具体工作。所以你会发现试卷里的题目难度普遍维持在“基础扎实就能答”的水平不会出现偏题怪题。HashMap的底层原理、TCP三次握手、SQL的join查询、MapReduce的shuffle流程这些题单独拿出来都不难难的是在90到120分钟内把一整卷题都答得又快又稳。这也解释了为什么很多“刷题刷得很深”但知识面偏窄的同学反而容易在笔试阶段翻车——这类试卷考察的是广度优先的工程基础而不是某个方向的深度花活。1.2 试卷结构与时间分配的底层逻辑这类笔试试卷通常由四到五个部分组成基础选择题或填空题、手写代码题、SQL查询题、简答题、场景设计题。按经验来看前面的基础题往往占30%到40%的分值代码题和SQL题是拉分的关键场景设计题则决定了你能不能进终面。基础题考察的是你在短时间内能调取多少“肌肉记忆”比如Java集合类的线程安全性、TCP的TIME_WAIT状态、索引失效的场景。这类题不能犹豫每道题控制在1到2分钟拿不准就果断标记跳过。代码题一般有两道左右其中一道是数据结构算法题另一道往往和大数据场景结合比如手写一个简化版的WordCount、求TopN或者模拟分组统计。SQL题通常是三到四道从简单查询逐步过渡到多表join和窗口函数。场景设计题放在最后分值最高重点考察你对数据链路整体架构的理解。我建议的时间分配是基础题30到40分钟代码题30分钟SQL题20到25分钟场景题15到20分钟留5到10分钟回头补做跳过的题目。这里有个很实用的小技巧拿到试卷先不要急着做花3到5分钟快速浏览全部题目心里对整张卷子的难度分布立刻有数哪些题目是送分题、哪些题目是大题先排好优先级。这一步看起来不起眼但特别能避免“前面磨蹭太久最后大题没时间写”的悲剧。1.3 为什么后端基本功和大数据生态会放在同一张卷子里很多同学会把“后端开发”和“大数据开发”看成两个完全不同的方向但在实际岗位里这两者的边界非常模糊。大数据平台本身就是一个分布式后端系统HDFS要处理海量文件的读写NameNode的元数据管理本质是分布式状态管理Kafka要保证消息的高吞吐和可靠投递背后是网络通信、存储、一致性这些后端基础问题Spark的Executor要管理内存和线程池更是直接建立在JVM和并发基础之上。所以你会发现这套试卷在命题时有一条暗线后端基本功是底层能力大数据组件是应用场景。问你Java内存模型后面可能就跟着问Spark的内存管理问你事务的隔离级别后面可能就跟着问Hive的ACID特性。答题的时候如果你能把两者串起来讲比如解释为什么Spark比MapReduce快时顺带提到JVM复用和堆外内存面试官对你的评价会明显不一样。这也是很多高分试卷的共同特点不是每个知识点都答得天花乱坠而是能把跨知识点的关联说清楚。2. 核心考点与题型详解2.1 Java与并发笔试里永远绕不开的主战场先说Java部分这是绝大多数后端大数据岗位笔试的第一道关卡。集合类是肯定要考的HashMap的底层数据结构、put操作的流程、扩容机制、为什么线程不安全这些都是高频中的高频。当年这类题目有一个很经典的问法HashMap在多线程环境下会出现什么问题如果你能说出并发put可能导致数据覆盖、JDK7及以前版本扩容时可能形成环形链表导致死循环基本就能拿全分。进阶一点还会考ConcurrentHashMap的实现演进从分段锁到CAS加synchronized这个变化一定要了解因为后面你会经常在并发编程里遇到类似的无锁优化思路。JVM部分重点看内存区域划分、对象创建过程、垃圾收集算法和三色标记。笔试阶段通常不会考太深但你要能说清楚新生代和老年代的区别、哪些对象会进入老年代、CMS和G1各自的特点。这里有一个被反复考察的细节什么情况下会发生Full GCFull GC对大数据任务意味着什么。这个问题之所以受欢迎是因为它实际上在考察你对实时计算任务延迟的理解——Spark或Flink的Executor如果频繁Full GC整个作业的吞吐量都会遭受重创。并发编程是笔试分差最大的模块。synchronized和ReentrantLock的区别、volatile的可见性和禁止重排序原理、线程池的核心参数和四种拒绝策略这些属于必背内容。我建议你把AQSAbstractQueuedSynchronizer的原理好好看一遍虽然笔试不一定会直接考但它能把Lock、Semaphore、CountDownLatch这些知识点串成一条线。另外线程池的提交流程也是高频题核心线程数已满、阻塞队列已满、最大线程数已满分别对应什么行为必须张口就来。2.2 计算机网络与操作系统基础不能再基础网络部分的考察集中在TCP和HTTP。三次握手和四次挥手的过程、为什么需要TIME_WAIT、SYN Flood攻击的原理这三件事必须烂熟于心。笔试时容易丢分的地方在于细节比如TIME_WAIT为什么主动关闭方需要等待2MSL如果你只说“为了保证对方收到ACK”就不够全面还要补充“为了让旧连接的报文在网络中消失避免影响新连接”这两点合起来才算完整答案。HTTP与HTTPS的区别也是常客。除了熟知的端口差异和加密方式你要能说清楚HTTPS建立连接时SSL/TLS握手的过程重点讲清楚对称加密和非对称加密各自用在哪个环节。另外HTTP常见的状态码比如301和302的区别、401和403的区别、502和504的区别这类题属于纯记忆题考前速记一遍就能拿分丢了很可惜。操作系统部分进程和线程的区别属于送分题但死锁的四个必要条件和预防措施就是分水岭了。你要是能举出实际工程中的死锁案例比单纯背概念要得分高得多。比如两个Spark任务互相持有锁并等待对方释放就可以类比成死锁的循环等待条件。另一个高频考点是IO多路复用select、poll、epoll的区别这个知识点对理解高并发网络框架很有帮助笔试和面试都常被追问。2.3 数据库与MySQL优化后端开发的基本盘数据库考察的核心只有一个索引。B树为什么适合做索引、聚簇索引和非聚簇索引的区别、回表是什么、覆盖索引是什么、最左前缀原则是什么这些是必须形成条件反射的内容。笔试里我见过一道很经典的题给定一个联合索引(a, b, c)然后问哪些查询能用上索引、哪些不能。这种题不难但如果你没真正理解最左前缀原则很容易在边缘条件上栽跟头。事务部分要重点看ACID和隔离级别。MySQL默认的隔离级别是RR可重复读这一点也常考。你不需要背下MVCC的所有实现细节但至少要理解MVCC通过版本链和ReadView实现了快照读因此InnoDB在RR级别下能部分解决幻读问题。另外间隙锁Gap Lock的概念要了解它本质上是在索引记录之间加锁防止其他事务插入数据这也是RR级别下解决幻读的关键手段。SQL题是笔试中性价比极高的题目。join的几种类型、group by和having的配合、子查询和临时表的使用这些都是基本功真正拉分的是窗口函数。row_number()、rank()、dense_rank()三者的区别以及sum() over (partition by ... order by ...)这种累计求和写法在大数据岗位试卷里出现频率极高。我见过不少试卷用Hive的SQL直接出题如果你只背了MySQL的写法而没接触过HiveQL很容易在语法细节上卡壳比如Hive中不允许在WHERE子句里使用聚合函数别名这类问题。2.4 大数据生态Hadoop、Spark、Kafka各自怎么考到大数据部分了这部分是整张试卷的核心拉分区域。HDFS部分重点考察读写流程。读流程要能说出客户端先从NameNode获取元数据再直接与DataNode建立连接读取数据块写流程要能说出客户端先将数据分块然后通过Pipeline方式写入多个副本。有一个容易被追问的点为什么HDFS适合存储大文件而不适合大量小文件这个问题的核心在于元数据全部保存在NameNode内存中文件数量越多内存压力越大。MapReduce的shuffle是另一道必考题。map阶段输出数据后经过分区、排序、溢写、合并再通过网络传输到reduce端reduce端还要进行归并排序。你要能把这个流程完整讲出来并且指出哪些环节会产生磁盘IO。另外要理解MapReduce为什么慢每一步都可能落盘、网络传输串行化、无法利用内存和CPU的并行优势这为后面理解Spark的改进点做铺垫。Spark部分最重要的是RDD的依赖关系和DAG执行机制。宽依赖和窄依赖的区别必须掌握因为这是Spark划分Stage的依据。为什么宽依赖要划分Stage而窄依赖可以不划分因为宽依赖需要在分区之间进行数据交换shuffle必须等待父RDD计算完成才能开始子RDD的计算。另外Spark的懒执行机制、transform算子和action算子的区别、RDD的缓存级别也是笔试常客。一个经典问题Spark为什么比MapReduce快答案是DAG计算引擎减少了shuffle次数内存计算减少了落盘以及Task启动时复用JVM这些点都要踩到。Kafka的考察集中在消息可靠性。Producer端如何保证消息不丢失ack机制、Consumer端如何保证不重复消费enable.auto.commit设置、Broker端如何保证数据持久化副本机制和ISR这三层结构答出来就算完整。另外Consumer Group的概念要理解它决定了消息是“点对点模式”还是“发布订阅模式”以及分区数跟消费者实例数的对应关系。还有一个经常考的组件是ZooKeeper重点在于它在集群中的角色HDFS的HA选主、Kafka的Broker注册和Controller选举、分布式锁的实现。你不需要深入源码但要把“ZooKeeper是分布式协调服务”这句话背后的几个典型应用场景讲清楚。3. 典型试题实操与解题思路3.1 数据倾斜题按“现象、原因、方案”三步答才拿分数据倾斜是大数据岗位笔试和面试中出现频率最高的场景题没有之一。题型通常是这样出的“有一个Hive或Spark任务某个reduce或executor任务运行特别慢其他任务早就结束了请分析原因并提出解决方案。”答题时一定要按结构化方式组织不要想到哪说到哪。建议按三步走先描述现象各Task处理的数据量不均匀少数Task处理的数据量远超其他Task导致整体作业运行时间被拖长。再分析原因最典型的是key分布不均比如热点key、空值过多、join时关联字段大量重复还有可能是小文件过多、分区键选择不当导致数据本身分布就不均匀。最后给方案针对单个热点key可以使用随机前缀加盐把大key拆成多个小key对于join数据倾斜可以用map join把小表加载到内存里避免shuffle如果是空值导致的分组聚合问题可以把空值替换成随机字符串再分组还可以全局调整并行度比如Hive的hive.groupby.skewindata参数。这里有一个加分技巧答题时能说出“先把skew的key单独拆出来处理和其他key分开聚合最后进行union”这个思路会显得你有真实处理经验而不仅仅是背答案。另外方案要分场景描述比如是group by聚合还是join导致的倾斜处理思路完全不同不能一套答案走天下。如果你能在答案里带上一个真实案例比如“我在实习时处理过一个用户行为日志统计任务某个热门app的曝光量特别大导致数据倾斜后来用加盐加两阶段聚合解决了”整道题的含金量会立刻上升也更符合这类笔试筛选“有工程理解力候选者”的初衷。3.2 手写代码题TopK、链表反转这类题目的解题模板代码题在大数据试卷里通常不会出太难的数据结构题但非常喜欢出“有大数据背景”的题目比如手写TopK、实现单链表反转、合并两个有序链表、LRU缓存、字符串统计TopN单词等。这类题目考验的是代码基本功不追求最优解但代码必须能跑、逻辑必须清晰。最常考的是TopK问题。你可以用两种思路解答如果允许用内置优先队列PriorityQueue是首选维护一个大小为K的小顶堆每次遇到比堆顶大的数就替换复杂度是O(N log K)如果想展示更强的算法能力可以用基于快排的partition思想平均复杂度能做到O(N)但要注意写清楚边界条件。笔试环境下推荐用优先队列方案因为代码量小、容错率更高并且要记得说明“小顶堆用于求最大K个元素大顶堆用于求最小K个元素”。另一个高频题是合并两个有序链表。这道题有两种典型解法迭代和递归。迭代法更推荐笔试使用因为不会因为递归深度太深而爆栈创建一个dummy头节点然后用两个指针分别遍历两个链表谁小就接谁最后把剩余部分接上。代码量大概十行左右但要注意链表的边界条件比如其中一个链表为空的情况。手写代码时的另一个得分点是变量命名和注释。比如统计单词出现次数变量名用word和count而不是w和c会让阅卷人觉得你的代码风格规范。代码不要求能一次性编译通过但逻辑要自洽。如果某个边界条件你没把握先写注释说明“这里还需要考虑空输入的情况”也比完全不提强。3.3 场景设计题“几十亿条日志怎么处理”的完整答题框架场景设计题通常放在试卷最后是一个综合性大题典型问法有“假设公司每天产生几十亿条用户行为日志需要做实时统计和离线分析请设计一套大数据处理架构。”这种题目要有全局视角不能只堆名词。建议你按照数据流转的层次来回答问题采集层日志通过Flume或Logstash从业务服务器采集写入Kafka。Kafka在这里起到削峰填谷和缓冲的作用避免流量高峰期直接压垮下游系统。存储层原始日志可以落地到HDFS同时Kafka中的数据供实时任务消费。这里的核心设计是主题分区的划分策略比如按业务类型分topic、按用户维度决定分区key。离线计算层使用Hive或Spark SQL对HDFS中的全量数据进行ETL和统计产出离线报表。调度上可以用Azkaban或Airflow管理定时任务。实时计算层消费Kafka中的数据使用Spark Streaming或Flink做窗口统计、实时指标计算结果写入Redis或ES供业务查询。应用层数据和报表的对外输出接口考虑如何支撑高并发查询。在回答完整体架构后还要补上两个维度体现你的深度。第一是数据准确性实时和离线计算结果不一致怎么处理比较常见的方案是“以离线为准实时提供近似结果”或者设定误差阈值。第二是故障恢复某个组件挂了怎么保证数据不丢比如Kafka的副本机制、消费者的offset提交策略。任何一步如果能结合你实际跑过的任务来说明比如说明你用Flink做过窗口聚合时事件时间乱序的应对这道题的分值会大幅提升。4. 常见失误与避坑指南4.1 笔试中的时间管理陷阱这类试卷最常见的失误就是把时间花在少数难题上导致后面大量送分题来不及做。选择题和填空题分值虽小但架不住数量多后面的场景题再会写也顶不过前面丢了二十分。我自己的习惯是完全不会的先空着做一遍记号等最后有时间再来蒙但千万别空太多题因为很多公司的笔试采用倒扣分很少蒙了就可能得分。另外一个很容易被忽视的时间陷阱是代码题。很多同学在IDE里写代码习惯了一到笔试平台连类的名字、main方法的签名都要想半天。建议笔试前先去牛客网或者各公司自己的笔试平台熟悉一下代码题的输入输出处理方式尤其是要明确什么时候用Scanner逐行读什么时候需要一次性读取大量数据用BufferedReader。很多题目不是不会做而是卡在输入解析上耽误了二十分钟。SQL题也是这样如果平台不支持在编辑器里实际执行你在本地语法没问题就可以放心写。另外提醒一点如果试卷同时出现了“MySQL”和“HiveSQL”的题目注意区分语法差异不要写成一套。Hive里很多内置函数和MySQL不一样比如求日期差、字符串拼接的语法一旦混用很容易失分。4.2 简答题和场景题的语言组织技巧很多人失分不是不知道答案而是写出来的答案太散、缺少结构。阅卷人一天要看几百份卷子没有精力从你的长篇大论里找得分点。简答题一定要采用“先结论后展开”的结构。比如问“Kafka为什么能支撑高吞吐”先直接给出结论依赖于顺序写盘、页缓存、零拷贝和批量发送这四个机制然后每个机制用一两句话展开说明结构清晰得分点明确。场景题则要体现出系统的思考过程。不要一上来就写“用Flink解决问题”而是先拆解需求数据量是多少、实时性要求是秒级还是分钟级、允许的数据丢失率是多少、下游要支持多少并发查询。这些前缀信息相当于告诉阅卷人“我知道工程实现的权衡”之后再给出方案就会显得很踏实。另外要注意专业术语的准确性。zookeeper不要拼错HDFS是Hadoop Distributed File System的缩写shuffle和sort不要混用。这里的细节问题虽然不影响整道题的理解但在“第一印象”上会打折扣尤其对校招的同学来说术语的准确使用是基本功的直接体现。4.3 大数据方向特有的“概念背诵误区”大数据方向的笔试有一个非常典型的误区背了一堆概念的名字但说不清概念解决的是什么问题。最典型的例子就是Spark的窄依赖和宽依赖。很多同学能背出“窄依赖是父RDD的分区最多被一个子RDD分区使用宽依赖是被多个子RDD分区使用”但被问到“为什么划分Stage要看宽依赖”时就会卡壳。对这个问题的理解应该落到数据传输上窄依赖不需要跨节点传输数据所以可以放在同一个Stage里并行计算宽依赖必须进行shuffle需要等待上游全部计算完成才能开始下游Stage所以是Stage的划分边界。如果没有这层理解单纯背定义在笔试里只能拿一半分。另一个常见误区是背结论不理解原理。比如“Spark比MapReduce快”这句几乎人人会说的话但问到具体原因时很多人只能答出“因为用内存计算”。更完整的答案至少包括三点DAG引擎能减少不必要的shuffle和落盘、内存计算避免反复读写磁盘、任务执行时复用JVM减少启动开销。这种“结论原因分解”式的组织方式才是大数据笔试最看重的答题能力。5. 笔试之外从校招笔试题反推面试准备重点5.1 简历项目经验怎么对应笔试考点笔试考的内容往往就是面试要深挖的内容所以准备笔试的过程其实也是在为面试铺路。你的简历项目描述如果能跟笔试题形成呼应面试时会被面试官另眼相看。一个完整的项目描述建议包含四步项目背景处理了多少数据量、用到的技术栈Hadoop、Spark、Flink、Kafka等、你具体承担的部分、以及遇到过最棘手的问题和解决方式。比如项目里用了Spark SQL做ETL就顺手准备好一个“数据倾斜怎么解决”的真实案例项目里用了Kafka和Flink做实时计算就整理一下“消费延迟和数据不丢怎么保证”的复盘。题库是固定的但你简历上的项目可以提前对上话术面试时被问到你亲历过的技术细节讲出来跟背模板是完全不同的效果。5.2 面试环节通常怎样延伸笔试内容校招面试官手里都会拿着你的笔试卷子几乎一定会从卷子里挑几道题深挖。你笔试时写的代码面试官可能让你现场重新讲一遍思路会追问“这个方法的时间复杂度是多少”“如果数据量变成一百倍你的方案还成立吗”。所以笔试结束后不要把题目丢掉尽量把写的答案归档整理一下尤其是场景设计题和代码题面试前回头看看非常有价值。还有一个比较隐蔽的面试习惯面试官问技术问题时如果你回答得过于流畅很有可能会被增加难度。如果是大数据的岗位最常见的是从Hive问数据倾斜再引申到Spark的shuffle机制再问到Flink的checkpoint实现逐层深挖。平时复习时最好就按这种链条把知识串起来比如准备数据倾斜时同时想清楚Hive、Spark、Flink三套引擎各自的处理差异这种体系化的准备方式比零散地背知识点要高效得多。说实话我在校招时准备这类笔试最深的感受是刷题和背概念能保证你不低分但真正让你拿到高分的是对技术原理和工程场景之间关系的理解。笔试只是第一道门槛它考的不是你能不能背出标准答案而是你有没有把后端和大数据这条技术线真正想明白。这套备考思路放到今天也依然适用数据结构与算法、操作系统、网络、数据库、分布式系统这些基本功永远不会过时反而是那些被炒作的技术名词过两年可能就没人提了。所以复习时别老追新把基础打牢把主干技术栈吃透比什么都有用。
“触宝科技2017秋季校招笔试后端大数据第二批”这个标题放在今天看可能有些年头了但经历过那几年校招的人再回头看会发现这类试卷的命题逻辑其实非常稳定。它基本代表了一批产品型移动互联网公司在招后端大数据方向应届生时的主流考察标准Java基础和并发、网络与数据库这些后端基本功要扎实Hadoop生态、Spark、Kafka这些大数据组件要真正理解同时还不能是个只会背概念的选手。这篇文章就把这类笔试从考察思路、核心考点、典型题目到避坑经验完整拆一遍正在准备后端或大数据方向校招的同学可以参考工作后想系统复盘自己技术体系的人也能从这套试卷结构里看出一些门道。我没办法给你还原当年的每道原题但这类校招笔试题的题型和考点高度稳定本质上是在用一套固定的框架筛选“来了就能干活”的人。下面所有内容都是基于这类试卷的考察逻辑做的梳理和还原结合的是行业里通用的笔试复盘经验你可以把它当成一套完整的备考地图来用。1. 笔试整体考察思路拆解1.1 移动互联网公司校招笔试到底想筛什么样的人先说一个很多人容易搞错的点企业笔试不是ACM竞赛目的不是为难你而是快速筛掉“基础不牢”的候选人。就拿触宝这种产品型公司来说后端大数据岗位的日常工作很具体维护数据采集链路、跑离线任务、优化实时计算作业、响应业务方的取数需求。笔试要考察的就是你能不能胜任这些具体工作。所以你会发现试卷里的题目难度普遍维持在“基础扎实就能答”的水平不会出现偏题怪题。HashMap的底层原理、TCP三次握手、SQL的join查询、MapReduce的shuffle流程这些题单独拿出来都不难难的是在90到120分钟内把一整卷题都答得又快又稳。这也解释了为什么很多“刷题刷得很深”但知识面偏窄的同学反而容易在笔试阶段翻车——这类试卷考察的是广度优先的工程基础而不是某个方向的深度花活。1.2 试卷结构与时间分配的底层逻辑这类笔试试卷通常由四到五个部分组成基础选择题或填空题、手写代码题、SQL查询题、简答题、场景设计题。按经验来看前面的基础题往往占30%到40%的分值代码题和SQL题是拉分的关键场景设计题则决定了你能不能进终面。基础题考察的是你在短时间内能调取多少“肌肉记忆”比如Java集合类的线程安全性、TCP的TIME_WAIT状态、索引失效的场景。这类题不能犹豫每道题控制在1到2分钟拿不准就果断标记跳过。代码题一般有两道左右其中一道是数据结构算法题另一道往往和大数据场景结合比如手写一个简化版的WordCount、求TopN或者模拟分组统计。SQL题通常是三到四道从简单查询逐步过渡到多表join和窗口函数。场景设计题放在最后分值最高重点考察你对数据链路整体架构的理解。我建议的时间分配是基础题30到40分钟代码题30分钟SQL题20到25分钟场景题15到20分钟留5到10分钟回头补做跳过的题目。这里有个很实用的小技巧拿到试卷先不要急着做花3到5分钟快速浏览全部题目心里对整张卷子的难度分布立刻有数哪些题目是送分题、哪些题目是大题先排好优先级。这一步看起来不起眼但特别能避免“前面磨蹭太久最后大题没时间写”的悲剧。1.3 为什么后端基本功和大数据生态会放在同一张卷子里很多同学会把“后端开发”和“大数据开发”看成两个完全不同的方向但在实际岗位里这两者的边界非常模糊。大数据平台本身就是一个分布式后端系统HDFS要处理海量文件的读写NameNode的元数据管理本质是分布式状态管理Kafka要保证消息的高吞吐和可靠投递背后是网络通信、存储、一致性这些后端基础问题Spark的Executor要管理内存和线程池更是直接建立在JVM和并发基础之上。所以你会发现这套试卷在命题时有一条暗线后端基本功是底层能力大数据组件是应用场景。问你Java内存模型后面可能就跟着问Spark的内存管理问你事务的隔离级别后面可能就跟着问Hive的ACID特性。答题的时候如果你能把两者串起来讲比如解释为什么Spark比MapReduce快时顺带提到JVM复用和堆外内存面试官对你的评价会明显不一样。这也是很多高分试卷的共同特点不是每个知识点都答得天花乱坠而是能把跨知识点的关联说清楚。2. 核心考点与题型详解2.1 Java与并发笔试里永远绕不开的主战场先说Java部分这是绝大多数后端大数据岗位笔试的第一道关卡。集合类是肯定要考的HashMap的底层数据结构、put操作的流程、扩容机制、为什么线程不安全这些都是高频中的高频。当年这类题目有一个很经典的问法HashMap在多线程环境下会出现什么问题如果你能说出并发put可能导致数据覆盖、JDK7及以前版本扩容时可能形成环形链表导致死循环基本就能拿全分。进阶一点还会考ConcurrentHashMap的实现演进从分段锁到CAS加synchronized这个变化一定要了解因为后面你会经常在并发编程里遇到类似的无锁优化思路。JVM部分重点看内存区域划分、对象创建过程、垃圾收集算法和三色标记。笔试阶段通常不会考太深但你要能说清楚新生代和老年代的区别、哪些对象会进入老年代、CMS和G1各自的特点。这里有一个被反复考察的细节什么情况下会发生Full GCFull GC对大数据任务意味着什么。这个问题之所以受欢迎是因为它实际上在考察你对实时计算任务延迟的理解——Spark或Flink的Executor如果频繁Full GC整个作业的吞吐量都会遭受重创。并发编程是笔试分差最大的模块。synchronized和ReentrantLock的区别、volatile的可见性和禁止重排序原理、线程池的核心参数和四种拒绝策略这些属于必背内容。我建议你把AQSAbstractQueuedSynchronizer的原理好好看一遍虽然笔试不一定会直接考但它能把Lock、Semaphore、CountDownLatch这些知识点串成一条线。另外线程池的提交流程也是高频题核心线程数已满、阻塞队列已满、最大线程数已满分别对应什么行为必须张口就来。2.2 计算机网络与操作系统基础不能再基础网络部分的考察集中在TCP和HTTP。三次握手和四次挥手的过程、为什么需要TIME_WAIT、SYN Flood攻击的原理这三件事必须烂熟于心。笔试时容易丢分的地方在于细节比如TIME_WAIT为什么主动关闭方需要等待2MSL如果你只说“为了保证对方收到ACK”就不够全面还要补充“为了让旧连接的报文在网络中消失避免影响新连接”这两点合起来才算完整答案。HTTP与HTTPS的区别也是常客。除了熟知的端口差异和加密方式你要能说清楚HTTPS建立连接时SSL/TLS握手的过程重点讲清楚对称加密和非对称加密各自用在哪个环节。另外HTTP常见的状态码比如301和302的区别、401和403的区别、502和504的区别这类题属于纯记忆题考前速记一遍就能拿分丢了很可惜。操作系统部分进程和线程的区别属于送分题但死锁的四个必要条件和预防措施就是分水岭了。你要是能举出实际工程中的死锁案例比单纯背概念要得分高得多。比如两个Spark任务互相持有锁并等待对方释放就可以类比成死锁的循环等待条件。另一个高频考点是IO多路复用select、poll、epoll的区别这个知识点对理解高并发网络框架很有帮助笔试和面试都常被追问。2.3 数据库与MySQL优化后端开发的基本盘数据库考察的核心只有一个索引。B树为什么适合做索引、聚簇索引和非聚簇索引的区别、回表是什么、覆盖索引是什么、最左前缀原则是什么这些是必须形成条件反射的内容。笔试里我见过一道很经典的题给定一个联合索引(a, b, c)然后问哪些查询能用上索引、哪些不能。这种题不难但如果你没真正理解最左前缀原则很容易在边缘条件上栽跟头。事务部分要重点看ACID和隔离级别。MySQL默认的隔离级别是RR可重复读这一点也常考。你不需要背下MVCC的所有实现细节但至少要理解MVCC通过版本链和ReadView实现了快照读因此InnoDB在RR级别下能部分解决幻读问题。另外间隙锁Gap Lock的概念要了解它本质上是在索引记录之间加锁防止其他事务插入数据这也是RR级别下解决幻读的关键手段。SQL题是笔试中性价比极高的题目。join的几种类型、group by和having的配合、子查询和临时表的使用这些都是基本功真正拉分的是窗口函数。row_number()、rank()、dense_rank()三者的区别以及sum() over (partition by ... order by ...)这种累计求和写法在大数据岗位试卷里出现频率极高。我见过不少试卷用Hive的SQL直接出题如果你只背了MySQL的写法而没接触过HiveQL很容易在语法细节上卡壳比如Hive中不允许在WHERE子句里使用聚合函数别名这类问题。2.4 大数据生态Hadoop、Spark、Kafka各自怎么考到大数据部分了这部分是整张试卷的核心拉分区域。HDFS部分重点考察读写流程。读流程要能说出客户端先从NameNode获取元数据再直接与DataNode建立连接读取数据块写流程要能说出客户端先将数据分块然后通过Pipeline方式写入多个副本。有一个容易被追问的点为什么HDFS适合存储大文件而不适合大量小文件这个问题的核心在于元数据全部保存在NameNode内存中文件数量越多内存压力越大。MapReduce的shuffle是另一道必考题。map阶段输出数据后经过分区、排序、溢写、合并再通过网络传输到reduce端reduce端还要进行归并排序。你要能把这个流程完整讲出来并且指出哪些环节会产生磁盘IO。另外要理解MapReduce为什么慢每一步都可能落盘、网络传输串行化、无法利用内存和CPU的并行优势这为后面理解Spark的改进点做铺垫。Spark部分最重要的是RDD的依赖关系和DAG执行机制。宽依赖和窄依赖的区别必须掌握因为这是Spark划分Stage的依据。为什么宽依赖要划分Stage而窄依赖可以不划分因为宽依赖需要在分区之间进行数据交换shuffle必须等待父RDD计算完成才能开始子RDD的计算。另外Spark的懒执行机制、transform算子和action算子的区别、RDD的缓存级别也是笔试常客。一个经典问题Spark为什么比MapReduce快答案是DAG计算引擎减少了shuffle次数内存计算减少了落盘以及Task启动时复用JVM这些点都要踩到。Kafka的考察集中在消息可靠性。Producer端如何保证消息不丢失ack机制、Consumer端如何保证不重复消费enable.auto.commit设置、Broker端如何保证数据持久化副本机制和ISR这三层结构答出来就算完整。另外Consumer Group的概念要理解它决定了消息是“点对点模式”还是“发布订阅模式”以及分区数跟消费者实例数的对应关系。还有一个经常考的组件是ZooKeeper重点在于它在集群中的角色HDFS的HA选主、Kafka的Broker注册和Controller选举、分布式锁的实现。你不需要深入源码但要把“ZooKeeper是分布式协调服务”这句话背后的几个典型应用场景讲清楚。3. 典型试题实操与解题思路3.1 数据倾斜题按“现象、原因、方案”三步答才拿分数据倾斜是大数据岗位笔试和面试中出现频率最高的场景题没有之一。题型通常是这样出的“有一个Hive或Spark任务某个reduce或executor任务运行特别慢其他任务早就结束了请分析原因并提出解决方案。”答题时一定要按结构化方式组织不要想到哪说到哪。建议按三步走先描述现象各Task处理的数据量不均匀少数Task处理的数据量远超其他Task导致整体作业运行时间被拖长。再分析原因最典型的是key分布不均比如热点key、空值过多、join时关联字段大量重复还有可能是小文件过多、分区键选择不当导致数据本身分布就不均匀。最后给方案针对单个热点key可以使用随机前缀加盐把大key拆成多个小key对于join数据倾斜可以用map join把小表加载到内存里避免shuffle如果是空值导致的分组聚合问题可以把空值替换成随机字符串再分组还可以全局调整并行度比如Hive的hive.groupby.skewindata参数。这里有一个加分技巧答题时能说出“先把skew的key单独拆出来处理和其他key分开聚合最后进行union”这个思路会显得你有真实处理经验而不仅仅是背答案。另外方案要分场景描述比如是group by聚合还是join导致的倾斜处理思路完全不同不能一套答案走天下。如果你能在答案里带上一个真实案例比如“我在实习时处理过一个用户行为日志统计任务某个热门app的曝光量特别大导致数据倾斜后来用加盐加两阶段聚合解决了”整道题的含金量会立刻上升也更符合这类笔试筛选“有工程理解力候选者”的初衷。3.2 手写代码题TopK、链表反转这类题目的解题模板代码题在大数据试卷里通常不会出太难的数据结构题但非常喜欢出“有大数据背景”的题目比如手写TopK、实现单链表反转、合并两个有序链表、LRU缓存、字符串统计TopN单词等。这类题目考验的是代码基本功不追求最优解但代码必须能跑、逻辑必须清晰。最常考的是TopK问题。你可以用两种思路解答如果允许用内置优先队列PriorityQueue是首选维护一个大小为K的小顶堆每次遇到比堆顶大的数就替换复杂度是O(N log K)如果想展示更强的算法能力可以用基于快排的partition思想平均复杂度能做到O(N)但要注意写清楚边界条件。笔试环境下推荐用优先队列方案因为代码量小、容错率更高并且要记得说明“小顶堆用于求最大K个元素大顶堆用于求最小K个元素”。另一个高频题是合并两个有序链表。这道题有两种典型解法迭代和递归。迭代法更推荐笔试使用因为不会因为递归深度太深而爆栈创建一个dummy头节点然后用两个指针分别遍历两个链表谁小就接谁最后把剩余部分接上。代码量大概十行左右但要注意链表的边界条件比如其中一个链表为空的情况。手写代码时的另一个得分点是变量命名和注释。比如统计单词出现次数变量名用word和count而不是w和c会让阅卷人觉得你的代码风格规范。代码不要求能一次性编译通过但逻辑要自洽。如果某个边界条件你没把握先写注释说明“这里还需要考虑空输入的情况”也比完全不提强。3.3 场景设计题“几十亿条日志怎么处理”的完整答题框架场景设计题通常放在试卷最后是一个综合性大题典型问法有“假设公司每天产生几十亿条用户行为日志需要做实时统计和离线分析请设计一套大数据处理架构。”这种题目要有全局视角不能只堆名词。建议你按照数据流转的层次来回答问题采集层日志通过Flume或Logstash从业务服务器采集写入Kafka。Kafka在这里起到削峰填谷和缓冲的作用避免流量高峰期直接压垮下游系统。存储层原始日志可以落地到HDFS同时Kafka中的数据供实时任务消费。这里的核心设计是主题分区的划分策略比如按业务类型分topic、按用户维度决定分区key。离线计算层使用Hive或Spark SQL对HDFS中的全量数据进行ETL和统计产出离线报表。调度上可以用Azkaban或Airflow管理定时任务。实时计算层消费Kafka中的数据使用Spark Streaming或Flink做窗口统计、实时指标计算结果写入Redis或ES供业务查询。应用层数据和报表的对外输出接口考虑如何支撑高并发查询。在回答完整体架构后还要补上两个维度体现你的深度。第一是数据准确性实时和离线计算结果不一致怎么处理比较常见的方案是“以离线为准实时提供近似结果”或者设定误差阈值。第二是故障恢复某个组件挂了怎么保证数据不丢比如Kafka的副本机制、消费者的offset提交策略。任何一步如果能结合你实际跑过的任务来说明比如说明你用Flink做过窗口聚合时事件时间乱序的应对这道题的分值会大幅提升。4. 常见失误与避坑指南4.1 笔试中的时间管理陷阱这类试卷最常见的失误就是把时间花在少数难题上导致后面大量送分题来不及做。选择题和填空题分值虽小但架不住数量多后面的场景题再会写也顶不过前面丢了二十分。我自己的习惯是完全不会的先空着做一遍记号等最后有时间再来蒙但千万别空太多题因为很多公司的笔试采用倒扣分很少蒙了就可能得分。另外一个很容易被忽视的时间陷阱是代码题。很多同学在IDE里写代码习惯了一到笔试平台连类的名字、main方法的签名都要想半天。建议笔试前先去牛客网或者各公司自己的笔试平台熟悉一下代码题的输入输出处理方式尤其是要明确什么时候用Scanner逐行读什么时候需要一次性读取大量数据用BufferedReader。很多题目不是不会做而是卡在输入解析上耽误了二十分钟。SQL题也是这样如果平台不支持在编辑器里实际执行你在本地语法没问题就可以放心写。另外提醒一点如果试卷同时出现了“MySQL”和“HiveSQL”的题目注意区分语法差异不要写成一套。Hive里很多内置函数和MySQL不一样比如求日期差、字符串拼接的语法一旦混用很容易失分。4.2 简答题和场景题的语言组织技巧很多人失分不是不知道答案而是写出来的答案太散、缺少结构。阅卷人一天要看几百份卷子没有精力从你的长篇大论里找得分点。简答题一定要采用“先结论后展开”的结构。比如问“Kafka为什么能支撑高吞吐”先直接给出结论依赖于顺序写盘、页缓存、零拷贝和批量发送这四个机制然后每个机制用一两句话展开说明结构清晰得分点明确。场景题则要体现出系统的思考过程。不要一上来就写“用Flink解决问题”而是先拆解需求数据量是多少、实时性要求是秒级还是分钟级、允许的数据丢失率是多少、下游要支持多少并发查询。这些前缀信息相当于告诉阅卷人“我知道工程实现的权衡”之后再给出方案就会显得很踏实。另外要注意专业术语的准确性。zookeeper不要拼错HDFS是Hadoop Distributed File System的缩写shuffle和sort不要混用。这里的细节问题虽然不影响整道题的理解但在“第一印象”上会打折扣尤其对校招的同学来说术语的准确使用是基本功的直接体现。4.3 大数据方向特有的“概念背诵误区”大数据方向的笔试有一个非常典型的误区背了一堆概念的名字但说不清概念解决的是什么问题。最典型的例子就是Spark的窄依赖和宽依赖。很多同学能背出“窄依赖是父RDD的分区最多被一个子RDD分区使用宽依赖是被多个子RDD分区使用”但被问到“为什么划分Stage要看宽依赖”时就会卡壳。对这个问题的理解应该落到数据传输上窄依赖不需要跨节点传输数据所以可以放在同一个Stage里并行计算宽依赖必须进行shuffle需要等待上游全部计算完成才能开始下游Stage所以是Stage的划分边界。如果没有这层理解单纯背定义在笔试里只能拿一半分。另一个常见误区是背结论不理解原理。比如“Spark比MapReduce快”这句几乎人人会说的话但问到具体原因时很多人只能答出“因为用内存计算”。更完整的答案至少包括三点DAG引擎能减少不必要的shuffle和落盘、内存计算避免反复读写磁盘、任务执行时复用JVM减少启动开销。这种“结论原因分解”式的组织方式才是大数据笔试最看重的答题能力。5. 笔试之外从校招笔试题反推面试准备重点5.1 简历项目经验怎么对应笔试考点笔试考的内容往往就是面试要深挖的内容所以准备笔试的过程其实也是在为面试铺路。你的简历项目描述如果能跟笔试题形成呼应面试时会被面试官另眼相看。一个完整的项目描述建议包含四步项目背景处理了多少数据量、用到的技术栈Hadoop、Spark、Flink、Kafka等、你具体承担的部分、以及遇到过最棘手的问题和解决方式。比如项目里用了Spark SQL做ETL就顺手准备好一个“数据倾斜怎么解决”的真实案例项目里用了Kafka和Flink做实时计算就整理一下“消费延迟和数据不丢怎么保证”的复盘。题库是固定的但你简历上的项目可以提前对上话术面试时被问到你亲历过的技术细节讲出来跟背模板是完全不同的效果。5.2 面试环节通常怎样延伸笔试内容校招面试官手里都会拿着你的笔试卷子几乎一定会从卷子里挑几道题深挖。你笔试时写的代码面试官可能让你现场重新讲一遍思路会追问“这个方法的时间复杂度是多少”“如果数据量变成一百倍你的方案还成立吗”。所以笔试结束后不要把题目丢掉尽量把写的答案归档整理一下尤其是场景设计题和代码题面试前回头看看非常有价值。还有一个比较隐蔽的面试习惯面试官问技术问题时如果你回答得过于流畅很有可能会被增加难度。如果是大数据的岗位最常见的是从Hive问数据倾斜再引申到Spark的shuffle机制再问到Flink的checkpoint实现逐层深挖。平时复习时最好就按这种链条把知识串起来比如准备数据倾斜时同时想清楚Hive、Spark、Flink三套引擎各自的处理差异这种体系化的准备方式比零散地背知识点要高效得多。说实话我在校招时准备这类笔试最深的感受是刷题和背概念能保证你不低分但真正让你拿到高分的是对技术原理和工程场景之间关系的理解。笔试只是第一道门槛它考的不是你能不能背出标准答案而是你有没有把后端和大数据这条技术线真正想明白。这套备考思路放到今天也依然适用数据结构与算法、操作系统、网络、数据库、分布式系统这些基本功永远不会过时反而是那些被炒作的技术名词过两年可能就没人提了。所以复习时别老追新把基础打牢把主干技术栈吃透比什么都有用。
