Flink学习笔记

在使用Flink过程中往往遇到一个问题调半天，后来发现只是一两个参数设置的不合适。看来还是要“读书”。这里做些摘录，以备需要时查阅。摘录多是别人的经验分享，自己并没有实际验证过，也有可能大家使用的Flink版本差异，有不适用的也在所难免，仅供参考!

window和group聚合操作即变更流和追加流对比

摘录于这里 

选择合适的Join实现方式

传统批处理使用的3种join实现:

1.Nested-loop Join：嵌套循环的join实现方式，简单粗暴的把需要进行join的两个数据集都加载到内存中，然后使用循环遍历的方式根据join条件进行遍历。这种实现方式空间和时间消耗是三种中最大的，要避免使用这种join实现方式，可以设参数：

table.exec.disabled-operators:NestedLoopJoin

2.Sort-Merge Join：排序合并的Join实现方式，故名思意是先对俩个数据集进行排序，再对排序后的数据集进行关联操作，由于数据是有序的所以在关联匹配时不需要每次都从头匹配，时间复杂度相对Nested-loop join较低。对于原本就有序的数据集，使用这种方式效率比较高

3.Hash Join: 这种Join实现方式，是首先把一个数据集转换为Hash Table，然后再便利另外一个数据集跟生成的Hash Table进行匹配，这样时间比较快，但也需要更多的存储空间，比较适合使用在俩个数据集大小差别比较大的场景。

摘录于这里

不同的Environment功能对比

摘录于这里 

读取Kafka数据时task数量应不应该设置成partition数量

不一定，还要看数据量，如果数据量比较小，task数量可以小于partition数量，但task数量大于partition数据是没有必要的，因为因为多出来的task会因为没有数据而退出。也就是task num <= partition num

摘录于这里

Sort-Based Blocking Shuffle

Flink1.12引入Sort-Based Blocking Shuffle，比Hash-Based Blocking Shuffle在并发度比较大（>100）的场景下性能有明显提升，而且可以有效避免引起操作系统打开文件过多问题.

可以配置：

taskmanager.network.sort-shuffle.min-parallelism 配置项开启此功能

摘录于这里

使用RocksDB做状态后端需要存储大量数据时最好设置下state.backend.rocksdb.localdir指向比较快的磁盘路径

如果状态数据需要Spill到硬盘，那硬盘的IO就会直接影响Flink应用的吞吐

摘录于这里

持续更新中....