flink之状态化流处理概述

[TOC]
Apache Flink 是一个分布式流处理引 擎，它提供了直观且极富表达 力的 API 来实现有状态的流处理应用，并且支持在容错的前提下高效、大规模地运行 此类应用。 Flink 于 2014 年 4 月以孵化项目的形式进入 Apache 软件基金会， 并在次年一月就成为了顶级项目。它自创建伊始就拥有 一 个活跃 、不 断发展 的用户及贡献者群体 。截至目 前，该项目已 经有超过 500 名贡献者 ， 井在不 断普及的过程中逐渐发展为开惊界最为先进的流处理引 擎之一。全球很多不 同行业的公司和企业都在使用 Flink支撑其大规模核心业务。

流处理技术正受到越来越 多不同规模公司的 青睐。这是因为它不仅可以为很 多现有场景提供更优的解决方案(例如数据分析、 ETL，以及事务性应用)， 还能催生很多新颖的应用、软件架构，以及商业机会。本章我们会讨论为何 状态化流处 理会变得 如此流行，并进 一 步评估其发展潜力。我们首先将回顾 传统数据应用架构并指出其局限。其次，我们 会 介绍基于状态化流处理的应 用设计。和传统设计相比，它有很多有意义的特性及优势。最后，我们将简 要回顾开源流处理引 擎 的 演变过程 ，并帮助你在本地 Flink 实例上运行 一 个流 式应用。

传统数据处理架构

几十年来，数据和数据处理在各类商业领域中无处不在 。随着数据采集和使 用量的不断增长，很多公司都设计井构建了各种基础架构来管理数据。绝大 多数企业所实现的传统架构都会将数据处理分为两类 : 事务型处理和分析型 处理。在本节中，我们将讨论这两类处理模型以及它们如何管理和处理数据。

事务型处理

企业在日常业务运营过程中会用到各类应用，例如 : 企业资源规划( ERP) 系统、客户关系管理(CRM)软件、基于Web的应用等。如图 1-1所示，这 些应用系统通常都会设置独立的数据处理层(应用程序本身)和数据存储层(事 务型数据库系统)。

image.png

这些应用通常会连接外部服务或实际用户，井持续处理诸如订单、 站点击等传入的数据。期间每处理 一条事 件，应用都会通过执行远程数据库 系统的事务来读取或更新状态。很多时候，多个应用会共享同 一 个数据库系统， 有时候还会访问相同的数据库或表。

该设计在应用需要更新或扩缩容时容易导致问题 。一且多 个应用基于相同的 数据表示或共享架构，那么更改表模式( Schema)或对数据库系统进行扩缩 容必将芳心费力。近些年提出的微服务设计模式可以解决这种应用之间紧藕 合情况。微服务由很多微型、完备、独立的应用组成，每个应用都遵循 UNIX 设计哲学 : 专注做好一件事。通过将多个微服务相互连接可以构建出更加复 杂的应用，而微服务间只会通过标准化接口(如 RESTful HTTP连接)进行通信 。 由于微服务彼此间严格解捐且仅通过定义良好的接口通信，所以在实现微服 务时可以选用不同的技术枝(编程语言、库和数据存储等)。通常情况下， 微服务会和所有必需的软件及服务一起打包部署到独立的容器中。图 1-2展示了一种微服务架构。

image.png

分析型处理

存储于不同事务型数据库系统中的数据，可以为企业提供业务运营相关的分析见解。例如: :i]l过分析订单处理系统中的数据来获知销售增辰率，或是通 过分析运输延迟原因或预测销 售量 以调整库存。然而用于存储事务性数据的 多个数据库系统通常都是相互隔离的，如能将它们联合分析必然会创造更高 的价值。此外，开发人员还经常需要将这些数据转换为某种通用格式。

对于分析类查询，我们通常不会直接在事务型数据库上执行，而是将数据复制到一个专门用来处理分析类查询的数据仓库。为了填充数据仓库，需要将 事务型数据库系统中的数据拷贝过去。这个向数据仓库拷贝数据的过程被称 为提取-转换-加载( Extract-Transform-Load, ETL)。 ETL 的基本流程是 : 从事务型数据库中提取数据，将其转换为通用表示形式(可 能包含数据验证、 数据归 一 化 、编码、去重、表模式转换等工作)，最终加载到分析型数据库中。 该流程可能会非常麻烦，通常需要复杂的技术方案来满足性能要求。为了保 持数据仓库中的数据同步， ETL 过程需要周期性地执行

一旦数据导 人数据仓库，我们就能对它们做 查 询分析 。通常数据 仓库中的 查 询可以分为两类:第一类是定期报告查询。它可用于计算业务相关的统计数据， 如收入、用户增长、产出等。将这些指标整合成报告，能够帮助管理层评估 企业整体健康状况。第 二类是即席查询( ad-hoc query)。其主要目的是通过 解答特定问题来辅助关键性的商业诀策，例如通过查询来整合营收数 字 和电
台广告中的投入，以评估市场营销的有效性。如图 1-3所示，无论哪一类查询， 都是在数据仓库中以批处理的方式执行。

image.png

时至今日， Apache Hadoop 生态组件已经成为很多公司和企业 IT 基础设施中 举足轻重的部分。海量日志文件、社交媒体、网页点击日志等数据已不再使 用关系数据库系统存储，而是会 写人 Hadoop 分布式文件系统( HDFS )、 S3 或其他诸如 Apache HBase 的批量数据存储系统。这些系统以低廉的成本提供 庞大的存储容 量， 而它们中的数据也可以通过很 多基于 Hadoop 的 SQL 引 擎 (如 Apache Hive、 Apache Drill 或 Apache Impala)进行查询和处理 。然而，这些 基础设施所用的架构和传统数据仓库只是大同小异。

状态化流处理

几乎所有 数据都是 以连 续事件流 的形式产 生。请考 虑 一下，无论是网站或移 动应用中的用户交互或订单下达，还是服务器日志或传感器测量结果，这些 数据本质上都是事件流。事实上，现实 世界中很难找到那种瞬间就 生成完整 数据集的例子。作为一类面向无限事件流的应用设计模式，状态化流处理适 用于企业 IT基础设施中的很多应用场景。在讨论这些场景之前，我们首先简 要解释一下状态化流处理的工作原理 。

任何一个处理事件流的应用，如果要支持跨多条记录的转换操作，都必须是 有状态的，即能够存储和访问中间结果。应用收到事件后可以执行包括读写 状态在内的任意计算。原则上，需要在应用中访问的状态有多种可选的存储 位置，例如:程序变量、本地文件、嵌人式或外部数据库等。

Apache Flink 会将应用状态存储在本地内存或嵌入式数据库中。 由于采用的 是分布式架构， Flink 需要对本地状态予以保护，以避免因应用或机器故障 导致数据丢失。为了实现该特性， Flink 会定期将应用状态的 一 致性检查点 (checkpoint)写入远程持久化存储。图 1-4简单展示了 Flink有状态的流式应用。 有关状态、状态一致性，以及 Flink 的检查点机制会在后面的章节详细讨论。

有状态的流处理应用通常会从事件日志中读取事件记录。事件日志负责存储事 件流并将 其分布式 化。由于 事件只 能以追加的形式 写入持久 化日 志中， 所以其顺序无怯在后期改变。写人事件日志的数据流可以被相同或不同的消 费者重复读取。得益于日志的追加特性，无论向消费者发布几次，事件的顺 序都 能保持 一致。有不少事件日志系 统都是开 源软件，其中最流行的当属 Apache Kafka，也有部分系统会以云计算提供商集成服务的形式提供。

出于很多原因，将运行在 Flink 之上的有状态的流处理应用和事件日志系统相连会很有意义。在该架构下，事件日志系统可以持久化输入事件井以确定的顺序将其重放。 一旦 出现故障， Flink 会利用之前的检查点恢复状态并重置事 件日志的读取位置，以此来使有状态的流处理应用恢复正常。随后应用会从 事件日志中读取并(快速)重放输入事件，直到追赶上数据流当前的进度。 该技术不但可用于失败恢复，还可用于应用更新、 Bug 修复、结果修正、集 群迁移或针对不同版本应用执行 A/B 测试。

流式分析

ELT 作业会周期性地把数据导人数据存储系统，并通过即席或计划查询处理 数据。无论它们的架构是基于数据仓库还是 Hadoop 生态系统组件，这都属于 批处理 。虽然周期性地将数据导人分析系统在多年来一直是最先进 的方法， 但它会给分析流程带来相当大的延迟。

根据调度周期的不同，数据可能会在数小时或数天后才出现在报告中。在某 种程度上，使用数据管道应用来导人数据可以降低延迟。但即便持续地进行 ETL 操作，事件在被查询和处理到之前总会有 一 定延迟。虽然 从过 去视角来 看，这种延迟可以接受，但当今的应用必须能够实时收集数据并迅速响应(例 如调整手游中的某个可变条件或使用户在网购过程中获得个性化体验)。

流式分析应用不再需要等待周期性地触发。相反，它会持续获取事件流，以 极低的延迟整合最新事件，从而可以不断更新结果 。 这有点类似于数据库系 统为了更新物化视图而用到的维护技术。通常情况下，流式应用会把它们的 结果保存在某种支持高效更新的外部数据存储中，例如数据库或键值存储。 如图 1-6所示，流式分析应用实时更新的结果可用于支撑仪表盘应用的展示。

image.png

除了将事件整合到分析结果的用时更短，流式分析应用还有另 一个不太明显 的优势。传统分析流程都会包含很多独立组件，例如 ETL 进程、存储系统等。 即便是基于 Hadoop 的环境，也需要有数据处理器和用来触发作业或查询的调 度器。相 比之下，运行有状态的流处理 应用的流处理引擎会全面负责事件获取、 维护状态的持续计算以及更新结果等所有处理步骤。此外，它还能以精确 一 次的状态一致性保障进行故障恢复，调节应用计算资源等。诸如 Fli此之类的 流处理引擎还支持事件时间处理，从而可以生成精准、确定的结果，并具备 在短 时间内处理大 量数据的能力。

历史回顾

第一代开源分布式流处理引擎( 2011 年)专注于以毫秒级延迟处理数据并保 证系统故障时事件不会丢失。它们的 API 非常底层，而且并未针对流式应用 结果的准确性和一致性提供内置保障。其结果完全取决于事件到达的时间和 顺序。此外，虽然数据在出错时不 会丢失，但可能会被处理多次。和 批处理 引擎相比，第一代开源流处理引擎通过牺牲结果的准确度来换取低延迟。以 当时的眼光看待流处理系统，计算快速和结果准确 二者不可兼得，因此才有 了所谓的 Lambda 架构，如图 1-7 所示。

image.png

Lambda 架构在传统周期性批处理架构的 基础上添加了 一个由低延迟流处理引 擎所驱动的“提速层” (speed layer) 。在该架构中，到来的数据会同 时发往 流处理引擎和写入批量存储。流处理引擎会近乎实时地计算出近似结果，并 将其写入“提速表”中。批处理引擎周期性地处理批量存储的数据，将精确 结果写人批处理表，随后将“提速表”中对应的非精确结果删除。为了获取 最终结果，应用需要将“提速表”中的近似结果和批处理表中的精确结果合井。

虽然 Lambda 架构已经算不上最先进，但仍然有着非常广泛的应用。它最初 是以改善原始批量分析架构中结果的高延迟为目标，然而自身却有很多明显 的缺点 。首先，该架构需要在拥有不同 A凹的两 套独立处理系统之上实现两 套语义相同的应用逻辑:其次，流处理引擎计算的结果只是近似的;最后， Lambda 架构很难配置和维护。

和第一代开源分布式流处理引 擎相比，第二代引 擎 (2013 年)提供了更加完 善的故障处理机制，即便出现故障，它们也能保证每条记录仅参与一次结果 运算。 此外，编程API也从底层基于算子的接口进化为拥有更多内置操作原 语的高层 API。但它们的部分改进(例如更高的吞吐和更完善的故障处理保障) 是以增加处理延迟(从毫秒级到秒级)为代价的，并且其处理结果仍依赖于 事 件到来的时间和顺序。

第三 代分布式流处理引 擎 (2015 年)解决了结果对事件到来时间及顺序的依 赖问题 。结合 精确 一 次故障恢复语义，这 一 代系统才称得上第一批能够计算 精确一致结果的开源流处理引擎。由于只需依靠实际数据计算结果，此类系 统可以将历史数据当做“实时”数据进行处理。它的另 一项改进是无需让用 户在延迟和吞吐之间做出困难的抉择。前几代的流处理引擎只能在高吞吐和 低延迟之间 二选其一 ，而第三代的系统可 以兼顾两者，这使得 Lambda 架构 彻底沦为历史 。

Flink 快览

Apache Flink是一个集众多具有竞争力的特性于一身的第三代流处理引 擎。 它支持精确的流处理，能同时满足各种规模下对高吞吐和低延迟的要求，尤其是以下功能使其在同类系统中脱颖而出:

同时支持事件时间和处理时间语义。事件时间语义能够针对无序事件提供 一致、精确的结果;处理时间语义能够用在具有极低延迟需求的应用中 。
提供精确 一 次( exactly-once)的状态 一 致性保障 。
• 在每秒处理数百万条事件的同时保持毫秒级延迟。基于 Flink 的应用可以
扩展到数千核心之上。

• 层次化的 API在表达能力和l易用性方面各有权衡。本书涵盖了 DataStream API 和处理函数( process function)的相关内容，它们提供了通用的流处 理操作原语(如窗口划分和异步操作)以及精确控制时间和状态的接口。 而 Flink 的关系型 API- SQL 及 LINQ 风格的 Table API

• 用于最常见存储系统的连接器，如 Apache Kafka、 Apache Cassandra、 Elasticsearch、 JDBC、 Kinesis 以及(分布式)文件系统( HDFS 和 S3 等)。

• 支持高可用性配置(无单点失效)， 和 Kubernetes、 YARN、 Apache Mesos 紧密集成，快速故障恢复，动态扩缩容作业等 。 基于上述特点，它 可以 7 × 24 小时运行流式应用，几乎无须停机 。

• . 允许在不丢失应用状态的前提下更新作业的程序代码，或进行跨 Flink 集 群的作业迁移。

• 提供了详细、可自由定制的系统及应用指标( metrics)集合，用于提前定 位和!响应问题。

• 最后要强调的一点: Flink同时也是一个成熟的批处理引擎。

除了上述特性， Flink 还是 一 个对开发者非常友好的框架，这得益于它十分 易用的 API。 Flink 的嵌入式执行模式可将应用自身连同整个 Flink 系统在单 个 JVM 进程内启动，方便从 IDE 里运行和 i周试 Flink 作业。这在开发和调试 Flink 应用的时候非常好用。