最近在准备大数据方向面试的朋友多少都应该遇见过一份流传挺广的资料叫《最强最全面的大数据SQL经典面试题》由31位小伙伴协作整理完成。我在刷了三遍、又拿它去复盘了真实面试之后最大的感受是这份题集的价值不在于“背答案”而在于它帮你把大数据SQL的考点系统地串了一遍。无论你是刚转行入坑的数据新人还是已经写了几年Hive SQL但没系统整理过知识树的老手它都能提供比较清晰的查漏补缺路径。所以这篇博文我不想做“资料导读”式的流水账而是想认真拆一拆这类SQL面试题背后到底在考什么、有哪些题型高频出现、刷的时候容易踩哪些坑以及31个人的协作模式为什么能让一份题集的质量明显不一样。内容会比较长但对准备面试或者想提升数仓SQL能力的人来说值得花时间看完。1. 这份SQL面试题合集到底在解决什么问题1.1 为什么大数据岗位的面试绕不开SQL考察先聊一个很多人没想透的问题为什么大数据开发、数据仓库工程师、数据分析师这些岗位面试时几乎必考SQL原因其实很实际。在大数据生态里Hive、Spark SQL、Flink SQL这些引擎把分布式计算能力“降维”成了类似关系型数据库的SQL接口。业务团队要取数、数据团队要做数仓加工、算法团队要做特征工程底层最终都会落到一大段SQL上。面试官没法在短短一小时内考察你对整个分布式框架的掌握但可以通过SQL题快速判断三件事逻辑思维清不清晰、对数据处理的敏感度高不高、有没有踩过真实数据的坑。这就导致SQL笔试变成了一道“高效筛子”。我在和几位做面试官的朋友聊的时候大家口径出奇一致能写出正确答案的人不少但能在限定时间内写出高效、健壮、能处理边界情况的SQL的人比例其实很低。而这份31人协作整理的题集恰好就是冲着“高效、健壮、能处理边界情况”这几个方向去的。1.2 这份合集的覆盖面远不止“刷题”市面上SQL面试题很多但大多是零散收集的MySQL题目直接套到大数据场景里其实不太对味。大数据SQL面试的核心场景是数仓而数仓SQL的考察重点和传统OLTP差别很大窗口函数、开窗聚合、UDTF炸裂、多维统计、留存漏斗、累计计算、去重优化、数据倾斜处理这些在传统SQL面试里很少系统出现。这份合集在这点上做得比较到位。它按题型和场景做了归类比如分组TopN、连续问题、行列互转、累计与同比环比、留存与漏斗、排名与去重等。每一类下面都有若干道题目而且解法不只一种。比如同样是TopN用row_number、rank、dense_rank写出来的结果完全不同题集里会把这类细微差异单独拎出来对比。1.3 适合谁看不适合谁看先说适合的。准备大数据开发、数仓工程师、数据分析师面试的人是最核心的受众。其次是工作中经常写Hive SQL、但对某些函数和优化点只是“用过但没吃透”的从业者通过题集里的解析能补上很多盲区。不太适合的是完全没有SQL基础、想靠背题混过面试的人。因为题目涉及的窗口函数、子查询、多层嵌套、炸裂函数如果不懂背后的执行逻辑就算把答案背下来面试官换个问法立刻露馅。我见过不少背题型选手在面试现场被追问“这个排序在Map端还是Reduce端做的”时直接卡住。所以这份题集更适合当“训练册”而不是“押题宝典”。2. 大数据SQL与传统SQL的本质差异决定了面试考点2.1 执行引擎和分布式计算带来的思维转变写传统MySQL的SQL大脑里默认的表是一张行存大表索引、锁、事务是隐形的底层框架而写Hive/Spark SQL数据是分散在多个节点上的计算过程本质上是Map Shuffle Reduce的流水线。这种模型差异会导致一个很核心的转变写SQL时不能只关心“结果对不对”还要关心“这种写法会产生多少次Shuffle、会不会数据倾斜、能不能利用分区裁剪”。举个例子。一张订单表按天分区要统计近30天每个品类的销售额。新手可能直接全表扫描再group by懂的会先加分区过滤条件把扫描量降下来更熟练的会进一步考虑如果group by的字段枚举值很少、但数据量巨大可能会触发数据倾斜这时候要考虑能不能用两级聚合、加盐打散。这在传统数据库里很难成为考点但在大数据SQL面试里几乎是必问题。这份题集里的很多题目都把这类优化点融进了解法里刷的时候值得格外留意。2.2 面试官到底在考察什么三层递进根据我自己面试和被面试的经历大数据SQL面试的考察是分层的。第一层是语法正确性窗口函数会不会写、join条件对不对、group by字段完不完整。这是底线但这只能拿到基础分。第二层是逻辑严谨性遇到连续登录、排名并列、累计去重、跨天漏斗这类稍复杂的问题能否分解成清晰的逻辑步骤而不是靠试错凑答案。第三层是执行意识写完SQL之后能不能预估数据量级、发现潜在的倾斜风险、知道某个函数在Hive和Spark上的行为差异。能到这一层的人基本已经具备了独立承担数仓开发任务的能力。这份面试题的价值在于很多题目本身不会直接考察第三层但参考答案或讲解里会提及背后的执行代价。比如用row_number做TopN会顺带解释这个窗口函数的Shuffle代价用later_view explode炸裂之后会提醒小文件膨胀的问题。这些细节是普通刷题资料很少覆盖的。2.3 大数据SQL核心知识点图谱刷这份题集前最好心里先有一张知识地图把知识点分成几大块基础查询与控制select、where、group by、having、join、union、子查询窗口函数row_number、rank、dense_rank、sum/count/avg开窗、lag/lead、first_value/last_value高阶数据处理lateral view explode、collect_list/collect_set、case when多层判断、字符串处理集合与去重distinct、group by去重、row_number去重、近似去重算法如HLL的适用场景优化参数分区裁剪、小文件合并、join顺序调整、mapjoin、数据倾斜处理对照图谱后再去刷题集效果会好很多。因为你能明显看出某道题对应的是哪块知识而不是被题目牵着走。3. 面试题里最高频的几类经典题型拆解3.1 分组TopN业务场景最密集的考题TopN问题在大数据SQL里出场率非常高因为它对应着太多真实场景每个类目销量最高的商品、每个用户最近一次下单时间、每个部门工资最高的员工。这题的考察点集中在窗口函数的使用差异上。我整理了一个小对照表可以直观看到三种排序函数的差别函数重复值处理排名结果典型使用场景row_number相同值随机排序号1,2,3,4取精确行数比如取前5条记录rank相同值并列且跳号1,1,3,4并列冠军场景比如销量最高的并列保留dense_rank相同值并列但不跳号1,1,2,3需要连续排名比如占比层级统计很多人在面试里一看到“TopN”就无脑用row_number这其实是个陷阱。如果题目要求“并列也保留”row_number就会丢失数据。我在实际工作中也踩过类似的坑统计销售排行时用row_number取了前10结果漏掉了两个与第10名销量完全一样的商品被业务方质疑数据不对。所以刷这类题时一定要先把题目里的“是否允许并列”“N条还是N个名次”读清楚。除了排序函数本身分组TopN的写法里还有一个高频扩展点如何取每个用户最近三笔订单的金额总和。这需要窗口函数嵌套子查询先按用户分组排序取前三笔再对金额聚合。这个题看着不难但在白板写SQL时很多人会卡在“先排序再聚合”和“先聚合再排序”的顺序上值得多练几道找感觉。3.2 连续性问题逻辑与数学表达的结合连续登录N天、连续充值N天、连续活跃N周这类题是面试里最能拉开差距的题型之一。它的核心解法其实很经典用日期减去按用户分组的行号如果日期是连续的相减得到的结果应该相等。举个最简单的例子。假设一张登录表里有用户ID和登录日期我们要找连续登录3天以上的用户。标准思路是先按用户分组、按日期排序得到row_number再用“日期 - row_number天数”得到一个辅助分组字段最后按用户和辅助分组字段做count大于等于3的就是目标用户。这个解法背后有一个很巧妙的数学思想连续日期序列里日期值本身等差递增而行号也是等差递增两个递增序列相减后差值恒等。一旦哪天没登录日期跳跃了差值就会变化自然把不连续的数据切分开。面试官一般会层层追问比如如果有重复登录日期怎么办需要先按用户和日期去重、如果数据里有跨月跨年怎么办日期相减函数在不同引擎里要注意格式转换。我自己在刷这类题时的心得是不要只记解法要理解“等差相减”这个数学本质。理解了本质之后题目从“连续登录天数”变成“连续登录的最大天数”“连续会话间隔小于5分钟的活跃时段”都能快速套用变形。3.3 行列互转数仓建模的基本功行列互转在大数据SQL题里也极其常见因为很多底层表是明细表但分析师希望用宽表形态直接看指标。面试题常见的行转列是用sum/count配合case when实现分组内多个条件计数列转行则是用lateral view explode实现一列展开为多行。先看一个行转列的例子一张订单表有订单ID、商品品类、销售额想要每个品类在每个月份的销售额可以用多条件聚合select category, sum(case when month 2025-01 then amount else 0 end) as jan_amount, sum(case when month 2025-02 then amount else 0 end) as feb_amount, sum(case when month 2025-03 then amount else 0 end) as mar_amount from orders group by category;这种写法看起来简单但实际里面埋了不少坑如果month字段本身有NULLcase when会把NULL当成不匹配条件导致当月数据漏统计如果某个月份整月没有订单这一列就会一直是0下游做环比时会误判为下降100%。所以面试官问到这种题通常还会追问“NULL和0要不要区分”“空月份怎么处理”这些都是真实数据环境里的必备意识。列转行是另一个方向一张表里有用户ID和一个标签数组字段要把每个标签拆成一行。Hive里常用lateral view explodeselect user_id, tag from user_tag_table lateral view explode(tag_list) t as tag;这个函数的代价在于炸裂后数据行数会膨胀如果标签数组很长会引发小文件、内存溢出等问题。刷这道题时最好顺便查一下“explode和posexplode的区别”“lateral view multiple的用法”它们在实际数仓开发里都是高频使用点。3.4 漏斗分析与留存率计算留存率和漏斗转化率之所以成为必考题是因为它们对SQL能力的要求很综合。这类题需要多次聚合、时间窗口计算、可能还要处理跨表join非常能考察一个人拆解复杂业务逻辑的能力。拿最简单的次日留存率来说题目可能长这样用户登录表user_id、login_date统计每天新增用户在次日再次登录的比例。思路分几步先找出每天每个用户首次登录日期作为新增日期关联登录表中该用户其后一天的登录记录计算“当日新增且次日登录的用户数 / 当日新增用户数”。如果不用子查询也可以用窗口函数first_value取首次登录日期。这两种写法执行代价不同子查询在Hive中的Shuffle次数更多窗口函数虽然逻辑上更紧凑但要注意first_value不会自动去重会导致一个用户出现多行。这两个细节都是真实面试里的加分点。漏斗分析更复杂一些用户行为日志表里有事件类型pv、add_cart、pay和时间戳要统计每一步的转化率。核心难点是同一用户可能有多条事件记录需要按“同一用户的最早触发事件”来确定每一步是否发生这个剔重逻辑处理不好就会导致转化率虚高。我在辅导一个新人时就遇到过这种情况不做去重统计出来的加购转化率是65%去重后只剩40%业务方完全是根据这个数据做决策的差别非常大。3.5 累计计算与同比环比这类题考的是开窗聚合的灵活运用。比如“统计每个商户每月销售额的累计值”如果只写sum(amount) group by month得到的是月度值想在同一行里既看到当月值、又看到截至当月的累计值就需要用窗口聚合select merchant_id, month, sum(amount) as month_amount, sum(sum(amount)) over (partition by merchant_id order by month) as cum_amount from orders group by merchant_id, month;这里有个很多人第一次看会愣住的写法sum(sum(amount)) over (...)。内层sum是把当月数据汇总外层sum是窗口内对汇总结果做累计。理解了这两层聚合的关系就理解了“先聚合再开窗”的核心逻辑。同比环比在面试题里通常以“月度销售额环比增长率”出现解法是把自己join上一个月的自己或者用lag函数select month, amount, lag(amount, 1) over (order by month) as prev_amount, round((amount - lag(amount, 1) over (order by month)) / lag(amount, 1) over (order by month), 3) as mom_ratio from monthly_sales;这个题的坑点在于一月份没有上一月数据prev_amount是NULL相除也是NULL业务方看到的环比增长会是空值而非0%。到底该显示为NULL、0还是“新增”标签取决于业务口径。面试时如果能主动说到这一层面试官会觉得你有真实业务经验。4. 一道高频题的完整实战从建表到SQL再到讲解4.1 题目与建表这里拿出题集里一道很典型的题目做完整实战题目是某电商平台有商品订单明细表和商品信息表请按品类统计销量Top3的商品若销量并列则全部保留。先说思路再逐步落到SQL。要把“每个品类”和“Top3”拆开看本质上有两步第一步是聚合每个商品的销量第二步是分组排序取TopN。难点在“并列保留”所以排序函数必须用rank或者dense_rank。假设有两张表sku_infosku_id商品ID、category品类、sku_name商品名order_detailorder_id订单ID、sku_id、sold_cnt销量先建临时表做演示create table if not exists sku_info ( sku_id string comment 商品ID, category string comment 品类, sku_name string comment 商品名 ) comment 商品信息表; create table if not exists order_detail ( order_id string comment 订单ID, sku_id string comment 商品ID, sold_cnt int comment 销量 ) comment 订单明细表;准备几条测试数据去验证逻辑。想象一下品类“家电”下有A、B、C三个商品销量分别是100、200、150品类“服饰”下有D、E、F、G四个商品销量分别是80、80、60、70。这样的话家电的Top3是B(200)、C(150)、A(100)服饰的Top3中D和E并列第一都要保留。4.2 第一种解法子查询加窗口函数先聚合每个商品的销量然后用rank排序再嵌套一层取排名小于等于3的select category, sku_id, sku_name, total_cnt from ( select s.category, s.sku_id, s.sku_name, sum(o.sold_cnt) as total_cnt, rank() over (partition by s.category order by sum(o.sold_cnt) desc) as rk from sku_info s join order_detail o on s.sku_id o.sku_id group by s.category, s.sku_id, s.sku_name ) t where rk 3;这段SQL里最关键的是rank() over (partition by s.category order by sum(o.sold_cnt) desc)。这里直接在窗口函数里用了聚合函数sum(o.sold_cnt)和group by合用在Hive和Spark SQL里都是支持的算是一个比较高频的“聚合窗口组合”写法。我见过不少人在这个地方犯迷糊窗口函数里的order by能不能用聚合后的结果答案是可以但要注意它依赖group by对数据的预聚合如果聚合粒度没对上窗口排序的结果就会错。所以我在写这题时习惯先把聚合结果落到子查询里再把窗口函数包在外面这种写法的逻辑链路更清晰别人review代码时也更容易看懂。4.3 第二种解法用临时表拆解如果觉得嵌套可读性差可以拆分步骤先把聚合结果存到临时表再在临时表上做排序过滤。用Hive举例create table sku_sold_stat as select s.category, s.sku_id, s.sku_name, sum(o.sold_cnt) as total_cnt from sku_info s join order_detail o on s.sku_id o.sku_id group by s.category, s.sku_id, s.sku_name; select category, sku_id, sku_name, total_cnt from ( select category, sku_id, sku_name, total_cnt, rank() over (partition by category order by total_cnt desc) as rk from sku_sold_stat ) t where rk 3;这种写法的好处是方便调试如果你不确定聚合结果对不对可以先看一眼临时表数据再继续做排序。缺点是多了临时表/中间步骤在笔试白板环境里可能没有建表权限所以两种解法都要掌握。笔试题里如果要求“一条SQL实现”就选嵌套写法如果是在数仓开发场景里我会更倾向临时表拆解因为可维护性更高。这里还要提一下并列情况的实验验证如果服饰品类下D和E销量都是80用rank得到结果是1、1、3把排名1和3的两条都保留实际上会输出D、E、F三条记录符合“并列全部保留”的要求。如果用row_number只会随机保留一条就扣分了。5. 刷题过程中最常踩的坑我帮你列了一份排查清单5.1 SQL执行顺序的误区很多人写SQL时被各种报错或者错误结果折腾半天根源在于没搞懂SQL的逻辑执行顺序。虽然是“select”写在最前面但它的逻辑执行顺序其实是from - join - on - where - group by - having - select - distinct - order by - limit。这个顺序带来的一个典型坑是where里不能使用select里的别名。这不算大数据SQL特有的问题但面试里很常出现。在Hive里如果非要过滤聚合结果必须要用having或者再套一层子查询。我在实际review团队代码时经常看到新人写“where total_cnt 100”结果一直报错原因就是对执行顺序不熟。另一个和Hive强相关的误区是group by字段和select字段的一致性。传统MySQL允许select非聚合字段且不写全group by字段虽然关了only_full_group_by之后会报错但在Hive和Spark SQL里这个约束更严格select里出现的所有非聚合字段必须出现在group by里否则直接报错或结果随机。这个细节能让面试官快速判断你有没有大数据SQL的实际使用经验。5.2 数据倾斜最容易翻车、最考验经验的一环前面提到了数据倾斜这里展开说。面试题给的数据量都不大可能跑个几秒就出结果但在真实生产环境里一张动辄上亿行的表如果某个key的枚举值集中了绝大比例的数据计算就会非常慢甚至OOM。面试官在追问阶段经常会问“如果这个SQL在集群上跑挂了你会怎么排查”常用的排查思路有几个小表join大表时考虑使用mapjoin把维度表分发到各个map端如果大表join大表且关联键倾斜配合加盐随机前缀打散后做两阶段聚合group by聚合倾斜时先加盐做局部聚合再去掉盐做全局聚合如果某个业务的“0”值或其他默认值特别多要把这些值和正常值分开处理。比如统计全国某类商店的销售额如果把店铺ID作为分组字段而某个头部商家的订单量占了全网的30%以上这个分组就会严重倾斜。在群里的协作题集里这种优化点在多个题目下面都有提示但它更多需要在实际项目中反复体会。5.3 窗口函数和NULL的隐藏陷阱窗口函数是高频考点也是最容易出细节问题的点。一个常见的坑是partition by的字段中包含NULL时NULL会不会被分到同一个分组在Hive和Spark SQL里NULL会被分到同一个组但它和字符串的同组语义不太直观可能导致聚合结果里出现一条“NULL组”的额外记录和业务预期不符。解决手段是在开窗前对NULL做缺省值填充比如coalesce字段或转成默认值。另一个容易踩的坑是avg、sum这类聚合开窗函数遇到NULL时的行为。普通聚合函数会忽略NULL但窗口聚合函数在某些版本和引擎里对NULL的处理并不完全一致。比如计算“N日滑动平均”如果某天销售额是NULL直接开窗平均值可能导致结果被低估需要先用coalesce把NULL转成0或做排除。刷题时如果你发现参考答案和自己的结果差一点点先检查数据里是不是有NULL。5.4 笛卡尔积与自连接失控面试里考察join时有个隐藏深坑是“隐式笛卡尔积”。比如写join时漏了on条件或者在where里写关联条件但join里没写on在Hive里可能产生巨大的中间结果把作业跑挂。这个坑我在生产环境里遇到过一个同事写了两张千万级表的inner join结果两边关联条件写到了where里底层执行时先做了全量笛卡尔积再过滤跑了两个多小时还没结束。自连接也是。很多连续类、环比类题目的常规解法是“同一张表自己join自己”这在逻辑上没毛病但如果join后没有明确的行数控制或者没有利用分区和过滤条件性能会非常差。刷题题目里一般数据量小看不出代价但在面试追问环节说出“我会先在子查询里把数据量压缩再做自连接避免全量互关联”会明显拉高评分。5.5 结果不一致本地对集群跑出来不对有些人在本地用小数据集验证SQL没问题一放到集群上就结果出错最常见的原因就是数据分布不同规模下隐含的假设失效了。比如某些SQL依赖了行与行之间的物理顺序但在分布式环境里shuffle之后的行顺序是不保证的。如果不用窗口函数内显式指定的order by而直接依赖默认顺序结果必然不稳定。另一个隐蔽点是不稳定函数的使用。比如在Hive里获取随机值时如果用rand()作为join的关联键且没有固定种子每次运行的打散结果都不同会导致最终统计结果在多次运行间漂移。对这种题我的建议是每次跑完至少验证两遍如果结果不一致大概率是函数行为或者隐含依赖顺序出了问题。5.6 顺手整理一份速查表把上面这些坑整理成速查表单刷题前过一遍能少走很多弯路问题类型典型症状快速排查方向执行顺序where引用别名报错改为having或子查询数据倾斜作业长时间卡在某个stage检查分组key分布考虑加盐NULL分组聚合结果多出NULL组提前coalesce窗口函数行为结果与预期差一行检查是否需要显式order by自连接膨胀中间数据量爆炸先压缩数据再join结果不稳定两次运行结果不同检查rand()、物理顺序依赖6. 31个人协作整理的模式为什么值得学习6.1 协作流程收集、归类、验证、评审这份题集之所以叫“最强最全面”除了题目本身还因为31个人参与让它的质量和覆盖面有了明显提升。我了解了一下类似的协作流程大致可以分为四步题目收集、题型归类、解法验证、交叉评审。第一步是收集。每位参与者把自己在面试中遇到过的、或在业务中用过的经典SQL题发到协作群里。这个阶段不求题目整理得多么规范先保证“量”足够大。第二步是归类。有人负责把同类型的题合并比如“连续登录”相关的题可能有七八个变体合并成一道但保留多个延伸问法。第三步是验证。每个解法都必须实际跑过确保结果是正确的不能想当然。这一步尤其关键因为很多网上流传的SQL答案其实跑不通要么报错要么结果不对。第四步是交叉评审。每个人负责review几个不熟悉的题型提出优化和补充。这种协作方法放到任何一个技术知识库整理场景里都通用。它的核心价值在于“多双眼睛盯同一份内容”能把个人盲区大幅缩小。一个人整理题集时很容易只在自己擅长的领域深挖而31个人各有所长覆盖了窗口函数、UDF、性能优化、业务口径等多个细分方向最终成品更均衡。6.2 怎么用这份题集做面试冲刺光收藏不实操是没有意义的。我自己的刷题节奏是这样的分享出来给需要的朋友参考。第一遍通刷但不求快。按题型顺序每天固定花一小时先不看答案自己动手写SQL。写不出来没关系卡了十分钟后再看解析把卡壳点记下来。第二遍专项突破。把第一遍中错误率最高的题型拎出来比如连续问题和留存计算找同类型的变体题再练直到能独立写出正确SQL。第三遍模拟面试。随机抽题目用手写板或者纸上写完整SQL限制时间然后自己当面试官追问“为什么用rank不用row_number”“如果数据量增大10倍怎么办”。这套节奏走下来通常两到三周会有明显效果。题集里如果有一些同学标注了真实面试中遇到的口径描述我会额外关注那些题因为它们往往带有业务上下文更贴近面试难度。6.3 刷题之外更重要的一件事最后想多说一句。SQL题集刷得再熟也替代不了真实数据环境里的锤炼。我在带人的过程中反复强调面试题是“经过抽象后的干净问题”但工作里面对的是脏数据、慢任务、口径冲突和上下游依赖。刷题训练出的逻辑能力是基础但基础之上的环境适应能力、沟通确认能力和优化意识只能靠真实项目去积累。所以如果你是为了面试刷这份题集建议再配两个动作一是找一个可用的SQL运行环境把题集里所有题目都亲手跑一遍不要只看答案二是试着把每道题“改造成副作用版本”比如加上数据倾斜模拟、NULL注入、重复数据看看原解法还成不成立。这两个动作做完你对SQL的理解会比单纯刷三遍题集深很多。这份大数据SQL经典面试题合集确实帮到了很多人包括我自己团队里的几个新人。它的价值不在于背下多少道题而在于帮你建立一张清晰的知识网络。刷完题集之后你会发现自己看SQL的眼光不一样了看到一条复杂SQL脑子里会自动浮现它的执行路径、潜在风险和优化点。这个能力才是面试官真正想从SQL考察里挖出来的东西。
最近在准备大数据方向面试的朋友多少都应该遇见过一份流传挺广的资料叫《最强最全面的大数据SQL经典面试题》由31位小伙伴协作整理完成。我在刷了三遍、又拿它去复盘了真实面试之后最大的感受是这份题集的价值不在于“背答案”而在于它帮你把大数据SQL的考点系统地串了一遍。无论你是刚转行入坑的数据新人还是已经写了几年Hive SQL但没系统整理过知识树的老手它都能提供比较清晰的查漏补缺路径。所以这篇博文我不想做“资料导读”式的流水账而是想认真拆一拆这类SQL面试题背后到底在考什么、有哪些题型高频出现、刷的时候容易踩哪些坑以及31个人的协作模式为什么能让一份题集的质量明显不一样。内容会比较长但对准备面试或者想提升数仓SQL能力的人来说值得花时间看完。1. 这份SQL面试题合集到底在解决什么问题1.1 为什么大数据岗位的面试绕不开SQL考察先聊一个很多人没想透的问题为什么大数据开发、数据仓库工程师、数据分析师这些岗位面试时几乎必考SQL原因其实很实际。在大数据生态里Hive、Spark SQL、Flink SQL这些引擎把分布式计算能力“降维”成了类似关系型数据库的SQL接口。业务团队要取数、数据团队要做数仓加工、算法团队要做特征工程底层最终都会落到一大段SQL上。面试官没法在短短一小时内考察你对整个分布式框架的掌握但可以通过SQL题快速判断三件事逻辑思维清不清晰、对数据处理的敏感度高不高、有没有踩过真实数据的坑。这就导致SQL笔试变成了一道“高效筛子”。我在和几位做面试官的朋友聊的时候大家口径出奇一致能写出正确答案的人不少但能在限定时间内写出高效、健壮、能处理边界情况的SQL的人比例其实很低。而这份31人协作整理的题集恰好就是冲着“高效、健壮、能处理边界情况”这几个方向去的。1.2 这份合集的覆盖面远不止“刷题”市面上SQL面试题很多但大多是零散收集的MySQL题目直接套到大数据场景里其实不太对味。大数据SQL面试的核心场景是数仓而数仓SQL的考察重点和传统OLTP差别很大窗口函数、开窗聚合、UDTF炸裂、多维统计、留存漏斗、累计计算、去重优化、数据倾斜处理这些在传统SQL面试里很少系统出现。这份合集在这点上做得比较到位。它按题型和场景做了归类比如分组TopN、连续问题、行列互转、累计与同比环比、留存与漏斗、排名与去重等。每一类下面都有若干道题目而且解法不只一种。比如同样是TopN用row_number、rank、dense_rank写出来的结果完全不同题集里会把这类细微差异单独拎出来对比。1.3 适合谁看不适合谁看先说适合的。准备大数据开发、数仓工程师、数据分析师面试的人是最核心的受众。其次是工作中经常写Hive SQL、但对某些函数和优化点只是“用过但没吃透”的从业者通过题集里的解析能补上很多盲区。不太适合的是完全没有SQL基础、想靠背题混过面试的人。因为题目涉及的窗口函数、子查询、多层嵌套、炸裂函数如果不懂背后的执行逻辑就算把答案背下来面试官换个问法立刻露馅。我见过不少背题型选手在面试现场被追问“这个排序在Map端还是Reduce端做的”时直接卡住。所以这份题集更适合当“训练册”而不是“押题宝典”。2. 大数据SQL与传统SQL的本质差异决定了面试考点2.1 执行引擎和分布式计算带来的思维转变写传统MySQL的SQL大脑里默认的表是一张行存大表索引、锁、事务是隐形的底层框架而写Hive/Spark SQL数据是分散在多个节点上的计算过程本质上是Map Shuffle Reduce的流水线。这种模型差异会导致一个很核心的转变写SQL时不能只关心“结果对不对”还要关心“这种写法会产生多少次Shuffle、会不会数据倾斜、能不能利用分区裁剪”。举个例子。一张订单表按天分区要统计近30天每个品类的销售额。新手可能直接全表扫描再group by懂的会先加分区过滤条件把扫描量降下来更熟练的会进一步考虑如果group by的字段枚举值很少、但数据量巨大可能会触发数据倾斜这时候要考虑能不能用两级聚合、加盐打散。这在传统数据库里很难成为考点但在大数据SQL面试里几乎是必问题。这份题集里的很多题目都把这类优化点融进了解法里刷的时候值得格外留意。2.2 面试官到底在考察什么三层递进根据我自己面试和被面试的经历大数据SQL面试的考察是分层的。第一层是语法正确性窗口函数会不会写、join条件对不对、group by字段完不完整。这是底线但这只能拿到基础分。第二层是逻辑严谨性遇到连续登录、排名并列、累计去重、跨天漏斗这类稍复杂的问题能否分解成清晰的逻辑步骤而不是靠试错凑答案。第三层是执行意识写完SQL之后能不能预估数据量级、发现潜在的倾斜风险、知道某个函数在Hive和Spark上的行为差异。能到这一层的人基本已经具备了独立承担数仓开发任务的能力。这份面试题的价值在于很多题目本身不会直接考察第三层但参考答案或讲解里会提及背后的执行代价。比如用row_number做TopN会顺带解释这个窗口函数的Shuffle代价用later_view explode炸裂之后会提醒小文件膨胀的问题。这些细节是普通刷题资料很少覆盖的。2.3 大数据SQL核心知识点图谱刷这份题集前最好心里先有一张知识地图把知识点分成几大块基础查询与控制select、where、group by、having、join、union、子查询窗口函数row_number、rank、dense_rank、sum/count/avg开窗、lag/lead、first_value/last_value高阶数据处理lateral view explode、collect_list/collect_set、case when多层判断、字符串处理集合与去重distinct、group by去重、row_number去重、近似去重算法如HLL的适用场景优化参数分区裁剪、小文件合并、join顺序调整、mapjoin、数据倾斜处理对照图谱后再去刷题集效果会好很多。因为你能明显看出某道题对应的是哪块知识而不是被题目牵着走。3. 面试题里最高频的几类经典题型拆解3.1 分组TopN业务场景最密集的考题TopN问题在大数据SQL里出场率非常高因为它对应着太多真实场景每个类目销量最高的商品、每个用户最近一次下单时间、每个部门工资最高的员工。这题的考察点集中在窗口函数的使用差异上。我整理了一个小对照表可以直观看到三种排序函数的差别函数重复值处理排名结果典型使用场景row_number相同值随机排序号1,2,3,4取精确行数比如取前5条记录rank相同值并列且跳号1,1,3,4并列冠军场景比如销量最高的并列保留dense_rank相同值并列但不跳号1,1,2,3需要连续排名比如占比层级统计很多人在面试里一看到“TopN”就无脑用row_number这其实是个陷阱。如果题目要求“并列也保留”row_number就会丢失数据。我在实际工作中也踩过类似的坑统计销售排行时用row_number取了前10结果漏掉了两个与第10名销量完全一样的商品被业务方质疑数据不对。所以刷这类题时一定要先把题目里的“是否允许并列”“N条还是N个名次”读清楚。除了排序函数本身分组TopN的写法里还有一个高频扩展点如何取每个用户最近三笔订单的金额总和。这需要窗口函数嵌套子查询先按用户分组排序取前三笔再对金额聚合。这个题看着不难但在白板写SQL时很多人会卡在“先排序再聚合”和“先聚合再排序”的顺序上值得多练几道找感觉。3.2 连续性问题逻辑与数学表达的结合连续登录N天、连续充值N天、连续活跃N周这类题是面试里最能拉开差距的题型之一。它的核心解法其实很经典用日期减去按用户分组的行号如果日期是连续的相减得到的结果应该相等。举个最简单的例子。假设一张登录表里有用户ID和登录日期我们要找连续登录3天以上的用户。标准思路是先按用户分组、按日期排序得到row_number再用“日期 - row_number天数”得到一个辅助分组字段最后按用户和辅助分组字段做count大于等于3的就是目标用户。这个解法背后有一个很巧妙的数学思想连续日期序列里日期值本身等差递增而行号也是等差递增两个递增序列相减后差值恒等。一旦哪天没登录日期跳跃了差值就会变化自然把不连续的数据切分开。面试官一般会层层追问比如如果有重复登录日期怎么办需要先按用户和日期去重、如果数据里有跨月跨年怎么办日期相减函数在不同引擎里要注意格式转换。我自己在刷这类题时的心得是不要只记解法要理解“等差相减”这个数学本质。理解了本质之后题目从“连续登录天数”变成“连续登录的最大天数”“连续会话间隔小于5分钟的活跃时段”都能快速套用变形。3.3 行列互转数仓建模的基本功行列互转在大数据SQL题里也极其常见因为很多底层表是明细表但分析师希望用宽表形态直接看指标。面试题常见的行转列是用sum/count配合case when实现分组内多个条件计数列转行则是用lateral view explode实现一列展开为多行。先看一个行转列的例子一张订单表有订单ID、商品品类、销售额想要每个品类在每个月份的销售额可以用多条件聚合select category, sum(case when month 2025-01 then amount else 0 end) as jan_amount, sum(case when month 2025-02 then amount else 0 end) as feb_amount, sum(case when month 2025-03 then amount else 0 end) as mar_amount from orders group by category;这种写法看起来简单但实际里面埋了不少坑如果month字段本身有NULLcase when会把NULL当成不匹配条件导致当月数据漏统计如果某个月份整月没有订单这一列就会一直是0下游做环比时会误判为下降100%。所以面试官问到这种题通常还会追问“NULL和0要不要区分”“空月份怎么处理”这些都是真实数据环境里的必备意识。列转行是另一个方向一张表里有用户ID和一个标签数组字段要把每个标签拆成一行。Hive里常用lateral view explodeselect user_id, tag from user_tag_table lateral view explode(tag_list) t as tag;这个函数的代价在于炸裂后数据行数会膨胀如果标签数组很长会引发小文件、内存溢出等问题。刷这道题时最好顺便查一下“explode和posexplode的区别”“lateral view multiple的用法”它们在实际数仓开发里都是高频使用点。3.4 漏斗分析与留存率计算留存率和漏斗转化率之所以成为必考题是因为它们对SQL能力的要求很综合。这类题需要多次聚合、时间窗口计算、可能还要处理跨表join非常能考察一个人拆解复杂业务逻辑的能力。拿最简单的次日留存率来说题目可能长这样用户登录表user_id、login_date统计每天新增用户在次日再次登录的比例。思路分几步先找出每天每个用户首次登录日期作为新增日期关联登录表中该用户其后一天的登录记录计算“当日新增且次日登录的用户数 / 当日新增用户数”。如果不用子查询也可以用窗口函数first_value取首次登录日期。这两种写法执行代价不同子查询在Hive中的Shuffle次数更多窗口函数虽然逻辑上更紧凑但要注意first_value不会自动去重会导致一个用户出现多行。这两个细节都是真实面试里的加分点。漏斗分析更复杂一些用户行为日志表里有事件类型pv、add_cart、pay和时间戳要统计每一步的转化率。核心难点是同一用户可能有多条事件记录需要按“同一用户的最早触发事件”来确定每一步是否发生这个剔重逻辑处理不好就会导致转化率虚高。我在辅导一个新人时就遇到过这种情况不做去重统计出来的加购转化率是65%去重后只剩40%业务方完全是根据这个数据做决策的差别非常大。3.5 累计计算与同比环比这类题考的是开窗聚合的灵活运用。比如“统计每个商户每月销售额的累计值”如果只写sum(amount) group by month得到的是月度值想在同一行里既看到当月值、又看到截至当月的累计值就需要用窗口聚合select merchant_id, month, sum(amount) as month_amount, sum(sum(amount)) over (partition by merchant_id order by month) as cum_amount from orders group by merchant_id, month;这里有个很多人第一次看会愣住的写法sum(sum(amount)) over (...)。内层sum是把当月数据汇总外层sum是窗口内对汇总结果做累计。理解了这两层聚合的关系就理解了“先聚合再开窗”的核心逻辑。同比环比在面试题里通常以“月度销售额环比增长率”出现解法是把自己join上一个月的自己或者用lag函数select month, amount, lag(amount, 1) over (order by month) as prev_amount, round((amount - lag(amount, 1) over (order by month)) / lag(amount, 1) over (order by month), 3) as mom_ratio from monthly_sales;这个题的坑点在于一月份没有上一月数据prev_amount是NULL相除也是NULL业务方看到的环比增长会是空值而非0%。到底该显示为NULL、0还是“新增”标签取决于业务口径。面试时如果能主动说到这一层面试官会觉得你有真实业务经验。4. 一道高频题的完整实战从建表到SQL再到讲解4.1 题目与建表这里拿出题集里一道很典型的题目做完整实战题目是某电商平台有商品订单明细表和商品信息表请按品类统计销量Top3的商品若销量并列则全部保留。先说思路再逐步落到SQL。要把“每个品类”和“Top3”拆开看本质上有两步第一步是聚合每个商品的销量第二步是分组排序取TopN。难点在“并列保留”所以排序函数必须用rank或者dense_rank。假设有两张表sku_infosku_id商品ID、category品类、sku_name商品名order_detailorder_id订单ID、sku_id、sold_cnt销量先建临时表做演示create table if not exists sku_info ( sku_id string comment 商品ID, category string comment 品类, sku_name string comment 商品名 ) comment 商品信息表; create table if not exists order_detail ( order_id string comment 订单ID, sku_id string comment 商品ID, sold_cnt int comment 销量 ) comment 订单明细表;准备几条测试数据去验证逻辑。想象一下品类“家电”下有A、B、C三个商品销量分别是100、200、150品类“服饰”下有D、E、F、G四个商品销量分别是80、80、60、70。这样的话家电的Top3是B(200)、C(150)、A(100)服饰的Top3中D和E并列第一都要保留。4.2 第一种解法子查询加窗口函数先聚合每个商品的销量然后用rank排序再嵌套一层取排名小于等于3的select category, sku_id, sku_name, total_cnt from ( select s.category, s.sku_id, s.sku_name, sum(o.sold_cnt) as total_cnt, rank() over (partition by s.category order by sum(o.sold_cnt) desc) as rk from sku_info s join order_detail o on s.sku_id o.sku_id group by s.category, s.sku_id, s.sku_name ) t where rk 3;这段SQL里最关键的是rank() over (partition by s.category order by sum(o.sold_cnt) desc)。这里直接在窗口函数里用了聚合函数sum(o.sold_cnt)和group by合用在Hive和Spark SQL里都是支持的算是一个比较高频的“聚合窗口组合”写法。我见过不少人在这个地方犯迷糊窗口函数里的order by能不能用聚合后的结果答案是可以但要注意它依赖group by对数据的预聚合如果聚合粒度没对上窗口排序的结果就会错。所以我在写这题时习惯先把聚合结果落到子查询里再把窗口函数包在外面这种写法的逻辑链路更清晰别人review代码时也更容易看懂。4.3 第二种解法用临时表拆解如果觉得嵌套可读性差可以拆分步骤先把聚合结果存到临时表再在临时表上做排序过滤。用Hive举例create table sku_sold_stat as select s.category, s.sku_id, s.sku_name, sum(o.sold_cnt) as total_cnt from sku_info s join order_detail o on s.sku_id o.sku_id group by s.category, s.sku_id, s.sku_name; select category, sku_id, sku_name, total_cnt from ( select category, sku_id, sku_name, total_cnt, rank() over (partition by category order by total_cnt desc) as rk from sku_sold_stat ) t where rk 3;这种写法的好处是方便调试如果你不确定聚合结果对不对可以先看一眼临时表数据再继续做排序。缺点是多了临时表/中间步骤在笔试白板环境里可能没有建表权限所以两种解法都要掌握。笔试题里如果要求“一条SQL实现”就选嵌套写法如果是在数仓开发场景里我会更倾向临时表拆解因为可维护性更高。这里还要提一下并列情况的实验验证如果服饰品类下D和E销量都是80用rank得到结果是1、1、3把排名1和3的两条都保留实际上会输出D、E、F三条记录符合“并列全部保留”的要求。如果用row_number只会随机保留一条就扣分了。5. 刷题过程中最常踩的坑我帮你列了一份排查清单5.1 SQL执行顺序的误区很多人写SQL时被各种报错或者错误结果折腾半天根源在于没搞懂SQL的逻辑执行顺序。虽然是“select”写在最前面但它的逻辑执行顺序其实是from - join - on - where - group by - having - select - distinct - order by - limit。这个顺序带来的一个典型坑是where里不能使用select里的别名。这不算大数据SQL特有的问题但面试里很常出现。在Hive里如果非要过滤聚合结果必须要用having或者再套一层子查询。我在实际review团队代码时经常看到新人写“where total_cnt 100”结果一直报错原因就是对执行顺序不熟。另一个和Hive强相关的误区是group by字段和select字段的一致性。传统MySQL允许select非聚合字段且不写全group by字段虽然关了only_full_group_by之后会报错但在Hive和Spark SQL里这个约束更严格select里出现的所有非聚合字段必须出现在group by里否则直接报错或结果随机。这个细节能让面试官快速判断你有没有大数据SQL的实际使用经验。5.2 数据倾斜最容易翻车、最考验经验的一环前面提到了数据倾斜这里展开说。面试题给的数据量都不大可能跑个几秒就出结果但在真实生产环境里一张动辄上亿行的表如果某个key的枚举值集中了绝大比例的数据计算就会非常慢甚至OOM。面试官在追问阶段经常会问“如果这个SQL在集群上跑挂了你会怎么排查”常用的排查思路有几个小表join大表时考虑使用mapjoin把维度表分发到各个map端如果大表join大表且关联键倾斜配合加盐随机前缀打散后做两阶段聚合group by聚合倾斜时先加盐做局部聚合再去掉盐做全局聚合如果某个业务的“0”值或其他默认值特别多要把这些值和正常值分开处理。比如统计全国某类商店的销售额如果把店铺ID作为分组字段而某个头部商家的订单量占了全网的30%以上这个分组就会严重倾斜。在群里的协作题集里这种优化点在多个题目下面都有提示但它更多需要在实际项目中反复体会。5.3 窗口函数和NULL的隐藏陷阱窗口函数是高频考点也是最容易出细节问题的点。一个常见的坑是partition by的字段中包含NULL时NULL会不会被分到同一个分组在Hive和Spark SQL里NULL会被分到同一个组但它和字符串的同组语义不太直观可能导致聚合结果里出现一条“NULL组”的额外记录和业务预期不符。解决手段是在开窗前对NULL做缺省值填充比如coalesce字段或转成默认值。另一个容易踩的坑是avg、sum这类聚合开窗函数遇到NULL时的行为。普通聚合函数会忽略NULL但窗口聚合函数在某些版本和引擎里对NULL的处理并不完全一致。比如计算“N日滑动平均”如果某天销售额是NULL直接开窗平均值可能导致结果被低估需要先用coalesce把NULL转成0或做排除。刷题时如果你发现参考答案和自己的结果差一点点先检查数据里是不是有NULL。5.4 笛卡尔积与自连接失控面试里考察join时有个隐藏深坑是“隐式笛卡尔积”。比如写join时漏了on条件或者在where里写关联条件但join里没写on在Hive里可能产生巨大的中间结果把作业跑挂。这个坑我在生产环境里遇到过一个同事写了两张千万级表的inner join结果两边关联条件写到了where里底层执行时先做了全量笛卡尔积再过滤跑了两个多小时还没结束。自连接也是。很多连续类、环比类题目的常规解法是“同一张表自己join自己”这在逻辑上没毛病但如果join后没有明确的行数控制或者没有利用分区和过滤条件性能会非常差。刷题题目里一般数据量小看不出代价但在面试追问环节说出“我会先在子查询里把数据量压缩再做自连接避免全量互关联”会明显拉高评分。5.5 结果不一致本地对集群跑出来不对有些人在本地用小数据集验证SQL没问题一放到集群上就结果出错最常见的原因就是数据分布不同规模下隐含的假设失效了。比如某些SQL依赖了行与行之间的物理顺序但在分布式环境里shuffle之后的行顺序是不保证的。如果不用窗口函数内显式指定的order by而直接依赖默认顺序结果必然不稳定。另一个隐蔽点是不稳定函数的使用。比如在Hive里获取随机值时如果用rand()作为join的关联键且没有固定种子每次运行的打散结果都不同会导致最终统计结果在多次运行间漂移。对这种题我的建议是每次跑完至少验证两遍如果结果不一致大概率是函数行为或者隐含依赖顺序出了问题。5.6 顺手整理一份速查表把上面这些坑整理成速查表单刷题前过一遍能少走很多弯路问题类型典型症状快速排查方向执行顺序where引用别名报错改为having或子查询数据倾斜作业长时间卡在某个stage检查分组key分布考虑加盐NULL分组聚合结果多出NULL组提前coalesce窗口函数行为结果与预期差一行检查是否需要显式order by自连接膨胀中间数据量爆炸先压缩数据再join结果不稳定两次运行结果不同检查rand()、物理顺序依赖6. 31个人协作整理的模式为什么值得学习6.1 协作流程收集、归类、验证、评审这份题集之所以叫“最强最全面”除了题目本身还因为31个人参与让它的质量和覆盖面有了明显提升。我了解了一下类似的协作流程大致可以分为四步题目收集、题型归类、解法验证、交叉评审。第一步是收集。每位参与者把自己在面试中遇到过的、或在业务中用过的经典SQL题发到协作群里。这个阶段不求题目整理得多么规范先保证“量”足够大。第二步是归类。有人负责把同类型的题合并比如“连续登录”相关的题可能有七八个变体合并成一道但保留多个延伸问法。第三步是验证。每个解法都必须实际跑过确保结果是正确的不能想当然。这一步尤其关键因为很多网上流传的SQL答案其实跑不通要么报错要么结果不对。第四步是交叉评审。每个人负责review几个不熟悉的题型提出优化和补充。这种协作方法放到任何一个技术知识库整理场景里都通用。它的核心价值在于“多双眼睛盯同一份内容”能把个人盲区大幅缩小。一个人整理题集时很容易只在自己擅长的领域深挖而31个人各有所长覆盖了窗口函数、UDF、性能优化、业务口径等多个细分方向最终成品更均衡。6.2 怎么用这份题集做面试冲刺光收藏不实操是没有意义的。我自己的刷题节奏是这样的分享出来给需要的朋友参考。第一遍通刷但不求快。按题型顺序每天固定花一小时先不看答案自己动手写SQL。写不出来没关系卡了十分钟后再看解析把卡壳点记下来。第二遍专项突破。把第一遍中错误率最高的题型拎出来比如连续问题和留存计算找同类型的变体题再练直到能独立写出正确SQL。第三遍模拟面试。随机抽题目用手写板或者纸上写完整SQL限制时间然后自己当面试官追问“为什么用rank不用row_number”“如果数据量增大10倍怎么办”。这套节奏走下来通常两到三周会有明显效果。题集里如果有一些同学标注了真实面试中遇到的口径描述我会额外关注那些题因为它们往往带有业务上下文更贴近面试难度。6.3 刷题之外更重要的一件事最后想多说一句。SQL题集刷得再熟也替代不了真实数据环境里的锤炼。我在带人的过程中反复强调面试题是“经过抽象后的干净问题”但工作里面对的是脏数据、慢任务、口径冲突和上下游依赖。刷题训练出的逻辑能力是基础但基础之上的环境适应能力、沟通确认能力和优化意识只能靠真实项目去积累。所以如果你是为了面试刷这份题集建议再配两个动作一是找一个可用的SQL运行环境把题集里所有题目都亲手跑一遍不要只看答案二是试着把每道题“改造成副作用版本”比如加上数据倾斜模拟、NULL注入、重复数据看看原解法还成不成立。这两个动作做完你对SQL的理解会比单纯刷三遍题集深很多。这份大数据SQL经典面试题合集确实帮到了很多人包括我自己团队里的几个新人。它的价值不在于背下多少道题而在于帮你建立一张清晰的知识网络。刷完题集之后你会发现自己看SQL的眼光不一样了看到一条复杂SQL脑子里会自动浮现它的执行路径、潜在风险和优化点。这个能力才是面试官真正想从SQL考察里挖出来的东西。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
