Flink写500亿 天数据到远端Kafka排错、Flink优化记录。_flink lz4 压缩

问题点：

使用checkpoint的时候，sink端需要进行幂等性操作，不然会在程序失败的时候导致重复写入。

批量推送没有问题，但是并没有进行压缩操作，导致数据大小太大，进行远距离消息传输所需带宽增大。

使用的kafka-connect 和kafkaSink版本过低。

解决三个问题：

手动提交或使用事务操作，由于是海量数据，故选择手动提交offset操作，避免数据重复提交。

在producer端添加lz4压缩，为方便consumer端方便操作，直接将topic也进行了compressType的更改。

将kafka-connect和KafkaSink版本升级，使用最新版本的jar包进行数据推送。

在升级jar包的时候发生了一个报错：

这个可能是将序列化和序列化解析弄反了，但是在Flink代码中并没有这个错误发生。最后发现是pom文件引入该包时使用了complie，而Flink提交时指定的库也有相同包，进行了更改报错消失。所以也算是莫名其妙。

上述问题看着简单，其实确实简单，但在巨量数据面前，问题就频频爆发。

但就算进行了上述更改，在数据量超过300MB/s的时候，还是发现有如下报错：

这个错误网上也有很多描述：

大多数都是说将request.timeout.ms 提高，batch-size 和liner-ms 调到比较合适的值。 但是其实这个原因的本质错误在org.apache.kafka.clients.producer.internals.ProducerBatch#maybeExpire中，（注意老版本不会区分以下三个报错）

可以看到这个报错时第一种类型。原理描述可以如下：

一个partition只会有队头的batch被发送，sender线程不会对发送中partition的其余batch检查过期，指向同一个broker的多个partition的batch能够合并成一个request发送。其中前两点是由Accumulator里的