实时数据开发的一些实战经验

实时数据开发与离线开发最大的区别在于：离线关注"吞吐量"，实时关注"确定性"。在生产环境中，一个微小的配置失误或逻辑漏洞都可能导致数据积压、状态爆炸甚至业务停摆。以下是从大量生产事故和优化案例中提炼出的实战经验，分为五个核心维度：

状态是实时计算的灵魂，也是故障的重灾区。

永远不要信任默认 State TTL
- 问题：很多新手设置 TTL=7天，但实际业务中某些 Key 的访问间隔可能超过7天，导致状态被误删；或者 TTL 过长导致 RocksDB Compaction 压力巨大。
- 实战：TTL 必须基于真实数据分布 设定。上线前用采样数据分析 Key 的访问间隔 P99 值，TTL = P99 + Buffer。对于会话类场景，优先使用 SessionWindow 自带的超时机制而非全局 TTL。
RocksDB 调优不是玄学
- BlockCache ：不要简单设为 TM 内存的 30%。当多个 Slot 共享 TM 时，每个 Slot 的 RocksDB 实例会独立分配 BlockCache，极易 OOM。正确做法 ：启用 sharedMemory 模式，让所有 Slot 共享同一块 BlockCache。
- WriteBufferManager ：当写入吞吐高时，MemTable 刷盘速度跟不上写入速度，会导致 Write Stall。需根据磁盘 IO 能力调整 writeBufferSize 和 maxWriteBufferNumber，并开启 rateLimiter 平滑写入。
大 Key 监控与治理前置
- 在作业上线前，通过 Flink Metrics 暴露 state.backend.rocksdb.actual-delayed-write-rate 和 compaction-pending-bytes。一旦触发 Delayed Write，立即告警。
- 对于已知的大 Key 场景（如热门商品、头部用户），在代码层面做Key 打散 （加随机后缀）或二级聚合（先局部聚合再全局聚合）。

Kafka 看似简单，但在实时链路中极易成为瓶颈。

Consumer Lag ≠ 数据延迟
- 陷阱：Lag=0 不代表数据及时。如果 Producer 发送延迟高，或 Watermark 生成过慢，即使消费完了，事件时间仍可能严重滞后。
- 实战：必须同时监控 EventTime Lag（当前 Watermark 与系统时间的差值）。只有 EventTime Lag 才能反映真实的业务数据新鲜度。
事务 Producer 的性能代价
- Exactly-Once Sink 必须开启事务，但事务会带来约 20%-40% 的吞吐下降。
- 优化：增大 transaction.timeout.ms 避免频繁超时重试；合理设置 batch.size 和 linger.ms 提升单事务批次大小；对于非关键指标，可降级为 At-Least-Once + 幂等写入（如 Doris Unique Key 模型）。
Topic 分区数 ≠ 并行度
- 下游 Flink 并行度 > Kafka 分区数时，多余子任务空跑浪费资源；并行度 < 分区数时，单任务消费多分区，Rebalance 时影响面大。
- 黄金法则：Flink 并行度 = Kafka 分区数，或为其因数。扩容时同步扩 Topic 分区和 Flink 并行度。

CDC 是实时数仓的入口，稳定性至关重要。

全量阶段是高危期
- Flink CDC 全量读取时会对源库造成巨大压力，且 Binlog 位点可能因 DDL 变更而中断。
- 实战：使用 Flink CDC 3.x 的 YAML Pipeline 模式，支持全量+增量无缝切换、自动分片、断点续传。对核心库务必配置限流（scan.incremental.snapshot.chunk.size）和只读账号。
Schema 演进必须防御性编程
- 上游加字段、改类型是常态。若未做兼容，整条链路会直接 Failover。
- 实战：在 Source 后接一个 Schema Validation 算子，对不兼容变更走 Side Output 告警并旁路存储，主链路继续运行。配合 Schema Registry 强制兼容性检查。
DDL 同步的双刃剑
- 自动同步 DDL 很方便，但风险极高（如误删列、类型隐式转换丢精度）。
- 建议：生产环境关闭自动 DDL 同步，改为告警通知人工确认后再手动执行。仅在内网测试或非核心链路开启。

拒绝"试错式调参"，建立科学的诊断流程。

反压定位三步法
1. 看 Web UI Backpressure 面板，找到 HIGH 的算子。
2. 检查该算子的 busyTimeMsPerSecond：若接近 100%，说明 CPU 瓶颈（可能是 UDF 低效、序列化开销大）；若远低于 100% 但反压高，说明是下游反压传导 或网络/IO 瓶颈。
3. 结合 Flame Graph 定位具体代码热点，或用 Async Profiler 分析 GC/锁竞争。
Checkpoint 超时≠State 太大
- 常见误区：CP 超时就直接加内存/换 SSD。
- 真相：更多时候是Barrier 对齐等待 导致。检查各算子处理速度是否均衡；开启 Unaligned Checkpoint 可大幅缓解因个别慢算子导致的 CP 超时（但会增加 State 大小）。
资源规划的"水位线"原则
- 不要将 TM 内存打满。预留 20%-30% 作为安全缓冲，应对流量突增和 GC 波动。Network Buffer 占比通常 10%-15%，Managed Memory（RocksDB）按需分配，Heap 留给框架和用户对象。

Savepoint 是升级的唯一凭证
- 任何代码变更、配置调整、版本升级，必须先触发 Savepoint 并验证可恢复，再停旧作业。禁止直接 Cancel 后重启（除非接受数据丢失）。
灰度发布与双跑验证
- 新作业上线必须与老作业双跑至少 24 小时 ，对比核心指标（PV/UV/GMV）差异 ≤1% 才可切流。使用 Flink 的 --detached 模式和独立 JobID 管理多版本。
告警分级与 On-Call SOP
- P0（数据中断/严重延迟）：电话告警，5分钟响应，SOP 包含回滚步骤。
- P1（轻微积压/CP 变慢）：IM 告警，30分钟内处理。
- P2（资源利用率低/非核心指标波动）：日报汇总，周会复盘。
- 关键：每条告警必须附带排查链接（Grafana Dashboard、Flink UI、日志查询语句），减少 On-Call 人员的认知负荷。

建立团队的 "实时故障知识库" ：每次故障后，不仅写 RCA（根因分析），更要提炼出可执行的 Checklist（如"上线前必查项"、"RocksDB 调参模板"、"Kafka 容量评估表"）。知识只有转化为标准化动作，才能真正避免重复踩坑。

这些经验大多来自血泪教训。实时开发没有银弹，唯有对细节的敬畏和对系统的深度理解，才能在毫秒级的世界里守住数据的准确性与稳定性。