大数据 on 方糖猫Blog

Spark 与 Flink 入门：批与流的两种血统，视频公司里各干什么活

Fri, 02 Oct 2026 19:00:00 +0800

Spark 与 Flink 入门：批与流的两种血统，视频公司里各干什么活

目标读者：四类人——

后端/数据工程师：要上手 Spark 或 Flink，需要心智模型加能跑的代码（看"基础"两节，附 Java API 示例）；

架构师/技术负责人：在给数据平台选型，想知道两者的边界和硬件投入（看"血统对比"“算力规格"和"选型决策”）；

运维/SRE：要看监控什么、出事怎么处理（看"监控"和"故障与恢复"）；

正在踩坑的人：直接翻到文末两家的避坑清单。

阅读前提：了解 Kafka 是什么即可，不需要大数据背景。

前两篇讲推荐 Feed 架构时，Spark 和 Flink 反复出现：Spark 做离线训练，Flink 做近线特征。有读者问：Spark 不就是内存分布式计算吗，和 Flink 功能差不多？

看着像，血统完全不同。这篇把两者各自的基础概念讲清，然后放进一家类 Netflix 的视频公司里看它们分别干什么活，最后附上两家的避坑指南。

Spark 基础：批处理血统的内存计算引擎

Spark 在 2010 年前后接棒 Hadoop MapReduce，核心卖点一句话：把中间结果放内存，迭代计算不用反复落盘。MapReduce 每轮迭代都要读写 HDFS，Spark 把数据缓存进内存，迭代型任务（机器学习训练要扫数据几十遍）快了十到一百倍。

三个核心概念：

RDD / DataFrame：数据被抽象成分布式集合，切成分区（partition）摊在集群各节点上。RDD 是原始 API，现在日常用的是 DataFrame——带结构（schema）的表，配合 Spark SQL 直接写 SQL。
DAG 执行：你对数据做的一串操作（filter、join、groupBy）不会立即执行，而是攒成一张有向无环图；遇到"要结果"的动作（count、写盘）才触发，调度器把图切成 stage、分发执行。惰性求值让引擎有机会做全局优化。
Shuffle：数据按 key 重新分发的操作（groupBy、join 都会触发），是 Spark 作业里最贵的一步——数据要跨节点搬运、序列化、落盘。后面避坑指南里一半的坑都和它有关。

血统决定视角：在 Spark 眼里，数据是一批一批的——有界的、静态的数据集。它的流处理能力（Structured Streaming）是后来在批的骨架上加的：把数据流切成一小批一小批，攒一批算一次（micro-batch）。延迟天然是秒级到分钟级。

上手：一个 ETL 作业的 Java 写法。场景：把昨天的播放原始日志清洗成"每视频日播放量"聚合表：

SparkSession spark = SparkSession.builder()
        .appName("play-events-etl")
        .getOrCreate();

// 读：数据湖里昨天的原始播放事件（分区表）
Dataset<Row> events = spark.read()
        .parquet("s3://warehouse/raw/play_events/dt=2026-10-01/");

// 处理：过滤脏数据、按 event_id 去重、换算播放分钟数
Dataset<Row> cleaned = events
        .filter("duration > 0 AND user_id IS NOT NULL")
        .dropDuplicates("event_id")
        .withColumn("play_minutes", col("duration").divide(60));

// join 内容维度表补标题和类目（小表广播，避免 shuffle）
Dataset<Row> enriched = cleaned
        .join(broadcast(spark.read().parquet("s3://warehouse/dim/videos/")), "video_id");

// 聚合出结果并写回数仓（coalesce 控制输出文件数，防止小文件）
enriched.groupBy("video_id", "category")
        .agg(count("*").alias("plays"), sum("play_minutes").alias("total_minutes"))
        .coalesce(4)
        .write()
        .mode("overwrite")
        .parquet("s3://warehouse/agg/daily_video_plays/dt=2026-10-01/");

注意这段代码提交后什么都不会立刻发生——filter、join、groupBy 只是在攒 DAG，最后的 write() 这个动作才触发真正的执行。这就是前面说的惰性求值。

这段代码里还有一件"看不见"的事值得说破：分区是自动切的，你全程没有指定过它。分区的三个来源：

读入分区由文件决定：读 parquet 时 Spark 按文件切块，spark.sql.files.maxPartitionBytes（默认 128MB）决定每块多大，每块一个分区。路径里的 dt=2026-10-01/ 本身就是物理分区，Spark 只扫这一天的目录，其余按分区裁剪跳过；
shuffle 后分区由配置决定：groupBy 触发数据重分发，之后的分区数由 spark.sql.shuffle.partitions 控制，默认 200——小作业跑完写出 200 个小文件，罪魁祸首就是它；
手动干预只有两个 API：repartition(n) 重新洗牌（会产生一次 shuffle，贵），coalesce(n) 只合并不洗牌（便宜）。上面代码写出前的 coalesce(4) 就是故意把默认的 200 个分区合并成 4 个输出文件。

那"拉起几十台机器并行计算"体现在哪？答案是：不体现在代码里，体现在物理执行里。 同一份代码在一台笔记本上（local 模式）和一百台机器上跑，一行都不用改——分布式是部署特征，不是代码特征。看这段 ETL 提交到集群时实际发生什么：

spark-submit \
  --class com.example.PlayEventsETL \
  --master yarn \
  --num-executors 50 \        # 拉起 50 个 executor 进程，分布在集群各节点
  --executor-cores 5 \        # 每个 executor 5 核
  --executor-memory 20g \
  --driver-memory 8g \
  app.jar

这里的 app.jar 是你自己的应用代码打包产物：前面那段 ETL 的 Java 代码用 Maven/Gradle 编译，打成包含全部依赖的 fat jar（Maven 用 shade 插件、Gradle 用 shadow 插件），--class 指定里面的入口类。提交时这个 jar 被上传到集群，driver 拿到后把代码分发到各 executor——executor 上跑的 task，执行的就是这个 jar 里的字节码。所以 Spark 作业的交付物就是一个 jar：改代码 = 重新打包重新提交。

生产环境里谁来"敲"这个 spark-submit？ 凌晨两点跑批不是值班同学手动敲命令。业界的提交方式按层次分：

SparkLauncher：Spark 官方自带的 Java API，在 Java 进程里编程式提交作业，还返回句柄可轮询状态——自研平台的标准做法：

SparkAppHandle handle = new SparkLauncher()
        .setAppResource("app.jar")
        .setMainClass("com.example.PlayEventsETL")
        .setMaster("yarn")
        .setConf(SparkLauncher.EXECUTOR_MEMORY, "20g")
        .startApplication();   // 异步返回，拿 handle 跟踪作业状态

Apache Livy：把提交做成 REST 服务——HTTP POST 一个 jar、轮询状态、拉日志。Web 系统里嵌入 Spark 提交能力的标准件；
调度系统：Apache DolphinScheduler、Airflow 这类工作流平台，管的是"凌晨 2 点跑 ETL、成功了再跑模型训练"这种依赖编排，底层调的仍然是 spark-submit 或 Livy；
云厂商 API：EMR Steps、Databricks Jobs 这类托管服务，提交动作变成一个云 API 调用。

顺带纠个常见的偏：Apache Commons 系列里没有 Spark 专用提交工具——Commons Exec 只是通用的外部进程包装器，有些自研平台拿它包 spark-submit 命令行（拿退出码、控超时），能用但不是主流。想在 Java 里提交作业，正路是 SparkLauncher 或 Livy。

50 个 executor × 5 核 = 250 个任务槽位同时干活，1TB 堆内存的总池子。作业跑起来后，逻辑计划被拆成物理 stage，每个分区对应一个 task，task 被调度到空闲槽位上：

flowchart TD
    A["Stage 1 读取+过滤<br/>2TB parquet 按 128MB 切块<br/>约 16000 个分区 = 16000 个 task"] --> B["Stage 2 join<br/>维度表广播到每个 executor<br/>无 shuffle"]
    B --> C["shuffle 重分发<br/>按 video_id 搬运数据"]
    C --> D["Stage 3 聚合+写盘<br/>200 个 task 各自聚合自己那份"]
    A -.->|"250 个槽位并发<br/>16000 个 task 分批消化"| A

几个数字感：

一天 100 亿条播放事件约 2TB parquet，切成约 16000 个分区，每个分区一个 task——250 个槽位并发，分批消化完这 16000 个 task，这就是"拉起多个节点"的物理形态；
谁挂了谁重试：某个 executor 宕机，它跑过的 task 在别的节点上按血统重算，作业整体不停；
想更快就加机器：--num-executors 100，槽位翻倍，16000 个 task 消化速度就近似翻倍——这就是水平扩展：代码不变，吞吐随机器数线性涨（直到被 shuffle 或存储 IO 卡住）。

ALS 训练是同一个道理，只是把"一批 task"换成"几十轮、每轮一批 task"：每一轮迭代都是一次全集群的分布式计算，中间结果留在内存里不落盘——这正是 Spark 相比 MapReduce 快的根源。

所以读 Spark 代码的正确姿势是：代码是蓝图，集群按分区把蓝图实体化成成千上万的 task。你在代码里看不到"多节点"，正如你在建筑图纸上看不到施工队——但图纸上的每一堵墙，都会变成某个工人在某个脚手架上的具体动作。

机器学习也一样是 DataFrame 风格的 API。Spark MLlib 里自带 ALS（交替最小二乘，就是矩阵分解），拿交互数据训练推荐模型只要几行：

ALS als = new ALS()
        .setMaxIter(10)          // 迭代轮数：交替优化用户矩阵和物品矩阵
        .setRegParam(0.1)        // 正则化，防过拟合
        .setUserCol("user_id")
        .setItemCol("video_id")
        .setRatingCol("score")   // 行为强度：完播=3 点赞=2 点击=1
        .setColdStartStrategy("drop");

ALSModel model = als.fit(playEvents);
// 输出用户向量和物品向量，供线上召回使用
model.userFactors().write().parquet("s3://warehouse/rec/user_factors/");
model.itemFactors().write().parquet("s3://warehouse/rec/item_factors/");

fit() 跑完，userFactors 就是前面推荐架构文章里说的"每个用户一个几百维的向量"——概念和代码在这里接上了。

Flink 基础：流处理血统的计算引擎

Flink 的出发点反过来：世界本质是流，批只是流的特例（有界流）。数据逐条进来逐条处理，毫秒到秒级延迟。

四个核心概念：

事件时间与水位线（event time & watermark）：事件"发生的时间"和"到达系统的时间"经常不同（用户手机离线两小时，数据才补传上来）。Flink 允许按发生时间计算，水位线是"我认为早于 t 的事件基本都到齐了"的声明，晚到超过容忍度的数据进侧输出流。这是流处理区别于批处理最本质的概念——批处理里根本没有"数据晚到"这个问题。
状态（state）：算子可以持有状态，比如"最近一小时的点击数"。状态按 key 分布在各并行实例上，大作业可以到 TB 级。
checkpoint / exactly-once：定期给所有算子的状态做全局一致性快照，故障后从快照恢复，保证每条数据恰好被计算一次。
savepoint：手动触发的快照，用于升级和扩缩容——代价是"停作业、改并行度、从快照重启"，这也是之前那篇 Netflix 给 Flink 做自动扩缩容那么难的原因。

上手：实时热榜的 Java 写法。场景：统计每个视频最近 10 分钟的播放量，每分钟刷新一次（滑动窗口）：

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
// 每 60 秒做一次 checkpoint，故障恢复就回到最近一次快照
env.enableCheckpointing(60_000);

// 数据源：Kafka
KafkaSource<PlayEvent> source = KafkaSource.<PlayEvent>builder()
        .setBootstrapServers("kafka:9092")
        .setTopics("play-events")
        .setGroupId("hot-ranking")
        .setValueOnlyDeserializer(new PlayEventSchema())
        .build();

// 关键一步：声明用事件时间，容忍 5 分钟乱序
// 手机离线两小时补传的数据，仍然算回"发生那一刻"的窗口
WatermarkStrategy<PlayEvent> wm = WatermarkStrategy
        .<PlayEvent>forBoundedOutOfOrderness(Duration.ofMinutes(5))
        .withTimestampAssigner((event, ts) -> event.getEventTime());

DataStream<PlayEvent> events = env.fromSource(source, wm, "kafka-play-events");

events
        .keyBy(PlayEvent::getVideoId)                                  // 按视频分流
        .window(SlidingEventTimeWindows.of(Time.minutes(10), Time.minutes(1)))
        .aggregate(new PlayCounter())                                  // 窗口内计数
        .addSink(new RedisSink<>());                                   // 结果写 Redis，榜单服务读

这段代码里藏着 Flink 思维方式的全部要点：keyBy 决定状态按什么分发（每个 video_id 一份计数状态），window 按事件时间划分窗口而不是按到达时间，水位线声明"晚到 5 分钟以内的数据我等你"。

状态的 TTL 管理（避坑指南第一条）在代码里长这样：

StateTtlConfig ttl = StateTtlConfig.newBuilder(Time.days(7))
        .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite)   // 写入时刷新过期时间
        .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired)
        .build();

ValueStateDescriptor<Long> desc = new ValueStateDescriptor<>("play-count", Long.class);
desc.enableTimeToLive(ttl);   // 状态 7 天不活跃自动清理，防止无限膨胀

部署：对应的启动命令。Flink 的交付物同样是一个 fat jar，但启动命令和 Spark 有一个本质区别——spark-submit 起的作业算完就退出，flink run 起的作业是常驻的（流处理理论上永不结束）：

# 提交常驻流作业到 YARN（跑在 K8s 上则换成 -t kubernetes-application）
flink run-application \
  -t yarn-application \
  -c com.example.HotRankingJob \      # main 入口类
  -p 64 \                             # 全局并行度：占用 64 个 slot
  hot-ranking.jar

# 升级代码或改并行度的标准动作：先打 savepoint，再从快照恢复
flink stop <jobId> --savepointPath s3://checkpoints/hot-ranking/
flink run-application \
  -t yarn-application \
  -c com.example.HotRankingJob \
  -s s3://checkpoints/hot-ranking/savepoint-abc123 \   # 从这份状态恢复
  -p 128 \                                             # 并行度可以顺便改
  hot-ranking.jar

对照着看两套命令的分工：Spark 用 --num-executors / --executor-cores 申请资源（因为要装下一批又一批的 task）；Flink 用 -p 声明并行度（因为作业结构固定，并行度就是常驻 worker 数）。而 -s 恢复 savepoint 这个参数是 Flink 独有的——Spark 批作业没有"带着状态继续跑"的概念，它每次都是从头算一批新的。

生产环境谁来提交 Flink 作业？ 和 Spark 不完全对称——Flink 没有一个像 SparkLauncher 那样常用的官方 Java 提交 API，业界的答案按部署形态分：

Flink Kubernetes Operator（当前主流）：作业定义成一份 FlinkDeployment YAML（K8s 自定义资源），kubectl apply 即提交。Operator 托管整个生命周期：拉起、监控、升级时自动做 savepoint 并从快照恢复——上面手动敲的 flink stop --savepointPath 那套动作，它全自动；
Apache StreamPark（原 StreamX）：作业管理平台，Web 界面管理 jar 上传、配置、启停和 savepoint，国内团队用得多；
Ververica Platform：Flink 创始团队公司的平台产品（有社区版）；
JobManager REST API：直接 HTTP 上传 jar 再触发 run——Flink Web UI 的提交走的就是它，自研平台想自己包一层时用；
YARN 模式：就是上面那条 flink run-application 命令，CLI 直连，老集群常见。

趋势很明确：K8s Operator 是官方主推方向，新平台直接从这里起步，别再自建提交流程。

血统对比：一张表

维度	Spark	Flink
数据观	有界批处理是本质，流是微批模拟	无界流是本质，批是有界流特例
典型延迟	秒级 - 分钟级	毫秒 - 秒级
状态管理	弱（流场景下才需要，能力有限）	一等公民（keyed state、TB 级）
事件时间	支持，但受微批粒度约束	原生设计，水位线机制成熟
生态主场	数仓 SQL、MLlib、Python 数据科学	实时管道、实时数仓、CEP
思维负担	低：写 SQL / DataFrame 像写单机代码	高：要时刻想着时间、状态、背压

一句话记忆：Spark 把流当批做，Flink 把批当流做；前者简单但延迟高，后者精确但心智负担重。

视频公司里各干什么活

场景设定：一家类 Netflix 的视频公司，几亿用户，每天产生百亿级行为事件。同一条数据流，两种引擎各管一段：

flowchart LR
    A["用户行为事件<br/>播放 暂停 点赞 卡顿"] --> B["Kafka 事件总线"]
    B --> C["Flink 实时链路<br/>秒级生效"]
    B --> D["落地数仓<br/>Iceberg 数据湖"]
    D --> E["Spark 离线链路<br/>小时级 天级"]
    C --> F["在线服务<br/>画像 热榜 监控告警"]
    E --> G["模型 报表 实验分析"]

Flink 的活——“这件事现在就要知道”：

实时画像更新：用户每看一条视频，行为事件进 Kafka，Flink 作业滚动更新"最近 N 次行为的加权兴趣向量"，秒级生效。下一刷推荐就变。
实时热榜：按事件时间滑动窗口统计各视频的播放增速，每分钟刷新 Trending 榜单。注意必须用事件时间——用户手机离线补传的数据不能算到"现在"。
播放质量监控（QoS）：卡顿率、首帧时间、播放失败率按地区/运营商/客户端版本实时聚合，超过阈值就告警。某运营商骨干网抽风，值班同学三分钟内就该收到电话。
实时风控：同一设备十分钟内播放 200 个视频？异常刷量实时拦截，不等第二天对账。

Spark 的活——“这件事今天算完就行”：

数仓 ETL：Kafka 落地到 Iceberg 的原始日志，Spark 按天清洗、去重、补维度（join 用户表、内容表），产出标准明细表。全公司数据分析的地基。
推荐模型训练：拿过去 30 天的用户-内容交互矩阵，训练排序模型（交互矩阵怎么变成用户偏好，详见推荐 Feed 架构里"用户偏好怎么算出来"一节）。训练要扫数据几十遍，正是 Spark 内存迭代的甜点场景。
经营报表：每日播放时长、新增会员、留存率——管理层早上九点要看的看板，Spark 凌晨跑批产出。
A/B 实验分析：实验组对照组的指标对比、显著性检验，数据科学家写 Spark SQL + Python 完成。

同一条数据的两次旅程：用户晚上 8 点点开一条视频——这个事件两秒内被 Flink 消费，画像更新、热榜计数、质量监控全部生效；凌晨 2 点，同一个事件（已从 Kafka 落盘）被 Spark 的 ETL 作业清洗进数仓，早上 6 点进入模型训练数据。实时链路管"现在"，离线链路管"沉淀"，谁也别抢谁的活。

算力规格：硬件怎么配

先给结论再讲推理：大数据集群的钱主要花在内存和 SSD 上，CPU 反而不是瓶颈的主角。

Spark 节点的典型规格（按 2026 年的行情）：

角色	规格	要点
Worker 节点	32-64 核 CPU、128-256GB 内存、4-8 块 NVMe SSD 做本地 shuffle 盘、10-25Gbps 网卡	shuffle 数据写本地盘，SSD 比内存更影响大 join 的稳定性
Executor 切分	每个 executor 4-5 核、16-24GB 堆内存	一台 32 核 128GB 的机器切 5-6 个 executor；executor 太大 GC 停顿长，太小则 broadcast 等开销被重复多份
Driver	8-16GB 内存起步	调度 + 收集元数据；大 job 的执行计划、broadcast 变量都压在这里

Flink 节点的典型规格：

角色	规格	要点
TaskManager	8-16 核、32-64GB 内存、本地 NVMe SSD 必须有	大状态用 RocksDB state backend，状态落在本地盘，SSD 的随机读写直接决定状态访问性能
slot 划分	slot 数 = CPU 核数（1:1 起步）	并行度不能超过总 slot 数；一个 slot 一个线程，避免 CPU 争抢
JobManager	4 核 8GB 起步，HA 模式至少两个	协调 checkpoint，不搬数据，轻
checkpoint 存储	S3 / HDFS / 对象存储	快照不占本地盘，占的是远程存储和网络带宽

容量估算的例子，把数字走一遍：假设行为事件峰值 10 万条/秒、单条 1KB，实时链路（画像 + 热榜 + 监控）合计维护 500GB 状态。

网络：10 万 × 1KB = 100MB/s，25Gbps 网卡毫无压力——数据管道的瓶颈很少是网络；
状态：按单个 TaskManager 管理 64-128GB RocksDB 状态比较稳妥的经验值，500GB 状态需要 4-8 台 TaskManager；
CPU：窗口聚合类作业每条事件的计算很轻，10 万条/秒摊到 64 个核上每核每秒 1500 条，富余；
所以这套链路 8 台"16 核 64GB + NVMe"的机器跑得很从容，再留 30% 峰值冗余即可。

反过来，凌晨的 Spark 训练作业要扫 30 天 × 百 TB 级日志，它的瓶颈是 shuffle 吞吐和内存，机器数量按"凌晨 6 点前必须跑完"倒推——离线集群的规格是被截止时间定义的。

监控：两套引擎各看什么

Spark 监控的主入口是 Spark UI（每个作业一个 Web 界面），配合 Prometheus 抓指标。值班时按这个顺序看：

Stages 页：哪个 stage 慢、shuffle read/write 多大——shuffle spill（内存放不下溢写磁盘）是性能第一警报；
Tasks 页的任务时长分布：p50 是 2 分钟、max 是 40 分钟 → 数据倾斜，不用怀疑；
Executors 页：GC 时间占比超过 10% 说明内存配置或数据结构有问题；executor lost 频繁出现说明节点或内存超卖；
Event Log 持久化到 HDFS/S3，作业挂了也能回放分析——务必开启，默认不一定开。

Flink 监控的主入口是 Web UI + 指标上报（Prometheus reporter），核心看四组：

指标	看什么	告警阈值参考
背压 `backPressuredTimeMsPerSecond`	哪个算子被顶住	持续 >50% 就要查
checkpoint `lastCheckpointDuration` / `lastCheckpointSize`	快照耗时和体积增长趋势	耗时接近间隔、体积周环比暴涨都是事故前兆
Kafka 消费 lag（`records-lag`）	消费追不上生产 = 延迟在堆积	持续增长 10 分钟告警
水位线延迟	事件时间推进是否停滞	水位线不动 = 窗口永远不触发

告警的验收标准只有一条：每个告警都必须对应一个动作。“CPU 高"不是告警，“热榜作业 Kafka lag 连续增长 10 分钟"才是——前者看了也不知道干嘛，后者直接指向扩容或查背压。

故障与恢复：出事时的标准动作

Spark 的故障模型是"重算”，血统里带着 MapReduce 的基因：

task 失败 → 自动重试（默认 4 次，spark.task.maxFailures 可调），重试时只重算这个分区；
executor 挂了 → 它算过的分区按 lineage（血统）重新算——RDD 天生记得自己从哪算来的，这就是当年 RDD 论文的核心思想；
个别 task 特别慢（straggler）→ 开推测执行（spark.speculation=true），同样的任务在别的节点再跑一份，谁先完用谁；
driver 挂了 → 最麻烦，批作业整体重跑；所以重要的 ETL 要幂等（写分区用 overwrite 而不是 append），重跑不出脏数据。

Flink 的故障模型是"回滚”，回到最近一次 checkpoint：

TaskManager 挂了 → 作业自动从最近的成功 checkpoint 恢复，Kafka source 回到快照时记录的 offset 重新消费，配合两阶段提交的 sink 保证恰好一次；
重启策略别用默认：生产上推荐 failure-rate（10 分钟内允许失败 N 次，超过才放弃）配合重启间隔，防止依赖的 Kafka/Redis 抖动时作业无脑高频重启把对方打垮；
JobManager 挂 → 必须配 HA（ZooKeeper 或 K8s 选主），否则协调者单点；
checkpoint 是自动的、savepoint 是手动的：代码升级、改并行度必须先做 savepoint 再停作业，从 savepoint 启动新版本。

一个标准故障处置剧本（实时画像更新作业 lag 暴涨）：

看 Flink UI 背压页——找到链条上第一个变红的算子；
是某个下游慢（比如 Redis 抖动）→ 修下游，作业自己追上来；
是数据洪峰 → 临时调大并行度（savepoint → 重启 → 恢复），或者干脆等洪峰过去，Kafka 里的数据丢不了；
恢复后盯 Kafka lag 回落到正常水位，确认 checkpoint 恢复绿色；
事后复盘：这次故障该变成哪条告警规则？

注意底气来自哪里：Kafka 保留了原始事件，Flink 保留了状态快照——前者保证"数据丢不了"，后者保证"进度丢不了"。两个都在，故障就只是插曲不是事故。

Kafka + Flink 组合：失败后到底会不会重复、会不会丢

这是面试和值班都绕不开的问题，拆开两个角色看就清楚了。

Kafka 侧：消息几乎不可能"被消费掉"。 Kafka 是持久化日志，消费不删除数据，保留期（比如 7 天）内随便重读。Flink 的 Kafka source 消费时不逐条 ack，只在 checkpoint 里记录各分区的 offset。所以消息丢失只有两种可能：保留期过了，或者 Kafka 集群自己故障。

Flink 侧：重启 = 状态回滚 + offset 回拨，两件事同步发生。 故障后从最近一次成功的 checkpoint 恢复，同一时刻两个动作：

flowchart LR
    A["故障发生<br/>部分事件已消费已计算"] --> B["从最近 checkpoint 恢复"]
    B --> C["Kafka offset 回拨<br/>到快照时刻"]
    B --> D["算子状态回滚<br/>到快照时刻"]
    C --> E["快照之后的事件重新消费"]
    D --> E
    E --> F["在回滚后的状态上重算<br/>内部不多算也不少算"]

假设 checkpoint 间隔 60 秒：故障意味着最多重放最近 60 秒的事件——重放不是丢失，是进度倒退后追赶。由于状态和 offset 同步回滚，窗口计数这类状态计算在内部是精确的（exactly-once）。

但"对外不重复"取决于 sink，这是最容易踩的边界：

sink 类型	端到端语义	例子
两阶段提交 sink	exactly-once	Kafka sink（事务）、Iceberg
幂等写入	等效 exactly-once	Redis 按 key 覆盖写、MySQL upsert
普通追加	at-least-once，会重复	直接 insert 进 MySQL、对外发 HTTP 回调

重放的那 60 秒里，如果 sink 是普通 insert，下游表里就会出现重复行——作业内部算得再精确，写出去的那一刻语义就降级了。这就是"exactly-once 只在链路两端都配合时才成立"的含义。

真正会丢、会重的边界情况清单：

没开 checkpoint：offset 只能周期性提交到 Kafka，重启从提交点读——退化成 at-least-once，且恢复语义模糊；
Kafka 保留期 < 故障停机时间：作业停 8 天、Kafka 只留 7 天，恢复时最早的数据真没了；
异步 IO 和侧输出不参与 checkpoint：算子里偷偷调外部接口、写侧输出流，这些动作不在快照里，重放时会重复执行；
savepoint 与升级不兼容：改了状态结构（比如给状态类加了字段）还想从旧 savepoint 恢复，直接恢复失败——升级前想清楚状态兼容性。

多节点会不会重复消费同一个分区：消费组的互斥语义

顺带的另一个常见疑问：Flink 作业有几十个 source subtask 在多个节点上跑，会不会两个节点同时读同一个 Kafka 分区、把数据算两遍？

不会，这是 Kafka 消费组协议内建的互斥保证，不需要你做任何事：

同一作业的所有 source subtask 用同一个 group.id 注册，Kafka 的组协调器把分区互斥分配——每个分区同一时刻只属于组内一个消费者。200 个分区、64 个 subtask，每个 subtask 分 3-4 个，互不重叠；
节点挂了触发 rebalance，分区重新分配，但交接是排他的：旧持有者被踢出组之后，新持有者才接手，不存在两个节点同时持有同一分区的窗口；
所以同一作业内"重复消费"只有一种情况：故障恢复时的时间维度重放（上一节讲的回滚），不存在"空间维度"的并行重复。

两个相关的配置纪律：

source 并行度不要超过分区数。并行度 64、分区只有 32 个时，32 个 subtask 永远分不到分区、空转白占资源。反过来分区数多于并行度没问题，一个 subtask 可以吃多个分区。
不同作业必须用不同的 group.id。消费组之间是广播语义——画像作业和热榜作业各自完整消费同一个 topic，互不干扰，这是特性。但两个本该独立的作业如果误配成同一个 group.id，就会瓜分分区、各自只读到一半数据，这种 bug 症状隐蔽（数据看着都在流，就是量不对），值得配进上线检查清单。

数据源不止 Kafka：还能从哪读，API 数据怎么办

Flink 的 source 生态按类别列全：

类别	连接器	场景
消息队列	Kafka、Pulsar、Kinesis、RocketMQ（社区）	实时事件流的主力入口
数据库 CDC	MySQL CDC、PostgreSQL CDC、MongoDB CDC（Flink CDC 项目）	直接订阅 binlog，数据库变更实时变成流——替代"定时全量导库"，是这几年增量最大的方向
文件/对象存储	FileSource（S3 / HDFS / 本地），支持批读和持续监听目录	批处理、日志文件实时采集
JDBC	Table API 的 JDBC connector	轮询式读关系库，伪实时
测试	DataGen 数据生成器、socket 流	本地开发与压测

HTTP API 提供的数据怎么办？ 核心发行版里没有内置的 HTTP source，分两种情况：

情况一：API 是数据源（想持续消费一个 REST 接口）。正确姿势不是让 Flink 直接轮询 API，而是中间加一层 Kafka：一个轻量采集服务定时调 API、把结果写进 Kafka，Flink 消费 Kafka。原因正是前两节的内容——Kafka 提供可回放、削峰、多消费者，API 直连则什么都没有：Flink 作业一挂，这段时间的 API 数据就永远丢了。非要直连也行：实现自定义 Source 接口自己轮询，但 offset 管理、故障恢复语义全得自己做，一般不值。

情况二：API 是维表（事件流经过时补充字段）。这是更常见的需求：每条事件只有 video_id，需要调内容服务拿标题、类目、时长。Flink 有标准件——异步 IO（Async I/O）：在算子里并发调用 HTTP 接口、回调组装结果，不阻塞主流；Table API 里对应的写法是 lookup join。配一层本地缓存（Guava/Caffeine）挡掉热点 key 的重复调用，避免把对方服务打挂。注意它的语义是"查询"不是"消费"——只在事件流经过时被动调用，永远不会主动拉数据。

Spark 避坑指南

按踩坑频率排序：

数据倾斜是第一杀手。某个 key 的数据量特别大（比如头部视频占了 10% 播放量），groupBy/join 时对应分区要处理别人几十倍的数据，99% 的任务十分钟跑完，最后 1% 卡两小时。解法：给热点 key 加盐（key 后面拼随机后缀打散）、先聚合再关联、小表广播（broadcast join）避免 shuffle。
小文件问题。ETL 作业输出几万个几 KB 的小文件，下游读取慢、元数据服务被打爆。解法：写出前 coalesce/repartition 控制分区数，或开自适应合并。
shuffle 爆炸。join 两张大表，中间数据量是笛卡尔级增长。先看能不能把一张表过滤小再 join，能 broadcast 就 broadcast。
滥用 cache。.cache() 不是免费的，内存不够会挤占执行内存反而更慢。只缓存"会被复用多次"的中间结果。
分区数拍脑袋。分区太少 → 单任务处理量太大 OOM；太多 → 任务调度开销压垮 driver。经验值：单个分区处理 128MB 上下。
driver OOM。collect() 把全量数据拉回 driver——生产事故的经典配方。要看几行数据用 show()/take()。

Flink 避坑指南

状态不设 TTL 无限膨胀。keyed state 默认永不过期，跑一个月状态涨到 TB 级，checkpoint 从秒级拖到分钟级最后超时失败。用户维度状态几乎总该设 TTL（比如 7 天）。
checkpoint 间隔拍太短。间隔小于一次 checkpoint 本身的耗时，系统永远在做快照没有空算数据。先看一次 checkpoint 要多久，间隔至少留它几倍。
背压不会看。作业 lag 持续上涨，先去 UI 看背压面板：红色背压的算子就是瓶颈，瓶颈的上游全会被"传染"成红色——找到链条上第一个变红的，那才是真正的病灶。
事件时间和处理时间混用。用处理时间算"每分钟播放量"，用户手机补传的数据会把昨天的量记到今天。涉及"按发生时间统计"的需求，必须事件时间 + 水位线，并接受乱序容忍度的权衡。
扩缩容当成无状态服务做。改并行度 = savepoint + 停作业 + 重启，大状态作业分钟级中断。扩缩容策略要保守，这个坑的完整故事见 Netflix 两代 autoscaler。
exactly-once 当默认值。端到端 exactly-once 要求 sink 支持两阶段提交，代价是吞吐下降。很多监控类场景 at-least-once + 下游幂等就够了，别为不需要的语义付费。

通用坑：用 Spark 微批硬扛秒级需求。需求方说"准实时"，你拿 Structured Streaming 把触发间隔压到秒级——能跑，但状态管理和乱序处理的坑会一个个冒出来。先问清楚：延迟到底是秒级还是分钟级需求？分钟级 Spark 很舒服，秒级请直接上 Flink，别硬扛。

选型决策

数据是有界的、延迟容忍分钟级以上 → Spark
数据是持续流、延迟要求秒级、或需要复杂状态/事件时间 → Flink

但必须诚实：边界在模糊化。Spark 能做流、Flink 能做批，两个社区都在往对方的领地走；Flink 的 Table API 写 SQL 也越来越像 Spark SQL。真实的选型经常是这样决定的：团队现有栈是什么、招聘市场上谁会、云厂商托管服务谁更便宜。技术血统决定的是"哪个更顺"，不是"哪个能做"。

国内的实际格局（2020 年代中期的现状，供校准）：

新上实时项目基本是 Flink。阿里 2019 年收购 Flink 母公司后全力主推（内部版 Blink 撑双 11 实时大屏），字节、美团、腾讯、快手的实时平台全部 Flink 化，新立项用 Spark Streaming 的已很难见到；
存量离线仍是 Spark 的天下：数仓 ETL、T+1 报表、Hive 承接，生态太厚，替换动力不足；
两边都在被挤压：Spark 的机器学习场景在流失到 Python 原生生态（PyTorch/Ray）；Flink 在进攻离线——“流批一体”（一套 SQL 跑流也跑批）配合 Paimon 这类流式湖格式在落地，但离线存量太重，替换以年计；
一句话：新实时 = Flink，存量离线 = Spark，交界处（实时数仓）在打架。求职市场同构：实时岗位 Flink 是硬通货，离线岗位 Spark/Hive 是基础盘。

一句话收拢：Spark 回答"这批数据算出来是什么"，Flink 回答"这件事现在发生了什么"；先想清楚你的问题是哪一种，再选工具——反过来拿着工具定义问题，是大数据平台翻车的最常见起点。

参考：Apache Spark 与 Apache Flink 官方文档；Structured Streaming 与 Flink DataStream 的设计文档。Netflix 场景参考其技术博客公开的数据平台架构。

Spark 从入门到精通：架构原理、RDD/DataFrame、调优踩坑与电商实战全指南

Wed, 26 Oct 2022 09:30:00 +0800

Spark 从入门到精通：架构原理、RDD/DataFrame、调优踩坑与电商实战全指南

目标读者：写过一两年后端（Java/Scala/Python 皆可）、第一次要碰大数据的同学；或者用 PySpark 写过一些脚本、但一遇到性能问题就抓瞎的同学。写这篇文章时（2022 年 10 月），Spark 3.3 刚发布，DataFrame 早已是绝对主流，Flink 在实时方向上攻城略地。但离线批处理、数仓 ETL、特征工程这些重活，Spark 依然是绕不开的那座山。

全文六篇，顺序就是学习的顺序：

flowchart LR
    A["一 为什么是 Spark<br/>从单机到分布式"] --> B["二 架构与原理<br/>Driver Executor DAG"]
    B --> C["三 RDD 与 DataFrame<br/>两代 API 的分水岭"]
    C --> D["四 电商实战<br/>宽表 漏斗 特征"]
    D --> E["五 调优与踩坑<br/>倾斜 OOM 小文件"]
    E --> F["六 AI 时代<br/>少写代码 多写提示词"]
    style F fill:#e8f4e8

为什么是这个顺序？第一篇解决「为什么要用它」；第二篇解决「它在集群里怎么跑」——不理解这个，写出来的代码就是玄学；第三篇解决「代码怎么写」；第四篇用真实业务把知识串起来；第五篇是血泪史，生产环境和本地 Demo 是两个物种；第六篇聊怎么让 AI 替你干活。

第一篇为什么是 Spark：一台机器装不下的时代

1.1 一个电商场景把问题引出来

假设你在一家中型电商公司做后端。双十一刚过，老板要看一份报表：

昨天所有下单用户，按城市分组，统计成交额、下单次数、客单价，再看这批用户里有多少是 30 天内的新客。

订单表 8 亿行，用户表 4000 万行，行为日志（埋点）一天 20 亿条。MySQL 里跑这个 SQL？GROUP BY 一个 8 亿行的表，跑一晚上 MySQL 先把你杀了——不，是 DBA 先把你杀了。

你想到的办法是「把数据导出来，写个 Python 脚本跑」。8 亿行订单数据，CSV 导出大概 400GB。你的开发机内存 32GB。装不下，这就是大数据的全部问题。

解决思路只有两个方向：

flowchart TB
    subgraph 思路一["思路一：垂直扩展（Stack Overflow 式的天真）"]
        A1["换个 1TB 内存的机器"] --> A2["贵得离谱<br/>且有物理上限"]
    end
    subgraph 思路二["思路二：水平扩展（唯一出路）"]
        B1["把 400GB 切成 1000 份"] --> B2["1000 台机器<br/>每台处理 400MB"]
        B2 --> B3["各自算局部结果<br/>最后合并"]
    end

思路二就是分布式计算。但自己写 1000 台机器的协调代码？分发任务、处理机器挂掉、合并结果、处理网络超时……你会写出第二个 Hadoop。

Spark 就是替你把这些脏活全包了：你只写「对这批数据做什么变换」，它负责切分、调度、容错、合并。

1.2 Spark 在生态里的位置

新人最容易被一堆名词搞晕：Hadoop、HDFS、YARN、Hive、Spark、Flink。一张图说清楚：

flowchart TB
    subgraph 存储层
        HDFS["HDFS<br/>分布式文件系统<br/>（把文件切块存到多台机器）"]
        S3["S3 / OSS<br/>对象存储"]
    end
    subgraph 资源层
        YARN["YARN / K8s<br/>集群资源调度<br/>（给任务分配 CPU 和内存）"]
    end
    subgraph 计算层
        MR["MapReduce<br/>老一辈 磁盘IO 慢"]
        SPARK["Spark<br/>内存计算 快<br/>本篇主角"]
        FLINK["Flink<br/>流处理专精"]
    end
    subgraph 应用层
        HIVE["Hive/Spark SQL<br/>SQL 写报表"]
        DS["数据科学<br/>MLlib 特征工程"]
    end
    HDFS --> YARN
    S3 --> YARN
    YARN --> MR
    YARN --> SPARK
    YARN --> FLINK
    SPARK --> HIVE
    SPARK --> DS
    style SPARK fill:#ffd699

几个关键认知：

Spark 不是存储系统，它没有自己的存储，数据放在 HDFS、Hive 表、S3 甚至 MySQL 里，它读进来算完再写回去。
Spark 也不是资源调度器，它跑在 YARN 或 Kubernetes 上，向它们「申请」机器。
Spark 相对 MapReduce 的快，核心就一句话：中间结果放内存，不落地磁盘。MapReduce 每步都要写磁盘，迭代式计算（比如机器学习跑 50 轮迭代）就慢到不可用。

踩坑预告：很多人学 Spark 的第一步是去装 Hadoop 全家桶，装了一周还没跑起来 Hello World。其实本地学习完全不需要——Spark 有 local 模式， pip 装个 pyspark 就能跑。下一篇的 Demo 全是单机可运行的。

第二篇架构与原理：代码提交之后到底发生了什么

这是最重要的一篇。Spark 调优 80% 靠对这套架构的直觉，剩下 20% 才是参数。

2.1 一次 Spark 任务的全貌

flowchart TB
    CODE["你的代码<br/>spark.read... .groupBy... .write..."] --> DRV
    subgraph Cluster["集群（YARN / K8s）"]
        subgraph DRV["Driver（司机/总指挥）"]
            DAG["DAG Scheduler<br/>把代码翻译成执行计划<br/>切成若干 Stage"]
            TS["Task Scheduler<br/>把 Stage 拆成 Task<br/>派发给 Executor"]
        end
        subgraph EXE["Executor × N（干活的工人）"]
            T1["Task 1<br/>处理 Partition 1"]
            T2["Task 2<br/>处理 Partition 2"]
            T3["Task 3<br/>处理 Partition 3"]
            CACHE["内存/磁盘<br/>缓存中间数据"]
        end
    end
    TS --> T1
    TS --> T2
    TS --> T3
    T1 -.shuffle 阶段互相交换数据.-> T2

关键角色就三个：

Driver：你的 main 函数（或 PySpark 脚本）运行的地方。它不干活，它发号施令——分析你的代码、生成执行计划、把任务派发出去、回收结果。Driver 挂了，整个任务就完了。
Executor：集群里真正干活的 JVM 进程，每个 Executor 有若干核，每个核同时跑一个 Task。数据是**分区（Partition）**存储的，一个 Task 处理一个 Partition。
Shuffle：当操作需要跨机器汇总数据（groupBy、join、distinct），数据就要在网络上重新分发——这叫 Shuffle。Shuffle 是 Spark 任务慢的第一大原因，后文反复出现。

2.2 懒执行（Lazy Evaluation）：为什么你的代码"没报错"却在运行时炸了

新手最常踩的认知坑：Spark 代码写下去并不会立刻执行。

df = spark.read.csv("orders.csv")          # 没执行！只是记录"要读个文件"
df2 = df.filter(df.amount > 100)           # 没执行！只是记录"要过滤"
df3 = df2.groupBy("city").sum("amount")    # 没执行！只是记录"要分组聚合"
df3.write.save("output")                   # 现在才真正开始跑！

读数据、过滤、分组这些叫 Transformation（变换），只是往计划里加节点；write、count、collect、show 这些叫 Action（行动），碰到 Action，Driver 才把整条链路翻译成 DAG（有向无环图），切成 Stage，真正派发执行。

这个设计的好处是优化：Spark 的 Catalyst 优化器能看到整条链路，比如发现你过滤条件写晚了，它可以自动把 filter 下推到读数据时就做（Predicate Pushdown），少读一半数据。

但坑也随之而来：

踩坑故事 1：错误行号的谎言 刚转 Spark 时我排查一个任务失败，日志说第 87 行 df.write.save() 报错 “文件不存在”。我盯着 87 行看了半小时——write 语法没问题啊！后来才明白：真正的错误发生在第 12 行的 spark.read（路径写错了），但因为是懒执行，直到 87 行触发 Action 才爆出来。看 Spark 报错，永远要从日志里的执行计划往上找 Transformation 的源头，而不是看报错行号。

2.3 Stage 是怎么切出来的：宽依赖与窄依赖

理解 Shuffle 就理解了 Stage 的切分：

flowchart LR
    subgraph Stage1["Stage 1（窄依赖，流水线执行）"]
        P1["Partition 1<br/>读文件"] --> F1["filter<br/>过滤"]
        P2["Partition 2<br/>读文件"] --> F2["filter<br/>过滤"]
    end
    subgraph SHUFFLE["⚡ Shuffle（跨网络搬数据）"]
        direction TB
        S["按 city 重新分区<br/>同 city 的数据<br/>汇聚到同一 Partition"]
    end
    subgraph Stage2["Stage 2"]
        G1["Partition A<br/>北京的订单<br/>sum(amount)"]
        G2["Partition B<br/>上海的订单<br/>sum(amount)"]
    end
    F1 --> SHUFFLE
    F2 --> SHUFFLE
    SHUFFLE --> G1
    SHUFFLE --> G2
    style SHUFFLE fill:#ffcccc

窄依赖（filter、map）：子 Partition 只依赖父的一个 Partition，可以像流水线一样在同一台机器一口气算完，不分 Stage。
宽依赖（groupBy、join、distinct）：子 Partition 需要父的所有 Partition 的数据，必须 Shuffle，Stage 在这里断开。

一个 Stage 内的失败重试只重跑这个 Stage。所以 Spark 的容错单位是 Stage——这也是为什么 Spark 会把 Shuffle 的中间结果落盘（对，嘴上说自己内存计算，Shuffle 还是要写磁盘的），挂了能从这里恢复，而不是从头再来。

第三篇 RDD 与 DataFrame：两代 API 的分水岭

3.1 RDD：能看清每个零件，但要自己造发动机

RDD（弹性分布式数据集）是 Spark 1.x 的核心抽象。用它写上面的需求：

// RDD 风格：你告诉 Spark 每一步"怎么做"
orders
  .filter(_.split(",")(5).toDouble > 100)     // 自己解析 CSV，自己转类型
  .map(line => (line.split(",")(3),           // 自己取城市字段做 key
                line.split(",")(5).toDouble)) // 自己取金额做 value
  .reduceByKey(_ + _)                          // 按 key 聚合
  .saveAsTextFile("output")

RDD 的问题是：Spark 看不懂你在干什么。filter(_.split(",")(5).toDouble > 100) 对优化器来说就是一个黑盒 lambda，它不知道你在过滤哪列，没法做谓词下推，没法选更好的 join 策略。而且 JVM 里每一行都是一个 Java 对象，序列化开销大、GC 压力巨大。

3.2 DataFrame：你只说"要什么"，优化器替你想"怎么做"

DataFrame（Spark 1.3 引入，2.0 后与 Dataset 合并）给数据加了Schema（表结构），从此 Spark 能看懂你的意图：

# DataFrame 风格：声明式
(spark.read
  .schema("order_id STRING, city STRING, amount DOUBLE")
  .csv("orders.csv")
  .filter("amount > 100")
  .groupBy("city")
  .sum("amount")
  .write.parquet("output"))

两者差距有多大？同样的逻辑，DataFrame 通常比 RDD 快 2~10 倍，原因：

flowchart TB
    subgraph RDD路径["RDD：信任程序员"]
        R1["你的 lambda"] --> R2["逐行 Java 对象<br/>序列化/GC 开销大<br/>优化器爱莫能助"]
    end
    subgraph DF路径["DataFrame：信任优化器"]
        D1["声明式表达式"] --> D2["Catalyst 优化器<br/>逻辑计划优化<br/>谓词下推/列裁剪"]
        D2 --> D3["Tungsten 执行引擎<br/>二进制内存布局<br/>代码生成 绕开 GC"]
    end
    style DF路径 fill:#e8f4e8

一句话结论（2022 年视角）：新业务永远用 DataFrame/Spark SQL 写，RDD 只在两种情况下出现——操作的是非结构化数据（比如解析一堆不规则日志），或者需要逐分区精细控制（mapPartitions 里建数据库连接池这种）。面试让你手写 RDD wordcount 是考察理解，不是让你生产上这么写。

3.3 本地就能跑的完整 Demo

别急着上集群。装个 Python 环境就能跑：

pip install pyspark==3.3.0

造一份模拟电商订单数据，跑通「读 → 变换 → 聚合 → 写」全流程：

# demo01_basic.py
from pyspark.sql import SparkSession
from pyspark.sql import functions as F

spark = (SparkSession.builder
         .appName("demo01")
         .master("local[*]")      # 本地模式，用满 CPU 核
         .getOrCreate())

# 造数据：100 万行模拟订单
orders = (spark.range(0, 1_000_000)
          .select(
              F.concat(F.lit("ORD"), F.col("id")).alias("order_id"),
              (F.col("id") % 50000).alias("user_id"),
              F.element_at(
                  F.array([F.lit(c) for c in
                           ["北京", "上海", "广州", "深圳", "杭州"]]),
                  (F.col("id") % 5 + 1).cast("int")).alias("city"),
              (F.rand() * 2000).alias("amount"),
              F.date_add(F.lit("2022-10-25"),
                         -(F.col("id") % 30).cast("int")).alias("order_date")))

result = (orders
          .filter(F.col("amount") > 100)
          .groupBy("city")
          .agg(F.count("*").alias("order_cnt"),
               F.round(F.sum("amount"), 2).alias("gmv"),
               F.round(F.avg("amount"), 2).alias("avg_price"))
          .orderBy(F.desc("gmv")))

result.show()          # Action：真正触发执行
result.write.mode("overwrite").parquet("output/city_gmv")
spark.stop()

运行：

python demo01_basic.py

输出：

+----+---------+-----------+---------+
|city|order_cnt|        gmv|avg_price|
+----+---------+-----------+---------+
|  深圳|   190231|...        |  1050.12|
|  北京|   190087|...        |  1049.87|
...
+----+---------+-----------+---------+

这个 Demo 麻雀虽小，五脏俱全：spark.range 造数、element_at 数组取值、rand 随机数、聚合多指标、写 Parquet。本地玩熟了，语法迁移到集群上一行都不用改——这就是 Spark 的优雅之处。

踩坑故事 2：Windows 上的 winutils.exe 我在 Windows 笔记本上第一次跑 PySpark，直接 winutils.exe 缺失报错 + 一堆权限异常。解决办法是下载对应 Hadoop 版本的 winutils.exe 放到 %HADOOP_HOME%\bin 并设置环境变量。后来学乖了：学习期直接 WSL2 或者 Docker 起个 Linux 环境，少生一肚子气。

第四篇电商实战：把知识串成业务

这一篇用三个电商真实场景，把前面的知识点全部用起来。这三个场景也是面试里最高频的"你做过什么项目"素材。

4.1 场景一：订单宽表（每日 ETL）

业务：订单数据分散在三张表——订单主表（order_id、user_id、amount、pay_time）、订单明细表（order_id、sku_id、quantity）、商品维表（sku_id、category、brand）。数据仓库要求每天凌晨产出一张"订单明细宽表"，下游 BI 直接查它。

# demo02_dwd_wide_table.py
orders = spark.table("ods.orders").filter(F.col("dt") == "2022-10-25")
items  = spark.table("ods.order_items").filter(F.col("dt") == "2022-10-25")
skus   = spark.table("dim.sku").filter(F.col("dt") == "2022-10-25")

wide = (items
        .join(orders, "order_id")
        .join(F.broadcast(skus), "sku_id")   # ★ 维表小，广播它！
        .select("order_id", "user_id", "sku_id", "category", "brand",
                "quantity", "amount", "pay_time")
        .withColumn("dt", F.lit("2022-10-25")))

(wide.write
 .mode("overwrite")
 .partitionBy("dt")
 .parquet("warehouse/dwd/order_detail_wide"))

知识点：Broadcast Join。普通 join 两张表都要 Shuffle；但如果一张表很小（商品维表几十万行，几十 MB），Spark 可以把它整个复制到每个 Executor 的内存里，大表原地不动就能完成 join——Shuffle 直接消失，速度提升一个数量级。

判断标准：小表 < spark.sql.autoBroadcastJoinThreshold（默认 10MB，生产常调到 100MB~500MB）。写 F.broadcast(skus) 是显式强制，防止优化器估算失误。

flowchart LR
    subgraph 普通Join["普通 Sort-Merge Join（两张表都 Shuffle）"]
        A1["大表 Partition"] -.网络搬家.-> J1["Join 节点"]
        A2["维表 Partition"] -.网络搬家.-> J1
    end
    subgraph 广播Join["Broadcast Join（只有小表复制）"]
        B1["大表 Partition 1<br/>原地不动"] --> C1["本地 Join<br/>查内存里的小表"]
        B2["大表 Partition 2<br/>原地不动"] --> C2["本地 Join<br/>查内存里的小表"]
        SM["小表整表复制<br/>→ 每个 Executor"] --> C1
        SM --> C2
    end
    style 广播Join fill:#e8f4e8

4.2 场景二：用户行为漏斗（转化率分析）

业务：运营想知道双十一预热期的转化漏斗：曝光 → 点击 → 加购 → 下单 → 支付，每一步流失多少人。

# demo03_funnel.py
events = spark.table("ods.user_events").filter(F.col("dt") == "2022-10-25")
# events 字段：user_id, event_type(view/click/cart/order/pay), ts

# 每个用户在每一步的最早时间
first_ts = (events
            .groupBy("user_id")
            .agg(F.min(F.when(F.col("event_type") == "view",  F.col("ts"))).alias("t_view"),
                 F.min(F.when(F.col("event_type") == "click", F.col("ts"))).alias("t_click"),
                 F.min(F.when(F.col("event_type") == "cart",  F.col("ts"))).alias("t_cart"),
                 F.min(F.when(F.col("event_type") == "order", F.col("ts"))).alias("t_order"),
                 F.min(F.when(F.col("event_type") == "pay",   F.col("ts"))).alias("t_pay")))

# 严格漏斗：必须按时间顺序走到该步才算转化
funnel = first_ts.agg(
    F.count("t_view").alias("曝光"),
    F.count(F.when(F.col("t_click") > F.col("t_view"), 1)).alias("点击"),
    F.count(F.when(F.col("t_cart")  > F.col("t_click"), 1)).alias("加购"),
    F.count(F.when(F.col("t_order") > F.col("t_cart"),  1)).alias("下单"),
    F.count(F.when(F.col("t_pay")   > F.col("t_order"), 1)).alias("支付"))

funnel.show()

知识点：groupBy + 条件聚合（F.when inside agg）是漏斗分析的标准套路——一行 SQL 出五步漏斗，不用写五次 count 再 join。这也是经典面试题。

踩坑故事 3：漏斗口径的战争 我第一版漏斗上线后，运营说数据和他们对不上。查了半天，发现分歧在口径：我写的是"严格顺序漏斗"（必须 view 之后才 click 才算），运营期望的是"存在性漏斗"（只要当天两个行为都发生过就算）。大数据开发一半的返工不是技术问题，是口径没对齐。现在的习惯：开工前把每一步的定义写成一行白话发群里，确认了再写代码。

4.3 场景三：推荐特征工程（用户画像）

业务：算法团队要用户特征——每个用户近 30 天的购买次数、客单价、最偏爱类目、最近一次购买距今天数（RFM 模型的雏形）。

# demo04_user_features.py
from pyspark.sql.window import Window

orders_30d = spark.table("dwd.order_detail_wide").filter(
    F.col("dt").between("2022-09-26", "2022-10-25"))

# 基础聚合特征
agg_feat = (orders_30d
            .groupBy("user_id")
            .agg(F.countDistinct("order_id").alias("order_cnt_30d"),
                 F.round(F.avg("amount"), 2).alias("avg_amount_30d"),
                 F.max("pay_time").alias("last_pay_time")))

# 最偏爱类目：窗口函数按类目的购买金额排序取第一
w = Window.partitionBy("user_id").orderBy(F.desc("cat_amount"))
top_cat = (orders_30d
           .groupBy("user_id", "category")
           .agg(F.sum("amount").alias("cat_amount"))
           .withColumn("rn", F.row_number().over(w))
           .filter(F.col("rn") == 1)
           .select("user_id", F.col("category").alias("top_category")))

features = (agg_feat
            .join(top_cat, "user_id")
            .withColumn("days_since_last_pay",
                        F.datediff(F.lit("2022-10-26"), F.col("last_pay_time"))))

features.write.mode("overwrite").parquet("features/user_rfm/dt=2022-10-25")

知识点：窗口函数（Window.partitionBy(...).orderBy(...) + row_number）是"每组取 TopN"的标准解法，Hive SQL 里也是同一句，大数据面试必考。

三个场景串起来，就是一条标准的离线数仓链路：

flowchart LR
    subgraph 数据源
        DB["业务 MySQL<br/>订单/明细/商品"]
        LOG["埋点日志<br/>曝光/点击/加购"]
    end
    DB -->|Sqoop/DataX 同步| ODS
    LOG -->|Flume/直接落盘| ODS
    subgraph 数仓["数仓分层（Hive on Spark）"]
        ODS["ODS 贴源层<br/>原样搬运"] --> DWD["DWD 明细层<br/>清洗 关联 宽表<br/>★ 场景一"]
        DWD --> DWS["DWS 汇总层<br/>按主题聚合<br/>★ 场景二漏斗"]
        DWS --> ADS["ADS 应用层<br/>直接服务业务<br/>★ 场景三特征"]
    end
    ADS --> BI["BI 报表"]
    ADS --> ALG["推荐算法"]

第五篇调优与踩坑：生产环境才是真的战场

本地 Demo 岁月静好，上了生产环境才知道什么叫残酷。下面三个坑，每一个我都在凌晨两点处理过。

5.1 天坑一：数据倾斜（一个 Task 跑三小时，其他三分钟）

现象：任务 99% 的 Stage 秒过，最后一个 Stage 的 200 个 Task 里，199 个 5 分钟跑完，1 个跑了 3 小时还在爬。Spark UI 上看，那个 Task 的 Shuffle Read 是别人的几百倍。

原因：某个 key 的数据量碾压其他 key。电商里最典型的就是：

大促时某个爆款商品（iPhone 发售当天）的订单明细占全站 30%；
维表 join 时空值/默认值 key——脏数据的 user_id = null 或 '-1' 有上千万条，全挤到一个 Partition。

排查：Spark UI → Stages → 看 Task 的 Summary Metrics，Max 时间远大于 Median（中位数），就是倾斜。

解法三板斧：

# 招式1：过滤异常 key（脏数据导致的倾斜，90% 的情况）
df = df.filter(F.col("user_id").isNotNull() & (F.col("user_id") != "-1"))

# 招式2：热点 key 加盐打散（真热点，比如爆款商品）
# 给大表的热点 key 加随机后缀 0~9，小表对应 key 复制 10 份
salted = big.withColumn(
    "join_key",
    F.when(F.col("sku_id") == "爆款SKU",
           F.concat(F.col("sku_id"), F.lit("_"), (F.rand()*10).cast("int")))
     .otherwise(F.col("sku_id")))
small_exploded = small.withColumn(
    "join_key",
    F.when(F.col("sku_id") == "爆款SKU",
           F.concat(F.col("sku_id"), F.lit("_"),
                    F.explode(F.array([F.lit(i) for i in range(10)]))))
     .otherwise(F.col("sku_id")))

# 招式3：开启 AQE 自动处理（Spark 3.x 的救星）
spark.conf.set("spark.sql.adaptive.enabled", "true")
spark.conf.set("spark.sql.adaptive.skewJoin.enabled", "true")

踩坑故事 4：AQE 救了我一个通宵 2022 年上半年迁移 Spark 3.x 后开了 AQE（Adaptive Query Execution），它能在运行时发现倾斜的 Partition 并自动拆分。以前要手工调参数 spark.sql.shuffle.partitions 反复试的任务，AQE 直接自己搞定了。所以第一建议永远是：先升级到 Spark 3.x 并开启 AQE，再用脑子去调。

flowchart TB
    subgraph 倾斜前["倾斜：一个 Partition 吞掉 40% 数据"]
        K1["Partition 1: 50MB"] 
        K2["Partition 2: 8GB 😱"] 
        K3["Partition 3: 50MB"]
    end
    subgraph 倾斜后["AQE 拆分后：化整为零"]
        L1["Partition 1: 50MB"]
        L2a["Partition 2a: 200MB"]
        L2b["Partition 2b: 200MB"]
        L2c["Partition 2c: 200MB<br/>...共拆 40 份"]
        L3["Partition 3: 50MB"]
    end
    倾斜前 -->|"AQE 运行时检测拆分"| 倾斜后
    style K2 fill:#ffcccc

5.2 天坑二：OOM（内存不够，但到底谁不够）

Spark 的 OOM 分两种，报错长得像，病因完全不同：

报错关键字	病因	解法
`ExecutorLostFailure` / 容器被 kill / `java.lang.OutOfMemoryError`	Executor 内存不够：数据太多、缓存太大	加 `executor-memory`、增加分区数摊薄数据、减少 `cache` 滥用
Driver 端 OOM	Driver 内存不够：几乎永远是 `collect()` / `toPandas()` 把全量数据拉回 Driver	不要用 collect 收大数据！用 `take(100)` 抽样看，用 `write` 落盘

踩坑故事 5：一个 collect 拖垮了整个集群调度 同事为了"快速验证"，在生产任务里写了 df.collect() 然后 len() 一下——那张表 2 亿行。Driver 内存从 4G 一路撑爆，任务挂掉不说，还因为是调度系统的重要任务，报警电话打到了总监那里。从此组里 Code Review 第一条红线：搜索代码里有没有 collect()、toPandas()，有就必须说明数据量上限。

5.3 天坑三：小文件灾难（HDFS 的慢性病）

现象：任务很快跑完，但写出的结果目录里是 20000 个 100KB 的小文件。然后：Hive 查这张表慢得离谱，NameNode 内存报警，下游任务读它要启动几万个 Task。

原因：200 个分区 × 每次写 100 个文件 = 每天积累，几个月后就是几百万小文件。HDFS 的 NameNode 把每个文件的元数据放内存，小文件多是集群的头号慢性病。

解法：

# 写出前合并分区（注意：coalesce 不 Shuffle，repartition 会 Shuffle）
df.coalesce(20).write.parquet(...)        # 知道大概要几个文件时用它
df.repartition(20, "dt").write.parquet(...)  # 需要按列重新分区时用它

# 根治：开启 AQE 的 Shuffle 分区自动合并，从源头减少小文件
spark.conf.set("spark.sql.adaptive.coalescePartitions.enabled", "true")

5.4 一张排障决策图

任务慢了/挂了，按这个顺序查：

flowchart TD
    Q1{"任务挂了还是慢？"}
    Q1 -->|挂了| Q2{"Driver 日志里<br/>OOM 关键字？"}
    Q2 -->|Executor 端| F1["加 executor-memory<br/>或增大分区数"]
    Q2 -->|Driver 端| F2["查 collect/toPandas<br/>换成 write 或 take"]
    Q2 -->|文件不存在等| F3["懒执行报错错位<br/>从执行计划往上找源头"]
    Q1 -->|慢| Q3{"Spark UI 看 Stage：<br/>个别 Task 特别慢？"}
    Q3 -->|是 Max远大于Median| F4["数据倾斜<br/>过滤脏key/加盐/AQE"]
    Q3 -->|否 全都慢| Q4{"Shuffle Read/Write<br/>数据量巨大？"}
    Q4 -->|是| F5["能广播的小表广播<br/>列裁剪 过滤下推<br/>提前聚合减少数据量"]
    Q4 -->|否| F6["查上游：小文件太多？<br/>查集群：资源不够排队？"]

第六篇 AI 时代：少写代码，完成大数据开发

时间快进到 AI 编程工具普及之后。回头看，Spark 开发是最适合被 AI 改造的领域之一，因为它的代码模式极其规整：读、变换、聚合、写，套路就那么多。

6.1 AI 能替你做什么，不能替你做什么

flowchart LR
    subgraph AI擅长["AI 做得比人好"]
        A1["自然语言 → PySpark/SQL 代码<br/>按用户30天行为算RFM特征 一句话出码"]
        A2["样板代码生成<br/>Schema 定义 造数脚本 单元测试"]
        A3["报错诊断<br/>贴堆栈 直接定位到懒执行错位/倾斜"]
        A4["口径文档化<br/>把代码翻译成业务能看懂的白话"]
    end
    subgraph AI不擅长["人必须自己把关"]
        B1["业务口径<br/>漏斗是严格顺序还是存在性<br/>AI 不知道你老板要什么"]
        B2["性能直觉<br/>哪里该广播 哪里会倾斜<br/>要看真实数据分布"]
        B3["生产决策<br/>资源参数 重跑策略 数据回补"]
    end

我的实际工作流变化：

以前：写「用户漏斗分析」= 查文档 30 分钟 + 写代码 40 分钟 + 调试 30 分钟。
现在：给 AI 描述清楚——表名、字段、漏斗定义（严格按时间顺序）、输出格式——10 秒出代码，我花 20 分钟 review 口径和边界条件。总耗时砍到三分之一。

但注意：省下来的时间全部应该砸在口径确认和数据校验上。AI 写的代码语法几乎不会错，但它不知道你们的 user_id = '-1' 是脏数据、不知道运营要的是存在性漏斗。这正是第五篇那些坑的价值——AI 时代，踩坑经验不是贬值了，而是成了你最贵的资产，因为代码人人都能生成，能判断代码对不对的人变稀缺了。

6.2 具体怎么干：三个提效姿势

姿势一：需求描述模板化。 给 AI 下指令时固定四段式：

背景：表 ods.user_events，字段 user_id/event_type/ts，按天分区 dt
任务：计算 2022-10-25 的转化漏斗 曝光→点击→加购→下单→支付
口径：严格顺序漏斗，后一步的最早时间必须大于前一步
输出：一行五列，列名用中文

第四篇场景三的完整代码，用这样的提示词一次就能生成得八九不离十。

姿势二：报错即提示词。 Spark 报错堆栈又长又唬人，直接整段贴给 AI，附上你的 Transformation 代码，它对「懒执行错位」「ClassNotFound（依赖没打包）」「分区越界」这类经典错误的诊断准确率很高。

姿势三：让 AI 写测试和校验脚本。 大数据开发最缺的就是测试——数据对不对以前靠人肉抽查。现在让 AI 顺手生成校验 SQL（行数对比、NULL 比例、金额总和与上游对账），质量反而比手工时代更好了。

6.3 冷静的一句话

AI 不会让你"少学 Spark"，它让学习曲线的重心变了：以前背 API 占 60% 的时间，现在这部分 AI 补上了；剩下 40%——架构直觉、业务口径、排障经验——变成了 100% 的核心竞争力。入门变容易了，精通的标准反而更高了。

思考与感悟

写完这篇文章，有几句话想单独说：

1. 学 Spark 的本质是学"分布式的世界观"。 单机时代的直觉——数据随手可得、循环遍历随意、内存无限——全都要扔掉。你要习惯一种新的思维方式：数据是流动的、分区是平行的、Shuffle 是昂贵的、失败是必然的（所以容错设计是一等公民）。这套世界观建立起来之后，学 Flink、学 Kafka、学 ClickHouse 都会很快，因为它们要解决的是同一族问题。

2. 调优经验 = 疼痛的记忆。 没有人看文档能学会处理数据倾斜，都是被凌晨两点的报警电话教会的。所以别怕踩坑，踩了记下来——我这篇第五篇的每个坑，当年都值一个通宵。

3. 离业务近一点，离技术远一点。 做了几年大数据，最大的感悟是：把 ETL 跑得快不算本事，知道这张表给谁用、口径对不对、错了谁会亏钱才是本事。电商场景里，GMV 算错 1% 可能就是一个部门的年终奖。技术只是手段，数据是业务的镜像。

4. AI 时代最值得押注的能力是"判断力"。 生成代码会越来越便宜，判断"这段代码对不对、这个口径该不该这么定、这个架构扛不扛得住双十一"会越来越贵。把 AI 当成一个能力极强但没有常识的实习生：活让它干，锅你来背，所以你必须看得懂它干的活。

与君共勉。

大数据 on 方糖猫Blog

Spark 与 Flink 入门：批与流的两种血统，视频公司里各干什么活

Spark 与 Flink 入门：批与流的两种血统，视频公司里各干什么活

Spark 基础：批处理血统的内存计算引擎

Flink 基础：流处理血统的计算引擎

血统对比：一张表

视频公司里各干什么活

算力规格：硬件怎么配

监控：两套引擎各看什么

故障与恢复：出事时的标准动作

Kafka + Flink 组合：失败后到底会不会重复、会不会丢

多节点会不会重复消费同一个分区：消费组的互斥语义

数据源不止 Kafka：还能从哪读，API 数据怎么办

Spark 避坑指南

Flink 避坑指南

选型决策

Spark 从入门到精通：架构原理、RDD/DataFrame、调优踩坑与电商实战全指南

Spark 从入门到精通：架构原理、RDD/DataFrame、调优踩坑与电商实战全指南

第一篇 为什么是 Spark：一台机器装不下的时代

1.1 一个电商场景把问题引出来

1.2 Spark 在生态里的位置

第二篇 架构与原理：代码提交之后到底发生了什么

2.1 一次 Spark 任务的全貌

2.2 懒执行（Lazy Evaluation）：为什么你的代码"没报错"却在运行时炸了

2.3 Stage 是怎么切出来的：宽依赖与窄依赖

第三篇 RDD 与 DataFrame：两代 API 的分水岭

3.1 RDD：能看清每个零件，但要自己造发动机

3.2 DataFrame：你只说"要什么"，优化器替你想"怎么做"

3.3 本地就能跑的完整 Demo

第四篇 电商实战：把知识串成业务

4.1 场景一：订单宽表（每日 ETL）

4.2 场景二：用户行为漏斗（转化率分析）

4.3 场景三：推荐特征工程（用户画像）

第五篇 调优与踩坑：生产环境才是真的战场

5.1 天坑一：数据倾斜（一个 Task 跑三小时，其他三分钟）

5.2 天坑二：OOM（内存不够，但到底谁不够）

5.3 天坑三：小文件灾难（HDFS 的慢性病）

5.4 一张排障决策图

第六篇 AI 时代：少写代码，完成大数据开发

6.1 AI 能替你做什么，不能替你做什么

6.2 具体怎么干：三个提效姿势

6.3 冷静的一句话

思考与感悟

第一篇为什么是 Spark：一台机器装不下的时代

第二篇架构与原理：代码提交之后到底发生了什么

第四篇电商实战：把知识串成业务

第五篇调优与踩坑：生产环境才是真的战场