五大数据处理架构

大数据是收集、组织和处理大容量数据集并从中获得洞察力所需的非传统策略和技术的总称。尽管处理数据所需的计算能力或存储容量早已超过了一台计算机的上限，但这种类型计算的普遍性、规模和价值只是在最近几年才经历了大规模的扩张。

本文将介绍大数据系统的一个基本组件:处理框架。处理框架负责计算系统中的数据，例如处理从非易失性存储中读取的数据或处理刚刚摄入系统中的数据。数据的计算是指从大量单个数据点中提取信息和观点的过程。

这些框架描述如下:

仅批处理框架:

Apache Hadoop

仅流处理框架:

阿帕奇风暴

阿帕奇萨姆扎

*混合框架:

阿帕奇火花

阿帕奇弗林克

什么是大数据处理框架？

处理框架和处理引擎负责计算数据系统中的数据。“引擎”和“框架”的区别虽然没有权威的定义，但很多时候，前者可以定义为实际负责处理数据操作的组件，后者可以定义为承担类似功能的一系列组件。

比如Apache Hadoop可以看作是一个以MapReduce为默认处理引擎的处理框架。引擎和框架通常可以互换使用，也可以同时使用。例如，另一个框架Apache Spark可以整合Hadoop并取代MapReduce。组件之间的互操作性是大数据系统如此灵活的原因之一。

虽然在生命周期的这个阶段负责处理数据的系统通常非常复杂，但从广义上来说，它们的目标是非常一致的:通过对数据执行操作来提高理解能力，揭示数据中包含的模式，并获得对复杂交互的洞察力。

为了简化对这些组件的讨论，我们将根据不同处理框架的设计意图所处理的数据的状态对它们进行分类。有些系统可以以批处理方式处理数据，有些系统可以以流方式处理连续流入系统的数据。此外，有些系统可以同时处理两种类型的数据。

在介绍不同实现的指标和结论之前，有必要简单介绍一下不同处理类型的概念。

批处理系统

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

批处理模式下使用的数据集通常满足以下特征…

有界:一个批处理数据集代表一个有限的数据集。

持久性:数据通常总是存储在某种持久存储位置。

海量:批处理操作通常是处理超大数据集的唯一方法。

批处理非常适合需要访问完整记录集的计算作业。例如，在计算总数和平均值时，必须将数据集视为一个整体，而不是多个记录的集合。这些操作要求数据在计算过程中保持自己的状态。

需要处理大量数据的任务通常最好通过批处理操作来处理。无论是直接从持久存储设备处理数据集，还是先加载到内存中，批处理系统在设计过程中都充分考虑了数据量，能够提供足够的处理资源。批处理因其在处理大量持久数据方面的优异性能，常被用于分析历史数据。

处理大量的数据需要大量的时间，所以批处理不适合处理时间要求高的场合。

Apache Hadoop

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

新版本的Hadoop包含多个组件，即多个层，它们可以一起用于处理批量数据:

HDFS: HDFS是一个分布式文件系统层，它可以协调集群节点之间的存储和复制。HDFS保证数据在不可避免的节点失效后仍然可以使用，可以作为数据源，可以用来存储中间状态的处理结果，可以存储计算的最终结果。

Yarn: Yarn是另一个资源协商器的缩写，可以充当Hadoop堆栈的集群协调组件。该组件负责协调和管理底层资源的运行以及调度作业。通过充当集群资源的接口，YARN使用户能够以迭代的方式在Hadoop集群中运行比过去更多类型的工作负载。

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

成批处理方式

Hadoop的处理功能来自MapReduce引擎。mapreduce的处理技术满足了使用键值对的Map、shuffle和reduce算法的要求。基本处理过程包括:

从HDFS文件系统读取数据集

将数据集分成小块，并将它们分发到所有可用的节点。

计算每个节点上的数据子集(计算的中间结果将在HDFS重写)。

中间结果的重新分配和按关键字分组

通过汇总和合并每个节点的计算结果来降低每个键的值。

将计算的最终结果重新写入HDFS。

优点和局限性

由于这种方式非常依赖持久存储，每个任务需要多次进行读写操作，所以速度比较慢。但另一方面，由于磁盘空间通常是服务器上最丰富的资源，这意味着MapReduce可以处理非常海量的数据集。这也意味着，与其他类似技术相比，Hadoop的MapReduce通常可以运行在廉价的硬件上，因为它不需要将所有东西都存储在内存中。MapReduce具有极高的扩展潜力，在生产环境中已经有了数万个节点的应用。

MapReduce的学习曲线很陡。虽然Hadoop生态系统的其他外围技术可以大大降低这个问题的影响，但是在通过Hadoop集群快速实现一些应用的时候，还是需要注意这个问题。

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

摘要

Apache Hadoop及其MapReduce处理引擎提供了一套经过时间考验的批处理模型，最适合处理时间要求不高的超大规模数据集。一个全功能的Hadoop集群可以通过非常低成本的组件来构建，这使得这种廉价而高效的处理技术可以灵活地应用于许多情况。与其他框架和引擎的兼容性和集成使Hadoop成为使用不同技术的各种工作负载处理平台的底层基础。

流处理系统

流处理系统将随时计算进入系统的数据。与批处理模式相比，这是一种完全不同的处理方式。流处理方法不需要对整个数据集执行操作，而是对通过系统传输的每个数据项执行操作。

流处理中的数据集是“无边界的”，这有几个重要影响:

一个完整的数据集只能代表目前为止进入系统的数据总量。

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

处理是基于事件的，除非显式停止，否则没有“结束”。处理结果立即可用，并将随着新数据的到来而更新。

流处理系统几乎可以处理无限量的数据，但同时只能处理一片(实流处理)或少量(微批处理)数据，不同记录之间只维持一个最小状态。尽管大多数系统都提供了维护某些状态的方法，但流处理主要是针对副作用较少的功能性处理进行优化的。

功能操作主要集中在具有有限状态或副作用的离散步骤上。对相同的数据执行相同的操作会产生相同的结果或一些其他因素，这非常适合流处理，因为不同项的状态通常是一些困难、限制和某些情况下不必要的结果的组合。因此，尽管一些类型的状态管理通常是可行的，但是这些框架在没有状态管理机制的情况下通常更简单和更有效。

这种处理非常适合某些类型的工作负载。具有接近实时处理要求的任务非常适合使用流处理模式。分析、服务器或应用程序错误日志以及其他基于时间的指标是最合适的类型，因为响应这些领域的数据变化对于业务功能来说极其重要。流处理适用于处理必须响应变化或峰值并关注一段时间内变化趋势的数据。

阿帕奇风暴

Apache Storm是一个注重极低延迟的流处理框架，可能是需要近实时处理的工作负载的最佳选择。这项技术可以处理非常大量的数据，并提供比其他解决方案延迟更低的结果。

流处理模式

Storm的流处理可以在框架中安排DAG(有向无环图)命名拓扑。这些拓扑描述了当数据段进入系统时，需要对每个传入数据段执行的不同转换或步骤。

拓扑包括:

Stream:普通数据流，是会持续到达系统的无边界数据。

Spout:位于拓扑边缘的数据流的来源，如API或query，从中可以生成要处理的数据。

Bolt: Bolt表示需要消费流数据、对其应用操作并以流的形式输出结果的处理步骤。Bolt需要与每个喷口建立连接，然后相互连接，形成所有必要的处理。在拓扑的末端，最终的Bolt输出可以用作其他互连系统的输入。

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

为了实现严格的一次性处理，即有状态处理，可以使用一种叫做Trident的抽象。严格来说，不使用三叉戟的风暴通常可以称为核心风暴。Trident会很大程度上影响Storm的处理能力，增加延迟，提供处理的状态，使用微批处理模式代替逐项的纯流处理模式。

为了避免这些问题，一般建议Storm用户尽量使用Core Storm。但是，还需要注意的是，Trident对内容严格的一次性处理保证在某些情况下也是有用的，比如当系统无法智能处理重复消息时。如果你需要维护项目之间的状态，比如统计一个小时内有多少用户点击了一个链接，Trident将是你唯一的选择。虽然不能充分发挥框架的固有优势，但三叉戟提高了风暴的灵活性。

三叉戟拓扑包括:

流批量:这是指流数据的微批量，可以通过分块提供批量语义。

操作:指可以对数据执行的批处理过程。

优点和局限性

目前，Storm可能是近实时处理领域的最佳解决方案。这项技术可以以非常低的延迟处理数据，并可用于希望获得最低延迟的工作负载。如果处理速度直接影响用户体验，比如需要将处理结果直接提供给访问者打开的网站页面，那么Storm会是一个不错的选择。

暴风和三叉戟的合作，让用户可以用微批量代替纯流处理。虽然用户可以获得更多的灵活性来创建满足需求的工具，但同时，这种做法会削弱这种技术相对于其他解决方案的最大优势。话虽如此，多一个流处理方法总是好的。

核心风暴不能保证消息的处理顺序。Core Storm为消息提供了“至少一次”的处理保证，这意味着每条消息都可以被处理，但也可能被复制。Trident提供了严格的一次性处理保证，可以提供不同批次之间的顺序处理，但无法实现一个批次内的顺序处理。

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

摘要

Storm可能是最适合高延迟要求的纯流工作负载的技术。这项技术可以确保每个消息都得到处理，并且可以用于许多编程语言。因为Storm不能批处理，如果需要这些能力，可能需要使用其他软件。如果对严格的一次性待遇保障有很高的要求，这个时候可以考虑三叉戟。然而，在这种情况下，其他流处理框架可能更合适。

阿帕奇萨姆扎

Apache Samza是一个流处理框架，与Apache Kafka消息传递系统紧密结合。虽然Kafka可以用在很多流处理系统中，但是根据设计，Samza可以充分发挥Kafka独特的架构优势和保障。这项技术可以通过Kafka提供容错、缓冲和状态存储。

Samza可以使用YARN作为资源管理器。这意味着默认情况下需要Hadoop集群(至少是HDFS和YARN)，但也意味着Samza可以直接使用YARN丰富的内置函数。

流处理模式

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

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

分区:为了将一个主题传播到多个节点，Kafka会将传入的消息分成多个分区。分区将基于密钥，这可以确保包含相同密钥的每个消息都可以被划分到相同的分区中。可以保证分区的顺序。

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

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

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

由于卡夫卡相当于一个永恒的日志，Samza也需要处理一个永恒的数据流。这意味着任何转换创建的新数据流都可以被其他组件使用，而不会影响原始数据流。

优点和局限性

乍一看，Samza对Kafka查询系统的依赖似乎是一种限制，但它也可以为系统提供一些独特的保障和功能，这是其他流处理系统所不具备的。

例如，Kafka已经提供了可以以低延迟方式访问的数据存储的副本，并且它还可以为每个数据分区提供非常易用和低成本的多订户模型。所有输出，包括中间状态的结果，都可以写入Kafka，并且可以由下游步骤独立使用。

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

Samza和Kafka之间的密切关系使得处理步骤本身非常松散地耦合。您可以在输出的任何步骤中添加任意数量的订阅者，而无需事先协调，这对于拥有需要访问相似数据的多个团队的组织非常有用。多个团队都可以订阅进入系统的数据主题，也可以订阅其他团队经过一些数据处理后创建的主题。所有这些都不会给数据库等负载密集型基础设施带来额外的压力。

直接写入卡夫卡也可以避免背压的问题。背压是指由于峰值负载，数据流入速度超过组件的实时处理能力，可能导致处理工作停止，并可能丢失数据的情况。根据设计，Kafka可以长期保存数据，这意味着组件可以在方便的时候继续处理，可以直接重启，而不用担心任何后果。

Samza可以使用本地键值存储实现的容错检查点系统来存储数据。通过这种方式，Samza可以获得“至少一次”的交付保证，但面对数据多次交付导致的失败，这种技术无法提供汇总状态的准确恢复(如计数)。

与Storm和其他系统提供的原语相比，Samza提供的高级抽象在许多方面都更容易使用。目前Samza只支持JVM语言，也就是说在语言支持上不如Storm灵活。

摘要

在Hadoop和Kafka已经可用或易于实施的环境中，Apache Samza是流式工作负载的良好选择。Samza本身非常适合拥有多个团队的组织，这些团队需要在不同的处理阶段使用(但不一定相互密切协调)多个数据流。Samza可以大大简化许多流处理任务，并实现低延迟性能。如果部署需求与当前系统不兼容，可能不适合使用，但如果要求极低延迟处理或者对严格的一次性处理语义要求较高，仍然适合考虑。

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

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

可以看到，这个特性主要是由Spark和Flink实现的，下面将介绍这两个框架。实现这一功能的关键是如何将两种不同的处理方式统一起来，对固定和不固定数据集之间的关系应该做什么样的假设。

尽管专注于某种处理类型的项目将更好地满足特定用例的需求，但混合框架旨在为数据处理提供一个通用的解决方案。该框架不仅可以提供处理数据所需的方法，还提供了自己的集成项、库和工具，可以胜任图形分析、机器学习和交互式查询等各种任务。

阿帕奇火花

Apache Spark是具有流处理能力的下一代批处理框架。基于与Hadoop的MapReduce引擎相同原理开发的Spark，主要是通过完善的内存计算和处理优化机制来加快批量工作负载的运行速度。

Spark可以作为独立集群部署(在相应存储层的配合下)，也可以与Hadoop集成，替代MapReduce引擎。

成批处理方式

与MapReduce不同，Spark的数据处理都是在内存中完成的，只需要在一开始将数据读入内存并永久存储最终结果时，与存储层进行交互。所有中间状态的处理结果都存储在存储器中。

虽然内存中的处理方式可以大大提升性能，但是Spark在处理磁盘相关任务时的速度也有了很大的提升，因为它可以通过提前分析整个任务集来实现更完美的整体优化。正因如此，Spark可以创建一个有向无环图(DAG)来表示所有需要执行的操作、需要操作的数据以及操作和数据之间的关系，这样处理器就可以更加智能地协调任务。

为了在内存中实现批量计算，Spark将使用一种称为弹性分布式数据集(Resilient Distributed Dataset，RDD)的模型来处理数据。这是一个永恒的结构，表示一个数据集，只存在于内存中。在RDD上执行的操作可以生成新的RDD。每个RDD都可以通过血统追溯到父RDD，并最终追溯到磁盘上的数据。Spark可以通过RDD实现容错，无需将每次操作的结果写回磁盘。

流处理模式

流处理能力是通过火花流实现的。Spark本身主要是为批量处理工作量而设计的。为了弥补引擎设计和流处理工作负载特征之间的差异，Spark实现了一个叫做微批处理的概念)。在具体策略上，该技术可以将数据流视为一系列非常小的“批处理”，可以通过批处理引擎的原生语义进行处理。

Spark Streaming以亚秒级增量缓冲流，然后这些缓冲作为小规模固定数据集进行批量处理。这种方法的实际效果非常好，但是与真实的流处理框架相比，在性能上还是有一些不足。

优点和局限性

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

Spark的另一个重要优势在于它的多样性。该产品可以作为独立的集群部署，也可以与现有的Hadoop集群集成。该产品可以运行批处理和流处理，一个集群可以处理不同类型的任务。

除了引擎本身的能力，围绕Spark建立了包含各种库的生态系统，可以为机器学习、交互查询等任务提供更好的支持。与MapReduce相比，Spark任务“众所周知”，易于编写，因此可以大大提高生产率。

流处理系统采用批处理方式，进入系统的数据需要缓冲。缓冲机制使这种技术能够处理非常大量的输入数据，并提高整体吞吐量，但等待缓冲区变空也会导致延迟增加。这意味着Spark流可能不适合具有高延迟要求的工作负载。

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

Spark内存计算设计的另一个后果是，如果部署在* * *共享集群中，可能会遇到资源不足的问题。与HadoopMapReduce相比，Spark消耗的资源更多，可能会影响同时需要使用集群的其他任务。本质上，Spark不适合与Hadoop stack的其他组件存储在一起。

摘要

Spark是多样化工作负载处理任务的最佳选择。Spark批处理能力提供了无与伦比的速度优势，但代价是更高的内存消耗。对于重视吞吐量而非延迟的工作负载，Spark流更适合作为流解决方案。

阿帕奇弗林克

Apache Flink是一个流处理框架，可以处理批处理任务。这种技术可以将批处理数据视为具有有限边界的数据流，从而可以将批处理任务视为流处理的子集。对所有处理任务采用流处理优先的方法将会产生一系列有趣的副作用。

这种先流处理的方法也称为Kappa架构，与更广为人知的Lambda架构形成对比(在Lambda架构中，批处理作为主要处理方法，stream作为补充，并提供早期未精炼的结果)。Kappa架构会将所有东西进行流处理，以简化模型，这只有在流处理引擎最近成熟之后才可行。

流处理模型

Flink的流处理模型在处理传入数据时，将每个项目都视为一个真实的数据流。Flink提供的数据流API可以用来处理无穷无尽的数据流。Flink可以一起使用的基本组件包括:

流是指在系统中循环的永恒的、无限的数据集。

运算符是指针的功能，对一个数据流执行运算，生成其他数据流。

源是指数据流进入系统的入口点。

Sink是指数据流离开Flink系统后进入的位置，可以是数据库，也可以是连接其他系统的连接器。

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

此外，Flink的流处理能力还可以理解“事件时间”的概念，事件时间是指事件实际发生的时间，这个函数也可以处理会话。这意味着可以以某种有趣的方式确保执行顺序和分组。

批量模型

Flink的批处理模型在很大程度上只是对流处理模型的扩展。此时，模型不再从持久流中读取数据，而是以流的形式从持久存储中读取有界数据集。Flink将为这些处理模型使用完全相同的运行时。

Flink可以在一定程度上优化批处理工作量。例如，因为批处理操作可以由持久存储支持，所以Flink不能创建批处理工作负载的快照。数据仍然可以恢复，但是正常的处理操作可以更快地执行。

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

优点和局限性

Flink是目前处理框架领域的独特技术。虽然Spark也可以执行批处理和流处理，但Spark的流处理采用的微批处理架构使其不适合许多用例。Flink流处理首先可以提供低延迟、高吞吐量和几乎逐项的处理能力。

Flink的许多组件都是自我管理的。尽管这种做法很少见，但出于性能原因，这种技术可以自己管理内存，而不依赖于本机Java垃圾收集机制。与Spark不同，Flink在待处理数据的特性发生变化后，不需要手动优化和调整，技术也可以自行处理数据分区和自动缓存。

Flink会以多种方式分工，优化任务。这种分析在某种程度上类似于SQL查询规划器对关系数据库的优化，可以为具体任务确定最高效的实现方法。该技术还支持多阶段并行执行，可以将阻塞任务的数据聚集在一起。对于迭代任务，出于性能考虑，Flink会尝试在存储数据的节点上执行相应的计算任务。此外，还可以进行“增量迭代”，或者只迭代数据发生变化的部分。

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

Flink与其他组件配合良好。如果配合Hadoop stack使用，这种技术可以很好地融入整个环境，任何时候都只占用必要的资源。这种技术可以很容易地与纱、HDFS和卡夫卡结合起来。在兼容包的帮助下，Flink还可以运行为其他处理框架编写的任务，比如Hadoop和Storm。

目前来看，Flink最大的局限之一就是它还是一个非常“年轻”的项目。该项目在真实环境中的大规模部署并不像其他处理框架那样普遍，也没有深入研究Flink在可伸缩能力上的局限性。随着快速的开发周期和兼容包的完善，当越来越多的组织开始尝试时，可能会出现越来越多的Flink部署。

摘要

Flink提供低延迟的流处理，同时支持传统的批处理任务。Flink可能最适合具有极高流要求和少量批处理任务的组织。该技术兼容原生Storm和Hadoop程序，可以在YARN管理的集群上运行，因此可以很容易地进行评测。快速的开发工作使其值得关注。

结论

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

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

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

对于混合工作负载，Spark可以提供高速批处理和微批处理。这项技术的支持更加完善，有各种集成库和工具，可以实现灵活集成。Flink提供了真正的流处理和批处理功能。通过深度优化，它可以运行为其他平台编写的任务，并提供低延迟处理，但其实际应用仍为时尚早。

最合适的解决方案主要取决于要处理的数据的状态、对处理所需时间的需求以及期望的结果。具体来说，使用全功能解决方案还是主要专注于某个项目的解决方案，需要仔细权衡。随着它的成熟和被广泛接受，在评估任何新兴的创新解决方案时，需要考虑类似的问题。