不得不收藏的大数据Hadoop干货:Hadoop集群搭建搭建环境:
安装时间同步
Yum install -y ntpdate
网络时间同步命了 服务器地址是阿里云
ntpdate ntp1.aliyun.com
手动时间同步方式
date -s "20190622 12:32:00" #yyyymmdd hh:mm:ss
完全分布式
Ps:这里我们已经将时间同步,主机名称,网络通信,hosts映射都做完,以上步骤省略
上传到目录中
然后进行解压
后面的路径自己写
进入到对应的路径
就可以查看版本了
配置环境变量是为了以后方便使用
将进入和这个里配置环境变量,这是一个全局的环境变量谁都可以使用了
在最后添加
保存退出 然后然后重新加载资源文件
然后执行java -version
1.先解压hadoop安装包 到 /opt/softwar/路径下
2. 修改配置文件先修改 /hadoop2.7.1/etc/hadoop/hadoop-env
3.修改相同路径下 core-site.xml hdfs-site.xml
修改core-site.xml内容
<property> <name>fs.defaultFS</name>主namenode <value>hdfs://hadoop01:9000</value> </property> <property> <name>hadoop.tmp.dir</name>fsimage的文件夹namenode初始化创建 <value>/var/hadoop/data</value> </property>
修改hdfs-site.xml
<property> <name>dfs.replication</name> 副本的数量(包含上的文件和副本) <value>2</value> </property> <property> <name>dfs.namenode.secondary.http-address</name> secondaryNamenode启动 <value>hadoop02:50090</value> </property>
4. 添加从节点(datanode) 相同路径下 slaves
5.添加hadoop路径作为全局
修改 vi /etc/profile
重新加载资源
source /etc/profile
6.免秘钥
图解:
hadoop01和hadoop02,03,04免秘钥.因为hadoop01是namenode需要管理01,02,03,04服务器,所以应该完成面秘钥操作
若机器中没有ssh命令 yum install openssh-clients.x86_64 -y 先产生.ssh文件夹 隐藏文件 并且在~(家)目录下
发送公钥给01,02,03,04
ssh-copy-id 服务器名称 下面图片是一个例子
7.分发hadoop安装包 因为已经配置完成直接分发即可 分发给02,03,04分发命令是scp -r是递归 代表分发的是文件夹并且文件夹下面还有文件 scp 发送文件
scp -r 当前主机软件安装的路径 主机名/IP:发送过来软件要存在在当前机器下的路径
scp -r /opt/software/hadoop-2.7.1/ hadoop02:/opt/software/
8.修改02,03,04机器上vi /etc/profile文件并配置HADOOP_HOME
配置成功后从新加载 source /etc/profile
9.启动集群但是 当前集群是第一次配置
需要格式化 namenode 在hadoop01
hdfs namenode -format
ps:这个命令只能第一次开启集群的时候格式化,以后进入公司,集群是搭建好的,千万不要
10.开启集群
start-dfs.sh 开启集群
stop-dfs.sh 停止集群
模块化开启
ps:
全部启动 start-all.sh
全部停止 stop-all.sh
单个角色启动
hadoop-daemon.sh start namenode或datanode或secondarynamenode hadoop-daemon.sh stop namenode或datanode或secondarynamenode直接杀死角色 kill -9 进程。
还不知道什么是Hadoop,现如今,几乎所有的互联网企业都拥有了自己的Hadoop集群,人们提起大数据,就会想起Hadoop,Hadoop俨然成为了大数据时代的代名词。楼主就不再赘述Hadoop啦,今天楼主尽量用大白话带着大家了解它的不足之处以及大佬们是如何改进的。
不足之处
随着计算机硬件的发展,存储介质不再是掣肘大数据发展的因素,大数据越来越火的今天人们对分布式计算的要求也越来越高,很显然Hadoop这项十多年前就起源的技术必须跟着时代潮流向前发展了。那么Hadoop到底有什么不足之处呢?
大家都知道,分布式计算之所以能够引领一个时代是因为它将复杂计算划分开来,在很多台机器上同时处理,故而它处理速度快。但是在新时代人们对事务处理的效率又有了新的需求,Hadoop要等待计算全部结束才能获取结果,那如果中间结果就能够满足用户对精度的要求,Hadoop还是要等全部节点计算结束才能够返回结果,如此这般,不仅响应速度慢,也造成一定的资源浪费。有需求就有进步,大牛们开始想办法了,能不能在一部分计算结束后,先返回一个中间结果给用户呢?
产生中间结果
楼主看来应用最广泛的是2010年Tyson Condie等人提出的HOP(hadoop online prototype)方法。该改进方法的大致思路是利用“snapshot”将Map的结果用管道传输给Reduce,Reduce接收到部分数据并来产生中间结果。这需要用户提交任务后JobTracher就分配好相应的map任务和reduce任务,并将每个map任务的位置发送给reduce。管道的使用方便了map产生的数据发送给reduce,增加了并行机会,提高了利用率,减少了响应时间。在这种情况下,map一旦产生数据,reduce就开始处理,它们可以在执行过程中生成并改善最终结果的近似值。管道这种思路还拓宽了分布式计算可被应用的领域,HOP可以被用于连续查询。HOP解决了产生中间结果的问题,但它也不是完美的,HOP产生的中间结果跟最终结果之间无联系,也就是说算了耗费资源半天的中间结果只是为了看一眼,那么这种浪费是否值得呢?
考虑资源消耗
HOP在中间结果的计算上颇为浪费资源,楼主再介绍一种新的改进方法—2011年N. Pansare等人在PVLDB上发表的文章。这篇文章提出了一个适用于大规模分布式计算的OLA系统模型,它花费更少的代价,并且中间结果可以参与到最终结果计算中去,它的改进主要在两方面。首先它将所有数据结构化成数据块,再随机分配数据块到map中。强调随机两个字,因为计算只涉及到一部分数据块,如果数据不随机,那么中间结果和最终结果的偏差将会很大。Reduce阶段的主要革新是一种叫estimator(评估器)的方法。评估器是该方法种比较重要的一部分,它根据从部分map上传回来的数据计算得到一个中间结果,并估计该结果的可信度。在实际生活中,我们并不能保证数据是随机的,所以这种方法有一定局限性。
后面零零星星出现了很多在产生中间结果上的改进,在这里不一一介绍啦,以上纯属楼主自己的理解,如有错误欢迎大家指正,期待和更多道友一起进步!