一文读懂Apache Flink技术
|
而有了BroadcastState以后就可以做一些优化：因为左表数据量比较大，右表数据量比较小，所以选择把右表进行广播，把左表按照它某一个进行均匀分布的key，做keyby shuffle，shuffle到下游的N个Join的节点，Join的节点里面会存两份State，左边state和右边state，左边state用来存左边数据流的state，是一个keyedState，因为它是按它某一个key做keyby分发下来的。右边State是一个BroadcastState，所有的Join节点里面的BroadcastState里面存的数据都是一模一样的，因为均为从上游广播而来。 所有keyedState进行并发处理，之后将keyedState集合进行合并便等于左边数据流的全集处理结果。于是便实现了这个Join节点的可扩充，通过增加join节点的并发，可以比较好地提升Job处理能力。除了不等值Join场景，BroadcastState还可以比较有效地解决像CAP上的动态规则。 在Flink 1.6.0时期，提供了State TTL参数、DataStream Interval Join功能。State TTL实现了在申请某个State时候可以在指定一个TTL参数，指定该state过了多久之后需要被系统自动清除。在这个版本之前，如果用户想要实现这种状态清理操作需要使用ProcessFunction注册一个Timer，然后利用Timer的回调手动把这个State清除。从该版本开始，Flink框架可以基于TTL原生地解决这件事情。DataStream Interval Join功能即含有区间间隔的Join，比如说左流Join右流前后几分钟之内的数据，这种叫做Interval Join。 2.3 Flink Checkpoint & Recovery的历史变迁 Checkpoint机制在Flink很早期的时候就已经支持，是Flink一个很核心的功能，Flink社区也一直致力于努力把Checkpoint效率提升，以及换成FailOver之后它的Recallable效率的提升。 在Flink 1.0.0时期，提供了RocksDB的支持，这个版本之前所有的状态都只能存在进程的内存里面，这个内存总有存不下的一天，如果存不下则会发生OOM。如果想要存更多数据、更大量State就要用到RocksDB。RocksDB是一款基于文件的嵌入式数据库，它会把数据存到磁盘，但是同时它又提供高效读写能力。所以使用RocksDB不会发生OOM这种事情。在Flink1.1.0里面，提供了纯异步化的RocksDB的snapshot。以前版本在做RocksDB的snapshot时它会同步阻塞主数据流的处理，很影响吞吐量，即每当checkpoint时主数据流就会卡住。纯异步化处理之后不会卡住数据流，于是吞吐量也得到了提升。 在Flink 1.2.0时期，引入了Rescalable keys和operate state的概念，它支持了一个Key State的可扩充以及operator state的可扩充。 （编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |