Spark/Flink

进阶预计进阶 2-3 个月

星团 数据

学习定位零前置,可直接入门→ Spark/Flink →学完本技能可衔接的下游技能建设中

岗位需求

1 核心 · 0 加分

在职岗位将其列为技能要求

核心岗位薪资带

18k-40k

核心要求岗位的月薪区间

需求趋势

上升 0稳定 1收缩 0

核心要求岗位的趋势分布

面试题库

高频真题 · 参考答案随题展开
1. Spark 的核心抽象 RDD 与其执行模型是怎样的?

RDD 是弹性分布式数据集:不可变、分区存放的血缘(lineage)记录了从源到当前的变换链,分区可并行处理、丢失时按血缘重算,这带来容错而无需复制。变换(map、filter、join 等)惰性构建 DAG,行动(collect、count、save)触发作业提交。执行层级:作业 job 按宽依赖边界切成阶段 stage,阶段内是窄依赖流水执行,stage 间需要 shuffle;任务 task 是分区级的执行单元,由调度器分配到 executor。内存策略上 Spark 尽量内存缓存中间结果(persist 与 cache),配合 Tungsten 引擎的堆外内存与代码生成提升性能。当前开发主力是 DataFrame 与 Dataset(Catalyst 优化器做谓词下推与执行计划优化),RDD 保留为底层抽象与兜底。能讲血缘容错、宽窄依赖、job 到 stage 到 task 三层即满分。

2. 宽依赖与窄依赖、shuffle 为什么贵?

窄依赖是父分区最多被一个子分区消费(map、filter、union),可流水线在同一任务内连续执行无需数据交换;宽依赖(groupByKey、reduceByKey、join 非同分区器、repartition)中子分区依赖全部父分区,必须 shuffle。shuffle 的代价:上游各任务按目标分区器把数据写溢出文件(可能多轮溢写磁盘合并),下游任务网络拉取并排序合并,涉及磁盘 IO、网络传输与序列化,同时带来 GC 与内存压力,是绝大多数 Spark 作业的瓶颈点。优化思路围绕减少与加速 shuffle:能 reduceByKey 不 groupByKey(先局部聚合减少传输量)、广播小表把 join 变窄依赖、合理分区器与预分区让多次 shuffle 复用分区、调大与调对缓冲参数、AQE 自动合并小分区。能讲溢写文件机制与广播 join 即优秀。

3. Flink 的流处理模型与 Spark Structured Streaming 有何不同?

Flink 是真正的流式执行:事件逐条流经算子,数据一到即处理,延迟毫秒级,天然持续运行;时间语义有事件时间与处理时间,水印(watermark)推进事件时间并触发窗口与定时器,支持乱序与迟到数据处理(allowed lateness 与侧输出流);状态是内建一等公民(keyed state、算子状态),配合 checkpoint(基于 Chandy-Lamport 的分布式快照、barrier 对齐)做精确一次语义,状态后端可落 RocksDB 支撑超大状态。Spark Structured Streaming 是微批模型:把流切成小批次用 Spark 引擎处理,吞吐高、与批共享 API,延迟取决于批次间隔(最低百毫秒级,连续处理模式受限),以 checkpoint 加 WAL 保一致。选型:毫秒级延迟、大状态、复杂事件时间语义选 Flink;已有 Spark 生态、秒级容忍、批流一体统一栈选 Spark。

4. Flink 的 checkpoint 机制是怎样的?

checkpoint 是 Flink 实现容错与精确一次的核心:JobManager 周期性向数据源注入 barrier(屏障),随数据流向下游;算子收到所有输入通道的 barrier 后做 barrier 对齐(exact once 模式下阻塞后到的通道,先到通道的数据缓冲),把自身状态快照异步写入状态后端(HeapStateBackend 或 RocksDB),再把 barrier 广播给下游;所有算子快照完成即一次全局一致快照,记账在 ZooKeeper 或 JobManager 持久化。恢复时全体回滚到最后快照状态并把源重置到对应 offset,配合可重放源(Kafka)实现 exactly once;at least once 则不对齐直接快照,延迟低但可能重复。要点:checkpoint interval 与超时、增量 checkpoint(RocksDB 只传增量)与 unaligned checkpoint(反压时屏障插队)是生产必调参数;端到端精确一次还需 sink 两阶段提交(Kafka 事务 sink)。能讲 barrier 对齐与两阶段提交 sink 即高分。

5. 事件时间、水印与窗口如何配合?

处理时间用机器时钟简单但乱序与回压会造成窗口切分漂移;事件时间以数据自带的时间戳为准,结果与到达顺序无关,适合业务统计。问题是如何知道某窗口的所有数据到齐——水印是事件时间的推进器:水印值 w 表示事件时间小于 w 的数据大概率已到,允许设定乱序容忍(w 等于 最大时间戳 减 延迟容忍),水印流到窗口算子时触发 end-of-window 计算并关闭窗口。迟到于水印但仍要的数据用 allowed lateness 在窗口真正销毁前补算,更晚的进侧输出流单独处理。窗口类型:滚动(不重叠分段)、滑动(步长小于长度有重叠)、会话(活动间隙切分)、全局加自定义触发器。坑:水印取自分区最大值会在 Kafka 分区闲置时卡住,需空闲源标记;聚合到下游还要注意并发 watermark 取最小。能画时间轴讲一遍触发时序即满分。

🔒 解锁完整面试题库与参考答案(Pro)

含高频追问与作答要点,系统准备面试。

官方文档

2 条

推荐教程

1 条

推荐课程

1 条

上手实践

1 条

🔒 完整前置链分析 + 逐岗位引用明细

本页已免费展示学习定位与市场聚合;Pro 深读补齐完整前置依赖链分析与逐岗位引用明细 (核心/加分与深度档、岗位画像)。

知识分享

社区经验 · 管理员审核后展示

暂无分享——第一个来聊聊你的经验和踩坑吧。

有经验想分享?登录后可提交你的知识分享,管理员审核通过后将署名展示。

难度档决定星等与难度分权重(入门 1 / 进阶 2 / 精通 3);学习资源由编辑部遴选并持续维护, 经验心得欢迎在上方「知识分享」区署名分享。