三月份眼看春招就全面铺开了后台不少准备投数据开发工程师岗位的同学来问我携程集团的笔试到底怎么准备第一批题量大不大考的是纯SQL还是连Spark、Flink原理一起上说实话我过去几年参与过不少数据团队的招聘流程也帮人模拟评过很多份笔试答卷对这个岗位的考察套路算是比较熟悉。这篇文章就把2025年春招携程集团数据开发工程师第一批笔试的考察逻辑、高频考点、刷题思路一次讲透另外附上完整的实战拆解和踩坑提醒。不管你是刚准备转行做数据开发还是已经在实习、想冲一把大厂offer这轮笔试的应对思路都值得你静下心来跟着走一遍。1. 先摸清岗位画像携程数据开发笔试究竟在筛什么样的人1.1 从业务形态反推考点在准备任何一场笔试之前我的习惯是先搞清楚这个岗位日常到底干什么因为考点一定是从岗位日常反推出来的。携程的核心业务是旅游出行包括机票、酒店、火车票、度假线路、商旅、景区门票等这些业务背后每天产生极其海量的订单流、用户行为流、库存变动流。数据开发工程师在携程这类公司里干的活大致可以分为三块一是建设数据仓库把散落在各个业务库、日志系统里的数据做清洗、结构化、分层加工二是搭建和维护离线与实时数据管道保证从业务库到数仓、从数仓到报表应用的数据链路稳定高效三是为业务方提供数据服务包括报表、指标体系、用户画像标签、算法特征等。此外跟算法团队配合做特征工程跟数据分析师配合做数据质量治理也都是日常工作的一部分。由此可以看出笔试的重点领域是很明确的SQL能力是绝对的基础门槛数据仓库建模和分层设计是专业分水岭大数据组件原理Hive、Spark、Flink、Kafka是区分只会写SQL和真懂数据开发的关键再加上一两道算法题检验编程基本功。这四块基本构成了试卷的主体。1.2 第一批笔试的整体结构与时间压力根据近几年头部互联网公司数据开发岗位笔试的通用形态携程的数据开发笔试通常是线上限时完成总时长大约在90到120分钟。题型一般可以分为三个平行的部分题型大致题量考察重点建议时间分配单选题/多选题15-25道数据仓库概念、Hadoop生态、Hive/Spark/Flink原理、基础Java/Python30-35分钟SQL编程题3-5道窗口函数、多表关联、去重、累加、连续问题、TopN40-50分钟算法编程题1-2道数组、字符串、哈希、贪心、DFS/BFS等20-30分钟这里必须提醒一句客观题里经常混入选非题就是选不正确的那一项这个非常阴险。很多人看到熟悉的知识点就手快选了正确答案结果题目问的是以下哪项是错误的。第一轮笔试刷人最多的往往不是不会做的题而是会做的题看错了问法。后面我会在每个章节里点出具体的高危陷阱。另外线上笔试的考试系统一般会切换页面检测甚至有的会要求开启摄像头所以考前要找一个安静的环境把通讯软件全部关掉保持网络稳定。这些细枝末节虽然不算智力考察但每年都有人因为这些低级问题翻车。2. SQL是生死线窗口函数与业务场景的组合拳2.1 为什么说SQL直接决定你能不能进下一轮我做过一个统计在数据开发岗位的笔试中SQL题的分值占比通常在三成到四成之间但它的区分度远比分值占比更高。因为客观题大家靠背八股文都能蒙对不少算法题很多人直接放弃唯独SQL是会就会、不会就是写不出来的硬功夫。阅卷时哪怕你的SQL只是思路对但语法有瑕疵往往也能得到部分分数而如果思路完全偏掉这一题基本就是零分。携程这种业务场景SQL题一定会结合旅游业务出常见的有统计每个城市的订单总量和环比增长率、找出连续N天有登录行为的用户、计算用户累计消费金额、查询每个酒店类目下销量排名前几的商品、分析机票订单和退改签记录之间的关联等。这些题表面看是业务分析题本质考的都是窗口函数。2.2 三个必须拿下的核心题型第一类累计类问题。比如计算每个用户从注册至今的累计下单金额这是在携程这种交易型平台里最常见的数据需求。解法很简单就是开窗累加SELECT user_id, order_date, order_amount, SUM(order_amount) OVER (PARTITION BY user_id ORDER BY order_date) AS cumulative_amount FROM user_orders ORDER BY user_id, order_date;这一题想拿满分有一个容易被忽略的细节窗口函数里的ORDER BY order_date需要跟ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW配合虽然在默认情况下SUM() OVER的窗口帧就是到当前行为止但有些线上判题系统对SQL方言的支持并不一致写上完整窗口帧规范反而更严谨。另外如果题目要求按自然月累计那就需要在PARTITION BY里加上月份字段改成分区键为user_id, month。第二类连续N天问题。这是互联网公司笔试里的常青树结合旅游业务就变成了找出连续3天浏览过携程酒店频道的用户。核心套路是用日期减去行号把连续日期归到同一个组WITH tmp AS ( SELECT user_id, visit_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY visit_date) AS rn FROM hotel_channel_visits WHERE visit_date IS NOT NULL AND user_id IS NOT NULL ) SELECT user_id, MIN(visit_date) AS start_date, MAX(visit_date) AS end_date, COUNT(*) AS continuous_days FROM ( SELECT user_id, visit_date, DATE_SUB(visit_date, rn) AS grp_date FROM tmp ) t GROUP BY user_id, grp_date HAVING COUNT(*) 3;这个思路第一次接触的人会觉得绕但想通了之后就很简单同一组连续日期每天减去它对应的行号得到的日期是同一个于是按这个差值分组就能切出连续段。需要注意两个细节一是如果有重复日期要先进行DISTINCT去重否则行号会错位导致本来连续的日期被拆成两组二是DATE_SUB在Hive、MySQL、PostgreSQL里的写法不完全一样考试前最好确认系统指定的SQL环境。第三类分组TopN问题。比如找出每个出发城市销量最高的3条机票线路。这类问题用RANK()、DENSE_RANK()、ROW_NUMBER()都能解关键在于搞清楚三者的区别因为判题系统往往对排序的并列情况有明确要求SELECT departure_city, route_id, sales_amount FROM ( SELECT departure_city, route_id, sales_amount, RANK() OVER (PARTITION BY departure_city ORDER BY sales_amount DESC) AS rk FROM flight_route_sales ) t WHERE rk 3;如果题目要求取前3条且并列只算一个名次用RANK()如果要求按行数取前3行、不管并列用ROW_NUMBER()如果要求并列算同一名次但后续名次连续递增用DENSE_RANK()。我见过太多人在这个细节上丢分明明SQL逻辑全对就栽在三个函数的语义差异上。2.3 SQL题里那些送命题笔试里还有一种常见考法是给你一段有问题的SQL让你找出报错原因或优化方向。这类题常见陷阱包括GROUP BY后面选了没分组的列、WHERE里使用了聚合函数、ON和WHERE的过滤顺序搞混导致关联结果不同、NULL值参与比较恒为UNKNOWN等。这里特别提醒一个关于NULL的坑统计订单金额平均值时AVG会忽略NULL行但如果你把NULL转成0再取平均结果会完全不同。题目如果问过滤掉未支付订单后计算退款率你要先想清楚未支付订单和已支付但未退款订单分别在什么表里、NULL表示什么含义。这种业务语义的判断题比你多会几个函数重要得多。3. 数仓理论与建模看似送分实则拉分的客观题板块3.1 维度建模的核心概念必须形成答题框架客观题里数据仓库部分的占比通常很大而且这些题的知识点非常密集。从往年真题规律来看维度建模是最核心的出题区域主要包括事实表和维度表的区别、星形模型和雪花模型的区别、缓慢变化维的几种处理策略、退化维度、代理键、事实表的粒度等。我建议你搭建一个清晰的答题框架而不是零散背知识点。比如拿到事实表相关题目先想到它的核心特征记录业务过程、每行表示一个度量事件、行数是天文数字、以可累加的数值度量为主而维度表则是描述业务过程的上下文包含文本属性行数相对少。星形模型用一句话概括就是中心一张事实表周围一圈维度表雪花模型则是把维度表进一步规范化拆成多层。关于缓慢变化维SCD也是高频考点第一种策略是直接覆盖旧值不保留历史第二种策略是新增一行用开始日期和结束日期标记有效期可以保留完整历史第三种策略是新增一列存储历史值只能保留上一次变化。笔试里最常见的问法是要统计某个酒店在过去三个月内价格调整的次数该用哪种SCD策略答案很明显是第二种。3.2 数仓分层ODS、DWD、DWS、ADS的边界要拎清携程这种规模的公司数仓一定是分层的笔试也一定会考分层的意义和各层职责。标准分层通常包括原始数据层ODS、明细数据层DWD、汇总数据层DWS和应用数据层ADS。这里有一个我在评卷时经常见到的误区很多人分不清DWD和DWS的边界以为DWD就是清洗后的数据DWS就是宽表。更准确的说法是DWD以业务过程为粒度保留最细的明细做一致性清洗和标准化比如把不同业务库里的日期格式统一、枚举值统一DWS则面向分析主题做轻度汇总比如按用户、按商品维度聚合出日成交额或者把多个维度的指标拼接到同一张宽表里。ADS则是直接服务于报表和大屏应用通常按具体业务需求定制。客观题常见的出法有给你一个加工场景问这个清洗逻辑应该落在哪一层或者给你一张表的字段列表判断它是事实表还是维度表。答这类题的关键是抓住粒度两个字一张表的粒度是什么决定了它属于哪一层。能对应到一行记录的原子业务事件就是DWD如果一行记录代表多个事件的汇总就往DWS靠。3.3 数据倾斜与一致性工程实践题的理论底子数据开发笔试中还经常出现关于数据倾斜、数据质量、调度依赖的题目。数据倾斜几乎是排查类题目的头号考点出题方式通常是一个SQL跑了很久如何定位原因并优化。你要能说出常见的倾斜原因一是JOIN时关联键有大量空值或热点值二是GROUP BY的键分布严重不均匀三是COUNT(DISTINCT)在某些引擎上的性能问题。对应的优化思路要能条理化答出先看执行计划确认倾斜发生在哪个阶段然后针对热点键做加盐随机拆分或者把大表拆成多个小任务并行处理空值键可以单独过滤后用随机值替换再关联COUNT(DISTINCT)可以改成先GROUP BY去重再COUNT或者用近似去重函数。这些不光是笔试答案实际工作中也是万能排查三板斧。4. 大数据组件原理Hive、Spark、Flink的知识密度4.1 Hive专题内外表、分区、文件格式一个不落Hive是数据开发工程师的日常工具笔试客观题几乎是必考的。常考的点集中在内部表和外部表的区别、分区表和分桶表的适用场景、常用文件格式的优缺点、Hive SQL转换为MapReduce的执行流程。内部表和外部表的区别最简洁的表述是内部表由Hive管理数据生命周期删表即删数据外部表仅管理元数据删除表不会删除HDFS上的底层文件。实际生产中数据湖或ODS层的原始数据一般使用外部表避免误删而在数仓内部加工产生的中间结果用内部表失真的可能性低。分区表这个点笔试喜欢问一张按日期分区的订单表查询时为什么必须带上分区条件。答案很好理解Hive本质上从HDFS读文件没有分区裁剪就得全表扫描文件量级是PB还是MB的差别。与之相关的是动态分区的概念插入数据时不手动指定分区值而是由SQL自动根据最后一列的值生成分区目录。但用动态分区要注意小文件问题如果分区数极多而且每个分区数据量很小会产生大量小文件后续读取时的NameNode压力和任务调度开销会非常高。4.2 Spark专题RDD的血缘、宽窄依赖、Lazy机制客观题里Spark的考察比Hive更有深度而且出题方式往往不是直接问RDD是什么而是给一段场景判断行为。高频知识点包括RDD的惰性求值与血统机制、转换算子和行动算子的区别、窄依赖与宽依赖、DataFrame和RDD的优劣势、发生Shuffle的场景。先说惰性求值。很多人在刚接触Spark时都困惑过为什么map和filter调用后日志里没有显示任务执行直到执行count或saveAsTextFile才有动静。因为转换算子只是生成新的RDD记录依赖关系真正触发计算的是行动算子。这个机制带来的好处是Spark可以做流水线优化把多个转换算子合并到同一个阶段也方便在真正计算前做逻辑优化。宽依赖和窄依赖的区分也是高频题。窄依赖每个父RDD分区最多被子RDD的一个分区使用例如map、filter、union宽依赖多个子分区需要同一个父分区典型操作是groupByKey、reduceByKey、join这会引入Shuffle。笔试里如果问某某算子是否会发生Shuffle你要牢记任何打乱数据重新分区的操作都会带来网络传输数据量大时这是性能瓶颈的核心来源。4.3 Flink专题事件时间、Watermark、Checkpoint必考近几年实时数仓越来越重要携程这类公司在交易风控、实时营销场景对Flink的要求很高所以笔试里Flink的出现频率也在上升。最常考的三块时间语义与Watermark、窗口类型滚动、滑动、会话、状态管理与Checkpoint的精确一次语义。先说时间语义。处理时间Processing Time是数据到达机器的时间事件时间Event Time是事件实际发生的时间对于订单这种天然存在网络延迟的数据必须用事件时间才能做准确的窗口统计。Watermark是一个处理乱序数据的机制本质是迟到数据的容忍水位线表示早于这个时间的数据可以认为已经全部到达可以触发窗口计算了。笔试里经常给出一串带延迟的数据流问你Watermark设为多少才能保证95%的数据被正确统计这需要理解Watermark的计算公式和乱序程度的关系。再说精确一次消费。这是FlinkKafka组合的经典考点Flink的Checkpoint机制会周期性地保存每个算子的状态和Kafka消费位点当任务失败重启时从最近一次成功的Checkpoint恢复状态和位点配合Kafka的幂等生产者与事务性写入可以实现端到端的精确一次语义。面试官和笔试都爱从一个细节切入Checkpoint的间隔设置太长会导致恢复时重复计算的数据量过大太短又会增加存储和IO开销如何权衡。所以这个点不是背概念而是要理解背后的成本逻辑。5. 编程题与算法题限时场景下的保分策略5.1 高频题型与现场思路推导数据开发岗的算法题整体难度略低于后端开发岗但也不能掉以轻心通常是LeetCode的简单到中等难度。结合近几年各大公司数据岗笔试的出题偏好最高频的是数组类、字符串类、哈希表和简单动态规划。以一道典型的出题方式为例给定一个整数数组找出数组中两个数之和等于目标值的下标组合。很多人第一反应是双重循环但你要知道笔试系统可能对数据规模有要求双重循环在数组长度超过1万时就会超时。正确的姿势是用哈希表存目标值与当前值的差一次遍历即可得到结果时间复杂度从O(n^2)降到O(n)。笔试题的判分通常按测试用例通过比例来计算这意味着你要主动考虑边界条件数组元素有负数、目标值是0、存在多组解时输出哪一组、空数组和单个元素数组的行为。把这些边界条件都处理掉的代码即使不是最优解也能拿到比裸暴力但对边界不加处理的代码更高的分数。5.2 时间不够时的答题顺序与本地调试技巧我见过不少笔试翻车案例共同原因都是死磕一道题导致后面全崩。合理的答题顺序建议是先快速把客观题做一遍不会的标记跳过不要反复纠结然后做SQL题因为SQL题思路相对固定得分性价比最高最后留30分钟左右做算法题。算法题如果卡住了有一个自救思路先写出严格按题意模拟的暴力解法保证核心功能正确再去考虑优化。测试用例通常有一组是小规模的暴力解法能通过这部分用例得分就不至于归零。另外很多在线笔试环境支持本地编译器测试建议在自己的IDE里先把样例跑通再粘贴进考试系统。千万注意不要直接依赖在线编辑器代码提示和缩进检查都不如本地IDE好用。还有一个小细节如果题目没有明确指定语言优先选择你最有把握手写出来的语言。这里说的有把握不只是会写语法而是你熟悉标准库里的常用数据结构和API。平时刷题用什么语言顺手笔试就用什么语言不要临时切换。6. 那些容易被人忽视的隐性考察点6.1 数据敏感性与业务理解很多人在准备笔试时只盯着技术知识忽略了携程这类业务驱动型公司对数据敏感性的考察。笔试中有些题目看起来是一道普通的SQL题但隐藏了业务理解的考察点。比如统计酒店订单的取消率时分母是全部订单还是仅包含已支付的订单分子是取消的订单数还是最终未入住的订单数日期口径是按下单日期还是按入住日期我在实际评卷时经常看到答卷里出现答案完全不同的两种情况但这两种答案单独看都逻辑自洽。这说明很多候选人缺少一个关键习惯在下笔之前先定义清楚指标的统计口径。口径没有定清楚不管代码写得多漂亮最终算出来的指标在业务上都是不可信的。所以答题的时候哪怕题目没有明确要求最好也在SQL注释里或解题思路里写明你的口径假设这个动作能让阅卷人一眼看出你懂业务而不是一个只会套模板的工具人。6.2 会SQL不等于会数据开发最后一个想认真强调的点笔试通过只是入场券真正的分水岭在后面。数据开发工程师说到底做的是让数据可信、可用、高效流动的工作。如果你只是刷熟了窗口函数、背熟了Spark源码层面的概念但说不清楚一个数仓任务从上游业务库变更到下游报表展示之间经历了哪些环节也不理解某个指标为什么连续两天波动那即使笔试通过后续面试也会被深挖到底。建议在等待笔试结果的同时自己动手做一个端到端的小项目比如搭建一个简化版的订单数仓用模拟数据生成订单表用Spark或Flink做清洗和加工落到Hive或Doris里再用SQL完成一个复购分析报表。这个过程中你会遇到真实的数据倾斜、重复数据、时区问题、空值过滤问题这些才是笔试题目背后真正想筛选的实战意识。我在实际带人的经验里发现一个规律那些笔试SQL写得非常标准的人往往在团队里也能最快定位线上数据问题的原因因为SQL的严谨程度就是一个人逻辑思维的投影。相反SQL写得松松垮垮、时对时错的人在后续做数据治理时通常也会埋下一堆坑。笔试只是一个开始2025年的春招竞争整体依然激烈但数据开发这个岗位的门槛是练出来的而不是背出来的。每天抽一到两个小时集中刷SQL窗口函数和数仓建模题坚持三周你的手感会完全不一样。祝你这轮笔试能顺利过关我们面试阶段见。