一文读懂流式计算框架Flink _Flink

文章插图

随着互联网的不断发展，行业内对于数据的处理能力和计算的实时性要求都在不断增加，随之而来的是计算框架的升级。经过了十余年开源社区的不断演进，现在计算框架已经从第一代的雅虎开源的Hadoop体系进化到目前主流的Spark框架，这两套框架的计算主要是从强依赖硬盘存储能力的计算发展到了内存计算，大大增强了计算力。下一代计算引擎，也就是第三代计算引擎，将会从计算实时性的角度突破，也就是今天要讲到的Flink框架，本文将从简入深的介绍Flink框架的特点。

文章插图

?
基本架构

文章插图

?调度层面Flink支持本地运行以及分布式运行两种，分布式运行可以跑在目前主流的基于Yarn体系中，也可以跑在目前业内最主流的K8S中，Flink本质上还是专注于做计算框架的部分，应用于目前行业内主流的调度引擎上而确保一个分布式的计算能力。
在核心层主要做的是一件事是如何对流式任务进行编排，流式任务不同于离线任务的最大一个特点在于任务编排上面，比如我们有三个事件分别叫1、2、3 。在离线任务中，事件运行是有先后顺序的，比如要先运行1再运行2接着运行3，在流式任务场景下这种事件只有逻辑上的先后关系，实际上是同时触发并执行的。

文章插图

?API层面稍后单独用一个模块讲解，在Library方面内置了图计算算法包Gelly和机器学习包FlinkML以及CEP 。其中Gelly和FlinkML是基于DataSet API进行开发的，而DataSet API是一个离线批计算的接口，所以本质上Gelly和FlinkML并没有发挥Flink这个天然流式框架的优势。个人觉得，Flink作为Apache相对比较年轻的开源计算框架，对于一些组件化的支持还不完善，相比于Spark生态还有比较大的差距。后续如果能基于Flink Stream API开发出流式的上层应用，会成为Flink的一大亮点。
分布式架构层面Flink和Spark或者Hadoop区别不大，整体框架是：

文章插图

?由Flink的Client向Job Master提交任务，Job Master作为整个集群的管理节点。Task Manager是Slave的角色，负责底层的运算工作。Job Master控制整个计算任务的Checkpoint的进度。Task Manager间可以通过数据流的方式交换数据，同时Task Manager在任务的并行化计算方面比MapReduce做的更好，Flink Task Manager是采用多线程的机制进行并行化数据计算，而传统的MapReduce方法采用的是JVM进程的形式。
开发接口架构作为一个算法发烧友，我还是愿意花更多的篇幅来介绍如何基于Flink框架进行开发。首先看下开放编程接口的API上下游站位关系，

文章插图

最上一层是Flink SQL，这一层其实是一个上级封装，了解机器学习或者其它更复杂编程模型的同学应该比较清楚，并不是所有的逻辑都能通过SQL来实现。不过目前绝大部分的数据实时处理逻辑通过SQL这一层就可以解决。
TableAPI这一级可以看出Flink要实现流批一体化的野心，Flink希望可以在流式DataStream API和离线DataSet API之上做一层封装，对用户暴露更多复杂计算的函数，同时基于这一层API实现的功能可以完成流批一体。这个设想是很好的，不过目前还有很多功能没办法在这一级实现，也导致了TableAPI的尴尬。
DataStream和DataSet仍是目前的主流编程接口，如果希望在Flink中实现诸如机器学习算法这样负责逻辑的函数，还是要依赖于这一层。至于Runtime内核开发，这个明显是留给非常资深的高级用户来使用，大部分的开发应该不会触碰。
如何做流式编程重点讲下DataStream这个开发接口，首先Flink把流式编程模型切分为DataSource模块、Transformation模块和DataSink模块。DataSource和DataSink分别对应着数据的流入和流出。
在DataSource和Sink模块，Flink都原生支持了Apache体系内的很多产品的I/O，比如Kafka Connector和Elastic Search Connector等等。同时在数据接入导出方面还内置了很多数据源，