浩鲸科技数据开发B卷考点解析：SQL、数仓建模与组件原理

又是一年校招季看到不少人翻出浩鲸科技2020届数据开发B卷来复习。这套题我在后台也被人问过好几次老实讲虽然它出题年份早了一点但数据开发这个岗位的考察框架这几年基本没大变——SQL能力、大数据组件原理、数仓建模思维、场景落地能力翻来覆去就是这几板斧。与其机械地背答案不如把这份卷子当成一张地图搞清楚每条题目背后到底在考什么、为什么这么考才是真正能带走的东西。这篇文章我就以这份B卷为引子把数据开发笔试和面试中最高频的考点梳理一遍包括题型结构、答题思路、容易踩的坑以及平时怎么有针对性地训练。无论你是正在准备校招的应届生还是想从传统SQL开发转大数据方向的工程师都可以对照着自查一遍。1. 先看这份卷子怎么考——题型结构与考察目标拆解拿到一套笔试题先别急着动笔花两分钟扫一遍题型分布基本就能判断出题人想要什么样的人。浩鲸科技这套B卷从题量和类型上看走的是比较典型的数据开发校招路线客观题用来筛基础SQL和编程题用来筛动手能力最后的大题用来筛工程思维。三者权重不同备考策略也应该不同。1.1 客观题看似送分其实在筛知识边界客观题通常涵盖单选、多选、判断题面铺得很广。HDFS读写流程、MapReduce的Shuffle阶段、Spark的RDD依赖关系、Hive的查询执行流程、Kafka的消费组机制、ZK的选举原理这些都会随机出现。很多人觉得这些题就是背八股但我更愿意把它理解为在摸你的知识边界——你到底是真的用过这些组件还是只停留在跑通Demo的层面。举个典型的例子题目问“HDFS客户端写数据时数据流向是怎样的”。如果只是背过答案你可能知道是客户端逐包写入DataNode但未必知道为什么是客户端主动推送而不是DataNode去拉取也未必清楚DataNode之间通过Replication Pipeline接力复制的细节。一旦多选题里换个问法比如“下列哪些环节会产生网络开销”背答案的人马上就露馅。所以客观题的正确打开方式不是死记硬背而是把一个组件的核心流程用自己的话讲清楚。能讲清楚数据在节点之间怎么流动、中间有哪些步骤可能失败、失败后怎么恢复这类题怎么换马甲你都能认出来。1.2 SQL题占分最重直接决定下限数据开发岗位的笔试SQL题是绝对的大头。B卷里的SQL题目覆盖了多表关联、聚合统计、窗口函数、行列转换、去重逻辑这些基础能力偶尔还会有一道写起来比较费劲的复杂查询。这背后的信号很明显你可以对某个框架的原理了解得不深但SQL写不熟练后面干活会非常吃力。为什么数据开发这么看重SQL因为绝大多数数据需求最终都会落到SQL上。不管底层是Hive、Spark SQL还是Flink SQL业务方要的是一张表、一个指标、一个报表你不可能每次都写MapReduce或Spark作业去满足临时需求。SQL写得好不好直接决定你能否快速响应需求也决定你能不能把一个复杂逻辑拆成清晰可读的查询。这里提醒一句笔试里写SQL千万别只顾着“能跑通”。阅卷人看的是你的思路是否清晰、逻辑是否严谨甚至你的缩进和字段命名习惯都会被注意到。我见过不少候选人结果算对了但SQL写得像一团乱麻子查询套了十几层连他自己都不一定能讲清楚每层在干什么。这种人就算进了面试也很容易被追问到怀疑人生。1.3 综合题与编程题考察工程落地能力B卷最后通常会有一道综合题给一个业务场景让你设计数据链路或写一段处理逻辑。这种题没有标准答案但恰恰是最能拉开差距的。有人只写了“用Spark读数据再算一下”有人却能给出完整方案数据源是什么、怎么接入、用实时还是离线、中间结果怎么存储、下游怎么消费、数据延迟怎么处理、任务失败怎么告警。两者的差距不在于谁背了多少技术名词而在于谁真正动手做过项目。数据开发这个岗位说到底是个工程岗不是研究岗。你写出来的代码要能上线跑、能稳定运行、能方便别人维护。笔试里那道综合题就是想看看你有没有建立这种工程直觉。如果你还没做过完整的数仓项目备考阶段一定要自己动手搭一套离线数仓哪怕是复用网上的开源数据集也行。把数据接入、清洗、分层建模、指标计算、任务调度整条链路走一遍很多笔试里看起来抽象的问题会瞬间变得具体。2. 高频真题的答题思路——从会做到讲清楚这一节我挑几类在B卷和同类笔试题中出现频率极高的题目逐一拆解背后真正想考察的东西。每一类我都会给出通用的解题范式而不是单纯给一道题一个答案。掌握了范式题目怎么变你都不慌。2.1 窗口函数分组TopN和排名的标准解法先看一道大概率会出现的题给一张用户订单表包含用户ID、订单日期、订单金额要求取出每个用户下单金额最高的前三笔订单。很多人第一反应是group by但group by一旦聚合就取不到明细行了。正确思路是用窗口函数。SELECT user_id, order_date, order_amount FROM ( SELECT user_id, order_date, order_amount, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_amount DESC) AS rn FROM user_orders ) t WHERE rn 3;这里有个容易被忽视的点为什么用ROW_NUMBER()而不是RANK()或DENSE_RANK()三者的区别是ROW_NUMBER()会给相同金额随机分配不同名次RANK()会跳号比如两个并列第一下一个名次是3DENSE_RANK()不跳号。如果业务上要求金额相同算并列就要换RANK()或DENSE_RANK()。笔试时如果不确定用哪个可以在答案旁边补一句“若金额相同需并列排名改用RANK()”这能体现你对细节的敏感度。窗口函数这类题考点其实就两个第一能不能想到用窗口函数替代group by第二PARTITION BY和ORDER BY的顺序会不会搞反窗口范围ROWS BETWEEN会不会用。把这几件事搞清楚窗口函数相关的SQL题基本就稳了。2.2 经典连续性问题连续登录N天的通用解法另一类出题率极高的题是连续登录问题。题目大概是“给定用户登录表求连续登录3天及以上的用户”。这类题在笔试里出现的频率非常高因为它能考察对日期处理、去重、分组等多个知识点的综合运用。通用的解法思路是用日期减去行号。先对每个用户的登录日期去重然后按用户分组按日期排序用当前日期减去这个用户内部的行号得到一个日期。如果原始日期是连续的那么差出来的日期是相同的所以再按用户和这个差值分组统计数量即可。WITH login_distinct AS ( SELECT DISTINCT user_id, login_date FROM user_login ), login_rank AS ( SELECT user_id, login_date, DATE_SUB(login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date)) AS group_date FROM login_distinct ) SELECT user_id FROM login_rank GROUP BY user_id, group_date HAVING COUNT(*) 3;这个解法的精妙之处在于它把“日期是否连续”这个难以直接判断的问题转换成“分组后数量是否达标”这个容易处理的问题。只要理解了这一点哪怕题目改成“连续7天”“连续30天”你只需要改最后的HAVING条件就行。答题时建议把“为什么先要去重”也写清楚。一个用户同一天可能存在多条登录记录如果不去重连续性的判断就会出错。这种细节写出来阅卷人一眼就知道你考虑过真实数据的脏乱问题。2.3 数据倾斜从原理到解决考察底层理解数据倾斜是笔试和面试中出现频率极高的话题而且是能够区分“背题选手”和“真正做过项目选手”的经典题目。先说原理数据倾斜的本质是数据在Key上的分布不均匀导致某个Reduce或某个Task处理了绝大部分数据拖慢了整个作业。解决思路要从多个层面说。第一层是提高并行度改参数让Reduce数量更多第二层是Map端聚合在Shuffle前先做部分聚合减少传输量第三层是加盐给存在倾斜的Key加上随机前缀把一个Task的数据打散到多个Task处理然后再做一次去盐聚合。此外还有MapJoin把一个小表放到内存里避免Shuffle阶段的大Key倾斜。笔试里如果让你写倾斜的解决方案建议按“先定位再处理”的顺序来。先说什么现象让你判断出发生了倾斜某个Task长时间卡在99%或者某个Reduce处理的数据量远大于其他Reduce再说怎么定位通过日志、Counter指标、查看Spark UI的Stage详情最后给出针对性方案。这个顺序本身就体现了工程排障的思维是加分项。2.4 数仓分层与建模不考SQL但比SQL更拉分B卷中还有一类简答题比如“介绍你们数仓的分层结构”或“设计一个订单事实表和维表”。这类题没有标准SQL答案完全看经验积累。基础答案是ODS、DWD、DWS、ADS四层核心思想是层层递进、数据解耦、指标复用。但如果你想拿高分必须能讲出分层的实际价值。比如为什么不能直接让业务方查ODS因为ODS层的数据没有经过清洗和规范字段命名随意直接暴露给下游会埋下无数隐患。到了DWD层数据经过清洗、格式统一、维度退化才是可以放心使用的明细数据。DWS层做的是轻度汇总服务通用的统计需求。ADS层则完全面向具体业务场景比如“近30天各渠道下单用户数”这种指标直接查ADS层就可以了。另外维度建模里的缓慢变化维SCD也很容易考。典型场景是用户的所属部门、会员等级会变化是直接覆盖更新SCD1还是保留历史记录SCD2还是增加历史字段SCD3不同场景有不同选择。答题时如果能结合一个具体例子说明选型原因比如“我们做用户历史行为分析时需要回溯用户当时的状态所以选了SCD2”就会让人相信你真的做过设计而不是背了几页PPT。3. 从笔试到实战——怎么把刷题转化为真实能力备考数据开发岗位只刷题不练项目等于空中楼阁。反过来说只做项目不刷题很多基础概念和常用SQL写法又不够熟练笔试容易折戟。我的建议是把两者结合起来通过一套完整的数据项目来驱动学习这样每个知识点都有真实的落地场景。3.1 手写SQL的现场感笔试中容易忽略的细节笔试和平时在IDE里写SQL完全不同。没有提示没有高亮也没有数据可以验证写错了只能靠肉眼硬看。这种情况下有几个细节特别重要。第一是字段名最好带上表别名前缀。多表关联时字段来源一眼就能看清逻辑也更严谨。第二是子查询必须起别名Oracle和MySQL对这块要求不完全一样笔试用的环境不确定写上别名最保险。第三是数据类型要心里有数比较日期时字段是字符串还是时间类型拼条件时要不要加引号这些都是手写SQL的高频失分点。还有一个小建议写复杂SQL前先在草稿纸上画出逻辑步骤。比如“先过滤近30天数据再按用户聚合再关联维表补全信息”然后按步骤拆成子查询或CTE。这能大幅降低一次性写对的难度。很多笔试题目并不要求写出最优解但要求逻辑正确、结构清晰你按步骤拆开写阅卷人看得舒服你自己也更容易自查。3.2 理解执行过程从“会写SQL”到“能优化SQL”刷题刷到一定量之后你会遇到瓶颈题目都会写但不知道为什么这么写效率高。这时候就需要往底层走一步理解SQL的执行过程。以Hive为例一条SQL从客户端提交到最终返回结果要经过解析、语法分析、逻辑计划、物理计划、执行引擎等一堆环节。笔试中不会让你把这套流程完整默写出来但理解其中关键环节能帮你解释很多现象。比如为什么要避免大表关联大表因为Hive默认的Reduce端Join要把两张表的数据都经过Shuffle按Join Key分发到Reduce端一旦Key分布集中就会触发前面说的数据倾斜。而MapJoin之所以快是因为把小表加载到分布式缓存里在Map端直接匹配跳过了Shuffle。能不能在面试中把这个问题讲清楚直接决定了面试官对你的评价是“会用工具”还是“懂原理”。平时练题时可以刻意做一件事每写完一条SQL追问自己一句“这个查询在引擎里是怎么跑的数据是怎么流转的”。想不明白的地方就去查资料、看源码解析把一个个“为什么”解决掉。这样做两三个月你对SQL的理解会和只会刷题的人完全不在一个层面。3.3 结合业务场景的加分项电信数据项目中的常见需求浩鲸科技出身于通信行业的大数据领域所以这类笔试中如果出现业务场景题很可能会带上电信行业的影子。比如话单数据、信令数据、用户上网日志这些数据的共性大家要心里有数。一份上网日志通常包含用户标识、时间戳、基站位置、访问URL、上下行流量等字段天然适合做数据分析。常见需求比如统计某个时段某个区域的用户在线数或者分析用户常驻地、通勤轨迹再比如基于流量使用情况做用户画像为精准营销提供数据支撑。数据开发的日常工作就是把这些原始日志清洗成标准格式然后加工成业务方可直接使用的指标。如果你没有通信行业背景也不用慌。把思路放在“数据的流转和加工”上就行原始数据长什么样、存在哪里、怎么接入、怎么清洗、怎么建模、产出什么指标。这个方法论在任何行业都是通用的只是举的例子不同而已。笔试时遇到不熟悉的业务场景先把通用的数据加工链路搭出来再结合题目中给出的业务名词做填充比你干坐在那里想“这是什么行业”要靠谱得多。4. 容易丢分的坑与备考阶段的实用建议最后和大家聊几个我在帮人改笔试题时经常看到的问题以及我自己备考时总结出来的一些心得。这些坑在B卷里大概率也会遇到提前打个预防针能帮你少走不少弯路。4.1 高频失分点速查表失误类型具体表现规避方法窗口函数使用不当ROW_NUMBER和RANK不分场合混用先确认业务上是否需要并列排名忽略去重连续登录问题没对用户和日期去重见到明细数据先想有没有重复的可能子查询嵌套过深单个SQL写了几十行逻辑不清晰优先用WITH AS或拆成临时表只知道答案讲不清原因能写对SQL但无法解释原理每天花30分钟深挖一个执行细节数据倾斜方案缺失只说“加盐”但说不清怎么加、怎么去手动模拟一次加盐过程理解每个步骤数据类型不敏感字符串和日期直接比较手写SQL前先确认字段类型没有容错意识没有考虑任务失败、数据延迟综合题里主动提到告警、重试、补偿机制这张表你可以保存下来每次做完一套笔试模拟题就对照检查一次连续几次都没踩到这些坑说明基础已经相对扎实了。4.2 笔试答题的时间分配策略笔试时间通常比较紧一大忌讳是在一道题上死磕太久。我的建议是先把所有题目扫一遍优先做有把握的题把该拿的分先拿到。遇到卡壳的题做个标记先跳过。整套卷子做完之后如果还有时间再回头啃硬骨头。客观题不会的也别空着先凭直觉选一个因为多选题如果选错会扣分但不选一定没分。SQL题如果写不出最优解写一个能跑通的解法也比留白强。阅卷很多时候是采点给分你写出来的每一步逻辑都可能得分。综合题更要注意时间分配。这类题字数多、分值高但也不是写得越长越好。建议先列一个简短的提纲再按提纲展开。如果你连提纲都列不出来说明对场景的理解还不够先花两分钟把业务需求拆解一遍输入是什么、输出是什么、中间要经过哪些步骤。只要链路想明白了写出来就是水到渠成的事。4.3 备考期间一定要做的三件事第一把SQL刷到“肌肉记忆”的程度。这里说的不是背题而是要条件反射般地说出窗口函数、各种JOIN之间的区别、GROUP BY和DISTINCT的适用场景。每天固定写三到五道SQL题坚持一个月效果立竿见影。第二亲手搭一套数仓Demo。不用多大规模能用Spark或Hive把一个公开数据集清洗、分层、建模、出指标就行。过程中你会遇到分区问题、字段类型问题、内存溢出问题、数据倾斜问题这些实战经验就是笔试里综合题的答案来源。第三把组件的核心机制讲给没有背景的人听。HDFS是怎么容错的、MapReduce的Shuffle到底做了什么、Spark和MapReduce的区别是什么能把这些用大白话讲清楚说明你真的理解了。讲不清的地方就是你需要补课的地方。我个人在准备数据开发面试的时候最大的体会是这套岗位的考题其实很诚实它考察的就是每天工作真正要用到的能力。你的SQL熟不熟练、对数据链路有没有全局观、出了问题能不能快速定位写几行代码、答两道简答题就试出来了。与其找各种押题资料不如把基础打扎实每一道做过的题都追问几句“为什么”把这些“为什么”都琢磨透了不管遇到哪家的B卷还是C卷都能从容应对。最后再分享一个小技巧笔试前把Hive和SparkSQL中常用函数的语法在脑子里过一遍尤其是窗口函数的排序方向、时间函数的格式转换、字符串函数的参数顺序。很多时候我们不是不会写而是记混了参数顺序导致提交的答案差一个逗号。这种低级错误只要提前过一遍完全可以避免。