秋招笔试季大数据岗位的题目又在各个技术群里刷屏了。刷屏的原因很现实题目看着不难真动笔写起来却处处是坑。我这些年既当过出题人也帮人复盘过上百份笔试题答案发现一个规律——笔试淘汰的人往往不是知识面窄而是踩在那些“以为会、其实没想透”的考点上。这篇文章就把大数据笔试题里的高频考点按模块拆开结合常见题型和答题思路给准备校招或跳槽的朋友一个可以直接对照复习的清单。1. 大数据笔试到底在考什么近两年的考察风向1.1 题型分布与分值结构大数据岗位的笔试题近几年已经从“背概念”转向“考理解”了。以我看到的各厂真题来看题型大致可以分成四块选择题/填空题约占三成、SQL题约占两到三成、简答/原理题约占两成、编程或场景设计题约占两成。有的公司会把SQL和编程合并成一道大数据量的代码题比如给你一份用户行为日志要求写出清洗逻辑或统计指标的实现。选择题考察面最杂Hadoop、Spark、Hive、Kafka、Flink、数据仓库理论都会涉及偶尔还会混几道Linux和Java基础题。简答题则集中在几个固定主题HDFS读写流程、Spark任务提交与执行流程、数据倾斜的解决方案、Hive与普通数据库的区别、Kafka消息不丢失的机制等。场景设计题一般是“给你一个业务需求请你设计离线数仓的层级结构”或者“某张表数据量暴增如何优化查询”。从分值倾斜来看出题人最看重的是两件事一是对分布式计算框架运行机制的理解程度二是实际写SQL和处理数据的能力。这两块占了总分的一半以上复习时务必优先投入。1.2 从背概念到考理解的转变我印象很深的一道真题是“Spark的RDD和DataFrame有什么区别”如果只回答“一个是弹性分布式数据集一个是带Schema的分布式表”基本只能拿一半分。出题人想听到的是二者在底层存储方式、类型安全、执行计划优化、序列化开销上的差异以及在实际项目中什么场景下选哪个更合适。这就是近两年笔试最明显的变化——考点还是那些考点但提问方式从“是什么”变成“为什么这么设计”“什么时候用哪个”“出现了问题怎么排查”。所以单纯背八股文已经不够了每个知识点都要能往下追问两层。2. Hadoop核心机制笔试题读写流程与小文件治理2.1 HDFS读写流程的完整链路HDFS读写流程是选择题和简答题的双料高频点。读流程的关键得分点有客户端先向NameNode发起请求NameNode返回数据块所在的DataNode列表客户端直接与DataNode建立流式读取连接数据按块传输并做校验。很多人在这一步容易漏掉细节——块所在的DataNode列表是按网络拓扑排序返回的目的是优先读取同机架的数据减少跨机架流量。写流程更容易丢分。完整链路是客户端向NameNode申请上传NameNode检查权限和配额后返回可写入的DataNode节点列表客户端将数据分块写入第一个DataNode第一个DataNode再复制到第二个第二个再复制到第三个形成管道复制每写一个块DataNode会向NameNode上报块信息。整个链路里最容易丢分的一个细节是客户端写入的并不是等所有副本都写完才算成功而是采用“最小副本数成功即返回”的语义配合后续的异步复制或副本修复来保证最终一致。把这个点讲出来面试官会觉得你是真跑过集群的人。2.2 小文件问题人人会背、少人能讲透HDFS小文件问题基本是必考题答题时很多人的表述停留在“小文件太多会占满NameNode内存”这种答案可以拿基础分但拿不到高分。完整的分析应该拆成四层NameNode层面每个文件、目录和块都要在内存里维护元数据一个块大约占150字节左右的元数据开销百万级小文件就能吃掉GB级内存。MapReduce/Spark层面小文件会导致InputSplit数量激增每个Split启动一个TaskTask调度开销比计算开销还大。数据读取层面小文件破坏了顺序读的连续性随机IO次数大增。下游链路层面小文件从HDFS同步到Hive、Kafka或数仓其他层时会产生大量网络连接和写入请求拖慢整个同步任务。解决思路也要分阶段答源头控制写入时用Hive的merge合并或Spark的coalesce/repartition控制输出文件数、周期合并定时任务对小文件目录做合并、存储层面转换比如将小文件存成ORC/Parquet格式再合并因为列式格式本身有较好的压缩和谓词下推能力。2.3 NameNode与SecondaryNameNode的关系辨析这道题出镜率极高因为它特别能区分“看过文档”和“真懂原理”的人。很多人的答案写“SecondaryNameNode是NameNode的备份”这个说法是错的。SecondaryNameNode并不是热备节点它只是定期拉取NameNode的EditLog和FsImage合并成新的FsImage再返回给NameNode作用是帮NameNode分担合并压力的“辅助工”一旦NameNode宕机它并不能直接顶上。顺带提一句真正的高可用方案是部署两个NameNode组成Active/Standby通过共享存储或JournalNode同步元数据变更日志。笔试中如果题目问“如何保证NameNode高可用”要把FailoverController、ZKFC、JournalNode这几个组件的关系写清楚并且说明Active节点宕机后Standby节点如何通过JournalNode补齐日志并切换状态。3. Spark高频题从算子原理到数据倾斜调优3.1 RDD的五大属性与Lineage容错机制Spark原理题中RDD的五大属性是基础中的基础分区列表、计算函数、依赖关系、分区器仅对Key-Value类型、首选位置。答题时不要干巴巴列点而要说明每个属性存在的意义。比如首选位置是为了让计算尽量在数据所在节点执行减少网络传输依赖关系既决定了Stage划分又是容错恢复的基础。Lineage容错也是高频考点。要答出RDD通过血缘关系记录父RDD到子RDD的转换链当某个分区数据丢失时可以根据血缘重新计算该分区。这里有个值得展开的点——宽依赖的容错代价远高于窄依赖因为窄依赖只需重算父RDD的对应分区而宽依赖可能导致多个父分区参与计算所以实际工程里常用检查点Checkpoint来切断过长的血缘链。3.2 宽依赖与窄依赖Stage划分的判断依据关于宽窄依赖的选择题通常长这样“以下哪个算子是宽依赖groupByKey、map、filter还是union”答案是groupByKey因为需要将相同Key的数据分发到同一分区产生Shuffle。窄依赖则指父RDD的每个分区最多被一个子RDD分区使用比如map、filter、union。更进阶的考法是给你一段执行计划要求判断划分成了几个Stage。方法是顺着RDD依赖链从后往前看遇到宽依赖就切一刀。值得注意的是窄依赖的算子之间可以放在同一个Stage里做流水线执行这也是Spark比MapReduce快的一个关键原因——减少Shuffle和中间结果落盘。把这两件事关联起来答得分会高不少。3.3 数据倾斜现象、定位与解决方案数据倾斜是笔试和面试都绕不开的压轴题。最典型的题目是“某Spark任务一直跑得很慢最后发现大部分Task很快结束只有一两个Task卡了很久你怎么排查”完整答题思路分四步定位通过Spark UI查看每个Stage的Task耗时和Shuffle读写量确认是否存在少数Task处理的数据量远大于中位数的情况。找因确认倾斜发生在哪个算子常见原因有groupBy的Key分布不均、join时关联键大量为空、distinct后的热点Key、两表join时小表Key重复率高。解决常规手段包括加随机前缀并二次聚合对聚合类倾斜、将大表热点Key与小表拆开处理再union对join类倾斜、过滤空值或单独处理空值Key、广播小表避免Shuffle、调整spark.sql.shuffle.partitions增大分区数分散压力。验证改完参数后观察前后两个Stage的Task耗时曲线确认长尾消失同时对比整任务耗时。这道题的高分关键不在于罗列方案而在于体现排查顺序和对方案适用条件的判断。比如加随机前缀只适合聚合场景不适合join场景因为join还需要还原原始Key。把每个方案的适用边界说清楚比背十个方案都管用。4. Hive和数据仓库必考题SQL基本功与权限设计4.1 窗口函数笔试SQL题的半壁江山一道Hive SQL题里如果出现“每个用户最近一笔订单”“各部门薪资排名”“连续登录天数”这类需求几乎必用窗口函数。高频窗口函数主要有ROW_NUMBER()、RANK()、DENSE_RANK()、SUM() OVER()、LAG()/LEAD()、FIRST_VALUE()/LAST_VALUE()。连续登录天数的题目值得单独练——它把窗口函数和日期函数结合得比较深。思路是先用ROW_NUMBER()按用户分组、登录日期排序然后用登录日期减去排序号得到分组标记日期与序号之差相同的记录属于同一连续区间再按用户和分组标记聚合计数。笔试里出现这道题时很多人卡在“怎么把连续区间切出来”这一步实际上只要理解“日期减行号”这个技巧整个问题就迎刃而解。4.2 分区与分桶原理层面的辨析题Hive分区和分桶的区别也是一道常青题。分区是按业务维度如日期、省份把数据切分到不同目录查询时通过分区裁剪减少扫描量分桶则是按某个字段的哈希值将数据散列到固定个数的桶文件中适合抽样查询和Map端Join优化。容易被忽略的知识点是分区字段是虚拟列数据文件中并没有这个字段而分桶字段必须是真实的普通字段。另外分桶在写入时需要设置分桶数和排序规则如果数据量不大或查询不涉及桶字段分桶的收益并不明显。这种“什么场景下收益有限”的边界感恰恰是阅卷人乐于看到的深度。4.3 行级与列级权限数据安全设计题的热门方向近两年数据安全类题目越来越多最典型的一道是“请设计一个方案实现同一张表中不同角色只能看到特定行和特定列。”这就是常说的行/列权限设计。列权限相对简单通常在查询引擎层做拦截通过视图或SQL改写实现。比如给低权限角色创建一张只包含部分字段的视图或使用Ranger/Atlas这类组件在Hive层配置列级别的访问策略。行权限要复杂一些核心是数据过滤条件的注入。常见实现方案有几种视图方案为每个权限角色创建带WHERE条件的视图比如只展示部门ID等于当前用户所属部门的数据。优点是实现简单缺点是视图过多时管理成本高。SQL改写方案在统一查询入口拦截SQL解析后自动追加数据权限过滤条件。优点是应用透明缺点是SQL解析存在复杂度和性能开销。标签/元数据方案给数据行打上权限标签查询时通过标签匹配用户属性。适合跨部门、跨项目的细粒度控制。如果笔试题目追问“开源方案怎么选”可以回答粗粒度场景用Hive本身的授权机制配合视图细粒度场景用Apache Ranger它对HDFS、Hive、HBase都提供了统一的行列级策略控制如果还需要列级脱敏Ranger也可以配置Masking策略。把“选型依据”说清楚而不是只写一个工具名才是这类题的得分点。5. 集群部署与资源调优题策略与参数怎么答5.1 集群部署策略从单机到分布式的演进“给一个从零开始的集群部署方案”算是场景题里的大题了。常见问法有两种一种是“10台机器怎么规划角色”另一种是“从单机到集群需要做哪些调整”。先回答角色规划。中小规模集群10到20台的典型部署方式是3台机器部署NameNode、ResourceManager等Master角色其中NameNode做Active/Standby HA剩余机器部署DataNode和NodeManager。如果要跑Hive还需要单独或复用节点部署MetaStore和HiveServer2如果要跑实时任务再加Kafka和Flink集群。角色的关键在于不要让Master角色的负载过重NameNode和ResourceManager放在同一台机器上时要注意内存分配避免互相争抢堆空间。再回答演进路径。单机伪分布部署Local模式只能用于学习和验证真正上生产前要做三件事开启NameNode HA、配置资源调度器多队列、调整存储和计算的磁盘布局。很多笔试失分点在“从单机到集群配置要改什么”这个具体问题上比如core-site.xml中的默认副本数要从1改成3这是一个特别明显但经常被忽略的点。5.2 内存与并行度参数一句话暴露实战水平集群参数调整类题目最能区分背文档和干过活的人。拿Spark Executor内存来说一个常见问法是“Executor内存设多大合适堆内和堆外怎么分”标准的大致思路是先看集群单个节点物理内存和CPU核数再估算每个Executor需要跑几个Task、每个Task处理多少数据。经验值一般是Executor内存取8G到16G之间核数取3到5个避免单个Executor占用过多核导致JVM GC时间上升。堆内内存里要预留20%到30%给RDD存储和Shuffle缓冲堆外内存spark.memory.offHeap用于网络缓冲和本地操作默认较小不必过分调大。Hive/Spark SQL侧的高频参数还包括spark.sql.shuffle.partitions默认200数据量大时通常要调大数据量小的时候调小反而更快因为Shuffle文件太多会产生大量随机IOspark.sql.adaptive.enabled开启自适应查询执行后Spark可以动态合并Shuffle分区这个参数在笔试里越来越常出现建议主动提一句。6. 项目场景题的高分答法以网约车数仓项目为例6.1 题目常见问法与回答结构项目类笔试一般给出一段业务描述比如“某网约车平台每天产生大量订单和轨迹数据请基于Hive/Spark设计离线数仓完成数据清洗、指标分析和可视化展示”。这类题的答题结构建议按数仓分层来展开ODS层存放原始日志订单表、司机表、乘客表、轨迹表DWD层做清洗和标准化去重、补全、格式统一DWS层做主题汇总按城市、时段、司机维度聚合成宽表ADS层面向报表输出核心指标订单量、完单率、平均应答时长、高峰时段运力。每层都点出存储格式和分区策略比如ODS层用Parquet格式按日期分区保存原始数据DWS层按城市和日期双分区。在分层设计的基础上再补充数据质量方案比如清洗规则里包含空值处理、经纬度越界剔除、同一订单重复上报去重从笔试角度这些点都已经踩到得分区了。6.2 清洗环节的考点从Spark算子到脏数据处理网约车项目里基于Spark的数据清洗是一个独立考点。常见脏数据包括订单状态缺失、上车点经纬度超出城市范围、司机ID与订单ID关联不上、行程时长负值、同一订单重复记录。用Spark实现清洗答题时建议按步骤写清楚算子链用filter过滤异常值用dropDuplicates按订单ID去重用withColumn补全或转换字段格式用join关联订单表和轨迹表并选择inner或left_outer。注意到的一个高频隐藏考点是join时如果轨迹表过大需要考虑数据倾斜此时可以按订单日期分桶后再join减少Shuffle压力。如果题目要求写出Scala或PySpark代码核心代码块只要体现关键逻辑就可以拿大半分不必追求完整工程代码。写清楚处理前后的数据量对比反而更像真实项目里的做法。6.3 可视化环节的考点指标口径比图表更重要关于Flask和ECharts做数据可视化笔试通常不会考代码细节而会问“你会展示哪些指标为什么”。这其实是查指标口径的把关能力。推荐答案是先用指标体系分层——全局概览指标日订单量、GMV、日活司机数、运营分析指标完单率、应答率、平均应答时长、运力调度指标高峰满载率、区域运力缺口、热力图。每类指标想清楚业务含义比炫酷图表重要得多。如果题目追问“某个指标两天之间下降了10%如何排查”可以回答从数据质量、业务活动、技术故障三个方向定位这种回答即便在笔试里也能体现数据思维。ECharts选型题里需要根据数据特点选择合适的图表类型趋势用折线图、地域分布用地图/散点图、司机时段热度用热力图、城市排行用柱状图。把指标和图表类型的匹配逻辑说清楚比罗列画了几个图更让人印象深。7. 笔试题里那些容易失分的细节坑7.1 读题与踩分点先想清楚再动笔复盘过不少答卷发现一个共性问题很多人在SQL题和场景设计题上不是不会做而是没读懂题目就往上写。比如题目说“统计每个用户最近30天的平均消费金额”有人直接把所有消费记录都算进去忽略了“最近30天”这个窗口又如“计算连续3天活跃的用户”有人没处理用户一天内多次活跃的情况导致重复计数。我的建议是动笔前先花两分钟把题目拆成三个问题输入是什么、输出是什么、边界条件是什么。输出列名、排序方式、去重要求往往写在题干最不起眼的地方却是判分的关键。7.2 答题格式与阅卷人视角大数据笔试的阅卷节奏通常很快一份有清晰结构的答案比一堆口水话更占便宜。一个实用的技巧是简答题采用“总-分”结构先一句话给出结论再分点补充细节。比如数据倾斜题先写“先通过Spark UI定位长尾任务再判断倾斜类型最后选择对应方案”然后逐点展开。这样即使后面的细节有口误阅卷人也能从首句就看到完整答题框架。另外要小心选择题的“绝对化表述”。选项里出现“一定”“必然”“所有”这种词时大概率是错误选项出现“可能”“可以按需”“主要用于”这类词时通常是正确选项。这是出题人惯用的干扰方式知道这个规律后遇到不确定的选择题至少能排除一半选项。7.3 备考顺序与时间分配建议结合近两年的出题频率我给一个相对稳妥的备考优先级SQL窗口函数练习排第一因为SQL题几乎是笔试必出且最容易拿分Spark核心原理排第二尤其是宽窄依赖、数据倾斜、内存管理Hadoop/HDFS基础排在第三重点是读写流程、小文件、NameNode HAHive数仓理论和权限设计排第四。Kafka和Flink虽然也考但出现的频率和分值占比明显低于前四类时间有限时可以放在后面。刷题时不要只刷笔试题可以配合真实数据处理练习。把一份真实的日志数据用Spark清洗一遍、统计出指标、再写几个窗口函数比背一百道题都有效。题是做不完的但对数据的感觉是练出来的。回到我自己带人和评卷的体会笔试真正筛掉的往往不是技术最差的人而是“没有梳理清楚自己知识体系”的人。大多数考点都在公开文档和源码里写得很明白差别在于能不能把它们串成一个闭环。如果你时间紧张优先把本文提到的几个模块练熟如果还有余力就把每个知识点都追问自己两个“为什么”这比多刷十道题更能建立竞争优势。