流处理 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 场景参考其技术博客公开的数据平台架构。

三万个 Flink 作业怎么自动扩缩容：Netflix 两代 Autoscaler 的教训

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

三万个 Flink 作业怎么自动扩缩容：Netflix 两代 Autoscaler 的教训

目标读者：三类人——

平台/数据工程师：正在或准备给 Flink 作业做自动扩缩容，想知道选哪个方案、坑在哪（看"背景二"和"三个工程缺口"）；

架构师：在给实时计算平台做选型，需要"外部指标 vs 内部推理"两条路线的完整对比（看两代方案的对比表）；

CTO/技术管理者：关心自研和开源的边界，Netflix 从自建收敛到开源的过程是一个现成的决策样本（看"三条可以带走的教训"）。

没跑过 Flink 也能读：正文前两节是背景知识；跑过的可以直接跳到"第一代"开始看。

之前那篇《软件知识的分层与获取地图》说过：方案层的知识没有教材，只有案例，大厂技术博客是主力来源。最近去读了 Netflix 技术博客的 A Tale of Two Flink Autoscalers，讲的是他们怎么做流处理作业的自动扩缩容。这篇是我的学习笔记，把里面的架构知识点整理出来。

问题的形状很普遍：作业负载随昼夜、活动、故障转移大幅波动，按峰值配资源浪费，按均值配资源高峰期 lag 爆炸。Netflix 的答案是先后造了两代 autoscaler，现在正在从自研收敛到开源。两代的设计差异和迁移教训，比算法本身更有价值。

不过进入正题前，先补两段背景：Flink 是什么、扩缩容在这上面为什么天然就贵；以及开源社区现在有哪些现成方案、谁更好。

背景一：Flink 是什么，扩缩容为什么贵

Apache Flink 是开源的流处理框架，核心能力是"对无界数据流做有状态计算"：数据像水管里的水一样源源不断地来（Kafka 消息、日志、点击流），Flink 一边流一边算，算出实时结果（实时报表、实时推荐、风控告警）。

一个 Flink 作业（job）在逻辑上是一张算子组成的有向无环图（DAG）：数据从 source 进来，经过 map、keyBy、window、join 这些算子的处理，最后写到 sink。

flowchart LR
    A["source<br/>读 Kafka"] --> B["map / filter<br/>转换清洗"]
    B --> C["keyBy + window<br/>分组聚合 带状态"]
    C --> D["sink<br/>写下游"]

要理解扩缩容为什么难，需要知道四个机制：

并行度（parallelism）：每个算子可以拆成多个并行实例（叫 subtask），分摊在集群的 TaskManager 进程里跑。所谓"扩缩容"，本质就是调整各算子的并行度、增减 TaskManager。
状态（state）：keyBy 之后的窗口、聚合结果都存在状态里，大作业的状态可以到 TB 级。状态按 key 分布在各个并行实例上。
checkpoint / savepoint：Flink 定期把状态整体快照下来，用于故障恢复。改并行度意味着状态要在新数量的实例间重新分配——所以扩缩容的标准动作是"做 savepoint → 停作业 → 按新并行度重启 → 重新加载状态"，状态越大恢复越慢。
背压（backpressure）：下游算子处理不过来，会沿着数据流反向"顶住"上游。背压是判断"瓶颈在哪个算子"的关键信号，也是第二代 autoscaler 的数据基础。

一句话：无状态服务扩缩容是加台机器的事；有状态流处理扩缩容是一次"带着全部家当搬家"。这就是为什么"自动扩缩容"在无状态微服务上早就普及，在 Flink 上却直到这两年才有成熟方案。

背景二：开源社区有什么方案，谁更好

给流处理作业做自动扩缩容，社区里前后出现过几条路线：

方案	原理	粒度	现状
Flink Reactive Mode（1.13 起）	作业自适应集群里现有的 TaskManager 数量，配合 K8s HPA 按 CPU 伸缩容器	整个作业一刀切	简单可用，但按容器指标决策，看不见作业内部瓶颈
Apache Flink Autoscaler（Flink Kubernetes Operator 内置）	从作业内部逐算子算"真实处理速率"，按需逐顶点调并行度	逐算子	社区主力方向，本文的主角
云厂商托管服务（如 AWS Managed Service for Apache Flink）	平台按容器利用率自动伸缩	整个作业一刀切	零运维但粒度粗，复杂有状态作业效果有限
各家自研（Netflix 第一代、当年 Twitter Heron 的 Dhalion 等）	外部指标（CPU、lag、背压）+ 自研策略	整个作业一刀切	大多是"社区没有成熟方案时"的历史产物

谁更好？对 2026 年刚开始做这件事的团队，答案基本收敛了：

作业跑在 K8s 上 → 直接用 Flink Kubernetes Operator 自带的 autoscaler，顶点级、背压感知，是当前最通用的最优解；
平台是自建的（不在 K8s 上、有自己的控制面）→ 核心算法库已经独立出来，可以像 Netflix 一样只接四个接口（下文详述），不必自建；
作业简单、无状态、量不大 → Reactive Mode 或云托管的粗粒度伸缩就够用，别上重武器；
从零自研外部指标 autoscaler → 2019 年的合理选择，2026 年不太成立——Netflix 自己正在从这条路迁走，这就是用脚投票。

有了这个背景，Netflix 这两代方案的故事就好读了：它几乎把上面每条路线都趟了一遍。

为什么这个问题在 Netflix 躲不掉

先看规模：2026 年，Netflix 在多个 AWS 区域跑着 3 万多个 Flink 作业（2017 年开始用 Flink）。这决定了"人肉运维"这条路根本不存在。

这三万个作业到底在干什么业务？按原文的分类可以拆成两大块：

大头是托管平台 Data Mesh 自动生成的数据管道——所以这三万个作业的主体确实是"大数据相关"，不是在跑在线业务服务。Data Mesh 是 Netflix 的托管数据搬运/处理平台（2023 年他们在博客公开过架构）：用户在界面上声明"数据从哪来、到哪去、中间做什么转换"，平台自动生成 Flink 作业——典型场景是 Kafka 之间的数据搬运、数据库变更（CDC）实时同步到数仓（Iceberg）、事件路由分发。用户大多根本不直接接触 Flink，自然也不会去管扩缩容。
少数但增长快的是各团队自建自运维的自定义作业，承载真正的实时业务逻辑：个性化（实时推荐特征计算）、广告（2022 年广告套餐上线后的曝光与计费遥测）、直播活动（体育赛事直播的实时监控）等。原文里靠 autoscaler 省下 110 万美元的案例，就来自做客户端遥测和日志的团队。

形态差异也很大：从 Kafka 搬运工式的单算子作业，到带分支、join、TB 级状态的复杂流水线都有——记住这个差异，后面两代 autoscaler 的能力边界正好卡在这里。

顺带澄清一个容易误解的点：首页千人千面的推荐，不是每个用户打开时都走一遍 Flink。Flink 是流处理引擎，干的是"事件来了就算"，不在用户请求链路上。个性化系统是经典的三层结构（Netflix 早在 2013 年就公开过这套架构）：

flowchart LR
    A["离线 offline<br/>批量训练模型<br/>计算全量候选集"] --> D["在线存储<br/>画像 特征 候选集"]
    B["近线 nearline<br/>行为事件进 Kafka<br/>Flink 实时更新画像特征"] --> D
    D --> C["在线 online<br/>打开首页时排序组装<br/>几十毫秒返回"]

你在观看、暂停、评分时产生的行为事件，由近线层的 Flink 作业实时消化、更新画像；你打开首页那一瞬间，在线服务只做"查 + 排"，几十毫秒返回。把重计算从请求路径挪到事件流上，正是个性化系统扛住全球用户规模的关键设计——本文说的"个性化"自定义作业，干的就是近线这一层的活。

更麻烦的是约束条件：在这个平台上，扩缩容不是免费的。默认动作是"做 savepoint → 优雅停掉作业 → 按新规模重启"，大状态作业一次要几分钟。这意味着扩缩容策略不能冲动——每次动作都是分钟级的中断。

于是一个真正难的问题摆在面前：如何在没有人的情况下，让每个作业在需要时拿到需要的资源，同时不把任何东西搞挂？

第一代：从外面看的 autoscaler（2019）

Netflix 的第一个答案本身就是一条流处理作业：跑在自家 Mantis 平台上，消费遥测系统 Atlas 吐出的集群级实时指标——每个作业的 CPU、网络、Kafka lag、摄入速率、消费速率。

决策逻辑是几种信号的组合：lag 推导出的追赶时间、CPU/网络利用率阈值、历史性能基线、对近期摄入速率做回归预测，然后决定扩容，或者判断"更小的集群也扛得住未来窗口"从而缩容。

这个设计有两个当时看来很聪明、事后定义了天花板的选择：

它独立于 Flink 平台运行。Flink 自己出问题时扩缩容不受牵连；而且按"流处理作业"的形态来构建，天然好扩展——每个 autoscaler 节点负责一部分 Flink 作业的指标，从没写过什么分片协调逻辑。
成绩单不差：在几千个托管流水线上稳定砍下 25%-45% 的资源用量（Flink Forward 2020 分享过）。

但"从外面看"是有代价的，原文叫它 ceiling（天花板）：

粗粒度 + 单一旋钮。它通过容器级指标推理整个集群，而且只能调一个数——TaskManager 总数，也就是作业里所有算子同比例缩放。对单算子简单流水线够用，对多算子、有状态的 DAG（广告、推荐、游戏团队越来越多拿来的正是这种）就无能为力——而这恰恰是它推理不了的作业类型。每接一种新 case 就得加定制逻辑，形不成通用能力。
指标会骗你。autoscaler 的天花板就是外部指标系统的天花板。有的作业明明忙得团团转，CPU 利用率上却毫无体现，作业卡在降级状态里，scaler 根本看不见。更狠的一次：一次网络迁移悄悄改变了部分流量的上报口径，Atlas 里 scaler 依赖的一组指标开始漏报——这个缺口在生产环境潜伏了很久才暴露。

到这一步，build vs buy 被重新摆上了桌面。

第二代：从里面推理的 autoscaler（开源方案）

2019 年自建时，Flink 社区没有成熟的 autoscaler；等 Netflix 重新评估时，已经有了：Apache Flink Autoscaler。思路发生了根本变化——不从外面看容器，从作业内部推理。

核心概念是真实处理速率（TPR, True Processing Rate）：一个算子如果满负荷运转，能扛住的吞吐是多少。

Flink 会按 subtask 上报"每秒真正干活的时间占比"（和背压时间、空闲时间分开统计）。用观测吞吐除以忙碌占比，就能把容量外推到满负荷：

一个算子实测每秒处理 700 条记录、忙碌占比 70%，TPR = 700 / 0.7 = 1000 条/秒。

有了这个数，autoscaler 从 source 开始遍历整个作业 DAG，结合每个算子的 TPR、输入输出比率和目标利用率，逐顶点计算需要的并行度——保证没有任何一个算子成为瓶颈，而不是把整个集群当整体伸缩。

flowchart TD
    A["Flink 上报<br/>每个 subtask 的忙碌占比"] --> B["TPR = 观测吞吐 / 忙碌占比<br/>外推满负荷容量"]
    B --> C["从 source 遍历作业 DAG<br/>结合输入输出比率"]
    C --> D["逐顶点计算目标并行度<br/>没有算子成为瓶颈"]

两代方案的契约差异：

维度	自研（外部观察）	开源（内部推理）
信号来源	容器级指标（Atlas）	作业内 per-vertex 指标
决策单元	整个集群一个旋钮	DAG 逐顶点并行度
适用作业	单算子简单流水线	多算子有状态 DAG
配置粒度	全局统一	每个作业可自定义

对 Netflix 来说，决定性的就是后两行：开源方案能扩缩的恰好是自研系统天生处理不了的那类作业，而且每个作业可以带自己的配置（稳定期、阈值等扩缩行为参数）——这正是那些一直被人工扩缩容的自定义作业需要的。

落到三万个作业：三个工程缺口

算法层面拿来即用，社区已经把难的部分做完了。Netflix 的工作是让它在自己的体系里可靠运转——这才是"社区能跑"和"Netflix 规模能跑"之间的距离。

接入方式：独立库 + 四个接口。 开源 autoscaler 最初架构在 Flink Kubernetes Operator 里，而 Netflix 的 Flink 平台跑在自己的控制面上。社区后来做了一个关键决策：把核心逻辑抽成独立库，只留四个通用接口——携带作业元数据和 REST 信息的 context、状态存储、事件处理器、执行扩缩动作的 realizer。Netflix 的接入服务是一个 Spring Boot 应用，编排跑在 Temporal（持久化工作流引擎）上：一个编排工作流每分钟轮询一次控制面，为每个开启扩缩容的作业启动一个独立的长运行工作流。

flowchart LR
    A["Temporal 编排工作流<br/>每分钟轮询控制面"] --> B["每个作业一个<br/>独立长运行工作流"]
    B --> C["从 JobManager 拉<br/>per-vertex 指标"]
    C --> D["跑开源评估算法"]
    D --> E["realizer 通过控制面<br/>执行扩缩"]

“每个作业一个工作流"是直接被 pain 教育出来的设计：最初用单一批处理循环评估所有作业，一个慢作业或异常作业能卡住它后面所有作业的指标采集和扩缩。拆开之后，单个作业出问题只在自己的工作流里失败重试，爆炸半径被隔离，接入更多作业时运行时水平扩展即可。

三个必须自己补的工程缺口：

高并行度下的指标采集。大作业上从 JobManager 拉指标成为瓶颈，部分原因在 Flink 运行时本身。Netflix 改了 JobManager：缓存瞬时指标名、统一清理而不是每次拉取都重扫，并加了服务端过滤让 autoscaler 只拉需要的指标。效果：可用规模从约 1000 个 subtask 提到 3000 个。这些改动在内部 fork 里，部分已贡献回上游（如 FLINK-36172）。
保住 forward chaining。由 forward 边连接的两个顶点必须同并行度——记录是在内存里走固定本地通道交接的。如果只扩一个，Flink 不会报错，它会悄悄把这条边转成网络 shuffle（性能完全另一回事）。Netflix 的 fork 会检测 forward 连接的子图，把它们当整体扩缩。
尊重 sink 的容量上限。有些 sink 写入能力有限，把上游作业扩上去只会把自己顶死。fork 里加了 async-sink 背压检测，阻止 autoscaler 把作业扩到 sink 吃不下。

最后还有 realizer 的安全检查：比如公司级区域故障转移期间，拒绝在被撤离的区域缩容；执行前确认新集群磁盘放得下作业的 checkpoint 状态；大集群再加一点 standby 缓冲。

效果与调校

开源方案的 autoscaler 去年在 Netflix 自定义作业上 GA，早期结果里有个硬数字：客户端遥测日志团队的 Flink 计算支出年化下降 58%，约省 110 万美元。效率来自三件事：

静态配置永远要按峰值留量，autoscaler 吃掉了昼夜和周末低谷；
性能优化或节后流量回落之后，不再依赖团队手工降配，autoscaler 持续跟进；
统一容器规格带来更好的装箱（bin-packing）和更细的扩缩粒度。

但"缩得太狠"是另一个坑：砍过头 CPU 打满、lag 飙升，而系统没法立刻反应——每次重启后指标窗口和稳定期都要重建。Netflix 现在把目标利用率定在 0.45，低于社区默认的 0.7，故意用一点效率换稳定：对大型有状态作业，更少、更平稳的扩缩动作值这个价。

剩下的最大成本已经不是 scaler 的逻辑，而是重启和状态恢复本身。Flink 2 的分离式状态架构（状态放外部存储而不是本地磁盘）有望让扩缩代价与状态大小解耦——Netflix 已开始支持 Flink 2.2，准备实验新 state backend。

三条可以带走的教训

文章结尾总结的三条，泛化到 Flink 之外依然成立：

指标选择比算法精巧更重要。 最有价值的调试很少是关于扩缩数学的，而是"该信哪个信号”。调算法之前，先搞懂你的指标——口径会变、会漏报、会测不到真正的瓶颈（第一代 scaler 的两次事故都是指标层的）。
默认值要合理，但留出调节空间。 托管作业相似度够高，一套好默认值覆盖大多数——这正是平台的意义。但把单一配置强加给所有作业，是在惩罚不适配的那些：默认值 + 每作业覆盖，同时把需要深专业知识的旋钮藏起来。大多数团队永远不该需要思考 autoscaler 的存在。
先采用，再扩展（Adopt, then extend）。 2019 年自建是因为没有成熟选项；社区方案出现后，正确的动作既不是永远捍卫自己的投资，也不是连夜拆掉，而是：新工作负载先用开源的，把修复贡献回上游，再有计划地迁移存量。自研基础设施的真实成本，要在"本来可以采用现成方案"的对照下衡量。

一句话收拢：自动扩缩容的难点从来不在"扩缩"二字，而在于你凭什么相信指标、怎么隔离故障、以及什么时候承认社区已经做得比你好了。

来源：Samuel Yeboah, Francesco Di Chiara, Mingliang Liu, “A Tale of Two Flink Autoscalers”, Netflix TechBlog。

《设计数据密集型应用》学习总结：存量、流量、回路——每个设计决策都是三者的权衡

Tue, 08 Aug 2023 10:40:00 +0800

《设计数据密集型应用》学习总结：存量、流量、回路——每个设计决策都是三者的权衡

目标读者：写过 CRUD、用过 MySQL/Redis/Kafka，但说不清它们"为什么这么设计"的工程师。
参考书籍：Martin Kleppmann《Designing Data-Intensive Applications》（DDIA，那只野猪书）
阅读目标：不背目录，而是拿到一个能套在任何存储/中间件上的分析框架——存量、流量、回路。

0. 写在前面：别背组件，背权衡

市面上的"中间件教程"有个通病：教你 MySQL 怎么用、Redis 怎么用、Kafka 怎么用，但从不告诉你为什么它们长得这么不一样。同样是存数据，Redis 敢把数据放内存，MySQL 不敢；同样是日志，Kafka 能当数据库用，而大多数人只拿它当管道。

DDIA 这本书最值钱的地方，就是把这些"为什么"串成了一条线。读完我把它提炼成三个词：

存量（State）：数据怎么存——存储引擎（LSM/B-Tree）、编码格式、行存列存。
流量（Flow）：数据怎么动——复制、分区、派生数据、流处理。
回路（Loop）：系统怎么自我纠错——事务、隔离级别、共识、线性一致性。

一句话理解：任何一个数据系统的设计决策，都是在存量成本、流量吞吐、回路强度三者之间做取舍。 你要强一致（回路强），就得牺牲可用性或延迟（流量贵）；你要写入快（流量大），就得接受读时合并或后台压缩的代价（存量结构变复杂）。

避坑指南 0：读完这本书最大的误区是"上来就选最强的一致性"。Kleppmann 自己说过大意如此的话：一致性模型的选择应该由业务能不能容忍异常决定，而不是由工程师的洁癖决定。能容忍就用最终一致，性能白捡。

和博客已有的 Redis/MySQL/MQ 笔记是"原理 vs 用法"的关系：那些笔记讲"这个命令怎么用、这个参数怎么调"，这篇讲"这个组件为什么被设计成这样"。建议搭配阅读——看完这篇再回头看 Redis 的 RDB/AOF、MySQL 的 InnoDB redo log、Kafka 的副本协议，会有"原来如此"的感觉。

第一部分存量：数据怎么存

1. LSM-Tree vs B-Tree：写的快和读的快，不可兼得

数据库索引结构就两大流派，区别一句话：

B-Tree：读的时候顺藤摸瓜，树的高度就是磁盘寻道次数。写入是"就地更新"——找到那一页，改掉。MySQL InnoDB 就是这个。
LSM-Tree：写入只往内存里的有序结构（Memtable）追加，内存写满了就整体刷到磁盘变成一个 SSTable（Sorted String Table，一段有序的文件）。读取时从最新的 SSTable 往最旧的依次找。LevelDB、RocksDB、Cassandra、HBase 都是这个。

SSTable 合并（compaction）是 LSM 的灵魂。因为同一个 key 的新旧版本散落在多个 SSTable 里，后台必须定期把它们归并排序、去重、丢掉被删除的墓碑标记，否则文件越积越多，读放大失控。

flowchart TD
    W["写入请求"] --> L["WAL 追加日志<br/>（崩溃恢复用）"]
    L --> M["Memtable<br/>（内存有序表）"]
    M -->|"写满阈值"| S1["SSTable 1<br/>（不可变文件）"]
    M -->|"再写满"| S2["SSTable 2"]
    M -->|"又写满"| S3["SSTable 3"]
    S1 --> C["后台 Compaction<br/>归并排序 + 去重 + 清墓碑"]
    S2 --> C
    S3 --> C
    C --> S4["合并后的大 SSTable<br/>（旧文件丢弃）"]
    R["读取请求"] --> M
    R --> S3
    R --> S2
    R --> S1
    R -->|"配合布隆过滤器<br/>跳过不含该 key 的文件"| MISS["快速判不存在"]

小数字例子感受写放大：假设每写 1 GB 数据，经过 3 层 compaction，每层都要重写一遍，实际磁盘写入可能是 5~10 GB。这就是"写放大"，也是 RocksDB 调优的核心战场。

LSM 读取慢怎么补救？靠布隆过滤器（Bloom filter）：一个很小的内存位图，能告诉你"这个 key 肯定不在这个 SSTable 里"（可能有误报，但绝不漏报）。查一个不存在的 key 时，布隆过滤器直接拦掉，不用真的去翻磁盘文件——这对"查缓存未命中再查库"的场景是救命优化。Cassandra、HBase、RocksDB 全都内置。

怎么选？ 记住这张对照表：

维度	B-Tree	LSM-Tree
写入	就地更新，写放大相对低但随机 IO	顺序追加，吞吐高但有 compaction 写放大
读取	稳定，一次查找几层树	要查多层文件，靠布隆过滤器和缓存补救
磁盘碎片	页分裂会产生碎片	文件整体重写，天然紧凑
典型代表	InnoDB、PostgreSQL	RocksDB、Cassandra、HBase

一句话理解：B-Tree 是"图书馆书架"，书按位置摆好，找书快、插书要挪位置；LSM 是"先记在便签上，攒一批再上架"，记便签飞快，但定期要整理书架，找书得翻几摞便签。

2. WAL：所有存储引擎的"保命符"

LSM 写 Memtable、B-Tree 改数据页，都是先动内存。断电怎么办？答案是 WAL（Write-Ahead Log，预写日志）：任何修改先追加一条日志到磁盘，再改内存结构。崩溃后重放日志恢复。

这个思想无处不在：

InnoDB 的 redo log 是 WAL；
PostgreSQL 的 WAL 直接就叫 WAL；
Redis 的 AOF 本质也是 WAL；
Kafka 的消息日志、ZooKeeper 的事务日志，全是同一个套路。

一句话理解：WAL 就是把"随机写"变成"顺序写"——磁盘顺序追加比随机写快几个数量级，顺便白捡了崩溃恢复能力。

3. 行存 vs 列存：OLTP 与 OLAP 的分水岭

行存：一行的所有列连续存放。适合"查一个人的全部信息"（点查、事务），即 OLTP。
列存：一列的所有值连续存放。适合"统计一百万人的平均年龄"（聚合、分析），即 OLAP。

为什么列存分析快？小数字例子：一张 100 列的表，分析查询只用 5 列。行存要把 100 列全部从磁盘读出来再丢弃 95 列；列存只读那 5 列，IO 直接省 95%。而且单列数据类型相同，压缩率极高（比如"性别"列去重后就两个值，位图编码一下几乎不占空间）。

代表：Parquet、ORC、ClickHouse、DuckDB 是列存；MySQL、PostgreSQL 是行存。Snowflake、BigQuery 这类数仓全部站在列存一边。

4. 编码与演进： schema 变了，老数据怎么办

存量还有个隐藏维度：数据格式会随时间演化。JSON 灵活但没约束；Protocol Buffers / Thrift / Avro 这类二进制编码通过字段编号实现前后兼容——新增字段给新编号，删掉字段不动旧编号，新老代码就能和平共处。

避坑指南 1：滚动升级时"新代码读老数据"和"老代码读新数据"会同时发生。所以兼容性必须是双向的：向后兼容（新读老）+ 向前兼容（老读新）。只考虑一个方向，升级到一半必出事。

第二部分流量：数据怎么动

单台机器存不下、扛不住、会宕机——这是"流量篇"要解决的三个问题。对应三板斧：复制（同一份数据放多台机器）、分区（不同数据放不同机器）、派生数据（数据从一个系统流向另一个系统）。

5. 复制：主从、多主、无主，三种政治体制

复制的目标是可用性和读扩展，但引入了全书最核心的矛盾：副本之间怎么保持一致。

主从复制（单主）：所有写请求走 Leader，Leader 把变更日志同步给 Follower。读可以分摊到 Follower。简单、直觉，MySQL、PostgreSQL、MongoDB（副本集）、Kafka 分区副本都是这个思路。

但"Follower 的数据是旧版本"这件事，会带来一连串用户可感知的诡异现象：

你刚发的朋友圈自己刷新后消失了 → 需要读己之写（read-your-writes）：用户写完之后，读请求必须走 Leader 或带版本号校验。
你的余额从 100 变成 80 又变回 100（读到了更旧的副本）→ 需要单调读（monotonic reads）：一个用户的连续读请求固定打到同一个副本。
聊天里先看到回复再看到原帖（分区的数据流向不同副本速度不同）→ 需要一致前缀读（consistent prefix reads）：有因果关系的写入，任何读者都应该按相同顺序看到。

sequenceDiagram
    participant C as 客户端
    participant L as Leader（主库）
    participant F1 as Follower 1（同步副本）
    participant F2 as Follower 2（异步副本）

    C->>L: 写 x = 1
    L->>L: 写本地 WAL 并提交
    L->>F1: 同步复制：等 F1 确认
    F1-->>L: ACK
    L-->>C: 写入成功
    L->>F2: 异步复制：后台慢慢发
    Note over F2: 此时 F2 还是旧值 x = 0<br/>复制延迟窗口
    C->>F2: 读 x
    F2-->>C: x = 0（读到旧数据！）
    Note over C,F2: 这就是"读己之写"被破坏的瞬间

同步 vs 异步是个硬权衡：全同步，任何一个副本宕机写入就卡死；全异步，Leader 宕机时没同步完的写入直接丢失。实践中的折中是"半同步"——一个副本同步、其余异步（MySQL 的 semi-sync 就是这个）。

多主复制：多个节点都能接受写，彼此同步。适合多数据中心就近写入，但写冲突是噩梦——两个机房同时改同一条数据，谁说了算？常见解法：LWW（最后写入者胜，靠时间戳，会丢数据）、CRDT（无冲突数据结构）、应用层解决。CouchDB 走这条路。

无主复制（Dynamo 风格）：没有 Leader，写入时客户端把数据发给 N 个副本中的任意 W 个，读的时候从 R 个里读，只要 W + R > N 就能保证读到最新值（法定人数，quorum）。经典参数 N=3, W=2, R=2。

经典案例：Amazon Dynamo 论文与购物车。2007 年 Amazon 发表 Dynamo 论文，动机极其务实：购物车绝不能拒绝写入——用户加购物车被拒，就是真金白银的损失。所以 Dynamo 选择永远可写（AP），哪怕网络分区时也接受写入，事后再合并冲突版本（著名的"向量时钟"就出自这篇论文）。这篇论文直接催生了 Riak、Cassandra、Voldemort 一整代 NoSQL。

一句话理解：单主是"独裁"，多主是"联邦"，无主是"全民投票"。越民主写入越自由，但事后摆平分歧的成本越高。

6. 分区：数据切蛋糕的两种刀法

单机存不下就分区（分片）。两种切法：

按 key 范围分区：字典式切分，A~~M 一个分区、N~~Z 一个分区。范围查询（“查 7 月的所有订单”）天然高效，但热点问题明显——如果 key 是时间戳，所有新写入全砸在最后一个分区上。Bigtable、HBase 用这套。

按键的哈希分区：key 过一遍哈希函数打散。负载均匀，但范围查询要 scatter-gather 到所有分区，效率骤降。Cassandra、DynamoDB 用这套（Cassandra 实际上是"哈希定分区 + 分区内按 key 排序"的混合体）。

再平衡（rebalancing） 是分区系统真正的试金石：加机器、减机器、某分区过热，数据都要搬家。要求搬家期间读写不停、搬迁量最小。

flowchart LR
    subgraph 扩容前["扩容前：3 节点，每节点 4 个虚拟分区"]
        N1["节点 A<br/>v0 v1 v2 v3"]
        N2["节点 B<br/>v4 v5 v6 v7"]
        N3["节点 C<br/>v8 v9 v10 v11"]
    end
    subgraph 扩容后["扩容后：新节点 D 加入<br/>只搬走 3 个虚拟分区，其余不动"]
        N1b["节点 A<br/>v0 v1 v2"]
        N2b["节点 B<br/>v4 v5 v6"]
        N3b["节点 C<br/>v8 v9 v10"]
        N4["节点 D<br/>v3 v7 v11<br/>（从 A/B/C 各搬一个）"]
    end
    扩容前 -->|"固定数量虚拟分区策略<br/>只迁移少量 vNode"| 扩容后

主流策略就是图里这个：固定数量的虚拟分区（vNode）——分区数远多于节点数，加节点时从每个老节点"匀"几个虚拟分区过来。Riak、Cassandra 都这么干。反例是取模哈希（hash mod N）：节点数一变，几乎全部 key 都要搬家，这就是一致性哈希要解决的原始问题。

避坑指南 2：分区键一旦选定，几乎不可更改。用 user_id 做分区键的系统，后来想做"按时间范围全局扫描"，会发现每个查询都要打满全部分区。选分区键时想清楚：你的主要查询模式是什么，热点在哪。

7. 派生数据：一个数据系统的输出，是另一个系统的输入

Kleppmann 有个非常锋利的视角：缓存、搜索索引、数据仓库，本质上都是派生数据——它们都是从某个"真相源"（source of truth）加工出来的冗余副本。

一旦接受这个设定，很多架构问题豁然开朗：

缓存和数据库不一致？因为派生数据没有和源数据同步更新。
ES 里的搜索结果和 MySQL 对不上？同理。
数仓报表延迟一天？因为派生管道是 T+1 的批处理。

于是问题从"怎么让缓存不失效"变成"派生管道怎么设计"，这正是流处理要回答的，下文第 10 节展开。

第三部分回路：系统怎么自我纠错

存量和流量解决了"存得下、流得动"，剩下的问题是：当多个客户端并发操作、机器会宕机、网络会分区时，系统凭什么保证数据不出错？ 这就是回路——一致性保障与反馈机制。

8. 事务与隔离级别：用"弱隔离"换性能，代价是异常

事务（ACID）是数据库给程序员的最大善意：把一堆操作打包成原子单元，要么全成要么全不成，并发的麻烦我来扛。但"我来扛"是有价格的——严格串行执行性能太差，于是数据库发明了隔离级别这个"滑杆"，让你自己选扛多少：

隔离级别	防住的异常	防不住的异常	谁在用
读未提交	几乎啥都不防	脏读、一切	基本没人用
读提交（RC）	脏读、脏写	不可重复读、写倾斜	Oracle、PostgreSQL 的默认
快照隔离（SI）	上面所有 + 不可重复读	写倾斜	PostgreSQL 的 RR、MySQL InnoDB 的 RR
串行化	一切	无	性能最好时的梦想

快照隔离（Snapshot Isolation） 值得单独说，因为它是现代数据库的主力。原理是 MVCC（多版本并发控制）：每次写入不覆盖旧值，而是生成新版本，每个事务看到"它开始那一刻"的数据快照。读不阻塞写、写不阻塞读，性能极佳。InnoDB 的 undo log、PostgreSQL 的多版本堆表，都是 MVCC 实现。

写倾斜（write skew）是快照隔离最大的盲区，也是面试和实战最容易踩的坑。小例子：医院排班系统要求"至少有一名医生值班"，当前有 Alice 和 Bob 两人值班。两人同时点"请假"：

Alice 的事务读到"2 人值班"，判断"我请假后还剩 1 人，OK"，提交；
Bob 的事务同样读到"2 人值班"（快照！他看不到 Alice 未提交的修改），同样判断 OK，提交；
结果：两人都不值班了，约束被破坏。

注意这不是脏读也不是不可重复读——每个事务内部看到的数据完全一致，但两个事务基于同一份过期前提做出了互相冲突的决定。解法只有：升级到串行化，或者用 SELECT ... FOR UPDATE 物化冲突（把隐含的读前提变成显式行锁）。

避坑指南 3：凡是有"读取一个约束条件，然后据此决定写入"模式的代码（库存扣减、名额抢占、余额校验），在 RR/快照隔离下都可能写倾斜。别指望 ORM 救你，老老实实 FOR UPDATE 或上串行化。

串行化的三条实现路线：

真的串行执行：单线程跑事务（Redis 单线程模型、VoltDB），简单暴力，内存够快时性能惊人；
两阶段锁（2PL）：读写都加锁，性能差但正确，MySQL 的串行化级别就是这么实现的，也是死锁的主要来源；
可串行化快照隔离（SSI）：快照隔离之上检测危险读写依赖，有冲突就中止重试。PostgreSQL 9.1+ 的串行化级别用的就是它，是近几十年事务领域最重要的学术成果落地。

9. 共识与线性一致性：分布式系统的"终极回路"

事务解决的是"单机/单系统内的并发正确性"，共识（consensus）解决的是更难的问题：一群会宕机、消息会延迟的机器，怎么对"某件事"达成一致。

先纠正一个常见混淆：

线性一致性（Linearizability）：让系统表现得"像只有一份数据"——任何人读到 x=1 之后，不可能再读到 x=0。它是对单个对象的读写一致性承诺。
共识（Consensus）：多个节点对某个值/某条决策达成不可逆的一致，典型算法 Paxos、Raft、Zab。

两者的关系：要实现线性一致的存储，背后几乎必然要靠共识算法选主或定序。ZooKeeper（Zab）、etcd（Raft）就是共识系统的工业代表，整个 Kubernetes 的正确性底座就是 etcd 里的那套 Raft。

经典案例：Google Spanner 与 TrueTime。Spanner 要在全球范围提供外部一致性（比线性一致更强，跨事务的全局顺序），最大的拦路虎是：分布式系统里各机器时钟不可靠，你没法靠时间戳判断两个事务谁先谁后。Google 的解法粗暴而硬核——给数据中心装 GPS 接收机和原子钟，把时钟误差压缩到一个已知的小区间（TrueTime API 返回的不是一个时间点，而是"真实时间必然落在的这个区间"）。提交事务时，如果发现误差区间还没过去，就故意等待（commit wait）直到确定。用硬件换确定性，用等待换正确性——这是"回路强度可以花钱买"的最著名示范。

FLP 不可能定理泼一盆冷水：在纯异步网络里，哪怕只有一台机器可能崩溃，也不存在确定性的、保证能终止的共识算法。工程上的出路是引入"部分同步"假设（网络总会恢复）和超时机制——所以 Raft/Paxos 的正确性不依赖时钟，但活性（liveness，能不能往前走）依赖。

极端案例：比特币与拜占庭容错。上面说的共识算法都假设节点"可能宕机但不会撒谎"（崩溃容错 CFT）。比特币面对的是更恶劣的环境：节点可能作恶（拜占庭将军问题）。中本聪的解法是放弃确定性共识，改用工作量证明（PoW）+ 最长链规则做概率性共识——一笔交易等 6 个区块确认，被推翻的概率指数级下降但永不为零。性能极差（比特币全网约 7 TPS，对比 Visa 峰值数万 TPS），换来的是"无许可环境下没人能篡改历史"。这是把回路强度推到极限、把流量吞吐牺牲殆尽的极端案例，也完美印证了我们的框架：一切都是权衡。

共识落地前，还有个更现实的问题：故障检测。分布式系统判断"某节点死了"的唯一办法是超时——但超时无法区分"节点真死了"和"节点只是 GC 停顿了 30 秒"（Java 应用的 Full GC、虚拟机的 steal time、网络拥塞都会造成这种"假死"）。于是就有了脑裂（split-brain）：老 Leader 以为自己还是 Leader，新 Leader 已经被选出来，两个"主"同时接受写入，数据互相覆盖。

工程解法是 fencing token（防护令牌）：每次选主，共识系统发一个单调递增的编号，存储层只接受"编号比上次大"的写入。老 Leader 拿着旧编号来写，直接被拒。这个小机制在 ZooKeeper（zxid）、etcd（revision）里都有对应物。

业界掌故：Kleppmann 本人就是分布式锁话题的"圈内名人"——2016 年他发文《How to do distributed locking》批判 Redis 的 Redlock 算法在时钟跳变和进程暂停下不安全，引来 Redis 作者 antirez 的公开反驳，两人来回论战了好几轮，成为分布式领域最著名的公开辩论之一。争论的核心正是上面这些：时钟不可信、暂停不可测，所以任何分布式锁要么上 fencing token，要么干脆用共识系统。

10. 批处理 vs 流处理：同一枚硬币的两面

最后回到流量，看数据处理的两种世界观：

批处理：数据是有界的——一堆文件摆在那，MapReduce/Spark 跑一遍，输出结果。优点是吞吐高、可重跑、容错简单（任务挂了重跑）；缺点是延迟以小时计。Hadoop/MapReduce 的黄金时代（Google 2004 年论文、Yahoo 孵化 Hadoop）就是这套世界观。
流处理：数据是无界的——事件源源不断地来，Kafka + Flink/Storm 逐条处理，延迟毫秒级。难点：乱序、恰好一次语义（exactly-once）、容错状态恢复。

Lambda 架构：流处理快但不准（可能丢、可能重复），批处理准但慢，那就两条都跑——流处理给实时近似结果，批处理定期用精确结果覆盖。维护两套系统、两份代码，运维成本翻倍，是出名的"说起来美、做起来痛"。

Kappa 架构：LinkedIn 的 Jay Kreps（Kafka 作者）提出的简化——只要流处理一条腿。历史数据重算？把 Kafka 的日志保留期拉长，让流处理程序从头重放一遍就行。这个架构能成立的前提，是 Kafka 把"消息队列"做成了"可重放的日志存储"。

flowchart TD
    subgraph 数据源
        DB[("业务数据库<br/>MySQL")]
        APP["应用事件"]
    end
    DB -->|"CDC 变更数据捕获<br/>（Debezium 监听 binlog）"| K["Kafka<br/>（可重放的日志存储）"]
    APP --> K
    K --> S["流处理引擎<br/>Flink / Kafka Streams"]
    S --> V1["派生视图：缓存 Redis"]
    S --> V2["派生视图：搜索索引 ES"]
    S --> V3["派生视图：数仓 ClickHouse"]
    K -->|"日志长期保留<br/>需要重算时从头重放"| S
    subgraph KP["Kappa / 批流一体"]
        S
    end

这张图里藏着 DDIA 全书最重要的思想之一：数据库和消息队列正在融合。Kafka 是可以当数据库用的日志（有保留期、可重放、有流处理）；反过来，数据库的 binlog/WAL 通过 CDC（Change Data Capture）技术流出来，就变成了消息流。Debezium 监听 MySQL binlog 把每一次行变更变成 Kafka 消息，是当下"派生数据管道"的标准做法。

经典案例：Kafka 从 LinkedIn 内部管道到行业标准。Kafka 诞生时（2010 年前后）只是 LinkedIn 内部的一个活动流（activity stream）和日志管道，目标是扛住"每个用户的每个页面浏览都要记录"的巨大流量。它的关键设计——把消息组织成分区有序日志、消费者自己维护 offset、依赖磁盘顺序写+page cache 而非内存——让它意外地发现：这个东西不只是消息队列，而是"以日志为中心的存储系统"。Confluent 成立后，Kafka 成了流处理事实标准，Kreps 那篇《The Log: What every software engineer should know about real-time data’s unifying abstraction》（2013）把"日志是数据系统统一抽象"的思想讲透了——和 DDIA 第 3 章"日志结构存储"一脉相承。

11. 全书串讲：用三个词复盘四个案例

现在用"存量、流量、回路"的框架，把本文案例快速过一遍，你会发现它们只是同一个框架的不同参数组合：

Kafka：存量用顺序日志（LSM 的近亲），流量靠分区+副本，回路选择"至少一次/恰好一次可配"的务实路线。→ 流量优先，回路可调。
Dynamo：无主复制+永远可写，回路是最终一致+应用层冲突解决。→ 流量（可用性）压倒一切，回路最弱。
Spanner：全球分区+同步复制，回路用 TrueTime 堆到最强（外部一致性）。→ 回路优先，花钱买。
比特币：回路要求拜占庭容错（最强敌对环境），代价是吞吐 7 TPS。→ 回路极限，流量牺牲殆尽。

没有银弹，只有取舍。 这就是 Kleppmann 反复想说、而无数"中间件选型指南"不会告诉你的事。

12. 带走的清单

读完 DDIA，做系统设计时问自己这几句话：

存量三问

写入多还是读取多？写多读少看 LSM（RocksDB/Cassandra），读多写少看 B-Tree（MySQL），分析查询上列存（ClickHouse/Parquet）。
崩溃恢复靠什么？找到那个 WAL——它一定存在，可能只是叫别的名字（redo log / AOF / binlog / journal）。
schema 演进支持双向兼容吗？向前向后都要，滚动升级时缺一不可。

流量三问

复制延迟用户能感知吗？能，就按需要补读己之写、单调读、一致前缀读，别等用户来报 bug。
分区键选对了吗？对照主要查询模式和热点，选错分区键≈架构重来。
缓存/索引/数仓是不是派生数据？是，就把"同步管道"当成一等公民来设计（CDC + 流处理），而不是事后打补丁。

回路三问

业务能容忍什么级别的一致性？能用最终一致就别上线性一致，省下的都是真金白银。
有没有"读约束再写入"的代码？有，检查写倾斜——FOR UPDATE 或串行化，二选一。
选主/分布式锁靠什么？别自己造轮子，ZooKeeper/etcd 这类共识系统才是正解（Redis 分布式锁的争议——Martin Kleppmann 本人就是那篇著名批判文章《How to do distributed locking》的作者，还设计了"马丁小花"fencing token 方案）。

最后的避坑清单

别把默认隔离级别当成"安全级别"——PostgreSQL/MySQL 的默认都不是串行化，写倾斜在看着你。
别迷信"分布式 = 高可用"——复制和分区引入的故障模式（脑裂、时钟漂移、复制滞后）比单机复杂一个数量级，Jepsen 测试报告（Kyle Kingsbury 对各大数据库的"虐测"）里全是血泪。
别在不了解权衡时引用 CAP——CAP 只说"网络分区时一致性和可用性二选一"，而网络不分区时你还有延迟与一致性的权衡（PACELC 才是完整版）。
时间不可信：进程会 GC 暂停、线程会被调度、时钟会跳变。所有依赖"本地时钟先后关系"的分布式逻辑都值得怀疑——这正是 Spanner 要装原子钟的原因。

13. 结语：野猪书为什么是神书

市面上讲分布式的书，要么讲理论（一堆证明，读完不会写代码），要么讲产品（一堆配置，换个组件就过时）。DDIA 恰好卡在中间：它讲的是"不会过时的权衡"。

LSM 和 B-Tree 的取舍，二十年前成立，二十年后还会成立；复制滞后引发的那些"诡异现象"，今天在 MySQL 从库上出现，明天就会在你的新数据库上换个马甲出现。工具会死，权衡永存。

顺带给个阅读路径建议：这本书 12 章不必按顺序啃——

日常写业务代码的：先读第 3 章（存储引擎）、第 7 章（事务），性价比最高；
做中间件/基础架构的：第 5、6 章（复制、分区）和第 9 章（共识）是主菜；
做数据平台/实时数仓的：第 10、11 章（批处理、流处理）直接对口；
第 8 章（分布式系统的麻烦）建议所有人都读，它是全书"劝退幻想"的一章，读完你会对时钟和网络产生健康的怀疑。

用一句话收尾，也是这本书给我最大的思维升级：

不要问"这个系统支持什么特性"，要问"这个系统在存量、流量、回路上各做了什么取舍，这些取舍和我的业务匹配吗"。

能问出这个问题，这本书就没白读。

流处理 on 方糖猫Blog

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

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

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

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

血统对比：一张表

视频公司里各干什么活

算力规格：硬件怎么配

监控：两套引擎各看什么

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

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

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

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

Spark 避坑指南

Flink 避坑指南

选型决策

三万个 Flink 作业怎么自动扩缩容：Netflix 两代 Autoscaler 的教训

三万个 Flink 作业怎么自动扩缩容：Netflix 两代 Autoscaler 的教训

背景一：Flink 是什么，扩缩容为什么贵

背景二：开源社区有什么方案，谁更好

为什么这个问题在 Netflix 躲不掉

第一代：从外面看的 autoscaler（2019）

第二代：从里面推理的 autoscaler（开源方案）

落到三万个作业：三个工程缺口

效果与调校

三条可以带走的教训

《设计数据密集型应用》学习总结：存量、流量、回路——每个设计决策都是三者的权衡

《设计数据密集型应用》学习总结：存量、流量、回路——每个设计决策都是三者的权衡

0. 写在前面：别背组件，背权衡

第一部分 存量：数据怎么存

1. LSM-Tree vs B-Tree：写的快和读的快，不可兼得

2. WAL：所有存储引擎的"保命符"

3. 行存 vs 列存：OLTP 与 OLAP 的分水岭

4. 编码与演进： schema 变了，老数据怎么办

第二部分 流量：数据怎么动

5. 复制：主从、多主、无主，三种政治体制

6. 分区：数据切蛋糕的两种刀法

7. 派生数据：一个数据系统的输出，是另一个系统的输入

第三部分 回路：系统怎么自我纠错

8. 事务与隔离级别：用"弱隔离"换性能，代价是异常

9. 共识与线性一致性：分布式系统的"终极回路"

10. 批处理 vs 流处理：同一枚硬币的两面

11. 全书串讲：用三个词复盘四个案例

12. 带走的清单

13. 结语：野猪书为什么是神书

第一部分存量：数据怎么存

第二部分流量：数据怎么动

第三部分回路：系统怎么自我纠错