Flink流处理（一）- 状态流处理简介

1. Flink 简介

Flink 是一个分布式流处理器，提供直观且易于使用的API，以供实现有状态的流处理应用。它可以以fault-tolerant的方式高效地运行在大规模系统中。

流处理技术在当今地位愈发重要，由于它为不少业务场景提供了很是优秀的解决方案，例如数据分析，ETL，事务应用等。

 

2. 有状态的流处理

在不少场景下，数据都是以持续不断的流事件建立。例如网站的交互、或手机传输的信息、服务器日志、传感器信息等。有状态的流处理（stateful stream processing）是一种应用设计模式，用于处理无边界的流事件。下面咱们简单介绍一下有状态流处理的机制。

对于任何处理流事件的应用来讲，并不会仅仅简单的一次处理一个记录就完事了。在对数据进行处理或转换时，操做应该是有状态的。也就是说，须要有能力作到对处理记录过程当中生成的中间数据进行存储及访问。当一个application 收到一个 event，在对其作处理时，它能够从状态信息（state）中读取数据进行协助处理。或是将数据写入state。在这种准则下，状态信息（state）能够被存储（及访问）在不少不一样的地方，例如程序变量，本地文件，或是内置的（或外部的）数据库中。

Apache Flink 存储应用状态信息在本地内存或是一个外部数据库中。由于Flink 是一个分布式系统，本地状态信息须要被有效的保护，以防止在应用或是硬件挂掉以后，形成数据丢失。Flink对此采起的机制是：按期为应用状态（application state）生成一个一致（consistent）的checkpoint，并写入到一个远端持久性的存储中。下面是一个有状态的流处理Flink application的示例图：

 

Stateful stream processing 应用的输入通常为：事件日志（event log）的持续事件。Event log 存储而且分发事件流。事件被写入一个持久性的，仅可追加的（append-only）日志中。也就是说，被写入的事件的顺序始终是不变的。因此事件在Publish 给多个不一样用户时，均是以彻底同样的顺序发布的。在开源的event log 系统中，最著名的当属 Kafka。

使用flink流处理程序链接event log的理由有多种。在这个架构下，event log 持久化输入的 events，而且能够以既定的顺序replay这些事件。万一应用发生了某个错误，Flink会经过前一个checkpoint 恢复应用的状态，并重置在event log 中的 read position，并据此对events作replay（and fast forward），直到它抵达stream 的末端。这个技术不只被用于错误恢复，而且也能够用于更新application，修复bugs，以及修复以前遗漏结果等场景中。

状态流处理主要有三种常见的实现方式：（1） Event-driven applications；（2）Data pipeline applications；（3）Data Analytics applications

在实际场景中，大部分应用会使用以上多种结合的方式。

 

3. Event-Driven Applications

事件驱动应用（event-driven application）消费事件流，并以业务逻辑处理events。根据业务逻辑，event-driven application 能够触发某些action（例如发送警报或是email），亦或是向另外一事件流写入events，并被其余event-driven application 处理。

常见event-driven applications 使用场景包括：

1. 实时推荐（例如客户在浏览卖家网站时，为客户推荐产品）
2. 模式识别或是复琐事件处理（例如信用卡诈骗识别）
3. 异常检测（例如网络入侵检测）

Event-driven application是微服务的演变。微服务使用 REST 调用以及外部数据存储（例如 Key-Value store）。而事件驱动应用使用的是 event log，并使用本地状态（local state）记录应用数据。下面是事件驱动应用的一个示例图：

 

 

 

从上图咱们能够看出，多个应用经由event log 链接。一个application 将输出写入 event log，并继而被另外一application 消费。Event log 将发送端与接收端解耦，并提供了异步非阻塞的事件传输。每一个application 均可以是有状态的，并能够在本地管理它本身的状态，而不须要外部数据存储。Applications 能够独立地运行并扩展。

相对于微服务来讲，事件驱动应用有多个优势。相较于读写外部数据库，本地状态访问（local state access）提供了很是好的性能。扩展以及容错，由流处理器解决。利用event log 做为输入源，application的输入被稳定存储，并可以以既定的顺序replay。再者，Flink 能够重置application的状态到前一个检查点，这样能够实如今不丢失application 状态的状况下，对应用进修改或是rescale。

Event-driven 应用对流处理器的要求较高。并非全部流处理器均适用于跑event-driven applications。对此应用的要求包括：处理state的有效方式，事件时间支持等。同时，exactly-once 状态的一致性，以及伸缩能力也一样重要。Apache Flink 的实现符合全部这些需求，对于这类应用来讲，是一个很好的选择。

 

4. Data Pipelines

当今的IT 架构中，涵盖了多种不一样的数据存储，例如关系型数据库、nosql 数据库、event logs、分布式文件系统、in-memory cache 以及 search indexes 等。全部这些系统以不一样的格式和结构存储数据，觉得它们特定的访问模式提供最高效的性能。在实际场景中，能够常常看到一样的数据被存储在多个不一样的系统中，以提升数据访问的性能。例如，一个产品的信息能够被存储在关系型数据库、nosql 数据库，以及cache 和search index中。因为数据有多个备份，因此各个位置存储的数据必须保持同步（in-sync）。

一个传统的实现方案是：使用按期的 ETL jobs对存储在不一样系统中的数据作同步。可是，此方法致使的高延迟，在当今系统中不少场景都没法接受。另外一个方法是使用event log用于发布数据的更新。更新操做被写入到event log，而后被 event log 发布出去。根据使用的场景，被传输的数据可能须要被标准化，亦或是与外部数据进行整合后，再写入到目标存储。

以低延迟的方式消费、转换，而后插入数据，是另外一个stateful stream processing application 的应用场景。这种应用被称为data pipeline。Data pipeline 必须能在短期内处理大量的数据。做为 data pipeline 的流处理器应有能力链接不一样的数据源，并进行写入。Flink 对此有较好的支持。

 

5. Streaming Analytics

ETL 任务会按期导入数据到存储， 而后数据会被一次（或是按期的query）处理。这种批处理与架构是否基于数据仓库，或是Hadoop 生态应用无关。按期载入数据到数据分析系统，在不少年都是业界标准用法。可是它对analytics pipeline 来讲，增长了至关的延迟。

取决于每两次操做的间隔，每次操做可能须要消耗几个小时或是几天，直到生成一个结果。在必定程度内，能够经过使用data pipeline application 将数据导入到datastore，以减小延迟。然而，即便是持续的 ETL，直到event被query处理以前，也会存在delay。这个delay在过去是能够被接受的，可是在当今场景中，数据更须要被实时收集并处理（例如，即时推荐）。

相对于等待一个按期触发的job处理数据，streaming analytics application 能够持续消费事件流，并以低延迟整合最新的事件，并更新输出的结果。通常来讲，streaming applications 会将它们的结果存储在一个外部datastore，此datastore支持高效的update，例如数据库，或是key-value 存储。流处理程序输出的实时更新的结果，能够被用于Dashboard applications。以下图：

 

 

 

除了能以更短的时间将一个event整合到最终的分析结果中，streaming analytics applications 还有另外一个优势。传统analytics pipeline由多个独立的部分组成，如一个ETL 系统，一个存储系统，大数据分析系统等。然而，stateful stream application 能够顾及到全部这些步骤，包括事件消费，持续计算（并维护状态信息），以及更新数据。进一步的，流处理器能够从错误恢复（经过保证exactly-once state consistency），并调整应用的计算资源。Flink 这类流处理器也支持event-time处理，以产生正确、肯定的结果，并有能力在短期内处理大量的数据。

Streaming analytics applications 经常使用场景有：

1. 监控手机网络的质量
2. 分析手机应用用户的行为
3. 实时数据的Ad-hoc 分析

Flink 同时也提供在流上的 SQL query。

 

6. Flink 的特色

Apache Flink能够在大规模集群中提供了高吞吐与低延时，相对于其余流处理器，有如下有点：

1. Event-time 与 processing-time 语义。事件-时间语义能够，在有无序事件的状况下，提供一致与准确的结果。处理-时间语义能够被用于须要低延迟的application
2. Exactly-once 状态一致性的保障
3. 以毫秒级的延迟处理每秒百万级的事件。Flink应用能够被扩展运行到上千个核
4. 易于使用的API
5. 多种connectors用于链接不一样数据源，如Kafka，Cassandra，Elasticsearch，JDBC，Kinesis，HDFS以及S3
6. 没有单点故障，支持HA设置，极少有downtime。与YARN，Kuberntes等集成较好。快速从错误恢复，以及动态扩展的能力
7. 更新application 代码，而后迁移到另外一Flink 集群时，能够不丢失application的state 信息
8. 详细、可自定义的系统及应用指标收集
9. 也能够用做为batch processor

除了这些特色，Flink的API的使用较为简单。内置的execution mode 能够启动一个application，并让整个Flink 系统运行在一个JVM 进程中，方便开发者作开发、测试与debug。

 

7. 第一个flink程序

在启动一个 flink 集群后，使用命令执行示例程序：

> flink run -m yarn-cluster -yn 2 /usr/lib/flink/examples/streaming/WordCount.jar --input hdfs:///user/hadoop/input --output hdfs:///user/hadoop/output

> cat output

(3123,1)

(asdf21,1)

…

 

References：

Vasiliki Kalavri, Fabian Hueske. Stream Processing With Apache Flink. 2019