高可用Hadoop平台－探索

1.概述

　　上篇《高可用Hadoop平台－启航》博客已经让咱们初步了解了Hadoop平台；接下来，咱们对Hadoop作进一步的探索，一步一步的揭开Hadoop的神秘面纱。下面，咱们开始赘述今天的探索之路。

2.探索

　　在探索以前，咱们来看一下Hadoop解决了什么问题，Hadoop就是解决了大数据（大到单台服务器没法进行存储，单台服务器没法在限定的时间内进行处理）的可靠存储和处理。

• HDFS：在由普通或廉价的服务器（或PC）组成的集群上提供高可用的文件存储，经过将块保存多个副本的办法解决服务器或硬盘坏掉的问题。
• MapReduce：经过简单的Mapper和Reducer的抽象提供一个编程模型，能够在一个由几十台或上百台的服务器组成的集群上进行并发，分布式的处理大量的数据集；而并发，分布式（如：机器间通讯）和故障恢复等计算细节隐藏起来。而Mapper和Reducer的抽象，又是各类各样的复杂数据处理均可以分解为基本元素。这样，复杂的数据处理能够分解为由多个Job（包含一个Mapper和一个Reducer）组成的有向无环图（DAG），而后每一个Mapper和Reducer放到Hadoop集群上执行，就能够得出以下图所示的结果：

　　在Hadoop的源码中，提供了一个很经典的例子：WordCount，具体源码能够参见上篇文章，若是对MapReduce不熟悉，经过该示例对MapReduce进行一些了解对理解下文会由帮助。在MapReduce中，Shuffle是一个很是重要的过程，正是有了看不见的Shuffle过程，才可使在MapReduce之上写数据处理的开发者彻底感受不到分布式和并发的存在。

　　注：广义的Shuffle是指图中在Map和Reduce之间的一系列过程。

2.1Hadoop的局限和不足

　　MapReduce存在如下局限，使用起来比较困难。

• 抽象层次低，须要手工编写代码来完成，使用上难以上手，入门门槛较高。
• 只提供两个操做，Map和Reduce，表达的力度不够。
• 一个Job只有Map和Reduce两个阶段，复杂的计算须要大量的Job来完成。Job之间的依赖关系是由开发者本身来管理的。
• 　　处理逻辑隐藏在代码细节中，没有总体逻辑。
• 中间结果也放在HDFS文件系统中。
• ReduceTask须要等待全部的MapTask都完成后才能够开始。
• 时延高，只适用Batch数据处理，对于交互式数据处理，实时数据处理的支持不够。
• 对于迭代式数据处理性能比较差。

　　举个例子，用MapReduce实现表与表之间的join，都是一个很须要技巧来处理的过程，以下图：

　　所以，在Hadoop以后，出现来不少相关技术对其中的局限进行改进，如：Hive，Oozie，Tez，Spark，Storm等等。

3.Hive

　　Hive是Facebook的产品，目前已托管到Apache基金。关于Hive的安装搭建和使用请参考《那些年使用Hive踩过的坑》和《Hive的安装部署》，这里就很少赘述了。Hive是一种底层封装了Hadoop的数据仓库处理工具，使用类SQL的HiveSQL语言实现数据查询，全部Hive的数据都存储在HDFS中。Hive在加载数据过程当中不会对数据进行任何的修改，只是将数据移动到HDFS中Hive的指定目录下，所以，Hive不支持对数据的改写和添加，全部的数据都是在加载的时候肯定的。

　　Hive解决类MapReduce存在的大量手写代码，语义隐藏，提供操做种类少的问题。相似的项目还有Pig，JAQL等。

4.Tez

　　Tez是HortonWorks的Stinger Initiative的的一部分。做为执行引擎，Tez也提供了有向无环图（DAG），DAG由顶点（Vertex）和边（Edge）组成，Edge是对数据的移动的抽象，提供了One-To-One，BroadCast，和Scatter-Gather三种类型，只有Scatter-Gather才须要进行Shuffle。

　　示例：

SELECT a.state, COUNT(*), AVERAGE(c.price) FROM a JOIN b ON (a.id = b.id) JOIN c ON (a.itemId = c.itemId) GROUP BY a.state

　　Tez的优化主要体如今：

1. 去除了连续两个任务之间的写屏障
2. 去除了每一个工做流中多余的Map阶段

　　经过提供DAG语义和操做，提供了总体的逻辑，经过减小没必要要的操做，Tez提高了数据处理的执行性能。

5.Spark

 

　　Spark也是一个大数据处理的引擎，主要特色是提供了一个集群的分布式内存抽象，以支持须要工做集的应用。

 

　　这个抽象就是RDD（Resilient Distributed Dataset），RDD就是一个不可变的带分区的记录集合，RDD也是Spark中的编程模型。Spark提供了RDD上的两类操做，转换和动做。转换是用来定义一个新的RDD，包括map, flatMap, filter, union, sample, join, groupByKey, cogroup, ReduceByKey, cros, sortByKey, mapValues等，动做是返回一个结果，包括collect, reduce, count, save, lookupKey。

 

　　Spark支持故障恢复的方式也不一样，提供两种方式，Linage，经过数据的血缘关系，再执行一遍前面的处理，Checkpoint，将数据集存储到持久存储中。

 

　　Spark的API很是简单易用，使用Spark，WordCount的示例以下所示：

val spark = new SparkContext(master, appName, [sparkHome], [jars])
val file = spark.textFile("hdfs://nna:9000/hdfs/in/a.txt")
val counts = file.flatMap(line => line.split(" "))
                 .map(word => (word, 1))
                 .reduceByKey(_ + _)
counts.saveAsTextFile("hdfs://nna:9000/hdfs/out")

　　其中的file是根据HDFS上的文件建立的RDD，后面的flatMap，map，reduceByKe都建立出一个新的RDD，一个简短的程序就可以执行不少个转换和动做。在Spark中，全部RDD的转换都是是惰性求值的。Spark的任务是由相互依赖的多个RDD组成的有向无环图（DAG），每一个RDD又包含多个分区，当在RDD上执行动做时，Spark才对任务进行调度。

　　Spark对于有向无环图对任务进行调度，肯定阶段，分区，流水线，任务和缓存，进行优化，并在Spark集群上运行任务。RDD之间的依赖分为宽依赖（依赖多个分区）和窄依赖（只依赖一个分区），在肯定阶段时，须要根据宽依赖划分阶段。根据分区划分任务。

　　Spark为迭代式数据处理提供更好的支持。每次迭代的数据能够保存在内存中，而不是写入文件。

　　Spark的性能相比Hadoop有很大提高，2014年10月，Spark完成了一个Daytona Gray类别的Sort Benchmark测试，排序彻底是在磁盘上进行的，与Hadoop以前的测试的对比结果如表格所示：

　　原图连接地址：http://databricks.com/blog/2014/11/05/spark-officially-sets-a-new-record-in-large-scale-sorting.html

　　从表格中能够看出排序100TB的数据（1万亿条数据），Spark只用了Hadoop所用1/10的计算资源，耗时只有Hadoop的1/3。

　　Spark的优点不只体如今性能提高上的，Spark框架为批处理（Spark Core），交互式（Spark SQL），流式（Spark Streaming），机器学习（MLlib），图计算（GraphX）提供一个统一的平台，这相对于使用Hadoop有很大优点。

6.总结

　　那么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都完成后才能够开始
  • =>它容许用户单独为Map Task和Reduce Task设置不一样的资源，进而细粒度控制任务占用资源量，有利于大做业的正常平稳运行。
• 时延高，只适用Batch数据处理，对于交互式数据处理，实时数据处理的支持不够。
  • =>经过将流拆成小的batch提供Discretized Stream处理流数据。
• 对于迭代式数据处理性能比较差。
  • =>经过在内存中缓存数据，提升迭代式计算的性能。

　　这篇文章就分享到这里，若在研究的过程当中有什么疑问，能够加群讨论或发送邮件给我，我会尽我所能为您解答，与君共勉！