大数据Flink概述

目录

• 1 Flink概述
• • 1.1 框架版本
  • 1.2 编程语言
• 2 实时即未来
• 3 富二代Flink
• 4 Flink官方介绍
• 5 Flink组件栈
• 6 Flink基石
• 7 Flink用武之地
• • 7.1 Event-driven Applications【事件驱动】
  • 7.2 Data Analytics Applications【数据分析】
  • 7.3 Data Pipeline Applications【数据管道】

---

1 Flink概述

1.1 框架版本

https://flink.apache.org/blog/

Flink1.12.0可以称得上是一个里程碑版本，由近 300 位开发者参与贡献者，提交了超过 1000多个修复或优化。这些修改极大地提高了 Flink 的可用性，并且简化（且统一）了 Flink 的整个API 栈。
✓ Flink1.12.0其中一些比较重要的修改包括：
✓ 在 DataStream API 上添加了高效的批执行模式的支持。这是批处理和流处理实现真正统一的运行时的一个重要里程碑。
✓ 实现了基于Kubernetes的高可用性（HA）方案，作为生产环境中，ZooKeeper方案之外的另外一种选择。
✓ 扩展了 Kafka SQL connector，使其可以在 upsert 模式下工作，并且支持在 SQL DDL 中处理connector 的 metadata。现在，时态表 Join 可以完全用 SQL 来表示，不再依赖于Table API 了。
✓ PyFlink 中添加了对于 DataStream API 的支持，将 PyFlink 扩展到了更复杂的场景，比如需要对状或者定时器 timer 进行细粒度控制的场景。除此之外，现在原生支持将 PyFlink作业部署到 Kubernete上。

https://developer.aliyun.com/article/780123?spm=a2c6h.12873581.0.0.1e3e46ccbYFFrC

1.2 编程语言

Flink官方提供了Java、Scala、Python语言接口用以开发Flink应用程序，但是Flink的源码是使用Java语言进行开发的，且Flink被阿里收购后，未来的主要编程语言都一直会是Java（因为阿里是Java重度使用者！），且GitHub上关于Flink的项目，大多数是使用Java语言编写的。所以Java语言为主进行Flink的学习，但会扩展讲解使用其他语言进行Flink开发

https://ci.apache.org/projects/flink/flink-docs-release-1.12/

`

https://github.com/search?q=Flink

2 实时即未来

如今的我们正生活在新一次的信息革命浪潮中，5G、物联网、智慧城市、工业4.0、新基建……等新名词层出不穷，唯一不变的就是变化！对于我们所学习的大数据来说更是这样：数据产生的越来越快、数据量越来越大，数据的来源越来越千变万化，数据中隐藏的价值规律更是越来越被重视！数字化时代的未来正在被我们创造！历史的发展从来不会一帆风顺，随着大数据时代的发展，海量数据和多种业务的实时处理需求激增，比如：实时监控报警系统、实时风控系统、实时推荐系统等，传统的批处理方式和早期的流式处理框架因其自身的局限性，难以在延迟性、吞吐量、容错能力，以及使用便捷性等方面满足业务日益苛刻的要求。在这种形势下，Flink 以其独特的天然流式计算特性和更为先进的架构设计，极大地改善了以前的流式处理框架所存在的问题。
⚫ 扩展阅读:为什么说流处理即未来？

https://news.qudong.com/article/562521.shtml

2.2 一切从Apache开始

Flink 诞生于欧洲的一个大数据研究项目 StratoSphere。该项目是柏林工业大学的一个研究性项目。早期， Flink 是做 Batch 计算的，但是在 2014 年， StratoSphere 里面的核心成员孵化出 Flink，同年将 Flink 捐赠 Apache，并在后来成为 Apache 的顶级大数据项目，同时 Flink计算的主流方向被定位为Streaming， 即用流式计算来做所有大数据的计算，这就是 Flink 技术诞生的背景。
2014 年 Flink 作为主攻流计算的大数据引擎开始在开源大数据行业内崭露头角。区别于Storm、Spark Streaming 以及其他流式计算引擎的是：它不仅是一个高吞吐、低延迟的计算引擎，同时还提供很多高级的功能。比如它提供了有状态的计算，支持状态管理，支持强一致性的数据语义以及支持 基于Event Time的WaterMark对延迟或乱序的数据进行处理等

3 富二代Flink

https://blog.csdn.net/dQCFKyQDXYm3F8rB0/article/details/86117374

随着人工智能时代的降临，数据量的爆发，在典型的大数据的业务场景下数据业务最通用的做法是：选用批处理的技术处理全量数据，采用流式计算处理实时增量数据。在绝大多数的业务场景之下，用户的业务逻辑在批处理和流处理之中往往是相同的。但是，用户用于批处理和流处理的两套计算引擎是不同的。因此，用户通需要写两套代码。毫无疑问，这带来了一些额外的负担和成本。阿里巴巴的商品数据处理就经常需要面对增量和全量两套不同的业务流程问题，所以阿里就在想，我们能不能有一套统一的大数据引擎技术，用户只需要根据自己的业务逻辑开发一套代码。这样在各种不同的场景下，不管是全量数据还是增量数据，亦或者实时处理，一套方案即可全部支持，这就是阿里选择 Flink 的背景和初衷。2015 年阿里巴巴开始使用 Flink 并持续贡献社区(阿里内部还基于Flink做了一套Blink)，2019年1月8日，阿里巴巴以 9000 万欧元(7亿元人民币)收购了创业公司 Data Artisans。从此Flink开始了新一轮的乘风破浪！

4 Flink官方介绍

⚫ 官网地址:
https://flink.apache.org/

5 Flink组件栈

一个计算框架要有长远的发展，必须打造一个完整的 Stack。只有上层有了具体的应用，并能很好的发挥计算框架本身的优势，那么这个计算框架才能吸引更多的资源，才会更快的进步。所以 Flink 也在努力构建自己的 Stack。Flink分层的组件栈如下图所示：每一层所包含的组件都提供了特定的抽象，用来服务于上层组件。
各层详细介绍：
◼ 物理部署层：Flink 支持本地运行、能在独立集群或者在被 YARN 管理的集群上运行， 也能部署在云上，该层主要涉及Flink的部署模式，目前Flink支持多种部署模式：本地、集群(Standalone、YARN)、云(GCE/EC2)、Kubenetes。Flink能够通过该层能够支持不同平台的部
署，用户可以根据需要选择使用对应的部署模式。
◼ Runtime核心层：Runtime层提供了支持Flink计算的全部核心实现，为上层API层提供基础服务，该层主要负责对上层不同接口提供基础服务，也是Flink分布式计算框架的核心实现层，支持分布式Stream作业的执行、JobGraph到ExecutionGraph的映射转换、任务调度等。将DataSteam和DataSet转成统一的可执行的Task Operator，达到在流式引擎下同时处理批量计算和流式计算的目的。
◼ API&Libraries层：Flink 首先支持了 Scala 和 Java 的 API，Python 也正在测试中。
DataStream、DataSet、Table、SQL API，作为分布式数据处理框架，Flink同时提供了支撑计算和批计算的接口，两者都提供给用户丰富的数据处理高级API，例如Map、FlatMap操作等，也提供比较低级的Process Function API，用户可以直接操作状态和时间等底层数据。
◼ 扩展库：Flink 还包括用于复杂事件处理的CEP，机器学习库FlinkML，图处理库Gelly等。Table 是一种接口化的 SQL 支持，也就是 API 支持(DSL)，而不是文本化的SQL 解析和执行。

6 Flink基石

Flink之所以能这么流行，离不开它最重要的四个基石：Checkpoint、State、Time、Window。
⚫ Checkpoint
这是Flink最重要的一个特性。Flink基于Chandy-Lamport算法实现了一个分布式的一致性的快照，从而提供了一致性的
语义。Chandy-Lamport算法实际上在1985年的时候已经被提出来，但并没有被很广泛的应用，而Flink则把这个算法发扬光大了。
Spark最近在实现Continue streaming，Continue streaming的目的是为了降低处理的延时，其也需要提供这种一致性的语义，最终也采用了Chandy-Lamport这个算法，说明Chandy-Lamport算法在业界得到了一定的肯定。https://zhuanlan.zhihu.com/p/53482103
⚫ State
提供了一致性的语义之后，Flink为了让用户在编程时能够更轻松、更容易地去管理状态，还提供了一套非常简单明了的State API，包括里面的有ValueState、ListState、MapState，近期添加了BroadcastState，使用State API能够自动享受到这种一致性的语义。
⚫ Time
除此之外，Flink还实现了Watermark的机制，能够支持基于事件的时间的处理，能够容忍迟到/乱序的数据。
⚫ Window
另外流计算中一般在对流数据进行操作之前都会先进行开窗，即基于一个什么样的窗口上做这个计算。Flink提供了开箱即用的各种窗口，如滑动窗口、滚动窗口、会话窗口以及非常灵活的自定义的窗口。

7 Flink用武之地

http://www.liaojiayi.com/flink-IoT/
https://flink.apache.org/zh/usecases.html

从很多公司的应用案例发现，其实Flink主要用在如下三大场景：

7.1 Event-driven Applications【事件驱动】

事件驱动型应用是一类具有状态的应用，它从一个或多个事件流提取数据，并根据到来的事件触发计算、状态更新或其他外部动作。
事件驱动型应用是在计算存储分离的传统应用基础上进化而来。在传统架构中，应用需要读写远程事务型数据库。相反，事件驱动型应用是基于状态化流处理来完成。在该设计中，数据和计算不会分离，应用只需访问本地(内存或磁盘)即可获取数据。系统容错性的实现依赖于定期向远程持久化存储写入 checkpoint。下图描述了传统应用和事件驱动型应用架构的区别。
从某种程度上来说，所有的实时的数据处理或者是流式数据处理都应该是属于DataDriven，流计算本质上是Data Driven 计算。应用较多的如风控系统，当风控系统需要处理各种各样复杂的规则时，Data Driven 就会把处理的规则和逻辑写入到Datastream 的API 或者是ProcessFunction 的API 中，然后将逻辑抽象到整个Flink 引擎，当外面的数据流或者是事件进入就会触发相应的规则，这就是Data Driven 的原理。在触发某些规则后，Data Driven 会进行处理或者是进行预警，这些预警会发到下游产生业务通知，这是Data Driven 的应用场景，Data Driven 在应用上更多应用于复杂事件的处理。
典型实例：

• 欺诈检测(Fraud detection)
• 异常检测(Anomaly detection)
• 基于规则的告警(Rule-based alerting)
• 业务流程监控(Business process monitoring)
• Web应用程序(社交网络)

7.2 Data Analytics Applications【数据分析】

数据分析任务需要从原始数据中提取有价值的信息和指标。如下图所示，Apache Flink 同时支持流式及批量分析应用。

Data Analytics Applications包含Batch analytics(批处理分析)和Streaminganalytics(流处理分析)Batch analytics可以理解为周期性查询：Batch Analytics 就是传统意义上使用类似于MapReduce、Hive、Spark Batch 等，对作业进行分析、处理、生成离线报表。比如Flink应用凌晨从Recorded Events中读取昨天的数据，然后做周期查询运算，最后将数据写入Database或者HDFS，或者直接将数据生成报表供公司上层领导决策使用。Streaming analytics可以理解为连续性查询：比如实时展示双十一天猫销售GMV(GrossMerchandise Volume成交总额)，用户下单数据需要实时写入消息队列，Flink 应用源源不断读取数据做实时计算，然后不断的将数据更新至Database或者K-VStore，最后做大屏实时展示。
典型实例

• 电信网络质量监控
• 移动应用中的产品更新及实验评估分析
• 消费者技术中的实时数据即席分析
• 大规模图分析

7.3 Data Pipeline Applications【数据管道】

什么是数据管道？
提取-转换-加载(ETL)是一种在存储系统之间进行数据转换和迁移的常用方法。ETL 作业通常会周期性地触发，将数据从事务型数据库拷贝到分析型数据库或数据仓库。数据管道和 ETL 作业的用途相似，都可以转换、丰富数据，并将其从某个存储系统移动到另一个。但数据管道是以持续流模式运行，而非周期性触发。因此数据管道支持从一个不断生成数据的源头读取记录，并将它们以低延迟移动到终点。例如：数据管道可以用来监控文件系统目录中的新文件，并将其数据写入事件日志；另一个应用可能会将事件流物化到数据库或增量构建和优化查询索引。和周期性 ETL 作业相比，持续数据管道可以明显降低将数据移动到目的端的延迟。此外，由于它能够持续消费和发送数据，因此用途更广，支持用例更多。下图描述了周期性ETL作业和持续数据管道的差异。
Periodic ETL：比如每天凌晨周期性的启动一个Flink ETL Job，读取传统数据库中的数据，然后做ETL，最后写入数据库和文件系统。
Data Pipeline：比如启动一个Flink 实时应用，数据源(比如数据库、Kafka)中的数据不断的通过Flink Data Pipeline流入或者追加到数据仓库(数据库或者文件系统)，或者Kafka消息队列。Data Pipeline 的核心场景类似于数据搬运并在搬运的过程中进行部分数据清洗或者处理，
而整个业务架构图的左边是Periodic ETL，它提供了流式ETL 或者实时ETL，能够订阅消息队列的消息并进行处理，清洗完成后实时写入到下游的Database或File system 中。
典型实例

• 电子商务中的持续 ETL(实时数仓)
  当下游要构建实时数仓时，上游则可能需要实时的Stream ETL。这个过程会进行实时清洗或扩展数据，清洗完成后写入到下游的实时数仓的整个链路中，可保证数据查询的时效性，形成实时数据采集、实时数据处理以及下游的实时Query。
• 电子商务中的实时查询索引构建(搜索引擎推荐)
  搜索引擎这块以淘宝为例，当卖家上线新商品时，后台会实时产生消息流，该消息流经过Flink 系统时会进行数据的处理、扩展。然后将处理及扩展后的数据生成实时索引，写入到搜索引擎中。这样当淘宝卖家上线新商品时，能在秒级或者分钟级实现搜索引擎的搜索。