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

AI前线导读&＃xff1a;

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

更多干货内容请关注微信公众号“AI前线”&＃xff08;ID&＃xff1a;ai-front&＃xff09;

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

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

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

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

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

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

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

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

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

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

在其他项目做不到的地方&＃xff0c;Flink却取得了成功。

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

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

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

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

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

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

英文原文&＃xff1a;
https://data-artisans.com/blog/early-observations-apache-flink

会议推荐&＃xff1a;