介绍
Apache Flink是一款开源的、统一的流处理和批处理 框架。有着高吞吐量、低延迟的流引擎，以及对事件时间处理和状态管理的支持。Flink 应用程序在机器故障的情况下具有容错性，并支持一次性语义。
大纲
在 Flink 应用程序中，无论你的应用程序是批程序，还是流程序，都是上图这种模型，有数据源（source），有数据下游（sink），我们写的应用程序多是对数据源过来的数据做一系列操作
source 算子
- 基于集合的 Source
- 基于 Socket 网络端口的 Source
- 基于文件的 Source
- 第三方 Connector
- 自定义 Source 五种。
Operator 算子
- Map （映射）
- FlatMap （扁平化映射）
- Filter （过滤）
- KeyBy （分组）
- Reduce （归约）
- Window （时间窗口聚）
- WindowAll （不需要调用keyBy函数）
- Union （将两个或多个 格式一致数据流结合在一起）
- Window Join （通过join()合并两条，通过.where()和.equalTo()方法指定两条流中联结的 key；然后通过.window()开窗）
- Interval Join （跨窗口数据join）
- Window CoGroup (将给定key和公共窗口上的两个数据流进行协组。)
- Connect （和union差不多 不需要两个流数据一致）
- CoMap, CoFlatMap （先connect对连接流做map操作，然后返回新的流）
- Iterate (对数据流进行迭代处理，直到满足条件输出)
sink 算子
- 打印输出 print
- 文件 Sink
- connect slink
Flink 时间语义
- Processing Time、 处理被处理 的 机器的系统时间
- Event Time 指事件发生的时间，一般就是数据本身携带的时间
- Ingestion Time 注入时间 具有自动分配时间戳和自动生成水印功能
Flink Window
Window 就是用来对一个无限的流设置一个有限的集合，在有界的数据集上进行操作的一种机制。
- 以时间驱动的 Time Window
- 以事件数量驱动的 Count Window
- 以会话间隔驱动的 Session Window
- 滚动窗口（Tumbling Windows）
- 滑动窗口（Sliding Windows）
Flink WaterMark
Windows -----> Watermark -----> allowLateNess(将窗口关闭时间再延迟一段时间) -----> sideOutPut (兜底 侧流输出)
如果在进行 Window 计算操作的时候，如果使用的时间是 Processing Time，那么在 Flink
消费数据的时候，它完全不需要关心的数据本身的时间，意思也就是说不需要关心数据到底是延迟数据还是乱序数据。因为 Processing Time
只是代表数据在 Flink 被处理时的时间，这个时间是顺序的。但是如果你使用的是 Event Time
的话，那么你就不得不面临着这么个问题：事件乱序 & 事件延迟。
- 所谓 watermark，就是在事件时间语义世界观中，用于单调递增向前推进时间的一种标记；
- 它的核心机制是在数据流中周期性地插入一种时间戳单调递增的特殊数据元素（watermark）， 来不可逆转地在整个数据流中进行时间的推进；
WatermarkStrategy.forMonotonousTimestamps();//不容忍乱序WatermarkStrategy.forBoundedOutOfOrderness(Duration.ofSeconds(10));//最大事件时间-容错时间WatermarkStrategy.forGenerator(new WatermarkGenerator(){ ... } );//自定义 生成策略
Flink State
一种为了满足算子计算时需要历史数据需求的，使用 checkpoint 机制进行容错，存储在 state backend 的数据结构
对于流处理系统，数据是一条一条被处理的，如果没有对数据处理的进度进行记录，那么如果这个处理数据的 Job 因为机器问题或者其他问题而导致重启，那么它是不知道上一次处理数据是到哪个地方了，这样的情况下如果是批数据，倒是可以很好的解决（重新将这份固定的数据再执行一遍），但是流数据那就麻烦了，你根本不知道什么在 Job 挂的那个时刻数据消费到哪里了？那么你重启的话该从哪里开始重新消费呢？你可以有以下选择（因为你可能也不确定 Job 挂的具体时间）：
State 的分类如
- Keyed State、
- Operator State、
- Raw State、
- Managed State、
- Broadcast State
State 常见的后端存储方式
- MemoryStateBackend：存储在内存中
- FsStateBackend：存储在文件中
- RocksDBStateBackend：存储在 RocksDB 中
Flink CheckPoint和SavePoint
Checkpoint 在 Flink 中是一个非常重要的 Feature，Checkpoint 使 Flink 的状态具有良好的容错性，通过 Checkpoint 机制，Flink 可以对作业的状态和计算位置进行恢复。
| Checkpoint | Savepoint |
|---|---|
| 由 Flink 的 JobManager 定时自动触发并管理 | 由用户手动触发并管理 |
| 主要用于任务发生故障时，为任务提供给自动恢复机制 | 主要用户升级 Flink 版本、修改任务的逻辑代码、调整算子的并行度，且必须手动恢复 |
| 当使用 RocksDBStateBackend 时，支持增量方式对状态信息进行快照 | 仅支持全量快照 |
| Flink 任务停止后，Checkpoint 的状态快照信息默认被清除 | 一旦触发 Savepoint，状态信息就被持久化到外部存储，除非用户手动删除 |
| Checkpoint 设计目标：轻量级且尽可能快地恢复任务 | Savepoint 的生成和恢复成本会更高一些，Savepoint 更多地关注代码的可移植性和兼容任务的更改操作 |
Flink Connector
DataStream Connectors
- Apache Kafka (source/sink)
- Apache Cassandra (sink)
- Amazon Kinesis Streams (source/sink)
- Elasticsearch (sink)
- FileSystem (sink)
- RabbitMQ (source/sink)
- Google PubSub (source/sink)
- Hybrid Source (source)
- Apache NiFi (source/sink)
- Apache Pulsar (source)
- JDBC (sink)
Table & SQL Connectors
| Name | Version | Source | Sink |
|---|---|---|---|
| Filesystem | Bounded and Unbounded Scan, Lookup | Streaming Sink, Batch Sink | |
| Elasticsearch | 6.x & 7.x | Not supported | Streaming Sink, Batch Sink |
| Apache Kafka | 0.10+ | Unbounded Scan | Streaming Sink, Batch Sink |
| Amazon Kinesis Data Streams | Unbounded Scan | Streaming Sink | |
| JDBC | Bounded Scan, Lookup | Streaming Sink, Batch Sink | |
| Apache HBase | 1.4.x & 2.2.x | Bounded Scan, Lookup | Streaming Sink, Batch Sink |
| Apache Hive | Supported Versions | Unbounded Scan, Bounded Scan, Lookup | Streaming Sink, Batch Sink |
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
