[转]为何选择 Flink

本文转自：https://www.ituring.com.cn/book/tupubarticle/23229

第 1 章　为何选择 Flink

人们对某件事的正确理解往往来自基于有效论据的结论。要获得这样的结论，最有效的方法就是沿着事件发生的轨迹进行分析。

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

因此，我们自然希望将数据用事件流的方式收集起来并加以处理。但直到目前，这并不是整个行业的标准做法。流处理并非全新的概念，但它确实是一项专业性强且极具挑战性的技术。实际上，企业常见的数据架构仍旧假设数据是有头有尾的有限集。这个假设存在的大部分原因在于，与有限集匹配的数据存储及处理系统建起来比较简单。但是，这样做无疑给那些天然的流式场景人为地加了限制。

我们渴望按照流的方式处理数据，但要做好很困难；随着大规模数据在各行各业中出现，难度越来越大。这是一个属于物理学范畴的难题：在大型分布式系统中，数据一致性和对事件发生顺序的理解必然都是有限的。伴随着方法和技术的演化，我们尽可能使这种局限性不危及商业目标和运营目标。

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

在 Flink 的开发过程中，开发人员着眼于避免其他流处理方法不得不在高效性或者易用性方面所做的妥协。

本书将讨论流处理的一些潜在好处，从而帮助你确定以流为基础的数据处理方法是否适合你自己的商业目标。流处理的一些数据来源以及适用场景可能会让你感到意外。此外，本书还将帮助你理解 Flink 的技术以及这些技术如何克服流处理面临的困难。

本章将介绍人们希望通过分析流数据获得什么，以及在大规模流数据分析过程中面临的困难。本章是关于 Flink 的入门介绍，你可以看到人们平常（包括在生产环境中）是怎么使用它的。

1.1　流处理欠佳的后果

谁需要和流数据打交道呢？首先映入脑海的是从事传感器测量和金融交易的工作人员。对于他们来说，流处理非常有用。但是流数据来源非常广泛，两个常见的例子是：网站获得的能够反映用户行为的点击流数据，以及私有数据中心的机器日志。事实上，流数据来源无处不在，但是从连续事件中获得数据并不意味着可以在批量计算中使用这些数据。如今，处理大规模流数据的新技术正在改变这一状况。

如果说处理大规模流数据是一个历史性难题，我们为什么还要不厌其烦地尝试打造更好的流处理系统呢？在介绍支持流处理的新架构及新技术之前，我们先来谈谈不能很好地处理流数据会有什么后果。

1.1.1　零售业和市场营销

在现代零售业中，网站点击量就代表了销量。网站获得的点击数据可能是大量、连续、不均匀的。用以往的技术很难处理好如此规模的数据。仅是构建批量系统处理这些数据流 1 就很有挑战性：结果很可能是需要一个庞大且复杂的系统。并且，传统的做法还会带来数据丢失、延迟、错误的聚合结果等问题。这样的结果怎能对商业领域有所帮助呢？

1在本书中，“数据流”是指由连续数据组成的流；“流数据”是指数据流中的数据。——译者注

假设你正在向首席执行官汇报上一季度的销售数据，你肯定不想事后因为使用了不准确的数据而不得不向首席执行官更正汇报结果。如果不能良好地处理点击数据，你很可能对网站点击量进行不准确的计算，这将导致广告投放报价和业绩数字不准确。

航空旅客服务业面临同样的挑战：航空公司需要快速、准确地处理从各种渠道获得的大量数据。例如，当为一名旅客办理登机手续时，需要对该旅客的机票预订数据进行核对，还需要核对行李处理信息、航班状态信息和账单信息。如果没有强大的技术来支持流处理，这种规模的数据是很难不出错的。近几年，美国四大航空公司中有三家都出现了大面积的服务中断，这几次故障都可以归咎于大规模实时数据处理失败。

当然，很多相关问题（如怎样避免重复预订酒店或演唱会门票），一般都能够通过有效的数据库操作来解决，但是这种操作相当费钱，也费精力。尤其当数据量增加时，成本会飙升，并且在某些情况下，数据库的反应速度会变得特别慢。由于缺乏灵活性，开发速度受到影响，项目在庞大又复杂或者不断发生变化的系统中进展缓慢。想要在大型系统中处理流数据，并且在保持一致性的同时有效地控制成本，难度非常大。

幸运的是，现代的流处理器经常可以用新的方式解决这些问题，这使得实时处理大规模数据的成本更低。流处理还激发了新的尝试，比如构建一个系统，该系统能够基于顾客当下购买的商品实时给出相关的建议，看看他们是否还需要买一些别的商品。这不代表流处理器替代了数据库（远远不能替代），而是说在数据库处理不好时，流处理器提供了更好的解决方案。这样做也使数据库得以解脱，不用再参与对当前业务状态的实时分析。第 2 章在介绍流处理架构时将对这一转变做更深入的讲解。

1.1.2　物联网

物联网是流数据被普遍应用的领域。在物联网中，低延迟的数据传输和处理，以及准确的数据分析通常很关键。各类仪器中的传感器频繁地获得测量数据，并将它们以流的形式传输至数据中心。在数据中心内，实时或者接近实时的应用程序将更新显示板，运行机器学习模型，发布警告，并就许多不同的服务项目提供反馈。

交通运输业也体现了流处理的重要性。举例来说，先进的列车系统依靠的是传感器测量数据，这些数据从轨道传至列车，再从列车传至沿途的传感器；与此同时，报告也被发送回控制中心。测量数据包括列车的速度和位置，以及轨道周边的状况。如果流数据没有被正确处理，调整意见和警告就不能相应产生，从而也就不能通过对危险状况做出反应来避免事故发生。

另一个例子是“智能”汽车，或称联网汽车，它们通过移动网络将数据传输回制造商。在有些国家（北欧国家、法国和英国，美国则刚开始），联网汽车甚至可以将信息传给保险公司；如果是赛车，信息还可以通过射频链路传送至维修站进行分析。此外，一些智能手机应用程序还支持数百万司机共享实时路况信息。

物联网对公用事业也有影响。相关公司已经开始安装智能计量表，以替换每个月需要人工读数的旧表。智能计量表可以定期将用电量反馈给公司（例如每 15 分钟一次）。有些公司正在尝试每 30 秒就进行一次测量。使用智能计量表的这一转变带来了大量的流数据，同时也获得了大量的潜在收益。其中一个好处就是通过机器学习模型来检测设备故障或者窃电等使用异常。如果不能对流数据进行高吞吐、低延迟和准确的处理，这些新的目标都无法实现。

如果流处理做得不好，其他物联网项目也会遭殃。大型设备，比如风力涡轮机、生产设备和钻井泵，都依赖对传感器测量数据的分析来获得故障警告。如果不能及时地处理好这些设备的流数据，将可能付出高昂的代价，甚至导致灾难性后果。

1.1.3　电信业

电信业是一个特殊的例子，它广泛地应用了基于各种目的而产生的跨地域的事件流数据。如果电信公司不能很好地处理流数据，就不能在某个移动通信基站出现流量高峰前预先将流量分配给其他的基站，也不能在断电时快速做出反应。通过处理流数据来进行异常检测，如检测通话中断或者设备故障，对于电信业来说至关重要。

1.1.4　银行和金融业

因为流处理做得不好而给银行以及金融业带来的潜在问题是极其显著的。从事零售业务的银行不希望客户交易被延迟或者因为错误统计而造成账户余额出错。曾有一个说法叫作“银行家工作时间”，指的就是银行需要在下午早早关门进行结算，这样才能保证第二天营业之前算出准确的账。这种批量作业的营业模式早已消失。如今，交易和报表都必须快速且准确地生成；有些新兴的银行甚至提供实时的推送通知，以及随时随地访问手机银行的服务。在全球化经济中，能够提供 24 小时服务变得越来越重要。

那么，如果缺少能够灵敏地实时检测出用户行为异常的应用程序，会对金融机构带来什么后果呢？信用卡欺诈检测需要及时的监控和反馈。对异常登录的检测能发现钓鱼式攻击，从而避免巨大的损失。

　在许多情况下，人们希望用低延迟或者实时的流处理来获得数据的高时效性，前提是流处理本身是准确且高效的。

1.2　连续事件处理的目标

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

2对 exactly-once 的解释，详见 5.1 节。——编者注

与此同时，获得这种程度的容错性所采用的技术还需要在没有数据错误的情况下不产生太大的开销。这种技术需要能够基于事件发生的时间（而不是随意地设置处理间隔）来保证按照正确的顺序跟踪事件。对于开发人员而言，不论是写代码还是修正错误，系统都要容易操作和维护。同样重要的是，系统生成的结果需要与事件实际发生的顺序一致，比如能够处理乱序事件流（一个很不幸但无法避免的事实），以及能够准确地替换流数据（在审计或者调试时很有用）。

1.3　流处理技术的演变

分开处理连续的实时数据和有限批次的数据，可以使系统构建工作变得更加简单，但是这种做法将管理两套系统的复杂性留给了系统用户：应用程序的开发团队和 DevOps 团队需要自己使用并管理这两套系统。

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

Lambda 架构概述：优势和局限性

对低成本规模化的需求促使人们开始使用分布式文件系统，例如 HDFS 和基于批量数据的计算系统（MapReduce 作业）。但是这种系统很难做到低延迟。用 Storm 开发的实时流处理技术可以帮助解决延迟性的问题，但并不完美。其中的一个原因是，Storm 不支持 exactly-once 语义，因此不能保证状态数据的正确性，另外它也不支持基于事件时间的处理。有以上需求的用户不得不在自己的应用程序代码中加入这些功能。

后来出现了一种混合分析的方法，它将上述两个方案结合起来，既保证低延迟，又保障正确性。这个方法被称作 Lambda 架构，它通过批量 MapReduce 作业提供了虽有些延迟但是结果准确的计算，同时通过 Storm 将最新数据的计算结果初步展示出来。

Lambda 架构是构建大数据应用程序的一种很有效的框架，但它还不够好。举例来说，基于 MapReduce 和 HDFS 的 Lambda 系统有一个长达数小时的时间窗口，在这个窗口内，由于实时任务失败而产生的不准确的结果会一直存在。Lambda 架构需要在两个不同的 API（application programming interface，应用程序编程接口）中对同样的业务逻辑进行两次编程：一次为批量计算的系统，一次为流式计算的系统。针对同一个业务问题产生了两个代码库，各有不同的漏洞。这种系统实际上非常难维护。

　若要依靠多个流事件来计算结果，必须将数据从一个事件保留到下一个事件。这些保存下来的数据叫作计算的状态。准确处理状态对于计算结果的一致性至关重要。在故障或中断之后能够继续准确地更新状态是容错的关键。

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

更重要的是，使用微批处理方法，可以实现 exactly-once 语义，从而保障状态的一致性。如果一个微批处理作业失败了，它可以重新运行。这比连续的流处理方法更容易。Storm Trident 是对 Storm 的延伸，它的底层流处理引擎就是基于微批处理方法来进行计算的，从而实现了 exactly-once 语义，但是在延迟性方面付出了很大的代价。

然而，通过间歇性的批处理作业来模拟流处理，会导致开发和运维相互交错。完成间歇性的批处理作业所需的时间和数据到达的时间紧密耦合，任何延迟都可能导致不一致（或者说错误）的结果。这种技术的潜在问题是，时间由系统中生成小批量作业的那一部分全权控制。Spark Streaming 等一些流处理框架在一定程度上弱化了这一弊端，但还是不能完全避免。另外，使用这种方法的计算有着糟糕的用户体验，尤其是那些对延迟比较敏感的作业，而且人们需要在写业务代码时花费大量精力来提升性能。

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

于是，Flink 出现了。这一数据处理器可以避免上述弊端，并且拥有所需的诸多功能，还能按照连续事件高效地处理数据。Flink 的一些功能如图 1-2 所示。

图 1-2：Flink 的一个优势是，它拥有诸多重要的流式计算功能。其他项目为了实现这些功能，都不得不付出代价。比如，Storm 实现了低延迟，但是在作者撰写本书时还做不到高吞吐，也不能在故障发生时准确地处理计算状态；Spark Streaming 通过采用微批处理方法实现了高吞吐和容错性，但是牺牲了低延迟和实时处理能力，也不能使窗口与自然时间相匹配，并且表现力欠佳

与 Storm 和 Spark Streaming 类似，其他流处理技术同样可以提供一些有用的功能，但是没有一个像 Flink 那样功能如此齐全。举例来说，Apache Samza（以下简称 Samza）是早期的一个开源流处理器，它不仅没能实现 exactly-once 语义，而且只能提供底层的 API；同样，Apache Apex 提供了与 Flink 相同的一些功能，但不全面（比如只提供底层的 API，不支持事件时间，也不支持批量计算）。这些项目没有一个能和 Flink 在开源社区的规模上相提并论。

下面来了解 Flink 是什么，以及它是如何诞生的。

1.4　初探Flink

Flink 的主页 3 在其顶部展示了该项目的理念：“Apache Flink 是为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架。”Flink 不仅能提供同时支持高吞吐和 exactly-once 语义的实时计算，还能提供批量数据处理，这让许多人感到吃惊。鱼与熊掌并非不可兼得，Flink 用同一种技术实现了两种功能。

3http://flink.apache.org

这个顶级的 Apache 项目是怎么诞生的呢？Flink 起源于 Stratosphere 项目，Stratosphere 是在 2010~2014 年由 3 所地处柏林的大学和欧洲的一些其他的大学共同进行的研究项目。当时，这个项目已经吸引了一个较大的社区，一部分原因是它出现在了若干公共开发者研讨会上，比如在柏林举办的 Berlin Buzzwords，以及在科隆举办的 NoSQL Matters，等等。强大的社区基础是这个项目适合在 Apache 软件基金会中孵化的一个原因。

2014 年 4 月，Stratosphere 的代码被复制并捐献给了 Apache 软件基金会，参与这个孵化项目的初始成员均是 Stratosphere 系统的核心开发人员。不久之后，创始团队中的许多成员离开大学并创办了一个公司来实现 Flink 的商业化，他们为这个公司取名为 data Artisans。在孵化期间，为了避免与另一个不相关的项目重名，项目的名称也发生了改变。Flink 这个名字被挑选出来，以彰显这种流处理器的独特性：在德语中，flink 一词表示快速和灵巧。项目采用一只松鼠的彩色图案作为 logo，这不仅因为松鼠具有快速和灵巧的特点，还因为柏林的松鼠有一种迷人的红棕色。

图 1-3：左侧：柏林的红松鼠拥有可爱的耳朵；右侧：Flink 的松鼠 logo 拥有可爱的尾巴，尾巴的颜色与 Apache 软件基金会的 logo 颜色相呼应。这是一只 Apache 风格的松鼠！

这个项目很快完成了孵化，并在 2014 年 12 月一跃成为 Apache 软件基金会的顶级项目。作为 Apache 软件基金会的 5 个最大的大数据项目之一，Flink 在全球范围内拥有 200 多位开发人员，以及若干公司中的诸多上线场景，有些甚至是世界 500 强的公司。在作者撰写本书的时候，共有 34 个 Flink 线下聚会在世界各地举办，社区大约有 12 000 名成员，还有众多 Flink 演讲者参与到各种大数据研讨会中。2015 年 10 月，第一届 Flink Forward 研讨会在柏林举行。

批处理与流处理

Flink 是如何同时实现批处理与流处理的呢？答案是，Flink 将批处理（即处理有限的静态数据）视作一种特殊的流处理。

Flink 的核心计算构造是图 1-4 中的 Flink Runtime 执行引擎，它是一个分布式系统，能够接受数据流程序并在一台或多台机器上以容错方式执行。Flink Runtime 执行引擎可以作为 YARN（Yet Another Resource Negotiator）的应用程序在集群上运行，也可以在 Mesos 集群上运行，还可以在单机上运行（这对于调试 Flink 应用程序来说非常有用）。

图 1-4：Flink 技术栈的核心组成部分。值得一提的是，Flink 分别提供了面向流处理的接口（DataStream API）和面向批处理的接口（DataSet API）。因此，Flink 既可以完成流处理，也可以完成批处理。Flink 支持的拓展库涉及机器学习（FlinkML）、复杂事件处理（CEP），以及图计算（Gelly），还有分别针对流处理和批处理的 Table API

能被 Flink Runtime 执行引擎接受的程序很强大，但是这样的程序有着冗长的代码，编写起来也很费力。基于这个原因，Flink 提供了封装在 Runtime 执行引擎之上的 API，以帮助用户更方便地生成流式计算程序。Flink 提供了用于流处理的 DataStream API 和用于批处理的 DataSet API。值得注意的是，尽管 Flink Runtime 执行引擎是基于流处理的，但是 DataSet API 先于 DataStream API 被开发出来，这是因为工业界对无限流处理的需求在 Flink 诞生之初并不大。

DataStream API 可以流畅地分析无限数据流，并且可以用 Java 或者 Scala 来实现。开发人员需要基于一个叫 DataStream 的数据结构来开发，这个数据结构用于表示永不停止的分布式数据流。

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

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

因为不用再在编写应用程序代码时考虑如何解决问题，所以工程师的时间得以充分利用，整个团队也因此受益。好处并不局限于缩短开发时间，随着灵活性的增加，团队整体的开发质量得到了提高，运维工作也变得更容易、更高效。Flink 让应用程序在生产环境中获得良好的性能。尽管相对较新，但是 Flink 已经在生产环境中得到了应用，下一节将做更详细的介绍。

1.5　生产环境中的Flink

本章旨在探讨为何选择 Flink。一个好的方法是听听在生产环境中使用 Flink 的开发人员解释他们选择 Flink 的原因，以及如何使用它。

1.5.1　布衣格电信

布衣格电信（Bouygues Telecom）是法国第三大移动通信运营商，隶属世界 500 强企业布衣格集团。布衣格电信使用 Flink 来进行实时事件处理，每天不间断地分析数十亿条消息。2015 年 6 月，在为 data Artisans 的博客撰写的文章中，Mohamed Amine Abdessemed4 描述了布衣格电信的目标以及 Flink 为什么能实现这些目标。

4他在布衣格电信负责技术系统。——编者注

……布衣格电信最终选择了 Flink，因为它支持真正的流处理——通过上层的 API 和下层的执行引擎都能实时进行流处理，这满足了我们对可编程性和低延迟的需求。此外，使用 Flink，我们的系统得以快速上线，这是其他任何一种方案都做不到的。如此一来，我们就有了更多的人手开发新的业务逻辑。

Mohamed Amine Abdessemed 在于 2015 年 10 月举行的 Flink Forward 研讨会上也做了报告。布衣格电信试图给其工程师实时提供关于用户体验的反馈，让他们了解公司遍布全球的网络正在发生什么，并从网络的演进和运行的角度掌握发展动向。

为了实现这个目标，他们的团队搭建了一个用来分析网络设备日志的系统，它定义了衡量用户体验质量的各项指标。该系统每天处理 20 亿次事件，要求端到端延迟不超过 200 毫秒（包括由传输层负责的消息发布和由 Flink 操作的数据处理）。这些都在一个仅有 10 个节点（每个节点 1GB 内存）的小集群上完成。布衣格电信还希望这些经过部分处理的数据能被复用，从而在互不干扰的前提下满足各种商业智能分析需求。

该公司打算利用 Flink 的流处理能力来转换和挖掘数据。加工后的数据被推送回消息传输系统，以保证数据可以被不同的用户使用。

相比于其他处理方案，比如在数据进入消息队列之前进行处理，或者将数据分派给消费同一个消息队列的多个应用程序来分头处理，Flink 的处理方案更合适。

布衣格电信利用 Flink 的流处理能力完成了数据处理和数据迁移，它既满足了低延迟的要求，又具有很高的可靠性、可用性，以及易用性。Flink 为调试工作提供了极大的便利，甚至支持切换到本地进行调试。它也支持程序可视化，有利于理解程序的运行原理。此外，Flink 的 API 吸引了很多开发人员和数据科学家。Mohamed Amine Abdessemed 在其文章中还提及布衣格电信的其他团队使用 Flink 解决了不同的问题。

1.5.2　其他案例

King公司

King 公司的游戏非常流行，全世界几乎每时每刻都有人在玩它的在线游戏。作为在线娱乐行业的佼佼者，该公司称自己已经开发了 200 多款游戏，市场覆盖 200 多个国家和地区。

King 公司的工程师曾在一篇博客文章中写道：“我们每月有超过 3 亿的独立用户，每天从不同的游戏和系统中收到 300 亿次事件，基于这么大的数据量做任何流分析都是真正的技术挑战。因此，为我们的数据分析师开发工具来处理如此大规模的流数据，同时保证数据在应用中具有最大的灵活性，这些对于公司而言至关重要。”

King 公司用 Flink 构建的系统让其数据分析师得以实时地获取大量的流数据。Flink 的成熟度给他们留下了深刻的印象。即使面对像 King 公司这样复杂的应用环境，Flink 也能很好地提供支持。

Zalando公司

作为欧洲领先的在线时尚平台，Zalando 公司在全球拥有超过 1600 万的客户。该公司的网站将其组织结构描述为“多个敏捷、自主的小型团队”（换句话说，该公司采用了微服务架构）。

流处理架构为微服务提供了良好的支持。因此，Flink 提供的流处理能力满足了这种工作模式的需求，特别是支持业务流程监控和持续的 ETL5 过程。

5ETL 是 Extract、Transform 和 Load 的缩写，即抽取、转换和加载。——编者注

Otto集团

Otto 集团是全球第二大 B2C（business to consumer，企业对顾客电子商务）在线零售商，也是欧洲时尚和生活领域最大的 B2C 在线零售商。

它的商业智能部门在最初开始评估开源流处理平台时，没有找到一种能够符合其要求的平台，所以后来决定开发自己的流处理引擎。但是当试过 Flink 之后，该部门发现 Flink 满足了他们对流处理的所有需求，包括对众包用户代理的鉴定，以及对检索事件的辨识。

ResearchGate

从活跃用户的数量上看，ResearchGate 是最大的学术社交网络。它从 2014 年开始使用 Flink 作为其数据基础设施的一个主要工具，负责批处理和流处理。

阿里巴巴集团

阿里巴巴这个庞大的电子商务集团为买方和卖方提供平台。其在线推荐功能是通过基于 Flink 的系统 Blink 实现的。用户当天所购买的商品可以被用作在线推荐的依据，这是使用像 Flink 这样真正意义上的流处理引擎能够带来的好处之一。并且，这在那些用户活跃度异常高的特殊日期（节假日）尤其重要，也是高效的流处理相较于批处理的优势之一。

1.6　Flink的适用场景

本章开头提出了“为何选择 Flink”这一问题。比这个问题更大的则是“为何要用流数据？”本章解释了一些原因，比如在许多情况下，我们都需要观察和分析连续事件产生的数据。与其说流数据是特别的，倒不如说它是自然的——只不过从前我们没有流处理能力，只能做一些特殊的处理才能真正地使用流数据，比如将流数据攒成批量数据再处理，不然无法进行大规模的计算。使用流数据并不新鲜，新鲜的是我们有了新技术，从而可以大规模、灵活、自然和低成本地使用它们。

Flink 并不是唯一的流处理工具。人们正在开发和改进多种新兴的技术，以满足流处理需求。显然，任何一个团队选择某一种技术都是出于多方面的考虑，包括团队成员的已有技能。但是 Flink 的若干优点、易用性，以及使用它所带来的各种好处，使它变得非常有吸引力。另外，不断壮大且非常活跃的 Flink 社区也暗示着它值得一试。你会发现“为何选择 Flink”这个问题变成了“为何不选择 Flink 呢？”

在深入探讨 Flink 的工作原理之前，我们先来通过第 2 章了解如何设计数据架构才能从流处理中充分获益，以及流处理架构是如何带来诸多好处的。