Flink,Spark,Storm,Hadoop 框架比较
引言
大数据分析作为一种用于分析大量按需数据的工具,越来越受到人们的欢迎。四个最常见的大数据处理框架包括 Apache Hadoop,Apache Spark,Apache Storm 和 Apache Flink。
虽然这四个都支持大数据处理,但是这些框架的用法和支持该用法的基础体系结构不同。大数据培训许多研究已经投入了时间和精力来通过评估已定义的关键绩效指标(KPI)来比较这些大数据框架。
本文通过确定一组通用的关键性能指标来总结这些早期工作,这些关键性能指标包括处理时间,CPU 消耗,延迟,吞吐量,执行时间,可持续的输入速率,任务性能,可伸缩性和容错能力,并比较这四个大数据通过文献综述了解这些 KPI 的框架。
与 Apache Hadoop 和 Apache Storm 框架相比,在非实时数据中 Spark 为多个 KPI(包括处理时间,CPU 消耗,延迟,执行时间,任务性能和可伸缩性)的赢家。在流处理中 Flink 与 Apache Spark 和 Apache Storm 框架相比,Flink 在处理时间,CPU 消耗,延迟,吞吐量,执行时间,任务性能,可伸缩性和容错能力方面最适合流处理。
本文分为以下几部分:下一部分将解释大数据的主要特征,称为大数据的维度。接下来是对一些大数据框架的讨论。Hadoop,Spark,Storm 和 Flink。它们的类别将作为框架和所得结果之间的比较研究而呈现。之后,我们给出一些结论。
大数据的特征
当我们在上一阶段定义了大数据的含义时,现在说明其特征非常重要。它由通用的大数据需求(volume(容量), variety (多样性) , and velocity (速度))组成,这些需求统称为 3 维。最近,大数据的特性从 3 维演变为 6 维度,增加了 value (价值), veracity (准确性), 和 variability (可变性) 的特征。图 1 中显示了 6 维的大数据。
图 1
译者注:Volume(指数据量大)、Velocity(指数据量增加速度快)、Variety(指数据种类多样)、Value(指数据价值密度)、Veracity(指数据真实性)、 variability(指数据源稳定性)。
A. Volume(容量)
Volume 是指数据的数量或大小。大数据的大小约为 TB,PB(PB),Zettabyte(ZB)和 Exabyte(EB)。Facebook,YouTube,Google 和 NASA 等组织拥有大量数据,这给存储,检索,分析和处理这些数据带来了新的挑战。大数据而非传统存储的使用改变了我们传输数据和使用数据的方式。
B. Variety (多样性)
多样性是指正在生成的不同类型的数据。可以使用不同的维度来衡量类型(例如结构,使我们能够区别结构化,半结构化和非结构化数据,或批处理与流处理的处理量)
C. Variability (可变性)
可变性是指不稳定,难以处理且难以管理的数据。解释可变数据对研究人员来说是一个重大问题。
译者注:指数据源不稳定
D.Velocity (速度)
是指大数据以多快的速度生成,以便进行操纵,交换,存储和分析。由于涉及的高成本,速度对数据科学家提出了新的研究挑战。当用户需要检索或处理数据并且处理速度不够快时,数据就被遗忘了。
E.Veracity (准确性)
准确性是指正在处理的数据的质量。数据源的准确性还取决于分析数据准确性。
F. Value (价值)
价值是指数据带来的目的或业务成果,以促进决策过程。
大数据处理框架
本文比较的四个框架在它们支持的功能和底层体系结构方面彼此不同,北京大数据培训同时将支持大数据处理的主要目的保留在其核心。本节概述了这四个大数据处理框架的体系结构。
A.Hadoop
在 2008 年,Doug Cutting 和 Mike Cafarella 将 Apache Hadoop 定义为一个开源框架,该框架通过一组称为群集或节点的主机(硬件层)收集和处理分布式数据。它提供的是分发服务机器,而不是一项服务。因此,它们可以通过使用群集或节点并行工作。
图 2 说明了 Hadoop 框架的三个主要层。第一个是用于收集数据的数据存储层,其中包含 Hadoop 分布式文件系统(HDFS)。第二层是 YARN 基础结构,它提供用于作业调度的算术资源,例如 CPU 和内存。第三个是 MapReduce,它用于与其他进程一起处理数据(软件层)。
图 2
许多公司,企业和组织使用 Apache Hadoop 的主要原因有两个。首先,进行学术或科学研究。其次,进行分析以满足客户的需求并帮助组织做出正确的决定。例如,当组织需要知道客户需要哪种产品时。然后,它可以产生大量所需的产品,这是 Apache Hadoop 的几种应用程序之一。
B. Spark
Apache Spark 是在加州大学伯克利分校建立的开源框架。它在 2013 年成为 Apache 项目,通过大规模数据处理提供更快的服务。Spark 框架对 Hadoop 而言就像 MapReduce 对数据处理和 HDFS 一样。此外,Spark 具有数据共享功能,称为弹性分布式数据集(RDD)和有向无环图(DAG)。
图 3 表示 Spark 架构,它非常容易且快速地选择大量数据处理。Spark 主要由五层组成。第一层包括数据存储系统,例如 HDFS 和 HBASE。第二层是资源管理;例如 YARN 和 Mesos。第三个是 Spark 核心引擎。第四个是一个库,由 SQL,流处理,用于机器学习的 MLlib,Spark R 和用于图形处理的 GraphX 组成。最后一层是应用程序接口,例如 Java 或 Scala。通常,Spark 提供了一种大型数据处理框架,供银行,电信公司,游戏公司,政府以及 Apple,Yahoo 和 Facebook 等公司使用。
图 3
C. Storm
Storm 引擎是一个开放源代码框架,旨在实时处理流数据。它是用 Clojure 语言编写的。
图 4 显示 Storm 可以在任何程序语言和任何应用程序开发平台上使用。因此,它保证了数据不会丢失。
图 5 说明了两种类型的节点:第一种是主节点,第二种是工作节点。主节点用于监视故障,承担分布式节点的责任并为每台计算机指定每个任务。所有这些任务统称为 Nimbus,类似于 Hadoop 的 Job-Tracker。工作节点称为主管。当 Nimbus 为它分配特定的进程时,它将起作用。因此,拓扑的每个子过程都可与许多分布式计算机一起使用。Zookeeper 扮演 Nimbus 与主管之间的协调员。更重要的是,如果任何集群出现故障,它将把任务重新分配给另一个任务。因此,从节点控制自己任务的执行。
图 4
图 5
D. Flink
Apache Flink 是由三所德国大学于 2010 年创建的开源框架,已被有效地用于实时和批处理模式下的数据处理。它使用内存中处理技术,并提供了许多用于查询的 API,例如流处理 API(数据流),批处理 API(数据集)和表 API。它还具有机器学习(ML)和图形处理(Gelly)库。
图 6 展示了 Flink 的体系结构。在基础层中,存储层可以从多个目标(例如 HDFS,本地文件等)读取和写入数据。然后,部署和资源管理层包含用于管理计划任务,监视作业和管理资源的群集管理器。该层还包含执行程序的环境,即集群或云环境。同时,它还支持单个 Java 虚拟机的本地部署。
此外,它还具有用于实时处理的分布式流数据流引擎的内核层。此外,应用程序还具有用于两个过程的接口层:批处理和流传输。上层是一个使用 Java 或 Scala 编程语言编写程序的库。然后在 Flink 优化器的帮助下将其提交给编译器进行转换,以提高其性能。
图 6
大数据框架的功能比较
我们研究中的每个大数据框架都支持一组功能,这些功能也可以用作关键绩效指标。在本节中,我们将介绍通过文献综述确定的一组通用功能,并比较这些功能中的四个框架。
A. Scalability(可伸缩性)
可伸缩性是系统响应不断增加的负载量的能力。它有两种类型:(纵向)扩展和(横向)扩展。向上扩展用于升级硬件配置,而向外扩展用于添加额外的硬件。我们研究中的所有四个框架都是水平可扩展的。这意味着我们可以根据需要在集群中添加许多节点。
B. Message Delivery Guarantees(消息传递保证)
失败时将使用消息传递保证。根据上面提到的四个框架,它可以分为两种类型:exactly once(恰好一次)和 atleast-once(至少一次)。exactly once(恰好一次)传递意味着该消息将不会重复,也不会丢失,并且将精确地传递给收件人一次。另一方面,atleast-once(至少一次)传递意味着有很多传递消息的尝试,并且这些尝试中的至少一个成功。此外,该消息可以重复而不会丢失。
C. Computation Mode(计算模式)
计算模式可以是内存中计算,也可以是更传统的模式,在该模式下,计算结果将写回到磁盘上。内存中计算速度更快,但存在潜在的缺点,即在关闭计算机的情况下丢失内容。
D. Auto-Scaling(自动扩展)
自动扩展是指根据情况自动扩展或缩减云服务。
E. Iterative Computation(迭代计算)
迭代计算是指迭代方法的实现,该迭代方法在没有实际解的情况下或在实际解的成本过高的情况下估计近似解。表 I 对大数据框架某些特征进行了汇总:
表 I:
比较四个大数据处理框架
本节介绍现有文献,比较上述四个大数据处理框架。通过文献,我们确定了九种不同的关键性能指标,即处理时间,CPU 消耗,延迟,吞吐量,执行时间,可持续的输入速率,任务性能,可伸缩性和容错能力。
A. Processing Time (处理时间)
许多现有研究已通过处理时间评估了大数据框架的性能。进行了一项采用该措施作为关键绩效指标的工作。这项研究使用了个性化的监视工具来监视资源使用情况,并使用 Python 脚本来检测计算机的状态。在批处理模式实验中,研究人员包含了 100 亿条推文的数据集,而在流模式实验中,他们收集了 10 亿条推文。在批处理模式下,他们评估了数据大小和使用的群集对处理时间的影响。
关于数据大小,研究发现 Spark 的速度比 Hadoop 和 Flink 的速度快,而 Flink 的速度最慢。他们还注意到,仅当数据集较小(小于 5 GB)时,Flink 才比 Hadoop 更快。实际上,与避免输入/输出操作的 Spark 相比,Hadoop 通过访问 HDFS 来传输数据。因此,在这种情况下,处理时间受到输入/输出操作量的影响,因此,当处理大量数据时,处理时间增加。
另一方面,关于所用集群的大小,该研究表明,Hadoop 和 Flink 比 Spark 需要更长的时间,因为 Spark 中作业的执行受处理器数量和对 Linux 的读写操作量的影响 RAM,而不是磁盘使用,例如 Hadoop。在流模式实验中,研究人员通过评估窗口时间对已处理事件数的影响来研究处理速率。他们证明,在每条消息发送 100 KB 的推文的情况下,Flink 和 Storm 具有最好的处理速度,优于 Spark。这是因为这些框架为窗口时间使用了不同的值。Flink 和 Storm 使用毫秒,而 Spark 使用秒。另一方面,在每条消息发送五个 500KB 的 tweet 时,Flink 的工作效率比 Storm 和 Spark 高。
此外,在进行的一项研究中,作者根据亚马逊网站上的电子商务数据评估了 Flink 和 Spark 的性能。他们使用的数据集为 JSON 格式。每条记录具有固定数量的字段,一条记录的平均大小为 3000 字节。他们发现使用 Flink 处理数据的平均时间为 240.3 秒,而 Spark 则为 60.4 秒。因此,Spark 的性能比 Flink 更好,约为 179.5%。
B. CPU Consumption(CPU 消耗)
许多人已经使用 CPU 消耗来评估大数据框架的性能。在进行的一项研究中,发现在批处理模式下,Flink 使用的资源少于 Hadoop 和 Spark。这是因为与 Spark 和 Hadoop 相比,Flink 会部分利用磁盘和内存资源。此外,基于流模式,研究发现 Flink 在 CPU 消耗方面低于 Spark 和 Storm,因为与 Storm 相比,Flink 主要用于处理大型消息。Spark 每秒收集一次事件,然后执行任务。因此,将处理多个消息,结果导致 CPU 使用率高。
研究中,使用 Yahoo 流基准测试(YSB)和三个数据流框架-Spark,Storm 和 Flink-进行实验。实验发现,与其他框架相比,Storm 具有最高的 CPU 资源使用率。此外,进行的一项研究发现,Apache Spark 达到大约 100%的 CPU 利用率,而 Apache Flink 使用更少的 CPU 资源执行相同的负载。
C. Latency(延迟)
延迟是评估大数据框架性能的另一重要性能指标。例如,使用来自监视摄像机的数据集,其中包括 1595 个不同人的 3425 个视频,使用 RAM3S 框架比较了 Spark,Storm 和 Flink 的性能。研究人员在本地环境以及 Google Cloud 平台上实施了他们的实验。当本地集群和云的节点数量变化时,Apache Storm 达到了最低的延迟,并且与 Flink 延迟非常相似。但是,由于其微批处理设计,Spark 获得了最高的延迟。
此外,进行的一项研究发现,只有在可以接受高延迟的情况下,Spark 才能胜过 Flink。另外,使用 RAM3S 框架比较 Storm,Spark 和 Flink 中大量多媒体流的实时分析。他们使用了 YouTube 面孔数据集(YTFD),其中包括来自 1595 个不同人群的 3425 个视频和不同的视频分辨率,其中 480360 最常见,总共 621、126 帧,平均连接的人脸最少每个视频 181.3 帧。他们证明,Storm 和 Flink 的效果比 Spark 稍好。
另一项研究基于两组数据集(即 3000 个良性和 500 个异常)比较了 Spark 和 Storm。第一个数据集来自 VMware 中的 Spark 集群(D1),第二个数据集来自 Yahoo Cloud Serving Benchmark(YCSB),可预测异常(D2)。作者完成了在不同 VM 和单个 VM 中测试数据的工作。他们发现,在所有情况下,Spark 的平均延迟都小于 Storm。
D. Throughput(吞吐量)
吞吐量是已用于评估大数据框架性能的另一种度量。例如,发现 Spark 的吞吐量要比 Storm 和 Flink 低,然而,研究人员证明,当 Spark 的批处理间隔较长时,吞吐量会更高。此外,在使用云环境的情况下,Storm 和 Flink 的效果略好于 Spark,而没有考虑构建 D-stream 所需的时间。
E.Execution Time (执行时间)
使用执行时间来评估和比较 Hadoop,Spark 和 Flink 框架的性能。他们使用大数据评估工具(BDEv)在 DAS-4 上进行了实验,以自动化框架的配置。实验指出,将 Spark 和 Flink 替换为 Hadoop,当使用 49 个节点时,平均执行时间分别减少 77%和 70%。
工作中,研究人员使用开源数据集评估了 SparkCount 和 Hadoop 在 WordCount 和 Logistic 回归程序方面的性能,该数据集包括各种公司的破产预测。他们的结果表明,Spark 中 WordCount 程序的执行时间少于 Hadoop。此外,在 Spark 中执行逻辑回归程序的时间少于 Hadoop。例如,如果迭代次数为 100,则 Spark 中的执行时间为 3.452 秒;对于 Hadoop,为 9.383 秒。
因此,Spark 在 WordCount 和 Logistic 回归方面均胜过 Hadoop。原因之一是,在 Spark 的内存存储中使用缓存使过程更快。此外基于 WordCount 程序使用 Spark 和 MapReduce 框架对性能进行了测量,该框架运行在安装在 Ubuntu 机器上的单节点 Hadoop(HDFS)上。他们使用了大文本文件形式的数据集,其中包含客户对多种产品的评论和反馈,并将该文件分配为不同的大小。
与 MapReduce 编程框架相比,Spark 的执行速度大约是三到四倍。比较使用 Karamel(Web 应用程序)的 Spark 和 Flink 框架,以便评估系统级别和应用程序级别的性能。使用了 TeraSort 应用程序生成并使用 HDFS 存储的数据,以及各种输入级别(200GB,400GB 和 600GB)。研究人员发现 Flink 减少了执行时间,比 Terasort 应用程序的 Spark 快 1.5 倍。
F. Sustainable Input Rate(可持续的输入速率)
使用可持续输入率作为比较大数据框架的绩效指标。当本地集群和云的计算节点数量发生变化时,将使用此度量。Storm 在两种情况下(本地和云)都优于 Flink 和 Spark。此结果是由于 Storm 使用的最简单的一次语义(atleast-once 至少一次),而在 Flink 中,是 exactly once(恰好一次)。另外,Storm 的拓扑是由程序员定义的,而在 Flink 中,它是由优化器定义的。这导致 Flink 的效率降低。另一方面,Spark 并非主要设计为流引擎。因此,这也是输入速率较低的原因之一。
G. Task Performance (任务性能)
研究比较大数据框架在许多给定任务上的性能,这些任务包括 WordCount,k-means,PageRank,Grep,TeraSort 和 connected components。研究发现,与 Flink 和 Hadoop 相比,Spark 在 WordCount 和 k-means 方面表现最佳,而 Flink 对于 PageRank 则取得了更好的结果。另一方面,Flink 和 Spark 在 Grep,TeraSort 和 connected components 上均取得了相同的结果,并且在这些方面均胜过 Hadoop。
导致 WordCount 结果的一种解释是,求每个单词出现的次数和,Spark 使用 reduceByKey()函数与 flink 中优化程度较低的 groupBy()。sum()函数的 Flink 相比,所以 WordCount 性能测试中 Spark 超越 Flink。
在 Grep 中,Spark 和 Flink 的性能要优于 Hadoop,因为 Hadoop 使用一个 MapReduce 搜索模式,然后使用另一个对结果进行排序。这导致大量的内存复制和写入 HDFS。在 PageRank 中,Flink 获得了最佳性能,因为它使用的增量迭代仅处理尚未达到最终值的元素。
H. Scalability(可伸缩性)
在衡量可扩展性方面,将运营商的执行计划(端到端执行时间)与资源使用和参数配置联系在一起,以衡量 Spark 和 Flink 的性能。结果表明,Spark 比 Flink 快大约 1.7 倍,特别是在大型图数据处理中。相比之下,在具有大型数据集和固定节点的情况下,Flink 更好,其性能比 Spark 高出 10%。
I. Fault Tolerance(容错)
关于容错度量, 进行的研究指出,Flink 具有比 Storm 和 Spark 框架更高的容错能力。
总体而言,这里回顾的所有研究都表明,与 Hadoop 和 Flink 相比,Spark 在 processing time(处理时间)方面是最快的。同样在延迟方面,Spark 也是最低的。此外,与 Hadoop 和 Flink 相比,Spark 在 Throughput(吞吐量)和 execution time(执行时间)方面是最好的。同样在 WordCount 和 k-means 方面,它比 Flink 和 Hadoop 更好。此外,在 Grep,TeraSort 和 Connected Components 方面,它比 Hadoop 也更好。此外,就可伸缩性而言,与 Flink 相比,Spark 在大型图计算的情况下更好。
与 Storm 和 Spark 相比,Flink 在 processing time(处理时间)方面效率更高。另外,在使用云环境的情况下,它在 Throughput(吞吐量)方面更有效,而无需考虑构建 d-stream 的时间。除此之外,仅在使用 Karamel 和 TeraSort 应用程序的情况下,与 Spark 相比,execution time(执行时间)更短。此外,就 PageRank 而言,与 Spark 和 Hadoop 相比,它是最好的。此外,就 Grep,TeraSort 和 Connected Components 而言,它比 Hadoop 更好。就可伸缩性而言,只有在数据集很大且节点数量固定的情况下,与 Spark 相比才是最好的。同样,在容错方面,它比 Storm 和 Spark 好。
Storm 在 CPU 利用率方面与 Spark,Flink 和 Hadoop 框架相比性能最佳。此外,与 Spark 和 Flink 相比,它具有最低的延迟。另外,仅在使用云环境的情况下,它才具有最佳吞吐量,而无需考虑构建 d-stream 所需的时间。而且,与 Flink 和 Spark 相比,它具有更好的可持续输入速率。表 II 四个大数据框架比较的文献综述。
表 II:
结论
这项研究的结果表明,与其他框架相比,Flink 表现最佳,因为它在八项指标中均达到了最佳性能。Spark 在六个方面优于其他框架,Storm 在四个方面优于其他框架。因此,公司,研究人员以及对该领域感兴趣的个人的用户可以根据他们希望使用的关键绩效指标来选择合适的框架,以便分析数据并获得有效的结果。最后,他们将获得高性能的计算(HPC)。
将来,通过在四个框架的性能中考虑这些度量,可以以任何对获得 HPC 影响不大的度量来增强每个框架的机会。因此,我们希望看到其中一些框架有所增强,同时还包括能够提供高性能的其他框架。
文章来源:IT 那活儿
评论