想学习大数据框架，听说过spark，hadoop，storm但我不知道从哪里开始，所以我在网上找到了一些文章。以下是对大数据框架的整体认知。
前言
说到大数据处理，一切都起源于Google公司的经典论文：《MapReduce:Simplied Data Processing on Large Clusters》。当时(2000年左右)，由于网页数量急剧增加，Google公司通常编写大量的程序来处理大量的原始数据：爬虫爬网页、网页请求日志；计算各种类型的衍生数据：倒置索引、网页的各种图形结构等。这些计算在概念上很容易理解，但由于输入数据量大，单机难以处理。因此，需要分布式计算，并考虑如何并行计算、分配数据和处理失败。
针对这些复杂的问题，Google决定设计一套抽象模型来实施这些简单的计算，并隐藏并发、容错、数据分布和平衡负载的细节。受到Lisp以及其他函数编程语言map、reduce论文的作者意识到，许多计算都涉及到每个数据的执行map操作，获得一批中间key/value是的，然后使用reduce合并这些操作key值相同的k-v对。该模型可以轻松实现大规模并行计算。
事实上，与许多人不同的是，MapReduce对大数据计算的最大贡献不是它的名字直观地显示出来的Map和Reduce思想(正如上面提到的，Map和Reduce思想在Lisp等函数编程语言已经存在很久了)，但这个计算框架可以在一群便宜的人中运行PC机上。MapReduce其伟大之处在于普及了工业界对大数据计算的理解：它提供了良好的横向扩展和容错处理机制，从集中到分布式。过去，如果你想计算更多的数据，你必须创建更快的计算机，但现在你只需要添加计算节点。
话说当年的Google有三宝：MapReduce、GFS和BigTable。但Google三宝虽好，但普通人想用却不能用。原因很简单:他们不开源。于是Hadoop应运而生，初代Hadoop的MapReduce和HDFS即为Google的MapReduce和GFS开源实现(另一宝BigTable开源实现也很有名HBase）。此后，大数据处理框架的历史帷幕正式缓慢拉开。
一、基础
1.定义大数据 大数据一词的确切定义实际上很难给出，因为不同的人（供应商、从业者、商业公司等）对它的理解并不完全一致。一般来说，大数据是： 大数据集 用于处理大数据集的某种技术 这里的大数据集是指数据集数据量过大，无法使用传统工具或单机处理和存储，处理技术包括数据访问、数据持久存储、数据计算和分析、数据显示（可视化）等。 2.大数据的特征 大数据系统的基本需求与传统系统没有本质区别。然而，虽然大数据系统有大量的数据规模，但它对数据的访问和处理速度也有很高的要求，数据应该在每个阶段进行处理。这些功能仍然为设计解决方案提供了新的挑战。 在2001年，美国Gartner公司的Doug Laney首先提出了3V模型描述了大数据处理系统与传统数据处理系统的区别： Volume 待处理数据的规模在很大程度上决定了系统是否为大数据系统。大数据系统中的数据规模可能比传统处理系统中的数据集大几个数量级，这也为数据处理和存储带来了更多的挑战。由于数据处理和存储超过了单台计算机所能达到的性能极限，大数据系统通常采用集群模式。集群管理和任务分配算法对资源的分配和协调越来越重要。 Velocity 大数据与其他数据系统的另一个显著区别体现在数据的流动速度上。在大数据系统中，数据经常从多个数据源流入系统，并以近实时的方式处理。为了跟上新数据的处理和分析数据，以跟上新数据的接入速度。由于近实时处理可以尽快提供有价值的信息，许多商业公司更喜欢实时处理系统而不是传统的批处理系统。 Variety 大数据系统的问题通常是其他系统所没有的，因为它处理了广泛的数据源。数据源可以是应用程序的日志信息、社交媒体的用户信息，甚至是物理设备传感器的收集数据。大数据系统的目标是在大量数据中找到有用的数据。 3.大数据处理流程 那么，大数据系统实际上是如何处理数据的呢？虽然不同公司的结构设计不同，但我们可以总结一个基本的过程。虽然下面介绍的过程并不适用于所有情况，但它们确实被广泛使用。大数据处理的基本过程是： 访问系统中的数据 将数据持久化为存储系统 计算和分析数据 展示结果(可视化) 4.定义大数据处理框架 说完大数据，我们来谈谈本文的重点——大数据处理框架。大数据处理框架负责计算大数据系统中的数据。数据包括从持久存储中读取的数据或通过消息队列访问系统中的数据，而计算是从数据中提取信息的过程。除了大数据处理框架外，一些学生还可能听说过大数据计算框架和大数据框架。这些术语没有严格区分，但基本上可以理解为一件事，只是big data processing framework不同的翻译(大数据框架是big data framework翻译)。 另一个术语是大数据处理引擎，那么这个引擎和我们所说的框架有什么关系呢？事实上，它们的权威定义并没有区分，但一般来说，前者是实际负责处理操作的组件，后者可以理解为一系列用于完成相同工作的组件。Apache Hadoop可视为是的MapReduce默认处理引擎的处理框架。
二、数据处理框架分类
无论是系统中的历史数据，还是连续访问系统中的实时数据，只要数据可访问，我们都可以处理数据。数据处理框架可分为两类： 批处理系统 流处理系统 批处理是计算大规模数据集的一种方法。批处理过程包括将任务分解为较小的任务，在集群中的每台计算机上计算，根据中间结果重新组合数据，然后计算和组合最终结果。批处理系统是处理大量数据集时最有效的。 典型的批处理系统是Apache Hadoop。流处理操作由连续单个数据项组成的数据流，注意数据处理结果的及时性。有典型的流处理系统Apache Storm，Apache Samza。还有一种系统，具有批处理和流处理的能力，称为混合处理系统，如Apache Spark，Apache Flink。接下来，我们将详细介绍这三种处理系统。
三、批处理系统
批处理系统在大数据世界有着悠久的历史。批处理系统主要操作大量静态数据，只有在所有处理完成后才能返回。批处理系统中的数据集一般符合以下特点： 有限：数据集中的数据必须有限（无限数据不能在一批中完成。流处理系统通常用于处理连续数据，我们稍后将讨论） 持久性：批处理系统处理的数据通常存储在持久存储系统上（如硬盘和数据库） 大量数据：大量数据通常只能由批处理系统处理。批处理系统在设计之初就充分考虑了数据量巨大的问题。事实上，批处理系统为此诞生的。 由于批处理系统在处理大量持久数据方面表现出色，因此通常用于处理历史数据OLAP（在线分析处理）系统的底层计算框架是使用的批处理系统。然而，由于大量数据的处理需要大量的时间，批处理系统通常不适用于延迟要求较高的场景。 Apache Hadoop 说到大数据处理框架，我们永远无法回避Hadoop。Hadoop它是开源社区第一个大数据处理框架，长期以来几乎可以作为大数据技术的代名词。.0版本以后，Hadoop由以下组件组成： Hadoop分布式文件系统HDFS：HDFS它是一种容错性高的分布式文件系统，适用于廉价机器集群的部署。HDFS它可以提供高吞吐量的数据访问，非常适合大规模数据集。它可以用来存储数据源或最终结果。 资源管理器YARN：YARN它可以为上层应用程序提供统一的资源管理和调度，可以管理服务器资源(主要是CPU并负责调度操作。Hadoop它被设计用于管理MapReduce计算服务。但现在许多其他大数据处理框架也可以YARN作为资源管理器，比如Spark。 MapReduce：即为Hadoop默认数据处理引擎也是Google的MapReduce实现论文思想的开源。HDFS用作数据源YARN资源管理。 从今天的角度来看，MapReduce作为Hadoop默认数据处理引擎存在许多不足。例如，编程模型抽象低，只支持Map和Reduce两种操作，需要手工编写大量的代码；Map中间结果需要写入磁盘，多个MR需要在两者之间使用HDFS数据交换不适合迭代计算（机器学习、图形计算）；任务启动和调度费用较大。随着高性能处理引擎的发展，目前在企业中使用MapReduce计算应用程序呈下降趋势（HDFS及YARN尽管如此，它仍然被广泛使用)，MapReduce作为最早的大数据处理引擎，它仍然值得记住。
四、流处理系统
批处理系统很容易理解，那么什么是流处理系统呢？在小学，我们都做过这样一个数学问题：一个池有一个进水管和一个出水管，只打开8小时的进水管充满水，只打开6小时的流水管，所以同时打开进水管和出水管，池充满水多久？ 嗯，这个问题的答案总是充满不满……因为出水管出水比较快。流处理系统相当于这个水池，加工流入的水(数据)，比如加盐，让它变成盐水，然后把加工过的水(数据)从出水管排出。这样，数据就永远不会像水流一样停止，并且已经在水池中处理过了。因此，这种处理永不停止接入数据的系统称为流处理系统。 流处理系统与批处理系统处理的数据的区别在于，流处理系统不操作现有的数据集，而是处理从外部系统访问的数据。流处理系统可分为两种类型： 逐项处理：每次处理一个数据，都是真正意义上的流处理。 微批处理：这种处理方法将短时间内的数据作为微批处理。 事实上，无论采用何种处理方法，时性都远好于批处理系统。因此，流处理系统不是适合应用于对实时性要求较高的场景，比如日志分析，设备监控、网站实时流量变化等等。由于很多情况下，我们想要尽快看到计算结果，所以近些年流处理系统的应用越来越广泛。下面我们来了解两种流处理系统。 Apache Storm Apache Storm是一种侧重于低延迟的流处理框架，它可以处理海量的接入数据，以近实时方式处理数据。Storm延时可以达到亚秒级。Storm含有如下关键概念： Topology：Storm topology中封装了实时应用程序的逻辑。Storm topology类似于MapReduce作业，但区别是MapReduce最终会完成，而topology则会一直运行（除非被强制停止）。Topology是由spouts和bolts组成的DAG（有向无环图）。 Stream：Stream是一种不断被接入Storm中的无界的数据序列。 Spout：Spout是topology中Stream的源。Spout从外部数据源读取数据并接入到Strom系统中 Bolt：Bolt用于Storm中的数据处理，它可以进行过滤、聚合、连接等操作。将不同的bolt连接组成完整的数据处理链条，最后一个bolt用来输出（到文件系统或数据库等）。 Storm的基本思想是使用spout拉取stream（数据），并使用bolt进行处理和输出。默认情况下Storm提供了“at least once”的保证，即每条数据被至少消费一次。当一些特殊情况（比如服务器故障等）发生时，可能会导致重复消费。为了实现“exactly once”（即有且仅有一次消费），Storm引入了Trident。Trident可以将Storm的单条处理方式改变为微批处理方式，但同时也会对Storm的处理能力产生一定的影响。 值得一提的是，一些国内的公司在Storm的基础上进行了改进，为推动流处理系统的发展做出了很大贡献。阿里巴巴的JStorm参考了Storm，并在网络IO、线程模型、资源调度及稳定性上做了改进。而华为的StreamCQL则为Storm提供了SQL查询语义。 Apache Samza 提到Apache Samza，就不得不提到当前最流行的大数据消息中间件：Apache Kafka。Apache Kafka是一个分布式的消息中间件系统，具有高吞吐、低延时等特点，并且自带了容错机制。以下是Kafka的关键概念： Broker：由于Kafka是分布式消息中间件，所以需要多个节点来存储数据。Broker即为Kafka集群中的单个节点。 Topic：用于存储写入Kafka的数据流。如同它的字面含义——主题，不同主题的数据流最好写入不同的topic，方便后续的处理。 Partition：每个topic都有1到多个partition，便于分散到不同的borker中。多个partition的数据合并在一起组成了topic完整的数据。 Producer：消息的生产者，用来将消息写入到Kafka集群。 Consumer：消息的消费者，用来读取Kafka中的消息并进行处理。 虽然Kafka被广泛应用于各种流处理系统做数据源，但Samza可以更好的发挥Kafka架构的优势。根据官网的解释，Samza由三个层次组成： 数据流层 执行层 处理层 支持三个层次的组件分别为： Kafka YARN Samza API 也就是说，Samza使用Kafka提供了数据流，使用YARN进行资源管理，自身仅提供了操作数据流的API。Samza对Kafka和YARN的依赖在很多方面上与MapReduce对HDFS和YARN的依赖相似。 如果已经拥有Hadoop集群和Kafka集群环境，那么使用Samza作为流处理系统无疑是一个非常好的选择。由于可以很方便的将处理过的数据再次写入Kafka，Samza尤其适合不同团队之间合作开发，处理不同阶段的多个数据流。
五、混合处理系统：批处理和流处理
一些处理框架既可以进行批处理，也可以进行流处理。这些框架可以使用相同或相关的API处理历史和实时数据。当前主流的混合处理框架主要为Spark和Flink。 虽然专注于一种处理方式可能非常适合特定场景，但是混合框架为数据处理提供了通用的解决方案。 Apache Spark 如果说如今大数据处理框架处于一个群星闪耀的年代，那Spark无疑就是所有星星中最闪亮的那一颗。Spark由加州大学伯克利分校AMP实验室开发，最初的设计受到了MapReduce思想的启发，但不同于MapReduce的是，Spark通过内存计算模型和执行优化大幅提高了对数据的处理能力（在不同情况下，速度可以达到MR的10-100倍，甚至更高）。相比于MapReduce，Spark具有如下优点： 提供了内存计算模型RDD（Resilient Distributed Dataset，弹性分布式数据集），将数据读入内存中生成一个RDD，再对RDD进行计算。并且每次计算结果可以缓存在内存中，减少了磁盘IO。因此很适用于迭代计算。 不同于MapReduce的MR模型，Spark采用了DAG编程模型，将不同步骤的操作串联成一个有向无环图，可以有效减少任务间的数据传递，提高了性能。 提供了丰富的编程模型，可以轻松实现过滤、连接、聚合等操作，代码量相比MapReduce少到令人发指，因此可以提高开发人员的生产力。 支持Java、Scala、Python和R四种编程语言，为不同语言的使用者降低了学习成本。 而Spark的流处理能力，则是由Spark Streaming模块提供的。Spark在设计之初与MapReduce一样是用于批处理系统，为了适应于流处理模式，Spark提出了微批次（Micro-Batch）的概念，即把一小段时间内的接入数据作为一个微批次来处理。这样做的优点是在设计Spark Streaming时可以很大程度上重用批处理模块（Spark Core）的代码，开发人员也不必学习两套编程模型。但缺点就是，与Storm等原生的流处理系统相比，Spark Streaming的延时会相对高一些。 除了最初开发用于批处理的Spark Core和用于流处理的Spark Streaming，Spark还提供了其他编程模型用于支持图计算（GraphX）、交互式查询（Spark SQL）和机器学习（MLlib）。 但Spark也不是没有缺点。在批处理领域，由于内存是比硬盘更昂贵的资源，所以Spark集群的成本比MapReduce集群更高。而在流处理领域，微批次的架构使得它的延时要比Storm等流处理系统略高。不过瑕不掩瑜，Spark依然是如今最炙手可热的数据处理框架。 Apache Flink 有趣的是，同样作为混合处理框架，Flink的思想与Spark是完全相反的：Spark把流拆分成若干个小批次来处理，而Flink把批处理任务当作有界的流来处理。其本质原因是，Spark最初是被设计用来进行批处理的，而Flink最初是被设计用来进行流处理的。这种流处理优先的方式叫做Kappa架构，与之相对的使用批处理优先的架构叫做Lambda架构。Kappa架构会使用处理流的方式处理一切，以此来简化编程模型。这一切是在最近流处理引擎逐渐成熟起来才有可能实现的。 Flink的流处理模型将逐项输入的数据作为真实的流处理。Flink提供了DataStream API用于处理无尽的数据流。Flink的基本组件包括： Stream：Stream是流过系统的不可变的、无界的数据集 Operator：Operator用来操作数据流以产生新的数据流（stream） Source：Source是数据流（stream）进入系统的入口 Sink：Sink是数据流（stream）流出Flink系统后的位置。它可能是数据库或到其他系统的连接器 Flink的流处理思想与Storm类似，以source接入数据，通过不同的operator进行transformation，最后输出到sink。 Flink的提供了DataSet API用于批处理。Flink的批处理在很大程度上可以看作是流处理的一种扩展，它读取在持久存储系统上的数据，并把去除的数据集当成一个有边界的流来处理。 与Spark相同，Flink也提供了较为完整的数据处理方式。除了上面介绍的流处理（DataStream API）和批处理（DataSet API）之外，Flink还提供了类SQL查询（Table API）、图计算（Gelly）和机器学习库（Flink ML）。而令人惊讶的是，在很多性能测试中，Flink甚至略优于Spark。 在目前的数据处理框架领域，Flink可谓独树一帜。虽然Spark同样也提供了批处理和流处理的能力，但Spark流处理的微批次架构使其响应时间略长。Flink流处理优先的方式实现了低延迟、高吞吐和真正逐条处理。 同样，Flink也并不是完美的。Flink目前最大的缺点就是缺乏在大型公司实际生产项目中的成功应用案例。相对于Spark来讲，它还不够成熟，社区活跃度也没有Spark那么高。但假以时日，Flink必然会改变数据处理框架的格局。
六、大数据处理框架的选择
1.对于初学者 由于Apache Hadoop在大数据领域的广泛使用，因此仍推荐作为初学者学习数据处理框架的首选。虽然MapReduce因为性能原因以后的应用会越来越少，但是YARN和HDFS依然作为其他框架的基础组件被大量使用（比如HBase依赖于HDFS，YARN可以为Spark、Samza等框架提供资源管理）。学习Hadoop可以为以后的进阶打下基础。 Apache Spark在目前的企业应用中应该是当之无愧的王者。在批处理领域，虽然Spark与MapReduce的市场占有率不相上下，但Spark稳定上升，而MapReduce却稳定下降。而在流处理领域，Spark Streaming与另一大流处理系统Apache Storm共同占据了大部分市场（当然很多公司会使用内部研发的数据处理框架，但它们多数并不开源）。伯克利的正统出身、活跃的社区以及大量的商用案例都是Spark的优势。除了可用于批处理和流处理系统，Spark还支持交互式查询、图计算和机器学习。Spark在未来几年内仍然会是大数据处理的主流框架，推荐同学们认真学习。 另一个作为混合处理框架的Apache Flink则潜力无限，被称作“下一代数据处理框架”。虽然目前存在社区活跃度不够高、商用案例较少等情况，不过“是金子总会发光”，如果Flink能在商业应用上有突出表现，则可能挑战Spark的地位。 2.对于企业应用 如果企业中只需要批处理工作，并且对时间并不敏感，那么可以使用成本较其他解决方案更低的Hadoop集群。 如果企业仅进行流处理，并且对低延迟有着较高要求，Storm更加适合，如果对延迟不非常敏感，可以使用Spark Streaming。而如果企业内部已经存在Kafka和Hadoop集群，并且需要多团队合作开发（下游团队会使用上游团队处理过的数据作为数据源），那么Samza是一个很好的选择。 如果需要同时兼顾批处理与流处理任务，那么Spark是一个很好的选择。混合处理框架的另一个好处是，降低了开发人员的学习成本，从而为企业节约人力成本。Flink提供了真正的流处理能力并且同样具备批处理能力，但商用案例较少，对于初次尝试数据处理的企业来说，大规模使用Flink存在一定风险。
以上转自：https://mp.weixin.qq.com/s/Q-VT3RG7GfKex2Ylg8-Opw