目录
- 状态恢复不能依赖单节点
- 写出频率和数据量要平衡
- 分区数要匹配计算资源
- 有状态操作必须设水位线控制状态增长
- 三个监控指标上线前就搭好
从 DZone 一篇文章 中读到 Kuladeep Sandra 跑了五年 Kafka + Spark Structured Streaming 的生产经验。他处理的是保险理赔、制造业遥测、金融交易这类有 SLA 要求的系统。文章讲的是 Kafka/Spark 的具体配置，但这些原则的思路在其他流式处理框架中也能找到对应的做法。
状态恢复不能依赖单节点
流式处理框架用 checkpoint 记录两样东西：已提交的消费偏移量（offset）和有状态操作的中间状态。checkpoint 写在本地磁盘的话，进程重启能恢复，但节点挂了就没戏了。Spark 的做法是写到 HDFS、S3 等共享存储上；Kafka Streams 的做法是把状态变更写入 Kafka topic（changelog topic），靠 Kafka 的复制机制保证持久化。具体手段不同，但原则一样：状态恢复不能绑定在某一台机器上。
原文提到两次生产事故，一次是工程师把 checkpoint 目录当临时文件删了，一次是代码重构改了 query name 导致 checkpoint key 变化。两次都导致消费偏移量重置，需要从 Kafka 自身的 offset 存储中手工重建。都不致命，但都够折腾。所以别手动碰 checkpoint 目录，也别随便改影响 checkpoint key 的配置（比如 query name）。
写出频率和数据量要平衡
流式处理框架最终都要把数据写到下游存储。写得太频繁（比如每秒写一次），每次只攒了几条数据，产出大量小文件，下游查询和合并（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 分钟水位线会把合法的迟到数据静默丢掉。因此，水位线就是你对迟到数据的容忍上限，设多长取决于你的数据源实际能迟到多久。
三个监控指标上线前就搭好
- 消费延迟（consumer lag），最重要的流式指标。延迟持续增长说明消费速度跟不上生产速度，SLA 快要违约了。
- 批处理耗时（batch duration），如果批处理耗时超过触发间隔，说明处理有瓶颈，作业已经跑不过来了。
- 状态存储大小（state store size），对有状态操作而言，状态持续增长就可能意味着内存泄漏，会 OOM。
这三个指标任何流式框架都能采集到，不需要特定云服务。关键是上线第一天就搭好，配上告警阈值（比如 consumer lag 连续 5 分钟增长就告警），别等出了第一次生产事故再补。