大数据框架对比:Hadoop,Storm,Samza,Spark和Flink

大数据

Justin Ellingwood,翻译员

介绍

大数据是用于收集,组织和处理大量数据集以及从中获取洞察力的非传统策略和技术的通用术语。虽然处理数据所需的计算能力或存储容量已经超过单个计算机的上限,但近年来这种类型的计算的普遍性,规模和价值已经经历了显着的扩展。

在上一篇文章中,我们讨论了大型数据系统的一般概念,处理和术语。本文将介绍大型数据系统最基本的组件之一:处理框架。处理框架负责计算系统中的数据,例如处理从非易失性存储器读取的数据或处理刚刚进入系统的数据。在提取信息和见解的过程中,从大量单个数据点计算数据。

这些框架如下所述:

仅批量框架:

  • Apache Hadoop

仅流式处理框架:

  • Apache风暴
  • Apache Samza

混合框:

  • Apache Spark
  • Apache Flink

什么是大数据处理框架?

处理框架和处理引擎负责计算数据系统中的数据。虽然“引擎”和“框架”之间的区别没有权威的定义,大多数时候,前者可以被定义为实际负责处理数据操作组件,可以定义为一系列类似的组件。

例如,Apache Hadoop可以看作是使用MapReduce作为默认处理引擎的处理框架。发动机和框架通常可以互换或同时使用。例如,另一个框架Apache Spark可以并入Hadoop并替换MapReduce。组件之间的这种互操作性是大数据系统如此灵活的原因之一。

虽然负责在生命周期的这个阶段处理数据的系统通常很复杂,但它们的目标是广泛一致的:通过增强对数据执行操作的能力,揭示数据隐含的模式,交互获得洞察。

为了简化对这些组件的讨论,我们将根据由不同处理框架的设计意图处理的数据的状态对它们进行分类。一些系统可以批量处理数据,并且一些系统可以将数据连续地流入系统。还有可以同时处理这两种类型的数据的系统。

在深入研究度量和结论的不同实现之前,需要简要介绍不同类型的处理的概念。

批处理系统

批处理在大数据世界中有着悠久的历史。批量处理大容量静态数据集的主要操作,并且计算过程完全返回结果。

在批处理模式中使用的数据集通常符合以下特性:

  • 有界:批处理数据集表示有限数据集
  • 持久性:数据通常总是存储在某种类型的持久存储位置
  • 批量:批处理操作通常是处理极大数据集的唯一方法

批处理是需要访问一整套记录的计算的理想选择。例如,在计算总计和平均值时,必须将数据集视为一个整体,而不是作为记录集合。这些操作要求数据在计算期间保持其状态。

需要大量数据的任务通常最适合使用批处理操作进行处理。无论是直接从永久存储设备处理数据集还是将数据集首先加载到内存中,批处理系统都充分考虑了设计过程中的数据量,并提供了足够的处理资源。因为批处理响应大量的持久数据性能非常好,它经常用于历史数据分析。

大量的数据处理需要大量的时间,因此批处理不适合高处理时间要求的场合。

Apache Hadoop

Apache Hadoop是用于批处理的专用处理框架。 Hadoop是第一个在开源社区获得更多关注的大数据框架。 Hadoop基于Google发布的关于海量数据处理的几篇论文和经验,重新实现了算法和组件堆栈,使大规模批处理技术更易于使用。

新的Hadoop包含多个组件,多个层,可用于处理批处理数据:

HDFS:HDFS是一个可以协调集群节点的存储和复制的分布式文件系统层。 HDFS确保不可避免的节点故障仍然可用,并且可以用作数据源来存储中间处理结果和存储计算的最终结果。

YARN:YARN是Yet Another Resource Negotiator的缩写,用作Hadoop堆栈的集群协调组件。该组件负责协调和管理底层资源并调度作业的操作。通过充当集群资源的接口,YARN允许用户在Hadoop集群中运行比以前的迭代更多类型的工作负载。

MapReduce:MapReduce是Hadoop的原生批处理引擎。

批处理模式

Hadoop的处理能力来自MapReduce引擎。 MapReduce处理技术符合映射,shuffle,减少使用键值对的算法要求。基本过程包括:

从HDFS文件系统读取数据集

将数据集拆分为块并将其分配给所有可用节点

为每个节点计算数据的子集(将计算的中间状态结果重写为HDFS)

重新分配中间结果并用键将它们分组

通过每个节点的结果来计算每个键的值的汇总和组合“Reducing”

计算的最终结果重写为HDFS

优点和局限性

因为这种方法严重依赖持久存储,每个任务需要执行多个读和写操作,因此速度相对较慢。另一方面,因为磁盘空间通常是服务器上最丰富的资源,这意味着MapReduce可以处理非常大的数据集。这也意味着与其他类似技术相比,Hadoop的MapReduce通常可以在廉价的硬件上运行,因为它不需要将所有内容存储在内存中。 MapReduce具有高的缩放潜力,并且在生产环境中已经有成千上万的节点。

MapReduce学习曲线更陡峭,虽然Hadoop生态系统的其他周边技术可以显着减少这个问题的影响,但是通过Hadoop集群的一些应用程序很快需要注意这个问题。

围绕Hadoop已经形成了一个庞大的生态系统,Hadoop集群本身经常被用作其他软件组件的一部分。许多其他处理框架和引擎也可以通过与Hadoop集成使用HDFS和YARN资源管理器。

总结一下

Apache Hadoop及其MapReduce处理引擎提供了一个经过试验和测试的批处理模型,最适合处理非时间关键的非常大的数据集。利用非常低成本的组件构建全功能Hadoop集群的能力使得这种廉价且高效的处理技术对于许多应用来说是灵活的。与其他框架和引擎的兼容性和集成使Hadoop成为使用不同技术的多个工作负载处理平台的基础。

流处理系统

流处理系统将在系统上随时输入数据。与批处理模式相比,这是一个非常不同的方法。流处理不需要对整个数据集执行操作,而是对通过系统传输的每个数据项执行操作。

流处理中的数据集是“无边界的”,这有几个重要的含义:

完整数据集仅表示到目前为止已进入系统的总数据量。

工作数据集可以更相关并且可以在特定时间仅表示单个数据项。

处理是基于事件的,除非明确停止,否则没有“结束”。处理结果立即可用,并且将在新数据到达时继续更新。

流处理系统可以处理几乎无限的数据,但同时只能处理一个(实际流处理)或非常小(微批处理)的数据,在不同记录之间只保持最小量的状态。虽然大多数系统提供用于维持某些状态的方法,但是流处理被优化用于较少的功能副作用和更多功能的处理。

功能操作主要集中在具有有限状态或副作用的离散步骤。对相同的数据或其他因素执行相同的操作产生相同的结果,其非常适合于流处理,因为不同项目的状态通常是一些困难,约束以及在一些情况下不期望的结果体的组合。因此,虽然一些类型的状态管理通常是可行的,但是这些框架通常在没有状态管理机制的情况下更简单和更有效。

这种类型的处理非常适合于某些类型的工作负载。近实时处理任务的要求非常适合使用流处理模式。分析,服务器或应用程序错误日志和其他基于时间的度量标准是最合适的类型,因为响应这些区域中的数据更改对业务功能至关重要。流处理非常适合处理必须响应变化或峰值的数据,并专注于随时间的趋势。

Apache风暴

Apache风暴是一个流处理框架,专注于非常低的延迟,可能是需要接近实时处理的工作负载的最佳选择。这种技术可以处理非常大量的数据,提供的结果具有比其他解决方案更低的延迟。

流处理模式

风暴流处理可以安排在称为拓扑DAG(Directed Acyclic Graph,有向无环图)的框架中进行排列。这些拓扑描述了当数据片段进入系统时需要对每个传入片段执行的不同变换或步骤。

拓扑包含:

流:普通数据流,其是继续到达系统的无边界数据。

Spout:拓扑的边缘处的数据流的源,例如,API或查询等,从中可以生成要处理的数据。

Bolt:Bolt表示消耗流数据的处理步骤,对其应用操作,并且以流的形式输出结果。螺栓需要与每个Spout建立连接,然后彼此连接以形成所有必要的处理。在拓扑结束时,最终的Bolt输出可以用作彼此连接的其他系统的输入。

Storm背后的理念是使用上述组件来定义大量小型离散操作,然后将组件组合到所需的拓扑中。默认情况下,Storm提供“至少一个”处理保证,这意味着您可以确保每个消息至少可以处理一次,但在某些情况下,如果遇到失败,它可能会被处理多次。 Storm不能确保消息可以按特定顺序处理。

为了实现严格的一次性处理,即状态处理,可以使用一个称为Trident的抽象。不使用Trident的风暴通常被称为Core Storms。 Trident将对Storm的处理能力产生巨大影响,增加延迟,提供处理状态,并使用微批处理模式,而不是纯流处理模式。

为了避免这些问题,一般建议Storm用户尽可能使用Core Storm。然而,应当注意,Trident的严格的一次性内容处理在某些情况下也是有用的,例如当系统不能智能地处理重复消息时。如果您需要维护项目之间的状态,例如,要计算用户点击链接的小时数,则Trident将是您唯一的选择。虽然不能充分发挥框架的固有优势,但是Trident提高了Storm的灵活性。

Trident拓扑包含:

流批处理:这是一个通过阻塞提供批处理语义的流式数据的微批处理。

操作(Operation):指可以执行批处理的数据。

优点和局限性

目前,Storm可能是近实时处理的最佳解决方案。此技术可以以非常低的延迟处理数据,并可用于要实现最低延迟的工作负载。如果处理速度直接影响用户体验,比如需要直接处理结果给访客打开网站页面,这个时候Storm会是个不错的选择。

Storm和Trident的组合允许用户使用微块而不是纯流处理。虽然这为用户提供了更多的灵活性来构建更好的工具,但这种方法削弱了技术相对于其他解决方案的最大优势。话虽如此,但是一个流处理方法总是好的。

Core Storm不能保证消息处理的顺序。 Core Storm为消息提供了“至少一个”处理保证,这意味着每个消息可以被保证被处理,但它也可以被复制。 Trident提供严格的一次性保证,您可以在批次之间提供顺序处理,但是无法在批次内实现顺序处理。

在互操作性方面,Storm可以与Hadoop的YARN资源管理器集成,使其易于集成到现有的Hadoop部署中。除了支持大多数处理框架,Storm还支持多种语言,为用户的拓扑定义提供更多选择。

总结一下

对于具有高延迟要求的纯流工作负载,Storm可能是最合适的技术。这种技术确保每个消息被处理并且可以与多种编程语言一起使用。由于Storm无法批处理,如果您需要这些功能,则可能需要使用其他软件。如果严格的一次性处理保证有相对较高的要求,那么考虑使用Trident。然而,在这种情况下,其他流处理框架可能更合适。

Apache Samza

Apache Samza是一个紧密绑定到Apache Kafka消息传递系统的流处理框架。虽然Kafka可以用于许多流处理系统,Samza设计利用Kafka的独特的建筑优势和保证。该技术通过Kafka提供容错,缓冲和状态存储。

Samara可以使用YARN作为资源管理器。这意味着默认情况下需要Hadoop集群(至少包含HDFS和YARN),但这也意味着Samza可以直接使用YARN的内置功能。

流处理模式

Samza依赖Kafka的语义来定义流如何处理。 Kafka在处理数据时涉及以下概念:

主题:进入Kafka系统的每个数据流都可以称为主题。主题基本上是由订户可以消费的相关信息组成的数据流。

分区:为了将主题分发到多个节点,Kafka将传入消息分为多个分区。分区将基于键(Key),这可以确保包含相同的键为每个消息可以划分为同一个分区。保证分区的顺序。

代理(代理):组成Kafka集群的每个节点也称为代理。

生产者:将数据写入Kafka主题的任何组件都可以称为生产者。生成器可以提供用于将主题划分为分区的键。

消费者:任何从Kafka读取主题的组件都可以称为消费者。消费者需要负责维护关于他们自己分支的信息,以便在处理了哪些记录失败后可以知道。

因为Kafka相当于一个永久的日志,Samza还需要处理不可变的数据流。这意味着由变换创建的任何新数据流可以由其他组件使用,而不会影响原始数据流。

优点和局限性

乍一看,Samza对Kafka查找系统的依赖似乎是一个限制,但它也为其他流处理系统没有的系统提供了一些独特的保证和功能。

例如,Kafka提供了对数据存储副本的低延迟访问,除了每个数据分区还可以提供易于使用和低成本的多用户模型。所有输出,包括中间状态的结果,可以写入Kafka,并可以通过下游步骤独立使用。

这种对Kafka的紧密依赖在许多方面类似于MapReduce引擎对HDFS的依赖。虽然在批处理中的每个计算之间的HDFS依赖性导致一些严重的性能问题,但它避免了流处理遇到的许多其它问题。

Samza和Kafka之间的密切关系允许处理步骤本身松散耦合在一起。您可以根据需要向输出中的任何步骤添加任意数量的订阅者,而无需事先协调,这一功能对于需要访问类似数据的多个团队的组织非常有用。多个团队可以订阅输入到系统中的数据主题,或订阅由处理了一些数据的其他团队创建的主题。所有这些不会对负载密集型基础设施(如数据库)造成额外的压力。

直接写卡夫卡还避免了背压问题。背压是负载尖峰导致数据流动速度快于组件的实时处理能力的情况,这可能导致停滞的处理和可能的数据丢失。通过设计,Kafka可以长时间保存数据,这意味着组件可以在方便的时间处理,并且可以重新启动,而不必担心任何后果。

Samza可以使用在本地键值存储中实现的容错检查点系统来存储数据。这允许Samza接收“至少一个”传递安全性,但是该技术不能在面对由于多个数据传递而导致的故障时提供聚合状态的精确恢复,例如计数。

Samza提供的高级抽象使它比Storm和其他系统提供的原语更容易以多种方式使用。目前,Samza仅支持JVM语言,这意味着在语言支持方面它不像Storm那么灵活。

总结一下

对于已经具有或易于实现Hadoop和Kafka的环境,Apache Samza是流处理工作负载的不错选择。 Samza本身非常适合具有多个数据流的组织,这些数据流需要在过程的不同阶段由多个团队使用(但不一定是彼此密切协作)。 Samza大大简化了许多流处理任务,并实现低延迟性能。如果部署要求与当前系统不兼容,可能不适合使用,但是如果需要非常低的延迟处理,或者严格的一次性处理语义有更高的需求,这个时候仍然适合考虑。

混合处理系统:批处理和流处理

一些处理框架可以处理批处理和流处理工作负载。这些框架可以使用相同或相关的组件和API来处理这两种类型的数据,从而允许简化不同的处理要求。

正如你所看到的,这个功能主要是由Spark和Flink实现的,这两个都在下面描述。这通过关注如何统一两种不同的处理模式以及对固定和非固定数据集之间的关系做出什么假设来实现。

虽然专注于特定类型进程的项目将更好地满足特定用例的要求,但混合框架旨在为数据处理提供一个通用解决方案。这个框架不仅提供了处理数据的必要方法,而且还提供了自己的集成项目,库,工具,能够进行图形分析,机器学习,交互式查询和其他任务。

Apache Spark

Apache Spark是包含流处理功能的下一代批处理框架。 Spark基于各种原理与Hadoop的MapReduce引擎开发,Spark通过复杂的内存计算和处理优化机制,加快批量工作负载的速度。

Spark可以作为独立集群(使用适当的存储层)部署,也可以与Hadoop集成并替换MapReduce引擎。

批处理模式

与MapReduce不同,Spark的数据处理工作都是在内存中完成的,只有当它首次将数据读入内存时,以及当最终结果持久存储时,它才需要与存储层进行交互。所有中间状态的处理结果存储在存储器中。

虽然内存处理可以显着提高性能,Spark处理磁盘相关任务的速度大大提高,因为通过提前分析整个任务集可以实现更好的整体优化。为此,Spark创建了一个定向非循环图(DAG),它表示需要执行的所有操作,需要操作的数据以及操作和数据之间的关系,从而使处理器可以使任务更加智能。

为了实现内存中批量计算,Spark使用一个名为Resilient Distributed Dataset(RDD)的模型来处理数据。这是数据集的表示,仅位于内存中,并且在结构上是不可变的。对RDD执行的操作可以生成新的RDD。每个RDD可以通过沿袭回溯到父RDD,并最终返回到磁盘上的数据。 Spark通过RDD提供容错,而不必将每个操作的结果写回磁盘。

流处理模式

流处理能力由Spark Streaming实现。 Spark本身主要用于批处理工作负载,Spark实现了一个称为微批处理*的概念,以补偿引擎设计和流处理工作负载特性的差异。在具体策略方面,这种技术将数据流视为一系列非常小的“批处理”,可以通过批处理引擎的本地语义来处理。

Spark Streaming缓冲亚秒级增量,然后将其分批为小的固定数据集。这种方法非常有效,但是与真实流程处理框架相比,在性能方面仍然不足。

优点和局限性

使用Spark而不是Hadoop MapReduce的主要原因是速度。借助内存计算策略和高级DAG调度等机制,Spark可以更快地处理相同的数据集。

火花是多样性的另一个重要优势。该产品可以部署为独立集群或与现有Hadoop集群集成。该产品可以运行批处理和流处理,运行集群可以处理不同类型的任务。

除了引擎本身的功能之外,围绕Spark构建了一个图书馆生态系统,以便为机器学习和交互式查询等任务提供更好的支持。与MapReduce相比,Spark任务是“众所周知的”,易于编写,因此大大提高了生产力。

流处理系统使用批处理方法,需要进入系统数据缓冲区。缓冲机制允许该技术处理非常大量的输入数据,增加总吞吐量,但等待缓冲器清空也可能导致延迟增加。这意味着Spark Streaming可能不适合处理具有高延迟要求的工作负载。

因为内存通常比磁盘空间更昂贵,Spark比基于磁盘的系统更昂贵。然而,提高处理速度意味着任务可以更快地完成,这一特征通常可以在需要以小时支付资源的环境中抵消增加的成本。

Spark Memory此设计的另一个后果是,如果您在共享集群上部署,您可能会遇到资源不足的问题。与Hadoop MapReduce相比,Spark的资源更加昂贵,并且可能对需要同时使用集群的其他任务产生影响。基本上,Spark不太适合与Hadoop堆栈的其他组件共存。

总结一下

Spark是各种工作负载处理任务的最佳选择。 Spark批量功能以更高的内存占用为代价提供无与伦比的速度优势。对于衡量吞吐量而不是延迟的工作负载,Spark Streaming是流处理的首选解决方案。

Apache Flink

Apache Flink是一个可以处理批处理任务的流处理框架。该技术将批处理数据视为具有有限边界的数据流,从而将批处理任务处理为流处理的子集。用于所有处理任务的流处理第一方法导致一系列有趣的副作用。

这种流优先方法也称为Kappa架构,与更广泛知道的Lambda架构相反,后者使用批处理作为主要方法,使用流作为补充并提供早期未精确的结果。 Kappa架构简化了一切以简化模型,这只有在最近的流处理引擎已经成熟时才可能。

流处理模式l

Flink的流处理模式在处理传入数据时将每个项目当作实际数据流。 Flink提供的DataStream API可以用于处理无尽的数据流。 Flink可以与基本组件一起使用包括:

  1. 流指的是流过系统的不可变非绑定数据集
  2. 算子是对数据流执行操作以产生其他数据流的功能
  3. 源是数据流进入系统的入口点
  4. Sink(slot)是从Flink系统进入位置的数据流,该槽可以是一个数据库或其他系统连接器

为了能够在计算中遇到问题之后恢复,流处理任务在预定的时间点创建快照。对于状态存储,Flink可以与各种状态后端系统一起使用,这取决于所需实现的复杂性和持久性级别。

另外,Flink处理能力的流程也可以了解“事件时间”的概念,这是事件的实际时间,除了功能还可以处理对话。这意味着可以以一些有趣的方式确保执行顺序和分组。

批处理模式l

Flink's批处理模式l主要是流处理模式l的扩展。代替从持久流读取数据,模型从持久存储器读取作为流的有界数据集。 Flink将为这些处理模型使用完全相同的运行时。

Flink可以针对批处理工作负载进行优化。例如,因为可以通过持久存储来支持批处理操作,所以Flink无法创建批处理工作负载的快照。数据仍然可以恢复,但是可以更快地执行常规处理操作。

另一个优化是批处理任务的分解,所以你可以在必要时调用不同的阶段和组件。这允许Flink与群集的其他用户更好地共存。提前分析任务允许Flink查看需要执行的所有操作,数据集的大小以及需要在下游执行以实现进一步优化的步骤。

优点和局限性

Flink目前是处理框架领域一个独特的技术。虽然Spark也可以执行批处理和流处理,但Spark的流处理采取的微批架构使其无法适用于很多用例。Flink流处理为先的方法可提供低延迟,高吞吐率,近乎逐项处理的能力。

Flink的很多组件是自行管理的。虽然这种做法较为罕见,但出于性能方面的原因,该技术可自行管理内存,无需依赖原生的Java垃圾回收机制。与Spark不同,待处理数据的特征发生变化后Flink无需手工优化和调整,并且该技术也可以自行处理数据分区和自动缓存等操作。

Flink会通过多种方式对工作进行分许进而优化任务。这种分析在部分程度上类似于SQL查询规划器对关系型数据库所做的优化,可针对特定任务确定最高效的实现方法。该技术还支持多阶段并行执行,同时可将受阻任务的数据集合在一起。对于迭代式任务,出于性能方面的考虑,Flink会尝试在存储数据的节点上执行相应的计算任务。此外还可进行“增量迭代”,或仅对数据中有改动的部分进行迭代。

在用户工具方面,Flink提供了基于Web的调度视图,借此可轻松管理任务并查看系统状态。用户也可以查看已提交任务的优化方案,借此了解任务最终是如何在集群中实现的。对于分析类任务,Flink提供了类似SQL的查询,图形化处理,以及机器学习库,此外还支持内存计算。

Flink能很好地与其他组件配合使用。如果配合Hadoop 堆栈使用,该技术可以很好地融入整个环境,在任何时候都只占用必要的资源。该技术可轻松地与YARN、HDFS和Kafka 集成。在兼容包的帮助下,Flink还可以运行为其他处理框架,例如Hadoop和Storm编写的任务。

目前Flink最大的局限之一在于这依然是一个非常“年幼”的项目。现实环境中该项目的大规模部署尚不如其他处理框架那么常见,对于Flink在缩放能力方面的局限目前也没有较为深入的研究。随着快速开发周期的推进和兼容包等功能的完善,当越来越多的组织开始尝试时,可能会出现越来越多的Flink部署。

总结一下

Flink提供了低延迟流处理,同时可支持传统的批处理任务。Flink也许最适合有极高流处理需求,并有少量批处理任务的组织。该技术可兼容原生Storm和Hadoop程序,可在YARN管理的集群上运行,因此可以很方便地进行评估。快速进展的开发工作使其值得被大家关注。

结论

大数据系统可使用多种处理技术。

对于仅需要批处理的工作负载,如果对时间不敏感,比其他解决方案实现成本更低的Hadoop将会是一个好选择。

对于仅需要流处理的工作负载,Storm可支持更广泛的语言并实现极低延迟的处理,但默认配置可能产生重复结果并且无法保证顺序。Samza与YARN和Kafka紧密集成可提供更大灵活性,更易用的多团队使用,以及更简单的复制和状态管理。

对于混合型工作负载,Spark可提供高速批处理和微批处理模式的流处理。该技术的支持更完善,具备各种集成库和工具,可实现灵活的集成。Flink提供了真正的流处理并具备批处理能力,通过深度优化可运行针对其他平台编写的任务,提供低延迟的处理,但实际应用方面还为时过早。

最适合的解决方案主要取决于待处理数据的状态,对处理所需时间的需求,以及希望得到的结果。具体是使用全功能解决方案或主要侧重于某种项目的解决方案,这个问题需要慎重权衡。随着逐渐成熟并被广泛接受,在评估任何新出现的创新型解决方案时都需要考虑类似的问题。

本文标签:大数据   数据
关注微信公众号

关注微信公众号获取全球最新资讯和案例分析

方法一: 手机扫描二维码添加关注;
方法二: 打开微信搜索公众号“云大数据研究院”;
方法三: 分享到微信,阅读本文,长按图片识别图中二维码。

声明:除非特别注明,本站所有文章均不代表本站观点。报道中出现的商标属于其合法持有人。请遵守理性,宽容,换位思考的原则,如文章内容侵犯你的版权,请联系我们处理。

猜你喜欢

    无相关信息

网友评论

最热评论

加载更多