1、KeyBy 操作后,只有当 Key 的数量大于算子的并发实例数才能获得较好的计算性能。A.而若Key 的数量比实例数量少,就会导致部分实例收不到数据,这些实例就得不到执行,这些实例的计算能力得不到充分发挥。 2、执行环境的excute()方法前面我们调用的所有方法,都不是在实际处理数据,而是在构通表达计算逻辑的DAG图。只有当我们将整个图构建完成并显式调用 Execute 方法后,框架才会把计算图提交到集群中,接入数据并执行实际的逻辑。 3、Flink Runtime 层的整个架构主要是在 FLIP-6 中实现的,整体上采用了标准 master-slave 的结构。其中master负责管理整个集群中的资源和作业;而TaskExecutor 则是 Slave,负责提供具体的资源并实际执行作业。 4、Master 部分又包含了三个组件,即 Dispatcher、ResourceManager 和 JobManager。A.Dispatcher负责接收用户提供的作业,并且负责为这个新提交的作业拉起一个新的 JobManager 组件。 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 注册相应资源后再继续选择空闲资源进程分配。 7、Flink 支持两种作业执行模式,即 Per-job 模式与 Session 模式。7.1Per-job 模式下整个 Flink 集群只执行单个作业,即每个作业会独享 Dispatcher 和 ResourceManager 组件。此外,Per-job 模式下 AppMaster 和 TaskExecutor 都是按需申请的。因此,Per-job 模式更适合运行执行时间较长的大作业,这些作业对稳定性要求较高,并且对申请资源的时间不敏感。【一般配合yarn、mesose、k8s等外部资源管理器】 |
|