高可用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的优化主要体现在:
- 去除了连续两个任务之间的写屏障
- 去除了每个工作流中多余的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处理流数据。
- 对于迭代式数据处理性能比较差。
- =>通过在内存中缓存数据,提高迭代式计算的性能。
这篇文章就分享到这里,若在研究的过程中有什么疑问,可以加群讨论或发送邮件给我,我会尽我所能为您解答,与君共勉!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Hive基本操作
1.概述 上一章《那些年使用Hive踩过的坑》介绍了Hive的基本架构及原理,加下来介绍Hive的基本操作和一些注意事项。 2.基本操作 2.1Create Table 2.1.1介绍 CREATE TABLE 创建一个指定名字的表。如果相同名字的表已经存在,则抛出异常;用户可以用 IF NOT EXIST 选项来忽略这个异常。 EXTERNAL 关键字可以让用户创建一个外部表,在建表的同时指定一个指向实际数据的路径(LOCATION),Hive 创建内部表时,会将数据移动到数据仓库指向的路径;若创建外部表,仅记录数据所在的路径,不对数据的位置做任何改变。在删除表的时候,内部表的元数据和数据会被一起删除,而外部表只删除元数据,不删除数据。 LIKE 允许用户复制现有的表结构,但是不复制数据。 用户在建表的时候可以自定义 SerDe 或者使用自带的 SerDe。如果没有指定 ROW FORMAT 或者 ROW FORMAT DELIMITED,将会使用自带的 SerDe。在建表的时候,用户还需要为表指定列,用户在指定表的列的同时也会指定自定义的 SerDe,Hive 通过...
- 下一篇
解读Secondary NameNode的功能
1.概述 最近有朋友问我Secondary NameNode的作用,是不是NameNode的备份?是不是为了防止NameNode的单点问题?确实,刚接触Hadoop,从字面上看,很容易会把Secondary NameNode当作备份节点;其实,这是一个误区,我们不能从字面来理解,阅读官方文档,我们可以知道,其实并不是这么回事,下面就来赘述下Secondary NameNode的作用。 2.Secondary NameNode? 在Hadoop中,有一些命名模块不那么尽人意,Secondary NameNode就是一个典型的例子之一。从它的名字上看,它给人的感觉就像是NameNode的备份节点,但实际上却不是。很多Hadoop的入门者都很疑惑,Secondary NameNode究竟在其中起什么作用,它在HDFS中所扮演的角色是什么。下面,我就来解释下: 从名字来看,它确实与NameNode有点关系;因此,在深入了解Secondary NameNode之前,我们先来看看NameNode是做什么的。 2.1NameNode NameNode主要是用来保存HDFS的元数据信息,比如命名空间信...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS7设置SWAP分区,小内存服务器的救世主
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS关闭SELinux安全模块