Flink基础

1. 诞生背景

许多系统都会产生连续的事件流，如行驶中的汽车发射出 GPS 信号，金融 交易，移动通信基站与繁忙的智能手机进行信号交换，网络流量，机器日 志，工业传感器和可穿戴设备的测量结果，等等。如果能够高效地分析大 规模流数据，我们对上述系统的理解将会更清楚、更快速。简而言之，流 数据更真实地反映了我们的生活方式。

在这样的背景下，Apache Flink（以下简称 Flink）应运而生。作为在公共社 区中诞生的开源软件，Flink 为大容量数据提供流处理，并用同一种技术实 现批处理。

能够以非常低的延迟处理数据，这并不是流处理的唯一优势。人们希望流 处理不仅做到低延迟和高吞吐，还可以处理中断。优秀的流处理技术应该 能使系统在崩溃之后重新启动，并且产出准确的结果；换句话说，优秀的 流处理技术可以容错，而且能保证 exactly-once

2. 流处理技术的演变

在开源世界里， Apache Storm 项目（以下简称 Storm）是流处理先锋。Storm 最早由 Nathan Marz 和创业公司 BackType（后来被 Twitter 收购）的一个团队开发，后来 才被 Apache 软件基金会接纳。Storm 提供了低延迟的流处理，但是它为实 时性付出了一些代价：很难实现高吞吐，并且其正确性没能达到通常所需 的水平。换句话说，它并不能保证 exactly-once；即便是它能够保证的正确 性级别，其开销也相当大。

在低延迟和高吞吐的流处理系统中维持良好的容错性是非常困难的，但是 为了得到有保障的准确状态，人们想出了一种替代方法：将连续事件中的 流数据分割成一系列微小的批量作业。如果分割得足够小（即所谓的微批 处理作业），计算就几乎可以实现真正的流处理。因为存在延迟，所以不 可能做到完全实时，但是每个简单的应用程序都可以实现仅有几秒甚至几 亚秒的延迟。这就是在 Spark 批处理引擎上运行的 Apache Spark Streaming（以下简称 Spark Streaming）所使用的方法。

更重要的是，使用微批处理方法，可以实现 exactly-once 语义，从而保障状 态的一致性。如果一个微批处理作业失败了，它可以重新运行。这比连续 的流处理方法更容易。Storm Trident 是对 Storm 的延伸，它的底层流处理引 擎就是基于微批处理方法来进行计算的，从而实现了 exactly-once 语义，但 是在延迟性方面付出了很大的代价。 然而，通过间歇性的批处理作业来模拟流处理，会导致开发和运维相互交 错。完成间歇性的批处理作业所需的时间和数据到达的时间紧密耦合，任 何延迟都可能导致不一致（或者说错误）的结果。这种技术的潜在问题是， 时间由系统中生成小批量作业的那一部分全权控制。Spark Streaming 等一 些流处理框架在一定程度上弱化了这一弊端，但还是不能完全避免。另外， 使用这种方法的计算有着糟糕的用户体验，尤其是那些对延迟比较敏感的 作业，而且人们需要在写业务代码时花费大量精力来提升性能。

为了实现理想的功能，人们继续改进已有的处理器（比如 Storm Trident 的 开发初衷就是试图克服 Storm 的局限性）。当已有的处理器不能满足需求 时，产生的各种后果则必须由应用程序开发人员面对和解决。以微批处理 方法为例，人们往往期望根据实际情况分割事件数据，而处理器只能根据 批量作业时间（恢复间隔）的倍数进行分割。当灵活性和表现力都缺乏的 时候，开发速度变慢，运维成本变高。 于是，Flink 出现了。这一数据处理器可以避免上述弊端，并且拥有所需的 诸多功能，还能按照连续事件高效地处理数据。

3. Flink

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

Flink 不仅能提供同时支持高吞吐和 exactly-once 语义的实时计算，还能提供批量 数据处理，这让许多人感到吃惊。鱼与熊掌并非不可兼得，Flink 用同一种 技术实现了两种功能。

官网：https://flink.apache.org/

批处理与流处理

Flink 是如何同时实现批处理与流处理的呢？答案是，Flink 将批处理（即处 理有限的静态数据）视作一种特殊的流处理。 Flink 的核心计算构造是图中的 Flink Runtime 执行引擎，它是一个分 布式系统，能够接受数据流程序并在一台或多台机器上以容错方式执行。 Flink Runtime 执行引擎可以作为 YARN（Yet Another Resource Negotiator） 的应用程序在集群上运行，也可以在 Mesos 集群上运行，还可以在单机上 运行（这对于调试 Flink 应用程序来说非常有用）。

Flink 的分布式特点体现在它能够在成百上千台机器上运行，它将大型的计 算任务分成许多小的部分，每个机器执行一个部分。Flink 能够自动地确保 在发生机器故障或者其他错误时计算能持续进行，或者在修复 bug 或进行 版本升级后有计划地再执行一次。这种能力使得开发人员不需要担心失败。 Flink 本质上使用容错性数据流，这使得开发人员可以分析持续生成且永远 不结束的数据（即流处理）。

Flink 解决了许多问题，比如保证了 exactly-once 语义和基于 事件时间的数据窗口。开发人员不再需要在应用层解决相关 问题，这大大地降低了出现 bug 的概率。

消息传输层和流处理层

如何有效地实现流处理架构并从 Flink 中获益呢？一个常见的做法是设置消 息传输层和流处理层，如图 所示。

(1) 消息传输层从各种数据源（生产者）采集连续事件产生的数据，并传输 给订阅了这些数据的应用程序和服务（消费者）。

(2) 流处理层有 3 个用途：①持续地将数据在应用程序和系统间移动；②聚合并处理事件；③在本地维持应用程序的状态。

 

事实上，在设计高效的流处理架构时，不仅流处理器的选择会造成架构的 巨大差异，消息传输层也很关键。现代系统之所以更容易处理大规模的流 数据，其中很大一部分原因就是消息传输方式的改进，以及流处理器与消 息传输系统的交互方式的改变。 消息传输层需要具备一些特定的功能。目前来看，有两种技术可以很好 地提供所需的功能，它们便是 Kafka 和 MapR Streams。MapR Streams 是 MapR 融合数据平台的一部分，它支持 Kafka API。

　

消息传输层的理想功能

1. 兼具高性能和持久性

消息传输层的一个作用是作为流处理层上游的安全队列——它相当于缓冲 区，可以将事件数据作为短期数据保留起来，以防数据处理过程发生中断。兼具高性能和持久性对于消息传输系统来说至关重要；Kafka 和 MapR Streams 都可以满足这个需求。

具有持久性的好处之一是消息可以重播。这个功能使得像 Flink 这样的处理 器能对事件流中的某一部分进行重播和再计算。正是 由于消息传输层和流处理层相互作用，才使得像 Flink 这样的系统有了准确 处理和“时空穿梭”（指重新处理数据的能力）的保障

2. 将生产者和消费者解耦

采用高效的消息传输技术，可以从多个源（生产者）收集数据，并使这些 数据可供多个服务或应用程序（消费者）使用，如图所示。Kafka 和 MapR Streams 把从生产者获得的数据分配给既定的主题。数据源将数据 推送给消息队列，消费者（或消费者群组）则拉取数据。事件数据只能 基于给定的偏移量从消息队列中按顺序读出。生产者并不向所有消费者自 动广播。这一点听起来微不足道，但是对整个架构的工作方式有着巨大的 影响。 这种传输方式——消费者订阅感兴趣的主题——意味着消息立刻到达，但 并不需要被立刻处理。在消息到达时，消费者并不需要处于运行状态，而是可以根据自身的需求在任何时间使用数据。这样一来，添加新的消费者 和生产者也很容易。采用解耦的消息传输系统很有意义，因为它能支持微 服务，也支持将处理步骤中的实现过程隐藏起来，从而允许自由地修改实 现过程。

 

 支持微服务架构的流数据

微服务方法指的是将大型系统的功能分割成通常具有单一目的的简单服务， 从而使小型团队可以轻松地构建和维护这些服务。即使是超大型组织，也 可以用这种设计实现敏捷。若要使整个系统正常工作，各服务之间因通信 而产生的连接必须是轻量级的。

消息传输系统一方面将生产者和消费者解耦，另一方面又有足够高的吞吐 量，并且能够满足像 Flink 这样的高性能流处理器。这种系统非常适合用于 构建微服务。

1. 　数据流作为中心数据源

流处理架构的核心是使各种应用程序互连在一 起的消息队列。流处理器（例如 Flink）从消息队列中订阅数据 并加以处理。处理后的数据可以流向另一个消息队列。这样一来，其他应 用程序（包括其他 Flink 应用程序）都可以共享流数据。在一些情况下，处 理后的数据会被存放在本地数据库中

流的跨地域复制

流处理架构并不是玩具：它被用于具有重要使命的系统，这些系统要求流 处理层和消息传输层具备一些特性。许多关键的业务系统依靠跨数据中心 的一致性，它们不仅需要高效的流处理层，更需要消息传输层拥有可靠的 跨地域复制能力。例如，电信公司需要在移动通信基站、用户和处理中心 之间共享数据；金融机构需要快速、准确地在相隔很远的办公室之间复制 数据，同时控制成本。

具体来说，数据中心之间的数据复制需要保存消息偏移量，这一点最有用， 因为它使得任何数据中心的更新都可以被传播到其他数据中心，且允许双 向和循环的数据复制。如果消息偏移量没有被保存，那么另一个数据中心 就无法可靠地重启程序。如果不允许其他数据中心更新数据，那么就必须 设计可靠的主节点。循环复制则可以避免复制过程出现单点故障。