Flink 的编程模型与其他框架比较

• Flink 的核心语义和架构模型
  • Flink核心概念
    • Streams(流)
      • 有界流
        有固定大小，不随时间增长而增长的数据，比如Hive中的一张表
      • 无界流
        无固定大小，数据随时间增长而增长，比如Kafka中的消息
    • State(状态)#重要
      指的是在进行流式计算过程中的信息，一般用作容错恢复和持久化。因为流式计算本质是增量计算，也就是说需要不断查询过去的状态
    • Time(时间)
      Flink 支持了 Event time、Ingestion time、Processing time , 是判断业务是否滞后和延迟的重要依据
    • API
      由上而下可分为 SQL / Table API、DataStream API、ProcessFunction 三层​​​
• Flink 编程模型和流式处理
  • 基础构建模块是流（Streams）和转换（Transformations）
    每一个数据流起始于一个或多个 Source，并终止于一个或多个 Sink。数据流类似于有向无环图（DAG）​
  • 算子链
    在分布式运行环境中，Flink 提出了算子链的概念，Flink 将多个算子放在一个任务中，由同一个线程执行，减少线程之间的切换、消息的序列化/反序列化、数据在缓冲区的交换，减少延迟的同时提高整体的吞吐量。
    官网中给出的例子如下，在并行环境下，Flink 将多个 operator 的子任务链接在一起形成了一个task，每个 task 都有一个独立的线程执行。​
• Flink 集群模型和角色（和spark差不多）
  • JobManager
  • TaskManager
  • Client
• Flink 资源和资源组
  • Task Slot( TaskManager 的计算资源子集)
    在 Flink 集群中，一个 TaskManger 就是一个 JVM 进程，并且会用独立的线程来执行 task，为了控制一个 TaskManger 能接受多少个 task，Flink 提出了 Task Slot 的概念。
    • 避免资源竞争
      假如一个 TaskManager 拥有 5 个 slot，那么该 TaskManager 的计算资源会被平均分为 5 份，不同的 task 在不同的 slot 中执行，避免资源竞争。
    • 降低资源消耗
      但是需要注意的是，slot 仅仅用来做内存的隔离，对 CPU 不起作用。那么运行在同一个 JVM 的 task 可以共享 TCP 连接，减少网络传输，在一定程度上提高了程序的运行效率，降低了资源消耗。
    • 资源共享
      与此同时，Flink 还允许将不能形成算子链的两个操作，比如下图中的 flatmap 和 key&sink 放在一个 TaskSlot 里执行以达到资源共享的目的
• Flink 的优势及与其他框架的区别
  • 架构
    1. Storm 的架构是经典的主从模式，并且强依赖 ZooKeeper；
    ​​2. Spark Streaming 的架构是基于 Spark 的，它的本质是微批处理，每个 batch 都依赖 Driver，我们可以把 Spark Streaming 理解为时间维度上的 Spark DAG。
    3. Flink 也采用了经典的主从模式，DataFlow Graph 与 Storm 形成的拓扑 Topology 结构类似，Flink 程序启动后，会根据用户的代码处理成 Stream Graph，然后优化成为 JobGraph，JobManager 会根据 JobGraph 生成 ExecutionGraph。ExecutionGraph 才是 Flink 真正能执行的数据结构，当很多个 ExecutionGraph 分布在集群中，就会形成一张网状的拓扑结构。
  • 容错
    1. storm在容错方面只支持 Record 级别的 ACK_FAIL, 发送出去的每一条消息，都可以确定是被成功处理或失败处理，因此 Storm 支持至少处理一次语义。
    2. Spark Streaming 任务可以配置对应的 checkpoint，也就是保存点。当任务出现 failover 的时候，会从 checkpoint 重新加载，使得数据不丢失。但是这个过程会导致原来的数据重复处理，不能做到“只处理一次”语义。​
    3.Flink 基于两阶段提交实现了精确的一次处理语义​
  • 反压(BackPressure)
    反压是分布式处理系统中经常遇到的问题，当消费者速度低于生产者的速度时，则需要消费者将信息反馈给生产者使得生产者的速度能和消费者的速度进行匹配。
    1. Storm 在处理背压问题上简单粗暴，当下游消费者速度跟不上生产者的速度时会直接通知生产者，生产者停止生产数据，这种方式的缺点是不能实现逐级反压，且调优困难。设置的消费速率过小会导致集群吞吐量低下，速率过大会导致消费者 OOM。
    2. Spark Streaming 为了实现反压这个功能，在原来的架构基础上构造了一个“速率控制器”，这个“速率控制器”会根据几个属性，如任务的结束时间、处理时长、处理消息的条数等计算一个速率。在实现控制数据的接收速率中用到了一个经典的算法，即“PID 算法”。
    3. Flink 没有使用任何复杂的机制来解决反压问题，Flink 在数据传输过程中使用了分布式阻塞队列。我们知道在一个阻塞队列中，当队列满了以后发送者会被天然阻塞住，这种阻塞功能相当于给这个阻塞队列提供了反压的能力。