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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125找到对应的错误的文件 对应的报错位置 修正 发送到其他的各个节点 重新格式化 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
1
2
3
4生产上肯定不会用 自己学习的时候 调试代码
2.伪分布式安装
这种安装方式只安装一个节点上的
有分布式文件系统的 有hdfs 有响应的hadoop的所有进程
分布式文件系统仅仅在一个节点上 这个集群中只有一个节点
这个节点上有5个进程 namenode datanode secondarynamenode resourcemanager nodemanager
1
2
3
4
5
6真正进行存储和计算只有一个节点 底层只有一个节点 伪分布式 学习 测试
3.完全分布式安装
一个集群中 有多个节点共同负责存储和计算
存在真正的分布式文件系统 计算系统的
但是在这个节点中 只有一个namenode主节点 剩下的都是从节点datanode
1
2
3
4
5
6
7
8
9
10
11
12这个时候存在一个问题：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
轮流切换的状态
1
2
3
4
5
6
7
8生产上 90% 企业 存在一个新的问题： 当集群的规模很大的时候 同一时间对外提供服务的只有一个namenode 会造成namenode的压力很大（两个namendoe是不能分担压力的） 高可用集群 不适用于 超级大的规模集群
5.联邦模式安装
解决高可用集群的namenode的压力过大的问题
同一时间 一个集群中存在多个namenode 但是这多个namenode都处于active的状态的 多个namenode共同管理集群的
1
2
3
4
5
6
7
8多个namenode共同管理集群的时候 分工明确的 不同的namenode进行管理不同的块池的数据 blockpoolID=BP-1453129122-192.168.191.201-1556592207649 多个namenode共同管理所有的从节点 超大集群 联邦+高可用
hadoop1
hdfs
mapreduce
hadoop2
hdfs
mapreduce
yarn
hdfs介绍：
1
2
3
4
5海量数据存储的 就是一个文件系统 分布式文件系统 hadoop distributed filesystem
hdfs的设计思想
假设有一个超级大的文件10T
服务器多台 3T
超级大的文件如何存储呢？
存储方案：将超级大的文件 切分 每一个小文件进行存储在不同的节点上
1）分而治之的思想 block
对文件进行分块存储
这个块如何进行切分呢？
这个时候需要一个切分标准
2.5T 合理吗？
切分的数据块太大了 容易造成集群中节点的存储的负载不均衡
1kb一个块合理吗？
会造成一个文件切分过多的块 会造成namenode的压力过大
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32关于这个标准 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个副本
这里的副本 不是备份的意思 代表的是总存储份数 这里的副本每一个副本都是同等地位的 没有优先级 多个副本数据相互互为副本的 对外提供服务的时候谁有时间谁提供
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27dfs.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）抽象目录树
通过目录树查看文件系统中存储的文件目录结构的
目录树 从/开始的目录结构
目录树不属于任何一个具体节点 抽象的一个目录
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67目前集群中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进行元数据合并
补充：
> 覆盖 >> 追加 重定向命令的用法
1
2
3
4
5
6查询文件内容结果 >|>> 需要重定向位置 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内容请搜索靠谱客的其他文章。
发表评论 取消回复