[大数据]Flink知识栈总结

一Flink基本介绍

• 背景

• 在flink之前也出现了很多流数据处理引擎，包括storm、sparkstreaming等知名流行框架，但各自均有较明显的不足，导致没有达到理想的流处理引擎的标准要求。

• 如何快速响应和处理这些大规模的实时数据流，成为众多互联网大厂的当务之急
  优秀流处理引擎标准要求

• 低延迟、高吞吐量、容错性、窗口时间语义化、编程效率高与运行效果好的用户体验等主要方面。
  storm
  优点：低延迟
  缺点：其它要求都较差一些

  sparkstreaming
  优点：高吞吐量、容错性高
  缺点：其它要求都较差一些

2. 概念

• 由Apache软件基金会开发的开源流处理框架
  其核心是用Java和Scala编写的框架和分布式处理引擎 用于对无界和有界数据流进行有状态计算。
  *
• 无界数据流: 即为实时流数据

• 有界数据流：即为离线数据，也称为批处理数据

3. 代码实现

• 实现方式： Java API Scala API
• 统一数据处理过程抽象
  将实时和批处理的数据过程，均抽象成三个过程，即
  1 Source->Transform->Sink
  Source为源数据读入，即Source算子。
  2 Transform是数据转换处理过程，即Transform算子。
  3 Sink即数据接收器，即数据落地到存储层，即Sink算子。

4. 应用场景

• 事件驱动型应用
• 数据分析型应用
• 数据管道 ETL
  实际情况要求严格的实时流处理场景

二Flink架构设计与运行流程

分层设计说明(相关术语解释）
一 物理部署层-deploy层

• 负责解决Flink的部署模式问题，
• 支持多种部署模式：本地部署、集群部署（Standalone/Yarn/Mesos）、云（GCE/EC2）以及kubernetes。
• 通过该层支持不同平台的部署，用户可以根据自身场景和需求选择使用对应的部署模式。

二 Runtime核心层

• 是Flink分布式计算框架的核心实现层，负责对上层不同接口提供基础服务。支持分布式Stream作业的执行、JobGraph到ExecutionGraph的映射转换以及任务调度等。

• 将DataStream和DataSet转成统一的可执行的Task
  Operator，达到在流式计算引擎下同时处理批量计算和流式计算的目的。

三 API & Libraries层

• 负责更好的开发用户体验，包括易用性、开发效率、执行效率、状态管理等方面。
  Flink同时提供了支撑流计算和批处理的接口，同时在这基础上抽象出不同的应用类型的组件库，如：
• 基于流处理的CEP（复杂事件处理库） Table & Sql库
• 基于批处理的FlinkML（机器学习库） 图处理库(Gelly)
• API层包括两部分
  • 流计算应用的DataStream API
  • 批处理应用的DataSet API

统一的API，方便用于直接操作状态和时间等底层数据提供了丰富的数据处理高级API，例如Map、FllatMap操作等，并提供了比较低级的Process Function API

运行模式

session模式（Flink Session 集群(会话模式)）

• 运行过程：一个机器启动一个进程的多线程来模拟分布式计算。主要用于代码测试

• 集群生命周期*：
  在 Flink Session 集群中，客户端连接到一个预先存在的、长期运行的集群，该集群可以接受多个作业提交。即使所有作业完成后，集群（和 JobManager）仍将继续运行直到手动停止 session 为止。因此，Flink Session 集群的寿命不受任何 Flink 作业寿命的约束。

• 资源隔离：
  TaskManager slot 由 ResourceManager 在提交作业时分配，并在作业完成时释放。由于所有作业都共享同一集群，因此在集群资源方面存在一些竞争 — 例如提交工作阶段的网络带宽。此共享设置的局限性在于，如果 TaskManager 崩溃，则在此 TaskManager 上运行 task 的所有作业都将失败；再比如，如果 JobManager 上发生一些致命错误，它将影响集群中正在运行的所有作业。

• 其他注意事项：
  拥有一个预先存在的集群可以节省大量时间申请资源和启动 TaskManager。有种场景很重要，作业执行时间短并且启动时间长会对端到端的用户体验产生负面的影响 — 就像对简短查询的交互式分析一样，希望作业可以使用现有资源快速执行计算。Flink Session 集群也被称为 session 模式下的 Flink 集群。
  

• 多个不同的FlinkJob向同一个Flink Session会话上提交作业，由这一个统一个的FlinkSession管理所有的Flink作业。

per-job模式

• 运行过程：完全独立的Flink集群的模式，各个环节均Flink自己搞定。并没有yarn、mesos的统一资源调度平台。主要是只有纯Flink纯计算的场景。

  • 集群生命周期：
    在 Flink Job 集群中，可用的集群管理器（例如 YARN）用于为每个提交的作业启动一个集群，并且该集群仅可用于该作业。在这里客户端首先从集群管理器请求资源启动 JobManager，然后将作业提交给在这个进程中运行的 Dispatcher。然后根据作业的资源请求惰性的分配 TaskManager。一旦作业完成，Flink Job 集群将被拆除。
  • 资源隔离：
  • JobManager 中的致命错误仅影响在 Flink Job 集群中运行的一个作业。在 Flink Application 集群中，ResourceManager 和 Dispatcher 作用于单个的 Flink 应用程序，相比于 Flink Session 集群，它提供了更好的隔离。
    

application模式

-

• JobManager

JobManager 具有许多与协调 Flink 应用程序的分布式执行有关的职责：它决定何时调度下一个 task（或一组 task）、对完成的 task 或执行失败做出反应、协调 checkpoint、并且协调从失败中恢复等等。这个进程由三个不同的组件组成：

• ResourceManager

ResourceManager 负责 Flink 集群中的资源提供、回收、分配 - 它管理 task slots，这是 Flink 集群中资源调度的最小单位。Flink 为不同的环境和资源提供者（例如 YARN、Mesos、Kubernetes 和 standalone 部署）实现了对应的 ResourceManager。在 standalone 设置中，ResourceManager 只能分配可用 TaskManager 的 slots，而不能自行启动新的 TaskManager。
*

• Dispatcher

Dispatcher 提供了一个 REST 接口，用来提交 Flink 应用程序执行，并为每个提交的作业启动一个新的 JobMaster。它还运行 Flink WebUI 用来提供作业执行信息。

• JobMaster

JobMaster 负责管理单个JobGraph的执行。Flink 集群中可以同时运行多个作业，每个作业都有自己的 JobMaster。
*
始终至少有一个 JobManager。高可用（HA）设置中可能有多个 JobManager，其中一个始终是 leader，其他的则是 standby。

• TaskManager

TaskManager（也称为 worker）执行作业流的 task，并且缓存和交换数据流。
必须始终至少有一个 TaskManager。在 TaskManager 中资源调度的最小单位是 task slot。TaskManager 中 task slot 的数量表示并发处理 task 的数量。请注意一个 task slot 中可以执行多个算子。

运行模式总结

应用场景总结

• 本地布署模式：demo、代码测试场景。
• Session模式：集群资源充分、频繁任务提交、小作业居多、实时性要求高的场景。(该模式较少）
• Per-Job模式：作业少、大作业、实时性要求低的场景
• Application模式：实时性要求不太高、安全性有一定要求均可以使用，普遍适用性最强。
• 生产环境使用说明 一般建议用per-job或是application模式，提供了更好的资源隔离性和安全性。

三Flink经典实战案例与分析