flink checkpoint 重启_Flink 批处理Api 0428

本文介绍了Flink批处理Api,特别是Source部分,详细阐述了Flink如何通过checkpoint实现exactly-once语义。文章提及Flink的预提交和确认提交机制,并讨论了StateBackend在内存和文件系统中的应用。同时,对比了Flink与Spark处理有状态数据的不同策略,并分析了Kafka的自动提交设置对处理流程的影响。最后,文章展示了map操作在Flink数据转换中的应用。
摘要由CSDN通过智能技术生成

c31872042bba47782d0e33fa6b8c41fb.png

Flink 批处理Api

2.1 Source

Flink+kafka是如何实现exactly-once语义的

  Flink通过checkpoint来保存数据是否处理完成的状态;

  有JobManager协调各个TaskManager进行checkpoint存储,checkpoint保存在 StateBackend中,默认StateBackend是内存级的,也可以改为文件级的进行持久化保存。

执行过程实际上是一个两段式提交,每个算子执行完成,会进行“预提交”,直到执行完sink操作,会发起“确认提交”,如果执行失败,预提交会放弃掉。

如果宕机需要通过StateBackend进行恢复,只能恢复所有确认提交的操作。

9582a71ac04b8431274940e4341884ad.png

Spark中要想实现有状态的,需要使用updateBykey或者借助redis;

而Fink是把它记录在State Bachend,只要是经过key

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值