Hadoop, Storm, Samza, Spark, 和 Flink：大数据框架比较
2016-10-13
分类：系统运维
阅读()
评论()
介绍
大数据是收集，组织，处理和收集大型数据集中的洞察所需的非传统战略和技术的总称。虽然使用超过单个计算机的计算能力或存储的数据的问题不是新的，但近年来这种类型的计算的普遍性，规模和价值已经大大扩展。 在先前的指导，我们讨论了一些的
一般概念，处理阶段，和术语在大数据系统中使用 。在本文中，我们将看一个大数据系统最重要的组件之一：处理框架。处理框架通过从非易失性存储器读取或者在其被摄取到系统中来计算系统中的数据。计算数据是从大量个体数据点提取信息和洞察的过程。 我们将涵盖以下框架：
什么是大数据处理框架？
处理框架和
处理引擎负责在一个数据系统数据的计算结束。虽然没有将“引擎”与“框架”分开的权威定义，但有时有用的是将前者定义为负责操作数据的实际组件，后者定义为设计为执行相同操作的一组组件。 例如
，Apache的Hadoop可以考虑用
MapReduce的
处理框架作为其默认的
处理引擎 。 发动机和框架通常可以交换出来或串联使用。 例如
，Apache星火 ，另一个框架，可以连接到Hadoop的更换MapReduce的。组件之间的这种互操作性是大数据系统具有很大灵活性的一个原因。 虽然处理数据生命周期的这一阶段的系统可能是复杂的，但是在广泛层面上的目标是非常相似的：对数据进行操作以增加理解，表面模式并且获得对复杂交互的洞察。 为了简化对这些组件的讨论，我们将按照它们设计处理的数据的状态将这些处理框架分组。一些系统批量处理数据，而其他系统在流入系统时以连续流处理数据。还有其他人可以以这些方式中的任何一种处理数据。 我们将介绍每种类型的处理作为一个概念，然后再介绍各种实现的细节和后果。
批处理系统
批处理有大数据世界中有着悠久的历史。批处理涉及对大的静态数据集进行操作，并在计算完成的稍后时间返回结果。 批处理中的数据集通常为...
- bounded：批量数据集表示数据的有限集合
- persistent：数据几乎总是由某种类型的永久存储器支持
- large：批处理操作通常是处理极大数据集的唯一选项
批处理非常适合于需要访问完整记录集的计算。例如，在计算总和和平均值时，必须整体处理数据集，而不是作为单个记录的集合。这些操作要求在计算的持续时间内保持该状态。 需要非常大量数据的任务通常最好由批处理操作来处理。无论数据集是从永久存储器直接处理还是加载到内存中，批处理系统都是在考虑大量数据的情况下构建的，并具有处理它们的资源。因为批处理在处理大量持久数据方面表现优异，所以它经常用于历史数据。 用于处理大量数据的权衡是较长的计算时间。因此，在处理时间特别显着的情况下，批处理是不合适的。
Apache Hadoop
Apache Hadoop是一个专门提供批处理的处理框架。 Hadoop是第一个在开源社区获得重大牵引力的大数据框架。基于Google的几篇论文和演讲，他们如何处理当时的大量数据，Hadoop重新实现了算法和组件，使大规模批处理更容易访问。 Hadoop的现代版本由几个组件或层组成，它们一起处理批处理数据：
- HDFS：HDFS是跨群集节点的坐标存储和复制分布式文件系统层。 HDFS确保数据保持可用，尽管不可避免的主机故障。它用作数据源，存储中间处理结果，并持久保存最终的计算结果。
- 纱 ：纱，它表示又一资源谈判，是在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集群本身经常用作其他软件的构建块。许多其他处理框架和引擎都使用Hadoop集成来利用HDFS和YARN资源管理器。
概要
Apache Hadoop及其MapReduce处理引擎提供了经过良好测试的批处理模型，最适合处理时间不是重要因素的非常大的数据集。运行良好的Hadoop集群所需的低成本组件使得该处理对于许多使用情况来说是便宜且有效的。与其他框架和引擎的兼容性和集成意味着Hadoop通常可以作为使用各种技术的多个处理工作负载的基础。
流处理系统
流处理系统计算过的数据，因为它进入该系统。这需要与批处理范例不同的处理模型。代替定义应用于整个数据集的操作，流处理器定义将在每个单独数据项通过系统时应用于其的操作。 流处理中的数据集被认为是“无界”。这有几个重要的含义：
- 总数据集仅定义为已进入系统迄今的数据量。
- 工作数据集可能是更相关的，并且在一个时间被限制在一个单一的项目。
- 处理是基于事件的，并且直到明确停止才会“结束”。结果立即可用，并且将在新数据到达时不断更新。
流处理系统可以处理几乎无限量的数据，但是它们一次仅处理一个（真实流处理）或非常少（微批处理）项，其中在记录之间保持最小状态。虽然大多数系统提供维护国家的一些方法，蒸汽处理高度与副作用少
功能更
强大的
处理进行
了优化。 功能操作集中于具有有限状态或副作用的离散步骤。对同一数据执行相同的操作将产生与其他因素无关的相同输出。这种处理适合流，因为项目之间的状态通常是困难的，有限的，有时是不期望的某种组合。因此，尽管某些类型的状态管理通常是可能的，但是在缺少这些框架的情况下，这些框架更加简单和高效。 这种类型的处理适用于某些类型的工作负载。具有近实时要求的处理由流模型很好地服务。分析，服务器或应用程序错误日志记录和其他基于时间的度量标准是非常合适的，因为对这些区域的更改做出反应对于业务功能至关重要。流处理非常适合于数据，您必须对变化或尖峰做出响应，并且随时间对趋势感兴趣。
Apache Storm
Apache Storm是一个流处理框架，专注于极低的延迟，并且可能是需要接近实时处理的工作负载的最佳选择。它可以处理非常大量的数据，并以比其他解决方案更少的延迟传递结果。
流处理模型
Storm流处理的工作原理是在调用
拓扑架构编排的DAG（有向无环图）。这些拓扑描述了当每个进入的数据进入系统时对其进行的各种变换或步骤。 拓扑结构包括：
- Streams ：传统的数据流。这是连续到达系统的无界数据。
- Spouts ：数据的来源在拓扑的边缘流。这些可以是产生要操作的数据的API，队列等。
- Bolts ：Bolts代表消耗流，适用的操作它们，并且将其结果作为流输出的处理步骤。Bolts连接到每个喷口，然后彼此连接以安排所有必要的处理。在拓扑结束时，最终Bolts输出可用作连接系统的输入。
Storm背后的想法是使用上述组件定义小的离散操作，然后将它们组合成一个拓扑。默认情况下，Storm提供至少一次的处理保证，这意味着它可以保证每个消息至少处理一次，但在一些故障情况下可能有重复。 Storm不保证将按顺序处理消息。 为了实现一次准确，状态处理，被称为
三叉戟抽象也可用。 是显式的，而不三叉戟Storm常被称为
核心Storm 。 Trident显着改变了Storm的处理动态，增加了延迟，为处理添加了状态，并实现了一个微批处理模型，而不是逐个项目的纯流系统。 Storm用户通常建议尽可能使用Core Storm以避免这些惩罚。考虑到这一点，Trident保证一次处理项目在系统不能智能地处理重复消息的情况下是有用的。当需要维护项目之间的状态时，例如在计算一小时内有多少用户点击链接时，Trident也是Storm中唯一的选择。三叉戟给予Storm灵活性，即使它不符合框架的自然优势。 Trident拓扑结构包括：
- 流批处理 ：这些是流数据的微批次被以提供批处理语义分块。
- 操作 ：这些是可以对数据进行分批的程序。
优点和局限性
Storm可能是目前可用于近实时处理的最佳解决方案。它能够以极低的延迟处理必须以最小延迟处理的工作负载的数据。当处理时间直接影响用户体验时，Storm通常是一个好的选择，例如当来自处理的反馈直接反馈到网站上的访问者的页面时。 Storm with Trident让您选择使用微批次，而不是纯流处理。虽然这给用户更大的灵活性来将工具塑造成预期的用途，但它也倾向于否定软件的一些最大的优势超过其他解决方案。话虽如此，有一个流处理风格的选择仍然是有帮助的。 Core Storm不提供消息的排序保证。 Core Storm提供至少一次的处理保证，这意味着可以保证每个消息的处理，但可能发生重复。 Trident提供一次性保证，并可以在批次之间提供订购，但不在内。 在互操作性方面，Storm可以与Hadoop的YARN资源协商器集成，使其易于连接到现有的Hadoop部署。除了大多数处理框架，Storm具有非常广泛的语言支持，为用户提供了定义拓扑的许多选项。
概要
对于具有非常严格的延迟要求的纯流处理工作负载，Storm可能是最好的成熟选项。它可以保证消息处理，并且可以与大量的编程语言一起使用。因为Storm不执行批处理，如果您需要这些功能，则必须使用其他软件。如果你对一次性加工保证有很强的需求，Trident可以提供。但是，其他流处理框架在这一点上也可能更好。
Apache Samza
Apache Samza是一个流绑定到Apache Kafka消息系统的流处理框架。虽然Kafka可以被许多流处理系统使用，Samza专门设计利用Kafka独特的架构和保证。它使用Kafka提供容错，缓冲和状态存储。 Samza使用YARN进行资源协商。这意味着默认情况下，需要Hadoop集群（至少HDFS和YARN），但这也意味着Samza可以依赖于内置于YARN中的丰富的功能。
流处理模型
Samza依赖Kafka的语义来定义流的处理方式。 Kafka在处理数据时使用以下概念：
- 主题 ：进入Kafka系统数据的每个数据流被称为一个主题。主题基本上是消费者可以订阅的相关信息流。
- 分区 ：为了分发节点之间的话题，Kafka把传入的邮件到分区。分区分区基于密钥，使得具有相同密钥的每个消息被保证被发送到同一分区。分区保证了排序。
- 经纪人 ：各个节点组成一个集群Kafka被称为代理。
- 制片人 ：任何组件写入Kafka题目就叫制片人。生产者提供用于分割主题的键。
- 消费者 ：消费者是从Kafka主题读取任何组件。消费者负责维护关于它们自己的偏移的信息，使得他们知道如果发生故障则处理了哪些记录。
因为Kafka代表不可变的日志，Samza处理不可变的流。这意味着任何转换都会创建由其他组件使用而不影响初始流的新流。
优点和局限性
Samza一开始就依赖Kafka排队系统似乎有限制性。然而，它为系统提供了一些独特的保证和在其他流处理系统中不常见的特性。 例如，Kafka已经提供了可以以低延迟访问的数据的复制存储。它还为每个单独的数据分区提供了非常容易和廉价的多用户模型。所有输出，包括中间结果，也写入Kafka，并可以由下游阶段独立消耗。 在许多方面，这种对Kafka的严重依赖反映了MapReduce引擎频繁引用HDFS的方式。虽然在每次计算之间引用HDFS会导致批处理时的一些严重的性能问题，但它解决了流处理时的一些问题。 Samza与Kafka的强烈关系使得加工步骤本身可以非常松散地捆绑在一起。任意数量的订户可以添加到任何步骤的输出，而无需事先协调。这对于多个团队可能需要访问类似数据的组织非常有用。团队都可以订阅进入系统的数据主题，或者可以轻松订阅已经过一些处理的其他团队创建的主题。这可以在不对负载敏感的基础设施（如数据库）增加额外压力的情况下完成。 写直Kafka也消除
背压的问题。背压是当负载尖峰导致以大于组件可以实时处理的速率流入数据时，导致处理停滞和潜在的数据丢失。 Kafka旨在保存数据很长一段时间，这意味着组件可以在方便的时候进行处理，并且可以重新启动而不会产生后果。 Samza能够使用实现为本地键值存储的容错检查点系统来存储状态。这允许Samza提供至少一次传递保证，但它不提供在失败的情况下聚合状态（如计数）的准确恢复，因为数据可能会多次传递。 Samza提供了高级抽象，在许多方面比由Storm等系统提供的原语更容易工作。 Samza目前仅支持JVM语言，这意味着它不具有与Storm相同的语言灵活性。
概要
Apache Samza是流工作负载的理想选择，Hadoop和Kafka已经可用或明智地实现。 Samza本身非常适合具有多个团队的组织在各个处理阶段使用（但不一定紧密协调）数据流。 Samza大大简化了流处理的许多部分，并提供低延迟性能。如果部署要求与当前系统不兼容，如果您需要极低延迟处理，或者您对完全一次性语义有强烈需求，那么它可能不是一个合适的选择。
混合处理系统：批处理和流处理器
一些处理框架可以处理批处理和流工作负载。这些框架通过允许相同或相关的组件和API用于这两种类型的数据来简化不同的处理需求。 正如你将看到的，Spark和Flink之间的实现方式差异很大，我们将讨论两个框架。这在很大程度上是如何将两个处理范例结合在一起的函数，以及对固定和非固定数据集之间的关系做出了什么假设。 虽然专注于一种处理类型的项目可能非常适合特定的用例，但混合框架试图为数据处理提供一个通用解决方案。它们不仅提供了用于处理数据的方法，它们具有自己的集成，库和工具，用于执行图形分析，机器学习和交互式查询等操作。
Apache Spark
Apache Spark是具有流处理能力的下一代批处理框架。使用许多与Hadoop MapReduce引擎相同的原理构建，Spark主要通过提供完整的内存计算和处理优化来加快批处理工作负载。 Spark可以部署为独立集群（如果与有能力的存储层配合使用），也可以挂钩到Hadoop作为MapReduce引擎的替代。
批处理模型
与MapReduce不同，Spark处理内存中的所有数据，只与存储层交互，最初将数据加载到内存中，最后保存最终结果。所有中间结果都在内存中管理。 虽然内存中处理大大提高了速度，但Spark对磁盘相关任务的速度也更快，因为整体优化可以通过提前分析完整的任务集来实现。它通过创建有向非循环图达到这一点，或者它代表所有所必须执行的操作的
DAG的 ，要操作的数据上，以及它们之间的关系，使所述处理器的更大的智能协调工作的能力。 为了实现内存批量计算，星火使用一种称为所谓的弹性分布式数据集或
RDDS模型，处理数据。这些是存储在存储器中的表示数据集合的不可变结构。 RDDs的操作产生新的RDD。每个RDD可以通过其父RDD并最终到磁盘上的数据跟踪其谱系。基本上，RDD是Spark维护容错而无需在每次操作后写回磁盘的一种方式。
流处理模型
流处理能力由Spark Streaming提供。 Spark本身设计时考虑到面向批处理的工作负载。为应对发动机的设计和流工作负载的特性之间的差距，实现星火一种叫做
微批次 *概念。此策略旨在将数据流视为一系列非常小的批次，可使用批处理引擎的本机语义进行处理。 Spark Streaming通过以亚秒级增量缓冲流来工作。这些作为小的固定数据集发送用于批处理。在实践中，这个工作相当好，但它的确导致不同的性能配置文件比真正的流处理框架。
优点和局限性
使用Spark over Hadoop MapReduce的明显原因是速度。 Spark可以显着更快地处理相同的数据集，因为它的内存计算策略和其高级DAG调度。 Spark的另一个主要优点是其多功能性。它可以部署为独立集群或与现有Hadoop集群集成。它可以执行批处理和流处理，让您操作单个集群以处理多种处理风格。 除了引擎本身的功能之外，Spark还有一个可用于机器学习，交互式查询等的图书馆生态系统。Spark任务几乎被普遍认为比MapReduce更容易编写，这对生产力有重要影响。 使用流处理的批处理方法涉及在数据进入系统时缓冲数据。缓冲器允许它处理大量的输入数据，增加总吞吐量，但等待刷新缓冲器也导致延迟的显着增加。这意味着Spark Streaming可能不适合在需要低延迟的情况下进行处理。 由于RAM通常比磁盘空间更昂贵，Spark的运行成本比基于磁盘的系统要高。然而，增加的处理速度意味着任务可以完成得更快，这可以完全抵消在每小时支付资源的环境中操作的成本。 Spark的内存中设计的另一个结果是，资源稀缺在部署在共享集群上时可能是一个问题。与Hadoop的MapReduce相比，Spark使用了更多的资源，这可能会干扰可能试图使用集群的其他任务。实质上，Spark可能是一个不太关心的邻居，而不是可以在Hadoop上运行的其他组件。
概要
Spark对于具有不同处理工作负载的用户来说是一个很好的选择。火花批处理提供了令人难以置信的速度优势，交易高内存使用。 Spark Streaming是一种用于工作负载的良好流处理解决方案，可以显着延长吞吐量。
Apache Flink
Apache Flink是一个流处理框架，也可以处理批处理任务。它认为批量仅仅是具有有限边界的数据流，并且因此将批处理视为流处理的子集。这种流首先的方法对所有的处理有许多有趣的副作用。 这个数据流的第一种方法被称为
卡帕架构 ，在对比的是更广泛地已知LAMBDA架构（其中配料被用作与用于补充和早期提供但粗大豆结果流中的主处理方法）。 Kappa架构，其中流用于一切，简化了模型，并且只是最近变得可能，因为流处理引擎已经变得更加复杂。
流处理模型
Flink的流处理模型将输入数据逐个项目地处理为真实流。 Flink提供了DataStream API来处理无界的数据流。 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中使用，它被写为一个好的邻居，在任何给定的时间只占用必要的资源。它易于与YARN，HDFS和Kafka集成。 Flink可以运行为其他处理框架（如Hadoop和Storm）编写的任务和兼容性包。 Flink目前最大的缺点之一是它仍然是一个非常年轻的项目。在野外的大规模部署仍然没有其他处理框架那么普遍，也没有对Flink的缩放限制进行太多研究。随着快速开发周期和功能，如兼容性包，可能开始更多的Flink部署，因为组织有机会进行实验。
概要
Flink提供低延迟流处理和支持传统的批处理任务。 Flink可能最适合具有强大流处理需求和一些面向批处理任务的组织。它与本机Storm和Hadoop程序的兼容性及其在YARN托管集群上运行的能力可以使其易于评估。它的快速发展使它值得关注。
结论
在大数据系统中有许多处理选项。 对于非时间敏感的仅批处理工作负载，Hadoop是一个好的选择，实施起来可能比其他解决方案更便宜。 对于纯流工作负载，Storm具有广泛的语言支持，并且可以提供极低延迟的处理，但是可以提供重复的并且不能保证其默认配置中的排序。 Samza与YARN和Kafka紧密集成，以提供灵活性，轻松的多团队使用以及简单的复制和状态管理。 对于混合工作负载，Spark提供高速批处理和流处理的微批处理。它具有广泛的支持，集成的库和工具，以及灵活的集成。 Flink提供真正的流处理支持批处理。它被大量优化，可以运行为其他平台编写的任务，并提供低延迟处理，但仍处于早期采用。 最适合您的情况将取决于要处理的数据的状态，您的需求的时间范围以及您感兴趣的结果类型。在实现一体化解决方案之间存在权衡并与重点突出的项目合作，在对其成熟和经过良好测试的同行评估新的和创新的解决方案时也有类似的考虑。
觉得文章有用就打赏一下文章作者
支付宝扫一扫打赏
微信扫一扫打赏
