Jeff Bean 谈 Flink 与流式处理的 5 大新发现

公众号/AI前线

作者｜Jeff Bean

译者｜无明

编辑｜Debra

AI 前线导读：

在大数据领域工作了近 8 年后，今年秋天，作为 data Artisans 的技术布道师，我在 Apache Flink 社区变得越来越活跃。在十月份举行的湾区 Flink 座谈会上，我从技术从业者的角度讨论了我对 Flink 的看法。虽然我是一名 Flink 新手，但我已经在大数据领域工作了很长时间。正如我在座谈会上所说的，我对人们这个领域的关注、投入和好奇心感到震惊。回想起来，这符合我对 Apache Flink 和 Apache Flink 社区的总体印象。下面我想介绍有关 Apache Flink 的 5 个早期印象，以及为什么企业应该在他们的流式处理架构中尽早尝试 Flink。

更多干货内容请关注微信公众号“AI 前线”（ID：ai-front）

流式处理一直是大数据项目的必经之路。

我在 2010 年进入大数据领域，当时最先进的是分布式文件系统，MapReduce、Hive、Pig、Flume 和 HBase。然而，低延迟数据处理长期以来一直是一个巨大的挑战。例如，在我进入该领域工作的头几个月，一位客户问我如何在 Hive 中对一个不断增长的表基于五分钟滚动窗口产生最新的聚合。这是一个非常困难的查询，客户和我都没有想出来该怎么做。MapReduce、Hive、Pig 和后来的 Spark 使用越来越小的批处理操作来处理大量不同数据，获得接近低延迟的结果。一些框架如 Flume 和后来的 Kafka 让数据摄取、封装和传输变得更容易。其他查询系统（如 HBase、Cassandra、Presto 和 Impala）可以近似实时地对新近摄取的数据进行交互式访问。但是，所有这些项目都忽略了客户和业务用户真正的需求：将数据表示为流，并基于流进行复杂有状态的分析。客户和最终用户通过各种有趣且昂贵的方式与延迟做斗争。

Apache Flink 在 2018 年的增长非常惊人。

最近 Qubole 的一份调查报告显示，Apache Flink 是 2018 年大数据和 Hadoop 生态系统中发展最快的引擎，与 2017 年的类似调查相比，采用量增长了 125％。这种采用率的提升给人造成了一种很强烈的印象，Datanami 网站的两篇与 Flink 不相关的文章中都提到了它。其中一篇感叹大数据生态系统变得日益复杂，涉及的项目呈爆发式的增长，以及在应用场景中采用了错误技术所涉及的风险，但又不遗余力地说明了 Flink 在采用方面的惊人增长。另一篇有关 Cloudera Mike Olson 的文章讨论了这个领域从“动物园动物争吵”到解决企业问题的演变，但它仍然给 Flink 的采用量增长点了一个赞。有时候，动物园里最好的动物不一定是你所期望的那个。

值得注意的是，虽然 data Artisans 支持 Flink，销售 Flink 相关的产品，并聘请了很多原始作者和提交者，但现今 Flink 的大部分采用都发生在 data Artisans 公司之外，比如 Netflix、阿里巴巴、Uber 和 Lyft，等等。

Flink 的分层抽象非常具有表现力，让你能够自然地概念化你的数据。

在使用 Hadoop 项目（如 MapReduce）多年之后，将流、状态、时间和快照的构造作为事件处理的构建块而不是键、值和执行阶段这些不完整的概念，这令人耳目一新。我的印象是 Flink 在接口以及这些接口如何与底层平台的功能相关联方面是最具表现力的。例如，SQL 接口支持滚动窗口和复杂事件处理。如下图的滚动时间窗口示例所示——几年前我们还很那做到这些——但现在却可以使用简单的 SQL 来表示。图中还显示了流式 API 和 processFunction 抽象级别的相似表现力。

我们看到了包装最佳实践的出现。

供应商可以为活跃的开源项目带来价值的一个地方是在精心构建的产品中包装专业知识和最佳实践。采用率较高的开源项目在选择性和可配置性方面变得更加广泛，因为它们运行在特定的生产环境中。

data Artisans 根据他们自己的经验以及 Flink 用户社区已经建立起的最佳实践包装了一些观点。例如，在部署方面，Apache Flink 支持 YARN、Mesos、Kubernetes 和独立部署。同样，Flink 的最终用户倾向于运行基于 Flink 的应用程序而不是 Flink 作业，这是 Flink 中可用的最高执行抽象。data Artisans 为 Flink 引入了应用程序的概念，可在 Kubernetes 上部署 Flink，包装了一个非常有用又可扩展的一集群一作业对应一个应用程序的最佳实践。这些简单的决策和包装的最佳实践有助于更早从 Flink 的采用中获得价值，从而让用户无需一次又一次地解决同类问题。因为包装了最佳实践，data Artisans Platform Application Manager 不仅适用于生产部署：它也适用于开始应用 Flink。

在其他项目做不到的地方，Flink 却取得了成功。

Flink 的流式处理有很多很好的生产应用场景。你可以从阿里巴巴、Netflix、Lyft、Uber、DriveTribe 等公司那里了解更多有关它们通过采用 Flink 来满足它们的业务对流式处理的需求。我注意到，在在采用 Flink 之前，总是先尝试一下其他的项目。

阿里巴巴在参考另一个项目的微批处理范式时，“第一种方法是使用批处理作为起点，然后尝试在批处理之上进行流式处理。但是，这可能无法满足他们对延迟的严格要求，因为模拟流的微批处理需要一些固定的开销——所以当你尝试减少延迟时，开销的比例会增加。

在 Flink Forward 演讲中，来自 Netflix 的 Shriya Arora 说道：“从历史上看，我们已经通过批量的方式连接了大量数据集。然而，我们会问自己，数据是否是实时生成的，为什么不能在下游进行实时处理？”

同样，在讨论他们基于 Flink 的平台 AthenaX 时，Uber 写道，他们在采用 Flink 之前尝试了 Apache Storm 和 Apache Samza，“然而，这些解决方案还不够理想。用户要么被迫实现、管理和监控他们自己的流式分析应用程序，要么只能为预先定义的一组问题获取答案。”

在我看来，乍一看，微批次处理、lambda 架构、辅助流式处理技术和替代流式处理项目等架构似乎都可以……直到有人从痛苦的经历中发现，低延迟处理和复杂分析无法通过廉价、可扩展和容错的方式来实现。

因此，我的建议是不要让自己在一开始就被困在错误的技术采用的痛苦中，而是尽早尝试使用 Flink 来解决你的流式处理问题。从 Flink 的采用模式来看，很多人走了弯路。

英文原文：

Years in Big Data. Months with Apache Flink. 5 Early Observations With Stream Processing