为什么hdfs文件块不能太大 hdfs为什么适合大文件

 1.1.HDFS概念
首先，它是一个文件系统，用于存储文件，通过统一的命名空间——目录树来定位文件 其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色；
1.2.优点

1.2.1.支持超大文件
支持超大文件。超大文件在这里指的是几百M，几百GB，甚至几TB大小的文件。一般来说hadoop的文件系统会存储TB级别或者PB级别的数据。所以在企业的应用中，数据节点有可能有上千个。
1.2.2.检测和快速应对硬件故障
在集群的环境中，硬件故障是常见的问题。因为有上千台服务器连接在一起，这样会导致高故障率。因此故障检测和自动恢复是hdfs文件系统的一个设计目标。
1.2.3.流式数据访问
Hdfs的数据处理规模比较大，应用一次需要访问大量的数据，同时这些应用一般都是批量处理，而不是用户交互式处理。应用程序能以流的形式访问数据集。主要的是数据的吞吐量，而不是访问速度。
1.2.4.简化的一致性模型
大部分hdfs操作文件时，需要一次写入，多次读取。在hdfs中，一个文件一旦经过创建、写入、关闭后，一般就不需要修改了。这样简单的一致性模型，有利于提高吞吐量。

1.3.缺点
1.3.1.低延迟数据访问
低延迟数据。如和用户进行交互的应用，需要数据在毫秒或秒的范围内得到响应。由于hadoop针对高数据吞吐量做了优化，牺牲了获取数据的延迟，所以对于低延迟来说，不适合用hadoop来做。
1.3.2.大量的小文件
Hdfs支持超大的文件，是通过数据分布在数据节点，数据的元数据保存在名字节点上。名字节点的内存大小，决定了hdfs文件系统可保存的文件数量。虽然现在的系统内存都比较大，但大量的小文件还是会影响名字节点的性能。
1.3.3.多用户写入文件、修改文件
Hdfs的文件只能有一次写入，不支持写入，也不支持修改。只有这样数据的吞吐量才能大。
1.3.4.不支持超强的事务
没有像关系型数据库那样，对事务有强有力的支持。
1.4.HDFS组成架构
HDFS 采用Master/Slave的架构来存储数据，这种架构主要由四个部分组成，分别为HDFS Client、NameNode、DataNode和Secondary NameNode。
1.4.1.Client：
文件切分。文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储。
与 NameNode 交互，获取文件的位置信息。
与 DataNode 交互，读取或者写入数据。
Client 提供一些命令来管理 HDFS，比如启动或者关闭HDFS。
Client 可以通过一些命令来访问 HDFS。

HDFS：
1）客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。
2）NameNode返回是否可以上传。
3）客户端请求第一个 Block上传到哪几个DataNode服务器上。
4）NameNode返回3个DataNode节点，分别为dn1、dn2、dn3。
5）客户端通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。
6）dn1、dn2、dn3逐级应答客户端。
7）客户端开始往dn1上传第一个Block（先从磁盘读取数据放到一个本地内存缓存），以Packet为单位，dn1收到一个Packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答。
8）当一个Block传输完成之后，客户端再次请求NameNode上传第二个Block的服务器。（重复执行3-7步）。

副本节点选择:
节点距离：两个节点到达最近的共同祖先距离总和。
副本节点选择：第一个副本在client所处节点，如果客服端在集群外，随机选择一个
第一和第二位于相同机架，随即节点
第三位于不同机架，随即节点

nn和2nn机制：
1. 第一阶段：NameNode启动
（1）第一次启动NameNode格式化后，创建Fsimage和Edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
（2）客户端对元数据进行增删改的请求。
（3）NameNode记录操作日志，更新滚动日志。
（4）NameNode在内存中对元数据进行增删改。
2. 第二阶段：Secondary NameNode工作
 （1）Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否检查结果。
 （2）Secondary NameNode请求执行CheckPoint。
 （3）NameNode滚动正在写的Edits日志。
 （4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
 （5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并。
 （6）生成新的镜像文件fsimage.chkpoint。
 （7）拷贝fsimage.chkpoint到NameNode。
 （8）NameNode将fsimage.chkpoint重新命名成fsimage。

1.4.2.NameNode：
就是 master，它是一个主管、管理者。
管理 HDFS 的名称空间
管理数据块（Block）映射信息
配置副本策略
处理客户端读写请求。
1.4.3.DataNode：
就是Slave。NameNode 下达命令，DataNode 执行实际的操作。
存储实际的数据块。
执行数据块的读/写操作。
1.4.4.Secondary NameNode：
并非 NameNode 的热备。当NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。
辅助 NameNode，分担其工作量。
定期合并 fsimage和fsedits，并推送给NameNode。
在紧急情况下，可辅助恢复 NameNode。
1.5.HDFS文件块大小
HDFS中的文件在物理上是分块存储（block），块的大小可以通过配置参数( dfs.blocksize)来规定，默认大小在hadoop2.x版本中是128M，老版本中是64M
HDFS的块比磁盘的块大，其目的是为了最小化寻址开销。如果块设置得足够大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。因而，传输一个由多个块组成的文件的时间取决于磁盘传输速率。
如果寻址时间约为10ms，而传输速率为100MB/s，为了使寻址时间仅占传输时间的1%，我们要将块大小设置约为100MB。默认的块大小实际为64MB，但是很多情况下HDFS使用128MB的块设置。
块的大小：10ms*100*100M/s = 100M

为什么块的大小不能设置太小，也不能设置太大？
（1）HDFS的块设置太小，会增加寻址时间，程序一直在找块的开始位置；
（2）如果块设置的太大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。导致程序在处理这块数据时，会非常慢。
总结：HDFS块的大小设置主要取决于磁盘传输速率。
如果你的磁盘传输速率很高的话，你完全可以加大块的大小。

1.6.HDFS的shell操作
基本语法
bin/hadoop fs 具体命令   OR  bin/hdfs dfs 具体命令
dfs是fs的实现类。

-ls #显示目录信息
-put #等同于copyFromLocal #从本地文件系统中拷贝文件到hdfs 路径去
-get #等同于copyToLocal，就是从hdfs 下载文件到本地#从hdfs 拷贝到本地
-getmerge #合并下载多个文件
-moveFromLocal #从本地移动到hdfs
-moveToLocal #从hdfs 移动到本地
-cp #从hdfs 的一个路径拷贝hdfs 的另一个路径
-mv #在hdfs 目录中移动文件
-mkdir #在hdfs 上创建目录这里的-p 是创建目录下再创建目录-mkdir 只能创建一个目录
-rmdir #删除空目录
-cat ---显示文件内容
-->hadoop fs -cat /hello.txt
-tail ---显示文件内容(用法和cat 一样)
.........
1.7.HDFS客户端操作
1.HDFS客户端环境准备（使用IDEA)
根据自己电脑的操作系统拷贝对应的编译后的hadoop jar包到非中文路径
2.配置HADOOP_HOME环境变量
3配置Path环境变量
4．创建一个Maven工程HdfsClientDemo
5．导入相应的依赖坐标+日志添加
6．创建包名：com.jinghang.hdfs
7．创建HdfsClient类
1.8.HDFS数据流
HDFS写数据流程
1）客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。
2）NameNode返回是否可以上传。
3）客户端请求第一个 Block上传到哪几个DataNode服务器上。
4）NameNode返回3个DataNode节点，分别为dn1、dn2、dn3。
5）客户端通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。
6）dn1、dn2、dn3逐级应答客户端。
7）客户端开始往dn1上传第一个Block（先从磁盘读取数据放到一个本地内存缓存），以Packet为单位，dn1收到一个Packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答。
8）当一个Block传输完成之后，客户端再次请求NameNode上传第二个Block的服务器。
HDFS的读数据流程
1）客户端通过Distributed FileSystem向NameNode请求下载文件，NameNode通过查询元数据，找到文件块所在的DataNode地址。
2）挑选一台DataNode（就近原则，然后随机）服务器，请求读取数据。
3）DataNode开始传输数据给客户端（从磁盘里面读取数据输入流，以Packet为单位来做校验）。
4）客户端以Packet为单位接收，先在本地缓存，然后写入目标文件。

1.11. HDFS HA高可用
1.11.1.HA概述
1）所谓HA（High Available），即高可用（7*24小时不中断服务）。
2）实现高可用最关键的策略是消除单点故障。HA严格来说应该分成各个组件的HA机制：HDFS的HA和YARN的HA。
3）Hadoop2.0之前，在HDFS集群中NameNode存在单点故障（SPOF）。
4）NameNode主要在以下两个方面影响HDFS集群
 NameNode机器发生意外，如宕机，集群将无法使用，直到管理员重启
 NameNode机器需要升级，包括软件、硬件升级，此时集群也将无法使用
HDFS HA功能通过配置Active/Standby两个NameNodes实现在集群中对NameNode的热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将NameNode很快的切换到另外一台机器。

1.11.2.HDFS-HA工作要点
1. 元数据管理方式需要改变
内存中各自保存一份元数据；
Edits日志只有Active状态的NameNode节点可以做写操作；
两个NameNode都可以读取Edits；
共享的Edits放在一个共享存储中管理（qjournal和NFS两个主流实现）；
2. 需要一个状态管理功能模块
实现了一个zkfailover，常驻在每一个namenode所在的节点，每一个zkfailover负责监控自己所在NameNode节点，利用zk进行状态标识，当需要进行状态切换时，由zkfailover来负责切换，切换时需要防止brain split现象的发生。
3. 必须保证两个NameNode之间能够ssh无密码登录
4. 隔离（Fence），即同一时刻仅仅有一个NameNode对外提供服务

1.12. HDFS-HA集群配置
环境准备
规划集群
配置Zookeeper集群
配置HDFS-HA集群
启动HDFS-HA集群
配置HDFS-HA自动故障转移
1.13. YARN-HA配置
1.环境准备
（1）修改IP
（2）修改主机名及主机名和IP地址的映射
（3）关闭防火墙
（4）ssh免密登录
（5）安装JDK，配置环境变量等
（6）配置Zookeeper集群
2.规划集群
3.具体配置
4.启动hdfs
5.启动YARN