尧图网页设计 
1. 大数据面试到底在考什么——先把这个搞清楚再刷题说实话我在这个圈子里混了十几年面过的人少说也有几百个自己也换过几次工作。我观察到的最普遍现象是很多候选人刷题的方式完全跑偏了。有的人抱着LeetCode死磕hard题有的人把时间全花在背八股文上结果一到手写SQL或者聊项目细节就露馅。大数据岗位的笔试题和纯后端开发不一样。面试官想考察的东西其实非常集中SQL能力是绝对的底线分布式计算的原理是分水岭框架源码是加分项数据建模能力决定了你能不能干高级活。这篇文章我会结合真实面试中出现频率最高的题目把每个模块的核心考点、解题思路、以及我自己总结的避坑经验全部拆开讲。先给一个整体图谱大数据笔试题基本逃不出这几个方向SQL窗口函数、行转列列转行、留存率计算、连续登录问题、TopN问题Java集合源码、并发编程、JVM基础大数据岗考得比后端浅但集合和并发必考HDFS/YARN读写流程、架构设计思想、容错机制MapReduceShuffle机制、数据倾斜、Join策略SparkRDD/DataSet/DataFrame区别、宽窄依赖、Stage划分、调优、数据倾斜、ShuffleFlink状态管理、Checkpoint机制、窗口、精确一次性语义、背压数仓分层架构、维度建模、拉链表、缓慢变化维、事实表分类一句话总结SQL决定你能不能过笔试框架原理决定你能不能过技术面数仓和调优决定你能拿什么级别的offer。下面我按模块逐个拆解。2. SQL笔试题——大数据岗的命根子2.1 窗口函数必考中的必考不管你是面数仓岗、数据开发岗还是数据工程师SQL笔试第一题大概率是窗口函数。我甚至见过有些公司笔试题全部都是窗口函数搞了8道题全是rank、row_number、lag、lead的组合应用。窗口函数的本质就是在每一行上打开一个“窗口”在这个窗口范围内做计算。关键要分清over子句里的三个部分partition by决定窗口怎么切分order by决定窗口内怎么排序rows/range between决定窗口的边界范围。高频考点主要有这几类排名类rank()、dense_rank()、row_number()三兄弟的区别这个几乎是必问的。rank是跳跃排名比如两个人并列第一那第三名直接是3dense_rank是连续排名并列第一后第二名是2row_number是纯行号即使值一样也会强制分出先后。真实场景里取每个分组的前N条记录99%用的是row_number。前后行取值类lag()和lead()。计算环比、同比、会话时长、用户行为序列分析全靠这两个函数。lag是取上一行lead是取下一行第三个参数是默认值。聚合类sum()、avg()、count()配合over这类题通常用于计算累计值。累计求和是经典题要注意order by的排序字段如果存在重复值结果可能和预期不一样这个细节下面单独说。窗口边界类rows between unbounded preceding and current row是累计到当前行rows between 1 preceding and 1 current row是算移动平均。这类题在金融领域出现得很频繁。我在面试中经常问的一道经典题是统计每个用户连续登录天数。这题的精髓不在于窗口函数本身而在于用row_number生成序号后用登录日期减去序号得到“分组标识”差相同的行属于同一个连续区间。具体做法select user_id, group_id, count(*) as 连续天数 from ( select user_id, log_date, date_sub(log_date, row_number() over(partition by user_id order by log_date)) as group_id from user_login_log where log_date between 2025-01-01 and 2025-01-31 ) t group by user_id, group_id这个思路必须刻在脑子里。连续天数、连续签到、连续消费、连续活跃本质上都是这个套路。2.2 行转列与列转行SQL笔试的经典款行转列通常用case when配合聚合函数实现。举个最常见的例子统计每个用户在不同渠道的消费金额输出格式是一行一个用户每个渠道是一列。select user_id, sum(case when channel app then amount else 0 end) as app_amount, sum(case when channel web then amount else 0 end) as web_amount, sum(case when channel mini_program then amount else 0 end) as mini_amount from user_pay_records group by user_id;为什么用sum而不是max因为同一个用户同一个渠道可能有多条记录如果用max会丢失数据用sum才能保证金额累加正确。这个细节很多人会踩坑。列转行用的是union all或者lateral view explode。Hive/Spark SQL里用explode配合lateral view纯SQL或者MySQL里用union all硬拼。列转行在实际业务中出现的频率也很高比如把一行里的多个属性拆成多行做明细分析。2.3 留存率计算面试官最爱考的指标题留存率几乎是数仓岗笔试的必考大题。留存率的难点在于理解时间窗口的概念——留存N日是指某个时间点新增的用户在N天后仍然活跃的比例。以计算7日留存为例思路如下先圈出所有在某个时间窗口新增的用户记录其首日活跃日期然后关联这波用户在后续每一天的活跃记录用第7天的活跃人数除以首日新增人数得到7日留存率with new_users as ( select user_id, min(active_date) as first_active_date from user_active_log group by user_id ), active_log as ( select user_id, active_date from user_active_log where active_date 2025-01-01 ) select n.first_active_date as 新增日期, count(distinct n.user_id) as 新增用户数, count(distinct case when datediff(a.active_date, n.first_active_date) 6 then a.user_id end) as 第七日活跃人数, count(distinct case when datediff(a.active_date, n.first_active_date) 6 then a.user_id end) / count(distinct n.user_id) as 七日留存率 from new_users n left join active_log a on n.user_id a.user_id group by n.first_active_date;注意几个容易出错的地方新增用户表要先去重活跃日志表要过滤时间范围关联时用left join保证没有活跃记录的用户不会丢失留存率的计算要用distinct避免同一用户重复计数。2.4 如何提升SQL笔试的通过率我在真实笔试中总结出的经验SQL题答得好不好和刷题量有关系但和思路的清晰度关系更大。看到题目先花30秒思考“有几张表、数据粒度是什么、最终输出需要什么粒度”比着急忙慌写代码重要得多。提高准确率的具体建议所有的表先看主键搞清楚一张表的粒度用户表是一行一个用户订单表是一行一个订单明细表是一行一个行为写完SQL后用“脑内测试”法构造两三行假数据手动跑一遍逻辑看输出是否符合预期注意null的处理count(字段)不会统计nullcount(*)会这个区别可以救你一命join之前先确认关联键是否唯一一对多join会产生笛卡尔积导致数据膨胀这个bug非常隐蔽另外强烈建议每个准备面试的人把牛客SQL题库刷两遍第一遍按顺序做第二遍按题型刷。尤其是困难难度那一档里面的非等值join、自连接、嵌套子查询思路面试中真的会出现类似的。3. 大数据核心组件原理——从Hadoop到Spark的必背清单3.1 HDFS和YARN的高频题HDFS常考的点集中在读写流程和设计思想上。读写流程要能画出来、讲清楚每个环节的通信过程面试官会追问细节比如写数据时DataNode宕机了怎么办、副本因子怎么确定、机架感知的作用是什么。HDFS写流程的要点是客户端先向NameNode请求上传NameNode返回允许写入的DataNode列表然后客户端把数据按块写入第一个DataNode再由第一个DataNode以管道方式复制到第二、第三个DataNode。每写一个chunk就会通过Packet逐级反馈ack全部完成后客户端通知NameNode关闭文件。这个流程里有一个很容易被问到但大多数人答不出来的点为什么管道复制是“增量式”的因为客户端每写入一个chunk的数据就会立刻传给下一个DataNode同时自己也继续读下一个chunk这样网络传输和磁盘写入是重叠进行的吞吐量最优。如果等一个块全部写完了再复制效率会低一个数量级。HDFS为什么不适合存大量小文件因为NameNode把元数据存在内存里一个文件、一个目录、一个block都要占用约150字节的元数据空间。一亿个小文件会直接吃掉几个GB的内存而且读文件时需要频繁访问NameNode获取元数据瓶颈非常明显。解决办法是使用SequenceFile、ORC、Parquet等格式合并小文件或者用Hive的Concatenate、Spark的coalesce/repartition来归并。YARN的核心考点是ResourceManager的调度机制和Container的生命周期。理解YARN的关键在于区分“资源申请”和“任务执行”这两个流程。ApplicationMaster向ResourceManager申请资源拿到Container后启动Task任务结束后ApplicationMaster注销并释放资源。面试如果问到Spark on YARN的两种模式——client和cluster的区别本质区别在于Driver跑在哪里以及由谁负责申请资源。3.2 MapReduce的必考点Shuffle和数据倾斜MapReduce虽然在实际生产中越来越少直接写但它的Shuffle机制是整个分布式计算的基础面试必考。Shuffle就是把Map的输出按key分区、排序、合并后传输给Reduce的过程。完整流程Map端输出后先写入内存缓冲区默认100MB达到阈值后溢写磁盘溢写过程中做分区、排序、combiner可选然后Merge多个溢写文件形成一个大的混合文件同时做归并排序。Reduce端通过fetcher拉取属于自己的那部分数据然后做合并排序最后交给reduce函数处理。面试追问点通常是这几个为什么需要combiner它的本质是局部聚合在Map端先做一次reduce操作减少跨节点传输的数据量。combiner必须满足一个条件输入和输出的类型与reduce函数一致且多次应用combiner的结果与一次应用reduce一致。因为combiner涉及函数的幂等性不是所有reduce逻辑都能直接用combiner比如求平均值的reduce就不能直接做combiner为什么溢写前要做排序因为最终各节点数据需要合并成有序序列Map端先排序可以减轻Reduce端的排序压力整体效率更高数据倾斜的本质是某些key的数据量远大于其他key导致单个Reduce节点负载极高。缓解手段增加Reduce数量治标不治本、对key加随机前缀打散适合聚合类任务需要两阶段聚合、自定义Partitioner适合关联键分布极度不均的情况3.3 Spark Core的高频题RDD、依赖关系与Stage划分Spark面试题比Hadoop更多题量大、层次深。从基础概念到源码级追问都有可能我遇到过从“什么是RDD”一路问到“DAGScheduler怎么切分Stage”的连环炮式追问。RDD、DataFrame、DataSet的区别这道题很多人的回答是“RDD是弹性分布式数据集DataFrame有schemaDataSet强类型”但面试官想要的是一套能说明演进逻辑的回答。更好的答题框架是RDD是Spark 1.0时代的核心抽象提供了函数式编程接口缺点是Java/Scala类型安全差、缺乏自动优化、序列化开销大DataFrame在RDD之上引入了schema信息让Spark能通过Catalyst优化器做逻辑优化和物理优化性能大幅提升缺点是类型不安全编译期不报错运行期才发现DataSet结合了两者优点既有类型安全又能利用优化器但在实际开发中如果使用Spark SQL做数据加工直接操作DataFrame就够了写自定义UDF、UDAF时才更需要DataSet的类型安全宽窄依赖和Stage划分是Spark面试的绝对核心。窄依赖指父RDD的每个分区最多被子RDD的一个分区使用常见算子包括map、filter、union、coalesce宽依赖指父RDD的每个分区被子RDD的多个分区使用常见算子包括groupByKey、reduceByKey、join。宽依赖意味着ShuffleShuffle会产生磁盘IO和网络传输是Spark性能瓶颈的主要来源。Stage的划分规则是从后往前遇到宽依赖就切断生成一个新的Stage。DAGScheduler根据RDD的依赖关系构建DAG然后反向拓扑排序把stage切出来。每个Stage内部都是窄依赖算子串联可以流水线执行。面试官通常还会追问一句为什么窄依赖可以流水线执行因为窄依赖下父分区和子分区一一对应数据不需要跨节点传输可以直接在同一个Executor上连续执行多个算子。Spark数据倾斜是面试必问也会在系统设计题中出现。常见的倾斜表现是某个Stage卡住不动Spark UI上看某个Task处理的数据量明显偏大或OOM。解决思路按优先级排序过滤掉导致倾斜的异常key脏数据提高Shuffle并行度让每个Task处理的数据量变少两阶段聚合先加随机前缀将key打散做第一轮局部聚合去掉前缀再做第二轮聚合对倾斜的key单独处理把倾斜的key筛出来走广播Join不倾斜的key走普通Join使用广播变量替代shuffle join适用于小表关联大表的场景3.4 Flink的高频题状态、Checkpoint与精确一次Flink在笔试题中的比重逐年增加尤其是实时数仓岗位。常考的点集中在状态管理、Checkpoint机制、窗口操作、背压四个方面。状态管理主要考状态类型分类Keyed State和Operator State。Keyed State又分为ValueState、ListState、MapState、ReducingState、AggregatingState。要能说清楚状态存储后端MemoryStateBackend存TaskManager堆内存适合小状态、FsStateBackend状态存堆内、Checkpoint存文件系统、RocksDBStateBackend本地RocksDB存储适合超大状态。在真实生产环境中超大状态几乎必选RocksDB。Checkpoint机制的核心是Barrier对齐。Source端周期性地向数据流中插入Barrier每个算子收到Barrier后做状态快照多输入流的算子需要等待所有输入流的Barrier对齐后才能快照。面试追问通常集中在“Barrier不对齐怎么办”和“状态和外部系统的一致性怎么保证”这两个问题上。精确一次语义Exactly Once的实现机制Source端记录消费偏移量Sink端使用两阶段提交协议Checkpoint完成时触发预提交和正式提交。如果事务提交失败整个作业会回滚到上一个Checkpoint状态。Kafka Flink端到端精确一次的经典组合是Kafka作为Source记录offsetKafka/S3等支持事务的Sink配合TwoPhaseCommitSinkFunction实现。背压是另一个高频问题。Flink背压的核心机制是TaskManager之间通过netty通信当下游处理速度慢时上游发送端的buffer会积压导致发送速率自然下降。查看背压的方法是Web UI的BackPressure选项卡或者通过监控指标分析。Flink 1.13之后引入的基于Credit的反压机制能更精细地控制数据发送速率。面试答这道题的思路要落在“背压是系统自动调节机制不是错误状态”上。4. 数据仓库与建模题——高阶岗位的分水岭4.1 数仓分层架构为什么必须分层数仓分层这个知识点笔试和面试都是必考。标准分层是ODS操作数据存储层、DWD明细数据层、DWS汇总数据层、ADS应用数据层。有时候中间还会加一层DIM维度层和DIM公共维度层的变体但核心思想是一致的。分层的核心目的绝不是“为了好看”而是为了控制数据流向和复用。ODS层保持和源系统一致不做任何加工本意是保留原始数据用于追溯和重算。DWD层是清洗和规范化后的明细数据具备业务主题属性是后续所有表的加工源头。DWS层做轻度汇总把公共指标预计算好ADS层面向具体业务需求输出结果。面试官会问一张报表要查从ODS到ADS的完整链路各层分别做了什么这个问题的意义在于考察你是否真正理解每个层的职责。我常用的回答范例订单事实数据在ODS层是源系统原样接入的JSON串DWD层解析成结构化表并统一字段名和枚举值DWS层按天粒度汇总成订单维度的指标表ADS层直接查询DWS产出报表。4.2 维度建模事实表和维度表的设计原则维度建模的经典问题是什么是事实表、什么是维度表、如何区分。事实表记录业务过程和度量值通常是细粒度、不断增加、不更新的维度表描述业务过程的上下文环境通常是缓慢变化、可以更新的。事实表进一步细分为事务事实表、周期快照事实表、累积快照事实表。面试常问的是它们的使用场景区别事务事实表记录每笔业务事件如每笔订单适合分析业务过程周期快照事实表按固定频率记录状态如每天库存余额适合分析存量状态累积快照事实表记录业务过程的生命周期如订单从下单到签收的各阶段时间戳适合分析流程耗时。维度建模的另一组高频题是缓慢变化维的处理策略。类型1是直接覆盖不保留历史类型2是新增一行并加生效和失效时间保留完整历史类型3是增加一列存历史值保留有限历史。绝大多数业务场景选择类型2但要明确它的代价是维度表体积膨胀关联时要带上时间条件才能取到正确的版本。拉链表是面试手写SQL的常客。拉链表本质是类型2缓慢变化维的简化实现记录每个key在某个时间区间内的状态。写法上要注意开链和闭链的逻辑-- 新增和变更的数据通过union all合并 insert overwrite table dim_user_zip select ... -- 保留未变化的数据 union all select ... -- 新增的数据start_date 今天end_date 9999-12-31 union all -- 变更的数据将旧的记录end_date改为昨天 select ..., from dim_user_zip a join (select key, max(start_date) from ... group by key) b where a.key b.key and a.end_date 9999-12-31;这道题的坑在于一天内同一key可能发生多次变更需要在update旧记录时确保只更新当前那一条通常用start_date最大且end_date为9999来定位。4.3 指标体系设计从口径到命名规范数仓岗除了写SQL还会考指标体系的设计能力。题目通常给一个业务场景比如电商、网约车、内容平台让你设计核心指标和维度。重点不在于指标多而在于口径清晰、层级完整。以一个电商场景为例常见考核点GMV的口径是支付金额还是下单金额是否包含退款未支付订单怎么办活跃用户的口径按设备ID还是用户ID去重Web端和App端是否打通订单转化率的分母是UV还是访问次数这个必须在面试现场明确说明我见过太多候选人在指标口径上栽跟头根本原因是脑子里没有“需求方在问什么”的意识。回答指标设计题时先明确指标的业务含义和统计口径再拆分指标的影响因素如GMV UV × 转化率 × 客单价最后说明指标在数仓中的层级位置ODS/DWD/DWS/ADS哪一层加工。这个回答框架基本能覆盖90%的指标设计面试题。5. 实战策略如何高效准备大数据笔面试5.1 根据目标岗位分配优先级大数据岗位的细分方向差异很大如果盲目什么都学效率极低。以我面试过的经验来分类数仓开发岗SQL和数仓建模是绝对核心权重可能占70%。Hadoop、Spark原理是基础要求但深度不会特别深。面试官主要确认你能否独立完成从需求分析到模型设计再到SQL开发的全流程。数据开发/大数据工程师岗Spark和Hadoop的深度要求更高。SQL也是笔试必考但侧重点不同。通常会有场景题让你设计一个离线ETL的完整流程涉及存储格式选择、分区策略、任务调度、数据质量校验。实时计算岗Flink的深度要求极高。从状态后端选型到Checkpoint参数配置到端到端精确一次的实现原理都会考察。SQL考察以窗口函数、双流Join、维表关联为主。我的建议是先确定目标岗位再对照上面的优先级分配刷题和复习的时间。不用在低权重内容上死磕但要保证高权重内容能形成“肌肉记忆”级别的熟练度。5.2 如何在笔试中稳定发挥笔试现场和时间赛跑策略比蛮力更重要。我用过的一个很实用的方法是“时间预算法”拿到题目先全部扫一遍预估每道题的难度和用时按分数权重分配时间。SQL大题如果半小时没想出来先写一个可运行的初级版本保底再逐步优化至少不会交白卷。另一个非常实用的技巧是“分步验证”每写完一个query先用简单的where条件把数据量缩小到肉眼可验证的级别快速确认逻辑正确性再放开条件跑全量。笔试环境没有真实数据时可以用select x来验证语法和运行逻辑是否正确。答题时注意几个习惯命名字段时用易于理解的英文别名别直接用中文很多在线笔试系统对中文别名支持不好能用CTE就用CTE不要嵌套太多层子查询一是容易写错二是理不清逻辑SQL写完检查三个点表名和字段名是否拼对、join条件是否写全、group by是否包含所有非聚合字段5.3 面试官视角什么样的候选人能加分最后从面试官的角度说几个很少有候选人能做到的加分项这些在笔试中同样适用一是写SQL时主动考虑性能。我看到很多候选人的SQL能跑出正确答案但扫描了全表、做了大量无用计算。如果能在答案里注明“这里加一个分区过滤条件”或“这里先过滤再做join”立刻会加分不少。二是对数据质量的敏感度。写出的SQL能考虑到重复数据、null值、极端值的情况给处理逻辑做防御这种意识在真实业务中极其重要。笔试答案里如果体现了“先用row_number去重”或“把字段为null时给默认值”面试官对你的评价会明显提升。三是沟通表达的清晰度。笔试不是只有编码很多公司笔试会要求写解题思路。用简单的语言把逻辑说清楚比晒高级语法更能体现真实水平。6. 冲刺建议与个人经验分享先把个人经验说在前面这个行业的笔试确实越来越卷了尤其是头部互联网公司和大厂数仓岗SQL题目难度逐年上升场景题越来越多。但有一个好消息是高频考点其实是有限的翻来覆去就是SQL窗口函数、Hadoop/Spark原理、数据倾斜、数仓建模这几个方向。只要把这些方向的题彻底吃透笔试通过率会有质的飞跃。关于复习材料的推荐我个人的组合是SQL牛客SQL题库 力扣数据库题库双管齐下按题型刷两遍Hadoop/Spark从官方文档过一遍核心概念再看源码解析类文章重点看HDFS写流程、MapReduce Shuffle、Spark Stage划分和Shuffle机制数仓找一本维度建模的书通读然后去真实数据集上练手比如自己拉一份公开的订单数据设计一套完整的分层数仓模拟面试找朋友或者用AI工具进行模拟问答重点是训练“把原理讲清楚”的能力而不是背答案最后再分享一个我在面试中最常用的小技巧回答任何一道原理题都按照“业务场景引入 - 核心机制拆解 - 优缺点分析 - 实际应用建议”这个顺序组织语言。这个顺序的好处是让面试官感受到你有真正的实战经验而不是在背题。比如回答Spark宽窄依赖先说我遇到过的一个数据倾斜案例然后引出宽依赖导致Shuffle再对比窄依赖的流水线执行优势最后给出优化的具体建议。笔试没有捷径但一定有方法。把精力花在高频考点上每次刷题都当成一次技术输出的演练坚持一个月就能看到明显效果。希望这篇文章能帮你少走一些弯路在面试中拿到理想的结果。 大数据面试高频考点：SQL窗口函数、Spark原理与数仓建模全解析
1. 大数据面试到底在考什么——先把这个搞清楚再刷题说实话我在这个圈子里混了十几年面过的人少说也有几百个自己也换过几次工作。我观察到的最普遍现象是很多候选人刷题的方式完全跑偏了。有的人抱着LeetCode死磕hard题有的人把时间全花在背八股文上结果一到手写SQL或者聊项目细节就露馅。大数据岗位的笔试题和纯后端开发不一样。面试官想考察的东西其实非常集中SQL能力是绝对的底线分布式计算的原理是分水岭框架源码是加分项数据建模能力决定了你能不能干高级活。这篇文章我会结合真实面试中出现频率最高的题目把每个模块的核心考点、解题思路、以及我自己总结的避坑经验全部拆开讲。先给一个整体图谱大数据笔试题基本逃不出这几个方向SQL窗口函数、行转列列转行、留存率计算、连续登录问题、TopN问题Java集合源码、并发编程、JVM基础大数据岗考得比后端浅但集合和并发必考HDFS/YARN读写流程、架构设计思想、容错机制MapReduceShuffle机制、数据倾斜、Join策略SparkRDD/DataSet/DataFrame区别、宽窄依赖、Stage划分、调优、数据倾斜、ShuffleFlink状态管理、Checkpoint机制、窗口、精确一次性语义、背压数仓分层架构、维度建模、拉链表、缓慢变化维、事实表分类一句话总结SQL决定你能不能过笔试框架原理决定你能不能过技术面数仓和调优决定你能拿什么级别的offer。下面我按模块逐个拆解。2. SQL笔试题——大数据岗的命根子2.1 窗口函数必考中的必考不管你是面数仓岗、数据开发岗还是数据工程师SQL笔试第一题大概率是窗口函数。我甚至见过有些公司笔试题全部都是窗口函数搞了8道题全是rank、row_number、lag、lead的组合应用。窗口函数的本质就是在每一行上打开一个“窗口”在这个窗口范围内做计算。关键要分清over子句里的三个部分partition by决定窗口怎么切分order by决定窗口内怎么排序rows/range between决定窗口的边界范围。高频考点主要有这几类排名类rank()、dense_rank()、row_number()三兄弟的区别这个几乎是必问的。rank是跳跃排名比如两个人并列第一那第三名直接是3dense_rank是连续排名并列第一后第二名是2row_number是纯行号即使值一样也会强制分出先后。真实场景里取每个分组的前N条记录99%用的是row_number。前后行取值类lag()和lead()。计算环比、同比、会话时长、用户行为序列分析全靠这两个函数。lag是取上一行lead是取下一行第三个参数是默认值。聚合类sum()、avg()、count()配合over这类题通常用于计算累计值。累计求和是经典题要注意order by的排序字段如果存在重复值结果可能和预期不一样这个细节下面单独说。窗口边界类rows between unbounded preceding and current row是累计到当前行rows between 1 preceding and 1 current row是算移动平均。这类题在金融领域出现得很频繁。我在面试中经常问的一道经典题是统计每个用户连续登录天数。这题的精髓不在于窗口函数本身而在于用row_number生成序号后用登录日期减去序号得到“分组标识”差相同的行属于同一个连续区间。具体做法select user_id, group_id, count(*) as 连续天数 from ( select user_id, log_date, date_sub(log_date, row_number() over(partition by user_id order by log_date)) as group_id from user_login_log where log_date between 2025-01-01 and 2025-01-31 ) t group by user_id, group_id这个思路必须刻在脑子里。连续天数、连续签到、连续消费、连续活跃本质上都是这个套路。2.2 行转列与列转行SQL笔试的经典款行转列通常用case when配合聚合函数实现。举个最常见的例子统计每个用户在不同渠道的消费金额输出格式是一行一个用户每个渠道是一列。select user_id, sum(case when channel app then amount else 0 end) as app_amount, sum(case when channel web then amount else 0 end) as web_amount, sum(case when channel mini_program then amount else 0 end) as mini_amount from user_pay_records group by user_id;为什么用sum而不是max因为同一个用户同一个渠道可能有多条记录如果用max会丢失数据用sum才能保证金额累加正确。这个细节很多人会踩坑。列转行用的是union all或者lateral view explode。Hive/Spark SQL里用explode配合lateral view纯SQL或者MySQL里用union all硬拼。列转行在实际业务中出现的频率也很高比如把一行里的多个属性拆成多行做明细分析。2.3 留存率计算面试官最爱考的指标题留存率几乎是数仓岗笔试的必考大题。留存率的难点在于理解时间窗口的概念——留存N日是指某个时间点新增的用户在N天后仍然活跃的比例。以计算7日留存为例思路如下先圈出所有在某个时间窗口新增的用户记录其首日活跃日期然后关联这波用户在后续每一天的活跃记录用第7天的活跃人数除以首日新增人数得到7日留存率with new_users as ( select user_id, min(active_date) as first_active_date from user_active_log group by user_id ), active_log as ( select user_id, active_date from user_active_log where active_date 2025-01-01 ) select n.first_active_date as 新增日期, count(distinct n.user_id) as 新增用户数, count(distinct case when datediff(a.active_date, n.first_active_date) 6 then a.user_id end) as 第七日活跃人数, count(distinct case when datediff(a.active_date, n.first_active_date) 6 then a.user_id end) / count(distinct n.user_id) as 七日留存率 from new_users n left join active_log a on n.user_id a.user_id group by n.first_active_date;注意几个容易出错的地方新增用户表要先去重活跃日志表要过滤时间范围关联时用left join保证没有活跃记录的用户不会丢失留存率的计算要用distinct避免同一用户重复计数。2.4 如何提升SQL笔试的通过率我在真实笔试中总结出的经验SQL题答得好不好和刷题量有关系但和思路的清晰度关系更大。看到题目先花30秒思考“有几张表、数据粒度是什么、最终输出需要什么粒度”比着急忙慌写代码重要得多。提高准确率的具体建议所有的表先看主键搞清楚一张表的粒度用户表是一行一个用户订单表是一行一个订单明细表是一行一个行为写完SQL后用“脑内测试”法构造两三行假数据手动跑一遍逻辑看输出是否符合预期注意null的处理count(字段)不会统计nullcount(*)会这个区别可以救你一命join之前先确认关联键是否唯一一对多join会产生笛卡尔积导致数据膨胀这个bug非常隐蔽另外强烈建议每个准备面试的人把牛客SQL题库刷两遍第一遍按顺序做第二遍按题型刷。尤其是困难难度那一档里面的非等值join、自连接、嵌套子查询思路面试中真的会出现类似的。3. 大数据核心组件原理——从Hadoop到Spark的必背清单3.1 HDFS和YARN的高频题HDFS常考的点集中在读写流程和设计思想上。读写流程要能画出来、讲清楚每个环节的通信过程面试官会追问细节比如写数据时DataNode宕机了怎么办、副本因子怎么确定、机架感知的作用是什么。HDFS写流程的要点是客户端先向NameNode请求上传NameNode返回允许写入的DataNode列表然后客户端把数据按块写入第一个DataNode再由第一个DataNode以管道方式复制到第二、第三个DataNode。每写一个chunk就会通过Packet逐级反馈ack全部完成后客户端通知NameNode关闭文件。这个流程里有一个很容易被问到但大多数人答不出来的点为什么管道复制是“增量式”的因为客户端每写入一个chunk的数据就会立刻传给下一个DataNode同时自己也继续读下一个chunk这样网络传输和磁盘写入是重叠进行的吞吐量最优。如果等一个块全部写完了再复制效率会低一个数量级。HDFS为什么不适合存大量小文件因为NameNode把元数据存在内存里一个文件、一个目录、一个block都要占用约150字节的元数据空间。一亿个小文件会直接吃掉几个GB的内存而且读文件时需要频繁访问NameNode获取元数据瓶颈非常明显。解决办法是使用SequenceFile、ORC、Parquet等格式合并小文件或者用Hive的Concatenate、Spark的coalesce/repartition来归并。YARN的核心考点是ResourceManager的调度机制和Container的生命周期。理解YARN的关键在于区分“资源申请”和“任务执行”这两个流程。ApplicationMaster向ResourceManager申请资源拿到Container后启动Task任务结束后ApplicationMaster注销并释放资源。面试如果问到Spark on YARN的两种模式——client和cluster的区别本质区别在于Driver跑在哪里以及由谁负责申请资源。3.2 MapReduce的必考点Shuffle和数据倾斜MapReduce虽然在实际生产中越来越少直接写但它的Shuffle机制是整个分布式计算的基础面试必考。Shuffle就是把Map的输出按key分区、排序、合并后传输给Reduce的过程。完整流程Map端输出后先写入内存缓冲区默认100MB达到阈值后溢写磁盘溢写过程中做分区、排序、combiner可选然后Merge多个溢写文件形成一个大的混合文件同时做归并排序。Reduce端通过fetcher拉取属于自己的那部分数据然后做合并排序最后交给reduce函数处理。面试追问点通常是这几个为什么需要combiner它的本质是局部聚合在Map端先做一次reduce操作减少跨节点传输的数据量。combiner必须满足一个条件输入和输出的类型与reduce函数一致且多次应用combiner的结果与一次应用reduce一致。因为combiner涉及函数的幂等性不是所有reduce逻辑都能直接用combiner比如求平均值的reduce就不能直接做combiner为什么溢写前要做排序因为最终各节点数据需要合并成有序序列Map端先排序可以减轻Reduce端的排序压力整体效率更高数据倾斜的本质是某些key的数据量远大于其他key导致单个Reduce节点负载极高。缓解手段增加Reduce数量治标不治本、对key加随机前缀打散适合聚合类任务需要两阶段聚合、自定义Partitioner适合关联键分布极度不均的情况3.3 Spark Core的高频题RDD、依赖关系与Stage划分Spark面试题比Hadoop更多题量大、层次深。从基础概念到源码级追问都有可能我遇到过从“什么是RDD”一路问到“DAGScheduler怎么切分Stage”的连环炮式追问。RDD、DataFrame、DataSet的区别这道题很多人的回答是“RDD是弹性分布式数据集DataFrame有schemaDataSet强类型”但面试官想要的是一套能说明演进逻辑的回答。更好的答题框架是RDD是Spark 1.0时代的核心抽象提供了函数式编程接口缺点是Java/Scala类型安全差、缺乏自动优化、序列化开销大DataFrame在RDD之上引入了schema信息让Spark能通过Catalyst优化器做逻辑优化和物理优化性能大幅提升缺点是类型不安全编译期不报错运行期才发现DataSet结合了两者优点既有类型安全又能利用优化器但在实际开发中如果使用Spark SQL做数据加工直接操作DataFrame就够了写自定义UDF、UDAF时才更需要DataSet的类型安全宽窄依赖和Stage划分是Spark面试的绝对核心。窄依赖指父RDD的每个分区最多被子RDD的一个分区使用常见算子包括map、filter、union、coalesce宽依赖指父RDD的每个分区被子RDD的多个分区使用常见算子包括groupByKey、reduceByKey、join。宽依赖意味着ShuffleShuffle会产生磁盘IO和网络传输是Spark性能瓶颈的主要来源。Stage的划分规则是从后往前遇到宽依赖就切断生成一个新的Stage。DAGScheduler根据RDD的依赖关系构建DAG然后反向拓扑排序把stage切出来。每个Stage内部都是窄依赖算子串联可以流水线执行。面试官通常还会追问一句为什么窄依赖可以流水线执行因为窄依赖下父分区和子分区一一对应数据不需要跨节点传输可以直接在同一个Executor上连续执行多个算子。Spark数据倾斜是面试必问也会在系统设计题中出现。常见的倾斜表现是某个Stage卡住不动Spark UI上看某个Task处理的数据量明显偏大或OOM。解决思路按优先级排序过滤掉导致倾斜的异常key脏数据提高Shuffle并行度让每个Task处理的数据量变少两阶段聚合先加随机前缀将key打散做第一轮局部聚合去掉前缀再做第二轮聚合对倾斜的key单独处理把倾斜的key筛出来走广播Join不倾斜的key走普通Join使用广播变量替代shuffle join适用于小表关联大表的场景3.4 Flink的高频题状态、Checkpoint与精确一次Flink在笔试题中的比重逐年增加尤其是实时数仓岗位。常考的点集中在状态管理、Checkpoint机制、窗口操作、背压四个方面。状态管理主要考状态类型分类Keyed State和Operator State。Keyed State又分为ValueState、ListState、MapState、ReducingState、AggregatingState。要能说清楚状态存储后端MemoryStateBackend存TaskManager堆内存适合小状态、FsStateBackend状态存堆内、Checkpoint存文件系统、RocksDBStateBackend本地RocksDB存储适合超大状态。在真实生产环境中超大状态几乎必选RocksDB。Checkpoint机制的核心是Barrier对齐。Source端周期性地向数据流中插入Barrier每个算子收到Barrier后做状态快照多输入流的算子需要等待所有输入流的Barrier对齐后才能快照。面试追问通常集中在“Barrier不对齐怎么办”和“状态和外部系统的一致性怎么保证”这两个问题上。精确一次语义Exactly Once的实现机制Source端记录消费偏移量Sink端使用两阶段提交协议Checkpoint完成时触发预提交和正式提交。如果事务提交失败整个作业会回滚到上一个Checkpoint状态。Kafka Flink端到端精确一次的经典组合是Kafka作为Source记录offsetKafka/S3等支持事务的Sink配合TwoPhaseCommitSinkFunction实现。背压是另一个高频问题。Flink背压的核心机制是TaskManager之间通过netty通信当下游处理速度慢时上游发送端的buffer会积压导致发送速率自然下降。查看背压的方法是Web UI的BackPressure选项卡或者通过监控指标分析。Flink 1.13之后引入的基于Credit的反压机制能更精细地控制数据发送速率。面试答这道题的思路要落在“背压是系统自动调节机制不是错误状态”上。4. 数据仓库与建模题——高阶岗位的分水岭4.1 数仓分层架构为什么必须分层数仓分层这个知识点笔试和面试都是必考。标准分层是ODS操作数据存储层、DWD明细数据层、DWS汇总数据层、ADS应用数据层。有时候中间还会加一层DIM维度层和DIM公共维度层的变体但核心思想是一致的。分层的核心目的绝不是“为了好看”而是为了控制数据流向和复用。ODS层保持和源系统一致不做任何加工本意是保留原始数据用于追溯和重算。DWD层是清洗和规范化后的明细数据具备业务主题属性是后续所有表的加工源头。DWS层做轻度汇总把公共指标预计算好ADS层面向具体业务需求输出结果。面试官会问一张报表要查从ODS到ADS的完整链路各层分别做了什么这个问题的意义在于考察你是否真正理解每个层的职责。我常用的回答范例订单事实数据在ODS层是源系统原样接入的JSON串DWD层解析成结构化表并统一字段名和枚举值DWS层按天粒度汇总成订单维度的指标表ADS层直接查询DWS产出报表。4.2 维度建模事实表和维度表的设计原则维度建模的经典问题是什么是事实表、什么是维度表、如何区分。事实表记录业务过程和度量值通常是细粒度、不断增加、不更新的维度表描述业务过程的上下文环境通常是缓慢变化、可以更新的。事实表进一步细分为事务事实表、周期快照事实表、累积快照事实表。面试常问的是它们的使用场景区别事务事实表记录每笔业务事件如每笔订单适合分析业务过程周期快照事实表按固定频率记录状态如每天库存余额适合分析存量状态累积快照事实表记录业务过程的生命周期如订单从下单到签收的各阶段时间戳适合分析流程耗时。维度建模的另一组高频题是缓慢变化维的处理策略。类型1是直接覆盖不保留历史类型2是新增一行并加生效和失效时间保留完整历史类型3是增加一列存历史值保留有限历史。绝大多数业务场景选择类型2但要明确它的代价是维度表体积膨胀关联时要带上时间条件才能取到正确的版本。拉链表是面试手写SQL的常客。拉链表本质是类型2缓慢变化维的简化实现记录每个key在某个时间区间内的状态。写法上要注意开链和闭链的逻辑-- 新增和变更的数据通过union all合并 insert overwrite table dim_user_zip select ... -- 保留未变化的数据 union all select ... -- 新增的数据start_date 今天end_date 9999-12-31 union all -- 变更的数据将旧的记录end_date改为昨天 select ..., from dim_user_zip a join (select key, max(start_date) from ... group by key) b where a.key b.key and a.end_date 9999-12-31;这道题的坑在于一天内同一key可能发生多次变更需要在update旧记录时确保只更新当前那一条通常用start_date最大且end_date为9999来定位。4.3 指标体系设计从口径到命名规范数仓岗除了写SQL还会考指标体系的设计能力。题目通常给一个业务场景比如电商、网约车、内容平台让你设计核心指标和维度。重点不在于指标多而在于口径清晰、层级完整。以一个电商场景为例常见考核点GMV的口径是支付金额还是下单金额是否包含退款未支付订单怎么办活跃用户的口径按设备ID还是用户ID去重Web端和App端是否打通订单转化率的分母是UV还是访问次数这个必须在面试现场明确说明我见过太多候选人在指标口径上栽跟头根本原因是脑子里没有“需求方在问什么”的意识。回答指标设计题时先明确指标的业务含义和统计口径再拆分指标的影响因素如GMV UV × 转化率 × 客单价最后说明指标在数仓中的层级位置ODS/DWD/DWS/ADS哪一层加工。这个回答框架基本能覆盖90%的指标设计面试题。5. 实战策略如何高效准备大数据笔面试5.1 根据目标岗位分配优先级大数据岗位的细分方向差异很大如果盲目什么都学效率极低。以我面试过的经验来分类数仓开发岗SQL和数仓建模是绝对核心权重可能占70%。Hadoop、Spark原理是基础要求但深度不会特别深。面试官主要确认你能否独立完成从需求分析到模型设计再到SQL开发的全流程。数据开发/大数据工程师岗Spark和Hadoop的深度要求更高。SQL也是笔试必考但侧重点不同。通常会有场景题让你设计一个离线ETL的完整流程涉及存储格式选择、分区策略、任务调度、数据质量校验。实时计算岗Flink的深度要求极高。从状态后端选型到Checkpoint参数配置到端到端精确一次的实现原理都会考察。SQL考察以窗口函数、双流Join、维表关联为主。我的建议是先确定目标岗位再对照上面的优先级分配刷题和复习的时间。不用在低权重内容上死磕但要保证高权重内容能形成“肌肉记忆”级别的熟练度。5.2 如何在笔试中稳定发挥笔试现场和时间赛跑策略比蛮力更重要。我用过的一个很实用的方法是“时间预算法”拿到题目先全部扫一遍预估每道题的难度和用时按分数权重分配时间。SQL大题如果半小时没想出来先写一个可运行的初级版本保底再逐步优化至少不会交白卷。另一个非常实用的技巧是“分步验证”每写完一个query先用简单的where条件把数据量缩小到肉眼可验证的级别快速确认逻辑正确性再放开条件跑全量。笔试环境没有真实数据时可以用select x来验证语法和运行逻辑是否正确。答题时注意几个习惯命名字段时用易于理解的英文别名别直接用中文很多在线笔试系统对中文别名支持不好能用CTE就用CTE不要嵌套太多层子查询一是容易写错二是理不清逻辑SQL写完检查三个点表名和字段名是否拼对、join条件是否写全、group by是否包含所有非聚合字段5.3 面试官视角什么样的候选人能加分最后从面试官的角度说几个很少有候选人能做到的加分项这些在笔试中同样适用一是写SQL时主动考虑性能。我看到很多候选人的SQL能跑出正确答案但扫描了全表、做了大量无用计算。如果能在答案里注明“这里加一个分区过滤条件”或“这里先过滤再做join”立刻会加分不少。二是对数据质量的敏感度。写出的SQL能考虑到重复数据、null值、极端值的情况给处理逻辑做防御这种意识在真实业务中极其重要。笔试答案里如果体现了“先用row_number去重”或“把字段为null时给默认值”面试官对你的评价会明显提升。三是沟通表达的清晰度。笔试不是只有编码很多公司笔试会要求写解题思路。用简单的语言把逻辑说清楚比晒高级语法更能体现真实水平。6. 冲刺建议与个人经验分享先把个人经验说在前面这个行业的笔试确实越来越卷了尤其是头部互联网公司和大厂数仓岗SQL题目难度逐年上升场景题越来越多。但有一个好消息是高频考点其实是有限的翻来覆去就是SQL窗口函数、Hadoop/Spark原理、数据倾斜、数仓建模这几个方向。只要把这些方向的题彻底吃透笔试通过率会有质的飞跃。关于复习材料的推荐我个人的组合是SQL牛客SQL题库 力扣数据库题库双管齐下按题型刷两遍Hadoop/Spark从官方文档过一遍核心概念再看源码解析类文章重点看HDFS写流程、MapReduce Shuffle、Spark Stage划分和Shuffle机制数仓找一本维度建模的书通读然后去真实数据集上练手比如自己拉一份公开的订单数据设计一套完整的分层数仓模拟面试找朋友或者用AI工具进行模拟问答重点是训练“把原理讲清楚”的能力而不是背答案最后再分享一个我在面试中最常用的小技巧回答任何一道原理题都按照“业务场景引入 - 核心机制拆解 - 优缺点分析 - 实际应用建议”这个顺序组织语言。这个顺序的好处是让面试官感受到你有真正的实战经验而不是在背题。比如回答Spark宽窄依赖先说我遇到过的一个数据倾斜案例然后引出宽依赖导致Shuffle再对比窄依赖的流水线执行优势最后给出优化的具体建议。笔试没有捷径但一定有方法。把精力花在高频考点上每次刷题都当成一次技术输出的演练坚持一个月就能看到明显效果。希望这篇文章能帮你少走一些弯路在面试中拿到理想的结果。