先说结论这份笔试题B覆盖的面几乎就是当时大数据开发岗的“标准考纲”——Hadoop 生态核心组件原理、离线与实时计算框架、数据仓库建模、SQL 能力、系统设计场景题再加少量 Java 基础。虽然名字叫“爱奇艺 2019 秋招”但它对现在准备大数据开发面试的人依然有很强的参考价值。我当时做完这套题的最大感受是题目不算偏但很考验“你到底是真的用过还是仅仅背过八股”。很多题看起来是概念题实际答起来会发现凡是没在集群上踩过坑的人很容易在某个细节上卡住。这篇文章就把这套题拆开结合我记得的一些重难点和自己的复盘把考点、答题思路、还有这背后面试官到底想看什么一次性说清楚。1. 这份笔试题到底在考什么爱奇艺大数据开发岗的能力坐标系先聊整体。很多人拿到大数据笔试题就慌觉得知识点多到复习不完。但如果你站在出题人的角度想爱奇艺这种体量的视频平台大数据开发要干的事其实很明确离线的报表和数仓、实时的推荐和运营反馈、用户行为日志的清洗与统计以及支撑这些业务的数据平台组件维护。业务画像一旦清晰考点就锁定了。1.1 岗位职责与考察方向的对应关系回忆一下我当时看到的岗位 JD核心关键词是Hadoop、Spark、Flink、Kafka、Hive、HBase加上“数据仓库建模”“实时计算”“调优”等。这基本对应了大数据开发的日常工作流数据接入层用 Flume / Kafka 收集日志能说清楚数据怎么落地、怎么保证不丢、怎么处理重复。离线计算层用 Hive / Spark 跑 T1 的报表任务能写 SQL懂分区、分桶知道数据倾斜怎么处理。实时计算层用 Flink / Spark Streaming 算实时指标理解窗口、状态、checkpoint 这些概念。数据服务层把结果写到 HBase / MySQL / Redis 供业务查询需要明白随机读写的原理。平台支撑HDFS、YARN、Zookeeper 这些基础组件的原理是排查问题的底层能力。所以这份笔试题B看着散实际上就是围绕“一个从日志产生到最终数据服务”的链路来出题的。你复习的时候如果脑子里没有这条链路就会觉得东一榔头西一棒子。1.2 从考试结构反推复习优先级我记得这份卷子大致有这几类单选/多选、简答、SQL 题和场景设计题。不同题型的复习权重应该完全不同题型主要考察能力复习优先级选择题基础组件原理、概念辨析高用于快速过知识点简答题框架运行机制、流程描述高需要能写清楚步骤SQL 题窗口函数、行列转换、UV 统计极高几乎必考场景设计题业务理解 技术选型 架构能力极高拉开差距的关键一个很残酷的现实是选择题偶而能蒙简答题也能背个大概但 SQL 题和场景设计题一旦没真做过很容易彻底卡住。这也是我和很多一起面试的人交流后共同的感受。1.3 爱奇艺的业务场景决定了出题风格爱奇艺是视频平台所以它的数据有非常明显的特点海量用户行为日志、高并发访问、实时性要求高、数据格式多样化。你在做它的场景题时如果能主动结合“视频 APP 的业务特性”来回答效果会好很多。比如统计播放量、分析用户留存、计算热门榜单这些都是视频平台典型场景答题时结合埋点、日志采集、多级缓存等思路来设计踩中得分点的概率会更大。2. 笔试核心考点拆解组件原理与框架机制这套题里分量最重的部分就是基础组件和计算框架的原理。这部分不光是记忆很多题喜欢给一个模糊描述问“哪个组件负责什么”或者在某个环节加一个“如果发生故障会怎样”。下面我把高频考点逐个拆开结合我当时的答题思路和后来的实际经验来讲。2.1 HDFS 与 Hadoop 基础别只背“主从架构”HDFS 一定是选择题和简答题的重灾区。要知道的不只是“NameNode 管元数据、DataNode 存数据”这种一句话概念而是要能画出读写流程图。特别是HDFS 写文件流程几乎每个面试官都爱问客户端先跟 NameNode 通信创建文件NameNode 校验权限和路径返回可用的 DataNode 列表客户端再分块默认 128MB写入写完一个块要形成 pipeline 复制到副本节点最后关闭流并通知 NameNode。这里有两个容易被问倒的细节副本放置策略同机架不同节点优先其次同数据中心不同机架再次跨数据中心。这个决定了容错和带宽消耗的平衡。小文件问题大量小文件会占满 NameNode 堆内存因为每个文件、目录、块都要在内存里维护元数据。爱奇艺这种每天日志量巨大的平台对文件数量的控制要求非常高所以答题时最好主动提到“小文件治理”。我当时在试卷里遇到一道关于“写入过程中 DataNode 宕机”的处理流程这题光背八股答不全。实际上pipeline 中的 DataNode 宕机后上游节点会从管线中移除它并把已确认写入的块信息上报给 NameNodeNameNode 会在后续触发副本复制。能答到这一层说明你真的理解副本机制。2.2 Zookeeper 与 Kafka分布式协调和消息队列的联考这两兄弟在选择题里往往会一起出现。Zookeeper 的核心考点是leader 选举机制基于 ZAB 协议只有超过半数节点同意才能选主所以集群通常是奇数台。节点类型持久节点、临时节点、顺序节点对应不同使用场景。watcher 监听机制为什么用推拉结合而不是纯推送。Kafka 的考点更多、更细分区与消费组一个分区同一时间只能被同一个消费组内的一个消费者消费这是 Kafka 实现并行消费和顺序保证的关键。消息可靠性acks0、1、-1all的区别和生产者的 retries、消费者的 enable.auto.commit 怎么配合。offset 管理老版本存在 Zookeeper 里新版本存在 Kafka 内部 topic__consumer_offsets里。提示回答 Kafka 可靠性时最好把生产者、broker、消费者三个维度分开讲然后再说明需要结合起来才能做到端到端的“不丢不重”。只答“acksall”是拿不全分的。我印象很深的是这套卷里有一道题问“Kafka 如何保证消息不丢失”很多人只写了 producer 端设置 acks-1但忽略了 broker 端的 min.insync.replicas、消费者端关闭自动提交 offset 这些配合项。这在真实场景里确实是个联动问题答全了对面试官来说是个加分信号。2.3 离线计算MapReduce Shuffle 与 Spark 核心机制离线计算是笔试里的重头戏。MapReduce 那边Shuffle 机制是必考中的必考map 端输出 - 分区排序 - 溢写 - merge - reduce 端拉取 - 合并排序 - reduce 函数。每一步都有很多细节比如 combiner 不能乱用求平均值时就不行、自定义 WritableComparable 为什么要有无参构造、分区数和 reduce 数的对应关系等。Spark 这边的必考点更密集RDD 血缘关系与容错为什么 lineage 比 checkpoint 代价低什么时候才需要 checkpoint长 lineage 或 shuffle 依赖。宽依赖与窄依赖判断标准是父 RDD 的一个分区是否被多个子 RDD 分区使用这决定了 Stage 划分和容错方式。Stage 划分遇到宽依赖就切断生成新的 Stage。笔试容易给一个算子链问你分成几个 Stage。算子区别map vs mapPartitions、reduceByKey vs groupByKey、coalesce vs repartition。每个对比都要能从源码原理和适用场景两个角度说。我当时答这道题时特别强调了reduceByKey 和 groupByKey 的本质区别reduceByKey 在 map 端先做一次局部聚合数据量大幅减少后才 shufflegroupByKey 则把所有原始数据全部 shuffle代价高。实际调优时能用 reduceByKey 就不选 groupByKey这是最基本的优化规则。2.4 实时计算Flink 的窗口与状态2019 年那会儿 Flink 已经非常热这套题涉及 Flink 并不意外。核心考点集中在窗口机制滚动窗口、滑动窗口、会话窗口的区别以及事件时间Event Time和处理时间Processing Time的对比。Watermark 的理解它本质是“时间进度”的标记用来触发窗口计算和解决乱序问题。还经常会问 watermark 设置的延迟时间和 allowedLateness 的区别。Checkpoint 与状态后端Flink 如何通过 barrier 机制做分布式快照状态是存在内存、文件系统还是 RocksDB。这里最好能答出 exactly-once 的语义保障和两阶段提交。注意这类题目容易混淆的是“窗口的触发条件”。很多人以为定时触发的窗口就是处理时间窗口其实事件时间窗口也可以定时只是触发的依据是 watermark 是否越过窗口结束时间。能把这个概念区分清楚基本上可以压制绝大多数候选人了。我记得这道题我回答得很细因为我那阵子刚用 Flink 做过一个实时指标项目对 watermark 和 barrier 有真实的理解写起来不会像背书。这一点也是我想跟读者强调的框架原理光看不行最好真去跑一个任务哪怕是本地小 demo。2.5 数据仓库与 Hive建模思维和 SQL 能力数仓建模和 Hive 是笔试题里相当“实在”的部分。爱奇艺这种公司对数据仓库的需求很典型用户行为、播放明细、会员订单、广告投放这些数据要组织成一系列分层表供分析和算法使用。考点包括数仓分层ODS原始数据层、DWD明细数据层、DWS汇总数据层、ADS应用数据层每层的职责是什么为什么要分层。维度建模星型模型和雪花模型的区别事实表和维度表的划分缓慢变化维SCD的处理策略。Hive 表类型内部表 vs 外部表、分区表 vs 分桶表。尤其外包表删除时 HDFS 数据是否保留这题经常有人做错。Hive 数据倾斜group by 时某个 key 特别大导致的倾斜常见解法有加随机前缀打散、两阶段聚合、map 端聚合combiner等。SQL 题我用一个单独的小节来讲因为它的权重实在太高。3. 高频题型与典型答题思路复盘题型不同答题节奏完全不同。这块我按自己的考后回忆把印象深的高频题型和套路总结一下每类题都给了可落地的答题模板尤其适合笔试时间紧、没时间现场想框架的读者。3.1 概念辨析题先给结论再讲原理最后举例这类题喜欢出成“下列哪个说法正确/错误”。比如“Spark 中的 reduceByKey 一定比 groupByKey 快”“Kafka 的消费者组内消费者数量一定不能超过分区数”“HDFS 支持随机修改文件内容”。做这类题的心法很简单先定位到具体组件的具体机制再根据你对机制的掌握做判断。举个例子“HDFS 支持随机修改文件内容”是经典的错误选项。HDFS 设计为一次写入、多次读取支持 append 追加但不支持像本地文件系统那样随机修改偏移量。要答好这个问题你得理解 HDFS 数据块的组织方式——块被创建后 immutable修改需要重写整个块这对大规模存储是不可接受的。如果试卷让“说明原因”我会从块机制和追加写模型两个角度答。3.2 场景设计题画链路、选组件、说方案场景设计题是拉分题。我来重建一道我当时比较有把握的题“请设计一个方案统计全网每日视频播放量 Top100 榜单要求实时性在分钟级。”我的回答框架是数据接入客户端埋点上报播放事件写入消息队列 Kafka。根据播放行为频率估算 QPS确定 Kafka 分区数和 broker 数。实时计算Flink 消费 Kafka按照 video_id 做 keyBy开 1 分钟滚动窗口或者 5 分钟窗口在窗口内聚合播放次数。结果存储聚合后的分钟级结果写入 Rediszset 结构或者写入 HBase 然后通过批量任务合并到 MySQL / ES。TopN 计算因为我们是按 video_id 维度聚合后再取 Top100可以避免在全量明细上排序。Redis zset 天然支持 rank 操作适合这种场景。容错与去重播放事件如果带有用户 ID 和 session ID需要在窗口内做 distinctCount 或至少用 Flink 的状态做去重。如果只是播放次数近似值可以用 HyperLogLog。这题没有标准答案但评分标准很明确是否分模块考虑、是否说明组件选型理由、是否处理去重和容错、是否考虑业务边界条件比如同一个用户连续刷新算不算多次播放。我当时联想到爱奇艺的业务还会有“试播和正片分开统计”“短剧和长剧的播放口径不同”等问题主动说明“需要和业务确认播放口径”这一点我觉得很加分。3.3 SQL 编程题窗口函数是永远的神大数据笔试的 SQL 题难度通常集中在这三类分组 TopN经典题“取每个部门工资最高的员工”。解法是用 ROW_NUMBER() OVER(PARTITION BY dept_id ORDER BY salary DESC)然后过滤出排名为 1 的记录。行转列 / 列转行多个 key-value 结构如何展开或合并一般要用 CASE WHEN 或 explode lateral view。连续问题 / 留存问题连续登录天数、次日留存率。这类题在爱奇艺这种运营驱动型公司特别常见。我演示一道典型题和答案题目有一张播放记录表 play_record(user_id, video_id, play_date)求 2024 年 5 月每个用户每天的播放次数以及每个用户当月的累计播放次数。SELECT user_id, play_date, COUNT(*) AS day_play_cnt, SUM(COUNT(*)) OVER(PARTITION BY user_id ORDER BY play_date) AS month_cum_cnt FROM play_record WHERE play_date BETWEEN 2024-05-01 AND 2024-05-31 GROUP BY user_id, play_date;核心是用开窗函数对 group by 之后的聚合结果再做一次累计求和。如果没有窗口函数你需要自连接或子查询又慢又容易错。这道题还想提醒一个小技巧窗口函数的执行顺序是先 group by 再开窗很多人在理解上搞反。3.4 故障排查与优化题从现象推原因再谈解决方案这类题是笔试中比较“高级”的考法。比如“某 Spark 任务一直运行很慢且发现某些 executor 的 GC 时间特别长可能是什么原因怎么排查”我一般会按“查看现象 - 定位瓶颈 - 给出措施 - 复盘预防”的顺序来答现象分析某个 executor GC 时间过长往往是数据倾斜导致单个 task 处理的数据量过大持有了大量对象无法释放。定位手段去 Spark UI 看各 stage 的 task 耗时分布和输入数据量如果某个 task 的 input 数据量明显高于其他 task就是数据倾斜。解决思路如果是 group by 导致的倾斜用加盐随机前缀两阶段聚合如果是 join 导致的倾斜考虑把热点 key 拆出来广播小表或者单独处理如果只是 executor 内存不足可以调大 spark.executor.memory 并配合调整 spark.memory.storageFraction 等参数。预防措施在代码里对 key 分布做前置统计上线前用中量数据做压测。这类题贵在“讲出流程”而不是“背出参数”。做题时我会把分析过程写成逻辑链条让阅卷人一眼看出我是真的排查过问题而不是背了一堆配置项。4. 这些题目背后的面试官视角为什么这么考刷完这套题我更在意的不是对了几道而是“爱奇艺到底想要什么样的人”。想明白这一点对以后准备面试会很有方向感。4.1 原理比工具重要因为工具会变爱奇艺 2019 年的时候实时计算正在从 Spark Streaming 往 Flink 迁移今天看来依然如此——新技术层出不穷但分布式计算的基本模型没变存储与计算分离、shuffle、容错、一致性。所以试卷里大量考察原理和机制而不是让你背诵某个 API 的签名。我记得当时有一道题问“Spark 和 MapReduce 的区别”其实更看重的是你能不能从“计算模型”的层面去比较MapReduce 每一步都要落盘Spark 基于内存做 DAG 计算两者在 shuffle 的物化策略、迭代计算效率、容错粒度上都有本质不同。能答到这种抽象层度说明你不是只会调工具是做工程的人。4.2 场景题考的是“业务转化为技术”的能力对一家视频公司来说数据开发不是纯技术活。你要能听懂产品经理说的“我们要看用户的完播率”然后转化成“对播放明细表按 user_id 和 video_id 聚合统计播放时长/视频总时长的分布”这样的技术方案。这套题的场景题本质上就是考察这种转化能力。我在笔试中写方案时习惯先明确指标口径再选技术组件最后画数据流转链路。这样做的好处是即使技术选型不完美阅卷人也能看出你的思考是有结构的。而且我在结尾总要补一句“需要结合业务确认指标口径”这在真实工作里是非常重要的一步却常常被校招同学忽略。4.3 代码题考的是工程规范和细节SQL 和 Java/Python 代码题考的不只是“写对”还有“写得规范”。比如 SQL 里有没有加分区条件过滤是不是用了 SELECT *join 时是不是注意了 null 值处理。大数据的笔试代码量不大但每道题都有可以优化的细节。阅卷人如果是资深工程师一眼就能看出这个候选人在生产环境里有没有写过代码。我自己的一个体会是代码题宁可多写几行注释也不要为了显得厉害写复杂的表达式。评卷时能看懂你是第一步简洁清晰的逻辑比炫技重要太多。5. 备考这套题的方法、答题策略和我踩过的坑最后这部分写给正在准备大数据开发方向校招或跳槽的读者。我把自己备考和实际笔试中总结的经验整理成清单希望能省下你一些摸索的时间。5.1 准备这份考题的实用学习路线如果只给一条主线我会建议按下面的顺序准备搭建一个简单的集群环境比如用 Docker 起一个 Hadoop Hive Spark 的伪分布式环境把数据链路从头跑通生成日志 - Flume/Kafka - Hive/Spark - MySQL。每个组件学完用中文写一篇自己的原理笔记讲清楚“它解决什么问题、有哪些核心概念、一个请求从进入到返回发生了什么”。集中刷 SQL 题尤其是窗口函数相关的练习题每个类型至少练 3 遍。看一遍生产环境中的调优案例比如网上很多人分享的 Spark 内存调优、Flink 反压处理不用记住所有参数但要能说出优化思路。自拟 5 个场景设计题按“接入层 - 计算层 - 存储层 - 服务层”的框架写方案反复打磨。提示我不是很建议直接去背网上的“大数据面试 300 题”。刷题的意义不是背答案而是通过题目发现自己知识体系里的盲区。正确的姿势是做错一道题就回到对应的组件文档和源码里把这个知识点彻底搞明白。5.2 笔试时间的分配策略笔试时间通常紧张我的时间分配原则是选择题每题控制在 1 分钟内不会的先跳过做完大题再回来蒙不对是回来推理。SQL 题控制在 10-15 分钟/题。如果卡了 5 分钟没思路先写一版“暴力解”保证有分再考虑窗口函数优化。简答题控制在 5-8 分钟/题写出关键步骤和关键词不需要长篇大论。场景设计题留足 20-25 分钟一定要画架构图和数据流图手写文字流程也行这是得分的重点。5.3 我踩过的三个坑希望你别再踩第一个坑只背组件概念不练流程描述。我刚开始复习时“HDFS 写流程”能背得很溜但一到笔试要自己用文字写出来就发现逻辑混乱。后来我改用“给别人讲一遍”的方法来练习用嘴说出来顺了写出来也顺了。第二个坑场景题没有前置的条件调研。有一道场景题让我设计方案我凭感觉选了组件结果后来复盘发现业务的实际 QPS 和响应要求根本不需要那么重的架构。做题前一定先列出“数据量、延迟要求、一致性要求、故障恢复”这几个前置条件再谈选型。第三个坑忽视参数背后的意义。笔试会考一些参数比如 Spark 的 shuffle partitions、Flink 的 checkpoint interval。我一开始只是背参数值直到工作中真实遇到 OOM 和反压才明白这些参数为什么存在。所以复习时一定要问自己这个参数到底影响哪个环节调大/调小会发生什么。5.4 笔试之外我建议你补上的系统设计能力如果你是应届生这套笔试里能拉开差距的往往不是基础知识而是系统设计能力。我的建议是别只盯着 Spark 和 Flink 的 API多想想“数据从用户点击到报表展示的完整链路”把每个环节可能出现的问题和对应的处理方式都过一遍。当你脑中形成了这条链路的全景图再看这类笔试题会发现它们只是同一个故事的不同章节。结语一些个人的体会这套题做完之后我最大的收获并不是拿到某个分数而是明白了大数据开发这个岗位的底层要求基本原理要扎实动手能力要在线业务理解要落地。如果你也在准备类似的笔试我想说的是与其焦虑面经里有没有出现过这道题不如真正去把一个端到端的项目做通、做透。真实理解了的东西不管题目怎么变你都能在有限时间里组织出有深度的回答。最后分享一个小技巧做完每道题先别急着交卷用最后 5 分钟检查一遍自己对“链路完整性”的描述——组件与组件之间如何衔接。很多时候卷面上的差距就藏在那句你没写出来的“Kafka 在中间做削峰填谷”里。 爱奇艺大数据开发笔试题深度解析：考点拆解与备考指南
先说结论这份笔试题B覆盖的面几乎就是当时大数据开发岗的“标准考纲”——Hadoop 生态核心组件原理、离线与实时计算框架、数据仓库建模、SQL 能力、系统设计场景题再加少量 Java 基础。虽然名字叫“爱奇艺 2019 秋招”但它对现在准备大数据开发面试的人依然有很强的参考价值。我当时做完这套题的最大感受是题目不算偏但很考验“你到底是真的用过还是仅仅背过八股”。很多题看起来是概念题实际答起来会发现凡是没在集群上踩过坑的人很容易在某个细节上卡住。这篇文章就把这套题拆开结合我记得的一些重难点和自己的复盘把考点、答题思路、还有这背后面试官到底想看什么一次性说清楚。1. 这份笔试题到底在考什么爱奇艺大数据开发岗的能力坐标系先聊整体。很多人拿到大数据笔试题就慌觉得知识点多到复习不完。但如果你站在出题人的角度想爱奇艺这种体量的视频平台大数据开发要干的事其实很明确离线的报表和数仓、实时的推荐和运营反馈、用户行为日志的清洗与统计以及支撑这些业务的数据平台组件维护。业务画像一旦清晰考点就锁定了。1.1 岗位职责与考察方向的对应关系回忆一下我当时看到的岗位 JD核心关键词是Hadoop、Spark、Flink、Kafka、Hive、HBase加上“数据仓库建模”“实时计算”“调优”等。这基本对应了大数据开发的日常工作流数据接入层用 Flume / Kafka 收集日志能说清楚数据怎么落地、怎么保证不丢、怎么处理重复。离线计算层用 Hive / Spark 跑 T1 的报表任务能写 SQL懂分区、分桶知道数据倾斜怎么处理。实时计算层用 Flink / Spark Streaming 算实时指标理解窗口、状态、checkpoint 这些概念。数据服务层把结果写到 HBase / MySQL / Redis 供业务查询需要明白随机读写的原理。平台支撑HDFS、YARN、Zookeeper 这些基础组件的原理是排查问题的底层能力。所以这份笔试题B看着散实际上就是围绕“一个从日志产生到最终数据服务”的链路来出题的。你复习的时候如果脑子里没有这条链路就会觉得东一榔头西一棒子。1.2 从考试结构反推复习优先级我记得这份卷子大致有这几类单选/多选、简答、SQL 题和场景设计题。不同题型的复习权重应该完全不同题型主要考察能力复习优先级选择题基础组件原理、概念辨析高用于快速过知识点简答题框架运行机制、流程描述高需要能写清楚步骤SQL 题窗口函数、行列转换、UV 统计极高几乎必考场景设计题业务理解 技术选型 架构能力极高拉开差距的关键一个很残酷的现实是选择题偶而能蒙简答题也能背个大概但 SQL 题和场景设计题一旦没真做过很容易彻底卡住。这也是我和很多一起面试的人交流后共同的感受。1.3 爱奇艺的业务场景决定了出题风格爱奇艺是视频平台所以它的数据有非常明显的特点海量用户行为日志、高并发访问、实时性要求高、数据格式多样化。你在做它的场景题时如果能主动结合“视频 APP 的业务特性”来回答效果会好很多。比如统计播放量、分析用户留存、计算热门榜单这些都是视频平台典型场景答题时结合埋点、日志采集、多级缓存等思路来设计踩中得分点的概率会更大。2. 笔试核心考点拆解组件原理与框架机制这套题里分量最重的部分就是基础组件和计算框架的原理。这部分不光是记忆很多题喜欢给一个模糊描述问“哪个组件负责什么”或者在某个环节加一个“如果发生故障会怎样”。下面我把高频考点逐个拆开结合我当时的答题思路和后来的实际经验来讲。2.1 HDFS 与 Hadoop 基础别只背“主从架构”HDFS 一定是选择题和简答题的重灾区。要知道的不只是“NameNode 管元数据、DataNode 存数据”这种一句话概念而是要能画出读写流程图。特别是HDFS 写文件流程几乎每个面试官都爱问客户端先跟 NameNode 通信创建文件NameNode 校验权限和路径返回可用的 DataNode 列表客户端再分块默认 128MB写入写完一个块要形成 pipeline 复制到副本节点最后关闭流并通知 NameNode。这里有两个容易被问倒的细节副本放置策略同机架不同节点优先其次同数据中心不同机架再次跨数据中心。这个决定了容错和带宽消耗的平衡。小文件问题大量小文件会占满 NameNode 堆内存因为每个文件、目录、块都要在内存里维护元数据。爱奇艺这种每天日志量巨大的平台对文件数量的控制要求非常高所以答题时最好主动提到“小文件治理”。我当时在试卷里遇到一道关于“写入过程中 DataNode 宕机”的处理流程这题光背八股答不全。实际上pipeline 中的 DataNode 宕机后上游节点会从管线中移除它并把已确认写入的块信息上报给 NameNodeNameNode 会在后续触发副本复制。能答到这一层说明你真的理解副本机制。2.2 Zookeeper 与 Kafka分布式协调和消息队列的联考这两兄弟在选择题里往往会一起出现。Zookeeper 的核心考点是leader 选举机制基于 ZAB 协议只有超过半数节点同意才能选主所以集群通常是奇数台。节点类型持久节点、临时节点、顺序节点对应不同使用场景。watcher 监听机制为什么用推拉结合而不是纯推送。Kafka 的考点更多、更细分区与消费组一个分区同一时间只能被同一个消费组内的一个消费者消费这是 Kafka 实现并行消费和顺序保证的关键。消息可靠性acks0、1、-1all的区别和生产者的 retries、消费者的 enable.auto.commit 怎么配合。offset 管理老版本存在 Zookeeper 里新版本存在 Kafka 内部 topic__consumer_offsets里。提示回答 Kafka 可靠性时最好把生产者、broker、消费者三个维度分开讲然后再说明需要结合起来才能做到端到端的“不丢不重”。只答“acksall”是拿不全分的。我印象很深的是这套卷里有一道题问“Kafka 如何保证消息不丢失”很多人只写了 producer 端设置 acks-1但忽略了 broker 端的 min.insync.replicas、消费者端关闭自动提交 offset 这些配合项。这在真实场景里确实是个联动问题答全了对面试官来说是个加分信号。2.3 离线计算MapReduce Shuffle 与 Spark 核心机制离线计算是笔试里的重头戏。MapReduce 那边Shuffle 机制是必考中的必考map 端输出 - 分区排序 - 溢写 - merge - reduce 端拉取 - 合并排序 - reduce 函数。每一步都有很多细节比如 combiner 不能乱用求平均值时就不行、自定义 WritableComparable 为什么要有无参构造、分区数和 reduce 数的对应关系等。Spark 这边的必考点更密集RDD 血缘关系与容错为什么 lineage 比 checkpoint 代价低什么时候才需要 checkpoint长 lineage 或 shuffle 依赖。宽依赖与窄依赖判断标准是父 RDD 的一个分区是否被多个子 RDD 分区使用这决定了 Stage 划分和容错方式。Stage 划分遇到宽依赖就切断生成新的 Stage。笔试容易给一个算子链问你分成几个 Stage。算子区别map vs mapPartitions、reduceByKey vs groupByKey、coalesce vs repartition。每个对比都要能从源码原理和适用场景两个角度说。我当时答这道题时特别强调了reduceByKey 和 groupByKey 的本质区别reduceByKey 在 map 端先做一次局部聚合数据量大幅减少后才 shufflegroupByKey 则把所有原始数据全部 shuffle代价高。实际调优时能用 reduceByKey 就不选 groupByKey这是最基本的优化规则。2.4 实时计算Flink 的窗口与状态2019 年那会儿 Flink 已经非常热这套题涉及 Flink 并不意外。核心考点集中在窗口机制滚动窗口、滑动窗口、会话窗口的区别以及事件时间Event Time和处理时间Processing Time的对比。Watermark 的理解它本质是“时间进度”的标记用来触发窗口计算和解决乱序问题。还经常会问 watermark 设置的延迟时间和 allowedLateness 的区别。Checkpoint 与状态后端Flink 如何通过 barrier 机制做分布式快照状态是存在内存、文件系统还是 RocksDB。这里最好能答出 exactly-once 的语义保障和两阶段提交。注意这类题目容易混淆的是“窗口的触发条件”。很多人以为定时触发的窗口就是处理时间窗口其实事件时间窗口也可以定时只是触发的依据是 watermark 是否越过窗口结束时间。能把这个概念区分清楚基本上可以压制绝大多数候选人了。我记得这道题我回答得很细因为我那阵子刚用 Flink 做过一个实时指标项目对 watermark 和 barrier 有真实的理解写起来不会像背书。这一点也是我想跟读者强调的框架原理光看不行最好真去跑一个任务哪怕是本地小 demo。2.5 数据仓库与 Hive建模思维和 SQL 能力数仓建模和 Hive 是笔试题里相当“实在”的部分。爱奇艺这种公司对数据仓库的需求很典型用户行为、播放明细、会员订单、广告投放这些数据要组织成一系列分层表供分析和算法使用。考点包括数仓分层ODS原始数据层、DWD明细数据层、DWS汇总数据层、ADS应用数据层每层的职责是什么为什么要分层。维度建模星型模型和雪花模型的区别事实表和维度表的划分缓慢变化维SCD的处理策略。Hive 表类型内部表 vs 外部表、分区表 vs 分桶表。尤其外包表删除时 HDFS 数据是否保留这题经常有人做错。Hive 数据倾斜group by 时某个 key 特别大导致的倾斜常见解法有加随机前缀打散、两阶段聚合、map 端聚合combiner等。SQL 题我用一个单独的小节来讲因为它的权重实在太高。3. 高频题型与典型答题思路复盘题型不同答题节奏完全不同。这块我按自己的考后回忆把印象深的高频题型和套路总结一下每类题都给了可落地的答题模板尤其适合笔试时间紧、没时间现场想框架的读者。3.1 概念辨析题先给结论再讲原理最后举例这类题喜欢出成“下列哪个说法正确/错误”。比如“Spark 中的 reduceByKey 一定比 groupByKey 快”“Kafka 的消费者组内消费者数量一定不能超过分区数”“HDFS 支持随机修改文件内容”。做这类题的心法很简单先定位到具体组件的具体机制再根据你对机制的掌握做判断。举个例子“HDFS 支持随机修改文件内容”是经典的错误选项。HDFS 设计为一次写入、多次读取支持 append 追加但不支持像本地文件系统那样随机修改偏移量。要答好这个问题你得理解 HDFS 数据块的组织方式——块被创建后 immutable修改需要重写整个块这对大规模存储是不可接受的。如果试卷让“说明原因”我会从块机制和追加写模型两个角度答。3.2 场景设计题画链路、选组件、说方案场景设计题是拉分题。我来重建一道我当时比较有把握的题“请设计一个方案统计全网每日视频播放量 Top100 榜单要求实时性在分钟级。”我的回答框架是数据接入客户端埋点上报播放事件写入消息队列 Kafka。根据播放行为频率估算 QPS确定 Kafka 分区数和 broker 数。实时计算Flink 消费 Kafka按照 video_id 做 keyBy开 1 分钟滚动窗口或者 5 分钟窗口在窗口内聚合播放次数。结果存储聚合后的分钟级结果写入 Rediszset 结构或者写入 HBase 然后通过批量任务合并到 MySQL / ES。TopN 计算因为我们是按 video_id 维度聚合后再取 Top100可以避免在全量明细上排序。Redis zset 天然支持 rank 操作适合这种场景。容错与去重播放事件如果带有用户 ID 和 session ID需要在窗口内做 distinctCount 或至少用 Flink 的状态做去重。如果只是播放次数近似值可以用 HyperLogLog。这题没有标准答案但评分标准很明确是否分模块考虑、是否说明组件选型理由、是否处理去重和容错、是否考虑业务边界条件比如同一个用户连续刷新算不算多次播放。我当时联想到爱奇艺的业务还会有“试播和正片分开统计”“短剧和长剧的播放口径不同”等问题主动说明“需要和业务确认播放口径”这一点我觉得很加分。3.3 SQL 编程题窗口函数是永远的神大数据笔试的 SQL 题难度通常集中在这三类分组 TopN经典题“取每个部门工资最高的员工”。解法是用 ROW_NUMBER() OVER(PARTITION BY dept_id ORDER BY salary DESC)然后过滤出排名为 1 的记录。行转列 / 列转行多个 key-value 结构如何展开或合并一般要用 CASE WHEN 或 explode lateral view。连续问题 / 留存问题连续登录天数、次日留存率。这类题在爱奇艺这种运营驱动型公司特别常见。我演示一道典型题和答案题目有一张播放记录表 play_record(user_id, video_id, play_date)求 2024 年 5 月每个用户每天的播放次数以及每个用户当月的累计播放次数。SELECT user_id, play_date, COUNT(*) AS day_play_cnt, SUM(COUNT(*)) OVER(PARTITION BY user_id ORDER BY play_date) AS month_cum_cnt FROM play_record WHERE play_date BETWEEN 2024-05-01 AND 2024-05-31 GROUP BY user_id, play_date;核心是用开窗函数对 group by 之后的聚合结果再做一次累计求和。如果没有窗口函数你需要自连接或子查询又慢又容易错。这道题还想提醒一个小技巧窗口函数的执行顺序是先 group by 再开窗很多人在理解上搞反。3.4 故障排查与优化题从现象推原因再谈解决方案这类题是笔试中比较“高级”的考法。比如“某 Spark 任务一直运行很慢且发现某些 executor 的 GC 时间特别长可能是什么原因怎么排查”我一般会按“查看现象 - 定位瓶颈 - 给出措施 - 复盘预防”的顺序来答现象分析某个 executor GC 时间过长往往是数据倾斜导致单个 task 处理的数据量过大持有了大量对象无法释放。定位手段去 Spark UI 看各 stage 的 task 耗时分布和输入数据量如果某个 task 的 input 数据量明显高于其他 task就是数据倾斜。解决思路如果是 group by 导致的倾斜用加盐随机前缀两阶段聚合如果是 join 导致的倾斜考虑把热点 key 拆出来广播小表或者单独处理如果只是 executor 内存不足可以调大 spark.executor.memory 并配合调整 spark.memory.storageFraction 等参数。预防措施在代码里对 key 分布做前置统计上线前用中量数据做压测。这类题贵在“讲出流程”而不是“背出参数”。做题时我会把分析过程写成逻辑链条让阅卷人一眼看出我是真的排查过问题而不是背了一堆配置项。4. 这些题目背后的面试官视角为什么这么考刷完这套题我更在意的不是对了几道而是“爱奇艺到底想要什么样的人”。想明白这一点对以后准备面试会很有方向感。4.1 原理比工具重要因为工具会变爱奇艺 2019 年的时候实时计算正在从 Spark Streaming 往 Flink 迁移今天看来依然如此——新技术层出不穷但分布式计算的基本模型没变存储与计算分离、shuffle、容错、一致性。所以试卷里大量考察原理和机制而不是让你背诵某个 API 的签名。我记得当时有一道题问“Spark 和 MapReduce 的区别”其实更看重的是你能不能从“计算模型”的层面去比较MapReduce 每一步都要落盘Spark 基于内存做 DAG 计算两者在 shuffle 的物化策略、迭代计算效率、容错粒度上都有本质不同。能答到这种抽象层度说明你不是只会调工具是做工程的人。4.2 场景题考的是“业务转化为技术”的能力对一家视频公司来说数据开发不是纯技术活。你要能听懂产品经理说的“我们要看用户的完播率”然后转化成“对播放明细表按 user_id 和 video_id 聚合统计播放时长/视频总时长的分布”这样的技术方案。这套题的场景题本质上就是考察这种转化能力。我在笔试中写方案时习惯先明确指标口径再选技术组件最后画数据流转链路。这样做的好处是即使技术选型不完美阅卷人也能看出你的思考是有结构的。而且我在结尾总要补一句“需要结合业务确认指标口径”这在真实工作里是非常重要的一步却常常被校招同学忽略。4.3 代码题考的是工程规范和细节SQL 和 Java/Python 代码题考的不只是“写对”还有“写得规范”。比如 SQL 里有没有加分区条件过滤是不是用了 SELECT *join 时是不是注意了 null 值处理。大数据的笔试代码量不大但每道题都有可以优化的细节。阅卷人如果是资深工程师一眼就能看出这个候选人在生产环境里有没有写过代码。我自己的一个体会是代码题宁可多写几行注释也不要为了显得厉害写复杂的表达式。评卷时能看懂你是第一步简洁清晰的逻辑比炫技重要太多。5. 备考这套题的方法、答题策略和我踩过的坑最后这部分写给正在准备大数据开发方向校招或跳槽的读者。我把自己备考和实际笔试中总结的经验整理成清单希望能省下你一些摸索的时间。5.1 准备这份考题的实用学习路线如果只给一条主线我会建议按下面的顺序准备搭建一个简单的集群环境比如用 Docker 起一个 Hadoop Hive Spark 的伪分布式环境把数据链路从头跑通生成日志 - Flume/Kafka - Hive/Spark - MySQL。每个组件学完用中文写一篇自己的原理笔记讲清楚“它解决什么问题、有哪些核心概念、一个请求从进入到返回发生了什么”。集中刷 SQL 题尤其是窗口函数相关的练习题每个类型至少练 3 遍。看一遍生产环境中的调优案例比如网上很多人分享的 Spark 内存调优、Flink 反压处理不用记住所有参数但要能说出优化思路。自拟 5 个场景设计题按“接入层 - 计算层 - 存储层 - 服务层”的框架写方案反复打磨。提示我不是很建议直接去背网上的“大数据面试 300 题”。刷题的意义不是背答案而是通过题目发现自己知识体系里的盲区。正确的姿势是做错一道题就回到对应的组件文档和源码里把这个知识点彻底搞明白。5.2 笔试时间的分配策略笔试时间通常紧张我的时间分配原则是选择题每题控制在 1 分钟内不会的先跳过做完大题再回来蒙不对是回来推理。SQL 题控制在 10-15 分钟/题。如果卡了 5 分钟没思路先写一版“暴力解”保证有分再考虑窗口函数优化。简答题控制在 5-8 分钟/题写出关键步骤和关键词不需要长篇大论。场景设计题留足 20-25 分钟一定要画架构图和数据流图手写文字流程也行这是得分的重点。5.3 我踩过的三个坑希望你别再踩第一个坑只背组件概念不练流程描述。我刚开始复习时“HDFS 写流程”能背得很溜但一到笔试要自己用文字写出来就发现逻辑混乱。后来我改用“给别人讲一遍”的方法来练习用嘴说出来顺了写出来也顺了。第二个坑场景题没有前置的条件调研。有一道场景题让我设计方案我凭感觉选了组件结果后来复盘发现业务的实际 QPS 和响应要求根本不需要那么重的架构。做题前一定先列出“数据量、延迟要求、一致性要求、故障恢复”这几个前置条件再谈选型。第三个坑忽视参数背后的意义。笔试会考一些参数比如 Spark 的 shuffle partitions、Flink 的 checkpoint interval。我一开始只是背参数值直到工作中真实遇到 OOM 和反压才明白这些参数为什么存在。所以复习时一定要问自己这个参数到底影响哪个环节调大/调小会发生什么。5.4 笔试之外我建议你补上的系统设计能力如果你是应届生这套笔试里能拉开差距的往往不是基础知识而是系统设计能力。我的建议是别只盯着 Spark 和 Flink 的 API多想想“数据从用户点击到报表展示的完整链路”把每个环节可能出现的问题和对应的处理方式都过一遍。当你脑中形成了这条链路的全景图再看这类笔试题会发现它们只是同一个故事的不同章节。结语一些个人的体会这套题做完之后我最大的收获并不是拿到某个分数而是明白了大数据开发这个岗位的底层要求基本原理要扎实动手能力要在线业务理解要落地。如果你也在准备类似的笔试我想说的是与其焦虑面经里有没有出现过这道题不如真正去把一个端到端的项目做通、做透。真实理解了的东西不管题目怎么变你都能在有限时间里组织出有深度的回答。最后分享一个小技巧做完每道题先别急着交卷用最后 5 分钟检查一遍自己对“链路完整性”的描述——组件与组件之间如何衔接。很多时候卷面上的差距就藏在那句你没写出来的“Kafka 在中间做削峰填谷”里。