Flink1.16新特性图文解析
前线速看
- 统一API:对比spark程序开发,flink一套应用开发即可重用在流批环境
- 统一计算:适配多种数据源,可以在streaming warehouse整体概念下计算,一套计算引擎解决多种场景计算
- 统一存储:table store不仅对flink提供存储能力,对spark外部计算引擎同样可以;同时flink也适配了各式的存储中间件
上图着重强调了中国团队对flink1.16的贡献。
sql gateway这个功能超级强大,支持多租户,协议插件化,兼容hive生态,以后flink流批作业都可以通过sql gateway提交到集群了。
上图是状态存储改进。
更快更稳更易用:Flink自适应批处理能力演进
那么具体有哪些优化呢?
1 Adaptive Batch Scheduler自动设置作业并行度
综上,上面的问题,我们都思考下,怎么解决?
那么自适应批量调度
2 Speculative Execution 发现和缓解热点机器对作业的影响
从上面 现状和问题,可以看到下面的图片flink批处理推出了推测执行,这也是flink1.16新推出的机制。
下面的推测执行在flink框架层面的执行范围,目前知道的是sink层面是不支持推测机制;如果自定义source事件,SplitEnumerator需要实现SupportsHandleExecutionAttemptSourceEvent接口
下图中是推测执行的web ui,后续会支持sink推测执行。
3 Hybrid Shuffle 提供资源利用率和数据传输率
那么怎么集合流和批两种的优势呢,其实就是怎样结合流的快和批的稳定,Hybrid Shufle应运而生
Hybrid Shuffle的目标时 具备资源自适应的能力,资源充足时,直接流式shuffle,资源不足时,又具备批量shuffle的稳定性,用户完全无感。
Hybrid Shuffle提供了两种落盘策略,从上图中可以看出,性能是有提升,但是提升有限,期待后面有质的飞跃。
4 Dynamic Partition Pruning 过滤无用数据,提高处理效率
从上图中可以看出DynmaicFilter DataCollector左边和右边的scan是没有依赖关系的,OrderEnforcer就是建立两者之间的依赖关系,仅是为了runtime调度器他们之前是有数据依赖的,从而确保调度先后顺序是没毛病的。
Flink 1.16 Preview: Hive SQL如何平迁到Flink SQL
1 迁移的动机
为什么Flink要做hive sql迁移?
离线用户吸引离线数仓用户,打磨批引擎,螺旋迭代;离线业务开发门槛降低用户flink开发离线业务的门槛;hive生态工具生态是最高的壁垒,融入离线生态;流批一体 推动业界,先统一殷勤,后统一API。
2 迁移的挑战
3 如何迁移
复用hive语法
hivesql到hive parser 再到flink relnode做了大量的工作,目的为了更好的与flinksql引擎的兼容。
hive语法兼容:Flink1.16 hive语法兼容度从85%提升至94.1%(Hive qtest 12k测试集)。
hivesql 迁移在快手的实践
4 demo
基于log的通用增量 Checkpoint
什么是checkpoint ,通常会想到状态持久化,flink独有的特性,轻量且快,容错,本地格式化,快速恢复。
1 checkpoint 性能优化之路
checkpoint不同版本之间的优化
- 0.9 轻量级异步的snapshot算法,把barrier作为一个特殊的record在graph中流动,同时将耗时较大的文件上传等工作放到异步的过程当中进行,这样的话对主流程的影响是变的非常小的。
- 1.0 当中支持了RocksDB StateBackend,对于大状态下的存储提供了很好的支持。
- 1.3 当中实现了基于RocksDB incremental checkpoint,这个机制是进一步提升了在异步阶段的checkpoint的性能。
- 1.11 当中引入了Unaligned Checkpoint。
- 1.13 当中又引入了Unaligned Checkpoint (Production-ready),在一些场景下对于barrier对齐会有瓶颈的作业的话,基于Unaligned Checkpoint 以及 buffer debloating我们可以甚至让一些作业在反压比较严重的情况下依然可以做出Checkpoint。
- 1.14 当中又加入了buffer debloating的概念,上面1.13中介绍的buffer debloating就是此概念,通过调整buffer debloating的大小来加速barrier的流动,进一步加速checkpoint的完成,而对 unaligned checkpoint去进一步减少 unaligned checkpoint过程中存储的数据量。
- 1.15 1.16 当中引入了changelog backend,这个功能就是我们本次学习的重点,它的机制就是进一步的通过一个更通用的increment的checkpoint机制更进一步异步的减少开销,提升checkpoint的异步部分的性能。
我们可以通过checkpoint链路上看这些优化技术在graph中的体现,在触发checkpoint的时候,我们知道source阶段barrier随着graph进行流动,然后在刚打开了buffer debloating的时候flink会通过计算数据吞吐等方式来动态调整network buffer的大小来加速barrier的传递,而当barrier到达state节点的时候,如果是aligned checkpoint那么就会等待barrier的对齐,如果是unaligned checkpoint的话会直接将buffer当中的内容存储到hdfs当中不会阻塞,然后同时触发statebackend上的checkpoint的过程 ,buffer的传输的话就像上图中虚线所示,然后在statebackend内部再触发checkpoint的时候基于异步的checkpoint算法,在异步部分会进行一个文件的上传,如上图实现所示,开启了rocksdb increment的时候,会做些增量文件的上传,在这次介绍changelog statebackend的部分的话,我们可以看到最下面的虚线 我们会把原来的statebackend的异步上传部分和changelog进行解耦,然后会有一个独立的上传hdfs的过程,这个过程会在后面进行详细介绍。
上图中的指标会让你对checkpoint有一些直观的感受,包括像端到端延迟,这个是对checkppoint最直观的性能的一个感受。
2 解析changelog
3 一览State/Checkpoint优化
4 总结
Flink CDC + Kafka加速业务实时化
广义的概念上,能够捕获数据变更的技术,我们都可以称为CDC (Change Data Capture)。通常我们说的CDC技术主要面向数据库的变更,是一种用于捕获数据库中数据变更的技术。
1 Flink CDC技术
主要用到的场景有以下这些:
2 Flink+Kafka实时数据集成方案
目前CDAS是阿里云商业化的功能,该部分代码在写这篇文章时暂时没有开源。
3 Demo:Flink+Kafka实现CDC数据的实时集成和实时分析
此处省略,有想看的请自行按照上面url查看。
Flink Table Store典型应用场景
1 介绍Flink Table Store
其实我觉得数仓分为实时和离线最好的状态。
2 应用场景
3 Demo
4 后续挑战
相关文章
- 天冷了,任务栏养只猫吧「GitHub 热点速览 v.21.46」
- GitHub 开源的小工具「GitHub 热点速览 v.21.45」
- 盘点 GitHub 年度盛会|附视频
- 它说你的代码有 Bug「GitHub 热点速览 v.21.44」
- 《HelloGitHub》第 67 期
- 代码混淆保安全「GitHub 热点速览 v.21.43」
- 每个男孩的机械梦「GitHub 热点速览 v.21.41」
- 《HelloGitHub》第 66 期
- 大型项目源码集合「GitHub 热点速览 v.21.39」
- 有备无患「GitHub 热点速览 v.21.38」
- 用 Java 写个塔防游戏「GitHub 热点速览 v.21.37」
- 这款打怪升级的小游戏,7 年前出生于 GitHub 社区,如今在谷歌商店有 8 万人打了满分
- 开源的 Web 框架哪个快?我在 GitHub 找到了答案
- 人生重开模拟器「GitHub 热点速览 v.21.36」
- 自建纯净谷歌搜索「GitHub 热点速览 v.21.35」
- 早产的《HelloGitHub》第 65 期
- 5 秒克隆声音「GitHub 热点速览 v.21.34」
- 那些 Unix 命令替代品们「GitHub 热点速览 v.21.32」
- 承载童年的游戏机,已停产!但我在 GitHub 找到了它们
- 自制车速记录仪「GitHub 热点速览 v.21.31」