Flink

Flink架构

Flink集群启动后，首先会启动一个JobManger和一个或多个的TaskManager。由Client提交任务给JobManager，JobManager再调度任务到各个TaskManager去执行，然后TaskManager将心跳和统计信息汇报给JobManager。TaskManager之间以流的形式进行数据的传输。上述三者均为独立的JVM进程。

• Client：提交Job的客户端，可以运行在任何机器上（与JobManager环境连通即可）。提交Job后，Client可以结束进程（Streaming的任务），也可以不结束并等待结果返回。
• JobManager：主要负责调度Job并协调Task做checkpoint。从Client处接收到Job和JAR包等资源后，会生成优化后的执行计划，并以Task的单元调度到各个TaskManager去执行。
• TaskManager：在启动时设置好槽位数（Slot），每个slot能启动一个Task，Task为线程。从JobManager处接收需要部署的Task，部署启动后，与自己的上游建立Netty连接，接收数据并处理。

  Flink的流处理与Spark Streaming

  Flink流处理是一行一行处理，而Spark Streaming是基于数据片集合（RDD）进行小批量处理，所以Spark在流式处理方面，不可避免增加一些延时。
  Spark Streaming是Apache Spark之上支持流处理任务的子系统，采用了一种micro-batch的架构，即将输入的数据流切分成细粒度的batch数据，对于每一个batch数据，以此为输入提交一个批处理Spark任务，所以Spark Streaming本质上还是基于Spark批处理系统对流式数据进行处理。
  在Flink中，批处理用DataSet，对于流处理有DataStreams。思想类似，但却有所不同：其一，DataSet在运行时表现为Runtime Plans，而在Spark中，RDD在运行时表现为Java Objects。在Flink中有Logical Plan，这和Spark中的DataFrames类似。因而，在Flink中，若是使用这类API，会被优先来优化（即：自动优化迭代）。
  
  在 Spark 中，RDD 就没有这块的相关优化。 在Spark中，所有不同的API，比如Streaming，DataFrame都是基于RDD抽象的。然而在Flink中，DataSet和DataStream是相对独立的API，是同一个公用引擎之上的两个独立的抽象。所以，不能把这两者的行为合并在一起操作。

  Flink的WaterMark

  Flink借鉴了Google的MillWheel项目，通过WaterMark来支持基于Event Time时间窗口。
  当操作符通过基于Event Time的时间窗口来处理数据时，它必须在确定所有属于该时间窗口的消息全部流入此操作符后，才能开始处理数据。但是由于消息可能是乱序的，所以操作符无法直接确认何时所有属于该时间窗口的消息全部流入此操作符。WaterMark包含一个时间戳，Flink使用WaterMark标记所有小于该时间戳的消息都已流入，Flink的数据源在确认所有小于某个时间戳的消息都已输出到Flink流处理系统后，会生成一个包含该时间戳的WaterMark，插入到消息流中输出到Flink流处理系统中，Flink操作符按照时间窗口缓存所有流入的消息，当操作符处理到WaterMark时，它对所有小于该WaterMark时间戳的时间窗口的数据进行处理并发送到下一个操作符节点，然后也将WaterMark发送到下一个操作符节点。
  为了保证能够处理所有属于某个时间窗口的消息，操作符必须等到大于这个时间窗口的WaterMark之后，才能开始对该时间窗口的消息进行处理，相对于基于Operator Time的时间窗口，Flink需要占用更多的内存，且会直接影响消息处理的延迟时间。对此，一个可能的优化措施是，对于聚合类的操作符，可能可以提前对部分消息进行聚合操作，当有属于该时间窗口的新消息流入时，基于之前的部分聚合结果继续计算，这样的话，只需缓存中间计算结果即可，无需缓存该时间窗口的所有消息。
  对于基于Event Time时间窗口的操作符来说，流入WaterMark的时间戳与当前节点的时钟一致是最简单理想的状况了，但是在实际环境中是不可能的，由于消息的乱序以及前面节点处理效率的不同，总是会有某些消息流入时间大于其本身的时间戳，真实WaterMark时间戳与理想情况下WaterMark时间戳的差别称为Time Skew，如下图所示：
  
  Time Skew决定了该WaterMark与上一个WaterMark之间的时间窗口所有数据需要缓存的时间，Time Skew时间越长，该时间窗口数据的延迟越长，占用内存的时间也越长，同时会对流处理系统的吞吐量产生负面影响。
  在流处理系统中，由于流入的消息是无限的，所以对消息进行排序基本上被认为是不可行的。但是在Flink流处理系统中，基于WaterMark，Flink实现了基于时间戳的全局排序。思路如下：排序操作符缓存所有流入的消息，当其接收到WaterMark时，对时间戳小于该WaterMark的消息进行排序，并发送到下一个节点，在此排序操作符中释放所有时间戳小于该WaterMark的消息，继续缓存流入的消息，等待下一个WaterMark触发下一次排序。由于WaterMark保证了其之后不会出现时间戳比它小的消息，所以可以保证排序的正确性。需要注意的是，如果排序操作符有多个节点，只能保证每个节点的流出消息是有序的，节点之间的消息不能保证有序，要实现全局有序，则只能有一个排序操作符节点。
  通过支持基于Event Time的消息处理，Flink扩展了其流处理系统的应用范围，使得更多的流处理任务可以通过Flink来执行。

  Flink的几种时间

  在处理Stream中的记录时，记录中通常会包含各种典型的时间字段，Flink支持多种时间的处理。 ![Flink Time][FT]
  Event Time：事件创建时间，Ingestion Time：事件进入到Flink Dataflow的时间 ，Processing Time：某个Operator对事件进行处理事的本地系统时间（是在TaskManager节点上）。通常根据Event Time会给整个Streaming应用带来一定的延迟性，因为在一个基于事件的处理系统中，进入系统的事件可能会基于Event Time而发生乱序现象，比如事件来源于外部的多个系统，为了增强事件处理吞吐量会将输入的多个Stream进行自然分区，每个Stream分区内部有序，但是要保证全局有序必须同时兼顾多个Stream分区的处理，设置一定的时间窗口进行暂存数据，当多个Stream分区基于Event Time排列对齐后才能进行延迟处理。所以，设置的暂存数据记录的时间窗口越长，处理性能越差，甚至严重影响Stream处理的实时性。

  Flink作业提交

  用户首先提交Flink程序到JobClient，经过JobClient的处理、解析、优化提交到JobManager，最后由TaskManager运行task。