Flink生产问题(1.10)

1、TaskManager OOM
发生地点：发生在flink到mysql两阶段提交阶段
原因①由于checkpoint间隔时间有5秒钟，保存的数据量大，以及没有把json数据中的无效数据去除
原因②flink默认内存分配，会把一部分内存分配给托管内存，但是我代码中没有用到rocksDB状态后端，所以不需要这部分内存，需要调整一下参数增大堆内存taskmanager.memory.managed.fraction=0
2、OOM GC时重启TaskManager
由于gc时间长，导致JobManager到TaskManager的心跳断开，此时重启另一个TaskManager，此时就会有启动时间的浪费。需要调整一下参数增加心跳延迟时间heartbeat.timeout=300000
3、通信问题
由于资源过少，导致jvm未能及时响应，影响到TM和JM的通信，此时需要调整一下超时时间akka.ask.timeout=500 s web.timeout=500000
4、业务问题
目前的业务场景：
一、
①上游kafka有多个partition，每个partition中的数据是通过canal监控mysql的binlog日志得来的，并且数据是以表的hash值进行分配到不同partition中的。所以每一个表的变更数据一定是在某个kafka的partition中是有序的。
②此时我们的需求是，有序的把每个表的增量数据同步到下游mysql(下游mysql表中会多三个字段，canal的id，数据的es，数据的类型)，比如，如果是insert操作，则下游mysql也执行一次upsert操作，此时保存的数据为上游json数据中的data数据，此时类型为insert；如果是update操作，则下游mysql也执行一次upsert操作，此时保存的数据为上游json数据中的data数据，类型为update；如果是delete操作，则下游mysql也执行一次upsert操作，此时保存的数据为上游json数据中的old数据，类型为delete；
如果有上游有ddl变更，则下游也执行一次ddl变更。
③从上述场景得出，我们必须需要顺序的去消费每个表的变更数据，但是这样就会导致一个问题，subtask分配数据不均匀，因为有的表变更消息多，有的表变更消息少，所以通过表的hash值分配到不同partition中的数据会不一样，导致flink消费时，每个并行度的数据也不均匀。
④如果上游没有ddl变更消息，我们可以通过表名+主键对数据进行keyby，尽量使得数据更分散一些。
⑤思考：现在的业务场景，因为有ddl变更，我们如何把每个subtask的数据更加均匀一些？
d->c->ddl->b->a
把ddl之前数据进行keyby
把ddl之后数据进行keyby
相当于一批一批的处理，
先根据表名keyby，在每个窗口攒一批数据，然后判断这批数据里有没有ddl，有的话根据ddl划分成多个部分，没有的话就是一个整体。。。。。。？

二、
目标下游表有唯一索引