企业官网建设流程全解析

先说结论：这份笔试题（B）覆盖的面，几乎就是当时大数据开发岗的“标准考纲”——Hadoop 生态核心组件原理、离线与实时计算框架、数据仓库建模、SQL 能力、系统设计场景题，再加少量 Java 基础。虽然名字叫“爱奇艺 2019 秋招”，但它对现在准备大数据开发面试的人依然有很强的参考价值。

我当时做完这套题的最大感受是：题目不算偏，但很考验“你到底是真的用过，还是仅仅背过八股”。很多题看起来是概念题，实际答起来会发现，凡是没在集群上踩过坑的人，很容易在某个细节上卡住。这篇文章就把这套题拆开，结合我记得的一些重难点和自己的复盘，把考点、答题思路、还有这背后面试官到底想看什么，一次性说清楚。

1. 这份笔试题到底在考什么：爱奇艺大数据开发岗的能力坐标系

先聊整体。很多人拿到大数据笔试题就慌，觉得知识点多到复习不完。但如果你站在出题人的角度想，爱奇艺这种体量的视频平台，大数据开发要干的事其实很明确：离线的报表和数仓、实时的推荐和运营反馈、用户行为日志的清洗与统计，以及支撑这些业务的数据平台组件维护。业务画像一旦清晰，考点就锁定了。

1.1 岗位职责与考察方向的对应关系

回忆一下我当时看到的岗位 JD，核心关键词是：Hadoop、Spark、Flink、Kafka、Hive、HBase，加上“数据仓库建模”“实时计算”“调优”等。这基本对应了大数据开发的日常工作流：

• 数据接入层：用 Flume / Kafka 收集日志，能说清楚数据怎么落地、怎么保证不丢、怎么处理重复。
• 离线计算层：用 Hive / Spark 跑 T+1 的报表任务，能写 SQL，懂分区、分桶，知道数据倾斜怎么处理。
• 实时计算层：用 Flink / Spark Streaming 算实时指标，理解窗口、状态、checkpoint 这些概念。
• 数据服务层：把结果写到 HBase / MySQL / Redis 供业务查询，需要明白随机读写的原理。
• 平台支撑：HDFS、YARN、Zookeeper 这些基础组件的原理，是排查问题的底层能力。

所以这份笔试题（B）看着散，实际上就是围绕“一个从日志产生到最终数据服务”的链路来出题的。你复习的时候如果脑子里没有这条链路，就会觉得东一榔头西一棒子。

1.2 从考试结构反推复习优先级

我记得这份卷子大致有这几类：单选/多选、简答、SQL 题和场景设计题。不同题型的复习权重应该完全不同：

一个很残酷的现实是：选择题偶而能蒙，简答题也能背个大概，但 SQL 题和场景设计题一旦没真做过，很容易彻底卡住。这也是我和很多一起面试的人交流后共同的感受。

1.3 爱奇艺的业务场景决定了出题风格

爱奇艺是视频平台，所以它的数据有非常明显的特点：海量用户行为日志、高并发访问、实时性要求高、数据格式多样化。你在做它的场景题时，如果能主动结合“视频 APP 的业务特性”来回答，效果会好很多。比如统计播放量、分析用户留存、计算热门榜单，这些都是视频平台典型场景，答题时结合埋点、日志采集、多级缓存等思路来设计，踩中得分点的概率会更大。

2. 笔试核心考点拆解：组件原理与框架机制

这套题里分量最重的部分，就是基础组件和计算框架的原理。这部分不光是记忆，很多题喜欢给一个模糊描述，问“哪个组件负责什么”，或者在某个环节加一个“如果发生故障会怎样”。下面我把高频考点逐个拆开，结合我当时的答题思路和后来的实际经验来讲。

2.1 HDFS 与 Hadoop 基础：别只背“主从架构”

HDFS 一定是选择题和简答题的重灾区。要知道的不只是“NameNode 管元数据、DataNode 存数据”这种一句话概念，而是要能画出读写流程图。特别是HDFS 写文件流程，几乎每个面试官都爱问：客户端先跟 NameNode 通信创建文件，NameNode 校验权限和路径，返回可用的 DataNode 列表，客户端再分块（默认 128MB）写入，写完一个块要形成 pipeline 复制到副本节点，最后关闭流并通知 NameNode。

这里有两个容易被问倒的细节：

• 副本放置策略：同机架不同节点优先，其次同数据中心不同机架，再次跨数据中心。这个决定了容错和带宽消耗的平衡。
• 小文件问题：大量小文件会占满 NameNode 堆内存，因为每个文件、目录、块都要在内存里维护元数据。爱奇艺这种每天日志量巨大的平台，对文件数量的控制要求非常高，所以答题时最好主动提到“小文件治理”。

我当时在试卷里遇到一道关于“写入过程中 DataNode 宕机”的处理流程，这题光背八股答不全。实际上，pipeline 中的 DataNode 宕机后，上游节点会从管线中移除它，并把已确认写入的块信息上报给 NameNode，NameNode 会在后续触发副本复制。能答到这一层，说明你真的理解副本机制。

2.2 Zookeeper 与 Kafka：分布式协调和消息队列的联考

这两兄弟在选择题里往往会一起出现。Zookeeper 的核心考点是：

• leader 选举机制：基于 ZAB 协议，只有超过半数节点同意才能选主，所以集群通常是奇数台。
• 节点类型：持久节点、临时节点、顺序节点，对应不同使用场景。
• watcher 监听机制：为什么用推拉结合而不是纯推送。

Kafka 的考点更多、更细：

• 分区与消费组：一个分区同一时间只能被同一个消费组内的一个消费者消费，这是 Kafka 实现并行消费和顺序保证的关键。
• 消息可靠性：acks=0、1、-1（all）的区别，和生产者的 retries、消费者的 enable.auto.commit 怎么配合。
• offset 管理：老版本存在 Zookeeper 里，新版本存在 Kafka 内部 topic（__consumer_offsets）里。

提示：回答 Kafka 可靠性时，最好把生产者、broker、消费者三个维度分开讲，然后再说明需要结合起来才能做到端到端的“不丢不重”。只答“acks=all”是拿不全分的。

我印象很深的是，这套卷里有一道题问“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 端先做一次局部聚合，数据量大幅减少后才 shuffle；groupByKey 则把所有原始数据全部 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 榜单，要求实时性在分钟级。”

我的回答框架是：

1. 数据接入：客户端埋点上报播放事件，写入消息队列 Kafka。根据播放行为频率估算 QPS，确定 Kafka 分区数和 broker 数。
2. 实时计算：Flink 消费 Kafka，按照 video_id 做 keyBy，开 1 分钟滚动窗口（或者 5 分钟窗口），在窗口内聚合播放次数。
3. 结果存储：聚合后的分钟级结果写入 Redis（zset 结构），或者写入 HBase 然后通过批量任务合并到 MySQL / ES。
4. TopN 计算：因为我们是按 video_id 维度聚合后再取 Top100，可以避免在全量明细上排序。Redis zset 天然支持 rank 操作，适合这种场景。
5. 容错与去重：播放事件如果带有用户 ID 和 session ID，需要在窗口内做 distinctCount 或至少用 Flink 的状态做去重。如果只是播放次数近似值，可以用 HyperLogLog。

这题没有标准答案，但评分标准很明确：是否分模块考虑、是否说明组件选型理由、是否处理去重和容错、是否考虑业务边界条件（比如同一个用户连续刷新算不算多次播放）。我当时联想到爱奇艺的业务还会有“试播和正片分开统计”“短剧和长剧的播放口径不同”等问题，主动说明“需要和业务确认播放口径”，这一点我觉得很加分。

3.3 SQL 编程题：窗口函数是永远的神

大数据笔试的 SQL 题，难度通常集中在这三类：

1. 分组 TopN：经典题“取每个部门工资最高的员工”。解法是用 ROW_NUMBER() OVER(PARTITION BY dept_id ORDER BY salary DESC)，然后过滤出排名为 1 的记录。
2. 行转列 / 列转行：多个 key-value 结构如何展开或合并，一般要用 CASE WHEN 或 explode + lateral view。
3. 连续问题 / 留存问题：连续登录天数、次日留存率。这类题在爱奇艺这种运营驱动型公司特别常见。

我演示一道典型题和答案：

题目：有一张播放记录表 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 准备这份考题的实用学习路线

如果只给一条主线，我会建议按下面的顺序准备：

1. 搭建一个简单的集群环境（比如用 Docker 起一个 Hadoop + Hive + Spark 的伪分布式环境），把数据链路从头跑通：生成日志 -> Flume/Kafka -> Hive/Spark -> MySQL。
2. 每个组件学完，用中文写一篇自己的原理笔记，讲清楚“它解决什么问题、有哪些核心概念、一个请求从进入到返回发生了什么”。
3. 集中刷 SQL 题，尤其是窗口函数相关的练习题，每个类型至少练 3 遍。
4. 看一遍生产环境中的调优案例，比如网上很多人分享的 Spark 内存调优、Flink 反压处理，不用记住所有参数，但要能说出优化思路。
5. 自拟 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 在中间做削峰填谷”里。