1、KeyBy 操作后，只有当 Key 的数量大于算子的并发实例数才能获得较好的计算性能。
A.而若Key 的数量比实例数量少，就会导致部分实例收不到数据，这些实例就得不到执行，这些实例的计算能力得不到充分发挥。
B.当Key个数多余并行实例数时，由于同一个 Key 对应的所有数据都能发送到同一个计算实例上，同一个Key中所对应的数据都能分配到同一个实例中，这样Key内计算就免去了数据传递的序列化和网络IO等开销。
2、执行环境的excute()方法
前面我们调用的所有方法，都不是在实际处理数据，而是在构通表达计算逻辑的DAG图。只有当我们将整个图构建完成并显式调用 Execute 方法后，框架才会把计算图提交到集群中，接入数据并执行实际的逻辑。
3、Flink Runtime 层的整个架构主要是在 FLIP-6 中实现的，整体上采用了标准 master-slave 的结构。
其中master负责管理整个集群中的资源和作业；而TaskExecutor 则是 Slave，负责提供具体的资源并实际执行作业。
4、Master 部分又包含了三个组件，即 Dispatcher、ResourceManager 和 JobManager。
A.Dispatcher负责接收用户提供的作业，并且负责为这个新提交的作业拉起一个新的 JobManager 组件。
B.ResourceManager 负责资源的管理，在整个 Flink 集群中只有一个 ResourceManager。
C.JobManager 负责管理作业的执行，在一个 Flink 集群中可能有多个作业同时执行，每个作业都有自己的 JobManager 组件。
以上三个组件都包含在 AppMaster 进程中。
5、当用户提交作业时，提交脚本会先启动一个Client进程负责作业的编译与提交。
它先将用户编写的代码编译为一个 JobGraph，在这个过程，它还会进行一些检查或优化等工作，如判断哪些 Operator 可以 Chain 到同一个 Task 中。然后，Client 将产生的 JobGraph 提交到集群中执行。此时有两种情况，一种是类似于 Standalone 这种 Session 模式，AM 会预先启动，此时 Client 直接与 Dispatcher 建立连接并提交作业即可。另一种是 Per-Job 模式，AM 不会预先启动，此时 Client 将首先向资源管理系统 （如Yarn、K8S）申请资源来启动 AM，然后再向 AM 中的 Dispatcher 提交作业。
6、当作业到 Dispatcher 后
Dispatcher 会先启动一个 JobManager 组件，然后 JobManager 会向 ResourceManager 申请资源来启动作业中具体的任务。这时根据 Session 和 Per-Job 模式的区别， TaskExecutor 可能已经启动或者尚未启动。若是前者，此时 ResourceManager 中已有记录了 TaskExecutor 注册的资源，可以直接选取空闲资源进行分配。若是后者，ResourceManager 也需要先向外部资源管理系统申请资源来启动 TaskExecutor，然后等待 TaskExecutor 注册相应资源后再继续选择空闲资源进程分配。
目前 Flink 中 TaskExecutor 的资源是通过 Slot 来描述的，一个 Slot 一般可以执行一个具体的 Task，但在一些情况下也可以执行多个相关联的 Task。ResourceManager 选择到空闲的 Slot 之后，就会通知相应的 TM “将该 Slot 分配给 JobManager XX ”，然后 TaskExecutor 进行相应的记录后，会向 JobManager 进行注册。JobManager 收到 TaskExecutor 注册上来的 Slot 后，就可以实际提交 Task 了。TaskExecutor 收到 JobManager 提交的 Task 之后，会启动一个新的线程来执行该 Task。Task 启动后就会开始进行预先指定的计算，并通过数据 Shuffle 模块互相交换数据。
7、Flink 支持两种作业执行模式，即 Per-job 模式与 Session 模式。
7.1Per-job 模式下整个 Flink 集群只执行单个作业，即每个作业会独享 Dispatcher 和 ResourceManager 组件。此外，Per-job 模式下 AppMaster 和 TaskExecutor 都是按需申请的。因此，Per-job 模式更适合运行执行时间较长的大作业，这些作业对稳定性要求较高，并且对申请资源的时间不敏感。【一般配合yarn、mesose、k8s等外部资源管理器】
7.2与之对应，在 Session 模式下，Flink 预先启动 AppMaster 以及一组 TaskExecutor，然后在整个集群的生命周期中会执行多个作业。可以看出，Session 模式更适合规模小，执行时间短的作业。【一般在standalone模式下使用】