【Flink---01】Flink概述

ElegantCodingWH

已于 2023-06-28 10:52:20 修改

阅读量122

点赞数

分类专栏： # Flink 文章标签： fink

于 2022-12-26 21:37:57 首次发布

本文链接：https://blog.csdn.net/qq_43546676/article/details/128449780

版权

Flink 专栏收录该内容

7 篇文章 2 订阅

订阅专栏

文章目录

1. Flink是什么？
2 Flink在大数据架构中的位置
3. Flink的特性
4. Flink的API
5. Flink的应用
6. Flink vs Spark

1. Flink是什么？

Apache Flink 是一个框架和 分布式处理引擎。
核心目标：用于在有边界和无边界数据流上进行有状态的计算。
- 关于处理引擎：
  1. 处理引擎：用于数据处理，常见的计算引擎有 Hadoop MR、Spark、Flink等。引擎就是发动机，发动机需要资源才能工作，所以处理引擎需要跑在yarn等资源管理器上才能进行计算。
  2. 消息队列：用于数据采集，如 Flume、kafka等
  3. 存储系统：用于存储数据，如 Mysql、HDFS、Redis等
- 关于有边界和无边界的数据流：
  1. 无边界的数据流：有定义流的开始，但没有定义流的结束。 即实时数据
    1. 特点：它们会无休止地产生数据，因此数据被摄取后需要立刻处理。我们不能等到所有数据都到达再处理，因为输入是无限的。
    2. 处理：处理无界数据通常要求以特定顺序摄取事件，例如事件发生的顺序，以便能够推断结果的完整性。
  2. 有边界的数据流：有定义流的开始，也有定义流的结束。 即离线数据
    1. 特点：有界流可以在摄取所有数据后再进行计算。
    2. 处理：有界流所有数据可以被排序，所以并不需要有序摄取。

2 Flink在大数据架构中的位置

Flink在大数据架构中的位置如下：
在这里插入图片描述

3. Flink的特性

高吞吐、低延迟。 每秒处理数百万个事件，毫秒级延迟
结果的准确性。 Flink提供了事件时间(event-time)和处理时间(processing-time)语义，对于乱序事件流，事件时间语义仍然能提供准确的结果。
Flink 能在所有常见集群环境中运行，且将作业迁移到不同的集群上时应用程序状态不会丢失，比如Hadoop yarn、 Kubernetes（k8s）、stand-alone等
高可用。 Flink可以做到7×24全天候运行。
有多种API可以选择
Flink是第三代流处理器，能同时做到一致性和准确性，即 精准一次(exactlu-once) 的状态一致性。
- 第一代流处理器：能够进行实时流数据处理，因此保证了实时性，但是没有批处理准确
- 第二代流处理器：采用Lambda架构，在使用流处理器保证实时性，同时使用批处理器辅助保证准确性。比如Spark的实时数据处理就采用了Lambda架构
- 第三代流处理器：采用万物皆可流的思想，将批处理看做是有界的流处理。因此只使用流处理器就能保证实时性和准确性。

4. Flink的API

Flink 为流式/批式处理应用程序的开发提供了不同级别的抽象。越往上自由度越低，能组合实现的功能越少，但是实现某功能的代码越简单。
在这里插入图片描述

用的较多的是DataStream API 和 SQL API。前者能够进行流批一条，即一套代码既可以处理有界的流数据也可以处理无界的流数据；后者是写SQL代码，最简单。
关于 流批一体：原本DataStream API用于流处理，DataSet API用于批处理。事实上 Flink 的思想是万物皆可流，将批处理数据集看做是有界的数据流，因此没有必要用两套不同的 API 来实现。所以从 Flink 1.12 开始，官方推荐的做法批处理也使用 DataStream API，但是默认情况下是无界流处理，如果要使用有界流处理该如何配置？
方式一：只需要在提交任务时将执行模式设为 BATCH即可：（推荐使用，更加灵活）
$ bin/flink run -Dexecution.runtime-mode=BATCH BatchWordCount.jar
方式二：在代码中配置：（不推荐使用，不够灵活，一般用于测试）
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
env.setRuntimeMode(RuntimeExecutionMode.BATCH);
这样，DataSet API就处于弃用状态，流和批都采用 DataStream API 就可以了，即流批一体。
什么时候选择 BATCH 模式？
STREAMING 执行模式对于有界数据和无界数据都是有效的；而 BATCH模式仅能用于有界数据。看起来 BATCH 模式似乎被 STREAMING 模式全覆盖了，那还有必要存在吗？我们能不能所有情况下都用流处理模式呢？
批处理和流处理输出的不同：在 STREAMING模式下，每来一条数据，就会输出一次结果（即使输入数据是有界的）；而 BATCH 模式下，只有数据全部处理完之后，才会一次性输出结果。最终的结果两者是一致的，但是流处理模式会将更多的中间结果输出。在本来输入有界、只希望通过批处理得到最终的结果的场景下，STREAMING 模式的逐个输出结果就没有必要了。
所以结论是：用 BATCH 模式处理批量数据，用 STREAMING模式处理流式数据。

5. Flink的应用

行业应用：对于流式框架Flink，数据来到之后就会被即刻处理，所以流处理的一大特点就是“快速”，也就是良好的实时性。因此，Flink 适合应用于需要实时处理数据流的场景。
应用场景：
1. 事件驱动型应用：以事件为单位进行处理，即来一条数据处理一条数据。就是处理实时数据
  - 优点：
    ① 事件驱动型应用无须查询远程数据库，本地数据访问使得它具有更高的吞吐和更低的延迟。
    ② 传统分层架构下，通常多个应用会共享同一个数据库，因而任何对数据库自身的更改需要谨慎协调；而事件驱动型应用，由于只需考虑自身数据，因此在更改数据表示或服务扩容时所需的协调工作将大大减少。
    - 传统的事务处理：使用外部数据库进行中间结果的保存
    - 流数据(有界或无界)的有状态处理：中间结果保存在本地内存中
2. 数据分析型应用：以一批事件为单位进行处理。就是处理离线数据
  - 优点：
    ① 和批量分析相比，由于流式分析省掉了周期性的数据导入和查询过程，因此从事件中获取指标的延迟更低。不仅如此，批量查询必须处理那些由定期导入和输入有界性导致的人工数据边界，而流式查询则无须考虑该问题。
    ② 另一方面，流式分析会简化应用抽象。批量查询的流水线通常由多个独立部件组成，需要周期性地调度提取数据和执行查询。如此复杂的流水线操作起来并不容易，一旦某个组件出错将会影响流水线的后续步骤。而流式分析应用整体运行在 Flink 之类的高端流处理系统之上，涵盖了从数据接入到连续结果计算的所有步骤，因此可以依赖底层引擎提供的故障恢复机制。
3. 连续数据管道应用：对数据进行ETL(提取-转换-加载)。就是数据清洗。
  - 优点：和周期性 ETL 作业相比，持续数据管道可以明显降低将数据移动到目的端的延迟。
4. 特征工程
5. 机器学习
6. 图标分析
7. 图计算
8. 容错的数据流处理

6. Flink vs Spark

相同点：都可以处理实时数据、离线数据、机器学习等
不同点：
1. 数据处理的模型不同：
  1. Flink是以流处理为出发点的，认为万物皆可流。离线数据是有界的流数据，实时数据是无界的流数据。
  2. Spark是以批处理为出发点的，认为万物皆可批。离线数据是一个大批，实时处理是由一个一个的小批组成。
2. 数据处理的方式不同：
  1. Spark是将任务对应的DAG划分为几个阶段，只有一个阶段的全部任务执行完后才能经过shuffe再进行下一阶段的计算。
  2. Flink是一个事件在一个节点处理完后就可以直接进入下一个节点进行处理。
如何选择？
1. 业务能够接受的时间范围
2. 团队的选择，对哪个技术积累的成熟