实时处理来自社交媒体流和传感器设备的数据变得越来越普遍&＃xff0c;并且有很多开源解决方案可供选择。 这是我在Strata &＃43; Hadoop World 上所做的演示 &＃xff0c;在这里我比较了三个流行的Apache项目&＃xff0c;它们允许您执行流处理&＃xff1a;Apache Storm&＃xff0c;Apache Spark和Apache Samza。 此博客文章是此演示文稿的摘要。 
总体而言&＃xff0c;流处理从根本上来说是简单的……除了它实际上根本不简单之外&＃xff01; 优化是使这些流处理系统正常工作的关键&＃xff0c;以及如何处理这些系统的反压力。 Kafka是这些流处理引擎的常见组件之一&＃xff0c;它们确实有助于提供最大程度的功能。
如果您问三个不同的人&＃xff0c;“哪个流媒体平台最快&＃xff1f;” 您将得到三个不同的答案。 另外&＃xff0c;如果仔细查看用例是什么&＃xff0c;您将开始注意到&＃xff0c;根据用例&＃xff0c;技术和实现方式的不同&＃xff0c;性能和里程也会有所不同。
您可能会认为Storm是自切面包以来最伟大的事情&＃xff0c;或者您可能认为这是自切面包以来最糟糕的事情。 您可能在任何一种实施上都有丰富的经验&＃xff0c;或者您在其他任何一种实施上都具有可怕的经验。 因此&＃xff0c;很难就这些平台之间的真实事实进行良好的对话。
让我们看一下交付模式。 你有&＃xff1a;
- 最多一次 &＃xff0c;您有可能会丢失数据&＃xff0c;您可以接受它&＃xff0c;这没什么大不了的。
- 至少一次 &＃xff0c;可以重新发送邮件&＃xff08;不会丢失&＃xff0c;但是您会重复&＃xff09;。 如果您的数据是幂等的&＃xff0c;那么您就很好。 这是您应该使用的模型&＃xff0c;永远不要考虑一次。
- 恰好一次 &＃xff1a;每封邮件仅发送一次&＃xff0c;且一次&＃xff08;无损失&＃xff0c;无重复&＃xff09;。 如果您的用例需要一次执行&＃xff0c;请非常小心&＃xff0c;因为无论您执行什么操作或如何处理它&＃xff0c;当您开始在分布式系统中处理一次执行的语义时&＃xff0c;复杂性便会突飞猛进。 这就是为什么我对在那里的流处理系统上工作的人表示敬意的原因&＃xff0c;因为他们知道这一点&＃xff0c;并且他们并不在乎这些平台的功能。 告诉您一次准确的操作很容易的人可能会给您打个电话。 这是很难做到的&＃xff0c;当您要转换为一次精确的模型时&＃xff0c;需要做出很大的权衡。 您应该意识到这一点&＃xff0c;并认真考虑如何在用例中利用流处理引擎来满足业务需求。
今日选项– Apache风格
这里要注意的基本事情是这三个都是实时计算系统&＃xff0c;它们是开源的&＃xff0c;低延迟的&＃xff0c;分布式的&＃xff0c;可伸缩的并且具有容错能力。
阿帕奇·萨姆扎&＃xff08;Apache Samza&＃xff09;
Apache Samza可能是最鲜为人知的&＃xff0c;并且它在开放源代码流引擎中的通话时间最少。 我认为这可能是最被低估的。 这项技术汇集了一些东西&＃xff0c;使其非常简单。 我对简单的体系结构很感激&＃xff0c;因为您在体系结构中移动的部分越多&＃xff0c;事情就越复杂。
流和分区
- 流&＃xff1a;不可变的消息
- 每个流包含一个或多个分区
- 分区&＃xff1a;消息的完全有序序列
在处理流媒体时&＃xff0c;我们希望有一种并行化工作的方法。 这是Samza破坏工作的方式-您定义密钥&＃xff0c;对数据进行分区并获得所需的性能。 Samza使用的线程模型与Storm中使用的线程模型不同。 如果您关心的是资源利用&＃xff0c;管理&＃xff0c;能够适当地计划这些作业的资源消耗&＃xff0c;那么您可能应该注意这一点。 这里重要的一点是&＃xff0c;一切总是有序的。
工作与任务
我们拥有的下一个概念是工作和任务。 这实际上是工作程序代码&＃xff0c;这就是要部署和分发的代码。 这是您的业务逻辑有效地发挥作用的地方。
对于熟悉Storm中拓扑的任何人来说&＃xff0c;这与数据流图的概念相似。 它们在功能上相似&＃xff0c;但是在实现方面它们甚至还不接近。 Samza带来的简单性意味着您将在此之前使用Kafka&＃xff0c;因此&＃xff0c;Samza将把所有东西放回到这些舞台闸门之间的Kafka中。
萨姆扎建筑
在部署和运行Samza方面&＃xff0c;您可以将其他资源管理器插入YARN之外。 当前没有其他人插入。您可以在Samza前面插入其他排队系统&＃xff0c;因为目前没有其他实现。
您实际上如何管理此处部署的容器&＃xff1f; 我会再次考虑这点&＃xff0c;因为您的工作被划分了&＃xff0c;很容易预测&＃xff0c;而且您知道事情将要降落在哪里。 从根本上讲&＃xff0c;这是Samza的核心。 我什至无法涵盖很多非常重要的实现细节&＃xff0c;因此请查看下面列出的资源。
Apache Samza资源
- 使用Kafka和Samza进行可扩展的实时数据处理
- LinkedIn如何使用Apache Samza
阿帕奇风暴
Apache Storm在某些方面做得很好&＃xff0c;而在其他方面则做得很痛苦。 风暴基于元组和流。 元组基本上就是您的数据以及数据的结构。 与Spark Streaming相比&＃xff0c;我经常听到Storm。 两者之间最大的根本区别之一是&＃xff0c;Storm像Samza一样处理单个事件&＃xff0c;Spark Streaming则处理微型批次。
上图显示了外观。 在Spark Streaming方面&＃xff0c;从概念上讲&＃xff0c;您可以从概念上认为这些元组的所有概念都只是一个事件。
喷口
展望未来&＃xff0c;我们已经有了Storm的喷口概念。 如果您熟悉Flume&＃xff0c;我认为这是Flume中的资源。 喷口可以与队列&＃xff08;Kafka&＃xff0c;Kestrel等&＃xff09;&＃xff0c;Web日志&＃xff0c;API调用&＃xff0c;文件系统&＃xff08;MapR-FS / HDFS&＃xff09;等对话。
螺栓
螺栓用于处理元组并创建新的流。 您可以通过Transform&＃xff0c;Filter&＃xff0c;Aggregate和Join来实现业务逻辑。 您可以访问数据存储&＃xff0c;数据库和API。 要了解的重要一点是&＃xff0c;不要将所有功能混为一谈&＃xff0c;因为以后将无法混合和匹配这些功能。 您应该将它们分开&＃xff0c;并将它们链接在一起成为拓扑。
拓扑结构
拓扑基本上是喷嘴和螺栓的有向图&＃xff0c;如上所示。 像Samza一样&＃xff0c;如果您想将代码捆绑在一起&＃xff0c;那么您就有一个模型。
流分组
我们得到的下一个概念是流分组概念。 上图显示了两个示例-随机播放和字段。 实际上&＃xff0c;您可以在Storm中使用七种不同的分组模型。 它具有很好的灵活性&＃xff0c;并且事情已经被合理地考虑了。 从概念上讲&＃xff0c;您需要确定消息的处理方式&＃xff0c;消息的去向以及使用的工作人员。 当您查看此模型以了解如何管理即将发生的事件时&＃xff0c;您确实应该通读所有描述以确保您符合期望。 您可以很容易地选择错误的一个&＃xff0c;并通过向每个螺栓发送相同的消息来轰炸您的系统。
任务和工人
从概念上讲&＃xff0c;任务和工作人员与Samza的处理方式根本没有太大不同。 对于一项任务&＃xff0c;每个喷口/螺栓在整个集群中执行的执行线程数相同。 工作程序是物理JVM&＃xff0c;它执行拓扑所有任务的子集。 基于Samza与YARN的原生构建&＃xff0c;它略有不同。
这就是Storm开始变得有趣的地方-我听到很多人谈论Trident&＃xff0c;Trident在Storm上提供了一系列功能&＃xff0c;使其与其他框架相比更具竞争力&＃xff0c;逐个功能。
三叉戟-风暴的“级联”
这里最大的好处是&＃xff0c;您实际上使用Trident获得了一次精确的语义。 如果那对您很重要&＃xff0c;那就很好。 从概念上讲&＃xff0c;发生的事情是将这些Trident拓扑编译为Storm拓扑。 就我个人而言&＃xff0c;我不一定总是喜欢那种必须从一个过渡到另一个的模型。
执行
在执行方面&＃xff0c;要注意的一件事是Storm中的Nimbus概念。 您可能会说Nimbus是单点故障。 从技术上讲是这样&＃xff0c;但是由于它的运行方式&＃xff0c;它并不是真正有害的单点故障。 如果崩溃&＃xff0c;它可以非常快速地旋转回去&＃xff0c;并且对已经运行的任何内容都没有任何下游影响。 尽管这是单点故障&＃xff0c;但对我来说并不是一个大问题。 如果在我的组织中实施它&＃xff0c;那可能将是我对实施Storm的最低关注之一。
请仔细阅读下面列出的Apache Storm资源&＃xff0c;因为这里没有很多与Storm相关的细节。
Apache Storm资源
- 使用Apache Storm进行实时分析
- 应用Storm&＃xff1a;实时事件处理策略
- 用于Storm的简单聚合器
阿帕奇火花
Spark Streaming获得了一些出色的采用&＃xff0c;部分原因是它与Spark框架的其余部分一起使用。 它可以访问属于Spark的所有组件&＃xff0c;并且还具有一些强大功能。 如果您已经将Spark用于其他用途&＃xff0c;则可能会影响您决定使用哪种流框架。
让我们看一下集群管理器。 从顶部开始&＃xff0c;您已经有了一个Spark驱动程序。 如果该驱动程序崩溃&＃xff0c;则需要重新启动它。 以前的发行版中已经完成了许多工作&＃xff0c;这些功能使其更具弹性和可用性。
这是人们真正关注此框架的地方。 从独立的角度来看&＃xff0c;您可以运行它&＃xff0c;可以在EC2上运行&＃xff0c;可以在YARN上运行&＃xff0c;也可以在Mesos上运行。 对于每种功能&＃xff0c;您的里程可能会有所不同&＃xff0c;具体取决于您的需求和要求。 根据我的经验&＃xff0c;Mesos可能会获得最佳性能&＃xff0c;因为它是所有这些产品的第一款产品。 但是&＃xff0c;如果您不使用Mesos&＃xff0c;它也会与其余所有功能一起使用。
RDD操作
此处火花流的区别在于RDD&＃xff08;弹性分布式数据集&＃xff09;。 这是这些流进入的地方。 然后将数据放入RDD中&＃xff0c;您便拥有了Spark在此框架中提供的所有功能和计算能力。 同样&＃xff0c;如果您对Spark有任何倾向&＃xff0c;则可能会选择它&＃xff1b; 您应该真正地对自己掌握的其他一切进行自我教育。 转换是这里的优势。 从RDD向您提供所有这些功能&＃xff0c;您将看到该框架的最大好处。
火花流
- 用于流数据的高级语言运算符
- 容错语义
- 支持将流数据与历史数据合并
在分布式系统中&＃xff0c;一次很难做到。 使其完美几乎是不可能的。 有许多不同的公司以不同的方式构建分布式系统&＃xff0c;每个公司都会告诉您它有多复杂。 话虽这么说&＃xff0c;这里的某些部分可以很好地工作&＃xff0c;但这并不一定意味着您在所有用例中都可以百分百地保证不会丢失数据。 您需要弄清楚什么是用例&＃xff0c;以及它们对实现的意义。
这里的原始概念实际上是DStream。 您的数据进入DStream&＃xff0c;您可以访问它&＃xff0c;执行数据处理&＃xff0c;获得结果&＃xff0c;并且可能会立即获得相当好的性能。
这里重要的是&＃xff0c;与单记录相反&＃xff0c;使用微批处理时&＃xff0c;您将具有一定的延迟和可操作的最小窗口时间。 例如&＃xff0c;如果您在一天中的某些时间流非常慢&＃xff0c;但是在一天中的其他时间流非常快&＃xff0c;那么分批处理这些时间的窗口时间可能会对您产生很大的影响。 例如&＃xff0c;如果您在一天中的高峰时段在一个窗口中结束了500个事件&＃xff0c;但是每个窗口中只有一个事件&＃xff0c;那么当您将RDD与一个对象一起使用时&＃xff0c;您可能最终不会高兴可能会对性能产生负面影响。 您必须考虑所用数据的用例以及它们如何协同工作。 开始测试时&＃xff0c;请考虑一下。 了解您的实际使用模式非常重要。
Spark流&＃xff1a;转换
- 无状态转换
- 有状态的转换
- 检查点
无状态和有状态转换-您是否在两次迭代之间保持状态&＃xff1f; 如果必须重新启动过程&＃xff0c;则检查点非常宝贵。 如果您要进行一系列的操作&＃xff0c;则需要定期检查点&＃xff0c;以便驱动程序崩溃时&＃xff0c;可以从检查点重播它。
Spark流&＃xff1a;执行
这里的接收器将类似于Storm中的喷口。 由于接收器很大&＃xff0c;因此这被认为比在Storm中看到的要运行的代码重得多。 您最终要消耗大量内存才能运行接收器。 但是&＃xff0c;我在社区中没有听到很多关于Spark的负面评论。
Apache Spark资源
- Apache Spark基础
- Learning Spark&＃xff1a;闪电般的快速大数据分析
- Spark开发人员资源
- Apache Spark开发人员认证
- Apache Spark堆栈
- MapR Sandbox上Spark入门
比较方式
萨姆萨vs风暴vs星火
从术语上讲&＃xff0c;这些是每个框架之间的大致等效。 当您查看原语&＃xff08;消息&＃xff0c;元组和DStream&＃xff09;时&＃xff0c;它并不是很复杂。 如果您想对最适合您的方法进行全面评估&＃xff0c;则可以将其用作复选框指南&＃xff0c;以查看这些特定组件中的任何一个是否比其他组件更适合您的实现模型。 当然&＃xff0c;那是在您确定了确切的语义要求之后&＃xff0c;并且至少一次就足够了。
vs Storm vs Spark
这个网格有点复杂。 处理模型选项是一次记录与微批处理的对比。 这对性能的可能性有很大的影响&＃xff0c;并且直接导致延迟&＃xff0c;这对于Spark Streaming来说是几秒钟。 对于吞吐量&＃xff0c;它实际上取决于特定用例的需求。 在处理保证方面&＃xff0c;Samza已经计划了一次准确的支持&＃xff0c;但是目前还没有。 如果您只需要使用Storm一次&＃xff0c;则可以使用Trident。
语言支持很可能是一个重要的决定因素。 如果您需要多种语言进行交互&＃xff0c;那么使用Samza将会非常困难&＃xff0c;因为您只能使用基于Java虚拟机的语言。 如果您对Python和Python都很满意&＃xff0c;那么Spark Streaming就很不错。 如果您需要一堆其他语言&＃xff0c;则几乎将您锁定在这两个选项之外&＃xff0c;您将需要选择Storm。
什么时候使用什么&＃xff1f;
对我而言&＃xff0c;最大的是Kappa-native的概念。 这是后处理的概念。 在我看来&＃xff0c;重新处理是任何这些流框架中最重要的事情之一。 如果将来要更改代码&＃xff0c;并且想要重新处理已发生的事件&＃xff0c;则需要能够进行重新处理。 我认为这是一个很大的特色&＃xff0c;太多人忽略了。
现在&＃xff0c;这是否意味着其他区域中没有复选框表示他们没有该复选框&＃xff1f; 否。请注意&＃xff0c;此表的目的是显示每个项目的优势领域。 例如&＃xff0c;如果您想进行计数&＃xff0c;那么在大多数情况下&＃xff0c;Samza不仅是最佳选择。
在这篇博客中&＃xff0c;我回顾了三个开源流处理框架&＃xff1a;Apache Storm&＃xff0c;Apache Spark和Apache Samza。
自从提供此演示文稿以来&＃xff0c; Apache Flink也已成为一个可行的选择&＃xff0c;因为它是具有一流性能的流式处理优先处理引擎&＃xff0c;且处理模型仅一次。
Apache Flink资源
- 使用Apache Flink进行流优先处理的基本指南
- 使用Apache Flink进行分布式流和图形处理
- Apache Flink&＃xff1a;处理流数据的新方法
请查看以下深入资源&＃xff0c;以帮助您进行决策&＃xff0c;并随时在下面的评论部分中提出任何问题。
翻译自: https://www.javacodegeeks.com/2016/02/stream-processing-everywhere-use.html
京公网安备 11010802041100号