前阵子有学弟来问我携程的大数据岗位笔试到底考什么。他说自己在牛客上看了不少面经感觉东西特别杂不知道从哪下手。这让我翻出自己当年整理的携程2019届秋招专业笔试大数据方向复盘重新看了一遍发现里面的核心考点放在今天依然很有参考价值。虽然岗位名称每年都在微调但笔试的出题逻辑没变它不考偏门算法也不深挖机器学习公式重点考的是你有没有真正接触过大数据链路里那些核心组件以及能不能用工程化的思维解决实际数据问题。这份复盘适合两类人看。一类是正在准备秋招、想投大数据开发或数据平台方向的同学你可以拿它当考点地图照着查漏补缺另一类是在校学生想了解“数据科学与大数据技术”这个专业未来就业具体在做什么看一遍笔试考什么基本就明白行业里的大数据岗位到底在解决什么问题。看完这篇复盘你会知道一份真实的大数据笔试是怎么出题的也会理解每个高频考点背后的能力模型而不是背了一堆名词却不知道怎么用。先说明一下资料来源2019届的真题现在很难收集到完整版本下面所有题型和考点是我结合当时多个参加笔试的同学反馈加上自己在实际工作中反复验证过的重点整理成的一份“题型还原解题思路”。原题细节可能有出入但考察方向、高频考点的分布和得分技巧到今天还是相通的。你把这篇文章当成一份“笔试地图”来用就好。1. 笔试整体分析携程大数据方向到底在考什么1.1 题型构成与分值分布携程那年的笔试用的是在线笔试平台题型大致分为三类选择题、编程题和简答设计题。从多位同学的回忆来看题量和时间设置大约是下面这个样子当然不同批次可能有微调但结构基本一致题型题量分值占比考察重点单选/多选25-30道约40%Java基础、Linux、数据库、Hadoop/Spark组件原理编程题2道约30%SQL窗口函数、TopN、字符串处理、日志统计简答/设计题2-3道约30%数据倾斜、架构设计、实时链路方案这个结构透露了一个关键信息选择题题量大、覆盖面广主要用来快速过滤基础不扎实的人编程题题量少但区分度高SQL写得好不好一眼就能看出来简答题则是最容易拉开分差的部分因为它考察的不是“知不知道”而是“能不能把思路写清楚”。我当时给学弟的建议是别把复习重心全放在选择题上。选择题大家都能刷到60分以上真正决定你能不能进面试的是后面那两三类主观题。尤其简答题阅卷人看的是你的分析思路和表达逻辑这两个是刷题刷不出来的必须靠深入理解原理。1.2 考点地图从基础组件到业务场景结合多方笔试反馈和后来面试复盘携程大数据方向的考点基本集中在下面几个模块模块具体考点出现频率Java基础集合、线程、JVM内存模型、异常处理高Linux常用命令、文件权限、进程查看、日志定位中数据库SQL基础、索引、join高HadoopHDFS读写流程、MapReduce执行流程、Shuffle高SparkRDD、宽窄依赖、算子、数据倾斜高消息与采集Kafka基础、Flume基础中数仓分层设计、维度表、星型模型中场景设计日志分析、实时ETL、数据质量中这张考点地图能看出携程笔试的明显特点不追求单项技术的绝对深度而是要求你对整条数据链路有完整认识。从数据采集、离线计算到实时计算每一层都会涉及还特别看重Java基础。很多同学以为大数据岗只考大数据组件结果在Java集合和JVM上丢了分非常可惜。1.3 为什么按这个思路出题从OTA业务看笔试逻辑携程的业务是OTA在线旅游平台每天会产生海量的订单、搜索、浏览、支付日志。这些数据既要落到数仓做经营报表又要进Spark算推荐特征还要走实时链路做风控和价格监控。所以大数据岗位的日常工作基本就是围绕“数据采集→清洗→计算→服务”这条链路展开的。笔试这么出题本质是在用最低成本筛选出“真的见过数据”的人。很多同学准备大数据笔试时喜欢死磕Flink、机器学习类内容但在2019届那会儿携程笔试里Flink在选择题里会露个脸主体还是Hadoop生态。原因很简单生产环境主流还是Hive加Spark实时侧用Spark Streaming和Kafka已经能覆盖绝大多数场景。笔试考的是岗位所需的主流技术栈而不是学术界最前沿的方向。另一个值得注意的点是场景设计题通常和旅游业务强相关比如“如何统计某个热门目的地近一小时的搜索量”“如何设计酒店订单的实时风控链路”。这类题不是纯考技术而是在考察你能不能理解业务指标、能不能把技术方案落到业务场景里。所以备考时多想想技术怎么服务于业务比单纯背概念要有用得多。1.4 考前准备的三条主线如果现在让我重新准备这次笔试我会把精力拆成三条主线而不是无头苍蝇式刷题。第一条主线是Java和SQL基础每天保持固定时间的刷题量重点保证选择题不丢分第二条主线是Hadoop和Spark原理关键是真理解MapReduce流程、Shuffle机制、宽窄依赖而不是死记概念第三条主线是场景题练习去网上找真实的日志分析和实时计算需求自己动手写完整代码。这三条主线基本能覆盖笔试70%以上的考点。等主线内容都过了一遍再去做整套模拟题会明显感觉到做题速度和对题目的敏感度不一样。2. Hadoop与Spark核心考点原理题拿分的关键2.1 MapReduce执行流程与Shuffle机制MapReduce在选择题里几乎是必考内容。基础题会问“MapReduce默认的输入格式是什么”“Partitioner的作用是什么”简答题则会上升到“描述一个MapReduce任务从提交到完成的完整流程”。很多同学对选择题能轻松答对但一到简答题就写不清楚原因就是没有把流程串成一条线。完整流程可以记成四段。第一段是客户端提交Job到YARNResourceManager分配容器并启动ApplicationMaster第二段是ApplicationMaster根据输入分片数启动对应数量的MapTask第三段是MapTask读取分片数据执行map函数输出结果经过分区、排序、合并后写入本地磁盘第四段是ReduceTask拉取属于自己的分区数据经过归并排序后执行reduce函数最后写回HDFS。我的经验是答题时不要只罗列流程要把Shuffle单独展开讲因为这是阅卷人最希望看到的细节。Shuffle是Map输出到Reduce输入之间的数据流转过程涉及环形缓冲区、分区、排序、溢写、合并、拷贝、归并排序等环节。你能把这个过程说清楚基本就能证明你真正理解过MapReduce的原理而不是背了一个框架的名字。2.2 Spark作业执行流程宽窄依赖与Stage划分携程选择题里Spark的频次也很高常考的点包括RDD的两种依赖方式、Stage怎么划分、reduceByKey和groupByKey的区别。背过的人能答对选项但简答题基本都会卡住因为简答题会问“一个Spark作业从提交到执行的完整流程是什么”。标准流程是提交Application后Driver创建SparkContextDAGScheduler根据宽依赖划分Stage然后TaskScheduler把TaskSet下发到Executor执行。要真正理解Stage划分关键在宽窄依赖。窄依赖是父RDD的一个分区只被子RDD的一个分区使用可以管道化执行效率高宽依赖是一次Shuffle父RDD的数据可能会分发到多个子分区所以需要在宽依赖处切断Stage。这里有一个高频对比题reduceByKey和groupByKey的区别。reduceByKey在map端会先做一次本地合并落盘和网络传输的数据量小很多groupByKey则是把所有原始value全部传到下游再合并数据量一大就容易OOM。笔试如果出“如何优化groupByKey”标准答案就是在map端尽量做预聚合本质就是reduceByKey的思路。2.3 数据倾斜必考的调优题怎么答才完整数据倾斜是大数据笔试和面试的“常客”携程笔试也绕不开。常见题目是一个Spark任务跑了几小时还没结束某个Executor内存爆了怎么排查和解决。这道题有固定解法套路按下面几层回答基本能拿满。先定位。在Spark UI里查看各个Task的耗时和数据量找到处理数据量远大于平均值的Task这一步的目的是证明你不是在瞎猜而是有排查方法的。再分析原因最常见的三个原因是key分布不均、业务数据本身存在热点、join操作时小表大表关联存在空key或脏数据。最后给方案对应不同原因给不同解法。如果空key没有业务意义直接过滤掉如果是热点key用加盐两阶段聚合对热点key加随机前缀做两轮聚合如果是大表join小表用广播变量把小表广播出去避免Shuffle如果还不行就调整spark.sql.shuffle.partitions或reduce端分区数提高并行度。这里要注意答题时不要只说方案名要写清“为什么要这么做”。比如加盐两阶段聚合本质是把一个热点key拆成多个随机key让数据先分散到不同Task各自聚合一次再去掉前缀做第二次聚合这样单个Task的负载就降下来了。你把原理讲清楚考官才会觉得你是真的解决过这类问题。2.4 数仓建模与分层思路数仓相关考题在携程笔试里经常以选择题和简答题的混合形式出现。选择题爱考星型模型和雪花模型的区别、维度表和事实表的概念简答题则可能是“你如何设计一个订单数据仓库的分层结构”。答题时我会按四层来写。ODS层存放原始数据与源系统保持一致不做过多的清洗DWD层做清洗去重、维度退化、标准化字段形成明细事实表DWS层按主题聚合比如订单主题、用户主题的天级汇总ADS层面向具体应用比如报表、接口、大屏展示。这个分层顺序不要颠倒因为每一层的职责是很清晰的。一个很好的答题抓手是“维度退化”。在DWD层把常用的维度字段直接冗余进事实表比如把商品名称、分类直接存在订单明细表里查询时就不用反复join维度表。这也是星型模型在数仓中比雪花模型更流行的原因查询路径更短性能更好。笔试时能主动提到这个点会很加分。3. SQL与编程题实操三大高频题型的得分技巧3.1 SQL窗口函数连续登录与留存率SQL编程题几乎必考窗口函数最常见的题目是“求每个用户的连续登录天数”。这道题有固定套路核心就是用row_number生成行号再用登录日期减去行号得到一个分组标识。如果日期连续减出来的值相同如果中间有断档减出来的值就不同按这个分组标识聚合就能算出连续天数。SELECT user_id, MAX(continuous_days) AS max_continuous_days FROM ( SELECT user_id, login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn, DATE_SUB(login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date)) AS grp FROM ( SELECT DISTINCT user_id, login_date FROM user_login_log ) t1 ) t2 GROUP BY user_id, grp;这个写法里有一个细节很多人会忽略必须先对用户登录记录做DISTINCT去重。因为真实的登录日志里同一天可能有多条记录不去重的话日期减去行号的结果就是错的。笔试里你把这层写出来阅卷人会认为你有真实处理数据的经验。留存率的题也经常出现比如“计算7月1日新增用户在7月2日和7月7日的留存率”。基本思路是一张新增用户表join一张活跃用户表用日期差判断用户在第几日活跃然后按新增日期聚合。这类题的关键在理解留存率的业务口径分母是某日新增用户数分子是该批用户在指定日期仍然活跃的人数。3.2 手写代码题TopN与分组统计携程笔试的编程题一般可以用Java、Python或Scala写平台会跑几个基础用例来判分。和纯算法题相比大数据方向的编程题更贴近数据处理场景但算法基本功仍然重要尤其是TopN这类经典题。一道典型的题目是“有一个超大日志文件每行是一个访问记录包含IP、访问时间、请求URL统计访问量最高的Top 10 IP”。思路很简单先逐行读取并统计每个IP的计数再用PriorityQueue维护一个大小为10的最小堆堆顶就是当前最小的元素新元素比堆顶大就替换堆顶最后堆里剩下的就是Top 10。import java.io.BufferedReader; import java.io.FileReader; import java.util.*; public class TopN { public static void main(String[] args) throws Exception { MapString, Integer countMap new HashMap(); try (BufferedReader br new BufferedReader(new FileReader(access.log))) { String line; while ((line br.readLine()) ! null) { String ip line.split( )[0]; countMap.put(ip, countMap.getOrDefault(ip, 0) 1); } } PriorityQueueMap.EntryString, Integer minHeap new PriorityQueue(Comparator.comparingInt(Map.Entry::getValue)); for (Map.EntryString, Integer e : countMap.entrySet()) { minHeap.offer(e); if (minHeap.size() 10) { minHeap.poll(); } } ListMap.EntryString, Integer result new ArrayList(minHeap); result.sort((a, b) - b.getValue() - a.getValue()); for (Map.EntryString, Integer e : result) { System.out.println(e.getKey() e.getValue()); } } }这里用最小堆而不是全排序是因为当数据量很大、key数量很多时堆空间固定为10内存可控时间复杂度从O(n log n)降到O(n log 10)。这个选择本身就是考察点你有没有根据数据量去选择合适数据结构的意识。3.3 场景题实战用Spark写日志分析场景设计题是携程笔试里最有区分度的一类其中“用Java编写Spark处理日志”是典型方向。比如给你一份服务器访问日志要求统计每个IP的访问次数和每个接口的平均响应时间。很多人能写出SQL版本但用Java配合Spark手写完整代码时就会卡壳因为涉及RDD算子的选择。下面是一段完整可运行的示例核心逻辑是读取日志、切分字段、过滤脏数据、用reduceByKey聚合、指定并行度、输出结果。import org.apache.spark.api.java.JavaPairRDD; import org.apache.spark.api.java.JavaRDD; import org.apache.spark.sql.SparkSession; import scala.Tuple2; public class LogAnalysis { public static void main(String[] args) { SparkSession spark SparkSession.builder() .appName(LogAnalysis) .master(local[*]) .getOrCreate(); JavaRDDString lines spark.read().textFile(hdfs://path/access.log).toJavaRDD(); JavaPairRDDString, Integer ipCounts lines .map(line - line.split( )) .filter(fields - fields.length 3) .mapToPair(fields - new Tuple2(fields[0], 1)) .reduceByKey(Integer::sum, 10); ipCounts.saveAsTextFile(hdfs://path/output/ip_count); spark.stop(); } }这段代码涵盖了笔试判分最看重的几个点读取数据源、切分字段、过滤脏数据、用reduceByKey聚合、指定并行度、输出结果。如果你在笔试时能写出filter那一步就已经超过很多直接切分不校验的选手了。因为真实日志格式非常脏字段缺失、空行、异常字符都会出现这是“有经验”的体现。3.4 编程题的时间分配与答题顺序编程题一共两道我建议按“SQL题优先代码题其次”的顺序做。SQL题只要思路对了写起来很快通常10到15分钟就能完成而代码题要考虑边界条件和编译环境时间不可控应该留出更充足的时间。如果两道题都比较难先把核心逻辑和思路写注释拿过程分比死磕一个用例要划算得多。在线笔试平台通常会在考试结束前自动保存代码但不会因为你的代码不完整就给分。所以哪怕最后没有完全跑通也要把伪代码或核心思路写在注释里让阅卷人看到你的思考过程。我在实际阅卷经验里见过不少代码没跑通但思路清晰的学生最终都拿到了面试机会。4. 架构与框架选型题用系统思维应对简答题4.1 Lambda架构与Kappa架构如何选型简答题里如果出现“请设计一个实时数据链路”大部分情况下绕不开Lambda架构和Kappa架构的对比。这题表面是考架构实际是考察你能不能根据业务场景做技术权衡。Lambda架构是经典套路一条离线链路批处理层负责全量数据的准确计算一条实时链路速度层负责低延迟的近似计算最后在服务层合并结果。优点是离线准、实时快缺点是两套代码要维护逻辑还可能对不上。Kappa架构则只保留实时链路用消息中间件的日志回放能力让实时计算引擎从头处理数据从而得到和批量计算一致的结果。它省掉了一套离线代码但要求实时引擎支持状态管理和历史回溯对技术栈要求更高。笔试答题时我的建议是不要只写定义要结合具体业务。比如携程的订单报表和数据分析用Lambda更稳妥因为离线结果要能回溯且准确而日志监控类场景数据量大、时效性要求高、对结果精确度容忍度更高Kappa更合适。这样答说明你不是背名词而是真的理解了两者的取舍。4.2 Kafka消息可靠性的完整答题思路Kafka在实时链路里几乎是核心组件携程笔试对Kafka的考点集中在消息可靠性。选择题会问“生产端acksall和acks0的区别”“consumer怎么保证不丢数据”场景题则把Kafka作为数据中枢考察整个链路的数据完整性。要答好Kafka可靠性可以从三个环节下手。生产端设置acksall并开启retries保证消息写入所有副本成功后才返回避免leader切换时消息丢失存储端保证topic副本数不少于2min.insync.replicas适当设置防止ISR列表中只剩一个副本时强行写入消费端先处理业务再提交offset或者使用手动提交避免消费到一半进程挂了却已经提交offset导致重启后跳过这段数据。这里特别想强调一点很多同学背了配置项但不知道怎么用。笔试里如果问“怎么保证Kafka不丢消息”你只要把生产、存储、消费三个环节各自对应的手段写清楚不管题目怎么变基本都能覆盖到。因为分布式系统的可靠性问题本质上就是数据在链路每个环节都不允许凭空消失。4.3 HDFS、HBase、Redis的存储选型存储选型是选择题和简答题的常客常考的是三类主流存储的区分。HDFS适合大文件批量读写吞吐量高但随机读写性能差不适合低频次的点查HBase适合超大表的随机读写支持行级查询适合订单流水、用户行为明细的存储Redis是纯内存存储延迟低适合缓存、热数据、计数器和排行榜。笔试里如果出这样一个场景“某业务需要实时展示热门旅游目的地的搜索量排行榜”最优解是用Redis的ZSetscore为搜索次数member为目的地ID。如果你答HBase或者MySQL说明你没有考虑到这个场景对“高并发实时写入有序读取”的要求。所以答题时先判断场景的关键字实时、高并发、排行榜、缓存这些词一出现就往Redis想海量存储、随机查询、按rowkey读取就往HBase想批量离线分析、全表扫描就往HDFS和数仓想。4.4 集群部署与资源估算题关于集群部署策略笔试虽然很少考到特别细的部署操作但集群规模规划、YARN资源调度的选择题偶尔会出现。比如“一个100台机器的集群内存每台64GB怎么分配NodeManager内存和Container内存”这类估算题。答题思路是先给系统预留20%左右的内存再用剩余内存大致估算每个Container的内存和并发数。比如每台机器64GB预留约12GB给系统和HDFS等常驻进程剩下约50GB分配给Container如果每个Container分配8GB那单节点最多跑6个并发Container。我没有遇到过需要精确到个位数的题但“预留系统资源”“控制单节点并发数”这两个原则永远不会错。这类题的意义在于考察你有没有“资源规划”的概念。很多同学只学过怎么提交Spark任务不知道集群资源是有限的更不知道任务提交时要考虑资源隔离。你把这些写出来哪怕数字估算得不够准思路对了也能拿分。5. 容易丢分的地方与冲刺备考建议5.1 高频丢分点复盘根据后来实际走完秋招流程的经验结合和同学之间的交流我总结出几个高频丢分点。第一个是选择题只记选项不记原理。很多同学刷过牛客题目看到“HDFS默认副本数是多少”能选3但问“为什么默认是3”就答不上来。笔试里简答题不会给选项这就暴露了。第二个是数据倾斜只答“加盐”。加盐是思路不是完整方案要写清楚两阶段聚合怎么做、加盐前缀怎么加、第二阶段的key怎么还原缺一步都不完整。第三个是SQL不写DISTINCT。日志表原始数据带重复直接开窗算连续天数结果一定是错的这一分丢得特别冤。第四个是手写代码忽略异常情况。比如日志行按空格切分后字段长度不够或者字段为空不校验就直接取下标运行直接报错。第五个是简答题只写概念不写场景。例如“请介绍Spark Streaming”一句话“Spark Streaming是准实时的流处理框架”肯定不够需要描述它通过微批次处理数据、容错机制是checkpoint、以及和Kafka的整合方式最好再带上一个业务场景。5.2 冲刺阶段的时间安排冲刺阶段不要贪多最后一到两周按下面这个节奏来。第1到3天把所有大数据组件原理用“给自己讲一遍”的方式过掉包括HDFS读写流程、MapReduce执行流程、Spark调度、Kafka可靠性讲的时候如果卡壳就是没掌握。第4到6天集中刷SQL窗口函数题连续登录、留存、复购、TopN至少各练五道直到能不翻书写出正确代码。第7到8天手写Java或Python的TopN、分组统计、字符串处理保持代码手感。第9到10天看场景设计题的答案重点关注“为什么”而不是背答案。最后一天把高频简答题自己默写一遍严格控制每道题的时间模拟真实考试节奏。这样安排的好处是梯度科学先原理后SQL再代码最后场景前一步是后一步的基础。5.3 笔试当天的应试技巧在线笔试时间紧张选择题不要死磕遇到不会的先标记做完后面的题再回来。编程题先写思路注释再写核心逻辑最后补边界处理。SQL题如果一时间想不到窗口函数的写法就用最朴素的子查询先写一版能跑通的答案有分总比没分强。简答题一定要分点作答用“首先、其次、最后”或者“定位、分析、方案”的结构让阅卷人一眼看到你的逻辑框架。别写一大段文字阅卷时间有限分点作答会大大提高得分率。如果遇到不会的题就把你想到的相关知识点都写上去尽量靠边沾分空白才是最坏的结果。最后分享一个我验证过很多次的体会。很多人准备大数据笔试喜欢花大量时间追新框架、看源码、背API但携程这类公司的笔试题目其实一直在提醒我们同一件事数据链路中的基础问题才是真正的分水岭。Hadoop的Shuffle、Spark的宽窄依赖、Kafka的ack机制、SQL的窗口函数——这些内容看起来“老”但无论技术怎么迭代只要你真的理解它们换什么框架都能快速上手。如果你正在准备秋招我个人建议把刷题时间的一半放到场景题上。因为选择题大家都能刷SQL基础也拉不开太大差距真正让面试官觉得“这人能干活”的永远是你能不能在真实数据场景里做出合理的技术选择。多拿一些真实的日志分析、实时统计需求练手写完再复盘一遍收获会比单纯刷题大得多。希望这篇文章对你接下来的笔试有实际帮助。