作者：任春德
10年积累的成都网站建设、做网站经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先制作网站后付款的网站建设流程，更有铜官免费网站建设让你可以放心的选择与我们合作。
Apache Flink作为下一代大数据计算引擎，在迅速发展强大中，其内部架构也在不断优化重构，以适应更多运行时环境和更大计算规模，Flink Improvement Proposals-6重新设计了在各集群管理系统(Standalone/YARN/Kubernetes等)上资源调度的统一架构，本文将介绍资源调度的架构发展及其清晰分层等设计特点，YARN上per-Job和session两种模式的实现，以及正在讨论开发的与K8S云原生融合的详细设计。
本文内容如下：
Apache Flink Standalone Cluster
Apache Flink 与 YARN 的原生融合
Apache Flink 与 K8S 的原生融合
如图1，Flink的Standalone集群部署是主从架构，其中主JobManager(简称JM)负责Job的计算单元Task调度，TaskManager(简称TM)向JobManager汇报并负责在其内部用线程执行Task。
cdn.xitu.io/2019/5/6/16a8b08199dfa29c?w=2145&h=916&f=png&s=115499">
之所以是Standalone，是因为其不依赖其他底层资源调度系统，直接部署启动在各自的裸机器节点上，虽然可以用一些自动化运维工具方便地部署和管理，但是存在以下几个问题：
隔离：多Job运行在一个集群，可能同一TM上执行不同Job的Task，其线程所用资源(cpu/mem)无法控制，相互影响，甚至一个Task造成整个TM的Out Of Memory，使其之上的Job都受影响；多个Job的调度也在同一个JM中，同样存在被有问题Job影响的问题。
多租户的资源用量(quota)管理：无法控制用户的Job资源使用总量，缺乏租户间的资源协调管理。
集群的可用性：虽然JM可以部署有Standby，支持High Available，但JM、TM进程缺乏被看护，难免因以上隔离等问题造成过多进程宕掉，整个集群不可用。
为了解决以上问题，需要将Flink跑在流行成熟的资源调度系统上，如YARN、Kubernetes、Mesos，如何实现呢？
简单有效的一种部署方式是利用YARN自身支持的特性，将Flink Standalone部署到YARN集群上，如图2(Apache Flink Standalone Cluster ON YARN)，
多个Job可以相应地起多个YARN Application，每个app是一个standalone cluster，各自独立运行，而且依靠YARN本身支持的cgroups等隔离手段，避免了多任务间的相互影响，隔离问题迎刃而解。
不同用户的App也可以运行在不同的YARN调度队列中，通过queue quota管理能力解决多租户的问题。
同时可以利用YARN对App进程的重启重试再调度的策略，使Flink Standalone Cluster高可用。
虽然解决了以上问题，但是每个(少量)Job起一个Standalone Cluster，难以达到高效的资源利用，因为：
Cluster的规模(多少个TM)是在启动YARN App时参数静态指定的，Flink自身的编译优化使其较难在运行前预估资源的需求，那就难以合理化TM数量，多了资源浪费，少了影响Job执行速度甚至无法运行。
每个TM拥有的资源大小也是参数静态指定，同样难以预估实际需要，不能针对不同的Task资源需求来动态申请不同大小的TM，只能设置相同规格大小的TM，那就难以恰好放置整数个Task，剩余的部分资源浪费。
大规模YARN集群中Flink Job越多，资源浪费的会更可观，成本损失越大，而且不只是on YARN存在以上问题，Standalone直接运行于其他资源调度系统之上，也是有相同问题，所以阿里巴巴实时计算率先在YARN实际生产经验上改进了Flink的资源利用模型，后续与社区讨论设计实现了一套通用的架构，适用于不同的资源调度系统。
FLIP-6全面记录了此次部署架构的重构，新的模块如图3。类似MapReduce-1架构向YARN+MapReduce-2的升级，将资源调度与Job计算逻辑单元(Task)的调度分成2层，使两个模块（系统）——ResourceManager(RM)和JobManager(JM)各司其职，与底层资源调度系统的耦合降低（只需实现不同plugable的ResourceManager即可），减少逻辑复杂度降低开发维护难度，优化JM实现资源按Task所需申请，解决了Standalone on YARN/K8S的资源利用率低的问题，同时还有利于集群和Job规模的扩展。
Dispatcher: 负责与Client通信接收Job的提交，生成JobManager，生命周期可跨Job。
ResourceManager: 对接不同资源调度系统，实现资源的调度（申请/释放），管理Container/TaskManager，同样生命周期可跨Job。
JobManager: 每个Job一个实例，负责Job的计算逻辑的调度执行。
根据以上架构，Flink on YARN实现了2种不同的部署运行模式Per-Job和Session（用户使用文档Flink on Yarn）。
Per-Job即一个Flink Job与其YARN Application(App)生命周期绑定，执行过程如图4，在提交YARN App时同时将Flink Job的file/jars通过YARN Distributed Cache分发，一次性完成提交，而且JM是根据JobGraph产生的Task的资源实际需求来向RM申请slot执行，Flink RM再动态的申请/释放YARN的Container。完美(?)解决了之前的所有问题，既利用了YARN的隔离又有高效的资源利用。
Per-Job完美？No，还是存在局限，YARN App的提交时资源申请和启动TM的时间较长(秒级)，尤其在交互式分析短查询等场景上，Job计算逻辑执行时间很短，那么App的启动时间占比大就严重影响了端到端的用户体验，缺少了Standalone模式上Job提交快的优点。但FLIP-6架构的威力，还是能轻松化解这个问题，如图5，通过预启动的YARN App来跑一个Flink Session（Master和多个TM已启动，类似Standalone可运行多个Job），再提交执行Job，这些Job就可以很快利用已有的资源来执行计算。Blink分支与Master具体实现有点不同（是否预起TM），后续会合并统一，并且继续开发实现Session的资源弹性——按需自动扩缩TM数量，这点是standalone无法实现的。
前面是架构上的变化，而要实现资源按需申请，需要有协议API，这就是Resource Profile，可以描述单个算子(Operator)的CPU & Memory等的资源用量，进而RM根据这些资源请求来向底层资源管理系统申请Container来执行TM，详细的使用文档见Task slots and resources。
最近几年，Kubernetes的发展迅猛，已然成为了云时代的原生操作系统，下一代的大数据计算引擎Apache Flink的部署与其融合，是否可以开辟大数据计算的新大陆？
依靠K8S自身支持Service部署的强大能力，Flink Standalone Cluster可以通过简单的K8S: Deployment & Service或Flink Helm chart很容易的部署到K8S集群上，但同样有类似Standalone on YARN的资源利用率低等问题，所以还是需要“原生融合”。
Flink与K8S的“原生融合”，主要是在FLIP-6架构上实现K8SResourceManager来对接Kubernetes的资源调度协议，现Blink的分支实现架构下图所示，用户使用文档见Flink on K8S，merge到主干Master上的工作正在进行中
部署管理、资源调度是大数据处理系统的底层基石，通过FLIP-6的抽象分层和重构，Apache Flink构建了牢固的基础，可以“原生”地运行于各大资源调度系统（YARN/Kubernetes/Mesos）上，支撑起更大规模更高并发的计算，高效地利用集群资源，为后续的不断发展强大提供了可靠的保障。
相关功能的优化改进依然在继续，如Resource Profile配置资源的难度使一些开发者望而生畏，并且严重降低了Flink的易用性，我们在尝试实现资源和并发配置的Auto Config/Scaling等功能来解决此类问题；“Serverless”架构在迅速发展，期待Flink与Kubernetes的融合成为云原生的强大计算引擎(类FaaS)，为用户节省资源，带来更大的价值。
更多资讯请访问 Apache Flink 中文社区网站
