hadoop的安装:
完全分布式

集群安装遇到的问题
1）格式化的时候配置文件报错
Caused by: org.xml.sax.SAXParseException; systemId: file:/home/hadoop/apps/hadoop-2.7.6/etc/hadoop/mapred-site.xml; lineNumber: 21; columnNumber: 3; The content of elements must consist of well-formed character data or markup.
file指定报错文件路径
lineNumber: 21; columnNumber: 3

找到对应的错误的文件
对应的报错位置
修正
发送到其他的各个节点
重新格式化
2）某一个进程缺失
1）全部重启
先停掉
stop-dfs.sh
任意
start-yarn.sh
resourcemanager节点
重启：
start-dfs.sh
start-yarn.sh
不建议
2)哪一个进程没有
启动哪一个进程
hadoop-daemon.sh
单独启动hdfs相关进程的命令
hadoop-daemon.sh start hdfs相关进程
hadoop-daemon.sh start datanode
hadoop-daemon.sh start namenode
hadoop-daemon.sh start secondarynamenode
yarn-daemon.sh
单独启动yarn相关进程的命令
yarn-daemon.sh start resourcemanager
yarn-daemon.sh start nodemanager
哪一个节点缺失
就在哪一个节点执行
如何判断没有启动成功的进程是否报错：
查看日志
hadoop-daemon.sh start datanode
控制台日志：starting datanode, logging to /home/hadoop/apps/hadoop-2.7.6/logs/hadoop-hadoop-datanode-hdp01.out
每一个进程真正的日志路径：
$HADOOP_HOME/logs/hadoop-hadoop-datanode-hdp01.log
日志文件的命名方式：
hadoop-hadoop-datanode-hdp01.log
段1：模块
hadoop--hdfs
yarn
代表的是当前的日志属于哪一个模块的
段2：用户名
段3：进程名
段4：哪一个节点的
如果想要确定某一个进程是否有问题，查看日志：
tail -100 $HADOOP_HOME/logs/hadoop-hadoop-datanode-hdp01.log
注意： 当前节点启动的所有进程的日志打印在当前节点的日志目录下了
3)linux安装组件的时候的环境变量问题：
环境变量配置有3个地方：
1） /etc/profile
系统环境变量
针对所有用户都有效
export java_home=/home/hadoop/apps/jdk
2）~/.bashrc
用户环境变量
/home/hadoop/.bashrc
/home/hadoop01/.bashrc
export java_home=/home/hadoop/apps/jdk1
3)~/.bash_profile
用户环境变量
export java_home=/home/hadoop/apps/jdk2
用户环境变量 仅仅对当前用户生效
上面的3个环境变量的加载顺序：
1） ----》 2） ----》 3）
最后加载的最终生效
注意：修改的是哪一个配置文件
source哪一个配置文件
4）格式化的问题
hdfs的成功的格式化只能一次
重新格式化
并启动集群：
datanode启动不了
日志报错：
java.io.IOException: Incompatible clusterIDs in /home/hadoop/data/hadoopdata/data: namenode clusterID = CID-7dc1dc31-9e8f-49ec-8dcf-540e23fbdd73; datanode clusterID = CID-0f6dc1df-3107-4ad5-b0e1-5ec6d224ffbb
hadoop的格式化的时候 生成namenode相关数据的
Re-format filesystem in Storage Directory /home/hadoop/data/hadoopdata/name ? (Y or N) Y
<property>
<name>dfs.namenode.name.dir</name>
<value>/home/hadoop/data/hadoopdata/name</value>
<description>namenode相关数据的存储目录</description>
</property>
格式化的时候 仅仅生成namenode相关数据
/home/hadoop/data/hadoopdata/name
数据下有两个文件：
current
核心信息文件夹
in_use.lock
锁文件
保证一个节点上指启动一个namenode进程
current:
VERSION: namenode的相关数据版本标识
clusterID=CID-7dc1dc31-9e8f-49ec-8dcf-540e23fbdd73
集群id
集群标识
集群中datanode和namenode之间相互相认的标志
这个标识是namenode格式化的时候生成的
datanode启动的时候 获取这个标志
datanode会将这个标志写入到自己的VERSION中
clusterID=CID-0f6dc1df-3107-4ad5-b0e1-5ec6d224ffbb
正常情况下
namenode的 clusterID
和 datanode的clusterID 一致的
但是如果重新格式化
只会将namenode的 clusterID 更新
datanode中的 clusterID 不会更新的
这个时候造成datanode启动的时候
找不到对应的 clusterID 的namenode
启动之后立即死掉
5）如何重新格式化
删除所有的hadoop的数据目录
namenode的
datanode的
rm -rf /home/hadoop/data
所有节点都需要删除
再去执行hadoop namenode -format
namenode节点执行
注意：重新格式化的
保证集群是关闭的
注意：start-all =====> start-dfs
start-yarn
stop-all ====> stop-dfs.sh
stop-yarn.sh
不建议使用

hadoop的集群的安装模式

1.单机安装模式
安装在一个节点上
直接解压 无需配置配置文件
没有分布式文件系统（hdfs） 没有后台进程
使用本地的文件系统
windows C |D |E|F
linux 数据存取来自于linux文件系统 /opt /etc /mnt

生产上肯定不会用
自己学习的时候
调试代码

2.伪分布式安装
这种安装方式只安装一个节点上的
有分布式文件系统的 有hdfs 有响应的hadoop的所有进程
分布式文件系统仅仅在一个节点上 这个集群中只有一个节点
这个节点上有5个进程 namenode datanode secondarynamenode resourcemanager nodemanager

真正进行存储和计算只有一个节点
底层只有一个节点
伪分布式
学习
测试

3.完全分布式安装
一个集群中 有多个节点共同负责存储和计算
存在真正的分布式文件系统 计算系统的
但是在这个节点中 只有一个namenode主节点 剩下的都是从节点datanode

这个时候存在一个问题：namenode存在单点故障的问题
只有一个namenode主节点
namenode一旦宕机
会造成整个集群不可用
极大安全隐患： namenode单点故障
极少数公司用
集群规模很小
3-5
学习
集群
7*24

4.高可用的安装
解决namenode的单点故障问题
hadoop2支持的
高可用集群中同时有两个namenode（注意在hadoop3中可以支持多个）
同一时间只有一个对外提供服务的 我们将这个对外提供服务的namenode称为active namenode 另一个namenode处于热备的状态（时刻处于准备接替active namenode的 active宕机的时候） 我们将这个namenode称为 standby namenode 一旦active的宕机 standby的会立即切换为active的 如果原来的active的活了 这个时候将自己的状态切换为standby
轮流切换的状态

生产上
90% 企业
存在一个新的问题：
当集群的规模很大的时候
同一时间对外提供服务的只有一个namenode
会造成namenode的压力很大（两个namendoe是不能分担压力的）
高可用集群 不适用于 超级大的规模集群

5.联邦模式安装
解决高可用集群的namenode的压力过大的问题
同一时间 一个集群中存在多个namenode 但是这多个namenode都处于active的状态的 多个namenode共同管理集群的

多个namenode共同管理集群的时候
分工明确的
不同的namenode进行管理不同的块池的数据
blockpoolID=BP-1453129122-192.168.191.201-1556592207649
多个namenode共同管理所有的从节点
超大集群
联邦+高可用

hadoop1
hdfs
mapreduce
hadoop2
hdfs
mapreduce
yarn

hdfs介绍：

海量数据存储的
就是一个文件系统
分布式文件系统
hadoop distributed filesystem

hdfs的设计思想

假设有一个超级大的文件10T
服务器多台 3T
超级大的文件如何存储呢？
存储方案：将超级大的文件 切分 每一个小文件进行存储在不同的节点上

1）分而治之的思想 block
对文件进行分块存储
这个块如何进行切分呢？
这个时候需要一个切分标准
2.5T 合理吗？
切分的数据块太大了 容易造成集群中节点的存储的负载不均衡
1kb一个块合理吗？
会造成一个文件切分过多的块 会造成namenode的压力过大

	关于这个标准
hdfs中已经帮我们设计好了：
blocksize
dfs.blocksize	134217728
<property>
<name>dfs.blocksize</name>
<value>134217728</value>
</property>
hadoop2中默认的每一个块的大小 128M
hadoop1中默认的每一个块的大小64M
hadoop3中每一个块默认大小
256M
总结：也就是说
hdfs进行文件存储的时候 将文件进行切块
默认的一个块大小128M
如果一个文件400M
0-128M blk01
128M
129-256 blk02	128M
257-384 blk03	128M
384-400 blk04	16M
独立成一个块
不会和其他的文件的数据块合并
又存储一个文件
10M
这个文件
单独成一个块
一个文件不够128M
单独成一个块
块的实际大小
实际存储的数据的大小

2）冗余存储
解决数据丢失的问题 hadoop基于普通廉价机的
用空间换取数据安全
在hdfs中每一个数据块都会进行备份存储

dfs.replication
2
HDFS 的数据块的副本存储个数

目前我们集群中配置的每一个数据块存储2个副本
这里的副本 不是备份的意思 代表的是总存储份数 这里的副本每一个副本都是同等地位的 没有优先级 多个副本数据相互互为副本的 对外提供服务的时候谁有时间谁提供

dfs.replication	3
默认配置
默认的情况下每一个数据块存储3份
注意：
1）一个节点上可以存储多个数据块的
一个数据块只能存储在一个节点上
但是同一个节点的多个数据块中肯定没有相同的
同一个数据块的多个副本
不可能存储在一个节点的 不同的副本存储在不同的节点
2）真实副本《设置值
假设集群3个节点
副本配置2个
有一个块的一个副本的节点宕机了 会造成这个块的副本数低于配置的值
这个时候会复制出来这个块的一个副本存储在另一个节点上
3）集群节点 《 副本
集群节点3个
副本 4个
会存储3份 另外与一份 namenode会进行记账
当集群中的添加节点的时候将这个欠的副本复制出来
4）真实副本 》 设置
集群中某一个节点宕机
这个节点上存储的所有的副本都会复制一份出来
过了一段时间 这个节点活了
造成这个节点上存储的数据块的副本多了
真实的副本大于设置的副本个数
等待1h左右删除多余的副本

hdfs的架构：
主从架构 一主多从的架构
namenode 主节点
hdfs的老大
1）存储元数据信息
这里的元数据指的是描述datanode上的存储的真实的数据的数据
datanode上存储数据的块的对应关系
存储路径：

dfs.namenode.name.dir
/home/hadoop/data/hadoopdata/name
namenode 存储元数据的目录

元数据存储路径 namenode节点的/home/hadoop/data/hadoopdata/name/current
fsimage 核心元数据信息
namenode记录的元数据 包含3部分内容的：
1）抽象目录树
通过目录树查看文件系统中存储的文件目录结构的
目录树 从/开始的目录结构
目录树不属于任何一个具体节点 抽象的一个目录

目前集群中3个从节点
/指的是3个从节点共同组成的一个存储系统的抽象的/目录
/jdk-8u73-linux-x64.tar.gz
180M
2)目录树中的文件和数据块的对应关系
/jdk-8u73-linux-x64.tar.gz
180M
0-128M
blk_1073741825
129-180M
blk_1073741826
注意：hadoop集群中
每一个数据块都会有一个唯一编号 全局唯一的
3）数据块和节点的对应关系 数据块存储位置
/jdk-8u73-linux-x64.tar.gz
180M
0-128M
blk_1073741825	[hdp03 hdp01]
129-180M
blk_1073741826
[hdp03 hdp01]
元数据：描述数据的数据
用于描述原始数据的数据
2）接受客户端的读写请求
客户端的所有的读写请求 先经过namenode
datanode 从节点
1）负责真正的数据存储
真正的干活的
每一个节点将对应的数据块存储在自己的本地
存储路径在哪里？
<property>
<name>dfs.datanode.data.dir</name>
<value>/home/hadoop/data/hadoopdata/data</value>
<description>datanode 存储真实数据的目录</description>
</property>
数据块的存储目录
/home/hadoop/data/hadoopdata/data
current
核心数据
in_use.lock
锁文件
current目录下：
BP-1453129122-192.168.191.201-1556592207649
块池文件夹 存储namenode管理的所有数据块信息的
VERSION
版本信息
数据块的存储目录：
/home/hadoop/data/hadoopdata/data/current/BP-1453129122-192.168.191.201-1556592207649/current/finalized/subdir0/subdir0
blk_1073741825
blk_1073741826
真实数据块
blk_1073741825_1001.meta
blk_1073741826_1002.meta
数据块的元数据信息 用于数据校验的
校验数据块的完整性的
2）	负责处理客户端真正的读写请求的
secondarynamenode
助理
namenode的冷备份节点
1）帮助namenode备份元数据
防止namenode元数据丢失
namenode元数据损坏或丢失的时候可以通过 secondarynamenode进行恢复的
2）减轻namenode的压力
帮助namenode做一些工作
帮助namenode进行元数据合并

补充：
> 覆盖 >> 追加 重定向命令的用法

查询文件内容结果 >|>>
需要重定向位置
echo "rr"
>>
cat |tail -100|head

hdfs的优缺点

缺点：
1）延时性比较高
不适合实时读取
2）不适合存储大量的小文件
原因：
1）不划算
集群中 存储了大量的 1kb一个文件 10w个
数据查询的时候
1）数据块的寻址
client — namenode （抽象目录树 数据-块 块存储位置）
client—datanode — 对应的块id
1s
2）开始读取
读取数据可能 1ms
寻址时间 远远大于 读取数据的时间 不划算
2）会造成namenode的压力很大
一个数据块 — 一条元数据
大量的小文件 — 大量的数据块— 大量的元数据信息
一条元数据信息 150byte
原始数据块 元数据
128M — 150byte
1kb ---- 150byte
10w * 1kb === 100000kb= 100M 原始数据 100g 多个从节点
10w * 150byte ==15000000byte=15M 元数据 15G 一个节点
3）不支持文件修改 支持文件追加
一次写入多次读取
修改的成本太高 首先需要先确定修改的数据所属的数据块id 在进行修改所有的对应的数据块的副本 hdfs干脆关闭了修改的功能
虽然支持文件追加 不建议使用
优点：
1）成本低
基于普通廉价机
2）高扩展性
集群的从节点 可以无限横向扩展 原则没有上线
3）高容错性
副本机制 保证数据的安全性
只要所有副本不同时宕机 就能访问数据
副本个数=节点个数 数据安全性 容错机制最好
空间—数据安全
4）高可用性
hadoop2 namenode的高可用方案
集群可以7*24 服务
5）适合批处理 大数据处理

1：查看hdfs的目录结构
基于linux 跟linux类似的 目录结构 /开始的
hadoop fs -ls /
2.文件上传
hadoop fs -put 本地文件 hdfs路径

最后

以上就是贪玩花生为你收集整理的hadoop02——hadoop的几种集群搭建方式hadoop的集群的安装模式hdfs介绍：hdfs的设计思想hdfs的优缺点的全部内容，希望文章能够帮你解决hadoop02——hadoop的几种集群搭建方式hadoop的集群的安装模式hdfs介绍：hdfs的设计思想hdfs的优缺点所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。