Hadoop之hdfs详解

@TOC@(Scala入门—)

Hadoop之hdfs详解

Hadoop由两部分组成，分别是分布式文件系统HDFS和分布式计算框架MapReduce。
在Hadoop中，MapReduce底层的分布式文件系统是独立模块，用户可按照约定的一套接口实现自己的分布式文件系统，然后经过简单的配置后，存储在该文件系统上的数据便可以被MapReduce处理。
Hadoop默认使用的分布式文件系统是HDFS（Hadoop Distributed File System）。

HDFS基本组成

HDFS的架构如下图所示：

hdfs的设计思：

假设有一个超级大的文件10T
服务器多台 ，每一个3T
超级大的文件如何存储呢？
存储方案：将超级大的文件 切分 每一个小文件进行存储在不同的节点上

1. 分而治之的思想 （block） ，对文件进行分块存储
   这个时候需要一个切分标准：
   2.5T 合理吗？
   切分的数据块太大了 容易造成集群中节点的存储的负载不均衡
   1kb一个块合理吗？
   会造成一个文件切分过多的块 会造成namenode的压力过大
   关于这个标准 hdfs中已经帮我们设计好了：
   blocksize
   dfs.blocksize 134217728
   > hadoop2.0中默认的每一个块的大小 128M
   hadoop1.0中默认的每一个块的大小64M
   hadoop3.0中每一个块默认大小 256M
   总结：也就是说 如果我们用hadoop2.0， hdfs进行文件存储的时候 将文件进行切块 默认的一个块大小128M。如果一个文件400M ，就会切分成如下：
   0-128M blk01 128M
   129-256 blk02 128M
   257-384 blk03 128M
   384-400 blk04 16M 独立成一个块 不会和其他的文件的数据块合并又存储一个文件
   这个文件 单独成一个块
   一个文件不够128M 单独成一个块。
   而块的实际大小 实际存储的数据的大小
2. 冗余存储
   解决数据丢失的问题 hadoop基于普通廉价机的
   用空间换取数据安全
   在hdfs中每一个数据块都会进行备份存储
   (
   dfs.replication
   2
   HDFS 的数据块的副本存储个数
   )
   目前我们集群中配置的每一个数据块存储2个副本
   这里的副本，不是备份的意思它代表的是总存储份数 这里的副本每一个副本都是同等地位的， 没有优先级 ，多个副本数据相互互为副本的 ，对外提供服务的时候谁有时间谁提供
   dfs.replication 3 默认配置 ，默认的情况下每一个数据块存储3份
   注意：
   1）一个节点上可以存储多个数据块的 一个数据块只能存储在一个节点上
   但是同一个节点的多个数据块中肯定没有相同的
   同一个数据块的多个副本 不可能存储在一个节点的 不同的副本存储在不同的节点
   2）真实副本<设置值
   假设集群3个节点 副本配置2个 有一个块的一个副本的节点宕机了 会造成这个块的副本数低于配置的值 这个时候会复制出来这个块的一个副本存储在另一个节点上
   3）集群节点>副本
   集群节点3个 副本 4个
   会存储3份 另外与一份 namenode会进行"记账"当集群中的添加节点的时候将这个欠的副本复制出来
   4）真实副本> 设置
   集群中某一个节点宕机 这个节点上存储的所有的副本都会复制一份出来 过了一段时间 这个节点活了 造成这个节点上存储的数据块的副本多了 真实的副本大于设置的副本个数 等待1h左右删除多余的副本

hdfs的架构：一主多从的架构

hdfs的架构：
主从架构 一主多从的架构
hdfs中主是：namenode 主节点，是hdfs的老大，它的功能是
1）存储元数据信息
这里的元数据指的是描述datanode上的存储的真实的数据的数据
datanode上存储数据的块的对应关系
存储路径：

dfs.namenode.name.dir
/home/hadoop/data/hadoopdata/name
namenode （存储元数据的目录）

2）namenode记录的元数据 包含3部分内容的：
1 抽象目录树
通过目录树查看文件系统中存储的文件目录结构的，其中目录树是从**/开始的目录结构
目录树不属于任何一个具体节点，它是一个抽象的一个目录，假如目前集群中3个从节点，分别是hdp01,hdp02,hdp03/指的是3个从节点共同组成的一个存储系统的抽象的/**目录
2 目录树中的文件和数据块的对应关系，如下有一个180M大小的文件
/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]
da1
2）datanode 从节点 包含2部分内容的：
1）负责真正的数据存储
真正的干活的
每一个节点将对应的数据块存储在自己的本地
存储路径在哪里？

dfs.datanode.data.dir
/home/hadoop/data/hadoopdata/data
datanode 存储真实数据的目录

数据块的存储目录
/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进行元数据合并

hdfs的架构：优缺点

缺点：
1）延时性比较高
不适合实时读取
2）不适合存储大量的小文件
原因：
1）不划算
集群中 存储了大量的 1kb一个文件 10w个
数据查询的时候
1数据块的寻址
client — namenode （抽象目录树 数据-块 块存储位置）
client—datanode — 对应的块id
2 开始读取
读取数据可能 1ms
寻址时间 远远大于 读取数据的时间 不划算
3 会造成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）适合批处理 大数据处理