我不止一次被准备校招的同学问起大数据方向笔试到底考什么。说实话网上能搜到的具体题目信息非常零散大多是我记得考了XXX这种碎片。去年秋招季我完整复盘过一套携程2019届大数据方向的笔试题对照当时的技术栈和业务场景把每类考点背后的考察意图、需要用到的知识体系、以及实战中容易踩的坑全都梳理了一遍。今天这篇就当作一份详细笔记分享出来。这套题的参考价值在于它不是那种随意拼凑的题库而是非常贴合携程实际业务场景的一套组合。整张卷子覆盖了Java基础、Hadoop生态组件原理、数据仓库建模、算法与数据结构、以及部分概率统计题型以选择题、填空题、简答题和一道在线编程题为主。从这套题里能清楚看出一个OTA在线旅游平台的大数据团队到底希望招进来的应届生具备哪些底层能力。1. 从考题分布看携程大数据岗的能力要求先说整体感受这套笔试并不追求偏题怪题但它非常强调你真的用过、真的理解过这些东西而不是背几篇面经就能混过去。整张卷子大概能分成四个能力维度第一维度是Java基础与并发编程。携程的核心业务系统尤其是交易、订单、价格相关的链路长期以来都是Java技术栈。就算你进来做的是大数据开发日常要写Spark作业、要维护Flink任务底层跑在JVM上这一点不会变。笔试题里会直接出现HashMap在并发场景下可能出现的问题、线程池核心参数的行为、volatile和synchronized的区别这类题。这些不是为了为难你而是他们真的遇到过因为并发处理不当导致的线上事故。第二维度是Hadoop生态组件的工作原理。MapReduce的Shuffle过程、Hive的SQL转化为MapReduce的流程、HDFS的读写机制、Kafka的消息投递语义这几大件是必考范围。而且考察方式很少是直接问请简述HDFS写流程更多是给你一个具体场景比如当DataNode节点宕机时HDFS写入会发生什么或者如何解决Hive数据倾斜问题。这类题目如果只看过原理没有实际调优经验答起来就会很虚。第三维度是数据仓库建模与数据治理。这一块容易被准备面试的人忽略但恰恰是携程这类重视数据应用的公司考察的重点。题目会涉及维度建模理论星型模型、雪花模型、事实表和维度表的区别、缓慢变化维的处理方式以及数据质量校验的策略。结合对于大数据而言最基本、最重要的要求就是减少错误、保证质量这个说法数据采集、清洗、校验链路里的问题笔试中也会以场景题的形式出现。第四维度是算法与数据结构。除了那道在线编程题之外选择题里也会穿插时间复杂度的判断、常见排序算法在特定场景下的选择、海量数据TopK问题的解法思路。难度大概在LeetCode中等题以下更偏向于考察基础的扎实程度。从这套卷子能反推出来的核心能力要求是基础扎实、真的动手跑过任务、对数据质量和数据应用有概念。这不是靠刷题能速成的需要系统过一遍大数据组件的原理和实战。接下来我把每个模块的考点和对应经验展开讲。2. 大数据组件原理笔试里的高频硬骨头2.1 Hadoop HDFS与MapReduce不只是背流程HDFS的读写流程是笔试的常客。但携程的题里很少会让你平铺直叙地默写而是会问当客户端向HDFS写入数据时如果某个DataNode写入失败整个过程如何处理。这个问题的考点其实是在Pipeline管道机制上客户端把数据包推给第一个DataNode再由它转发给下一个形成一条管道。当某个DataNode发生故障上游节点会收到异常此时NameNode会重新分配一个新的DataNode接替并让客户端从断点处继续写入。如果你只在文档里看过这个过程大概率会漏掉已写入的副本如何同步这个细节。MapReduce的Shuffle也是出题重灾区。笔试会考分区Partition、排序Sort、合并Combine、归并Merge这几个阶段的先后顺序以及环形缓冲区的默认大小一般是100MB达到阈值80%会触发溢写。我建议你在准备这类题的时候不要死记数字而是去搞清楚每个步骤为什么存在。比如排序的意义在于让Reduce端拿到的数据按键有序这样合并相同Key的效率才高分区的作用是让相同Key的数据进入同一个Reducer保证全局聚合的正确性。有一道题我记得很清楚给了两个MapReduce作业第一个输出作为第二个输入问第二个作业的Map输入格式是什么。答案是SequenceFileInputFormat可以读取第一个作业的输出。这考的其实是MapReduce作业链路的衔接在实际离线数仓ETL里非常常见。一个日报任务常常要串联三四个MapReduce子任务中间结果用SequenceFile或Parquet落地比用文本格式省很多IO和存储。2.2 Hive与数据倾斜不只会写SQL还要知道为什么慢Hive的题目一般分成两层第一层是SQL本身比如row_number() over (partition by)和group by的差异第二层是SQL底层如何跑成MapReduce。笔试中问得比较多的是Hive中一个简单的SELECT COUNT(*) FROM table底层会执行几个MapReduce任务这类题。更深一层的考点是数据倾斜。选择题里出现过一个典型场景一张订单表按城市id做group by上海、北京、深圳这几个城市的数据量远大于其他城市导致Reducer任务长时间跑不完。很多人背过加盐打散再聚合这个方案但笔试如果问如何在不改变最终结果的前提下解决倾斜光背概念就答不全面。正确的做法是对倾斜的Key做加盐比如在Key后面拼接随机后缀先做一次局部聚合再按原始Key做第二次聚合。这个方案要注意业务正确性如果涉及SUM而不是COUNT DISTINCT需要套两层来处理否则容易算错。这里有一道让我印象深刻的简答题给了两张表一张订单事实表几亿行一张用户维表几百行问用Hive怎么做Join效率更高。答案是MapJoin也就是把小表加载到每个MapTask的内存里避免Shuffle。这个知识点现在看起来是基础但在当时的笔试里很多人只记得大表join小表要优化却说不清楚优化的原理是把维表DistributedCache到每个节点上。这提醒我们准备笔试时多问一步为什么比多背十个方案有用得多。2.3 Spark与Kafka流批一体的考察思路虽然2019届的正式岗位多数还是以Hive和MapReduce为主Spark和Kafka已经被大量引入生产环境携程笔试也明显加大了对这两块的考察权重。Spark这边高频考点是RDD的宽依赖和窄依赖、持久化策略的选择、以及Spark SQL和Hive SQL的执行差异。有一道选择题问以下哪个操作会产生Shuffle选项有map、filter、groupByKey、union。答案是groupByKey因为它在对Key分组时需要把相同Key的数据汇聚到同一个Executor。这里容易混淆的是union很多人以为union也需要Shuffle其实RDD的union只是逻辑上的合并不会移动分区数据。这个点确实要在实际写作业时调试过DAG图才会印象深刻。Kafka的题基本围绕消息模型Partition的作用、Consumer Group的Rebalance机制、消息不丢失的三个层级Producer端、Broker端、Consumer端分别怎么做。有一道场景题某业务需要保证日志数据不丢但允许少量重复问Producer端设置acks为多少合适。答案是acksall或者-1同时开启retries和enable.idempotence。笔试里如果只答设置副本数大于1是拿不全分的因为acksall意味着Leader和所有ISR副本都写入成功才返回这才是生产端不丢消息的关键。携程这种体量的OTA平台实时计算链路非常长用户在前端产生行为日志通过Nginx收集到Kafka再用Spark Streaming或Flink做实时ETL最后落入ClickHouse或Druid供报表查询。所以Kafka的题目不只是考API还会顺着这个生产链路来出题。这就是为什么复习时不能只盯着组件本身还要理解它在整个数据链路里的位置。3. 数据仓库建模题笔试里最容易被低估的拉分项3.1 维度建模理论的活学活用说实话很多准备大数据笔试的同学把大量时间花在刷组件原理上对数据仓库建模这一块比较轻视。但从我前后几年的笔试经验来看数仓建模题恰恰是区分度很大的部分刷过题和没刷过题的人差距非常明显。维度建模的基础题是星型模型和雪花模型的区别。携程笔试的考法更实际给出一个酒店订单业务场景包含订单事实订单号、用户ID、酒店ID、入住时间、离店时间、订单金额、订单状态以及酒店维度酒店名称、城市、星级、品牌、用户维度用户ID、注册时间、会员等级问采用星型模型如何设计表结构。这里面有个隐含考点事实表只存外键和度量值不要冗余维度的描述信息。很多人会把酒店名称、城市这种维度属性直接塞进事实表这在笔试中会被扣分。其实在实际生产数仓里星型模型确实是最常用的因为它的查询性能好、理解成本低。携程这种业务线复杂的公司数仓层会分得非常细DWD层做明细清洗DWS层做主题汇总ADS层做应用指标。笔试不会直接考分层的命名但会通过从ODS到DWS需要做哪些处理这类问题来考察ETL的设计思路。3.2 缓慢变化维容易丢分的实操题缓慢变化维SCD是我觉得这套笔试里最有含金量的一道题。题目大概是用户维表中用户的会员等级会升级问如何处理这种历史变化。选项涉及SCD1直接覆盖、SCD2保留多条记录并加生效区间、SCD3保留当前值和上一个值。正确做法要看业务需求如果数仓只需要分析用户当前等级SCD1就够了但如果要分析用户升级前后行为的变化就必须用SCD2给维度表增加维度开始日期、结束日期、当前标识这几个字段。携程的会员体系是会直接影响订单转化率和用户粘性分析的所以他们很看重这种细节。这种题在笔试里不会明说请设计SCD策略而是把业务场景描述出来让你做决策这时候如果没有实际做过数仓模型设计就很容易选错。我的经验是遇到变化维相关的题先判断分析需求要的是当前快照还是全历史轨迹再判断数据量级最后再选策略。笔试考的是判断逻辑面试官不会要求你背出SCD4的定义但他们希望看到你能根据业务场景说出理由。3.3 数据质量与校验机制大数据岗位的隐形门槛摘要描述里有一句非常关键的话对于大数据而言最基本、最重要的要求就是减少错误、保证质量。那么大数据收集的...。这句被截断的话实际上点出了大数据领域最核心的一个隐性门槛——数据质量。这套笔试里有一道简答题是数据同步任务每天凌晨跑完数据量比前一天少了20%请列出排查思路。这类题在笔试里考察的不是一个标准答案而是你的排查链路是否完整。我的建议是分三层来答第一层检查同步链路本身源端表是否有数据、同步任务日志是否报错、同步延迟是否导致未同步完全第二层检查目标表是否有分区未生成、数据是否被覆盖第三层检查数据特征是否存在大量去重或者上游业务表本身有清理。把排查链路写清楚比堆砌一堆工具名要得分。数据质量校验这块笔试如果深挖会涉及单表校验行数、主键唯一性、空值率、跨表校验关联表指标对比、波动阈值告警。携程这类OTA企业订单金额汇总差一分钱都是严重事故所以他们格外看重你有没有质量校验的思维。4. 算法与Java基础决定笔试上限的部分4.1 海量数据算法大数据岗位的特色考点一般技术岗笔试的算法题是LeetCode风格大数据岗位的算法题则更偏向海量数据处理。这套题里出现了一道非常典型的题目一个文件里有100亿个整数内存只有1GB如何找出出现次数最多的前100个数。这道题的思路可以拆成两步。第一步是分而治之用哈希取模的方式把100亿个整数映射到若干个小文件里保证相同的数一定会落入同一个小文件第二步是逐个处理小文件用哈希表统计文件内每个数的出现次数再在每个文件内找出Top100最后把所有小文件的Top100汇总做全局排序。这里有一个关键细节哈希取模的模数选择要保证小文件能被读入内存一般按内存大小估算1GB内存大概能处理5000万到1亿个整数的统计那100亿数据取模100或200都够。笔试选择题还会考到BitMap、布隆过滤器这类概率数据结构。有一道题问判断一个URL是否曾经出现过允许一定的误判率使用哪种数据结构最合适答案是布隆过滤器。这个考点非常典型大数据场景下精确判断往往需要巨大的存储用概率型数据结构可以用极小的存储代价换来可接受的误判率。顺带一提这道题如果放到系统设计面试里还会延伸到布隆过滤器的参数选择位数组大小m、哈希函数个数k、误判率p之间的关系一般是p越低m越大k约等于ln2乘m/n。4.2 Java并发与集合不是走过场而是保命项大数据岗位笔试考Java很多人不理解觉得我又不写业务代码考这个干什么。但携程这类公司的大数据开发写Spark/Flink作业本质上就是在写分布式Java程序。你在Executor里跑的每一个算子都是并发执行在多个JVM线程上的如果不理解线程安全、不理解并发容器线上作业出问题的时候基本无从下手。卷子里有一道经典题多线程环境下使用HashMap导致CPU 100%如何解决。答案涉及三种方案Hashtable全表锁性能差、ConcurrentHashMap分段锁/CAS部分锁、Collections.synchronizedMap也是全表锁。这道题如果深挖可以引出一个非常关键的面试加分项ConcurrentHashMap在JDK 7和JDK 8的实现区别JDK 8用CAS加synchronized锁Node节点锁的粒度更细。笔试如果只要求选择正确答案你知道选ConcurrentHashMap就够了但如果后续有面试环节一定要把底层实现也说清楚。线程池的题也考到了一个任务队列、核心线程数、最大线程数、拒绝策略当任务提交速度大于处理速度时线程池各参数的变化过程。核心是理解ThreadPoolExecutor的执行顺序核心线程满后任务进入队列队列满后再创建非核心线程直到最大线程数再满则触发拒绝策略。这个执行顺序和很多人直觉上想的先加线程再入队列不一样是个经典的易错点。4.3 在线编程题需要快速AC但别过度纠结在线编程题一般是一道中等难度的算法题携程这套题我记得是一道字符串处理相关的题目整体难度不大核心是考察你能否在限定时间内用Java或Python写出无Bug的代码。在线编程题的策略我建议是先暴力后优化。笔试时间本来就紧张大数据方向的选择题和简答题很花时间如果在线编程题一上来就想最优解很容易卡住。先把暴力解法跑通通过基础测试用例拿部分分再把核心优化点补上比如把内层循环用哈希表代替把重复计算用前缀和缓存。这跟实际工作中的做法是一样的——先让任务跑出结果再优化性能。5. 从一套笔试题反推出来的备战路线5.1 知识点优先级排序根据这套卷子的覆盖范围和权重我把校招大数据方向的知识点优先级从高到低排一下优先级知识模块典型考点复习建议P0Hadoop生态核心组件HDFS读写、MapReduce Shuffle、Hive SQL底层原理动手搭建伪分布式集群实际操作后再对照原理复盘P0数据仓库建模维度建模、事实表/维表设计、SCD策略找一个真实业务场景如电商订单完整设计一遍模型P1并发与集合HashMap并发问题、线程池参数、JMM刷并发编程题同时了解Spark Executor的并发模型P1海量数据算法分治、TopK、哈希、布隆过滤器刷LeetCode的TopK和哈希相关题目P2消息队列Kafka生产/消费原理、消息不丢失搭一个Kafka集群用命令行生产消费一次消息P2实时计算Spark Streaming/Flink基础跑通一个实时WordCount即可不用太深这个排序的核心逻辑是先保底再拔高。P0模块是笔试覆盖面最大、最容易出简答题的部分一旦丢分影响很大P1模块是区分度所在很多人挂在Java并发上P2模块考到就是加分项但投入产出比不如P0和P1。5.2 最有效的复习方式场景复现式刷题我见过很多同学准备大数据笔试方式是刷面经、背题。但我复盘这套题之后最大的体会是最好把知识点放到具体场景里复习而不是孤立地背概念。以Hive数据倾斜为例光是理解groupByKey会产生数据倾斜远远不够。你可以这样设计一个小项目本地生成一份模拟日志数据其中一个城市的日志占比超过80%然后用Hive或Spark写一个统计任务观察Reducer任务的耗时分布是否不均匀再实现一种倾斜解决方案对比优化前后耗时。这种场景复现式复习花的时间不多但印象极其深刻遇到笔试里的场景题时你脑子里浮现的不只是答案而是你实际处理过的画面。5.3 笔试中不会明说但隐藏分值很高的能力这里再额外说一个容易被忽视的点跨组件的数据链路理解能力。有些题表面上是问Hive但实际在考察你是否理解Hive和HDFS、YARN之间的关系有些题表面上是问Kafka但实际在考察你是否理解Kafka和实时计算框架如何衔接。这种组件间关系的题目在笔试里经常以组合形式出现比如一条用户行为日志从产生到最终进入BI报表经过了哪些组件每个组件承担什么职责。这个问题是整场笔试里最接近实际工作的一题。你在公司里做的所有事情本质上都是让数据更高效、更准确地在这条链路里流动。笔试的分数只能代表你知识的广度但真正决定你能否胜任这份工作的是你有没有能力把这条链路里的每个环节串起来思考。我当时准备校招时花了大量时间画这条链路图用一张纸把数据从源头到报表展示的每一步都写清楚包括每个环节用什么组件、可能出现什么故障、如何排查。这张纸在后续面试中帮了大忙因为几乎所有面试官的问题我都会在脑子里先定位到链路图的某个环节再具体展开。5.4 给备战校招的同学一个时间分配建议如果距离笔试还有两个月我建议按这样的节奏分配时间前两周主攻Hadoop生态原理重点是HDFS和MapReduce同时每天做两道LeetCode简单题保持手感。第三四周主攻Hive和数据仓库建模做一个小型数仓设计练习比如自己设计一个酒店订单主题的数仓分层模型。第五六周主攻Spark和Kafka把两者的核心机制和常见问题过一遍。最后两周进入刷题冲刺模式做往年笔试题查漏补缺重点复习Java并发和数据结构。如果是准备时间只剩一周的冲刺阶段那就抓大放小把HDFS写流程、MapReduce Shuffle、Hive数据倾斜、Kafka消息不丢失、维度建模基础、ConcurrentHashMap原理、海量数据TopK这几大高频考点过一遍再把在线编程的常用模板准备好。这些内容足够覆盖笔试里70%以上的得分点。从这套2019届的笔试题往前看大数据笔试的考察方向虽然每年在变但底层的逻辑一直没有变过你不是在考知道什么而是在考能不能在真实场景里解决实际问题。组件可能从MapReduce换成Spark再换成Flink数仓可能从离线变成实时但数据质量意识、链路理解能力、排查问题的思维方式这些才是真正让你在笔试和后续面试里站得住脚的东西。