高可用Hadoop平台-探索

简介:

1.概述

  接下来,我们对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处理流数据。
  • 对于迭代式数据处理性能比较差。
    • =>通过在内存中缓存数据,提高迭代式计算的性能。

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


目录
相关文章
|
存储 机器学习/深度学习 SQL
图解大数据 | 分布式平台Hadoop与Map-Reduce详解
Hadoop是最基础和场景的开源分布式计算平台,ShowMeAI在本节内容中给大家讲解Hadoop相关知识。
334 0
图解大数据 | 分布式平台Hadoop与Map-Reduce详解
|
8月前
|
机器学习/深度学习 存储 分布式计算
Hadoop学习---11、HA高可用
Hadoop学习---11、HA高可用
|
10月前
|
分布式计算 Hadoop 大数据
大数据 | Hadoop HA高可用搭建保姆级教程(大二学长的万字笔记)(下)
大数据 | Hadoop HA高可用搭建保姆级教程(大二学长的万字笔记)(下)
124 0
|
10月前
|
分布式计算 运维 Hadoop
大数据 | Hadoop HA高可用搭建保姆级教程(大二学长的万字笔记)(上)
大数据 | Hadoop HA高可用搭建保姆级教程(大二学长的万字笔记)(上)
272 0
|
10月前
|
分布式计算 资源调度 Hadoop
【大数据】Hadoop高可用集群搭建
【大数据】Hadoop高可用集群搭建
134 0
|
11月前
|
机器学习/深度学习 分布式计算 Hadoop
搭建高可用Hadoop集群
搭建高可用Hadoop集群
|
存储 分布式计算 资源调度
平台服务 开源 Hadoop|学习笔记
快速学习平台服务 开源 Hadoop
137 0
平台服务 开源 Hadoop|学习笔记
uiu
|
存储 分布式计算 安全
【亲测】Hadoop 高可用集群搭建 与 开发环境部署(二)
【亲测】Hadoop 高可用集群搭建 与 开发环境部署(二)
uiu
110 0
【亲测】Hadoop 高可用集群搭建 与 开发环境部署(二)
uiu
|
分布式计算 Oracle 关系型数据库
【亲测】Hadoop 高可用集群搭建 与 开发环境部署
【亲测】Hadoop 高可用集群搭建 与 开发环境部署
uiu
315 0
【亲测】Hadoop 高可用集群搭建 与 开发环境部署
|
存储 分布式计算 运维
hadoop HA高可用集群实战
大数据实战:hadoop HA高可用集群
hadoop HA高可用集群实战

相关实验场景

更多