ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

Flink-core小总结

2022-07-29 01:01:56  阅读:156  来源: 互联网

标签:总结 core Flink 窗口 flink checkpoint task 计算 数据


Flink-core小总结

1. 实时计算和离线计算

1.1 离线计算

  • 离线计算的处理数据是固定的
  • 离线计算是有延时的,T+1
  • 离线计算是数据处理完输出结果,只是输出最终结果
  • 离线计算相对可以处理复杂的计算

1.2 实时计算

  • 实时计算是实时的处理数据,数据从流入到计算出结果延迟低
  • 实时计算是输出连续的结果
  • 做的计算相对来讲比较简单

1.3 数据时效性越高,价值就越高

2. flink和sparkstreaming

2.1sprk streaming

  • 微批处理,一次处理少量的数据
  • 时间驱动,每隔一段时间计算一次
  • 底层是MapReduce模型,现执行map端,后执行reduce端,优点就是可以在map端做预聚合,缺点就是延迟高
  • 粗粒度的资源调度
  • 实时处理,每一条数据处理一次
  • 事件驱动,每条数据处理一次
  • 底层是持续流模型,上游task和下游task同时启动一起运行,等待数据流入
  • 粗粒度资源调度
  • flink的功能更强大,窗口,事件时间,状态,sql api,cep

3. flink代码

3.1 source

读取文件,读取socket,基于集合,自定义source(SourceFunction|KafkaSource),kafkaSource

3.2 transformation算子

map,flatmap.filter,union,key

  1. 可以用于DataStream
  2. 可以用于keyBy之后,可以对于同一个可key的数据做处理
  3. 可以用于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资源调度框架,不需要搞两个资源调度框架
  • 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. 事件时间

  1. 数据中自带了一个时间
  2. 使用数据中的时间字段进行计算,可以反应数据真实发生的情况
  3. 使用事件时间存在乱序的解决办法: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机制

    1. acks=0, 生产者只负责生产数据,不管kafka是否保存成功, 会丢失数据,生产效率高

    2. acks=1 (默认),生产者会等待第一个副本数据保存成功,再返回数据发生成功,如果这个时间第-个副本所在的节点挂了,会导致数据丢失

    3. acks=-1, 生产者需要等待所有的副本数据都保存成功才返回成功,不会丢失数据,效率低

      事务

    11.2 flink消费端

    • flink会将kafka的消费偏移量和中间计算结果保存在状态中,如果任务执行失败,可以恢复,在进行聚合计算的情况下,可以保证数据的最终一致性
    • 如果作数据的清洗过滤,会出现重复的数据
    • 为了解决清洗过滤任务中的出现数据重复出现的问题,flink在sink到Kafka的时候可以开启事务
    • 在上次checkpoint完成之后开启事务,在一次checkpoint完成之后提交事务,事务未提交不会出现重复
    • 但是会增加数据的延迟

标签:总结,core,Flink,窗口,flink,checkpoint,task,计算,数据
来源: https://www.cnblogs.com/atao-BigData/p/16530848.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有