一文读懂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的可扩充。

在Flink 1.3.0时期，引入了增量的checkpoint这个比较重要的功能。只有基于增量的checkpoint才能更好地支持含有超大State的Job。在阿里内部，这种上TB的State是非常常见。如果每一次都把全量上TB的State都刷到远程的HDFS上那么这个效率是很低下的。而增量checkpoint只是把checkpoint间隔新增的那些状态发到远程做存储，每一次checkpoint发的数据就少了很多，效率得到提高。在这个版本里面还引入了一个细粒度的recovery，细粒度的recovery在做恢复的时候，有时不需要对整个Job做恢复，可能只需要恢复这个Job中的某一个子图，这样便能够提高恢复效率。

在Flink 1.5.0时期，引入了Task local 的State的recovery。因为基于checkpoint机制，会把State持久化地存储到某一个远程存储，比如HDFS，当发生Failover的时候需要重新把这个数据从远程HDFS再download下来，如果这个状态特别大那么该download操作的过程就会很漫长，导致Failover恢复所花的时间会很长。Task local state recovery提供的机制是当Job发生Failover之后，能够保证该Job状态在本地不会丢失，进行恢复时只需在本地直接恢复，不需从远程HDFS重新把状态download下来，于是就提升了Failover recovery的效率。

2.4 Flink Runtime的历史变迁

Runtime的变迁历史是非常重要的。

在Flink 1.2.0时期，提供了Async I/O功能。如果任务内部需要频繁地跟外部存储做查询访问，比如说查询一个HBase表，在该版本之前每次查询的操作都是阻塞的，会频繁地被I/O的请求卡住。当加入异步I/O之后就可以同时地发起N个异步查询的请求，这样便提升了整个job的吞吐量，同时Async I/O又能够保证该job的Async语义。

在Flink 1.3.0时期，引入了HistoryServer的模块。HistoryServer主要功能是当job结束以后，它会把job的状态以及信息都进行归档，方便后续开发人员做一些深入排查。

在Flink 1.4.0时期，提供了端到端的exactly once的语义保证，Flink中所谓exactly once一般是指Flink引擎本身的exactly once。如果要做到从输入到处理再到输出，整个端到端整体的exactly once的话，它需要输出组件具备commit功能。在kafka老版本中不存在commit功能，从最近的1.1开始有了这个功能，于是Flink很快便实现了端到端exactly once。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!