简介

大数据 是一个笼统的术语，指的是从大型数据集中收集、组织、处理和收集见解所需的非传统策略和技术。虽然处理超过单个计算机的计算能力或存储的数据的问题并不新鲜，但近年来这种类型的计算的普遍性，规模和价值已经大大扩展。

在之前的指南中，我们讨论了大数据systems](https://andsky.com/tech/tutorials/an-introduction-to-big-data-concepts-and-terminology).中使用的一些[一般概念、处理阶段和术语在本文中，我们将介绍大数据系统最基本的组件之一：处理框架。处理框架通过从非易失性存储中读取或在数据被摄取到系统中时对系统中的数据进行计算。数据计算是从大量单独的数据点中提取信息和洞察力的过程。

我们将介绍以下框架：

• 纯批量框架： -[Apache Hadoop](# apache-hadoop)
• 纯流媒体框架： -[阿帕奇风暴](# apache-Storm) -[apache samza](# apache-samza)
• 混合框架： -[阿帕奇火花](# apache-spark) -[apache Flink](# apache-flink)

什么是大数据处理框架？

处理框架 和** 处理引擎** 负责对数据系统中的数据进行计算。虽然没有权威的定义将引擎与框架区分开来，但有时将引擎定义为负责操作数据的实际组件，而将后者定义为一组旨在执行相同操作的组件，有时会很有用。

例如，Apache Hadoop 可以被认为是一个_处理框架_，其默认的_处理引擎_是** MapReduce** 。引擎和框架通常可以互换或同时使用。例如，另一个框架** ApacheSpark** 可以挂钩到Hadoop来取代MapReduce.组件之间的互操作性是大数据系统具有极大灵活性的原因之一。

虽然处理数据生命周期这一阶段的系统可能很复杂，但在广泛层面上的目标是非常相似的：对数据进行操作，以增加对数据的理解、表面模式，并深入了解复杂的交互。

为了简化对这些组件的讨论，我们将根据设计用于处理的数据状态对这些处理框架进行分组。一些系统成批处理数据，而另一些系统则在数据流入系统时以连续流的形式处理数据。还有一些人可以用这两种方式中的任何一种来处理数据。

在深入研究各种实现的细节和结果之前，我们将把每种类型的处理作为一个概念进行介绍。

批量处理系统

批量处理 在大数据领域有着悠久的历史。批处理涉及对大型静态数据集进行操作，并在稍后计算完成时返回结果。

批处理中的数据集通常是...

• bounded：批处理数据集表示有限的数据集合
• 持久性：数据几乎总是由某种类型的永久存储支持
• 大型：批处理操作通常是处理超大数据集的唯一选择

批处理非常适合需要访问完整记录集的计算。例如，在计算总计和平均值时，必须将数据集作为整体处理，而不是将其视为单个记录的集合。这些操作要求在计算期间保持该状态。

需要大量数据的任务通常最好由批处理操作来处理。无论数据集是直接从永久存储中处理还是加载到内存中，构建批处理系统时都考虑到了大量数据，并拥有处理这些数据的资源。由于批处理擅长处理大量持久数据，因此它经常与历史数据一起使用。

处理大量数据的代价是计算时间较长。因此，批处理不适合处理时间特别长的情况。

ApacheHadoop

ApacheHadoop是一个专门提供批处理的处理框架。Hadoop是第一个在开源社区获得巨大吸引力的大数据框架。根据Google关于当时如何处理海量数据的几篇论文和演示文稿，Hadoop重新实现了算法和组件堆栈，以使大规模批处理更容易访问。

Hadoop的现代版本由多个组件或层组成，这些组件或层协同工作来处理批处理数据：

• HDFS ：HDFS是跨集群节点协调存储和复制的分布式文件系统层。HDFS可确保即使出现不可避免的主机故障，数据仍保持可用。它用作数据源，存储中间处理结果，并持久化最终计算结果。
• 纱线 ：纱线代表另一个资源协商者，是Hadoop堆栈的集群协调组件。它负责协调和管理底层资源，并调度要运行的作业。通过充当到集群资源的接口，Yar可以在Hadoop集群上运行比早期迭代中更多不同的工作负载。
• MapReduce ：MapReduce是Hadoop原生的批处理引擎。

批处理模型

Hadoop的处理功能来自于MapReduce引擎。MapReduce的处理技术遵循使用键-值对的map、Shuffle、Reduce算法。基本程序包括：

• 从HDFS文件系统读取数据集
• 将数据集分成块，分布在可用节点中
• 将每个节点上的计算应用于数据子集(中间结果被写回HDFS)
• 将中间结果重新分发到GROUP BY KEY
• 通过汇总和组合各个节点计算的结果来减少每个键的值
• 将计算的最终结果写回HDFS

优点和限制

因为这种方法在很大程度上利用了永久存储，每个任务多次读取和写入，所以它往往相当慢。另一方面，由于磁盘空间通常是最丰富的服务器资源之一，这意味着MapReduce可以处理大量的数据集。这也意味着Hadoop的MapReduce通常可以在比某些替代方案更便宜的硬件上运行，因为它不会尝试将所有内容都存储在内存中。MapReduce具有令人难以置信的可伸缩性潜力，并已在数万个节点上用于生产。

作为开发目标，MapReduce以具有相当陡峭的学习曲线而闻名。 Hadoop生态系统中的其他附加功能可以在不同程度上减少这种影响，但它仍然是在Hadoop集群上快速实现想法的一个因素。

Hadoop拥有广泛的生态系统，Hadoop集群本身经常被用作其他软件的构建块。许多其他处理框架和引擎都集成了Hadoop，以利用HDFS和YAR资源管理器。

总结

Apache Hadoop及其MapReduce处理引擎提供了一个经过良好测试的批处理模型，该模型最适合处理时间不是重要因素的非常大的数据集。运行良好的Hadoop集群所需的组件成本低，这使得这种处理对于许多用例来说既便宜又有效。与其他框架和引擎的兼容性和集成意味着Hadoop通常可以作为使用不同技术的多个处理工作负载的基础。

流处理系统

流处理 系统在数据进入系统时对其进行计算。这需要与批处理范例不同的处理模型。流处理器不是定义应用于整个数据集的操作，而是定义当每个单独的数据项通过系统时将应用于其的操作。

流处理中的数据集被认为是无界的。这有几个重要的影响：

• _TOTAL_DataSet仅定义为到目前为止已进入系统的数据量。
• _Working_DataSet可能更相关，并且一次仅限于一个项目。
• 处理是基于事件的，除非显式停止，否则不会结束。结果立即可用，并将随着新数据的到来而不断更新。

流处理系统可以处理几乎无限的数据量，但它们一次只能处理一个(真正的流处理)或极少的(微批处理)项，在记录之间维护最小的状态。虽然大多数系统提供了保持某种状态的方法，但蒸汽处理针对更多功能处理 进行了高度优化，几乎没有副作用。

功能性操作侧重于具有有限状态或副作用的离散步骤。对相同的数据执行相同的操作将产生与其他因素无关的相同输出。这种处理非常适合流，因为项之间的状态通常是困难的、有限的，有时甚至是不希望的。因此，虽然某种类型的状态管理通常是可能的，但在没有它们的情况下，这些框架要简单得多，效率也更高。

这种类型的处理适合某些类型的工作负载。流模型很好地服务于具有接近实时要求的处理。分析、服务器或应用程序错误记录以及其他基于时间的指标非常适合，因为对这些领域的更改做出反应对业务功能至关重要。流处理非常适合您必须对更改或峰值做出响应的数据，以及您对随时间变化的趋势感兴趣的数据。

阿帕奇风暴

ApacheStorm是一个专注于极低延迟的流处理框架，可能是需要接近实时处理的工作负载的最佳选择。与其他解决方案相比，它可以处理非常大量的数据，并以更短的延迟交付结果。

流处理模型

风暴流处理通过在一个称为 拓扑 的框架中编排DAG（有向无环图)来工作。 这些拓扑描述了在每个传入数据进入系统时将对其执行的各种转换或步骤。

这些拓扑由以下部分组成：

• 流 ：常规数据流。这是不断到达系统的无界数据。
• SPOUTS ：拓扑边缘的数据流来源。这些可以是生成要操作的数据的API、队列等。
• 螺栓 ：螺栓代表消耗流的处理步骤，对流进行操作，并将结果以流的形式输出。螺栓连接到每个喷嘴上，然后相互连接，以安排所有必要的加工。在拓扑的末尾，最终的螺栓输出可以用作连接系统的输入。

Storm背后的思想是使用上面的组件定义小的、离散的操作，然后将它们组合成一个拓扑。默认情况下，Storm提供至少一次的处理保证，这意味着它可以保证每条消息至少处理一次，但在某些故障场景中可能会有重复处理。Storm不保证消息将按顺序处理。

为了实现只有一次的有状态处理，还提供了称为三叉戟 的抽象。明确地说，没有三叉戟的风暴通常被称为** 核心风暴** 。三叉戟显著改变了Storm的处理动态，增加了延迟，增加了处理状态，并实现了微批处理模型，而不是逐个项目的纯流媒体系统。

Storm用户通常建议尽可能使用Core Storm来避免这些惩罚。 考虑到这一点，Trident保证只处理一次项目，这在系统无法智能处理重复消息的情况下非常有用。 Trident也是Storm中需要维护项目之间状态的唯一选择，例如计算一小时内有多少用户点击链接。 Trident给Storm带来了灵活性，尽管它没有发挥框架的自然优势。

Trident拓扑由以下部分组成：

• 流批次 ：流数据的微批次，为了提供批处理语义，对流数据进行分块。
• 操作 ：这些是可以对数据执行的批处理过程。

优势与局限

Storm可能是目前可用于近实时处理的最佳解决方案。对于必须以最小延迟处理的工作负载，它能够以极低的延迟处理数据。当处理时间直接影响用户体验时，Storm通常是一个很好的选择，例如，当处理的反馈直接反馈到网站上的访问者页面时。

带有三叉戟的Storm为您提供了使用微批处理而不是纯数据流处理的选项。虽然这给了用户更大的灵活性来调整工具以适应预期的用途，但它也往往会否定该软件相对于其他解决方案的一些最大优势。话虽如此，拥有流处理样式的选择仍然很有帮助。

Core Storm不提供消息的订购保证。Core Storm提供至少一次的处理保证，这意味着可以保证处理每条消息，但可能会发生重复。三叉戟提供只需一次的保证，可以提供批次之间的订购，但不能在内部订购。

在互操作性方面，Storm可以与Hadoop的纱线资源协商器集成，从而很容易与现有的Hadoop部署挂钩。与大多数处理框架相比，Storm具有非常广泛的语言支持，为用户提供了许多定义拓扑的选项。

总结

对于具有非常严格的延迟要求的纯流处理工作负载，Storm可能是最成熟的选择。它可以保证消息处理，并可以与大量编程语言一起使用。由于Storm不执行批处理，因此如果您需要这些功能，则必须使用其他软件。如果您强烈需要一次性处理保证，三叉戟可以提供这一点。但是，其他流处理框架也可能更适合这一点。

Apache Samza

ApacheSamza是一个与ApacheKafka消息传递系统紧密绑定的流处理框架。虽然Kafka可以被许多流处理系统使用，但Samza是专门为利用Kafka的独特架构和保证而设计的。它使用Kafka来提供容错、缓冲和状态存储。

Samza使用纱线进行资源谈判。这意味着在默认情况下，需要Hadoop集群(至少是HDFS和纱线)，但这也意味着Samza可以依赖于构建在纱线中的丰富功能。

流处理模型

Samza依赖于Kafka的语义来定义处理流的方式。卡夫卡在处理数据时使用以下概念：

• 主题 ：进入Kafka系统的每一条数据流都称为主题。主题基本上是消费者可以订阅的相关信息流。
• Partitions ：为了在节点之间分发主题，Kafka将传入的消息划分为多个分区。分区划分基于密钥，从而保证将具有相同密钥的每个消息发送到相同分区。分区保证了有序。
• Brokers ：组成Kafka集群的单个节点称为Broker。
• 生产者 ：任何写入Kafka主题的组件都称为生产者。生产者提供用于划分主题的键。
• 消费者 ：消费者是阅读卡夫卡主题的任何组件。消费者负责维护有关他们自己的偏移量的信息，以便他们知道在发生故障时处理了哪些记录。

因为Kafka代表一个不变的日志，所以Samza处理不变的流。这意味着任何转换都会创建供其他组件使用的新流，而不会影响初始流。

优点和限制

乍一看，Samza对卡夫卡式排队系统的依赖似乎受到了限制。然而，它为系统提供了一些在其他流处理系统中不常见的独特保证和功能。

例如，Kafka已经提供了可以以低延迟访问的数据的复制存储。它还为每个单独的数据分区提供了一种非常简单且廉价的多订户模型。所有输出，包括中间结果，也都写入Kafka，并可由下游阶段独立消费。

在许多方面，这种对Kafka的紧密依赖反映了MapReduceEngine频繁引用HDFS的方式。虽然在每次计算之间引用HDF会在批处理时导致一些严重的性能问题，但它解决了流处理时的一些问题。

Samza与Kafka的紧密联系使得处理步骤本身可以非常松散地联系在一起。 可以将任意数量的用户添加到任何步骤的输出中，而无需事先协调。 这对于多个团队可能需要访问类似数据的组织非常有用。 团队都可以订阅进入系统的数据的主题，或者可以很容易地订阅其他团队创建的经过一些处理的主题。 这可以在不增加对负载敏感的基础设施（如数据库)的额外压力的情况下完成。

直接写信给卡夫卡也消除了反压力 的问题。反压力是指负载高峰导致数据涌入的速度超过组件可以实时处理的速度，从而导致处理停滞和潜在的数据丢失。Kafka被设计为在很长一段时间内保存数据，这意味着组件可以在方便的情况下进行处理，并且可以重新启动而不会产生任何后果。

Samza能够使用作为本地键值存储实现的容错检查点系统来存储状态。 这允许Samza提供至少一次交付保证，但它不能在发生故障时提供聚合状态（如计数)的准确恢复，因为数据可能会交付多次。

Samza提供了高级抽象，与Storm等系统提供的原语相比，这些抽象在许多方面更易于使用。Samza目前只支持JVM语言，这意味着它没有Storm那样的语言灵活性。

总结

对于Hadoop和Kafka已经可用或可以实现的流传输工作负载，ApacheSamza是一个很好的选择。Samza本身非常适合有多个团队在不同处理阶段使用数据流(但不一定要紧密协调)的组织。Samza极大地简化了流处理的许多部分，并提供低延迟性能。如果部署要求与您的当前系统不兼容，如果您需要极低的延迟处理，或者如果您对只需一次的语义有强烈的需求，那么它可能不太适合。

混合处理系统：批处理器和流处理器

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

正如您将看到的，Spark和Flink（我们将讨论的两个框架)之间实现这一点的方式有很大不同。 这在很大程度上取决于两种处理范式如何结合在一起，以及对固定和非固定数据集之间的关系做出了哪些假设。

虽然专注于一种处理类型的项目可能非常适合特定的用例，但混合框架试图为数据处理提供通用的解决方案。 它们不仅提供了处理数据的方法，还拥有自己的集成、库和工具，用于进行图形分析、机器学习和交互式查询等工作。

阿帕奇火花!

ApacheSpark是具有流处理能力的下一代批处理框架。Spark使用Hadoop的MapReduce引擎的许多相同原理构建，主要专注于通过提供完全内存中的计算和处理优化来加速批处理工作负载。

Spark可以部署为独立的集群（如果与有能力的存储层配对)，也可以挂钩到Hadoop作为MapReduce引擎的替代方案。

批量处理模型

与MapReduce不同，Spark处理内存中的所有数据，只与存储层交互，最初将数据加载到内存中，最后将最终结果持久化。所有中间结果都在内存中管理。

虽然内存处理大大提高了速度，但Spark在与磁盘相关的任务上也更快，因为可以通过提前分析完整的任务集来实现整体优化。它通过创建有向无环图或DAG 来实现这一点，这些图表示必须执行的所有操作、要操作的数据以及它们之间的关系，从而使处理器具有更强的智能协调工作的能力。

为了实现内存中的批量计算，Spark使用一种名为弹性分布式数据集(Resilient Distributed DataSet，简称RDDS)的模型来处理数据。这些是存在于表示数据集合的内存中的不可变结构。对RDDS的操作会产生新的RDDS。每个RDD可以通过其父RDDS追溯其谱系，并最终追溯到磁盘上的数据。本质上，RDDS是Spark维护容错的一种方式，而不需要在每次操作后写回磁盘。

流处理模型

流处理功能由Spark Streaming提供。Spark本身在设计时就考虑到了面向批处理的工作负载。为了处理引擎设计和流工作负载特性之间的差异，Spark实现了一个称为微批处理的概念。此策略旨在将数据流视为一系列非常小的批处理，可以使用批处理引擎的本机语义处理这些批处理。

火花流的工作原理是以亚秒为增量对流进行缓冲。这些数据被作为小的固定数据集发送，以进行批处理。在实践中，这工作得相当好，但它确实导致了与真正的流处理框架不同的性能配置。

优势与局限

使用Spark而不是Hadoop MapReduce的明显原因是速度。由于其内存计算策略和高级DAG调度，Spark可以显著加快处理相同数据集的速度。

Spark的另一个主要优势是它的多功能性。它可以部署为独立的群集，也可以与现有的Hadoop群集集成。它可以执行批处理和流处理，允许您操作单个集群来处理多种处理风格。

除了引擎本身的功能之外，Spark还拥有一个可用于机器学习、交互式查询等的库生态系统。Spark任务几乎被公认为比MapReduce更容易编写，这可能会对生产率产生重大影响。

采用批处理方法进行流处理涉及在数据进入系统时对其进行缓冲。缓冲区允许它处理大量传入数据，从而增加了总体吞吐量，但等待刷新缓冲区也会导致延迟显著增加。这意味着火花流可能不适合需要低延迟的处理。

由于RAM通常比磁盘空间更昂贵，因此Spark的运行成本可能比基于磁盘的系统更高。然而，处理速度的提高意味着任务可以更快地完成，这可能会完全抵消在按小时支付资源的环境中操作时的成本。

Spark的内存设计的另一个结果是，当部署在共享集群上时，资源稀缺可能会成为一个问题。与Hadoop的MapReduce相比，Spark使用的资源要多得多，这可能会干扰当时可能正在尝试使用集群的其他任务。从本质上讲，与可以在Hadoop堆栈上运行的其他组件相比，Spark可能不是一个考虑得那么周到的邻居。

摘要

对于那些有不同处理工作负载的人来说，Spark是一个很好的选择。Spark批处理提供了令人难以置信的速度优势，牺牲了高内存使用率。对于重视吞吐量而不是延迟的工作负载，Spark Streaming是一个很好的流处理解决方案。

Apache Flink

ApacheFlink是一个流处理框架，也可以处理批处理任务。它将批处理简单地视为具有有限边界的数据流，并因此将批处理视为流处理的子集。所有处理的这种流优先方法有许多有趣的副作用。

这种流优先的方法被称为Kappa体系结构 ，与更广为人知的Lambda体系结构(其中批处理被用作主要处理方法，流用于补充和提供早期但未经改进的结果)形成对比。Kappa架构，其中流用于任何事情，简化了模型，直到最近才成为可能，因为流处理引擎变得更加复杂。

流处理模型

Flink的流处理模型将传入的数据作为真正的流逐项处理。Flink提供其数据流API来处理无限数据流。Flink使用的基本组件包括：

• STREAMS 是流经系统的不可变、无界的数据集
• 运算符 是对数据流进行操作以产生其他流的函数
• 来源 是流进入系统的切入点
• 汇 是水流流出Flink系统的地方。它们可能表示一个数据库或另一个系统的连接器

流处理任务在其计算期间在设定点处获取快照，以便在出现问题时用于恢复。 对于存储状态，Flink可以与许多状态后端一起工作，这取决于不同的复杂性和持久性水平。

此外，Flink的流处理能够理解事件时间的概念，即事件实际发生的时间，并且可以处理会话。这意味着它可以保证以一些有趣的方式进行排序和分组。

批处理模型

Flink的批处理模型在很多方面只是流处理模型的扩展。它不是从连续的流中读取数据，而是以流的形式从持久性存储中读取有界数据集。Flink对这两个处理模型使用完全相同的运行时。

Flink为批处理工作负载提供了一些优化。例如，由于批处理操作由持久性存储支持，因此Flink从批处理加载中删除了快照。数据仍可恢复，但正常处理完成得更快。

另一个优化涉及分解批处理任务，以便仅在需要时才涉及阶段和组件。这有助于Flink很好地与集群的其他用户一起玩。先发制人的任务分析使Flink能够通过查看整个操作集、数据集的大小和后续步骤的要求来进行优化。

优点和限制

Flink目前是处理框架世界中的唯一选项。虽然Spark执行批处理和流处理，但由于其微批处理架构，它的流不适合许多用例。Flink的流优先方法提供低延迟、高吞吐量和真正的逐个条目处理。

Flink自己管理着许多事情。有些不同寻常的是，出于性能原因，它管理自己的内存，而不是依赖原生Java垃圾收集机制。与Spark不同，Flink在其处理的数据特性发生变化时不需要手动优化和调整。它还可以自动处理数据分区和缓存。

Flink分析其工作并以多种方式优化任务。这种分析的一部分类似于SQL查询规划者在关系数据库中所做的工作，制定出实现给定任务的最有效方法。它能够将可并行完成的阶段并行化，同时将数据聚集在一起用于阻塞任务。对于迭代任务，出于性能原因，Flink尝试在存储数据的节点上进行计算。它还可以进行增量迭代，即只对发生更改的数据部分进行迭代。

在用户工具方面，Flink提供了一个基于Web的调度视图，可以轻松管理任务和查看系统。用户还可以显示已提交任务的优化计划，以查看它将如何在集群上实际实施。对于分析任务，Flink提供了SQL风格的查询、图形处理和机器学习库以及内存计算。

Flink与其他组件配合运行良好。如果在Hadoop堆栈中使用，它被写成是一个好邻居，在任何给定的时间只占用必要的资源。它可以很容易地与纱线、HDFS和Kafka集成。Flink可以通过兼容包运行为Hadoop和Storm等其他处理框架编写的任务。

Flink目前最大的缺点之一是它仍然是一个非常年轻的项目。在野外大规模部署仍然不像其他处理框架那样普遍，而且还没有太多关于Flink可伸缩性限制的研究。随着快速的开发周期和兼容性包之类的功能，随着组织有机会尝试Flink，可能会开始有更多的Flink部署。

总结

Flink既提供低延迟流处理，又支持传统批处理任务。Flink可能最适合具有繁重的流处理要求和一些面向批处理的任务的组织。它与本机Storm和Hadoop程序的兼容性，以及在纱线管理的集群上运行的能力，使其易于评估。它的快速发展使其值得关注。

结论

在大数据系统中有很多可供处理的选项。

对于时间不敏感的仅批处理工作负载，Hadoop是一个很好的选择，其实施成本可能比其他一些解决方案要低。

对于仅支持流的工作负载，Storm具有广泛的语言支持，可以提供非常低的延迟处理，但可以提供副本，并且不能保证在其默认配置中订购。Samza与纱线和Kafka紧密集成，以提供灵活性、轻松的多团队使用以及简单的复制和状态管理。

对于混合工作负载，Spark为流提供高速批处理和微批处理。它具有广泛的支持、集成库和工具以及灵活的集成。Flink通过批处理支持提供真正的流处理。它经过了大量优化，可以运行为其他平台编写的任务，并提供低延迟处理，但仍处于采用的早期阶段。

最适合您的情况的方法在很大程度上取决于要处理的数据的状态、您的需求的时间限制以及您感兴趣的结果类型。 在实施一体化解决方案和处理重点紧密的项目之间存在权衡，在评估新的和创新的解决方案时，也有类似的考虑因素，而不是成熟和经过充分测试的解决方案。