Flink处理Kinesis数据流写入Elasticsearch严重延迟，求原因排查建议

1. Flink作业配置问题 #

• 并行度配置不合理：Flink Kinesis消费并行度未和Kinesis分片数对齐，会导致单分片消费积压；ES Sink并行度设置过低会直接导致写入请求排队，吞吐上不去。
• 批量写入参数配置过小：Flink Elasticsearch Sink的bulk.flush.max.actions、bulk.flush.max.size.mb、bulk.flush.interval.ms参数如果保留默认值，会产生大量零散的小批量请求，大幅降低写入效率，推荐配置为单批次1000_{5000条，或单批次大小1}5MB。
• 未开启异步写入：如果ES Sink使用同步写入模式，每个请求需要等待ES返回后才处理下一批数据，会直接拉低整体处理速度。
• 作业存在反压：可通过Flink UI排查反压节点，90%以上的同类场景都是ES Sink返回过慢导致上游处理阻塞。

2. AWS OpenSearch（Elasticsearch 7.7）侧问题 #

• 分片策略与集群规模不匹配：当前仅2个节点，设置了5个主分片+每个分片1个副本，总共有10个分片，单节点需要承载5个分片，过多的分片会提升节点元数据管理开销，拉低写入性能；同时1个副本的配置会带来一倍写入放大，写入请求需要主、副本分片都落盘才会返回成功，写入密集场景下可以临时将副本数设为0，写入完成后再恢复，也可以将主分片数调整为2~3个匹配节点规模。
• 刷新间隔过于频繁：默认1秒的index.refresh_interval会导致ES频繁生成分段文件，后台分段合并压力陡增，写入性能会下降30%~70%，写入密集场景可以将该参数调整为30秒，甚至设为-1（写入完成后手动触发刷新）。
• 索引写入配置未优化：index.translog.durability默认是request，每次写入都要刷盘translog，可调整为async模式大幅降低磁盘IO开销；如果indices.memory.index_buffer_size设置过小，会导致写入缓冲区频繁溢写到磁盘，也会拖慢写入速度。
• 节点资源不足：如果使用的是小规格实例（如t系列、低配置m系列实例），CPU、内存、网络带宽不足以支撑高吞吐写入，可排查OpenSearch监控的CPU使用率、JVM Old区占比、写入队列长度指标，确认是否存在资源打满的情况。
• 未使用批量写入API：如果Sink端是单条数据调用写入接口，性能会比_bulk批量API低10倍以上。

3. Kinesis数据流侧问题 #

• 分片数不足：Kinesis单分片最多支持每秒1000条写入、1MB/s吞吐量，每秒5万条事件至少需要50个分片，如果Kinesis分片数不够会触发平台侧限流，消费端无法拿到全量数据。
• 消费端限速配置：如果Flink Kinesis Consumer配置了消费限速参数，会直接限制消费速度，导致数据积压。

内容的提问来源于stack exchange，提问作者Rohit