flink generic log-based incremental checkpoints 设计

背景

flink 在1.15版本后开始提供generic log-based incremental checkpoints的检查点方案,目的在于减少checkpoint的耗时,尽量缩短端到端的数据处理延迟,本文就来看下这种新类型的checkpoint的设计

generic log-based incremental checkpoints 设计

generic log-based incremental checkpoints的设计主要是参考事务数据库的设计方案,总体来说就是insert、update、delete操作先记录到事务日志文件中,然后应用到DB数据文件中,通过这样的设计,相当于每时每刻状态操作都已经持久化到了事务日志中,遇到checkpoint barrier的时候也是只要确保barrier之前的修改操作已经记录到事务日志中即可,这样的话,整个checkpoint操作就会非常快,当然缺点也是显而易见,包括双写会导致状态操作的时延增加,状态的大小空间占用庞大,crash崩溃后恢复耗时增加等

相关推荐
其实防守也摸鱼10 分钟前
网安自测题:掌握核心知识点的实用练习
linux·运维·服务器·前端·数据库·sql·xss
数字化顾问10 分钟前
(142页PPT)PLM+ERP系统选型及建设方案建议书(附下载方式)
数据库
木白CPP11 分钟前
[QNX] 深入理解 Resource Manager 接口设计
linux·服务器·数据库
Shadow(⊙o⊙)16 分钟前
MySQL C/C++链接MySQL使用
数据库·sql·mysql
Mortalbreeze21 分钟前
MySQL 基础篇(五):数据操作基础 —— CRUD
linux·服务器·数据库·mysql
Shadow(⊙o⊙)23 分钟前
mysql为创建普通用户并创建库赋权
数据库·sql·mysql
Studying 开龙wu30 分钟前
CVAT 导出崩溃排查实录:一个空壳轨迹引发的连锁反应
数据库·sqlite
PaperData9 小时前
1985-2025年全国区县专利申请与授权面板数据
数据库
snpgroupcn9 小时前
大数据量SAP迁移方案:系统越大,越不能硬搬
数据库·sap
Flynt10 小时前
Redis Cluster主节点挂了,为什么"高可用"还全员掉线?我把三次kill的记录翻出来了
数据库·redis·分布式