Flink 一个以事件驱动的流处理框架

这是官网对Flink的描述

Apache Flink is a framework and distributed processing engine for stateful computationsover unbounded and bounded data streams. Flink has been designed to run in all common cluster environments, perform computations at in-memory speed and at any scale.

流处理的的几个阶段

事务处理

也就是我们常说的业务处理，主要分为两层：计算层和存储层。

对于传统的关系型数据库处理来自计算层的请求,我们可以把请求数据理解为一条一条的，其实就是一个数据流。而对于每一个事件，系统都在收到之后进行相应的处理，这也是符合流处理的原则的。所以可以说，传统的事务处理，就是最基本的流处理架构。

随着业务愈发庞大，来自计算层的请求逐渐增多，程序员需要解决的东西由解决业务增加到了维护数据库。不仅要对其进行分库分表将大量的时间花费到了业务以外的编码上，由此引申出了第二种模型。

分析处理

把数据从业务数据库进行ETL清洗、整合、提取出来，然后统一放到数据仓库中去，然后用数据分析的引擎进行查询分析处理，最后将结果生成报表或即席查询

事件驱动的流处理

第一代流处理模型

将数据的最小单元看作一个event，来一个处理一个。对于数据的状态STATE将其存储到本地内存中，在更新状态的时候仅仅只需要更新本地的状态。然而在服务器掉电可能导致存在内存中的本地状态丢失，可以做一个周期性检查点（periodic checkpoint），将periodic checkpoint放在远程的存储空间中，这样当节点故障之后进行恢复可以从远程存储空间将之前存盘的状态恢复就可以了。

第二代流处理模型 Lambda架构

考虑到第一代流式处理架构不准确的问题，例如算电商的平均销售额，可能来一条数据平均值就会发生改变，只有在当前时刻的结果是准确的，由此Lambda架构应运而生。Lambda架构可以说是流批一体的架构，流式计算负责实时计算，批计算负责统筹结果。

Lambda架构的优势很明显，但是也有很大的弊端就是我们需要维护两套模型。且这两套模型是完全独立的系统，会极大的增加我们的工作量。

最新一代流处理模型（Flink）

第三代流处理器通过巧妙的设计，完美解决了乱序数据对结果正确性的影响。这一代系统还做到了精确一（exactly-once）的一致性保障，是第一个具有一致性和准确结果的开源流处理器。另外，先前的流处理器仅能在高吞吐和低延迟中二选一，而新一代系统能够同时提供这两个特性。所以可以说，这一代流处理器仅凭一套系统就完成了 Lambda 架构两套系统的工作，它的出现使得 Lambda 架构黯然失色。

浅谈一下Flink和Spark的区别

从数据的基本单元而言： Spark底层主要维护的是RDD 弹性分布数据集，所以对于Spark处理的数据而言是伪流处理，属于是微批。而Flink而言FLink是以事件驱动的流处理框架，底层处理的是Event能够做到真正的流式处理。然而Flink也提供了DataStream 和 DataSet api 既能流处理也能批处理。但批处理逐渐被批处理api取代了。

Spark采用的是处理时间、Flink可以事件时间，到达时间，处理时间

Spark在运行时的主要角色包括：Master、Worker、Driver、Executor。Flink 在运行时主要包含：Jobmanager、Taskmanager和Slot。

SparkStreaming的容错机制是基于RDD的容错机制，会将经常用的RDD或者对宽依赖加Checkpoint。利用SparkStreaming的direct方式与Kafka可以保证数据输入源的，处理过程，输出过程符合exactly once。Flink 则使用两阶段提交协议来保证exactly once。

spark是基于微批的,而且流水线优化做的很好,所以说他的吞入量是最大的,但是付出了延迟的代价,它的延迟是秒级;而Flink是基于事件的,消息逐条处理,而且他的容错机制很轻量级,所以他能在兼顾高吞吐量的同时又有很低的延迟,它的延迟能够达到毫秒级;