flink 的用途场景

flink 的用途

Flink为流处理器开辟了新的用武之地，它使流处理架构变得完整。它的一大优势便是，使应用程序的构建过程符合自然规律。为了了解Flink的用途及用法，我们来看一看令它具有多用途的几个核心特点，特别是它如何保障数据的正确性。

1　不同类型的正确性，Flink如何正确地进行流处理，以及保障正确性到底意味着什么。人们往往将正确性等同于准确性——以计数为例，计数结果是否“正确”？这个例子很好地诠释了正确性，但是正确性的影响因素很多，当思考计算怎样才能契合需要建模和分析的场景时，更是如此。换句话说，在处理数据时，需要解决这几个问题：“我需要什么？”“我期望什么？”“我在什么时候需要得到结果？”

2　符合产生数据的自然规律流处理器（尤其是Flink）的正确性体现在计算窗口的定义符合数据产生的自然规律。举个例子，通过点击流数据追踪某网站的3个访问者（图中的A、B和C）的活动。对于每个访问者来说，活动是不连续的。在访问时间段内，事件数据被收集起来；当访问者起身去喝茶或喝咖啡时，或者当他们因为老板从身边经过而切换回工作页面时，数据就产生了间隙。处理框架能够将访问者行为分析的计算窗口与实际的访问时间段吻合到什么程度？换句话说，计算窗口与会话窗口吻合吗？首先让我们来看看，当访问者行为分析通过微批处理方法或者固定的计算窗口来处理时，会发生什么情况，

如图所示：（采用微批处理方法时，很难使计算窗口（虚线所示）与会话窗口（长方形所示）吻合）

由微批处理方法得到的计算窗口是人为设置的，因此很难与会话窗口吻合。使用Flink的流处理API，可以更灵活地定义计算窗口，因此这个问题迎刃而解。举个例子，开发人员可以设置非活动阈值，若超过这个阈值（例如5分钟），就可以判断活动结束。下图展示了这种开窗方式。

Flink的流处理能力能够使计算窗口与会话窗口吻合。如图所示，计算窗口随间隙出现。在本例中，相邻事件之间都有间隙，间隙的时长都超过了预先定义的阈值Flink能做到这一点的根本原因是，它可以根据真实情况设置计算窗口。

事件时间

一般而言，流处理架构不常采用事件时间，尽管越来越多的人这样做。Flink能够完美地做到这一点，这在实现计算的正确性上非常有用。为了获得最佳的计算结果，系统需要能够通过数据找到事件发生的时间，而不是只采用处理时间。Flink理解事件时间的这种能力保障了正确性。2016年，时任dataArtisans公司应用工程总监的JamieGrier在OSCON大会上展示了这一点。他通过生成的数据模拟压力传感器的测量结果，并写了一个Flink程序来计算以1秒为计算窗口、每秒内正弦波的数值之和。正确的结果是0。他比较了用处理时间划分窗口和用事件时间划分窗口的差别。采用处理时间时，结果总是或多或少地有些偏差；采用事件时间时，则总是可以获得正确的结果，

如图:

处理时间

从处理时间切换到事件时间，让许多计算工作完成得更好。用处理时间来计算会导致错误，用事件时间则能得到正确的结果（与其他流处理系统相比，Flink的一个优势就是能区分不同类型的时间。

发生故障后仍保持准确

若想使计算保持准确，就必须跟踪计算状态。如果计算框架本身不能做到这一点，就必须由应用程序的开发人员来完成这个任务。连续的流处理很难跟踪计算状态，因为计算过程没有终点。实际上，对状态的更新是持续进行的。Flink解决了可能影响正确性的几个问题，包括如何在故障发生之后仍能进行有状态的计算。Flink所用的技术叫作检查点（checkpoint），在每个检查点，系统都会记录中间计算状态，从而在故障发生时准确地重置。这一方法使系统以低开销的方式拥有了容错能力——当一切正常时，检查点机制对系统的影响非常小。值得注意的是，检查点也是Flink能够按需重新处理数据的关键所在。毕竟，并不是只有在发生故障之后才会重新处理数据。比如，在运行新模型或者修复bug时，就可能需要重播并重新处理事件流数据。Flink成全了这些操作。　

Flink的检查点特性在流处理器中是独一无二的，它使得Flink可以准确地维持状态，并且高效地重新处理数据.

及时给出所需结果

Flink能够满足低延迟应用程序的需要，将这算作一种正确性可能出人意料。我们换个角度看看：有些计算结果或许很准确，例如求和或者求平均值的结果，但是如果没有及时地取得结果，那么很难说它们是正确的。举一个例子，假设你在开车上班的途中想通过智能手机上的实时路况查询及导航应用程序选择一条畅通的路，如果应用程序花了2小时才把查询结果发给你，那么结果再准确也是无用的。哪怕只有5秒钟的延迟也足以造成麻烦，因为你可能已经拐错了弯。可见，在某些情况下，极低的延迟非常重要，它决定了系统能够及时地给出所需结果，而不仅仅是完成计算。Flink的实时且容错的流处理能力可以满足这类需求。

使开发和运维更轻松

Flink与用户交互的接口也有助于保障正确性。完备的语义简化了开发工作，进而降低了出错率。此外，Flink还承担了跟踪计算状态的任务，从而减轻了开发人员的负担，简化了编程工作，并提高了应用程序的成功率。用同一种技术来实现流处理和批处理，大大地简化了开发和运维工作。

分阶段采用Flink

尽管Flink拥有非常丰富的功能，并能处理极为复杂的数据，但是没有必要为了采用Flink而彻底抛弃其他技术。流处理架构可以分步来实现。有些公司在引入流处理架构时，先实现简单的应用程序，等到熟悉后再推广。虽然试点应用程序的类型完全取决于公司的需求，但是许多公司都有相似的流处理“价值链”。

对时间的处理

用流处理器编程和用批处理器编程最关键的区别在于对时间的处理。举一个非常简单的例子：计数。事件流数据（如微博内容、点击数据和交易数据）不断产生，我们需要用key将事件分组，并且每隔一段时间（比如一小时）就针对每一个key对应的事件计数。这是众所周知的“大数据”应用，与MapReduce的词频统计例子相似。

采用批处理架构和Lambda架构

计数尽管看起来简单，但是大规模的计数任务在实践中出人意料地困难。当然，计数无处不在。针对联机分析处理多维数据集的聚合或其他操作，都可以简单地归结为计数。图41展示了如何采用传统的批处理架构实现计数任务。

在该架构中，持续摄取数据的管道每小时创建一次文件。这些文件通常被存储在HDFS或MapRFS等分布式文件系统中。像ApacheFlume这样的工具可以用于完成上述工作。由调度程序安排批处理作业（如MapReduce作业）分析最近生成的一个文件（将文件中的事件按key分组，计算每个key对应的事件数），然后输出计数结果。对于每个使用Hadoop的公司来说，其集群都有多个类似的管道。这种架构完全可行，但是存在以下问题。太多独立的部分。为了计算数据中的事件数，这种架构动用了太多系统。每一个系统都有学习成本和管理成本，还可能存在bug。对时间的处理方法不明确。假设需要改为每30分钟计数一次。这个变动涉及工作流调度逻辑（而不是应用程序代码逻辑），从而使DevOps问题与业务需求混淆。预警。假设除了每小时计数一次外，还需要尽可能早地收到计数预警（比如在事件数超过10时预警）。为了做到这一点，可以在定期运行的批处理作业之外，引入Storm来采集消息流（Kafka或者MapRStreams）。Storm实时提供近似的计数，批处理作业每小时提供准确的计数。但是这样一来，就向架构增加了一个系统，以及与之相关的新编程模型,上述架构叫作Lambda架构.

Lambda架构用定期运行的批处理作业来实现应用程序的持续性，并通过流处理器获得预警。流处理器实时提供近似结果；批处理层最终会对近似结果予以纠正乱序事件流。在现实世界中，大多数事件流都是乱序的，即事件的实际发生顺序（事件数据在生成时被附上时间戳，如智能手机记录下用户登录应用程序的时间）和数据中心所记录的顺序不一样。这意味着本属于前一批的事件可能被错误地归入当前一批。批处理架构很难解决这个问题，大部分人则选择忽视它。批处理作业的界限不清晰。在该架构中，“每小时”的定义含糊不清，分割时间点实际上取决于不同系统之间的交互。充其量也只能做到大约每小时分割一次，而在分割时间点前后的事件既可能被归入前一批，也可能被归入当前一批。将数据流以小时为单位进行分割，实际上是最简单的方法。假设需要根据产生数据的时间段（如从用户登录到退出）生成聚合结果，而不是简单地以小时为单位分割数据，则用上面的图的架构无法直接满足需求。

采用流处理架构计数

当然有更好的办法来对事件流进行计数。如你所想，计数是流处理用例，上一节只是使用定期运行的批处理作业来模拟流处理。此外，必须把各种系统耦合在一起。下图展示了采用流处理架构的应用程序模型。

通过流处理架构实现应用程序的持续性。水平圆柱体表示消息传输系统（Kafka或MapRStreams）。消息传输系统为负责处理所有数据的流处理器（在本例中是Flink）提供流数据，产生的结果既是实时的，也是正确的事件流由消息传输系统提供，并且只被单一的Flink作业处理，从而以小时为单位计数和预警（后者可选）。这种方法直接解决了上一节提到的所有问题。Flink作业的速度减慢或者吞吐量激增只会导致事件在消息传输系统中堆积。以时间为单位把事件流分割为一批批任务（称作窗口），这种逻辑完全嵌入在Flink程序的应用逻辑中。预警由同一个程序生成，乱序事件由Flink自行处理。要从以固定时间分组改为根据产生数据的时间段分组，只需在Flink程序中修改对窗口的定义即可。此外，如果应用程序的代码有过改动，只需重播Kafka主题，即可重播应用程序。采用流处理架构，可以大幅减少需要学习、管理和编写代码的系统。Flink应用程序用来计数的代码非常简单，如下所示。
DataStream<LogEvent>stream=env

//通过Kafka生成数据流

.addSource(newFlinkKafkaConsumer(...))

//分组

.keyBy("country")

//将时间窗口设为60分钟

.timeWindow(Time.minutes(60))

//针对每个时间窗口进行操作

.apply(newCountPerWindowFunction());

流处理区别于批处理最主要的两点是：流即是流，不必人为地将它分割为文件；时间的定义被明确地写入应用程序代码（如以上代码的时间窗口），而不是与摄取、计算和调度等过程牵扯不清。流处理系统中的批处理第1章讨论过微批处理，它是介于流处理和批处理之间的方法。实际上，微批处理的含义取决于具体情况。从某种角度来说，图41中的批处理架构也可以称为微批处理架构，前提是文件足够小。StormTrident是这样实现微批处理的：它先创建一个大的Storm事件，包含固定数量的子事件；聚合在一