“数据开发”这个岗位的笔试刷过题和没刷过题的人完全是两种体验。尤其是京东这种大厂的校招题覆盖面广、题型固定、细节陷阱多如果只看面经不去手写SQL、不真练算法考场会非常难受。这篇内容是根据我做过的大量数据开发笔试真题整理出来的拆解重点讲京东2019校招数据开发工程师笔试题背后的考察逻辑、高频考点、答题套路以及我踩过的坑。适合准备校招、社招转岗、或者想系统梳理数据开发知识体系的人。我对这套题的整体印象是它不追求偏题怪题反而特别看重基础功底。SQL/Hive占了很大比重大数据组件和数仓理论是简答题的常客算法编程题难度适中但很要求思路稳定。笔试能过的人不一定是刷题最多的但一定是对“为什么这么写”有清晰理解的人。1. 从京东笔试题看数据开发岗在筛什么1.1 数据开发笔试的整体结构先给大家还原一下京东数据开发工程师笔试题的大致结构不同年份会有微调但总体框架比较稳定客观题部分单选、多选覆盖Java基础、Scala基础、Hadoop生态、Linux命令、数据仓库概念。手写SQL题2到4道Hive SQL题考察窗口函数、行列转换、分组聚合、连续值统计等。编程算法题1到2道代码题可以用Java或Scala写考察常见数据结构和算法。简答题数据倾斜、数仓分层、任务优化等需要用文字把方案说明白。这种结构决定了你不能只刷算法也不能只看SQL两边都得稳。京东这类大厂的数据开发笔试核心要筛的是“能直接上手做数据加工的人”。所以SQL和Hive的执行逻辑、数据倾斜的处理、数仓分层这些实战概念比重往往比纯编程题还高。我观察到题目难度分布大致是这样的客观题整体基础但常设坑SQL题中等偏上算法题中等简答题是区分度最大的部分。很多人客观题和算法题做得不错却在简答题上丢分因为只背了概念没有形成自己的分析框架写着写着就变成了名词堆砌。1.2 这些年数据开发笔试风格的变化如果你把2019年前后的笔试题和近两年的对比会发现一个明显变化早期笔试偏重Hive SQL和Java基础考察点相对固定后来随着Spark、Flink在工业界大规模使用笔试开始加入流处理概念、Spark算子分类、状态管理等题目但核心还是没变都在考察候选人“处理数据的基本功”。数据开发这个岗位名字里带“开发”但本质上是数据仓库、数据管道、数据服务的建设者。京东的业务场景是典型的海量电商数据订单表动辄上亿行用户行为数据更是成百上千亿条所以笔试题非常强调处理大规模数据的能力。你在刷题时不要只满足于“能跑通”还要多想一步这段SQL在几十亿数据上会不会数据倾斜这个join能不能优化这种思维才是笔试要真正筛选的东西。有个很实在的建议准备数据开发笔试时把“我是在写一段可能跑在大规模集群上的代码”当作默认前提而不是“我是在做算法课作业”。带着这个意识去答题你的SQL写法、算法选择、简答论述都会明显更贴合大厂口味。2. SQL/Hive笔试里占分最高的硬核考点2.1 连续登录类题目窗口函数的经典应用连续N天登录是数据开发笔试里出现频率极高的题型京东也考过差不多的变体。我先说结论这类题的核心思路是用登录日期减去按用户分组的行号如果日期是连续的减出来的值就相同。我举个例子假设有一张登录日志表login_log(user_id, login_date)要求统计连续登录3天及以上的用户。SELECT user_id FROM ( SELECT user_id, login_date, DATE_SUB(login_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date)) AS diff FROM login_log ) t GROUP BY user_id, diff HAVING COUNT(*) 3;第一次接触这个解法的人通常会问为什么是DATE_SUB(login_date, 行号)我用一个通俗的话解释把每个用户的登录日期按顺序排好今天是第1天、明天是第2天如果用户连续登录那“日期增量”和“行号增量”是同步增长的两者相减就永远落在同一个值上一旦中间断了差值就会跳变。这个思路不仅用于连续登录还适用于连续签到、连续付费等任何“连续性度量”场景。这里有一个特别值得提醒的细节如果用户一天可能有多条登录记录直接查会出错。比如用户同一天登录了三次行号会多出来导致本该连续的记录被拆开。笔试中很多人栽在这个细节上。稳妥的做法是先对(user_id, login_date)去重再套窗口函数WITH tmp AS ( SELECT DISTINCT user_id, login_date FROM login_log ) SELECT user_id FROM ( SELECT user_id, login_date, DATE_SUB(login_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date)) AS diff FROM tmp ) t GROUP BY user_id, diff HAVING COUNT(*) 3;实际笔试里不一定要求你考虑得这么全面但你在答案里主动写出去重这一步会让面试官觉得你有生产环境意识。毕竟真实业务里的登录日志几乎不可能每天只有一条。2.2 行转列与列转行从SQL到Hive UDTF行转列是另一个高频考点本质上是把一维的长表变成宽表。京东零售场景里经常要把多个维度指标横向展开所以这类题几乎年年出现。一个非常经典的题目有一张成绩表score_table(user_id, subject, score)需要把数学、语文、英语三科成绩转成一行。SELECT user_id, MAX(CASE WHEN subject math THEN score END) AS math_score, MAX(CASE WHEN subject chinese THEN score END) AS chinese_score, MAX(CASE WHEN subject english THEN score END) AS english_score FROM score_table GROUP BY user_id;注意这里为什么用MAX而不是SUM因为每个用户每个科目只会留下一行用MAX取到唯一值逻辑更严谨。有人会写成SUM(CASE WHEN subject chinese THEN score ELSE 0 END)这种写法在“成绩”场景也能跑通但如果你转的是“点击次数”这种本身就可能为0的指标ELSE 0会导致无法区分“没有记录”和“真正为0”。所以我的习惯是能用MAX就用MAX不写ELSE保留语义的准确性。Hive环境下还有一种写法是用collect_list或collect_set配合concat_ws把多行聚合成一个字符串适合在结果里展示明细。列转行则更依赖lateral viewexplode。从笔试角度看理解explode的“炸开”作用以及lateral view的“侧写视图”作用是答这类题的核心。我提醒一句笔试里如果考到collect_list要注意顺序问题它是一个无序聚合函数想保证顺序需要配合sort_array或先排序后再聚合。这个细节在面试追问时经常被问到提前准备好会加分。2.3 TopN与去重面试官最常用的两种变体TopN问题在数据开发笔试里几乎是必考的。常见题目是“按部门找出薪资最高的前3名”。标准解法是用ROW_NUMBER()SELECT dept_no, emp_no, salary FROM ( SELECT dept_no, emp_no, salary, ROW_NUMBER() OVER(PARTITION BY dept_no ORDER BY salary DESC) AS rn FROM employee ) t WHERE rn 3;很多人会问ROW_NUMBER()、RANK()、DENSE_RANK()这三个窗口函数有什么区别我直接说结论ROW_NUMBER()不管是否并列都生成连续不重复的行号。RANK()并列时行号相同但下一个行号会跳跃比如两个人并列第一下一个人是第3。DENSE_RANK()并列时行号相同但下一个行号不跳跃紧接着是第2。笔试求“前3名”如果只取3条用ROW_NUMBER()如果“并列第1、第2这种概念允许用户上榜”要用RANK()或DENSE_RANK()。这个差异在真实业务里影响很大比如排行榜场景就不能随便用ROW_NUMBER()否则并列第一的两个人只显示一个。去重类题目往往会和ROW_NUMBER()结合比如“取每个用户最新的一条订单记录”SELECT user_id, order_id, order_time FROM ( SELECT user_id, order_id, order_time, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY order_time DESC) AS rn FROM orders ) t WHERE rn 1;这个思路比传统的“先group by max(time)再join回来”更简洁而且在MySQL 8.0、Hive、Spark SQL、Flink SQL里都通用。准备笔试时我强烈建议把窗口函数相关题目全部手敲一遍不要只看不写因为窗口函数的语法在真实环境里最容易出错一不小心就漏掉OVER子句里的分区字段。2.4 SQL题踩坑清单SQL题失分往往不是不会而是细节没注意。我把多年刷题和实际评审中常见的问题整理成一个清单供大家参考字段别名子查询里用了别名外层查询引用时大小写不一致或者没有加引号导致解析报错。Group By 遗漏SELECT里出现的非聚合字段没有全部放进GROUP BY这在Hive里会报错在MySQL里却可能“侥幸”通过笔试时用Hive语感写更稳妥。去重意识一对多场景没先做去重结果多出重复行。日期格式日期被当成字符串处理用DATE_SUB或DATEDIFF时格式不统一导致计算结果错误。边界条件连续N天里的N1时逻辑不成立TopN里的N大于实际数据量时结果不报错但可能不符合预期。性能意识能先WHERE过滤再JOIN就不要先JOIN再过滤虽然笔试不追求执行计划但简答时能体现出你懂Hive的执行流程。SQL题答题时我会先写一遍完整答案再倒回去检查有没有“自然连接会产生笛卡尔积”这类隐患。很多看一眼就会的SQL题真正动笔时反而容易漏掉PARTITION BY里少个字段这种低级错误在笔试里非常致命因为机器判题直接看结果对不对。3. 大数据组件与数仓理论简答题不能只会背概念3.1 HDFS、MapReduce、Spark、Flink到底怎么区分笔试简答题里“说说HDFS和MapReduce的关系”“Spark和MapReduce有什么区别”这类问题出现频率很高。它考的不是你能不能默写定义而是你是否真的理解它们在大数据链路里的位置。我用生活化类比来解释如果把处理海量数据比作在一家大型图书馆整理书籍HDFS就是图书馆的仓储系统负责把一箱箱书分散存放在不同楼层的书架上每一箱还有编号和备份防止丢失或损坏MapReduce和Spark则是整理书籍的工作流程前者像一个“一板一眼的老员工”每次都要先从一楼把所有书看一遍再回工位整理产出结果后又得回一楼再搬下一批效率不高但可靠后者像一个“手脚麻利的年轻人”尽量把书在架子上就地分类能少搬运就少搬运明显快很多。具体到笔试题里你至少要能说出这几个要点HDFS分布式文件系统负责存储。核心思想是把文件切块多副本存储在不同节点上提供容错能力。面试官常问默认副本数是3这个是基础知识。MapReduce第一代分布式计算模型分为Map阶段和Reduce阶段中间结果落盘因此慢。但也正是因为“每一步都落盘”它极其稳定适合超大离线任务。Spark内存计算框架把中间结果尽量放在内存而不是磁盘性能大幅提升。DAG有向无环图、RDD弹性分布式数据集、Stage划分这些概念很容易被放到多选或简答里。Flink真正的流处理框架它的核心模型是“无界数据流”事件驱动、有状态计算、支持精确一次语义。如果笔试里问“实时计算选型会选哪个”那基本是考 Flink 的概念。很多人分不清Spark和Flink一个最简单的记忆点Spark擅长做“微批次”处理把流切成一堆小批Flink是“真正的流式”来一条处理一条延迟更低状态管理更完善。这个区别不用写得多复杂但一定要点出来。前几年面试官可能会更关注Spark但近几年Flink相关题目越来越多因为实时数仓、实时风控这些业务都已经大面积用Flink了。3.2 数仓分层设计ODS到ADS每一层在干什么数仓理论是数据开发笔试的另一大重点京东这类电商公司尤其爱考。题目通常不会让你设计一套完整数仓而是问“为什么数据仓库要分层”“ODS、DWD、DWS各层的作用是什么”。如果你只说“分层为了管理方便”那基本等于没答。我的回答思路会是这样数仓分层是为了“让数据从原始到可分析”的过程变得可管理、可追踪、可复用。ODS层操作数据存储层这一层直接对接业务库binlog、日志文件、消息队列把原始数据原封不动地拉过来。它就像图书馆的“入馆登记处”所有书进来先登记哪怕内容还没整理。DWD层明细数据层对ODS的数据做清洗、过滤、去重、维度补充、格式标准化保留最细粒度的业务事实。比如订单表在ODS可能拼着各种状态值到DWD要拆成清晰、可靠的订单明细宽表。DWS层汇总数据层面向业务主题做轻度汇总比如用户维度、商品维度、店铺维度的累计指标按天或按小时聚合。ADS层应用数据层面向具体报表、大屏、BI查询做高度定制化的分析结果输出。如果你在简答题里只是依次写完这四层的定义可能只能拿到一半分。想拿高分要补充两件事第一层与层之间的依赖关系是严格的“单向依赖”上层只能依赖下层不能出现DWS直接读ODS这种跳层行为。否则数据血缘混乱出了问题极难追踪。第二每一层的存储和计算成本不同ODS层往往用压缩率高的格式DWD层要考虑到查询效率DWS层和ADS层则要设计合适的partition、bucket和索引。能聊到这一层说明你具备“成本意识”这是很多应届生容易忽略的。我在实际笔试中遇到过一个加问题“如果底层数据发生变化你如何保证最终应用层的数据准确”这其实考的是数据血缘和数据质量。你只需要说清楚每层有自己的数据校验规则、任务失败要重跑、并且通过血缘关系找到下游影响范围基本就能过关。3.3 数据倾斜答好这一题能拉开明显差距数据倾斜简答题在实际面试和笔试里出现频率极高是数据开发笔试最重要的简答题之一。京东海量数据场景下数据倾斜几乎是每天都会遇到的问题所以这题答得好面试官会默认你有点实战经验。什么是数据倾斜一句话解释当某个Key的数据量远大于其他Key时负责处理这个Key的Reduce任务或Spark Task要处理的数据量远大于其他Task整个作业的完成时间被这个“最慢的Task”拖住甚至导致OOM。这就像快递分拣时某一片区的包裹特别多其他快递员都下班了这个片区的快递员还在加班。常见的解决思路我按场景整理笔试时你可以挑选合适的说法展开MapJoin小表join大表时把小表广播到每个Map节点避免Reduce阶段的数据倾斜。适用于“大表join小表”场景。两阶段聚合先加随机前缀打散Key局部聚合一次再去掉前缀做全局聚合。适用于“group by某个倾斜Key”的场景。单独处理倾斜Key如果某个Key真的需要单独业务处理就把倾斜Key拆出来单独计算其他Key走正常流程。过滤空值或无意义Key很多时候倾斜是因为空值、默认值这种“无效Key”导致的直接把异常值过滤掉任务立刻恢复正常。调整并行度增加Reduce数量或Task数量能缓解但无法根治更适合作为辅助手段。答题时我会先说“定位现象”再说“分析可能原因”最后给解决方案。这个思路比直接背答案更像实战。解释原因时可以提到JOIN字段的值分布不均、GROUP BY字段分布不均、以及count(distinct)因为排他性无法局部聚合导致的数据倾斜。3.4 理论题回答框架针对数据开发笔试里的理论简答题我总结了一个通用的回答结构大家可以直接套用一句话定义先用最精炼的语言说清楚是什么。解决什么问题它出现的原因和痛点。核心机制/原理用两三点展开核心实现。实际方案/做法给出具体可执行的动作不要只说概念。效果与局限说明它解决了什么又可能带来哪些新问题。以“HDFS为什么不适合存储大量小文件”为例用这个框架答就是一句话定义HDFS适合大文件的顺序读写不适合大量小文件原因是每个文件、目录、块都要在NameNode内存里维护元数据小文件多了会撑爆NameNode内存解决思路是合并小文件比如用SequenceFile、Har或者Hive里设置小文件合并参数最后说下合并可能产生的问题比如压缩格式变化会影响下游读取。这个框架保证了你的答案结构清晰且有深度而不是零散地蹦出几个知识点。4. 编程题与基础题数据开发的“内功修炼”4.1 数据开发笔试中的算法题定位数据开发的算法题不如纯后端工程师那么难但也不能掉以轻心。京东2019年这批笔试涉及的编程题整体风格偏向“常用数据结构 基础算法”不会出太偏的动态规划但链表的反转、字符串处理、TopK、最大子数组和这种题目经常出现。你可能会疑惑数据开发平时写SQL和Spark为什么要考算法我的理解是算法题能最快检验一个人的逻辑思维和代码规范性。很多数据开发任务本质上也是“对数据进行转换和计算”只是处理规模不同。能写清楚一个链表的翻转过程说明你对指针/引用关系理解到位这种能力在调试Spark程序、理解Shuffle执行时同样适用。备考策略我建议按优先级排序第一优先级数组、链表、字符串、栈、队列、哈希表的经典操作。第二优先级排序算法的手写、二分查找、双指针。第三优先级动态规划入门题最大子序和、爬楼梯、零钱兑换。第四优先级树的基础遍历、递归。不建议把时间浪费在超难题上因为数据开发笔试更看重你能否用代码解决“常见问题”而不是证明你会ACM。4.2 编程题高频考点与解题套路这里说几个我在真实笔试里遇到次数最高的题型以及它们的标准思路。第一个是链表反转。题目通常要求“反转一个单链表”边界条件处理是重点。递归和迭代两种写法都要会我一般默认用迭代因为更符合工程习惯public ListNode reverseList(ListNode head) { ListNode prev null; ListNode curr head; while (curr ! null) { ListNode next curr.next; curr.next prev; prev curr; curr next; } return prev; }答题时注意一个细节必须把next curr.next先在循环里保存否则修改curr.next之后链表就断了。这个点在真实编码时很常见丢分原因往往不是思路问题而是循环里几行代码的顺序写错。第二个是最大子序和。给一个整数数组找出和最大的连续子数组返回最大和。经典解法是Kadane算法核心是“以当前位置结尾的最大子数组和 max(当前元素, 前面最大子数组和 当前元素)”public int maxSubArray(int[] nums) { int maxSoFar nums[0]; int maxEndingHere nums[0]; for (int i 1; i nums.length; i) { maxEndingHere Math.max(nums[i], maxEndingHere nums[i]); maxSoFar Math.max(maxSoFar, maxEndingHere); } return maxSoFar; }第三类是TopK问题。比如“找到数组中第K大的数”。最优解是用快速选择算法平均复杂度O(n)如果笔试环境不要求最优用小根堆维护K个最大值也可以。我建议两种都练因为面试官可能追问“为什么堆解法复杂度是O(n log k)”。笔试编程题还有一个实战建议先写一个暴力解法保证不空题再考虑优化。大厂笔试通常是在线判题系统跑不过就是0分哪怕思路再对提交一个语法错误也比写一个“暴力但正确”的答案更可惜。先暴力后优化能保证拿到基础分如果题目不要求超时暴力解能过一大半测试用例。4.3 Java/Scala基础容易被忽略的送分题客观题部分Java和Scala基础经常被低估。很多同学觉得“我是做数据开发的Java不用细看”结果一到HashMap底层原理、JVM内存分区、线程池参数这些题就懵。实际上这部分是最容易拿分也最容易丢分的地方。Java基础常见考点有HashMap的底层结构数组链表红黑树。JDK8之后链表长度超过8且数组长度超过64会转红黑树。JVM内存结构堆、栈、方法区、程序计数器、本地方法栈JDK8后方法区改名为元空间不在堆内。线程池参数核心线程数、最大线程数、工作队列、拒绝策略以及它们之间的关系。并发基础synchronized和ReentrantLock的区别、volatile的可见性和禁止指令重排。如果笔试用的是Scala还需要掌握val和var的区别。伴生对象和伴生类的关系伴生对象可以直接访问伴生类的私有成员。不可变集合与可变集合的区别。高阶函数map、flatMap、filter、foldLeft的使用。数据开发工程师写Spark作业用Scala的场景很多所以Scala基础扎实在面试中也有加成。但笔试客观题不会考得太深通常是判断一段代码能否编译通过、某个算子的输出结果是什么。刷题时多看看集合操作的输出尤其是map和flatMap的区别这个点在笔试里很容易出错。5. 从笔试到面试备考路线与避坑经验5.1 三个月备考规划如果你的时间比较充裕比如还有三个月才到校招季我建议按这个节奏准备第一个月主攻SQL和Hive。每天手写5到10道SQL题重点练窗口函数、行列转换、连续值统计、TopN。可以找数据集练习也可以在本地装个MySQL或者用在线SQL练习平台但一定要动手写只看题解没有用。第二个月主攻算法和Java/Scala基础。LeetCode按标签刷题重点是数组、链表、哈希、字符串、二分、双指针、简单动态规划。每天做2到3道做完之后总结套路。Java基础按“集合 JVM 并发”三个模块复习Scala基础重点看集合和伴生对象。第三个月主攻大数据组件和数仓理论。读一些数仓建模的资料理解维度建模把ODS、DWD、DWS、ADS的分层原理彻底吃透。同时准备数据倾斜、Spark执行流程、Hive调优等高频简答题用自己的话写成一份笔记。如果你的时间只剩下两周我建议直接抓重点SQL窗口函数刷熟、LeetCode高频题型过一遍、数据倾斜和数仓分层的简答题背出自己的版本。放弃冷门知识点优先保证能得分的地方不丢分。5.2 备考中的常见误区第一误区是“只看不写”。数据开发笔试跟数学考试一样看懂了不等于会做会做了不等于写得对。尤其在SQL上一个括号、一个OVER子句的字段顺序都能让你全题没分。我自己的经验是每道题至少要完整手写一遍再对照答案看差异。第二误区是“过度依赖网上现成的题解”。网上很多数据开发笔试题的答案质量参差不齐尤其是SQL题同一个业务问题可能有多种写法有的写法在真实大数据引擎里性能很差。你如果不理解每种写法的适用场景面试官一追问就露馅。第三误区是“忽略简答题”。很多人备考把时间全花在写代码上理论简答题只靠考前突击背几段话。但大厂笔试的简答题往往是区分度最高的部分因为编程题大家都会个七七八八简答题才能真正看出你有没有整体架构意识。第四误区是“轻视基础概念”。你可能觉得HDFS副本数3这种题太简单但恰恰是简单题最容易因紧张而答错。笔试时心态要稳越是基础题越要慢慢审题看它是考副本数还是考写入流程。5.3 笔试当天的时间分配与答题策略笔试时间通常比较紧张我的策略是“先做简单题再做编程题最后攻简答题”。客观题部分遇到不会的不要死磕先标记跳过把会做的拿到手。因为客观题分值通常不高一题纠结五分钟会严重挤压后面的SQL和编程题时间。SQL题和编程题尽量留出足够时间因为它们的分值密度最高。写SQL题时如果时间允许可以在草稿纸上先画一下表结构和预期输出再动笔写代码。这个习惯能帮你避免很多低级错误。简答题放在最后但不要最后五分钟才写。简答题需要用文字组织至少要保证每个问题能写出一段结构完整的答案。如果时间紧张我会采用“关键词 短句”的方式先列出核心要点再补一两句展开这样即使没写完整判卷老师也能看到你的思路。提示在线笔试的IDE通常没有自动补全也不允许切到本地编辑器。平时练习时尽量用纯文本环境手写代码别依赖IDE提示否则考试时会很不适应。最后再分享一个备考小技巧我在准备数据开发笔试时会把做错的每一道题按“类型 错误原因 正确思路”记录成一份错题文档比如“连续登录SQL漏了DISTINCT去重正确思路是先子查询去重再开窗”。这个文档在考前一周反复看比重新刷一百道题都管用。因为我发现人最有价值的错误不是“完全不会的题”而是“你以为会、但一写就错”的题。后者往往说明你对某个细节的理解还不到位这种问题在考场上一旦出现就是实打实的丢分。数据开发这道门槛笔试只是第一关。把SQL、算法、数仓理论、大数据组件这四块地基打牢后面无论是面试还是真正做项目都会顺畅很多。希望这篇拆解能帮你少踩点坑早点拿到心仪的offer。