Flink介绍、特点及和与其他大数据框架对比

Flink 是什么

在数据量激增的时代，各种业务场景都有大量的业务数据产生，对于这些不断产生的数据应该如何进行有效的处理，成为当下大多数公司所面临的问题。目前比较流行的大数据处理引擎 Apache Spark，基本上已经取代了 MapReduce 成为当前大数据处理的标准。但对实时数据处理来说，Apache Spark 的 Spark-Streaming 还有性能改进的空间。Spark-Streaming 的流计算本质上还是批（微批）计算，Apache Flink 就是近年来在开源社区不断发展的技术中的能够同时支持高吞吐、低延迟、高性能的纯实时的分布式处理框架。

Flink定义

Apache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。
Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Flink has been designed torun in all common cluster environments, perform computations at in-memory speed and at any scale.

有界流和无界流

无界流： 有定义流的开始，但没有定义流的结束。它们会无休止地产生数据。无界流的数据必须持续处理，即数据被摄取后需要立刻处理。不能等到所有数据都到达再处理，因为输入是无限的，在任何时候输入都不会结束。处理无界数据通常要求以特定顺序摄取事件，例如事件发生的顺序，以便能够推断结果的完整性。
有界流： 有定义流的开始，也有定义流的结束。有界流可以在摄取所有数据后再进行计算。有界流中所有数据可以被排序，所以并不需要有序摄取。有界流处理通常被称为批处理

有状态的计算架构

数据流就是是一条条真实存在的事件按照时间顺序源源不断的产生。我们很难在数据产生的过程中直接进行计算并产生统计结果，因为这不仅对系统有非常高的要求，还必须要满足高性能、高吞吐、低延时等众多目标。
有状态流计算架构（如图所示）的提出，从一定程度上满足了企业的这种需求，基于实时的流式数据，维护所有计算过程的状态(所谓状态就是计算过程中产生的中间计算结果)，每次新的数据进入到系统中,都基于中间状态结果进行运算，最终产生正确的统计结果。
基于有状态计算最大的优势是不需要将原始数据重新从外部存储中拿出来进行全量计算(这种计算方式代价非常高)。同时，用户无须通过调度和协调各种批量计算工具，从数据仓库中获取数据统计结果，可以极大地减轻系统对其他框架的依赖，减少数据计算过程中的时间损耗以及硬件存储。

为什么要用Flink

有状态流计算将会逐步成为企业作为构建数据平台的架构模式，而目前从社区来看，能够满足的只有 Apache Flink。Flink 通过实现 Google Dataflow 流式计算模型实现了高吞吐、低延迟、高性能兼具实时流式计算框架。同时 Flink 支持高度容错的状态管理，防止状态在计算过程中因为系统异常而出现丢失，Flink 周期性地通过分布式快照技术Checkpoints 实现状态的持久化维护，使得即使在系统停机或者异常的情况下都能计算出正确的结果

应用场景

理论上所有大数据场景都可以使用Flink，例如金融交易数据、互联网订单数据、GPS 定位数据、传感器信号、移动终端产生的数据、通信信号数据等，以及我们熟悉的网络流量监控、服务器产生的日志数据，这些数据最大的共同点就是实时从不同的数据源中产生，然后再传输到下游的分析系统。主要包括实时智能推荐、复杂事件处理、实时欺诈检测、实时数仓与 ETL 类型、流数据分析类型、实时报表类型等实时业务场景

特点和优势

Flink具有以下特点
1. 同时支持高吞吐、低延迟、高性能
Flink 是目前开源社区中唯一一套集高吞吐、低延迟、高性能三者于一身的分布式流式数据处理框架。像 Apache Spark 也只能兼顾高吞吐和高性能特性而流式计算框架 Apache Storm 只能支持低延迟和高性能特性，但是无法满足高吞吐的要求
2. 支持事件时间（Event Time）概念
目前大多数框架窗口计算采用的都是系统时间（Process Time），也是事件传输到计算框架处理时，系统主机的当前时间。Flink 能够支持基于事件时间（Event Time）语义进行窗口计算，也就是使用事件产生的时间，这种基于事件驱动的机制使得事件即使乱序到达，流系统也能够计算出精确的结果，保持了事件原本产生时的时序性，尽可能避免网络传输或硬件系统的影响
3. 支持有状态计算
所谓状态就是在流式计算过程中将算子的中间结果数据保存在内存或者文件系统中，等下一个事件进入算子后可以从之前的状态中获取中间结果中计算当前的结果，从而无须每次都基于全部的原始数据来统计结果，这种方式极大地提升了系统的性能，并降低了数据计算过程的资源消耗
4. 支持高度灵活的窗口（Window）操作
在流处理应用中，数据是连续不断的，需要通过窗口的方式对流数据进行一定范围的聚合计算，例如统计在过去的 1 分钟内有多少用户点击某一网页，在这种情况下，我们必须定义一个窗口，用来收集最近一分钟内的数据，并对这个窗口内的数据进行再计算。Flink 将窗口划分为基于 Time、Count、Session，以及 Data-driven 等类型的窗口操作，窗口可以用灵活的触发条件定制化来达到对复杂的流传输模式的支持，用户可以定义不同的窗口触发机制来满足不同的需求
5. 基于轻量级分布式快照（CheckPoint）实现的容错
Flink 能够分布式运行在上千个节点上，将一个大型计算任务的流程拆解成小的计算过程，然后将 tesk 分布到并行节点上进行处理。在任务执行过程中，能够自动发现事件处理过程中的错误而导致数据不一致的问题，比如：节点宕机、网路传输问题，或是由于用户因为升级或修复问题而导致计算服务重启等。在这些情况下，通过基于分布式快照技术的 Checkpoints，将执行过程中的状态信息进行持久化存储，一旦任务出现异常停止，Flink 就能够从 Checkpoints 中进行任务的自动恢复，以确保数据在处理过程中的一致性（Exactly-Once）
6. 基于 JVM 实现独立的内存管理
Flink 实现了自身管理内存的机制，尽可能减少 JVM GC 对系统的影响。另外，Flink 通过序列化/反序列化方法将所有的数据对象转换成二进制在内存中存储，降低数据存储的大小的同时，能够更加有效地对内存空间进行利用，降低 GC 带来的性能下降或任务异常的风险，因此Flink 较其他分布式处理的框架会显得更加稳定，不会因为 JVM GC 等问题而影响整个应用的运行
7. Save Points（保存点）
对于 7*24 小时运行的流式应用，数据源源不断地接入，在一段时间内应用的终止有可能导致数据的丢失或者计算结果的不准确，例如进行集群版本的升级、停机运维等操作。Flink 通过 Save Points 技术将任务执行的快照保存在存储介质上，当任务重启的时候可以直接从事先保存的 Save Points 恢复原有的计算状态，使得任务继续按照停机之前的状态运行，Save Points 技术可以让用户更好地管理和运维实时流式应用

流式计算框架对比

计算引擎的发展经历了几个过程，从第 1 代的 MapReduce，到第 2 代基于有向无环图的 Tez，第 3 代基于内存计算的 Spark，再到第 4 代的 Flink,各框架对比如下：

模型： Storm 和 Flink 是真正的一条一条处理数据；而 Trident（Storm 的封装框架）和 Spark Streaming 其实都是小批处理，一次处理一批数据（小批量）。
API ： Storm 和 Trident 都使用基础 API 进行开发，操作相对复杂；而 Spark Streaming 和 Flink 中都提供封装后的高阶函数，可以直接拿来使用，这样就比较方便了。
保证次数： 在数据处理方面，Storm 可以实现至少处理一次，但不能保证仅处理一次，这样就会导致数据重复处理问题，所以针对计数类的需求，可能会产生一些误差；Trident 通过事务可以保证对数据实现仅一次的处理，Spark Streaming 和 Flink 也是如此。
容错机制： Storm和Trident可以通过ACK机制实现数据的容错机制，而Spark Streaming和 Flink 可以通过 CheckPoint 机制实现容错。
状态管理： Storm 中没有实现状态管理，Spark Streaming 实现了基于 DStream 的状态管理，而 Trident 和 Flink 实现了基于操作的状态管理。
延时： 表示数据处理的延时情况，因为 Storm 和 Flink 接收到一条数据就处理一条数据，其数据处理的延时性是很低的；而 Trident 和 Spark Streaming 都是小型批处理，它们数据处理的延时性相对会偏高。
吞吐量： Storm 的吞吐量其实也不低，只是相对于其他几个框架而言较低；Trident 属于中等；而 Spark Streaming 和 Flink 的吞吐量是比较高的。