流式处理框架用 checkpoint 记录两样东西：已提交的消费偏移量（offset）和有状态操作的中间状态。checkpoint 写在本地磁盘的话，进程重启能恢复，但节点挂了就没戏了。Spark 的做法是写到 HDFS、S3 等共享存储上；Kafka Streams 的做法是把状态变更写入 Kafka topic（changelog topic），靠 Kafka 的复制机制保证持久化。具体手段不同，但原则一样：状态恢复不能绑定在某一台机器上。

原文提到两次生产事故，一次是工程师把 checkpoint 目录当临时文件删了，一次是代码重构改了 query name 导致 checkpoint key 变化。两次都导致消费偏移量重置，需要从 Kafka 自身的 offset 存储中手工重建。都不致命，但都够折腾。不管用什么框架，搞清楚状态存在哪里、什么操作会重置状态，然后别碰它。

流式处理框架最终都要把数据写到下游存储。写得太频繁（比如每秒写一次），每次只攒了几条数据，产出大量小文件，下游查询和合并（compaction）压力大。写得太稀疏（比如攒 10 分钟再写），单次数据量大，处理时内存压力又上来了。

原文作者的经验法则是让每次写出的数据量落在 50-500MB 范围内。在 Spark Structured Streaming 里他用触发间隔控制这个节奏：制造业遥测管道用 30 秒触发，保险理赔管道用 2 分钟触发。其他框架的控制手段不同，但问题一样：得在延迟要求和下游存储效率之间找个平衡。

数据分片数和计算并行度是供需关系，哪边多了都是浪费。分片太少，计算资源吃不饱；分片太多，调度和上下文切换的开销反而拖慢处理。原文举的例子：Kafka 的每个分区在 Spark 中对应一个 task，如果 topic 有 200 个分区但集群只有 32 个核，200 个 task 在 32 个核上跑，上下文切换开销很大。反过来，如果下游处理比读取更吃 CPU，就得在读取后把数据重新分发到更多分区，让更多核参与计算——在 Spark 里是 repartition()，不过这会触发 shuffle，网络开销不小，只在确实需要时才用。

窗口聚合、流-流 join 这类有状态操作需要框架跨批次维护状态。不设水位线（watermark）的话，状态会无限增长，直到内存爆掉。

水位线阈值既是技术参数也是业务参数。设 10 分钟就是说「事件时间超过 10 分钟的迟到数据会被丢弃」。如果你的数据源本身就有 30 分钟延迟（IoT 设备批量上报、批结算场景），10 分钟水位线会把合法的迟到数据静默丢掉。水位线就是你对迟到数据的容忍上限，设多长取决于你的数据源实际能迟到多久。

1. 消费延迟（consumer lag），最重要的流式指标。延迟持续增长说明消费速度跟不上生产速度，SLA 快要违约了。
2. 批处理耗时（batch duration），如果批处理耗时超过触发间隔，说明处理有瓶颈，作业已经跑不赢了。
3. 状态存储大小（state store size），对有状态操作而言，状态持续增长就是内存泄漏，迟早 OOM。

这三个指标任何流式框架都能采集到，不需要特定云服务。关键是上线第一天就搭好，配上告警阈值（比如 consumer lag 连续 5 分钟增长就告警），别等出了第一次生产事故再补。