Hadoop学习第三课（HDFS架构--读、写流程）

1. 块概念

举例1：一桶水  1000ml，瓶子的规格 100ml   =>需要10个瓶子装完

           一桶水  1010ml，瓶子的规格 100ml   =>需要11个瓶子装完

           一桶水  1010ml，瓶子的规格 200ml   =>需要6个瓶子装完

块的大小<==>规格，只要是需要存储，哪怕一点点，也是要占用一个块的

块大小的参数：dfs.blocksize   官方默认的大小为128M

官网：https://hadoop.apache.org/docs/r3.2.2/hadoop-project-dist/hadoop-hdfs/hdfs-default.xml

搜索blocksize关键字

举例2：假设一个小电影的大小是256M

1   128M

2   128M

3    4M

需要三个块来存储

在伪分布式模式：有一个DN节点，副本数为1，3个块，它的实际存储空间是260M

在集群模式：有3个DN节点，副本数为3，3*3=9个块，它的实际存储就是260*3=780M，而不是128*3*3=1152M，这是错误的，每个副本的第三块是没有装满的，它不会自动生成数据。

举例3：假设有一亿个小文件，每个小文件的大小是10kb，集群模式下，3个DN节点，副本数为3，一共有1亿*3=3亿个块===>3亿条数据

假设还有一亿个小文件，每个小文件的大小是10kb,合并成100万个100M的文件（块的大小128M），集群模式下，3个DN节点，副本数为3，一共有100万*3=300万个块===>300万条数据

NN维护：元数据，元数据指的就是，文件名称、路径、权限、被切割哪些块、这些块分布在哪些机器，假设每个元数据大小是15kb。

namenode维护==>3亿*15kb数据 VS 300万*15kb 哪个轻松？肯定是300万的轻松

但是：基本上，很少有数据文件超过128M的，都是小文件比较多

业务关系型数据源，同步很难解决小文件。
日志型数据源(flume)、计算结果(spark--语法--coalesce)，可以控制小文件；

所以生产上：尽规避小文件在HDFS存储，又或者 

a.数据在传输到hdfs之前，提前合并
b.数据已经到了hdfs，就定时在业务低谷时期，去合并(冷)文件----比如 12月1号，合并10月1号； 12月2号，合并10月2号。 做到一天卡一天；

在之后的学习中有：hive--有一套合并小文件的方法，并且是手动的 ；hbase--自带小合并和大合并，是自动的

所以说，小文件过多会对危害我们的元数据！！！！！

2. hdfs架构

2.1 hdfs是一个主从架构，并且大数据的组件大部分都是主从架构的---老大带着一群小弟干活

官网：