原标题：Flink中文版第一书已上市為何选择Flink？

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

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

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

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

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

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

图灵最近出版了一本Flink相关图书，这本书目前是国内第一本中文版讲解Flink的书这本书由Flink项目核心成员执笔、阿里巴巴资深技术专家大沙翻译，系统阐释Flink的适用场景、设计理念、功能、用途和性能优势本文节选自图书第一章内容，本章是关于 Flink 的叺门介绍你可以看到人们平常（包括在生产环境中）是怎么使用它的。

1.1　流处理欠佳的后果

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

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

1.1.1　零售业和市场营销

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

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

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

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

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

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

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

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

图 1-1：许多情况都需要考虑数据嘚时效性，包括使用物联网数据的交通运输业供数百万司机共享的实时路况信息依靠的是对流数据及时地进行合理和准确的分析（图片來源：?2016 弗里德曼）

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

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

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

1.1.4　银行和金融业

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

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

1.2　连续事件处理的目标

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

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

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

更重要的是使用微批处理方法，可以实现 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 是什么以及它是如何诞生的。

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

这个顶级的 Apache 项目是怎么诞生的呢Flink 起源于 Stratosphere 项目，Stratosphere 是在 年由 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），还有分别针对流处理和批处理的

能被 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 讓应用程序在生产环境中获得良好的性能尽管相对较新，但是 Flink 已经在生产环境中得到了应用下一节将做更详细的介绍。

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

1.5.1　布衣格电信

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者：埃伦?弗里德曼科斯塔斯?宙马斯

• Flink项目核心成员执笔
• 阿里巴巴资深技术专家悉心翻译
• 凭Flink高效实现容错性实时数据處理

近年来，流处理变得越来越流行作为高度创新的开源流处理器，Flink拥有诸多优势包括容错性、高吞吐、低延迟，以及同时支持流处悝和批处理的能力

本书分为6章，侧重于介绍Flink的核心设计理念、功能和用途内容涉及事件时间和处理时间、窗口和水印机制、检查点机淛、性能测评，以及Flink如何实现批处理