1.hosts文件
无论Linux还是window系统都有hosts文件
Linux/mac配置hadoop网络：
局域网内网机器 /VM : 内网ip
云服务器: 内网ip + 外网ip(ssh链接、打开服务web界面、对外提供服务，也就是
类似的堡垒机
)
云服务器的host文件也是配置
内网ＩＰ
[root@hadoop001 ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
本地浏览器访问hadoop的web管理界面问题？
在本地访问hadoop web管理界面时，需配置网络
1.情况 本地-----------VM虚拟机中hadoop
链接线路:本地浏览器外网----windows hosts-----本地VM-----hadoop
方法：配置C:\Windows\System32\drivers\etc\hosts
192.168.1.100 hadoop # IP为虚拟机中的
内网
IP
2.情况 本地-------------云服务中hadoop
链接线路 :本地浏览器外网----windows hosts-----云服务器外网-----云服务器内网-----hadoop
方法：配置C:\Windows\System32\drivers\etc\hosts
XXXXXXXXXX hadoop # IP为云服务器的
外网
IP
提醒:
在windows上进行apache hbase 开发时，windows配置hbase集群的时候
hosts文件 都要配置hbase集群的节点的i “IP HOSTNAME”。
hadoop web界面介绍
1.通过hdfs上传文件
2.web界一览表
首页--Hadoop 显示hdfs文件信息
找
到根目录下
这个文件。包括文件的
详细信息
。
首页--Overview 查看节点信息
SUMARY信息，也是提供节点信息，生产一般看DFS Remaining剩余空间
首页--Overview Startup Progress
yarn的web界面介绍
配置yarn的内存大小
默认是8G，如果yarn的作业无法提交，需要调大此内存。
HDFS架构设计:
块block介绍
hdfs-default.xml 寻找blocksize,配置块大小参数。
dfs.blocksize
#块的大小默认128M
134217728
dfs.replication
#块的副本数默认3份
3
生产HDFS存储小文件问题？
答：生产HDFS不适合存放小文件，
HDFS将文件以块的方式存储，块默认128M。比如一个260M的文件，实际存块情况如下
实际存储 规格
块A: 128M 128M A0 A1 A2
块B: 128M 128M B0 B1 B2
块C: 4M 128M C0 C1 C2
(生产上 hdfs不适合存储小文件？为什么不合适？如果真的有小文件，该怎么办？该怎么合并)
将文件以块的方式分割，去存储
面试题:
一个文件160m,块大小128m，副本数2。
请问实际几个块，实际物理存储多少？
块1 128m
块2 32m
各自备份：
-
块3 128m
-
块4 32m
-
所以4个块,实际大小为160m *2 =320m
-
3.HDFS架构设计
进程介绍
namenode 简称nn 名称节点
secondary namenode 简称snn 第二名称节点
datanode 简称dn 数据节点
每个节点存放块。相邻节点中块是互相备份关系，
主从架构
Rack : 机柜 可以放多个主机 10个 GPU主机 5个
机柜：
1.物理的 类似图中的机柜
2.虚拟的 类似虚拟机划分区域
namenode作用:
1.管理文件系统的命名空间，维护文件系统(可理解成维护一些文件的数据字典)
2.存放在【命名空间镜像文件-fsimage】和【编辑日志editlog】永久保存在磁盘上。
信息包括：
a.文件名称
b.文件目录结构
c.文件属性 创建时间 权限 副本数
d.文件对应哪些数据块
e.数据块对应哪些datanode节点上。
每个节点的块有损坏等因素，nn节点不会持久化存储块的映射关系，故需要namenode与datanode 之间有一个动态维 护关系，叫做blockmap。
blockmap
datanode定期向namenode发送blockreport信息。
以此namenode在【内存】中动态维护这种映射关系。
假设 nn 8G,爆了
关于生产上 hdfs不适合存储小文件的思考，
生产上 hdfs不适合存储小文件？为什么不合适？如果真的有小文件，该怎么办？该怎么合并。
假设namenode有8G大小,nn节点需要250字节，有1亿个小文件即1亿*250字节大小，是很占空间的
因为解决方案是：将碎片文件尽量合并为小于一个块的大小 ，例如：120m <=128m
hdfs合并文件有具体方法，百度搜索。
寻找存放文件信息：
su - hadopp
ll
cd dfs/name/current
[root@hadoop001 current]# pwd
/tmp/hadoop-hadoop/dfs/name/current
[root@hadoop001 current]# ll
total 1040
-rw-r--r--. 1 root root 1048576 Feb 17 20:23 edits_inprogress_0000000000000000001 #存放文件信息位置，
记录读写请求
-rw-r--r--. 1 root root 321 Feb 17 19:23 fsimage_0000000000000000000 #存放文件信息
-rw-r--r--. 1 root root 62 Feb 17 19:23 fsimage_0000000000000000000.md5
-rw-r--r--. 1 root root 2 Feb 17 19:23 seen_txid
-rw-r--r--. 1 root root 219 Feb 17 19:23 VERSION
提示：secoundarynode 进程就是通过备份edits_inprogress_0000000000000000001 和 fsimage_0000000000000000000来防止，文件目录树字典的丢失
，
达到保护文件信息的目的。
datanode作用: 读写文件的数据块。
1.存储【数据块】和【数据块的校验和】
“数据块的校验和” 作用比如在上海写入A块和杭州写入B块。用户在读取数据先判断 块是否有损坏，再就近原则拿块，高容错的做法。
2.与namenode通信:
a.每隔3秒发送一个心跳,通知自己的链接状态。
b.每10次心跳发送一次当前节点的blockreport，以便namenode及时更新各节点块信息文件。
snn作用:
1.读取namenode日志信息，定时备份，将fsimage+editlog文件合并为新的fsimage文件,防止namenode挂掉。
2.将合并后的文件推送给nn节点，简称为checkpoint
参数 ：
dfs.namenode.checkpoint.period 3600s ，相当于1小时备份一次。
editlog与fsiamge的关系
editlog是小碎片文件，fsiamge是一段时间内对editlog日志文件的归并。
例如：editlog-001
editlog-002 统一合并为 fsiamge-001
editlog-003
editlog-004
editlog-001
editlog-002
editlog-003
editlog-004
统一合并为 fsiamge-002
editlog-005
editlog-006
editlog-007
editlog-008
这里要注意： fsiamge文件是对前面 editlog日志文件的全量归并，而不是增量。
