flink-1 flink简介

有界数据和无界数据

---

有界数据通常被称为批处理

• 既定义了数据流的开始，也定义了数据流的结束。
• 处理有界数据时，既可以等所有数据都接收完再处理，也可以处理此刻前的所有数据。
• 有界流数据可以被排序，所以处理的时候不需要有序的提取

无界数据

• 有数据流的开始，但是没有数据流的结束。
• 处理无界数据时，不能等到所有数据都接收完再处理，数据会无休止的产生，需要立即处理
• 无界数据处理时一般需要根据特定的顺序提取数据（如，事件发生顺序），以便能够推断结果的完整性

flink应用场景

• flink既可以处理有界数据（批处理）和无界数据，flink把批处理当做一种特殊的无界数据
• spark只能处理批处理，当数据间隔足够小时，在宏观上认为是可以处理实时数据（实际上是伪实时）
• storm可以处理实时数据，但是吞吐量小，远不如flink。

一般批处理选择spark，实时处理（设计钱的业务）选择flink。storm用的很少了

以下是一些flink应用的常见场景

在实际生产的过程中，大量数据在不断地产生，例如金融交易数据、互联网订单数据、 GPS 定位数据、传感器信号、移动终端产生的数据、通信信号数据等，以及我们熟悉的网络 流量监控、服务器产生的日志数据，这些数据最大的共同点就是实时从不同的数据源中产生， 然后再传输到下游的分析系统。针对这些数据类型主要包括实时智能推荐、复杂事件处理、 实时欺诈检测、实时数仓与 ETL 类型、流数据分析类型、实时报表类型等实时业务场景，而 Flink 对于这些类型的场景都有着非常好的支持。

flink优势

• 既可以处理有界数据也可以处理无界数据。
• 在处理数据时，每次保留数据的状态，非常容易实现exactly-once（这点优于sparkstreaming）
• 可以部署到不同平台
  • yarn
  • mesos
  • kubernetes
• 运行任意规模应用
  • 应用程序可以并行化成数千个任务，分布在集群中进行。并利用其异步和增量的检查点算法对处理延迟产生最小的影响，同时保证精确一次状态的一致性。
• 充分利用内存性能
  • 有状态的 Flink 程序针对本地状态访问进行了优化。任务的状态始终保留在内存中，如果状态大小超过可用内存，则会保存在能高效访问的磁盘数据结构中。任务通过访问本地（通常在内存中）状态来进行所有的计算，从而产生非常低的处理延迟。Flink 通过定期和异步地对本地状态进行持久化存储来保证故障场景下精确一次的状态一致性。
    

flink基本技术栈

• API & libraries层

作为分布式数据处理框架，fink同时提供了支撑流计算和批计算的接口，同时在此基础之上抽象出不同的应用类型的组件库。
如：基于流处理的CEP（复杂事件处理库）、SQL&Table库、FlinkML(机器学习库)、Gelly(图处理库)

有流式处理API，批处理API。流式处理的支持事件处理，表操作。批处理的，支持机器学习，图计算，也支持表操作。

• Runtime核心层

该层主要负责对上层的接口提供基础服务，也就是flink分布式计算的核心实现。flink底层的执行引擎。

• 物理部署层

该层主要涉及到flink的部署模式，目前flink支持多种部署模式：

• 本地 local
• 集群 standalone/yarn
• 云 GCE/EC2 谷歌云、亚马逊云
• kubenetes

flink基本架构

flink系统也遵循主从架构（Master-Slave）设计原则。整个系统主要由两部分组成：JobManager和TaskWorker

• JobManager为Master节点
• TaskWorker为Slave(Worker)节点
  所有组件之间的通信借借助于Akka Framework，包括人物的状态以及checkpoint触发信息等

---

• Client

  • 客户端负责将任务提交到集群，与JobManager构建Akka链接，然后将任务提交到JobManager，通过和JobManager之间进行交互获取任务执行状态
  • 客户端提交任务可以采用CLI 方式或者通过使用 Flink WebUI 提交，也可以在应用程序中指定 JobManager 的 RPC 网络端口构建 ExecutionEnvironment 提交 Flink 应用

• JobManager

  • JobManager 负责整个 Flink 集群任务的调度以及资源的管理，从客户端中获取提交的应用，然后根据集群中 TaskManager 上 TaskSlot 的使用情况，为提交的应用分配相应的 TaskSlot 资源并命令 TaskManager 启动从客户端中获取的应用。

  • JobManager 相当于整个集群的 Master 节点，且整个集群有且只有一个活跃的 JobManager ，负责整个集群的任务管理和资源管理。

  • JobManager 和 TaskManager 之间通过 Actor System 进行通信，获取任务执行的情况并通过 Actor System 将应用的任务执行情况发送给客户端。同时在任务执行的过程中，Flink JobManager 会触发 Checkpoint 操作，每个 TaskManager 节点 收到 Checkpoint 触发指令后，完成 Checkpoint 操作，所有的 Checkpoint 协调过程都是在 Fink JobManager 中完成。

  当任务完成后，Flink 会将任务执行的信息反馈给客户端，并且释放掉 TaskManager 中的资源以供下一次提交任务使用

• TaskManager

  • TaskManager 相当于整个集群的 Slave 节点，负责具体的任务执行和对应任务在每个节点上的资源申请和管理。客户端通过将编写好的 Flink 应用编译打包，提交到 JobManager，然后 JobManager 会根据已注册在 JobManager 中 TaskManager 的资源情况，将任务分配给有资源的 TaskManager节点，然后启动并运行任务。
  • TaskManager 从 JobManager 接收需要部署的任务，然后使用 Slot 资源启动 Task，建立数据接入的网络连接，接收数据并开始数据处理。同时 TaskManager 之间的数据交互都是通过数据流的方式进行的。
  • 可以看出，Flink 的任务运行其实是采用多线程的方式，这和 MapReduce 多 JVM 进行的方式有很大的区别，Flink 能够极大提高 CPU 使用效率，在多个任务和 Task 之间通过 TaskSlot 方式共享系统资源，每个 TaskManager 中通过管理多个 TaskSlot 资源池进行对资源进行有效管理。