点一下关注吧！！！非常感谢！！持续更新！！！

目前已经更新到了：

• Hadoop（已更完）
• HDFS（已更完）
• MapReduce（已更完）
• Hive（已更完）
• Flume（已更完）
• Sqoop（已更完）
• Zookeeper（已更完）
• HBase（已更完）
• Redis （已更完）
• Kafka（已更完）
• Spark（已更完）
• Flink（正在更新！）

终于到了Flink！

章节内容

上节完成了如下的内容：

• Spark GraphX 注意事项
• Spark GraphX 开发过程
• Spark GraphX 案例

官方网站

https://flink.apache.org/

什么是Flink

Apache Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算，Flink被设计在所有常见的集群环境中运行，以内存执行速度和任意规模来执行计算。

• Flink起源于2008年柏林大学的研究性项目 Stratosphere
• 2014年该项目被捐赠给了Apache软件基金会
• Flink一跃成为Apache软件基金会的顶级项目之一

在德语中，Flink一次表示快速和灵巧，项目采用一只松鼠的彩色图案作为LOGO，这不仅仅是因为松鼠具有快速和灵巧的特点，还因为柏林的松鼠有一种迷人的红棕色，而Flink的松鼠LOGO拥有可爱的尾巴，尾巴的颜色和Apache软件基金会的LOGO颜色相呼应，也就是说，这是一只Apache风格的松鼠。

Flink特点

Flink是一个开源的批处理框架，它具有以下特点：

• 批流一体：统一批处理、流处理
• 分布式：Flink程序可以运行在多个服务器上
• 高性能：处理性能比较高
• 高可用：Flink支持高可用性（HA）
• 准确：Flink可以保证数据处理的准确性

Flink场景

Flink主要用于流式数据分析场景，数据无处不在，绝大多数的企业采取的处理数据的框架都会划分为两类：

• 事务型处理
• 分析性处理

事务型处理

• OLTP：On-Line Transaction Processing 联机事务处理过程
  流程审批、数据录入、填报等
  特点：线下工作线上化，数据保存在各自的系统中，互不相通（数据孤岛）

OLTP联机事务处理系统以事务元作为数据处理的单位、人机交互的计算机应用系统。它能对数据进行即时更新或其他操作，系统内的数据总是保持在最新状态。
用户可以将一组保持数据一致性的操作序列指定为一个事务元，通过终端、个人计算机或其他设备输入事务元，经系统处理后返回结果。

OLTP主要用于记录某类业务事件的发生，如购买行为，当行为产生后，系统会记录是谁在何时何地做何事，这样的一行或者多行数据会以增删改查的方式在数据库中进行数据的更新处理操作，要求实时性高、稳定性强、确保数据及时更新成功。

应用主要在：

• 飞机订票
• 股票交易
• 超市销售
• 饭店前后台管理等等

常见的：ERP、CRM、OA等系统都属于 OLTP 系统。

在这个期间，每处理一条事件，应用都会通过执行远程数据库系统的事务来读取或更新状态。很多时候，多个应用会共享同一个数据库系统，有时候还会访问相同的数据库或表。
该设计在应用需要更新或数据库扩容或表模式修改时会容易导致问题。

分析型处理

当数据积累到一定的程度，我们需要对过去发生的事情做一个总结分析时，就需要把过去一段时间内产生的数据拿出来进行统计分析，从中获取我们想要的信息，为公司做决策提供支持，这时候就是在做OLAP了。
因为OLTP所产生的业务数据分散在不同的业务系统中，而OLAP往往需要将不同的业务数据集中到一起进行统一综合的分析，这时候就需要根据业务分析需求做对应的数据清洗后存储在数据仓库中，然后由数据仓库来统一提供OLAP分析
OLAP On-Line Analytical Processing：联机分析系统：

• 分析报表
• 分析决策
• 等等

根据业务分析需求做对应的数据清洗后存储在数据仓库中称为ETL（Extract-Transform-Load）：从事务型数据中提取数据，将其转换为通用的表示形式（可能包含数据验证、数据归一化、编码、去重、表模式转换等工作），最终加载到分析型数据库中。

如上图所示，数据实时写入HBase，实时的数据更新也在HBase完成，为了应对OLAP需求，我们定时（通常T+1或者T+H）将HBase数据写成静态的文件（如：Perquet）导入到OLAP引擎（如：HDFS，比较常见的是Impala操作Hive），这一架构能满足既需要随机读写，又可以支持OLAP分析的场景，但他有如下缺点：

• 架构复杂，从架构上看，数据在HBase、消息队列、HDFS间流转，涉及环节太多，运维成本很高。并且每个环节需要保证高可用，都需要维护多个副本，存储空间也有一定的浪费，最后数据在多个系统上，对数据安全策略，监控都提出了挑战。
• 时效低，数据从HBase导出成静态文件是周期性的，一般这个周期是一天（或一小时），在时效性上不是很高。
• 难以应对后续的更新，真实场景中，总会有数据【延迟】到达的，如果这些数据之前已经从HBase导出到HDFS，新到的变更数据就难以处理了，一个方案是把原有数据应用上新的变更后重写一遍，但这代价又很高。

通常数据仓库中的查询可以分为两类：

• 普通查询：是定制的
• 即系查询：是用户自定义查询条件的

• 实时ETL：集成流计算现有的诸多数据通道和SQL灵活的加工能力，对流式数据进行实时清洗，归并和结构化处理，同时，对离线数仓进行有效的补充和优化，并为数据实时传输提供可计算通道
• 实时报表：实时化采集、加工流式数据存储，实时监控和展现业务，客户各类指标，让数据化运营实时化。如通过分析订单处理系统中的数据获知销售增长率。通过分析运输延迟原因或预测销售量调整库存。
• 监控预警：对系统和用户行为进行实时监测和分析，以便及时发现危险行为，如果计算机网络入侵、诈骗预警等
• 在线系统：实时计算各类数据指标，并利用实时结果及时调整在线系统的相关策略，在各类内容投放、智能推送领域有大量的应用，如在客户浏览商品的同时推荐相关的商品

Flink 核心组成

Deploy层

• 可以启动单个JVM，让Flink以Local模式运行
• Flink也可以以Standalone集群模式运行，同时支持FlinkOnYRAN，Flink应用直接提交到YRAN上面运行
• Flink还可以运行在谷歌云服务和亚马逊云服务

Core层

在Runtime之上提供了两套核心的API

• DataStreamAPI（流处理）
• DataSet API（批处理）

APIs & Libraries 层

核心API上又扩展了一些高阶的库和API

• CEP流处理
• Table API 和 SQL
• Flink ML机器学习库
• Celly 图计算

Flink 生态发展

• 中间部分主要内容在Flink核心组成中已经提到
• 输入 Connectors （左侧部分）：1.流式处理中包含Kafka（消息队列）、AWS Kinesis（实时数据流服务）、RabbitMQ（消息队列）、NIFI（数据管道）、Cassandra（NoSQL数据库）、Elasticsearch（全文检索）、HDFS（滚动文件）2.批处理方式：包含HBase（分布式列式数据库）、HDFS（分布式文件系统）

Flink处理模型

Flink 流处理与批处理，Flink专注于无限流处理，有限流处理是无限流处理的一种特殊情况。

无限流处理

• 输入的数据没有尽头，像水流一样源源不断
• 数据处理从当前或者过去的某一个时间点开始，持续不停地进行

有限流处理

• 从某一个时间点开始处理数据，然后在另一个时间点结束
• 输入数据可能本身是有限的（即输入数据集并不会随着时间的增长），也可能出于分析的目的被人为设定为有限集（即只分析某一个时间段内的事件）

Flink封装了DataStreamAPI进行流处理，封装了DataSetAPI进行批处理。同时，Flink是一个批流一体的处理引擎，提供了TableAPI/SQL统一批处理和流处理。

流处理引擎的技术选型

市面上的流处理引擎不止Flink一种，其他的Storm、SparkStreaming、Trident等，实际应用如何进行选型，给大家一些建议参考：

• 流数据要进行状态管理，选择使用 Trident、SparkStreaming或者Flink
• 消息投递需要保证At-least-once（至少一次）或者 Exactly-once（仅一次）不能选择Storm
• 对于小型独立项目，有低延迟要求，可以选择使用Storm，更简单
• 如果项目已引入大框架Spark，实时处理需求可以满足的话，建议直接使用Spark中的SparkStreaming
• 消息投递要满足Exactly-once （仅一次），数据量大、有高吞吐、低延迟要求、要进行状态管理或者窗口统计，建议使用Flink

架构组件

JobManager（作业管理器）

JobManager 是 Flink 集群的核心控制组件，负责整个数据流处理作业的生命周期管理。它的主要职责包括：

• 任务调度：JobManager 负责将用户提交的作业划分为多个任务，并调度这些任务到不同的 TaskManager 执行。
• 资源管理：它与资源管理系统（如 YARN 或 Kubernetes）进行交互，以分配和管理作业执行所需的资源。
• 故障恢复：当作业中的某个任务失败时，JobManager 负责重新调度该任务并从故障点恢复执行，以确保作业的持续进行。
• 协调点（Checkpointing）：JobManager 负责协调 Flink 的容错机制，通过管理 Checkpointing 来保证作业的状态一致性。

TaskManager（任务管理器）

TaskManager 是 Flink 集群中的工作节点，负责执行由 JobManager 分配的具体任务。它的职责包括：

• 任务执行：TaskManager 接受 JobManager 分配的任务，并执行这些任务。每个 TaskManager 可以同时执行多个任务实例，利用多线程技术提高处理效率。
• 状态管理：在有状态流处理应用中，TaskManager 负责管理任务的本地状态。当进行 Checkpoint 时，TaskManager 会将任务的状态保存到分布式存储中。
• 数据传输：TaskManager 负责在不同任务之间传输数据。这些数据可以通过网络在不同的 TaskManager 之间进行传输，也可以在同一个 TaskManager 内的不同任务实例之间进行数据交换。

Dispatcher（调度器）

Dispatcher 是一个相对较新的组件，它的主要职责是处理客户端提交的作业，并将这些作业分配给集群中的 JobManager 进行处理。Dispatcher 也管理 Flink 集群的 REST API，允许用户通过 HTTP 接口提交作业、查询状态、取消作业等操作。

ResourceManager（资源管理器）

ResourceManager 负责与集群管理器（如 YARN、Kubernetes、Standalone 等）交互，管理 Flink 作业所需的资源。它的主要职责包括：

• 资源分配：ResourceManager 接收 JobManager 的资源请求，并在集群管理器中申请相应的计算资源，如 TaskManager 容器或进程。
• TaskManager 启动：一旦资源被分配，ResourceManager 会启动新的 TaskManager 实例来执行任务。

Client（客户端）

客户端是用户与 Flink 集群交互的入口。用户通过客户端提交作业到 Dispatcher，客户端负责将用户的作业打包，并通过 REST API 传递给 Dispatcher。客户端还可以用来监控作业执行状态、收集执行结果和错误信息。

Flink Runtime（Flink 运行时）

Flink Runtime 是 Flink 核心数据处理引擎所在的地方。它负责处理数据流、执行用户定义的操作（如 map、reduce、filter 等）、管理状态和执行 Checkpointing。Flink Runtime 的运行环境高度并行化，能够充分利用集群中的计算资源，处理大量的数据流或批数据。

State Backend（状态后端）

State Backend 是 Flink 中用来存储任务状态的模块。有两种主要的状态后端：

内存状态后端：将状态存储在 TaskManager 的内存中，适用于小规模的、对容错要求不高的作业。
RocksDB 状态后端：将状态存储在嵌入式的 RocksDB 数据库中，并支持将状态持久化到分布式文件系统，如 HDFS。适用于大规模、有状态的流处理应用。

Checkpointing 和 Savepoints

Flink 提供了 Checkpointing 和 Savepoints 两种机制来实现容错：

• Checkpointing：定期将任务的状态保存到分布式存储中，以确保在故障时可以从最近的检查点恢复。
• Savepoints：用户触发的状态快照，可以在程序升级或重新部署时使用。

Data Stream 和 Data Set API

• DataStream API：用于流处理，支持无界和有界数据流，提供丰富的操作符和窗口机制。
• DataSet API：用于批处理，支持有界数据集处理，提供了类似 SQL 的操作符。

Execution Graph（执行图）

当一个 Flink 作业被提交时，它会被转化为一个执行图（Execution Graph）。执行图描述了作业中的各个任务及其之间的依赖关系。JobManager 根据执行图来调度任务，并协调各个 TaskManager 之间的数据传输。