2018年的爱奇艺秋季校招hadoop工程师笔试题放到今天来看依然有很强的参考价值。那会儿正是大数据岗位的招聘旺季爱奇艺作为视频行业的头部公司对hadoop生态的要求相当务实不考偏题怪题但非常看重候选人是否真正理解分布式系统的运行机制。我当时把这场笔试的题目完整复盘了一遍结合后面几年带团队面试的经验把里面的核心考点重新梳理了一次。这篇文章不打算逐题罗列答案而是把题目背后的知识点、出题人想考察的思维逻辑以及对应的实操场景串起来讲对正在准备大数据岗位面试的朋友应该会有直接帮助。1. 爱奇艺这次笔试到底在考什么——题型分布与考察思路拆解先说说这场笔试的整体观感。第一场的题目覆盖面很广从HDFS的基础原理到MapReduce的计算模型再到Zookeeper、Hive这些生态组件的使用几乎把hadoop工程师日常工作中最常打交道的几个模块都点到了。题型上以选择题、简答题和手写代码题为主没有特别偏门的源码级追问但要求对底层机制有清晰的认知而不是停留在“会用命令”的层面。我当时复盘的最大感受是爱奇艺的考察思路非常贴近实际生产环境。它不问你“HDFS的默认副本数是几”这种死记硬背的东西而是会给你一个故障场景让你分析数据丢失的可能性或者给你一个数据倾斜的作业让你给出调优方案。这意味着单纯刷面试题意义不大必须真正动手搭过集群、跑过作业、排查过问题才能答到点子上。整张卷子的知识点分布大致可以分成四块HDFS读写机制与副本策略、MapReduce计算模型与Shuffle过程、Zookeeper在HA架构中的作用、Hive的基础操作与底层原理。另外还夹杂了一些Java基础题和简单的算法题这个后面会单独说。接下来的几个章节我就按这个脉络逐块展开把高频考点、易错点和延伸思考一次性说清楚。1.1 从岗位JD反推考点视频公司为什么这么考先别急着看题咱得先搞清楚爱奇艺这样的视频平台hadoop工程师到底在解决什么问题。视频网站的日志数据量是出了名的大用户行为日志、播放记录、推荐系统的训练样本、内容审核的元数据全都得落到分布式存储里。每天新增的数据量是TB级别甚至更高单机根本扛不住所以HDFS是绝对的核心基础设施。与此同时离线计算的任务也非常重。推荐系统的用户画像、内容热度排行、运营报表这些都是通过MapReduce或者Hive跑出来的。这就解释了为什么笔试里MapReduce的题目比重那么大——它不是单纯考理论而是考察你有没有能力在真实集群上写出高效、稳定的数据处理作业。至于Zookeeper则是因为生产集群几乎都是HA架构NameNode的Active/Standby切换、YARN的ResourceManager高可用全都依赖Zookeeper做分布式协调。爱奇艺考Zookeeper本质上是在考察候选人有没有接触过企业级集群的部署和运维而不是停留在伪分布式学习的层面。这些内容刷题软件里能给你答案但理解背后的业务驱动面试时才能答得让面试官眼前一亮。2. Hadoop核心基础考点精讲——从HDFS到MapReduce的高频题目拆解这一部分是整场笔试的绝对重点也是hadoop工程师日常工作中用得最多的知识模块。我按照HDFS和MapReduce两大块来拆每个知识点都结合笔试题目和实际场景展开尽量把背后的原理讲透。2.1 HDFS读写流程与副本策略不是背答案而是理解设计哲学笔试里关于HDFS的题目翻来覆去绕不开这几个数据块默认大小是多少、副本因子默认是多少、读写流程是怎么走的、NameNode挂掉怎么办。这些基础题说实话不难难的是理解为什么这么设计。HDFS默认数据块大小是128MB早期是64MB2.x之后改成128MB副本因子是3。为什么要用这么大的块因为HDFS的设计目标是存储超大文件块越大NameNode需要维护的元数据就越少一个集群能管理的文件总量就越大。读写流程方面读和写的路径是反过来的。写入时客户端先联系NameNode获取数据块对应的DataNode列表然后以流水线的方式把数据包依次传给第一个DataNode再由它转发给第二个、第三个形成一条管道。这样做的好处是减少了客户端的网络压力坏处是中间任何一个节点挂了整条管道就要重建。读取时客户端会优先选择离自己最近的DataNode读数据这涉及到机架感知——如果客户端和某个副本在同一个机架就优先读那个副本避免跨机架的网络开销。副本放置策略也是笔试常客第一个副本放在客户端所在节点如果客户端不在集群内就随机选一个负载较低的节点第二个副本放在与第一个副本不同的机架上第三个副本放在与第二个副本相同机架的不同节点上。这样设计的目的是兼顾容错和性能——两个副本在同机架可以降低写入的网络开销三个副本跨两个机架可以容忍整个机架宕机。笔试如果只考到这里其实区分度不高。真正拉开差距的是故障场景分析题。比如面试官会问三副本机制下如果两个DataNode同时宕机数据会丢吗答案是不一定。如果宕机的两个节点恰好各自持有同一数据块的不同副本而第三个副本所在节点还活着数据就不会丢。但如果其中一台宕机的节点是写入管道里的中间节点那就有可能出现数据块尚未完全写入的情况。这个分析过程比答案本身更重要它考察的是你对副本分布机制的理解深度。我当年遇到这道题时直接把副本放置的三种情况画出来分析面试官明显是认可的。2.2 MapReduce计算模型从WordCount到数据倾斜的进阶之路MapReduce的题目在笔试里占的比重最大也是很多候选人翻车的地方。基础题包括MapReduce的完整执行流程是什么、Shuffle阶段经历了哪些步骤、Combiner和Partitioner的区别是什么、Reduce阶段是怎么拉取数据的。这些是必须拿分的题。但真正有区分度的是数据倾斜和调优类的题目。先讲执行流程。一个MapReduce作业从提交到完成大致经历这样几个阶段客户端提交Job给YARNResourceManager分配Container启动ApplicationMasterApplicationMaster根据输入分片数启动相应数量的MapTaskMapTask读取数据后经过Map函数处理输出结果先写入环形缓冲区默认100MB缓冲区达到阈值默认80%后开始溢写溢写过程中会进行分区Partitioner、排序Sort和合并Combiner如果设置了的话然后将溢写文件合并成一个大文件。Map端完成后ReduceTask会从各个MapTask拉取属于自己分区的数据跨节点的数据拉取会先写入内存缓冲区大小不够再落盘全部拉取完后进行一次归并排序最后输入给Reduce函数。这里有个高频易错点Combiner是在Map端做的局部聚合它的输入和输出类型必须与Reduce函数的输入输出类型一致因为Combiner本质上就是一套Reduce逻辑在Map端的复用。很多候选人会把Combiner和Partitioner搞混其实两者作用完全不同——Combiner是减少Map端到Reduce端的数据传输量Partitioner是决定每条KV数据发给哪个ReduceTask。默认的Partitioner是哈希取模这就会导致数据倾斜问题如果某个key对应的数据量特别大哈希取模后它们会全部落在同一个ReduceTask上其他ReduceTask却空闲。针对数据倾斜笔试和面试里最常见的考察方式是给你一个实际场景比如统计电商平台每个用户的订单金额结果发现某个大客户的数据量占了80%问你怎么优化。标准思路有几种可以在Map端提前做Combiner聚合减少倾斜key的数据量可以对倾斜key加随机前缀让它们分散到不同ReduceTask最后再合并一次也可以设置spill阈值、增加ReduceTask数量从资源层面缓解压力。我实测下来最有效的是前缀加盐的方案但要注意加盐之后需要额外跑一个Job做二次聚合会有一定的性能开销需要权衡。还有一个高频考点是MapReduce的推测执行机制。当某个Task运行时间明显长于其他Task时ApplicationMaster会在另一个节点上启动一个相同的Task作为备份谁先跑完就用谁的结果然后杀掉另一个。这个机制在笔试里经常被问到“有什么优缺点”优点当然是能有效应对慢节点问题缺点是有可能造成集群资源的浪费尤其是当集群本身负载就很高的时候。实际生产中很多团队会针对长尾任务关闭推测执行因为资源竞争反而会拖慢整体进度。3. 生态组件与实战场景Hive、Zookeeper、集群搭建的高频问题如果说HDFS和MapReduce是hadoop的骨架那Hive和Zookeeper就是让hadoop真正能被业务用起来的血肉。笔试里这部分题目更偏向实际应用需要结合项目经验来答。同时集群搭建类问题也是考察操作能力的重要环节很多人理论背得滚瓜烂熟一上手就露馅。3.1 Hive的底层逻辑SQL怎么变成MapReduce的Hive几乎是所有hadoop工程师日常接触最多的组件因为它把复杂的MapReduce编程封装成了SQL让数据分析师也能直接操作海量数据。笔试里关于Hive的题目很少直接考语法更多是考底层原理。最经典的一道题就是一条Hive SQL从提交到返回结果经历了哪些过程完整的流程是这样的客户端提交SQL后Hive的Driver组件会将SQL交给Parser解析器进行语法解析生成AST抽象语法树然后交给Semantic Analyzer语义分析器进行表字段校验和类型检查接着是Logical Plan Generator逻辑计划生成器将AST转换成逻辑计划——这个阶段会做一些优化比如列剪枝、分区剪枝然后是Physical Plan Generator物理计划生成器把逻辑计划转换成一系列MapReduce任务最后通过Executor执行这些任务把结果返回给客户端。这里面涉及到的优化器Optimizer是Hive性能调优的关键比如谓词下推Predicate Pushdown就是典型的优化手段。笔试里关于Hive还有一个高频考点内部表和外部表的区别。内部表的数据由Hive管理删除表时数据也会被删除外部表的数据由HDFS管理删除表只删除元数据数据还保留在HDFS上。这个知识点本身不难但在实际使用中很多人会踩坑——在建表的时候没有仔细区分数据是否还需要复用结果误删了重要数据。我的习惯是如果原始数据还需要被其他组件使用一律建外部表只有Hive内部的中间结果表才用内部表。Hive的存储格式也是常考的。TextFile、SequenceFile、RCFile、ORC、Parquet这几种格式各有优劣。TextFile是人类可读的但压缩率和查询性能最差ORC和Parquet是列式存储查询效率高、压缩比大是生产环境的主流选择。笔试如果问“为什么ORC比TextFile查询快”核心要答出列式存储的优势——只读取查询涉及的列减少磁盘IO同时ORC内置了轻量级索引能进一步跳过无关数据块。我之前在项目里对比过同样一份10GB的数据TextFile格式跑一个简单的聚合查询要6分钟换成ORC格式只需要1分半这个差距在生产环境是质的区别。3.2 Zookeeper的角色与选举机制HA架构的定海神针Zookeeper在hadoop生态中的角色通俗点说就是分布式系统的协调者。笔试里关于Zookeeper的题目集中在几个方面节点类型有哪些、选举机制是如何运作的、在HDFS HA中扮演什么角色。Zookeeper的节点类型主要有四种持久节点、临时节点、持久顺序节点、临时顺序节点。其中临时节点和会话绑定客户端断开连接后临时节点会被自动删除这个特性常被用来做服务注册与发现。在HDFS的HA架构中两个NameNode会在Zookeeper上注册同一个临时节点Active节点会持有这个节点的锁Standby节点则监听这个节点。一旦Active节点宕机会话超时临时节点被删除Standby节点会收到通知并尝试获取锁进而完成主备切换。选举机制是Zookeeper最核心也最容易被考懵的部分。Zookeeper的选举算法在3.4.0之后默认是FastLeaderElection核心逻辑是基于投票的比较每个节点会投出自己认为最适合当Leader的节点比较的依据是zxid事务ID和myid节点编号zxid大的优先zxid相同则myid大的优先。当某个节点收到超过半数的选票时它就成为Leader。这里有个关键点为什么Zookeeper集群要求奇数节点因为选举需要超过半数投票才能产生Leader如果有两个节点两个节点各自投自己谁也没法超过半数集群就无法选出Leader这就是脑裂问题的根源。奇数节点可以保证任何情况下都只有一个节点能获得超过半数的选票。笔试里关于Zookeeper还有一个容易忽略的点Zookeeper最适合管理的是元数据这类小数据不适合存大数据。它的写入性能受限于磁盘同步如果频繁写入大对象会严重拖垮集群性能。我见过有团队把Zookeeper当成配置中心往里塞了几MB的配置文件结果整个HDFS的NameNode心跳都受到影响。正确的做法是Zookeeper只保存路径和标志位真正的数据放HDFS。3.3 集群搭建与伪分布式从零开始的经验总结笔试里偶尔会出一些关于集群部署的简答题比如“描述一下搭建一个3节点hadoop集群的步骤”或者“伪分布式和完全分布式的区别是什么”。这类题目看起来简单但想答得完整并不容易尤其是涉及HA、联邦等高级配置时很多细节会被忽略。先说伪分布式。所谓伪分布式就是在一台机器上模拟分布式环境所有守护进程NameNode、DataNode、ResourceManager、NodeManager都跑在同一台机器上。它的价值在于学习和开发测试但和真实集群有本质区别——没有网络通信、没有机架感知、没有故障转移。如果你只在伪分布式环境下跑过WordCount笔试题里关于“DataNode挂了NameNode如何感知”这类问题你很难答出真实环境中的细节。完全分布式的搭建核心步骤大致是配置SSH免密登录、配置core-site.xml指定NameNode地址和临时目录、配置hdfs-site.xml设置副本数、NameNode目录、DataNode目录、配置mapred-site.xml指定MapReduce运行在YARN上、配置yarn-site.xml指定ResourceManager地址和NodeManager的辅助服务、格式化NameNode、启动进程。每一步都有坑比如格式化NameNode时如果忘记删除之前的数据目录会导致NameNode启动失败再比如hdfs-site.xml里的副本数如果设置成3但集群只有2个DataNode写入时会一直报错。现在的环境还有一个常见需求用Docker快速搭建hadoop集群。这个在热词里也有体现。我之前写过一套基于Docker Compose的方案原理是每个容器跑一个hadoop组件通过容器名做DNS解析映射宿主机端口供外部访问。核心配置文件其实和物理机部署没有区别区别只在于网络和存储的隔离方式。有一点要特别注意Docker容器里的DataNode默认会使用主机名作为hostname如果不固定容器的主机名重启后DataNode的集群ID会变化导致DataNode无法加入集群报Incompatible clusterIDs错误。这个坑我踩过一次后来统一在docker-compose.yml里固定了container_name和hostname再没出过问题。4. 复杂度分析题与Java编程考点——笔试中的算法与代码题笔试的算法和代码题虽然不像纯开发岗那么难但也不能掉以轻心。爱奇艺这场笔试里的编程题大致分为两类一是基础的Java API运用二是简单的数据结构和算法题。这两个部分放在一起讲是因为它们本质上都是在考察候选人能否写出健壮的工程代码而不只是会写LeetCode。4.1 Java操作HDFS不只是上传下载关于Java操作HDFS网上有个高频提问“Java中对hadoop上传文件和下载就是对HDFS操作吗”这个问题的答案是肯定的但要理解透彻还需要知道FileSystem API背后做了什么。Java通过Configuration对象加载core-site.xml的配置然后通过FileSystem.get(conf)获取文件系统对象这个对象会根据配置连上NameNode之后调用的所有方法都是和HDFS交互。上传文件使用的是FileSystem.copyFromLocalFile方法它会把本地文件切分成数据块按照我们前面讲的流水线方式写入DataNode。笔试里的Java编程题通常会给一个场景让你写代码实现某个HDFS操作。比如统计一个文件的行数或者过滤出包含指定关键词的行。这种题目要拿高分关键在于代码的鲁棒性——是否处理了文件不存在的情况、是否设置了合理的缓冲区大小、是否在finally块中关闭了FileSystem实例、是否在客户端设置了副本数等参数。代码示例方面我给出一个常见题目的写法递归遍历HDFS目录并输出文件路径及大小。这个题目考察了FileSystem的listStatus和递归思想是生产开发中写数据同步工具的基础能力。import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.FileStatus; import org.apache.hadoop.fs.FileSystem; import org.apache.hadoop.fs.Path; import java.net.URI; public class HdfsListFiles { public static void main(String[] args) throws Exception { Configuration conf new Configuration(); conf.set(fs.defaultFS, hdfs://namenode:8020); FileSystem fs FileSystem.get(URI.create(hdfs://namenode:8020), conf); Path root new Path(/); listFilesRecursively(fs, root); fs.close(); } private static void listFilesRecursively(FileSystem fs, Path path) throws Exception { FileStatus[] statuses fs.listStatus(path); for (FileStatus status : statuses) { if (status.isDirectory()) { listFilesRecursively(fs, status.getPath()); } else { System.out.println(status.getPath().toString() status.getLen()); } } } }这段代码有几个细节值得说明。Configuration设置了fs.defaultFS这是连接HDFS的入口也可以选择从classpath加载配置文件但显式设置会让代码更清晰。listStatus返回的都是完整路径的FileStatus通过isDirectory判断要不要递归。最后一定要关闭FileSystem否则客户端进程不会退出。这个代码框架我在日常写数据校验工具时也在用基础但实用。4.2 排序与TopN考的是复杂度和边界处理算法题方面这场笔试出现了一些基础排序和TopN相关的问题。比如手写一个快速排序分析时间复杂度和空间复杂度或者给出一个海量日志文件要求找出访问量最大的TopN个IP。这类题目不难但能看出候选人是否具备扎实的算法功底和复杂度分析能力。快速排序的关键是Partition过程——选取基准元素把小于基准的放左边大于基准的放右边。平均时间复杂度是O(nlogn)最坏是O(n²)最坏情况发生在每次Partition都选到最大或最小元素作基准的时候。空间复杂度是O(logn)来自递归调用栈。这些如果只是背结论面试官追问几句就会露馅一定要自己手写一遍理解为什么递归深度是logn而不是n。海量日志TopN的问题最佳实践是利用堆这种数据结构维护一个大小为N的小顶堆遍历数据时如果当前元素大于堆顶就替换堆顶并调整堆最后留在堆里的就是TopN。时间复杂度是O(nlogN)比全排序的O(nlogn)更优。如果数据量实在太大单机内存放不下也可以结合MapReduce的思路先分片求TopN再合并求全局TopN——这正好把前面的MapReduce知识和算法题串起来了也是让我在笔试中觉得比较顺的答题路径。5. 这些真题背后的面试追问——从笔试到技术面的思维升级笔试只是第一关爱奇艺这类公司的技术面往往会围绕笔试答案进行追问。你笔试写“设置副本数为2可以节省存储空间”面试官就会问“那副本数设置成2会不会导致数据更容易丢失读写性能会有什么变化”你笔试写“用Zookeeper做HA”面试官就会问“Zookeeper自己挂了怎么办”所以准备笔试的时候不能只背答案要顺着答案继续往下推演形成一套自洽的知识网络。5.1 高频追问场景一HDFS写性能优化笔试题问你“如何提高HDFS的写入性能”你答了“增大缓冲区、增加副本因子、使用固态硬盘”面试官会追问“增大缓冲区是调哪个参数影响是什么”标准答案是dfs.client.block.write.replace-datanode-on-failure.policy和dfs.blocksize前者控制写入失败后的处理策略后者控制数据块大小。增大缓冲区可以增加单次写入的数据量减少网络往返次数但会增加客户端内存消耗。增加副本因子会提升数据可靠性但写入性能会呈线性下降因为流水线中需要同步写入的节点数量变多了。生产环境里的HDFS写入性能优化最常用的方案是使用SNAPPY或LZ4压缩。压缩可以在源头减少数据量写入速度和磁盘占用都能改善。但要注意压缩后的数据如果后续要做计算MapTask需要先解压这会增加CPU开销。所以不是所有场景都适合压缩需要根据业务权衡。5.2 高频追问场景二Zookeeper的脑裂和容错Zookeeper相关的问题面试官很喜欢追问脑裂。实际上Zookeeper的过半机制已经很好地解决了脑裂问题——一个集群永远只能有一个Leader。但面试官会问得更深入如果Leader和Follower之间的网络出现分区同一个Zookeeper集群被分成了两半会发生什么答案是只有当其中一半的节点数超过半数时才能继续对外提供服务。比如5个节点的集群被分成2个和3个3个节点的分区可以选出新Leader继续工作2个节点的分区无法达到过半投票会一直处于Looking状态无法提供读写服务。这个机制保证了整个集群始终保持一致性但也意味着Zookeeper的可用性是有牺牲的——网络分区时少数派分区会拒绝服务。扩展到HDFS的HA场景如果Zookeeper集群因网络分区而无法正常选举NameNode的自动故障转移就会失效。为了避免这种情况生产环境通常会把Zookeeper节点部署在与NameNode不同的机架上降低同时故障的概率。同时HDFS还支持配置QJMQuorum Journal Manager的高可用方案它保证了只有过半数的JournalNode写入成功才认为EditLog提交成功这又是另一个维度的过半机制。5.3 高频追问场景三从Docker镜像到平台化最近两年面试还有一个越来越常见的场景Docker化部署和平台化。热词里的“hadoop的docker镜像”和“搭建hadoop平台”其实代表了一个趋势——传统的物理机部署hadoop的方式正在被容器化替代。面试官可能会问“如果用Docker跑hadoop需要注意哪些问题”首先要明确hadoop内部使用hostname进行节点间通信所以Docker容器的hostname必须是固定的不能是随机分配的容器ID。其次DataNode的数据存储不应该放在容器内部因为容器删除后数据就没了必须挂载宿主机目录或使用持久化存储卷。第三容器编排工具如Kubernetes对hadoop的支持还需要考虑网络模型——hadoop依赖广播发现节点但在Kubernetes的扁平化网络下广播包可能无法跨节点传送所以通常需要显式配置所有NameNode和DataNode的地址。我之前在公司内部搭过一个基于Docker Compose的实验集群三个节点分别是namenode、datanode1、datanode2。配置文件其实和物理机部署没有区别核心区别在于网络和存储的隔离方式。Docker带来的最大好处是环境一致性——团队里任何一个人拉取同一个镜像都能得到一模一样的hadoop环境这对测试和开发来说效率提升非常明显。但生产环境做大规模容器化还需要考虑资源隔离、日志采集、监控告警等一系列问题远不是拉个镜像起个容器那么简单。我在这块的实际体会是搭一个能用的hadoop集群并不难难的是让这个集群在真实的业务压力下稳定运行。笔试里写的那些参数和命令如果不亲手在集群上验证过面试时被追问到细节就会发怵。所以给正在准备校招的朋友几个建议第一一定要自己动手搭一个hadoop集群哪怕是伪分布式也要把HDFS的读写、MapReduce的提交、Hive的查询完整跑一遍第二每一个知识点都要追问自己三个“为什么”——为什么这么设计、不这样设计会怎样、生产环境里怎么选第三多看真实的生产问题和对应的解决方案技术社区里有很多实战帖信息密度比教科书高不少。这套思路当年帮我拿下了几家大厂的大数据offer现在带团队面试时我也是按同样的标准去筛选候选人。希望这篇复盘对你有用。