Hadoop、Spark、Storm、Flink是比较常用的分布式计算系统
1）仅批处理框架：Hadoop常用于离线的复杂的大数据处理。
2）仅流处理框架：Samza与YARN和Kafka紧密集成的流处理，Storm常用于在线的实时的大数据处理。
3）混合框架：Spark常用于离线的快速的大数据处理（基于内存），Flink可扩展的批处理和流式数据处理的数据处理平台。
关于Hadoop
Hadoop介绍
大数据架构之基于hadoop的大数据生态圈也是分布式架构的一种，主要处理的是巨量数据的挖掘分析等。Hadoop是一个分布式系统基础框架，由Apache基金会开发,用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力高速运算和存储。基于这个框架开发分布式应用程序，利用集群的高速运算和存储的威力。Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问（streaming access）文件系统中的数据。类似于，基于NVIDIA的CUDA并行架构开发并行程序，发挥GPU的并行计算能力。（NVIDIA：官方中文名称英伟达的简称，是一家以设计智核芯片组为主的无晶圆（Fabless）IC半导体公司。CUDA是一种开发环境。）
Hadoop的框架最核心的设计就是：HDFS和Map Reduce。HDFS为海量的数据提供了存储，则Map Reduce为海量的数据提供了计算。Hadoop平台的一个大特点就是坑多。Hadoop是一种专用于批处理的处理框架。Hadoop是首个在开源社区获得极大关注的大数据框架。基于谷歌有关海量数据处理所发表的多篇论文与经验的Hadoop重新实现了相关算法和组件堆栈，让大规模批处理技术变得更易用。
Hadoop历史
由于Google没有开源Google分布式计算模型的技术实现，所以其他互联网公司只能根据Google三篇技术论文中的相关原理，搭建自己的分布式计算系统。Yahoo的工程师Doug Cutting和Mike Cafarella在2005年合作开发了分布式计算系统Hadoop。后来，Hadoop被贡献给了Apache基金会，成为了Apache基金会的开源项目。Doug Cutting也成为Apache基金会的主席，主持Hadoop的开发工作。Hadoop采用MapReduce分布式计算框架，并根据GFS开发了HDFS分布式文件系统（GFS->HDFS），根据BigTable开发了HBase数据存储系统。（BigTable->HBase）尽管和Google内部使用的分布式计算系统原理相同，但是Hadoop在运算速度上依然达不到Google论文中的标准。不过，Hadoop的开源特性使其成为分布式计算系统的事实上的国际标准。Yahoo，Facebook，Amazon以及国内的百度，阿里巴巴等众多互联网公司都以Hadoop为基础搭建自己的分布式计算系统。
Hadoop的批处理模式
Hadoop的处理功能来自MapReduce引擎。MapReduce的处理技术符合使用键值对的map、shuffle、reduce算法要求。基本处理过程包括：
①从HDFS文件系统读取数据集
②将数据集拆分成小块并分配给所有可用节点
③针对每个节点上的数据子集进行计算（计算的中间态结果会重新写入HDFS）
④重新分配中间态结果并按照键进行分组
⑤通过对每个节点计算的结果进行汇总和组合对每个键的值进行“Reducing”
⑥将计算而来的最终结果重新写入HDFS
Hadoop概括原理
开源的可运行于大规模集群上的分布式并行编程框架，其最核心的设计包括：Map Reduce和HDFS。基于 Hadoop,你可以轻松地编写可处理海量数据的分布式并行程序，并将其运行于由成百上千个结点组成的大规模计算机集群上。简单的说：Map Reduce框架的核心步骤主要分两部分：Map和Reduce。当你向Map Reduce框架提交一个计算作业时，它会首先把计算作业拆分成若干个Map任务，然后分配到不同的节点上去执行，每一个Map任务处理输入数据中的一部分，当Map任务完成后，它会生成一些中间文件，这些中间文件将会作为Reduce任务的输入数据。Reduce对数据做进一步处理之后，输出最终结果。Map Reduce是Hadoop的核心技术之一，为分布式计算的程序设计提供了良好的编程接口，并且屏蔽了底层通信原理，使得程序员只需关心业务逻辑本事，就可轻易的编写出基于集群的分布式并行程序。从它名字上来看，大致可以看出个两个动词Map和Reduce，“Map（展开）”就是将一个任务分解成为多个子任务并行的执行，“Reduce”就是将分解后多任务处理的结果汇总起来，得出最后的分析结果并输出。适合用 Map Reduce来处理的数据集(或任务)有一个基本要求：待处理的数据集可以分解成许多小的数据集，而且每一个小数据集都可以完全并行地进行处理。
Hadoop优势和局限
由于这种方法严重依赖持久存储，每个任务需要多次执行读取和写入操作，因此速度相对较慢。但另一方面由于磁盘空间通常是服务器上最丰富的资源，这意味着MapReduce可以处理非常海量的数据集。同时也意味着相比其他类似技术，Hadoop的MapReduce通常可以在廉价硬件上运行，因为该技术并不需要将一切都存储在内存中。MapReduce具备极高的缩放潜力，生产环境中曾经出现过包含数万个节点的应用。MapReduce的学习曲线较为陡峭，虽然Hadoop生态系统的其他周边技术可以大幅降低这一问题的影响，但通过Hadoop集群快速实现某些应用时依然需要注意这个问题。围绕Hadoop已经形成了辽阔的生态系统，Hadoop集群本身也经常被用作其他软件的组成部件。很多其他处理框架和引擎通过与Hadoop集成也可以使用HDFS和YARN资源管理器。
hadoop总结
Apache Hadoop及其MapReduce处理引擎提供了一套久经考验的批处理模型，最适合处理对时间要求不高的非常大规模数据集。通过非常低成本的组件即可搭建完整功能的Hadoop集群，使得这一廉价且高效的处理技术可以灵活应用在很多案例中。与其他框架和引擎的兼容与集成能力使得Hadoop可以成为使用不同技术的多种工作负载处理平台的底层基础。
关于Spark
如果Hadoop是一头大象，那spark相当于大象的翅膀。spark批处理为主，流处理为辅，俗称微批。
spark介绍
Apache Spark 是专为大规模数据处理而设计的快速通用的计算引擎。Spark是UC Berkeley AMP lab (加州大学伯克利分校的AMP实验室)所开源的类Hadoop MapReduce的通用并行框架，Spark，拥有Hadoop MapReduce所具有的优点；但不同于MapReduce的是——Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。
Spark 是一种与Hadoop相似的开源集群计算环境，但是两者之间还存在一些不同之处，这些有用的不同之处使Spark在某些工作
负载方面表现得更加优越，换句话说，Spark启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。Spark是在Scala语言中实现的，它将Scala用作其应用程序框架。与Hadoop不同，Spark和Scala能够紧密集成，其中的Scala可以像操作本地集合对象一样轻松地操作分布式数据集。
尽管创建Spark是为了支持分布式数据集上的迭代作业，但是实际上它是对Hadoop的补充，可以在Hadoop文件系统中并行运行。通过名为Mesos等第三方集群框架可以支持此行为。
Spark是一种包含流处理能力的下一代批处理框架,与Hadoop的MapReduce引擎基于各种相同原则开发而来的Spark主要侧重于通过完善的内存计算和处理优化机制加快批处理工作负载的运行速度。Spark可作为独立集群部署（需要相应存储层的配合），或可与Hadoop集成并取代MapReduce引擎。
Spark批处理模式
与MapReduce不同，Spark的数据处理工作全部在内存中进行，只在一开始将数据读入内存，以及将最终结果持久存储时需要与存储层交互。所有中间态的处理结果均存储在内存中。虽然内存中处理方式可大幅改善性能，Spark在处理与磁盘有关的任务时速度也有很大提升，因为通过提前对整个任务集进行分析可以实现更完善的整体式优化。为此Spark可创建代表所需执行的全部操作，需要操作的数据，以及操作和数据之间关系的Directed Acyclic Graph（有向无环图），即DAG，借此处理器可以对任务进行更智能的协调。为了实现内存中批计算，Spark会使用一种名为Resilient Distributed Dataset（弹性分布式数据集），即RDD的模型来处理数据。这是一种代表数据集，只位于内存中，永恒不变的结构。针对RDD执行的操作可生成新的RDD。每个RDD可通过世系（Lineage）回溯至父级RDD，并最终回溯至磁盘上的数据。Spark可通过RDD在无需将每个操作的结果写回磁盘的前提下实现容错。
Spark流处理模式
流处理能力是由Spark Streaming实现的。Spark本身在设计上主要面向批处理工作负载，为了弥补引擎设计和流处理工作负载特征方面的差异，Spark实现了一种叫做微批（Micro-batch）*的概念。在具体策略方面该技术可以将数据流视作一系列非常小的“批”，借此即可通过批处理引擎的原生语义进行处理。Spark Streaming会以亚秒级增量对流进行缓冲，随后这些缓冲会作为小规模的固定数据集进行批处理。这种方式的实际效果非常好，但相比真正的流处理框架在性能方面依然存在不足。
Spark的功能特点
1）高级 API 剥离了对集群本身的关注，Spark 应用开发者可以专注于应用所要做的计算本身。
2）Spark很快，支持交互式计算和复杂算法。
3）Spark是一个通用引擎，可用它来完成各种各样的运算，包括SQL查询、文本处理、机器学习等，而在Spark出现之前，我们一般需要学习各种各样的引擎来分别处理这些需求。
Spark的性能特点
1）速度更快-内存计算下，Spark比Hadoop快100倍。
2）易用性-Spark提供了80多个高级运算符。
3）通用性-Spark提供了大量的库，包括SQL、DataFrames、MLlib、GraphX、Spark Streaming。开发者可以在同一个应用程序中无缝组合使用这些库。
4）支持多种资源管理器-Spark支持Hadoop YARN，Apache Mesos，及其自带的独立集群管理器。
Spark优势和局限
使用Spark而非Hadoop MapReduce的主要原因是速度。在内存计算策略和先进的DAG调度等机制的帮助下，Spark可以用更快速度处理相同的数据集。Spark的另一个重要优势在于多样性。该产品可作为独立集群部署，或与现有Hadoop集群集成。该产品可运行批处理和流处理，运行一个集群即可处理不同类型的任务。除了引擎自身的能力外，围绕Spark还建立了包含各种库的生态系统，可为机器学习、交互式查询等任务提供更好的支持。相比MapReduce，Spark任务更是“众所周知”地易于编写，因此可大幅提高生产力。为流处理系统采用批处理的方法，需要对进入系统的数据进行缓冲。缓冲机制使得该技术可以处理非常大量的传入数据，提高整体吞吐率，但等待缓冲区清空也会导致延迟增高。这意味着Spark Streaming可能不适合处理对延迟有较高要求的工作负载。由于内存通常比磁盘空间更贵，因此相比基于磁盘的系统，Spark成本更高。然而处理速度的提升意味着可以更快速完成任务，在需要按照小时数为资源付费的环境中，这一特性通常可以抵消增加的成本。Spark内存计算这一设计的另一个后果是，如果部署在共享的集群中可能会遇到资源不足的问题。相比Hadoop MapReduce，Spark的资源消耗更大，可能会对需要在同一时间使用集群的其他任务产生影响。从本质来看，Spark更不太适合与Hadoop堆栈的其他组件共存一处。
Spark总结
Spark是多样化工作负载处理任务的最佳选择。Spark批处理能力以更高内存占用为代价提供了无与伦比的速度优势。对于重视吞吐率而非延迟的工作负载，则比较适合使用Spark Streaming作为流处理解决方案。
关于Flink
流处理为主，批处理为辅，与spark相反。
Flink介绍
Flink是一种可以处理批处理任务的流处理框架。该技术可将批处理数据视作具备有限边界的数据流，借此将批处理任务作为流处理的子集加以处理。为所有处理任务采取流处理为先的方法会产生一系列有趣的副作用。这种流处理为先的方法也叫做Kappa架构，与之相对的是更加被广为人知的Lambda架构（该架构中使用批处理作为主要处理方法，使用流作为补充并提供早期未经提炼的结果）。Kappa架构中会对一切进行流处理，借此对模型进行简化，而这一切是在最近流处理引擎逐渐成熟后才可行的。
Flink流处理模型
Flink的流处理模型在处理传入数据时会将每一项视作真正的数据流。Flink提供的DataStream API可用于处理无尽的数据流。Flink可配合使用的基本组件包括：
1）Stream（流）是指在系统中流转的，永恒不变的无边界数据集。
2）Operator（操作方）是指针对数据流执行操作以产生其他数据流的功能。
3）Source（源）是指数据流进入系统的入口点。
4）Sink（槽）是指数据流离开Flink系统后进入到的位置，槽可以是数据库或到其他系统的连接器。
为了在计算过程中遇到问题后能够恢复，流处理任务会在预定时间点创建快照。为了实现状态存储，Flink可配合多种状态后端系统使用，具体取决于所需实现的复杂度和持久性级别。此外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堆栈使用，该技术可以很好地融入整个环境，在任何时候都只占用必要的资源。该技术可轻松地与YARN、HDFS和Kafka 集成。在兼容包的帮助下，Flink还可以运行为其他处理框架，例如Hadoop和Storm编写的任务。目前Flink最大的局限之一在于这依然是一个“年幼”的项目。现实环境中该项目的大规模部署尚不如其他处理框架那么常见，对于Flink在缩放能力方面的局限目前也没有较为深入的研究。随着快速开发周期的推进和兼容包等功能的完善，当越来越多的组织开始尝试时，可能会出现越来越多的Flink部署。
Flink总结
Flink提供了低延迟流处理，同时可支持传统的批处理任务。Flink也许最适合有极高流处理需求，并有少量批处理任务的组织。该技术可兼容原生Storm和Hadoop程序，可在YARN管理的集群上运行，因此可以很方便地进行评估。快速进展的开发工作使其值得被大家关注。通过一系列关于Flink的介绍，可以感觉到Flink具有很大的发展空间和扩展性。
关于Storm
Apache Storm是一种侧重于极低延迟的流处理框架，也许是要求近实时处理的工作负载的最佳选择。该技术可处理非常大量的数据，通过比其他解决方案更低的延迟提供结果。
storm流处理模式
Storm的流处理可对框架中名为Topology（拓扑）的DAG（Directed Acyclic Graph，有向无环图）进行编排。这些拓扑描述了当数据片段进入系统后，需要对每个传入的片段执行的不同转换或步骤。
拓扑包含：
1)Stream：普通的数据流，这是一种会持续抵达系统的无边界数据。
2)Spout：位于拓扑边缘的数据流来源，例如可以是API或查询等，从这里可以产生待处理的数据。
3)Bolt：Bolt代表需要消耗流数据，对其应用操作，并将结果以流的形式进行输出的处理步骤。Bolt需要与每个Spout建立连接，随后相互连接以组成所有必要的处理。在拓扑的尾部，可以使用最终的Bolt输出作为相互连接的其他系统的输入。Storm背后的想法是使用上述组件定义大量小型的离散操作，随后将多个组件组成所需拓扑。默认情况下Storm提供了“至少一次”的处理保证，这意味着可以确保每条消息至少可以被处理一次，但某些情况下如果遇到失败可能会处理多次。Storm无法确保可以按照特定顺序处理消息。为了实现严格的一次处理，即有状态处理，可以使用一种名为Trident的抽象。严格来说不使用Trident的Storm通常可称之为Core Storm。Trident会对Storm的处理能力产生极大影响，会增加延迟，为处理提供状态，使用微批模式代替逐项处理的纯粹流处理模式。为避免这些问题，通常建议Storm用户尽可能使用Core Storm。然而也要注意，Trident对内容严格的一次处理保证在某些情况下也比较有用，例如系统无法智能地处理重复消息时。如果需要在项之间维持状态，例如想要计算一个小时内有多少用户点击了某个链接，此时Trident将是你唯一的选择。尽管不能充分发挥框架与生俱来的优势，但Trident提高了Storm的灵活性。
Trident拓扑包含：
①流批（Stream batch）：这是指流数据的微批，可通过分块提供批处理语义。
②操作（Operation）：是指可以对数据执行的批处理过程。
加入Trident，提供数据状态，storm处理变慢，变为微批处理。
不加Trident（Core Storm），纯粹的流式处理模式，速度较快，出意外时无法保证特定顺序。
storm优势和局限
目前来说Storm可能是近实时处理领域的最佳解决方案。该技术可以用极低延迟处理数据，可用于希望获得最低延迟的工作负载。如果处理速度直接影响用户体验，例如需要将处理结果直接提供给访客打开的网站页面，此时Storm将会是一个很好的选择。Storm与Trident配合使得用户可以用微批代替纯粹的流处理。虽然借此用户可以获得更大灵活性打造更符合要求的工具，但同时这种做法会削弱该技术相比其他解决方案最大的优势。话虽如此，但多一种流处理方式总是好的。Core Storm无法保证消息的处理顺序。Core Storm为消息提供了“至少一次”的处理保证，这意味着可以保证每条消息都能被处理，但也可能发生重复。Trident提供了严格的一次处理保证，可以在不同批之间提供顺序处理，但无法在一个批内部实现顺序处理。在互操作性方面，Storm可与Hadoop的YARN资源管理器进行集成，因此可以很方便地融入现有Hadoop部署。除了支持大部分处理框架，Storm还可支持多种语言，为用户的拓扑定义提供了更多选择。
storm总结
对于延迟需求很高的纯粹的流处理工作负载，Storm可能是最适合的技术。该技术可以保证每条消息都被处理，可配合多种编程语言使用。由于Storm无法进行批处理，如果需要这些能力可能还需要使用其他软件。如果对严格的一次处理保证有比较高的要求，此时可考虑使用Trident。不过这种情况下其他流处理框架也许更适合。
关于Samza
Apache Samza是一种与Apache Kafka消息系统紧密绑定的流处理框架。虽然Kafka可用于很多流处理系统，但按照设计，Samza可以更好地发挥Kafka独特的架构优势和保障。该技术可通过Kafka提供容错、缓冲，以及状态存储。Samza可使用YARN作为资源管理器。这意味着默认情况下需要具备Hadoop集群（至少具备HDFS和YARN），但同时也意味着Samza可以直接使用YARN丰富的内建功能。
Samza流处理模式
Samza依赖Kafka的语义定义流的处理方式。Kafka在处理数据时涉及下列概念：
1）Topic（话题）：进入Kafka系统的每个数据流可称之为一个话题。话题基本上是一种可供消耗方订阅的，由相关信息组成的数据流。
2）Partition（分区）：为了将一个话题分散至多个节点，Kafka会将传入的消息划分为多个分区。分区的划分将基于键（Key）进行，这样可以保证包含同一个键的每条消息可以划分至同一个分区。分区的顺序可获得保证。
3）Broker（代理）：组成Kafka集群的每个节点也叫做代理。
4）Producer（生成方）：任何向Kafka话题写入数据的组件可以叫做生成方。生成方可提供将话题划分为分区所需的键。
5）Consumer（消耗方）：任何从Kafka读取话题的组件可叫做消耗方。消耗方需要负责维持有关自己分支的信息，这样即可在失败后知道哪些记录已经被处理过了。 由于Kafka相当于永恒不变的日志，Samza也需要处理永恒不变的数据流。这意味着任何转换创建的新数据流都可被其他组件所使用，而不会对最初的数据流产生影响。
Samza优势和局限
乍看之下，Samza对Kafka类查询系统的依赖似乎是一种限制，然而这也可以为系统提供一些独特的保证和功能，这些内容也是其他流处理系统不具备的。例如Kafka已经提供了可以通过低延迟方式访问的数据存储副本，此外还可以为每个数据分区提供非常易用且低成本的多订阅者模型。所有输出内容，包括中间态的结果都可写入到Kafka，并可被下游步骤独立使用。这种对Kafka的紧密依赖在很多方面类似于MapReduce引擎对HDFS的依赖。虽然在批处理的每个计算之间对HDFS的依赖导致了一些严重的性能问题，但也避免了流处理遇到的很多其他问题。Samza与Kafka之间紧密的关系使得处理步骤本身可以非常松散地耦合在一起。无需事先协调，即可在输出的任何步骤中增加任意数量的订阅者，对于有多个团队需要访问类似数据的组织，这一特性非常有用。多个团队可以全部订阅进入系统的数据话题，或任意订阅其他团队对数据进行过某些处理后创建的话题。这一切并不会对数据库等负载密集型基础架构造成额外的压力。直接写入Kafka还可避免回压（Backpressure）问题。回压是指当负载峰值导致数据流入速度超过组件实时处理能力的情况，这种情况可能导致处理工作停顿并可能丢失数据。按照设计，Kafka可以将数据保存很长时间，这意味着组件可以在方便的时候继续进行处理，并可直接重启动而无需担心造成任何后果。
Samza可以使用以本地键值存储方式实现的容错检查点系统存储数据。这样Samza即可获得“至少一次”的交付保障，但面对由于数据可能多次交付造成的失败，该技术无法对汇总后状态（例如计数）提供精确恢复。Samza提供的高级抽象使其在很多方面比Storm等系统提供的基元（Primitive）更易于配合使用。目前Samza只支持JVM语言，这意味着它在语言支持方面不如Storm灵活。
Samza总结
对于已经具备或易于实现Hadoop和Kafka的环境，Apache Samza是流处理工作负载一个很好的选择。Samza本身很适合有多个团队需要使用（但相互之间并不一定紧密协调）不同处理阶段的多个数据流的组织。Samza可大幅简化很多流处理工作，可实现低延迟的性能。如果部署需求与当前系统不兼容，也许并不适合使用，但如果需要极低延迟的处理，或对严格的一次处理语义有较高需求，此时依然适合考虑。(总之没有storm灵活)
hadoop和spark特性对比
1）二者的主要模块
hadoop四个主要模块：①Hadoop Common②Hadoop分布式文件系统(HDFS)③Hadoop YARN④Hadoop MapReduce
Spark核心组件可以和其他一些高效的软件库无缝连接使用：①SparkSQL②Spark Streming③MLlib(机器学习专用)④GraphX
2）Hadoop vs Spark使用难易度
随带易于使用的API，支持Scala(原生语言)、Java、Python和Spark SQL。Spark SQL非常类似于SQL 92，且有一种交互模式，可马上上手。
Hadoop MapReduce没有交互模式，有Hive和Pig等附加模块，采用者使用MapReduce更加容易。Spark因易用性受到追捧。
3）Hadoop vs Spark使用成本对比
MapReduce和Spark都是Apache项目，是开源免费软件产品。MapReduce使用常规数量的内存，Spark需要大量内存。需要速度更快的磁盘和大量磁盘空间来运行MapReduce，需要更多的系统，将磁盘输入/输出分布到多个系统上。Spark系统的成本更高，但技术减少了数量，最终结果是系统成本较高，但是数量大大减少。
4）Hadoop vs Spark数据处理方式
Hadoop MapReduce使用批量处理，不断收集来自网站的信息，不需要这些数据具有实时性或近乎实时性。Hadoop MapReduce运行顺序：集群读取-执行操作-写回到集群-读取更新后的数据-执行下一个数据操作Spark使用内存处理在内存中处理一切数据，为来自多个来源的数据提供了近乎实时分析的功能。Spark执行类似的操作，不过是在内存中一步执行：集群读取-执行操作-写回到集群。
5）Hadoop vs Spark二者兼容性
在兼容性一点上，二者互相兼容，MapReduce通过JDBC和ODC兼容诸多数据源、文件格式和商业智能工具，Spark亦是如此。
6）Hadoop vs Spark容错性
MapReduce使用TaskTracker节点，它为 JobTracker节点提供了心跳(heartbeat)Spark用弹性分布式数据集(RDD)，它们是容错集合，里面的数据元素可执行并行操作，使RDD可以引用外部存储系统中的数据集，Spark可以用Hadoop支持的任何存储源创建RDD ，Spark的缓存也具有容错性。
7）Hadoop vs Spark可扩展性
MapReduce和Spark都可以使用HDFS来扩展据目前所知，最大的Hadoop集群是42000个节点，可以说扩展无极限最大的已知Spark集群是8000个节点，随着大数据增多，预计集群规模也会随之变大
8）Hadoop vs Spark安全性
Hadoop支持Kerberos身份验证，Spark的安全性弱一点，目前只支持通过共享密钥(密码验证)的身份验证，能够充分利用活动目录Kerberos和LDAP用于身份验证。在HDFS上运行Spark，它可以使用HDFS ACL和文件级权限。Hadoop分布式文件系统支持访问控制列表(ACL)和传统的文件权限模式，确保用户拥有正确的权限Spark可以在YARN上运行，因而能够使用Kerberos身份验证。
9）Spark解决的Hadoop的问题
①抽象层次低，需要手工编写代码来完成，使用上难以上手。
=>基于RDD的抽象，实数据处理逻辑的代码非常简短。。
②只提供两个操作，Map和Reduce，表达力欠缺。
=>提供很多转换和动作，很多基本操作如Join，GroupBy已经在RDD转换和动作中实现。
③一个Job只有Map和Reduce两个阶段，复杂的计算需要大量的Job完成，Job之间依赖关系由开发者自己管理。
=>一个Job可以包含RDD的多个转换操作，在调度时可以生成多个阶段，而且如果多个map操作的RDD分区不变，是可以放在同一个Task中进行
④处理逻辑隐藏在代码细节中，没有整体逻辑。
=>在Scala中，通过匿名函数和高阶函数，RDD的转换支持流式API，可以提供处理逻辑的整体视图。代码不包含具体操作的实
现细节，逻辑更清晰。
⑤中间结果也放在HDFS文件系统中。
=>中间结果放在内存中，内存放不下了会写入本地磁盘，而不是HDFS。
⑥ReduceTask需要等待所有MapTask都完成后才可以开始。
=>分区相同的转换构成流水线放在一个Task中运行，分区不同的转换需要Shuffle，被划分到不同的Stage中，需要等待前面的
Stage完成后才可以开始。
⑦时延高，只适用Batch数据处理，对于交互式数据处理，实时数据处理的支持不够。
=>通过将流拆成小的batch提供Discretized Stream处理流数据。
⑧对于迭代式数据处理性能比较差。
=>通过在内存中缓存数据，提高迭代式计算的性能。
hadoop、spark和storm简单的融合
备注：shark是sparkSQL前身，可以考虑把shark换成sparkSQL
a.蓝色部分，是Hadoop生态系统组件，黄色部分是Spark生态组件，虽然他们是两种不同的大数据处理框架，但它们不是互斥的，Spark与hadoop 中的MapReduce是一种相互共生的关系。Hadoop提供了Spark许多没有的功能，比如分布式文件系统，而Spark提供了实时内存计算，速度非常快。有一点大家要注意，Spark并不是一定要依附于Hadoop才能生存，除了Hadoop的HDFS，还可以基于其他的云平台，当然啦，大家一致认为Spark与Hadoop配合默契最好摆了。
b.技术趋势：Spark在崛起，hadoop和Storm中的一些组件在消退。大家在学习使用相关技术的时候，记得与时俱进掌握好新的趋势、新的替代技术，以保持自己的职业竞争力。HSQL未来可能会被Spark SQL替代，现在很多企业都是HIVE SQL和Spark SQL两种工具共存，当Spark SQL逐步成熟的时候，就有可能替换HSQL；MapReduce也有可能被Spark 替换，趋势是这样，但目前Spark还不够成熟稳定，还有比较长的路要走；Hadoop中的算法库Mahout正被Spark中的算法库MLib所替代，为了不落后，大家注意去学习Mlib算法库；Storm虽然不是hadoop生态中的一员，但我仍然想把它放在一起做过比较。由于Spark和hadoop天衣无缝的结合，Spark在逐步的走向成熟和稳定，其生态组件也在逐步的完善，是冉冉升起的新星，相信Storm会逐步被挤压而走向衰退。
低成本、高可靠、高扩展、高有效、高容错等特性让Hadoop成为最流行的大数据分析系统，然而其赖以生存的HDFS和MapReduce组件却让其一度陷入困境——批处理的工作方式让其只适用于离线数据处理，在要求实时性的场景下毫无用武之地。因此，各种基于Hadoop的工具应运而生。为了减少管理成本，提升资源的利用率，有当下众多的资源统一管理调度系统，例如Twitter 的Apache Mesos、Apache 的YARN、le 的Borg、腾讯搜搜的Torca、Facebook Corona(开源)等。Apache Mesos是Apache孵化器中的一个开源项目，使用ZooKeeper实现容错复制，使用Linux Containers 来隔离任务，支持多种资源计划分配(内存和CPU)。提供高效、跨分布式应用程序和框架的资源隔离和共享，支持Hadoop、MPI、Hypertable、Spark 等。YARN 又被称为MapReduce 2.0，借鉴Mesos，YARN 提出了资源隔离解决方案Container，提供Java 虚拟机内存的隔离。对比MapReduce 1.0，开发人员使用ResourceManager、ApplicationMaster与NodeManager代替了原框架中核心的JobTracker 和TaskTracker。在YARN平台上可以运行多个计算框架，如MR、Tez、Storm、Spark等。
hadoop、spark和storm的相同或不同
1.Storm用于处理高速、大型数据流的分布式实时计算系统。
Storm是Twitter主推的分布式计算系统，它由BackType团队开发，是Apache基金会的孵化项目。它在Hadoop的基础上提供了实时运算的特性，可以实时的处理大数据流。不同于Hadoop和Spark，Storm不进行数据的收集和存储工作，它直接通过网络实时的接受数据并且实时的处理数据，然后直接通过网络实时的传回结果。
storm特点：基于hadoop
①不收集不存储②实时接受③实时处理④实时传回
2.Spark采用了内存计算。从多迭代批处理出发，允许将数据载入内存作反复查询，此外还融合数据仓库，流处理和图形计算等多种计算范式。Spark构建在HDFS上，能与Hadoop很好的结合。它的RDD是一个很大的特点。它在Hadoop的基础上进行了一些架构上的改良。Spark与Hadoop最大的不同点在于，Hadoop使用硬盘来存储数据，而Spark使用内存来存储数据，因此Spark可以提供超过Hadoop100倍的运算速度。但是，由于内存断电后会丢失数据，Spark不能用于处理需要长期保存的数据。
MapReduce和spark都是计算引擎，二者比较，在处理速度上面，Spark有天然的优势，Spark每次将处理过程加载到内存之中，然后该操作作为缓存一直保持在内存中直到下一步操作。但是当涉及单次读取、类似ETL操作的任务，比如数据转化、数据整合等时，MapReduce 是更优的选择。
spark特点：基于hadoop
①运算速度是hadoop的100倍②基于内存计算，不能提供持久化
③估计100～1000 rmb可以应对大多数100tb到1pb的运算巨大的低成本优势 几乎是个人都可以分析大数据了
3.Hadoop当前大数据管理标准之一，运用在当前很多商业应用系统。可以轻松地集成结构化、半结构化甚至非结构化数据集。
结构化数据：数字、符号等数据。非结构化数据：文本、图像、声音、视频等
Hadoop是一个生态圈，spark、storm、Flink等都是hadoop生态圈的一部分。Hadoop 2.x支持Spark作为一个组件！！！！随着Spark在崛起，hadoop和Storm中的一些组件在消退。
hadoop、spark、storm、Flink和Samza的比较
大数据系统可使用多种处理技术。对于仅需要批处理的工作负载，如果对时间不敏感，比其他解决方案实现成本更低的Hadoop将会是一个好选择。对于仅需要流处理的工作负载，Storm可支持更广泛的语言并实现极低延迟的处理，但默认配置可能产生重复结果并且无法保证顺序。Samza与YARN和Kafka紧密集成可提供更大灵活性，更易用的多团队使用，以及更简单的复制和状态管理。对于混合型工作负载，Spark可提供高速批处理和微批处理模式的流处理。该技术的支持更完善，具备各种集成库和工具，可实现灵活的集成。Flink提供了真正的流处理并具备批处理能力，通过深度优化可运行针对其他平台编写的任务，提供低延迟的处理，但实际应用方面还为时过早。最适合的解决方案主要取决于待处理数据的状态，对处理所需时间的需求，以及希望得到的结果。具体是使用全功能解决方案或主要侧重于某种项目的解决方案，这个问题需要慎重权衡。随着逐渐成熟并被广泛接受，在评估任何新出现的创新型解决方案时都需要考虑类似的问题。
