一.block块的概念
Block块大小的默认参数：dfs.blocksize 默认128M
理解一：
假如一桶水1000 ml， 瓶子规格 100ml ==》 需要10瓶子
一桶水1010 ml， 瓶子规格 100ml ==》 需要10+1=11瓶子
假如瓶子规格200ml ==》需要 5+1 =6瓶子
理解二：
假如一个小电影260M，根据block块大小的默认参数dfs.blocksize分为：
第一个块128M；第二个块128M；第三个块 4M。总共三个块。
对于伪分布式来讲，1个小弟DN节点, 副本数(dfs.replication) 1 ，共3个块，实际存储空间是260M*1=260M。
但是对于集群来讲，3个小弟DN节点，副本数(dfs.replication)设置为3（默认值是连它自己复制3份） ，共3*3=9个块，实际存储空间是260M*3=780M 【注意】!!!此时不是128M*3*3哟，128M*3*3是错误的!!!因为第三个块并没有装满，而且不能把128M*3作为实际的存储空间，因为绝对不能够平白无故产生数据。
【考点】存储空间=文件大小*其副本数
对于老大Namenode维护的是元数据，元数据是指文件名称、路径、权限、被切割哪些块，这些块分布在哪些机器上。
【面试题】假设有1亿个小文件，每个小文件10KB（没有达到128M规格，一个文件就是一个块），对于集群3个DN节点，副本数为3 ， 那么共1亿block块*3=3亿块。那么3亿个块，即Namenode就需要维护3亿条数据。
假设1亿个小文件，每个小文件10KB，在生产上把这些小文件合并为100万个100M的大文件，对于集群3 DN节点，副本数为3 ，那么此时100百万*3=3百万块，即Namenode只需要维护3百万条数据。
问：Namenode维护3亿条数据和3百万条数据的压力，谁轻松？
答：肯定是维护300万条数据更轻松。因为元数据是存储在namenode进程的内存里，内存是一定的。比如内存8G，三亿条数据可能撑爆，而三百万少了两个数量级。
但是实际生产中基本都是小文件，在业务关系型数据源中，同步很难解决小文件（基本上不可能达到128M）；而日志型数据源(flume)、计算结果(spark coalesce)，我们可以控制小文件。
所以生产上: 尽量规避小文件在HDFS的存储
第一步：数据在传输到hdfs之前，提前合并
第二步：数据已经到了hdfs，就定时在业务低谷时期，去合并(冷)文件，比如 12月1号，去合并10月1号的；在12月2号，去合并10月2号的。一天卡一天的去合并。
对于hbase自带的小合并和大合并；对于hive有一套手动合并小文件的方法；对于spark coalesce和flume都是手动合并的。
二.hdfs架构
大数据的大多数组件都是主从架构（都是一个老大带着一堆小弟去干活）
【面试题】：大数据的组件是不是每一个组件都是属于主从架构？
答：不是。Hdfs、yarn、hbase等属于主从构架；而kafka、kettle等不属于主从架构。
机架（服务器机架）：Rack1机架1里面三台机器；Rack2机架2里面两台机器。
1.NN:namenode名称节点-"老大"
老大NN的作用
主要维护：
a.文件的名称
b.文件的目录结构、权限、大小、所属用户用户组 时间
c.【超级重点】文件被切割哪些块？这些块(块本身+2副本=3个块)分布在哪些DN节点上？这种关系叫blockmap块映射。老大NN不会持久化存储这种映射关系（因为数据文件一直在变化），而是通过集群启动和运行时候，小弟DN定期给老大NN汇报blockreport，然后老大NN在内存中动态维护这种映射关系。
老大NN的数据表现形式
ll ~/tmp/hadoop-hadoop001/dfs/name/current
其中：edits是指编辑日志文件；fsimage是指镜像文件；edits_inprogress正在进行的读和写的请求。
2. SNN:secondarynamenode 第二名称节点-"老二"
老二SNN的数据表现形式
ll ~/tmp/hadoop-hadoop001/dfs/namesecondary/current
老二SNN的作用
将老大NN的镜像文件fsimage_0000000000000000222和编辑日志文件edits_0000000000000000223-0000000000000000224拿到SNN，进行【合并】，生成fsimage_0000000000000000224文件，然后将此文件【推送】给老大；同时，老大在新的编辑日志文件edits_inprogress_0000000000000000225
这个整体的动作叫做检查点：checkpoint
checkpoint：
dfs.namenode.checkpoint.period 3600s（1小时做一次）
dfs.namenode.checkpoint.txns 1000000（数据内容达到100万做一次）二者满足其一做一次checkpoint动作。
在大数据早期的时候，只有老大NN一个人，假如挂了 ，真的挂了。
中期的时候，SNN，定期来合并、 备份 、推送，但是这样的也就是1小时备份1次，局限性很大。比如11点合并备份，但是11点半挂了，从SNN恢复到NN，只能恢复11点的时刻的元数据，丢了11-11点半的元数据。
后期就取消SNN，新建一个实时NN，作为高可靠 HA。相当于两个老大：“老大”NN Active和“新老大”NN Standby，新老大实时的等待active NN挂了，瞬间启动Standby--》active，取代老大，对外提供读写服务。
3. DN:datanode 数据节点-"小弟"
a.存储数据块 和 块的校验和
b.定期给NN发送块报告
dfs.blockreport.intervalMsec 21600000(ms 即块的报告6个小时报告一次)
dfs.datanode.directoryscan.interval 21600(s即块的扫描6个小时报告一次)
注意单位哟!!!
4.修复数据块
参考：生产HDFS Block损坏恢复最佳实践(含思考题) | 若泽大数据 www.ruozedata.com
三.hdfs 写流程(面试题)output
1. hdfs client调用FileSystem.create(filePath)方法，去和老大NN进行【RPC】通信。
①校验：老大NN会去check检查这个文件是否已经存在、是否有权限创建这个文件等一系列校验操作。假如都校验通过，就创建一个新的文件(但这时文件是没有数据的、是不关联任何的block的)。
②计算：NN会根据文件的大小、需要的块大小、副本数等参数(当前集群的块大小128、副本数3)和当前的DN节点情况，计算出这个文件要上传多少个块(包含副本)和这些块上传到哪些DN节点。
③最终把这个信息返回给客户端【FsDataOutputStream】对象。
2. Client 调用【FsDataOutputStream】对象的write方法。
根据【副本放置策略】，将第一个块的本身写到DN1，写完复制到DN2，再写完复制到DN3.
当三个副本写完的时候，就返回一个ack package确认包给DN2，DN2接收到确认包并加上自己也写完了，发送ack package确认包给DN1，DN1接收到ack package确认包后加上DN1自己写完了，就给【FsDataOutputStream】发送ack package确认包，告诉它第一个块 三个副本都写完了。
以此类推。
3. 当所有的块全部写完，Client调用【FsDataOutputStream】对象的close方法，关闭输出流。再次调用FileSystem.complete方法，告诉NN文件写成功。
【问题1】伪分布式1台datanode,副本参数设置必须是1吗？
答：按理说只能设置1，但实际上通过验证，设置2也可以，但这样会显示丢失一个副本。
验证：cd ~/app/hadoop/etc/hadoop
vi hdfs--site.xml将<value>1</value>中的1改为2(副本数)
sh stop-dfs.sh && sh start-dfs.sh
【问题2】生产上分布式3台datanode，副本参数是3，如果其中一个datanode挂了，数据是否能够写入？
答：按照正常的写法肯定是写不了的。如果要写的话，除非写的时候降低副本数，指定副本参数为1和2，那就可以写了。
【问题3】生产上分布式大于3台datanode，副本参数是3，如果其中一个datanode挂了，数据是否能够写入？
答：肯定可以。
四.hdfs 读流程(面试题)input
一个块有三个副本，写的时候三个副本都需要，但是读的时候只读一个。
1. Client调用FileSystem的open(filePath)，与NN进行【RPC】通信。
返回这个文件的部分或者全部的block列表，也就是返回【FSDataInputStram】对象。
2. Client调用【FSDataInputStram】对象的read方法，去与第一个块的最近的DN的进行读取。（块也可以看成一个副本）
读取完成后会check校验，假如ok就关闭与DN通信；假如不ok，就记录块和DN的信息，下次就不从这个节点读取，那么从第二个节点读取。然后与第二个块的最近的DN进行读取，以此类推。
假如当block的列表全部读取完成，文件还没结束，再去NN请求下一个批次的block列表。
比如：
block1-1放在 dn1
block1-2放在 dn2
block1-3 放在dn3
读的时候，dn3离的最近，就先被读取：
block2-1 dn3
block2-2 dn1
block2-3 dn2
3. Client调用【FSDataInputStram】对象的close方法，关闭输入流。
【 提醒】：hbase ，主从架构，读写操作不经过老大
五.副本放置策略
参考：【若泽大数据】大数据平台建设三部曲，真正从0开始(全网讲该主题第一人，因为在职)_哔哩哔哩_bilibili
生产上读写操作，尽量选择DN节点操作。
第一个副本：放置在DN自己本身节点，就近原则，节省网络IO。假如不是datanode节点，就随机挑选一个磁盘不太慢、CPU不太忙的节点。
第二个副本：放置在第一个副本的不同机架的某个节点。
第三个副本：放置与第二个副本相同机架（一个机架一般放5台机器）的不同机器上。
如果副本数设置更多，随机放。
但是:
生产上真的是这样的吗？这样会带来 权限问题，比如一不小心把Linux文件删除了怎么办
所以生产上真正的是，有个单点的客户端节点，不是NN也不是DN进程在。
其实网络IO，还好。一般生产上集群内部都是万兆带宽 光纤的。忽略不计。
