【Flink】Flink介绍、优势、使用场景，传统数据处理架构，流处理的演变、Flink的特点、与SparkStreaming的区别

1 什么是Flink

Flink起源于Stratosphere项目，Stratosphere是在2010~2014年由3所地处柏林的大学和欧洲的一些其他的大学共同进行的研究项目，2014年4月Stratosphere的代码被复制并捐赠给了Apache软件基金会，参加这个孵化项目的初始成员是Stratosphere系统的核心开发人员，2014年12月，Flink一跃成为Apache软件基金会的顶级项目。

在德语中，Flink一词表示快速和灵巧，项目采用一只松鼠的彩色图案作为logo，这不仅是因为松鼠具有快速和灵巧的特点，还因为柏林的松鼠有一种迷人的红棕色，而Flink的松鼠logo拥有可爱的尾巴，尾巴的颜色与Apache软件基金会的logo颜色相呼应，也就是说，这是一只Apache风格的松鼠。

Flink项目的理念是：“Apache Flink是为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架”。

Apache Flink是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。Flink被设计在所有常见的集群环境中运行，以内存执行速度和任意规模来执行计算。

Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams.

2 Flink的优势

• 流数据更真实地反映了我们的生活方式

  都是基于有限数据集，我们目前使用的数据都有流的特性，流在编程中是一种很常见的概念，如

  • 网站的点击流。
  • 自动驾驶的导航和上传数据。
  • 前端的点击事件（事件流），前端和Flink的相似性远远大于后端。
  • 在向硬盘中写数据时，是一种文件流。
  • 迭代器，维护迭代器的指针，使用next方法依次消费迭代器的数据。

  如果想要使用流的特性进行编程，就会相对批处理复杂一些。

• 传统的数据架构是基于有限数据集的，如Hadoop、Spark和SparkStreaming。

• 最终的目标

  • 低延迟（Spark Streaming 的延迟是秒级，Flink 延迟是毫秒级）。
  • 高吞吐（阿里每秒钟使用 Flink 处理 4.6PB，双十一大屏）。
  • 结果的准确性和良好的容错性（exactly-once）。

3 应用场景

• 电商和市场营销：数据报表、广告投放、业务流程需要。
• 物联网（IOT）：传感器实时数据采集和显示、实时报警，交通运输业（自动驾驶）。
• 电信业：基站流量调配。
• 银行和金融业：实时结算和通知推送，实时检测异常行为（信用卡盗卡）。

4 传统数据处理架构

（1）事务处理（OLTP）

使用一个关系型数据库来实现所有的功能，当数据规模越来越大时，此种架构模式就不再适用了。

（2）分析处理

将数据从业务数据库复制到数仓，再进行分析和查询。

缺点就是无法快速的看到统计指标，那么lambda结构应运而生。

5 流处理的演变

（1）lambda 架构

用两套系统，计算同一套指标，同时保证低延迟和结果准确。

流处理层保证低延迟，先得到一个大概的数据，之后在固定的时间使用批处理（脚本）重新计算一次，得到精确结果。

但是这两个系统执行的代码基本是一样的，如果计算的指标非常多，就需要将同一份代码写很多次，最终的结果就是实现很简单，但维护很困难，这样，Flink就诞生了。Flink使用一套系统，既可以保证批处理的结果准确性，又保证了流处理的低延迟。

（2）有状态的流式处理

有状态流式处理特点：

• 每接收到一次事件都会进行处理。
• 维护一个本地状态。
• 固定时间将本地状态备份到远程存储。

具体处理流程如下图：

Flink有状态的流式处理典型的处理过程：当一个事件来临，就会触发应用程序的运行。如进行简单的计数操作，应用程序首先从本地状态读取累加器的值，将累加器的值加1，然后再写回本地状态，最终将累加器的值向下游发送。

本地状态会在固定时间将累加器的值保存得到远程存储中，在Flink的流处理过程中，不存在落盘操作。

SparkStreaming不会对每一条数据都进行处理，同样kafka是一个无状态的流式处理，其只维护一个偏移量，不能够开窗进行计算，不会保存任何的缓存去进行一些计算。

（3）演变过程

流处理的演变过程如下图：

时间正确/语义化窗口：按照事件发生的时间处理数据，而不是按照事件到达机器的时间，这样就需要将事件发生的准确时间放置到正确的时间窗口上，如将00:00:09发生的事件放到[00:00:00,00:00:10)窗口中，而不是其他窗口。

6 Flink的特点

（1） 事件驱动（Event-driven）

事件驱动型应用是一类具有状态的应用，它从一个或多个事件流提取数据，并根据到来的事件触发计算、状态更新或其他外部动作。比较典型的就是以kafka为代表的消息队列几乎都是事件驱动型应用。事件驱动可以等同于流处理。

与之不同的就是SparkStreaming微批次，如图：

应用程序的运行都是通过事件来进行驱动，如在网页上点击一个按钮发生了跳转，就是事件驱动，事件驱动的程序是被动的，只有有事件发生的时候，它才会运行。对Flink来说，每接收到一条数据，就会驱动Flink程序的运行。

事件驱动的典型例子：

• 前端：点击按钮、定时器等。
• 后端：redis的IO多路复用，Nginx等。

（2） 基于流的世界观

批处理的特点是有界、持久、大量，非常适合需要访问全套记录才能完成的计算工作，一般用于离线统计。

流处理的特点是无界、实时, 无需针对整个数据集执行操作，而是对通过系统传输的每个数据项执行操作，一般用于实时统计。

在Spark/SparkStreaming 的世界观中，一切都是由批次组成的，离线数据是一个大批次，而实时数据是由一个一个无限的小批次组成的，没有认识到无界流的本质，但不影响其大量使用，只是在特定场景下，其不如Flink。。

而在flink的世界观中，一切都是由流组成的，离线数据是有界限的流，实时数据是一个没有界限的流，这就是所谓的有界流和无界流。

无界数据流：无界数据流有一个开始但是没有结束，它们不会在生成时终止并提供数据，必须连续处理无界流，也就是说必须在获取后立即处理event。对于无界数据流我们无法等待所有数据都到达，因为输入是无界的，并且在任何时间点都不会完成。处理无界数据通常要求以特定顺序（例如事件发生的顺序）获取event，以便能够推断结果完整性。

有界数据流：有界数据流有明确定义的开始和结束，可以在执行任何计算之前通过获取所有数据来处理有界流，处理有界流不需要有序获取，因为可以始终对有界数据集进行排序，有界流的处理也称为批处理。

流批一体体现在下图：

这种以流为世界观的架构，获得的最大好处就是具有极低的延迟。

（3） Flink 的分层 API

最底层级的抽象仅仅提供了有状态流，它将通过过程函数（Process Function）被嵌入到DataStream API中。底层过程函数（Process Function） 与 DataStream API 相集成，使其可以对某些特定的操作进行底层的抽象，它允许用户可以自由地处理来自一个或多个数据流的事件，并使用一致的容错的状态。除此之外，用户可以注册事件时间并处理时间回调，从而使程序可以处理复杂的计算。

实际上，大多数应用并不需要上述的底层抽象，而是针对核心API（Core APIs） 进行编程，比如DataStream API（有界或无界流数据）以及DataSet API（有界数据集）。这些API为数据处理提供了通用的构建模块，比如由用户定义的多种形式的转换（transformations），连接（joins），聚合（aggregations），窗口操作（windows）等等。DataSet API 为有界数据集提供了额外的支持，例如循环与迭代。这些API处理的数据类型以类（classes）的形式由各自的编程语言所表示。

Table API 是以表为中心的声明式编程，其中表可能会动态变化（在表达流数据时）。Table API遵循（扩展的）关系模型：表有二维数据结构（schema）（类似于关系数据库中的表），同时API提供可比较的操作，例如select、project、join、group-by、aggregate等。Table API程序声明式地定义了什么逻辑操作应该执行，而不是准确地确定这些操作代码的看上去如何。

尽管Table API可以通过多种类型的用户自定义函数（UDF）进行扩展，其仍不如核心API更具表达能力，但是使用起来却更加简洁（代码量更少）。除此之外，Table API程序在执行之前会经过内置优化器进行优化。

你可以在表与 DataStream/DataSet 之间无缝切换，以允许程序将 Table API 与 DataStream 以及 DataSet 混合使用。

Flink提供的最高层级的抽象是 SQL 。这一层抽象在语法与表达能力上与 Table API 类似，但是是以SQL查询表达式的形式表现程序。SQL抽象与Table API交互密切，同时SQL查询可以直接在Table API定义的表上执行。

目前Flink作为批处理还不是主流，不如Spark成熟，所以DataSet使用的并不是很多。Flink Table API和Flink SQL也并不完善，大多都由各大厂商自己定制。所以我们主要学习DataStream API的使用。实际上Flink作为最接近Google DataFlow模型的实现，是流批统一的观点，所以基本上使用DataStream就可以了。

总结下来，有以下两点：

• 越顶层越抽象，表达含义越简明，使用越方便。
• 越底层越具体，表达能力越丰富，使用越灵活。

Spark的API对应Flink的DataStream API，如map，reduce，filter，groupBy，sort。

Spark的链式调用API对应Flink中的Table API，如.fliter.groupBy等。

Spark的SQL对应Flink的SQL。

Stateful Stream Processing 在Spark中没有对应的部分，同样也是Flink学习的重点，掌握这一层也就掌握了什么是时间正确、什么是语义化窗口、什么是状态，这一层主要是针对时间和状态进行编程。

（4） 其他特点

• 支持事件时间（event-time）和处理时间（processing-time）语义。

事件时间：发生的时间。

处理时间：到达机器的时间。

SparkStreaming本质上针对的处理时间语义。

Flink支持事件时间和处理时间也就是其可以按照事件发生的时间处理数据，而不是到达机器的时间。

• 精确一次（exactly-once）的状态一致性保证。
• 低延迟，每秒处理数百万个事件，毫秒级延迟（实际上就是没有延迟）。
• 与众多常用存储系统的连接（ES，HBase，MySQL，Redis…）。
• 高可用（zookeeper），动态扩展，实现 7*24 小时全天候运行。

7 Flink 和 SparkStreaming的区别

两者的根本区别就在于流（stream）和微批的区别。

（1）数据模型

Spark 采用 RDD 模型，Spark Streaming 的 DStream 实际上也就是一组组小批数据 RDD 的集合。

Flink 基本数据模型是数据流，以及事件（Event）序列（Integer、String、Long、POJO Class（对应scala的样例类））。

（2）运行时架构

Spark 是批计算，将 DAG 按照有无shuffle划分为不同的 Stage，一个 Stage完成后才可以计算下一个 Stage，如果发生数据倾斜会发生一定的延迟。

Flink 是标准的流执行模式，一个事件在一个节点处理完后可以直接发往下一个节点进行处理。