这篇博客就和大家分享到这里,如果大家在研究学习的过程当中有什么问题,可以加群进行讨论或发送邮件给我,我会尽我所能为您解答,与君共勉!
Hadoop 3.x 新特性剖析系列2
1.概述
接着上一篇博客的内容,继续介绍Hadoop3的其他新特性。其内容包含:优化Hadoop Shell脚本、重构Hadoop Client Jar包、支持等待Container、MapReduce任务级别本地优化、支持多个NameNode、部分默认服务端口被改变、支持文件系统连接器、DataNode内部添加负载均衡、重构后台程序和任务堆管理。
2.内容
2.2.1 优化Hadoop Shell脚本
Hadoop Shell脚本已经被重写,用来修复已知的BUG,解决兼容性问题和一些现有安装的更改。它还包含了一些新的特性,内容如下所示:
- 所有Hadoop Shell脚本子系统现在都会执行hadoop-env.sh这个脚本,它允许所有环节变量位于一个位置;
- 守护进程已通过*-daemon.sh选项从*-daemon.sh移动到了bin命令中,在Hadoop3中,我们可以简单的使用守护进程来启动、停止对应的Hadoop系统进程;
- 触发SSH连接操作现在可以在安装时使用PDSH;
- ${HADOOP_CONF_DIR}现在可以任意配置到任何地方;
- 脚本现在测试并报告守护进程启动时日志和进程ID的各种状态;
2.2.2 重构Hadoop Client Jar包
Hadoop2 中可用的Hadoop客户端将Hadoop的传递依赖性拉到Hadoop应用程序的类路径上。如果这些传递依赖项的版本与应用程序使用的版本发送冲突,这可能会产生问题。
因此,在Hadoop3中有新的Hadoop客户端API和Hadoop客户端运行时工件,它们将Hadoop的依赖性遮蔽到单个JAR中,Hadoop客户端API是编译范围,Hadoop客户端运行时是运行时范围,它包含从Hadoop客户端重新定位的第三方依赖关系。因此,你可以将依赖项绑定到JAR中,并测试整个JAR以解决版本冲突。这样避免了将Hadoop的依赖性泄露到应用程序的类路径上。例如,HBase可以用来与Hadoop集群进行数据交互,而不需要看到任何实现依赖。
2.2.3 支持等待容器和分布式调度
在Hadoop3 中引入了一种新型执行类型,即等待容器,即使在调度时集群没有可用的资源,它也可以在NodeManager中被调度执行。在这种情况下,这些容器将在NM中排队等待资源启动,等待荣容器比默认容器优先级低,因此,如果需要,可以抢占默认容器的空间,这样可以提供机器的利用率。如下图所示:
默认容器对于现有的YARN容器,它们由容量调度分配,一旦被调度到节点,就保证有可用的资源使它们执行立即开始。此外,只要没有故障发生,这些容器就可以允许完毕。
等待容器默认由中心RM分配,但还增加了支持以允许等待容器被分布式调度,该调度群被实现于AM和RM协议的拦截器。
2.2.4 MapReduce任务级别本地化优化
在Hadoop3中,本地的Java实现已加入MapReduce地图输出器,对于Shuffle密集的作业,这样可以提高30%或者更高的性能。
它们添加了映射输出收集器的本机实现,让MapTask基于JNI来本机优化。基本思想是添加一个NativeMapOutputCollector收集器来处理映射器发出的键值对,因此Sort、Spill、文件序列化都可以在本机代码中完成。
2.2.5 支持多个NameNode节点
在Hadoop2中,HDFS NameNode高可用体系结构有一个Active和Standby NameNode,通过JournalNodes,该体系结构能够容忍任何一个NameNode失败。
然而,业务关键部署需要更高程度的容错性。因此,在Hadoop3中允许用户运行多个备用的NameNode。例如,通过配置三个NameNode(1个Active NameNode和2个Standby NameNode)和5个JournalNodes节点,集群可以容忍2个NameNode节点故障。如下图所示:
2.2.6 默认的服务端口被修改
早些时候,多个Hadoop服务的默认端口位于Linux端口范围以内。除非客户端程序明确的请求特定的端口号,否则使用的端口号是临时的,因此,在启动时,服务有时会因为与其他另一个应用程序冲突而无法绑定到端口。
因此,具有临时范围冲突端口已经被移除该范围,影响多个服务的端口号,即NameNode、Secondary NameNode、DataNode等如下所示:
Daemon | App | Hadoop2 Port | Hadoop3 Port |
NameNode Port | Hadoop HDFS NameNode | 8020 | 9820 |
Hadoop HDFS NameNode HTTP UI | 50070 | 9870 | |
Hadoop HDFS NameNode HTTPS UI | 50470 | 9871 | |
Secondary NameNode Port | Secondary NameNode HTTP | 50091 | 9869 |
Secondary NameNode HTTP UI | 50090 | 9868 | |
DataNode Port | Hadoop HDFS DataNode IPC | 50020 | 9867 |
Hadoop HDFS DataNode | 50010 | 9866 | |
Hadoop HDFS DataNode HTTP UI | 50075 | 9864 | |
Hadoop HDFS DataNode HTTPS UI | 50475 | 9865 |
2.2.6 支持文件系统连接器
Hadoop现在支持与微软 Azure数据和阿里云对象存储系统的集成。它可以作为一种替代Hadoop兼容的文件系统,首先添加微软Azure数据,然后添加阿里云对象存储系统。
2.2.7 DataNode内部负载均衡
单个数据节点配置多个数据磁盘,在正常写入操作期间,数据被均匀的划分,因此,磁盘被均匀填充。但是,在维护磁盘时,添加或者替换磁盘会导致DataNode节点存储出现偏移,这种情况在早期的HDFS文件系统中,是没有被处理的。如图下图所示,维护前和维护后不均衡的情况:
现在Hadoop3通过新的内部DataNode平衡功能来处理这种情况,这是通过hdfs diskbalancer CLI来进行调用的。执行之后,DataNode会进行均衡处理,如下图所示:
2.2.8 重构后台程序和任务堆管理
Hadoop守护进程和MapReduce任务的堆管理已经发生了一系列的变化。
- 配置守护进程堆大小的新方法:值得注意的是,现在可以根据主机的内存大小进行自动调整,并且已经禁止HADOOP_HEAPSIZE变量。在HADOOP\_HEAPSIZE\_MAX 和 HADOOP\_HEAPSIZE\_MIN位置上,分别设置XMX和XMS。所有全局和守护进程特定堆大小变量现在都支持单元。如果变量仅为一个数,它的大小为MB。
- Map和Reduce的堆大小的配置被简化了,所以不再需要任务配置作为一个Java选项指定。已经指定的两个现有配置不受此更改的影响。
3.总结
Hadoop3的这些新特性还是很吸引人的,目前官方推出的稳定版本是2.9.0,发行版是3.1.0,感兴趣的同学可以下载Hadoop3去体验调研学习一下这些新特性。
4.结束语
邮箱:smartloli.org@gmail.com
Twitter: https://twitter.com/smartloli
QQ群(Hadoop - 交流社区1): 424769183
温馨提示:请大家加群的时候写上加群理由(姓名+公司/学校),方便管理员审核,谢谢!
热爱生活,享受编程,与君共勉!
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
都是default惹的祸-yarn调度(一)-fair调度器drf调度策略作业不执行问题的调查和源码分析
本文主要记录了fair调度器drf调度策略作业不执行问题的解决过程,重点介绍了调查方法和调查过程细节,希望对大家了解fair调度器有所帮助 。 除本人知乎专栏外,转载请联系我。 一.问题背景 yarn的调度器有capacity和fair两种,之间的区别可以自行谷歌。fair调度器(附录1)是企业级hadoop用户常用的资源池类型,该调度器默认的队列内部调度策略(SchudelingPolicy)是fair,即分配资源时只考虑内存限制。 对一个跨部门多个团队共同使用的大集群来说,如果存在cpu密集型作业,不进行cpu控制肯定会影响其他作业的运行。想要在分配资源时同时计算内存和cpu限制,需要指定队列的调度策略为drf,即DominantResourceFainessPolicy(附录2)。一般配合cgroup使用,控制容器实际的cpu资源(
- 下一篇
Druid:实时处理时序数据的OLAP数据库
大数据分析和Druid 大数据一直是近年的热点话题,随着数据量的急速增长,数据处理的规模也从GB 级别增长到TB 级别,很多图像应用领域已经开始处理PB 级别的数据分析。大数据的核心目标是提升业务的竞争力,找到一些可以采取行动的洞察(Actionable Insight),数据分析就是其中的核心技术,包括数据收集、处理、建模和分析,最后找到改进业务的方案。 最近一两年,随着大数据分析需求的爆炸性增长,很多公司都经历过将以关系型商用数据库为基础的数据平台,转移到一些开源生态的大数据平台,例如Hadoop 或Spark 平台,以可控的软硬件成本处理更大的数据量。Hadoop 设计之初就是为了批量处理大数据,但数据处理实时性经常是它的弱点。例如,很多时候一个MapReduce 脚本的执行,很难估计需要多长时间才能完成,无法满足很多数据分析师所期望的秒级返回查询结果的分析需求。 为了解决数据实时性的问题,大部分公司都有一个经历,将数据分析变成更加实时的可交互方案。其中,涉及新软件的引入、数据流的改进等。数据分析的几种常见方法如下图。 Druid:实时处理时序数据的OLAP数据库 整个数据分析的...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2全家桶,快速入门学习开发网站教程
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS8安装Docker,最新的服务器搭配容器使用
- Hadoop3单机部署,实现最简伪集群
- MySQL8.0.19开启GTID主从同步CentOS8
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8编译安装MySQL8.0.19
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Docker快速安装Oracle11G,搭建oracle11g学习环境