Flink-core小总结
作者：互联网
Flink-core小总结
1. 实时计算和离线计算
1.1 离线计算
- 离线计算的处理数据是固定的
- 离线计算是有延时的，T+1
- 离线计算是数据处理完输出结果，只是输出最终结果
- 离线计算相对可以处理复杂的计算
1.2 实时计算
- 实时计算是实时的处理数据，数据从流入到计算出结果延迟低
- 实时计算是输出连续的结果
- 做的计算相对来讲比较简单
1.3 数据时效性越高，价值就越高
2. flink和sparkstreaming
2.1sprk streaming
- 微批处理，一次处理少量的数据
- 时间驱动，每隔一段时间计算一次
- 底层是MapReduce模型，现执行map端，后执行reduce端，优点就是可以在map端做预聚合，缺点就是延迟高
- 粗粒度的资源调度
flink
- 实时处理，每一条数据处理一次
- 事件驱动，每条数据处理一次
- 底层是持续流模型，上游task和下游task同时启动一起运行，等待数据流入
- 粗粒度资源调度
- flink的功能更强大，窗口，事件时间，状态，sql api,cep
3. flink代码
3.1 source
读取文件，读取socket，基于集合，自定义source（SourceFunction|KafkaSource），kafkaSource
3.2 transformation算子
map,flatmap.filter,union,key
- 可以用于DataStream
- 可以用于keyBy之后，可以对于同一个可key的数据做处理
- 可以用于window之后，可以对一个窗口内地数据做处理
3.3 sink
print,写入文件，写入socket（测试），自定义sink(SinkFunction,Rich function),kafkaSink
4. 架构
4.1 jobManager
- 将task发送到taskmanager中执行
- 监控taskmanager的状态，task的状态
- 定时触发任务的checkpoint
4.2 taskManager
- 执行task
- 将数据发送到下游的task
- 构建数据流程图，将任务提交到jobManager中
5. 环境搭建
5.1 local
5.2 独立集群
- 为flink搭建一个独立的集群，和hadoop没关系，但是公司中一般已经有了yarn资源调度框架，不需要搞两个资源调度框架
5.3 flink on yarn
-
application-为每一个任务单独在yarn中启动一个flink的集群（jobmanager,taskmanager）,数据流程图在jobmanager中构建
-
per job-为每个任务单独在yarn中启动一个flink集群（jobmanager,taskmanager）,数据流程图在本地中构建
在提交到jobmanager
-
yarn session-现在yarn集群中启动一个flink的集群（jobmanager）,所有的使用session模式提交的任务共用一个jobmanager，但是任务之间会有影响，一般用于测试。在提交任务的时候在动态的申请taskmanager，任务结束后就会释放taskmanager。提交方式：页面提交，命令行提交，远程rpc提交
6. 并行度
6.1 共享资源
- flink不是每一个task占用一个资源，而是一个并行度占用一个资源
- 上游和下游的task可以共享一个slot
6.2 并行度的设置
- 每一个算子单独设置，优先级最高
- 在env中统一设置
- 提交任务的时候试着，优先级最低（推荐使用）
7. 事件时间
- 数据中自带了一个时间
- 使用数据中的时间字段进行计算，可以反应数据真实发生的情况
- 使用事件时间存在乱序的解决办法：flink通过将水位线前移，避免数据乱序导致数据丢失
8. 窗口
8.1 时间窗口
- 滑动的处理时间窗口
- 滑动的事件时间窗口
- 滚动的处理时间窗口
- 滚动的事件时间窗口
8.2 会话窗口
- 处理时间的会话时间窗口
- 事件时间的的会话时间窗口
8.3 统计窗口
- 滑动的统计窗口
- 滚动的统计窗口
9. checkpoint
checkpoint时flink的容错机制
flink通过checkpoint将计算过程的状态持久化到外部系统中，如果任务执行失败，可以从checkpoint的位置恢复保证数据的完整性
checkpoint流程：
- Jobmanager会定时的向source task 发送trigger
- source task 在数据流中安插barrier
- source task 将barrier 向下游传递，同时自己会同步做快照，并异步将状态持久化到hdfs中
- 将下游task收到上游所有的实例的barrier后就会作快照
- 当所有的task处理完同一次的checkpoint之后，一次checkpoint完成
- jobmanager会删除掉旧的checkpoint文件，保留最新的
10. state状态
可以理解为flink计算过程中产生的中间结果
- valueState
- listState
- mapState
- reducingState aggState
状态会被checkpoint持久滑倒hdfs中，如果任务执行失败，还可以挥复
11. exactly once
11.1 kafka端
-
kafka的副本机制，每一个分区有多个副本，可以保证数据不会丢失
-
生产者的等幂性，同一条数据由于各种原因重试多次，不会导致数据的重复
-
ack机制
-
acks=0, 生产者只负责生产数据，不管kafka是否保存成功， 会丢失数据，生产效率高
-
acks=1 (默认)，生产者会等待第一个副本数据保存成功，再返回数据发生成功，如果这个时间第-个副本所在的节点挂了，会导致数据丢失
-
acks=-1, 生产者需要等待所有的副本数据都保存成功才返回成功，不会丢失数据，效率低
事务
11.2 flink消费端
- flink会将kafka的消费偏移量和中间计算结果保存在状态中，如果任务执行失败，可以恢复，在进行聚合计算的情况下，可以保证数据的最终一致性
- 如果作数据的清洗过滤，会出现重复的数据
11.3 flink sink端
- 为了解决清洗过滤任务中的出现数据重复出现的问题，flink在sink到Kafka的时候可以开启事务
- 在上次checkpoint完成之后开启事务，在一次checkpoint完成之后提交事务，事务未提交不会出现重复
- 但是会增加数据的延迟
-
标签：总结,core,Flink,窗口,flink,checkpoint,task,计算,数据 来源： https://www.cnblogs.com/atao-BigData/p/16530848.html