2019/2/16 星期六
hdfs基本概念（设计思想 特性 工作机制 上传下载 namenode存储元数据机制） 1、hdfs总的设计思想： 设计目标：提高分布式并发处理数据的效率（提高并发度和移动运算到数据） 分而治之：将大文件、大批量文件，分布式存放在大量独立的服务器上，以便于采取分而治之的方式对海量数据进行运算分析； 重点概念：文件切块，副本存放，元数据，位置查询，数据读写流
2、hdfs的shell操作 //见响应的单独文档
3、hdfs的一些概念 Hdfs分布式文件系统的基本工作机制及相关概念解析 //见画图
首先，它是一个文件系统，有一个统一的命名空间——目录树, 客户端访问hdfs 文件时就是 通过指定这个目录树中的路径来进行 其次，它是分布式的，由很多服务器联合起来实现功能； hdfs 文件系统会给客户端提供一个统一的抽象目录树，Hdfs 中的文件都是分块（block） 存储的，块的大小可以通过配置参数( dfs.blocksize)来规定，默认大小在hadoop2.x 版本 中是128M，老版本中是64M 文件的各个block 由谁来进行真实的存储呢？----分布在各个datanode 服务节点上，而 且每一个block 都可以存储多个副本（副本数量也可以通过参数设置dfs.replication，默 认值是3） Hdfs 中有一个重要的角色：namenode，负责维护整个hdfs 文件系统的目录树，以及每 一个路径（文件）所对应的block 块信息（block 的id，及所在的datanode 服务器） hdfs 是设计成适应一次写入，多次读出的场景，并不支持文件的修改 (hdfs 并不适合用来做网盘应用，因为，不便修改，延迟大，网络开销大，成本太高)
hdfs 切片的定义 概念 1：定义一个切片大小：可以通过参数来调节，默认情况下等于“hdfs 中设置的blocksize”,通常是128M 2：获取输入数据目录下所有待处理文件List 3：遍历文件List，逐个逐个文件进行切片 for(file:List) 对file 从0 偏移量开始切，每到128M 就构成一个切片，比如a.txt（200M），就会被切成两个切片： a.txt: 0-128M, a.txt :128M-256M 再比如b.txt（80M），就会切成一个切片， b.txt :0-80M
HDFS Block复制策略 –第1个副本放在客户端所在节点 •如果是远程客户端，block会随机选择节点 •系统会首先选择空闲的DataNode节点 –第2个副本放在不同的机架节点上 –第3个副本放在与第2个副本同一机架的不同机器上 –很好的稳定性、负载均衡，较好的写入带宽、读取性能，块均匀分布 –机架感知：将副本分配到不同的机架上，提高数据的高容错性 –以节点为备份对象
4、特性： 容量可以线性扩展 数据存储高可靠 分布式运算处理很方便 数据访问延迟较大，不支持数据的修改操作 适合一次写入多次读取的应用场景
5、hdfs 的工作机制 HDFS 集群分为两大角色：NameNode、DataNode NameNode 负责管理整个文件系统的元数据 DataNode 负责管理用户的文件数据块
6、namenode 工作机制 namenode 职责： 1、响应客户端请求 //客户端去请求hdfs的时候都会先去找namenode 2、维护目录树 //客户端去读或者写文件的时候都会去指定一个目录，这个目录是hdfs的目录，这个目录有namenode管理 3、管理元数据（查询，修改） ***** //什么是元数据 文件的描述信息：某一个路径的文件有几个block，每一个block在那些datanode上面有存储，一个文件的副本数量是几？这些信息就是元数据，元数据很重要，不能发生丢失或者错误，那么在客户端请求的时候，就有可能请求不到。 提示：内存中存储了一份完整的元数据，包括目录树结构，以及文件和数据块和副本存储地 的映射关系；
7、datanode 的工作机制 1、Datanode 工作职责： 2、存储管理用户的文件块数据 3、定期向namenode 汇报自身所持有的block 信息（通过心跳信息上报） 4、上传一个文件，观察文件的block 具体的物理存放情况 在每一台datanode 机器上的这个目录： /home/hadoop/app/hadoop-2.4.1/tmp/dfs/data/current/BP-193442119-192.168.2.120-1432457733 977/current/finalized
2019/2/18 星期一
hdfs 写数据流程（put）
1、根namenode 通信请求上传文件，namenode 检查目标文件是否已存在，父目录是否存在 2、namenode 返回是否可以上传 3、client 请求第一个block 该传输到哪些datanode 服务器上 4、namenode 返回3 个datanode 服务器ABC 5、client 请求3 台dn 中的一台A 上传数据（本质上是一个RPC 调用，建立pipeline），A收到请求会继续调用B，然后B 调用C，将真个pipeline 建立完成，逐级返回客户端 6、client 开始往A 上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位，A 收到一个packet 就会传给B，B 传给C；A 每传一个packet 会放入一个应答队列等待应答 7、当一个block 传输完成之后，client 再次请求namenode 上传第二个block 的服务器。
hdfs 读数据流程（get）
1、跟namenode 通信查询元数据，找到文件块所在的datanode 服务器 2、挑选一台datanode（就近原则，然后随机）服务器，请求建立socket 流 3、datanode 开始发送数据（从磁盘里面读取数据放入流，以packet 为单位来做校验） 4、客户端以packet 为单位接收，现在本地缓存，然后写入目标文件
小结： 在这里我们描述的是hdfs的读写数据的流程是比较顺利的一种情况，这上面的每一个阶段都有可能出现异常，那hdfs对于每个异常也是很完善的，容错性非常的高，这些异常处理的逻辑比较复杂，我们暂时不做深入的描述，搞懂正常的读写流程就ok了。
Hdfs中namenode管理元数据的机制 //元数据的 CheckPoint 如图：
hdfs 元数据是怎么存储的？ A、内存中有一份完整的元数据（特定数据结构） B、磁盘有一个“准完整”的元数据的镜像文件 C、当客户端对hdfs 中的文件进行新增或者修改操作，首先会在edits 文件中记录操作日志，当客户端操作成功后，相应的元数据会更新到内存中；每隔一段时间，会由secondary namenode 将namenode 上积累的所有edits 和一个最新的fsimage 下载到本地，并加载到内存进行merge（这个过程称为checkpoint） D、checkpoint 操作的触发条件配置参数： dfs.namenode.checkpoint.check.period=60 #检查触发条件是否满足的频率，60 秒 dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary #以上两个参数做checkpoint 操作时，secondary namenode 的本地工作目录 dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir} dfs.namenode.checkpoint.max-retries=3 #最大重试次数 dfs.namenode.checkpoint.period=3600 #两次checkpoint 之间的时间间隔3600 秒 dfs.namenode.checkpoint.txns=1000000 #两次checkpoint 之间最大的操作记录 E、namenode 和secondary namenode 的工作目录存储结构完全相同，所以，当namenode故障退出需要重新恢复时，可以从secondary namenode 的工作目录中将fsimage 拷贝到namenode 的工作目录，以恢复namenode 的元数据 F、可以通过hdfs 的一个工具来查看edits 中的信息 bin/hdfs oev -i edits -o edits.xml
