2019年那场笔试我做完了还整理过考点去年帮学弟复盘的时候顺手又把这套题重新过了一遍。顺丰科技这套秋招大数据平台开发客观题考察范围很典型基本就是当时一线大厂大数据岗的风向标——Java基础、JVM、并发、Hadoop生态、Spark/Flink、数据库、数据仓库、Linux、算法和网络一个都不少。但这套题真正的价值不在于你背下哪道题的答案而在于它揭示了一个大数据平台开发工程师到底需要掌握什么知识体系。我把这套题合集的考点和题目背后的考察逻辑拆开来讲结合我自己的备考和面试经验给准备校招或者想转行做大数据平台开发的朋友一份能直接用的复习地图。1. 顺丰科技这套题背后的大数据平台岗真实画像先说一个很多人容易忽略的点大数据平台开发工程师和数据分析师、算法工程师、数据仓库工程师考的东西完全不是一回事。顺丰这套客观题考的是“平台开发”方向你要做的是搭平台、写框架、调优引擎、处理数据链路不是跑SQL做报表也不是调参训练模型。这决定了笔试题的底层逻辑——你必须真正理解大数据组件的原理而不是只会API调用。面试官出一套客观题不是想知道你背过多少面试题而是想通过选择题、判断题这种客观形式快速筛掉那些简历写得漂亮、底层一问就倒的候选人。为什么这么说因为大数据平台开发这个岗位日常工作中大概率要面对这些场景你要基于Hadoop/YARN维护一个日均处理PB级数据的集群节点挂了怎么恢复、任务卡了怎么诊断你要开发Spark或者Flink任务处理实时数仓的链路需要对Spark的Shuffle机制、Flink的Checkpoint原理有深入理解你要写Java代码开发平台的功能模块那JVM调优、并发编程就不仅仅是面试题而是线上问题排查的基本功顺丰科技作为物流行业里技术投入很大的公司有一套题的考察方向明显偏实战。同样是考Hadoop它不太会问你“HDFS的默认副本数是多少”这种纯背题考点而是更倾向考察你对原理的理解深度。我在准备面试的时候一个很深的体会是客观题往往比主观题更考验知识的扎实程度。主观题你不会写还能编几句客观题不会就只能蒙。而顺丰这套题的覆盖面把大数据平台开发需要掌握的知识版图画得明明白白。2. Java和JVM部分平台开发绕不开的第一关顺丰这套题里Java相关的内容占比很大。这不奇怪——虽然现在很多大数据组件用Scala、Python也能写但主流的大数据框架底层都是Java技术栈。Hadoop、HBase、Kafka的源码是JavaSpark的底层执行引擎是JVM你写UDF、写平台服务本质上都是在和JVM打交道。2.1 集合框架HashMap和ConcurrentHashMap的底层逻辑这属于Java基础里的高频考点。顺丰的题里直接考察HashMap底层实现细节的概率很高比如HashMap在JDK 1.7和1.8之间有什么变化为什么引入红黑树为什么HashMap是线程不安全的扩容时会出现什么问题ConcurrentHashMap在JDK 1.7和1.8之间锁的粒度有怎样变化同样学习这部分内容很多人会直接背面试题答案但我的建议是真正去看一下源码至少把关键方法的实现逻辑看完。因为笔试有多个选项的干扰如果你只知道结论而不知道原理细节看到相近的选项很容易犹豫。JDK 1.8中HashMap引入了红黑树结构当链表长度超过8且数组长度超过64时链表才会转成红黑树。这两个条件缺一不可。但笔试肯定不会只考这个点它可能问的是“为什么不是所有链表都能转红黑树”——因为当数组长度比较短的时候扩容比树化更划算。类似的还有ConcurrentHashMapJDK 1.8中抛弃了Segment分段锁改用CAS synchronized加锁的方式锁粒度从段级别细化到单个桶。这个变化的根本原因在于分段锁在极端情况下仍然存在竞争瓶颈而用CAS加锁的方式在绝大多数情况下是无锁的。理解了为什么你遇到类似问题才能举一反三。2.2 JVM内存模型和垃圾回收大厂必考JVM相关的题目在这套题中也必不可少。因为大数据任务跑在JVM上JVM参数设置不当、内存分配不合理、频繁Full GC都会直接影响任务运行效率。顺丰的题可能会涉及JVM运行时数据区域堆、栈、方法区、程序计数器的职责划分垃圾回收算法标记-清除、标记-复制、标记-整理的原理和适用场景垃圾收集器CMS和G1的区别为什么G1适合大堆内存场景这一部分我建议用“内存分区是个什么结构”到“谁在什么时候触发回收”到“不同的收集器又是什么策略”这条线来复习。JVM的堆内存又分为新生代和老年代新生代采用复制算法因为大部分对象朝生夕死复制成本低老年代采用标记-整理或标记-清除因为对象存活率高复制不划算。这个逻辑链串起来之后你就不会再去死记硬背哪个区域用哪个算法了。我记得当时复习JVM的时候一个很大的心得是把调优参数和线上问题对应起来。比如你的Spark Executor频繁Full GC从JVM角度看可能是堆内存设置不合理或者对象分配过多导致老年代快速占满。同样是Executor OOM可能是堆内内存不足也可能是堆外内存不足这就要分清楚Spark的内存管理是统一在堆内的。笔试题不会给你这么长的上下文但它的知识点一定是从这些衍生出来的。2.3 并发编程锁、线程池和并发工具类并发这一块对于大数据平台开发来说更重要的是理解并发工具类在大数据框架源码中的应用。像ThreadPoolExecutor的核心参数corePoolSize、maximumPoolSize、workQueue、拒绝策略笔试几乎必考。为什么因为大数据框架本身需要管理大量线程比如Kafka的发送和拉取、Flink的Task线程调度都依赖线程池。一个高频考的细节是线程池的corePoolSize与maximumPoolSize的关系。当提交任务数大于corePoolSize且队列已满时才会创建新线程直到maximumPoolSize如果仍然不够就触发拒绝策略。很多人记忆混乱以为队列满了就直接触发拒绝策略忽略了还有扩展线程这一步。客观题往往会设计这类“看起来差不多但差一个条件”的选项。另外synchronized和ReentrantLock的区别也是高频题。需要记住synchronized是非公平锁ReentrantLock可以选公平还是非公平ReentrantLock支持多个条件变量可以精确地唤醒某个等待线程而synchronized做不到这一点。从大数据框架的角度看比如Flink的异步IO中为了控制并发度就用到信号量Semaphore这类并发工具在框架源码中无处不在。建议复习的时候多问自己一个问题这个工具在哪个框架里有用到这么一问知识点就和实战挂上钩了。3. Hadoop生态组件题从原理到实战应用场景顺丰这套题的大数据核心部分Hadoop生态是绝对的主战场。HDFS、MapReduce、YARN、HBase这些组件的原理题能直接反映你对大数据底层机制的理解。根据近几年的笔试题风格我整理了几个高频考察方向。3.1 HDFS读写流程和副本策略HDFS相关的题目主要考察读写流程和副本放置策略。这里很多人容易犯一个错误就是只知道“写数据流程是Client→NameNode→DataNode”但具体每一步在做什么并不清楚。完整流程拆开来看是这样一个链条Client向NameNode发起写请求NameNode检查权限和目标路径Client分成多个Block向NameNode申请Block位置NameNode返回可用的DataNode列表Client将Block写入第一个DataNode第一个DataNode再复制给第二个以此类推副本放置策略也是一个常考点第一个副本放在客户端所在节点如果客户机在集群中第二个副本放在与第一个副本不同机架的节点第三个副本放在与第二个副本相同机架的另一个节点。这样既保证数据可靠性又能兼顾容错和网络开销。考题可能会问为什么这样放置——第一副本就近写入减少网络传输第二副本跨机架防止整个机架故障第三副本同一机架是为了在保证机架级容错的同时减少跨机架写流量。HDFS读流程相对简单但也常考“Client和DataNode之间直接传输数据NameNode只负责元数据”这一核心特性。理解了这一点你就知道为什么HDFS能支持高吞吐并发读——NameNode不参与实际数据传输不会成为瓶颈。3.2 MapReduceShuffle的每个环节都要清楚MapReduce在整个Hadoop生态中的重要性虽然被Spark和Flink逐步取代但作为大数据处理的基石笔试题几乎必考。其中Shuffle过程是重中之重。MapReduce的Shuffle可以分为Map端和Reduce端。Map端包括环形缓冲区写入、溢写、分区、排序、合并Reduce端包括拉取、合并、归并排序。考试题很喜欢考这些细节比如环形缓冲区的默认大小是100MB当缓冲区使用率达到80%时会触发溢写分区数等于Reduce任务数分区规则默认是HashPartitioner溢写过程中会进行排序排序的依据是Key的字典序我到后来才真正想明白为什么会有“80%溢写阈值”这个设计。因为不能等缓冲区满了才溢写那样写入线程和溢写线程没有办法并行设置了一个阈值缓冲区剩下一部分空间继续接收数据同时溢写线程开始工作这样读写才能并行。客观题考这种阈值的时候往往就是考察你对这个并行设计逻辑的理解。3.3 YARN的资源调度容量调度器和公平调度器的区别YARN这一块重点考察资源调度器之间的区别。Capacity Scheduler和Fair Scheduler在顺丰这类公司的生产环境中都有人用笔试也常考它们的异同。Capacity Scheduler的特点是多个队列之间是相互隔离的每个队列有固定的资源比例队列内部是FIFO或优先级调度。好处是资源分配可控但缺点是即使一个队列的资源空闲也不能分给另一个资源紧张的队列因为配额固定。Fair Scheduler的特点是所有任务动态共享集群资源当只有一个任务运行时它可以独占整个集群的资源当多个任务提交时资源会按照某种公平策略重新分配。这样利用率更高但任务之间的相互影响也更大。这个知识点建议结合生产场景来复习。比如顺丰的业务特点是波峰波谷明显——平时订单量平稳大促或突发高峰期数据量暴涨。这种场景下哪个调度器更合适其实两种都有实际使用案例关键是看你对资源利用率和任务隔离性的取舍。笔试题不会问你“选哪个更好”更可能是问你“在不同场景下两个调度器分别有什么表现”。3.4 HBaseLSM树和读写路径HBase作为大数据领域常用的列式NoSQL也是大数据平台开发岗的常客。顺丰的物流轨迹数据、订单状态变化理论上都适合存储在HBase这类系统中因为写入量大、查询按RowKey维度。所以HBase的考点里LSM树存储结构是核心。LSM树的核心思路是写入时只追加到内存中的MemStore当MemStore达到一定大小后Flush成HFile落盘读取时先查MemStore再查布隆过滤器最后查HFile。这套机制保证了写入的高性能但读取需要查多个地方。笔试里高频的考点包括HBase根据RowKey快速定位数据RowKey的设计直接影响读写性能MemStore的Flush触发条件大小阈值、时间阈值、WAL数量等HFile是存储在HDFS上的底层依赖HDFS的容错这里给个加分建议复习的时候可以顺便思考一下“为什么HBase的写性能远高于读性能”。答案就是LSM树的设计——写入是顺序追加不需要随机读写而读取需要查内存布隆过滤器可能多次磁盘IO。理解了这些考题怎么变换你都能应对。4. Spark和Flink两种引擎对比是近年命题趋势到了近几年Spark和Flink的题目在大数据平台的笔试题中占比越来越高。顺丰这套题里Spark相关的考察比较多Flink也一定有涉及。尤其值得关注的是“Spark和Flink的对比类题目”这种题最能区分候选人是真正理解还是背了知识点。4.1 Spark的RDD血缘、Stage划分和ShuffleSpark的核心考点主要是RDD的血缘关系、Transformation和Action的区别、Stage的划分、Shuffle机制。先说RDD血缘。RDD之间的依赖关系分为窄依赖和宽依赖。窄依赖指的是父RDD的一个分区最多被子RDD的一个分区使用比如map、filter宽依赖指的是父RDD的一个分区被子RDD的多个分区使用比如groupByKey、reduceByKey。为什么这个考点重要因为Stage划分的依据就是依赖关系——从后往前推遇到宽依赖就断开生成一个新的Stage。宽依赖意味着Shuffle而Shuffle是最耗性能的操作大数据调优的核心就是减少不必要的Shuffle。顺丰这类企业的笔试往往会让你判断某个操作是窄依赖还是宽依赖然后考察对应的Stage划分。第二个高频考点是Spark的算子。reduceByKey和groupByKey的区别几乎是必考题——reduceByKey先在Map端做局部聚合传输数据量大幅减少groupByKey则不会做Map端聚合所有数据都要Shuffle到下游。这个区别在生产中是一个巨大的性能差异。数据量大时用reduceByKey可能几分钟就跑完用groupByKey可能直接OOM。第三个常考的是cache和checkpoint的区别。cache把RDD缓存在内存或磁盘上但它不切断RDD的血缘关系一旦缓存数据丢失还可以通过血缘重新计算。checkpoint会把数据保存到可靠存储如HDFS中同时切断血缘关系数据丢失时不会回溯计算而是直接读取检查点数据。这个区别在很多客观题中会用“是否切断血缘”来作为关键判定点。4.2 Spark内存管理和Executors分配大数据平台开发写Spark任务时不仅要会写代码还要理解任务运行时的内存分布。笔试题常考Spark内存管理模型这部分顺丰的题也有涉及。Spark早期1.5及之前是静态内存管理预留内存、堆内内存、堆外内存各管各的。之后1.6引入了统一内存管理模型把堆内内存划分成Storage和Execution两部分两者之间可以互相借用——Execution内存不够时可以占用Storage的空闲内存Storage同理。这个设计大幅提升了内存利用率。为什么统一内存管理是个重要改进因为在实战中有些任务Cache用得少、Shuffle用得多有些任务正好相反静态分区必然造成浪费。统一内存管理允许动态借用更适应不同任务的真实需求。Executors分配相关的题也常考。例如已知集群资源的核数和内存问你怎么设置spark.executor.cores、spark.executor.memory比较合理。这类题没有绝对标准答案但一般原则是给YARN的ApplicationMaster留足够的核和内存然后给每个Executor分配2到5个核避免Executor数量过多导致任务调度开销过大同时spark.executor.memory要预留一部分作为系统开销和Overhead。如果你能了解清楚这些配置背后的资源关系客观题基本难不倒你。4.3 Flink的Checkpoint和Exactly-OnceFlink这几年的热度一直在涨流处理笔试题中几乎必考。顺丰这种有大量实时业务场景的公司Flink平台开发岗考察Checkpoint和状态一致的题目非常多。Flink达到Exactly-Once的基石是Checkpoint机制。它的核心思路是基于Chandy-Lamport分布式快照算法定期将每个算子的状态和事件流的位置保存下来当发生故障时从最近一次Checkpoint恢复状态并重新处理数据。这里面有一个关键的机制——Barrier。Barrier是插入到数据流中的一种特殊标记当某个输入流的Barrier到达算子时算子会把当前状态保存下来然后等待其他输入流的Barrier全部到达再继续处理。如果这个过程理解不清考试中看到“Barrier对齐”这类选项可能就会懵。还有两个容易混淆的概念At-Least-Once和Exactly-Once。Flink的Checkpoint机制本身可以保证故障恢复时不会丢数据但如果不启用Barrier对齐可能出现重复处理的情况那就是At-Least-Once。只有实现了Barrier对齐才能精确一次。注意这里有个细节值得单独记一下在Flink 1.11版本之后还可以配置CheckpointingMode为AT_LEAST_ONCE来跳过Barrier对齐以牺牲一致性为代价换取更低的延迟——这个选项设置有时也会出现在题目中。4.4 Spark Streaming和Flink的定位差异大数据平台开发岗弄清楚Spark Streaming和Flink在架构上的差异很重要。Spark Streaming的本质是微批处理——把实时数据流切分成一小段一小段的RDD然后对每个批次的RDD进行批处理Flink则是真正的流处理引擎——数据一条一条流转每个事件独立处理同时支持基于事件时间的高精度窗口计算。这个差异带来的实际影响是什么呢如果你只需要做准实时处理对延迟要求不是那么极致比如分钟级Spark Streaming完全够用而且生态更成熟、和离线任务共用一套代码更简单。但如果你的业务要求毫秒级或者事件驱动那Flink是更合适的选择。顺丰的物流轨迹实时监控就需要低延迟、高吞吐的实时计算能力所以Flink题目的占比才会逐年提升。另一个常考点是窗口机制。Spark Streaming窗口计算在微批的基础上实现窗口长度和滑动间隔必须是批处理间隔的整数倍Flink原生支持滚动窗口、滑动窗口、会话窗口还支持Event Time和Watermark机制。考Event Time、Watermark相关概念时很多时候会结合乱序数据处理来理解。5. 数据仓库和数据库数仓建模是平台开发的基本功数据仓库相关的内容在面向校招的大数据平台开发笔试题中很常见。虽然你可能不直接负责建模但理解数仓的分层架构和建模方法论是日常和数仓团队协作的基础。5.1 数仓分层ODS、DWD、DWS、ADS数仓分层在顺丰这类互联网公司几乎是标配。常见的分层是ODS层原始数据层直接存放从业务库、埋点日志、消息队列同步来的原始数据不做或只做很小的清洗DWD层明细数据层对ODS层数据做清洗转换统一格式、去重、补齐维度保持数据粒度明细DWS层汇总数据层按主题进行轻度汇总比如按日汇总订单数、按小时汇总物流量等ADS层应用数据层面向具体业务需求、报表、大屏等按需组装数据考试中经常会给你一个场景问某张表应该划分到哪个层。比如“一个订单明细表包含订单号、商品ID、金额、状态、时间等所有明细字段”应该放哪个层正确答案大概率是DWD层因为它是明细数据。又比如“一张按省份按天汇总订单金额的表”用于报表展示应该放ADS层。分层不只是表结构的问题本质是让数据流向清晰、每个环节职责单一同时减少重复计算。理解了这个目的你做题时就不会死记硬背。5.2 数据库事务特性和隔离级别数据库部分ACID和隔离级别是必考内容。这里有一个经典考察点四种隔离级别的各自特点以及对应的并发异常。读未提交可能脏读、不可重复读、幻读读已提交避免脏读仍可能不可重复读、幻读可重复读避免脏读、不可重复读仍可能幻读串行化避免所有问题但性能很低关于MySQL默认隔离级别是“可重复读”这个点需要注意Oracle默认是“读已提交”而MySQL默认是“可重复读”。选择哪个隔离级别取决于并发控制策略。MySQL选择“可重复读”是为了兼容基于BinLog的复制机制在特定场景下减少问题而Oracle选择“读已提交”是因为它用多版本并发控制MVCC能在底层处理很多一致性需求所以不需要默认可重复读。顺丰的大数据平台开发岗日常主要面对的是大数据组件而不是传统关系型数据库但客观题里数据库基础是躲不开的。我建议把MVCC的原理、事务隔离级别的定义、常见死锁场景搞清楚这些相对容易拿分。5.3 NoSQL的典型应用场景NoSQL在笔试题中考的是你对不同存储引擎适用场景的判断。常见的几类Key-Value存储Redis适合缓存、计数器、限流列式存储HBase、Cassandra适合海量数据写入和按Key查询文档存储MongoDB适合半结构化数据搜索存储Elasticsearch适合全文检索和日志分析一个经典题目是如果业务需要存储海量订单流水同时支持按订单号实时查询你会选什么存储HBase因为RowKey直接按订单号设计写入吞吐很高。如果题目换成“需要全文检索订单备注信息”答案就变成Elasticsearch。其实这类题考的不是你会不会用某个组件而是你能不能选型——这是大数据平台开发工程师必备的技能。6. Linux、网络和算法客观题里的技术底座最后这部分说说经常被忽视但也会出现在考卷上的内容。一套完整的笔试题目不会只考大数据组件Linux命令、计算机网络、数据结构算法这些都是基础能力的检测项。6.1 Linux命令排查问题的看家本领大数据平台开发日常肯定要跟Linux打交道排查问题时常用命令包括top看CPU、内存、负载free -h看内存使用情况df -h看磁盘空间jstack看JVM线程快照定位死锁或线程问题jstat查看JVM GC情况netstat看端口和网络连接状态tail -f看日志笔试中Linux题目范围比较广比如查看进程线程数用什么命令、如何查看某个端口是否被占用、如何大文件快速定位关键字。这套题里出现的一些命令可能不是最常用的那几个所以复习时把高频命令的常用参数过一遍很关键。6.2 网络基础TCP三次握手和HTTP状态码网络基础题在大数据笔试题中占比不高但比较送分。TCP三次握手的过程包括SYN、SYNACK、ACK三个步骤考题中会改为每次握手客户端和服务端分别发送什么标志位。HTTP状态码也常考200表示成功、301/302是重定向、401未认证、403禁止访问、404资源不存在、500服务器内部错误、502网关错误、503服务不可用。大数据平台开发还要了解一些常用的RPC框架包括Thrift、gRPC等。顺丰这种技术栈比较复杂的公司内部各系统之间通过RPC通信非常普遍。客观题可能会考gRPC基于HTTP/2传输、默认使用Protocol Buffers序列化协议这类基础概念但不会考得太深。6.3 数据结构和算法不是竞赛级别的难度大数据平台开发的算法题通常不会出现特别偏难怪的竞赛题目更偏向经典数据结构操作和基础算法思想。校招笔试中算法客观题出现的场景一般是给出一个代码片段问你它的时间复杂度或空间复杂度或者是给定场景选合适的数据结构。时间复杂度分析比较常考二分查找是O(log n)链表的插入删除是O(1)但随机访问是O(n)哈希表平均O(1)但最坏O(n)快排平均O(n log n)但最坏O(n^2)。红黑树和平衡二叉树的区别也是大数据框架源码中经常涉及的考点——ConcurrentHashMap在JDK 1.8中就用到了红黑树结构。由于时间有限更推荐优先复习核心的排序算法尤其是快排、归并重点理解分治思想和最坏时间复杂度的原因、二叉树遍历、常用数据结构的时间复杂度对比难度不需要追求到极限但基础一定要扎实。7. 我做题时的避坑笔记和复习建议说到底一套客观题合集的作用不只是让你“刷完知道答案”而是帮你定位自己的知识盲区。我有几个实用的复习建议算是自己在求职路上踩过坑后总结出来的经验。第一按专题梳理而不是按套卷刷。不要一套一套盲目地刷那样效率很低。把题目拆分成专题今天是JVM专题明天是Spark专题集中突破效果要好得多。这里没有绝对标准但一个有效的方式是把薄弱知识点单独拉出来反复练习相关题目直到不再模糊为止。第二每个知识点都要追问原理。为什么用这种数据结构、为什么选这个参数、为什么这样划分阶段遇到不懂的宁可花一个小时查明白也不要背一个答案就算了。因为客观题选项之间的差异往往非常细微只知道结论的话遇到变形题很容易丢分。第三错题一定要整理。把每次做错的题、模糊的题、蒙对的题统统摘出来记下知识点和易混淆的点考前集中回顾。我当时整理了一套自己的笔记把“容易混淆的知识点”专门做了一页对比比如reduceByKey和groupByKey的区别、cache和checkpoint的区别、HDFS和HBase的存储区别效果很好。第四不要只刷题不写代码。笔试题是客观题但考察的知识点都是来源真实的开发场景。如果条件允许我建议你一边复习一边动手练习——比如自己搭一个小的Hadoop集群写几个MapReduce任务或者用Spark读一份数据做TopN排行。对于对数据链路有一定理解的人来说实际动手过一遍看到运行过程比刷十道题都有用。第五考前把基础概念快速过一遍。像HDFS读写流程、YARN调度机制、Spark Shuffle机制、Flink Checkpoint原理这类主干知识考前一周每天花一点时间过一遍不需要细抠关键在于看到题目后能迅速匹配到对应的知识点。最后再分享一个小细节笔试遇到不会的题不要慌。大部分校招笔试的客观题是有一定区分度的它会故意放几道容易混淆的题来判别你的掌握程度。碰到不确定的先跳过把会做的做完再回头推敲。基于我个人的经验能把主干知识掌握清楚、把易混淆点拉通对比、对底层原理理解到位的候选人通过笔试的概率和后续面试的通过率都会比单纯靠刷题背答案的人高出一截。核心竞争力始终来自对技术的深度理解而不只是题库里那几道答案。