Flink 与 Spark 架构对比
架构对比
Flink
当 Flink 集群启动后，首先会启动一个 JobManger 和一个或多个的 TaskManager。
由 Client 提交任务给 JobManager，JobManager 再调度任务到各个 TaskManager 去执行。
然后 TaskManager 将心跳和统计信息汇报给 JobManager。TaskManager 之间以流的形式进行数据的传输。
上述三者均为独立的 JVM 进程。
Client 为提交 Job 的客户端，可以是运行在任何机器上（与 JobManager 环境连通即可）。提交 Job 后，Client 可以结束进程（Streaming的任务），也可以不结束并等待结果返回。
JobManager 主要负责调度 Job 并协调 Task 做 checkpoint，职责上很像 Storm 的 Nimbus。从 Client 处接收到 Job 和 JAR 包等资源后，会生成优化后的执行计划，并以 Task 的单元调度到各个 TaskManager 去执行。
TaskManager 在启动的时候就设置好了槽位数（Slot），每个 slot 能启动一个 Task，Task 为线程。从 JobManager 处接收需要部署的 Task，部署启动后，与自己的上游建立 Netty 连接，接收数据并处理。
可以看到 Flink 的任务调度是多线程模型，并且不同 Job/Task 混合在一个 TaskManager 进程中。虽然这种方式可以有效提高 CPU 利用率，但是不仅缺乏资源隔离机制，同时也不方便调试。
Spark
Spark 应用程序在集群上作为独立的进程集运行，由主程序（称为驱动程序）中的sparkContext对象协调。
具体来说，要在集群上运行，sparkContext可以连接到几种类型的集群管理器（spark自己的独立集群管理器、mesos或yarn）,
它们在应用程序之间分配资源一旦连接, spark将获取集群中节点上的执行器，这些节点是运行计算和存储应用程序数据的进程。
接下来，它将应用程序代码（由传递给sparkcontext的jar或python文件定义）发送给执行器。最后，sparkContext将任务发送给执行器以运行。
- 每个应用都会有自己的处理器进程，处理器上会利用多线程执行任务。这样做到了应用级的隔离, 定时任务或者处理器任务都可以跑在不同的Jvm上。这样做的弊端是不能很好的进行多应用(SparkContext)之间的 数据共享，除非应用之间是共享一个数据存储
- Spark 支持多种底层集群管理器, 因为他可以申请处理器进程, 并且彼此间可以互相通信，它很容易的就可以跑在类似 Mesos/YARN 的集群管理服务器上
- Driver Program 会一直管理 SprintContext 的请求，Driver Program 会执行集群上的任务，Driver Program 和工作节点一定是要网络互通的，最好和 work node 在一个局域网之内运行,如果需要远程向群集发送请求，最好让 Driver Program 通过 RPC 提交请求操作
Yarn
YARN总体上是 Master/Slave 结构，主要由 ResourceManager、NodeManager、 ApplicationMaster 和 Container 等几个组件构成。
ResourceManager(RM)
负责对各NM上的资源进行统一管理和调度。将AM分配空闲的Container运行并监控其运行状态。对AM申请的资源请求分配相应的空闲Container。
主要由两个组件构成：调度器和应用程序管理器调度器(Scheduler)
调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等）将系统中的资源分配给各个正在运行的应用程序。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位是Container，从而限定每个任务使用的资源量。Shceduler不负责监控或者跟踪应用程序的状态，也不负责任务因为各种原因而需要的重启（由ApplicationMaster负责）。总之，调度器根据应用程序的资源要求，以及集群机器的资源情况，为应用程序分配封装在Container中的资源。调度器是可插拔的，例如CapacityScheduler、FairScheduler。应用程序管理器(Applications Manager)
应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动AM、监控AM运行状态并在失败时重新启动等，跟踪分给的Container的进度、状态也是其职责。
NodeManager (NM)
NM是每个节点上的资源和任务管理器。它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；同时会接收并处理来自AM的Container 启动/停止等请求。ApplicationMaster (AM)
用户提交的应用程序均包含一个AM，负责应用的监控，跟踪应用执行状态，重启失败任务等。ApplicationMaster是应用框架，它负责向ResourceManager协调资源，并且与NodeManager协同工作完成Task的执行和监控。MapReduce就是原生支持的一种框架，可以在YARN上运行Mapreduce作业。有很多分布式应用都开发了对应的应用程序框架，用于在YARN上运行任务，例如Spark，Storm等。如果需要，我们也可以自己写一个符合规范的YARN application。Container
Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container 表示的。 YARN会为每个任务分配一个Container且该任务只能使用该Container中描述的资源
参考资料
