1.1、一般为数据条数倍增
1.2、也有一些业务是单条数据体积增大
1.2.1、考虑在消息中间件的messagesize的限制
1.2.2、对序列化、反序列化的性能影响
2.1、根据业务逻辑随机生成数据
2.2、通过kafka等消息中间件将多天的数据一次性消费完
3.1、kafka的流控阈值是否合理
3.2、kafka的pt数是否够用
3.2.1、临时扩容kafka的pt只对新数据有帮助，历史数据积压无法快速消除
3.2.2、确定数据在源头没有严重的数据倾斜问题，防止大量数据集中于某一个特定的pt上
3.2.3、kafkasource的parallelism应为pt数的1/2或1/4，预留临时扩大parallelism的空间
3.3、增加高效的数据质量校验，检查job逻辑，适当的增加try-catch，注意catch发生时对性能的影响
3.4、配置好监控
4.1、如果job存在时间窗口逻辑，要考虑模拟数据的正确性，简单的通过2.2进行性能测试大多无效
4.2、不单单指flink的window操作，一些job逻辑中也可能包含时间窗口概念（比如：积攒10s的数据再批量输出，统计单位时间的uv等）
4.3、乱序数据的问题也可能更为严重，合理指定latency或者watermarket逻辑
5.1、一般job都依赖redis、hbase等存储，在数据处理过程中对数据进行加工
5.1.1、外部依赖的资源是否够用（存储、性能等）
5.1.2、配置监控，有容灾方案
5.2、适当使用asyncIO来提升性能
5.2.1、不建议将有外部IO依赖的Operator的parallelism设置的非常大，一般都可以通过asyncIO来解决，更利于chaining-strate gy的优化
5.2.2、不要一味的提升asyncIO的thread数，适当做batch效果更佳，可参照sdk中的async-batch模型
6.1、kafkasink的parallelism不要与pt数绑死，防止pt扩容无效，也不要过大的parallelism
6.2、如果序列化逻辑过于耗时，建议单独写在一个Operator里
6.3、尽量不要单条数据sink输出，会对外部造成很大的压力
6.4、batchsink时注意flush与checkpoint之间的关系
6.5、batchsink时谨慎处理batchsize和lingertime
6.6、在sink中实现重试逻辑，尽量不要将exception交给flink，效率太低，代价太大
7.1、合理设置checkpoint的频率，不要过于频繁
7.2、慎重使用exactly-once，能不用尽量不用
7.3、检查任务对于State的依赖程度，配合Savepoint启停任务
8.1、净化日志打印内容
8.2、避免system.out.println或者e.printstacktrace()等
9.1、关注ygc、fgc的频率和耗时
9.2、堆外空间的使用情况
9.3、networkbuffer的分配比例
10.1、在性能测试时可以使用原生背压探测方式分析背压情况
10.2、我们定制的背压监控是更为准确的量化指标，无需开启就可实现全天候的监控，不但可以定位，还能分析趋势
11.1、核心Operator设置uid或uidhash
11.2、使用预览拓扑功能提交job
11.3、谨慎控制chaining-strategy，尤其是cpu开销高的Operator尽量分散
11.4、尽量离散同类slot，控制slot在taskmanager的分配策略