Flink(一)

初始Flink

       Flink 是 Apache 基金会旗下的一个开源大数据处理框架。目前，Flink 已经成为各大公司大数据实时处理的发力重点，特别是国内以阿里为代表的一众互联网大厂都在全力投入，为Flink 社区贡献了大量源码。如今 Flink 已被很多人认为是大数据实时处理的方向和未来，许多公司也都在招聘和储备掌握 Flink 技术的人才。

那 Flink 到底是什么，又有什么样的优点，能够让大家对它如此青睐呢？

本章我们就来做一个详细的了解。首先讲述 Flink 的源起和设计理念，接着介绍 Flink 如今的应用领域；进而通过梳理数据处理架构的发展演变，解答为什么要用 Flink 的疑问。进而梳理 Flink 的特点，并同另一个流行的大数据处理框架 Spark 进行比较，从而更深刻地理解 Flink 的底层架构和优势所在。

Flink的应用

       Flink 是一个大数据流处理引擎，它可以为不同的行业提供大数据实时处理的解决方案。随着 Flink 的快速发展完善，如今在世界范围许多公司都可以见到 Flink 的身影。

        目前在全球范围内，北美、欧洲和金砖国家均是 Flink 的应用热门区域。当然，这些地区其实也就是 IT、互联网行业较发达的地区。

        Flink 在国内热度尤其高，一方面是因为阿里的贡献和带头效应，另一方面也跟中国的应用场景密切相关。中国的人口规模与互联网使用普及程度，决定了对大数据处理的速度要求越来越高，也迫使中国的互联网企业去追逐更高的数据处理效率。试想在中国，一个网站可能要面对数亿的日活用户、每秒数亿次的计算峰值，这对很多国外的公司来说是无法想象的。而Flink 恰好给我们高速准确的处理海量流式数据提供了可能。

     

       可以看到，各种行业的众多公司都在使用 Flink，那到底他们用 Flink 来处理什么需求呢？ 换句话说，什么的场景最适合 Flink 大显身手呢？

回到 Flink 本身的定位，它是一个大数据流式处理引擎，处理的是流式数据，也就是“数据流”（Data  Flow）。顾名思义，数据流的含义是，数据并不是收集好的，而是像水流一样，是一组有序的数据序列，逐个到来、逐个处理。由于数据来到之后就会被即刻处理，所以流处理的一大特点就是“快速”，也就是良好的实时性。Flink 适合的场景，其实也就是需要实时处理数据流的场景。

Flink的核心特性

Flink 区别与传统数据处理框架的特性如下：

1. 1.高吞吐和低延迟。每秒处理数百万个事件，毫秒级延迟。
2. 2.结果的准确性。Flink 提供了事件时间（event-time）和处理时间（processing-time） 语义。对于乱序事件流，事件时间语义仍然能提供一致且准确的结果。
3. 3.精确一次（exactly-once）的状态一致性保证。
4. 4.可以连接到最常用的存储系统，如Apache Kafka、Apache Cassandra、Elasticsearch、JDBC、Kinesis 和（分布式）文件系统，如 HDFS 和S3。
5. 5.高可用。本身高可用的设置，加上与 K8s，YARN 和 Mesos 的紧密集成，再加上从故障中快速恢复和动态扩展任务的能力，Flink 能做到以极少的停机时间 7×24 全天候运行。
6. 6.能够更新应用程序代码并将作业（jobs）迁移到不同的 Flink 集群，而不会丢失应用程序的状态。

Flink与Spark

       谈到大数据处理引擎，不能不提 Spark。Apache Spark 是一个通用大规模数据分析引擎。它提出的内存计算概念让大家耳目一新，得以从Hadoop 繁重的 MapReduce 程序中解脱出来， 可以说是划时代的大数据处理框架。除了计算速度快、可扩展性强，Spark 还为批处理（Spark SQL）、流处理（Spark  Streaming）、机器学习（Spark  MLlib）、图计算（Spark  GraphX）提供了统一的分布式数据处理平台，整个生态经过多年的蓬勃发展已经非常完善。

       然而正在大家认为Spark 已经如日中天、即将一统天下之际，Flink 如一颗新星异军突起， 使得大数据处理的江湖再起风云。很多读者在最初接触都会有这样的疑问：想学习一个大数据处理框架，到底选择 Spark，还是 Flink 呢？

       这就需要我们了解两者的主要区别，理解它们在不同领域的优势。

1.数据处理架构

我们已经知道，数据处理的基本方式，可以分为批处理和流处理两种。

批处理针对的是有界数据集，非常适合需要访问海量的全部数据才能完成的计算工作，一般用于离线统计。

流处理主要针对的是数据流，特点是无界、实时, 对系统传输的每个数据依次执行操作， 一般用于实时统计。

从根本上说，Spark 和 Flink 采用了完全不同的数据处理方式。可以说，两者的世界观是截然相反的。

Spark 以批处理为根本，并尝试在批处理之上支持流计算；在 Spark 的世界观中，万物皆批次，离线数据是一个大批次，而实时数据则是由一个一个无限的小批次组成的。所以对于流处理框架 Spark Streaming 而言，其实并不是真正意义上的“流”处理，而是“微批次”（micro-batching）处理:

 

而 Flink 则认为，流处理才是最基本的操作，批处理也可以统一为流处理。在 Flink 的世界观中，万物皆流，实时数据是标准的、没有界限的流，而离线数据则是有界限的流。如图1-13 所示，就是所谓的无界流和有界流。

1.无界数据流（Unbounded Data Stream）

所谓无界数据流，就是有头没尾，数据的生成和传递会开始但永远不会结束，如图 1-13 所示。我们无法等待所有数据都到达，因为输入是无界的，永无止境，数据没有“都到达”的时候。所以对于无界数据流，必须连续处理，也就是说必须在获取数据后立即处理。在处理无界流时，为了保证结果的正确性，我们必须能够做到按照顺序处理数据。

2.有界数据流（Bounded Data Stream）

对应的，有界数据流有明确定义的开始和结束，如图 1-13 所示，所以我们可以通过获取所有数据来处理有界流。处理有界流就不需要严格保证数据的顺序了，因为总可以对有界数据集进行排序。有界流的处理也就是批处理。

       正因为这种架构上的不同，Spark 和 Flink 在不同的应用领域上表现会有差别。一般来说， Spark 基于微批处理的方式做同步总有一个“攒批”的过程，所以会有额外开销，因此无法在流处理的低延迟上做到极致。在低延迟流处理场景，Flink 已经有明显的优势。而在海量数据的批处理领域，Spark 能够处理的吞吐量更大，加上其完善的生态和成熟易用的 API，目前同样优势比较明显。

2.数据模型和运行架构

除了三观不合，Spark 和 Flink 在底层实现最主要的差别就在于数据模型不同。

Spark 底层数据模型是弹性分布式数据集（RDD），Spark Streaming  进行微批处理的底层接口DStream，实际上处理的也是一组组小批数据 RDD 的集合。可以看出，Spark 在设计上本身就是以批量的数据集作为基准的，更加适合批处理的场景。

而 Flink 的基本数据模型是数据流（DataFlow），以及事件（Event）序列。Flink 基本上是完全按照 Google 的 DataFlow 模型实现的，所以从底层数据模型上看，Flink 是以处理流式数据作为设计目标的，更加适合流处理的场景。

数据模型不同，对应在运行处理的流程上，自然也会有不同的架构。Spark 做批计算，需要将任务对应的 DAG 划分阶段（Stage），一个完成后经过 shuffle 再进行下一阶段的计算。而 Flink 是标准的流式执行模式，一个事件在一个节点处理完后可以直接发往下一个节点进行处理。

Flink还是Spark

通过前文的分析，我们已经可以看出，Spark 和 Flink 可以说目前是各擅胜场，批处理领域 Spark 称王，而在流处理方面 Flink 当仁不让。具体到项目应用中，不仅要看是流处理还是批处理，还需要在延迟、吞吐量、可靠性，以及开发容易度等多个方面进行权衡。

如果在工作中需要从 Spark 和 Flink 这两个主流框架中选择一个来进行实时流处理，我们更加推荐使用 Flink，主要的原因有：

1.Flink 的延迟是毫秒级别，而 Spark Streaming 的延迟是秒级延迟

2.Flink 提供了严格的精确一次性语义保证

3.Flink 的窗口API 更加灵活、语义更丰富

4.Flink 提供事件时间语义，可以正确处理延迟数据

5.Flink 提供了更加灵活的对状态编程的 API

基于以上特点，使用 Flink 可以解放程序员, 加快编程效率, 把本来需要程序员花大力气手动完成的工作交给框架完成。

当然，在海量数据的批处理方面，Spark 还是具有明显的优势。而且 Spark 的生态更加成熟，也会使其在应用中更为方便。相信随着 Flink 的快速发展和完善，这方面的差距会越来越小。

另外，Spark 2.0 之后新增的 Structured Streaming 流处理引擎借鉴DataFlow 进行了大量优化，同样做到了低延迟、时间正确性以及精确一次性语义保证；Spark 2.3 以后引入的连续处理（Continuous Processing）模式，更是可以在至少一次语义保证下做到 1 毫秒的延迟。而 Flink 自 1.9 版本合并Blink 以来，在 SQL 的表达和批处理的能力上同样有了长足的进步。

那如果现在要学习一门框架的话，优先选 Spark 还是 Flink 呢？其实我们可以看到，不同的框架各有利弊，同时它们也在互相借鉴、取长补短、不断发展，至于未来是 Spark 还是 Flink、甚至是其他新崛起的处理引擎一统江湖，都是有可能的。作为技术人员，我们应该对不同的架构和思想都有所了解，跳出某个框架的限制，才能看到更广阔的世界。