Flink教程（02）- Flink入门（上）

01 引言

在上一节《Flink教程（01）- Flink知识图谱》，我们知道了Flink的知识大纲，明白了需要学习的主要内容，本专栏以后都是围绕以下内容来讲 ：

• Flink介绍
• Flink环境准备（安装部署）
• Flink编程模型
• DataStream API
• Flink状态管理与容错
• DataSet API
• Table API & SQL
• Flink组件栈
• Flink部署与应用
• Flink监控与性能优化

• Flink框架版本：https://flink.apache.org/blog/
• Flink编程语言：https://ci.apache.org/projects/flink/flink-docs-release-1.12/
• Flink GitHub：https://github.com/apache/flink

本文主要开始讲解Flink一些入门概念。

02 Flink概述

2.1 产生缘由

流处理即未来：https://news.qudong.com/article/562521.shtml

随着大数据时代的发展，海量数据和多种业务的实时处理需求激增，比如：

• 实时监控报警系统；
• 实时风控系统；
• 实时推荐系统等等。

传统的批处理方式和早期的流式处理框架因其自身的局限性，难以在延迟性、吞吐量、容错能力，以及使用便捷性等方面满足业务日益苛刻的要求。

在这种形势下，Flink 以其独特的天然流式计算特性和更为先进的架构设计，极大地改善了以前的流式处理框架所存在的问题。

2.2 Flink 定义

Apache Flink ：是一个分布式流处理器，具有直观和富有表现力的 API，可实现有状态的流处理应用程序，它以容错的方式有效地大规模运行这些应用程序，还提供了有状态的计算，支持状态管理，支持强一致性的数据语义以及支持基于Event Time的WaterMark对延迟或乱序的数据进行处理等。

Flink的官方地址： https://flink.apache.org/

03 Flink 组件栈

Flink分层的组件栈如下图所示（每一层所包含的组件都提供了特定的抽象，用来服务于上层组件）:

主要分为如下几层：

• 物理部署层
• Runtime核心层
• API&Libraries层
• 扩展

3.1 物理部署层

Flink 支持的部署模式：

• 本地：本地运行
• 集群：独立集群（Standalone）、Yarn管理的集群
• 云上：GCE/EC2
• 容器化部署：Kubenetes

Flink能够通过该层能够支持不同平台的部署，用户可以根据需要选择使用对应的部署模式。

3.2 Runtime核心层

• 提供了支持Flink计算的全部核心实现，为上层API层提供基础服务，该层主要负责对上层不同接口提供基础服务，也是Flink分布式计算框架的核心实现层；
• 支持分布式Stream作业的执行、JobGraph到ExecutionGraph的映射转换、任务调度等；
• 将DataSteam和DataSet转成统一的可执行的Task Operator，达到在流式引擎下同时处理批量计算和流式计算的目的。

3.3 API&Libraries层

• Flink 首先支持了 Scala和 Java 的 API，Python也正在测试中；
• DataStream、DataSet、Table、SQL API，作为分布式数据处理框架，Flink同时提供了支撑计算和批计算的接口，两者都提供给用户丰富的数据处理高级API，例如Map、FlatMap操作等，也提供比较低级的Process Function API，用户可以直接操作状态和时间等底层数据;

3.4 扩展库

• Flink 还包括用于复杂事件处理的CEP，机器学习库FlinkML，图处理库Gelly等。
• Table 是一种接口化的 SQL支持，也就是 API支持(DSL)，而不是文本化的SQL解析和执行。

04 Flink 四大基石

如上图，Fink有四大基石，分别为：

• Checkpoint
• State
• Time
• Window

4.1 Checkpoint

Checkpoint是Flink最重要的一个特性。

Flink基于 Chandy-Lamport 算法实现了一个分布式的一致性的快照，从而提供了一致性的语义。

Chandy-Lamport算法实际上在1985年的时候已经被提出来，但并没有被很广泛的应用，而Flink则把这个算法发扬光大了。

Spark最近在实现Continue streaming，Continue streaming的目的是为了降低处理的延时，其也需要提供这种一致性的语义，最终也采用了Chandy-Lamport这个算法，说明Chandy-Lamport算法在业界得到了一定的肯定。

4.2 State

在提供了一致性的语义之后，Flink为了让用户在编程时能够更轻松、更容易地去管理状态，还提供了一套非常简单明了的State API，包括里面的有ValueState、ListState、MapState，及BroadcastState。

使用State API能够自动享受到这种一致性的语义。

4.3 Time

除此之外，Flink还实现了Watermark的机制，能够支持基于事件的时间（Time）的处理，能够容忍迟到/乱序的数据。

4.4 Window

另外流计算中一般在对流数据进行操作之前都会先进行开窗（Window），即：基于一个什么样的窗口上做这个计算。

Flink提供了开箱即用的各种窗口，比如滑动窗口、滚动窗口、会话窗口以及非常灵活的自定义的窗口。

05 Flink 应用场景

Flink的应用场景主要在这三个方面：

• 事件驱动：Event-driven Applications
• 数据分析：Data Analytics Applications
• 数据管道：Data Pipeline Applications

5.1 事件驱动（Event-driven Applications）

5.1.1 事件驱动应用与传统应用的区别

事件驱动型应用（Event-driven Applications）：是一类具有状态的应用，它从一个或多个事件流提取数据，并根据到来的事件触发计算、状态更新或其他外部动作。

• 事件驱动型应用是在计算存储分离的传统应用基础上进化而来；
• 在传统架构中，应用需要读写远程事务型数据库，相反，事件驱动型应用是基于状态化流处理来完成。
• 在该设计中，数据和计算不会分离，应用只需访问本地(内存或磁盘)即可获取数据；
• 系统容错性的实现依赖于定期向远程持久化存储写入 checkpoint。

下图描述了传统应用和事件驱动型应用架构的区别：

从某种程度上来说，所有的实时的数据处理或者是流式数据处理都应该是属于Data Driven，流计算本质上是Data Driven计算。

5.1.2 风控系统案例

风控系统案例：

1. 当风控系统需要处理各种各样复杂的规则时，Data Driven 就会把处理的规则和逻辑写入到Datastream 的API 或者是ProcessFunction 的API 中；
2. 然后将逻辑抽象到整个Flink引擎，当外面的数据流或者是事件进入就会触发相应的规则，这就是Data Driven 的原理；
3. 在触发某些规则后，Data Driven会进行处理或者是进行预警，这些预警会发到下游产生业务通知，这是Data Driven 的应用场景，Data Driven 在应用上更多应用于复杂事件的处理。

5.1.3 典型案例

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

5.2 数据分析（Data Analytics Applications）

5.2.1 批处理和流处理分析

数据分析任务：需要从原始数据中提取有价值的信息和指标。

如下图所示，Apache Flink 同时支持流式及批量分析应用：

Data Analytics Applications包含以下两种分析：

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

5.2.2 典型案例

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

5.3 数据管道（Data Pipeline Applications）

5.3.1 什么是数据管道

首先我们了解下ETL（提取-转换-加载）：

• ETL是一种在存储系统之间进行数据转换和迁移的常用方法；
• ETL 作业通常会周期性地触发，将数据从事务型数据库拷贝到分析型数据库或数据仓库；

那什么是数据管道呢？

数据管道和 ETL 作业的用途相似，都可以转换、丰富数据，并将其从某个存储系统移动到另一个，但数据管道是以持续流模式运行，而非周期性触发，因此数据管道支持从一个不断生成数据的源头读取记录，并将它们以低延迟移动到终点。

例如：

• 数据管道可以用来监控文件系统目录中的新文件，并将其数据写入事件日志；
• 另一个应用可能会将事件流物化到数据库或增量构建和优化查询索引；

5.3.1 数据管道与周期性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 中。

5.3.2 典型实例

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