在配置hbase集群将 hdfs 挂接到其它镜像盘时，有不少困惑的地方，结合以前的资料再次学习;　大数据底层技术的三大基石起源于Google在2006年之前的三篇论文GFS、Map-Reduce、 Bigtable，其中GFS、Map-Reduce技术直接支持了ApacheHadoop项目的诞生，Bigtable催生了NoSQL这个崭新的数据库领域，由于map-Reduce处理框架高延时的缺陷， Google在2009年后推出的Dremel促使了实时计算系统的兴起，以此引发大数据第二波技术浪潮，一些大数据公司纷纷推出自己的大数据查询分析产品，如： Cloudera 开源了大数据查询分析引擎 Impala 、 Hortonworks 开源了 Stinger 、 Fackbook 开源了 Presto 、UC Berkeley AMPLAB实验室开发了 Spark 计算框架，所有这些技术的数据来源均基于hdsf, 对于 hdsf 最基本的不外乎就是其读写操作

目录：hdfs 名词解释hdsf 架构NameNode(NN)Secondary NNhdfs 写文件hdfs 读文件block持续化结构HDFS名词解释：Block： 在HDFS中，每个文件都是采用的分块的方式存储，每个block放在不同的datanode上，每个block的标识是一个三元组（ block id， numBytes，generationStamp ），其中block id是具有唯一性，具体分配是由namenode节点设置，然后再由datanode上建立block文件，同时建立对应block meta文件Packet： 在DFSclient与DataNode之间通信的过程中，发送和接受数据过程都是以一个packet为基础 的方式进行Chunk： 中文名字也可以称为块，但是为了与block区分，还是称之为chunk。在DFSClient与DataNode之间通信的过程中，由于文件采用的是基于块的方式来进行的，但是在发送数据的过程中是以packet的方式来进行的， 每个packet包含了多个chunk ，同时对于每个chunk进行checksum计算，生成checksum bytes小结：Packet结构与定义： Packet分为两类，一类是实际数据包，另一类是heatbeat包。一个Packet数据包的组成结构，如图所示上图中，一个Packet是由Header和Data两部分组成，其中Header部分包含了一个Packet的概要属性信息，如下表所示：Data部分是一个Packet的实际数据部分，主要包括一个4字节校验和（Checksum）与一个Chunk部分，Chunk部分最大为512字节在构建一个Packet的过程中，首先将字节流数据写入一个buffer缓冲区中，也就是从偏移量为25的位置（checksumStart）开始写Packet数据Chunk的Checksum部分，从偏移量为533的位置（dataStart）开始写Packet数据的Chunk Data部分，直到一个Packet创建完成为止。当写一个文件的最后一个Block的最后一个Packet时，如果一个Packet的大小未能达到最大长度，也就是上图对应的缓冲区中，Checksum与Chunk Data之间还保留了一段未被写过的缓冲区位置，在发送这个Packet之前，会检查Chunksum与Chunk Data之间的缓冲区是否为空白缓冲区（gap），如果有则将Chunk Data部分向前移动，使得Chunk Data 1与Chunk Checksum N相邻，然后才会被发送到DataNode节点hdsf架构：hdfs的构架图网上一堆，抓了一张表述比较清楚的图如下, 主要包含因类角色：Client、NameNode、SecondayNameNode、DataNodeHDFS Client: 系统使用者，调用HDFS API操作文件;与 NN交互获取文件元数据 ;与DN交互进行数据读写, 注意： 写数据时文件 切分由Client完成　Namenode： Master节点（也称元数据节点），是系统唯一的管理者。负责元数据的管理( 名称空间和数据块映射信息 );配置 副本策略 ；处理客户端请求Datanode： 数据存储节点(也称Slave节点)， 存储实际的数据；执行 数据块的读写；汇报存储信息给NNSecondary NameNode： 小弟角色，分担大哥namenode的工作量；是NameNode的冷备份； 合并fsimage和fsedits然后再发给namenode, 注意： 在hadoop 2.x 版本，当启用 hdfs ha 时，将没有这一角色。（详见第二单）解释说明：hdfs构架原则：NameNode:NameNode是整个文件系统的管理节点，也是HDFS中最复杂的一个实体，它维护着HDFS文件系统中最重要的两个关系：第一个关系即目录树、元数据和数据块的索引信息会 持久化到物理存储 中，实现是保存在命名空间的镜像 fsimage 和编辑 日志edits 中， 注意： 在fsimage中， 并没有记录每一个block对应到哪几个Datanodes的对应表信息第二个关系是在NameNode启动后，每个Datanode对本地磁盘进行扫描，将 本Datanode上保存的block信息汇报给Namenode ，Namenode在接收到每个Datanode的块信息汇报后，将接收到的块信息，以及其所在的Datanode信息等保存在内存中。HDFS就是通过这种块信息汇报的方式来 完成 block -> Datanodes list的对应表构建fsimage 记录了自最后一次检查点之前HDFS文件系统中所有目录和文件的序列化信息;edits 是元数据操作日志(记录每次保存fsimage之后到下次保存之间的所有hdfs操作)在NameNode启动时候，会先将fsimage中的文件系统元数据信息 加载到内存 ，然后根据eidts中的记录将内存中的元数据 同步至最新状态， 将这个新版本的 FsImage 从内存中保存到本地磁盘上，然后删除 旧的 Editlog，这个过程称为一个 检查 点 (checkpoint)， 多长时间做一次 checkpoint？（ 见第四章 参数配置 ） checkpoint 能手工触发吗？ 验证重启hdfs服务后editlog没删除呢？类似于 据库中的检查点，为了避免edits日志过大，在Hadoop1.X中，SecondaryNameNode会按照时间阈值（比如24小时）或者edits大小阈值（比如1G），周期性的将fsimage和edits的合并，然后将最新的fsimage推送给NameNode。而在Hadoop2.X中，这个动作是由Standby NameNode来完成 .由此可看出，这两个文件一旦损坏或丢失，将导致整个HDFS文件系统不可用，在HDP2.4安装(五)：集群及组件安装　 集 群安装过程中，hdfs 默认的只能选择一个NN，是否意味着 NN存在单点呢？，2.X版本默认block的大小是 128M （见第四章参数配置）Client将FileA按64M分块。分成两块，block1和Block2;Client向nameNode发送写数据请求，如图蓝色虚线①------>NameNode节点，记录block信息。并返回可用的DataNode ( NameNode按什么规则返回DataNode? 参见第三单 hadoop机架感知 ），如粉色虚线②--------->Block1: host2,host1,host3Block2: host7,host8,host4client向DataNode发送block1；发送过程是以流式写入，流式写入过程如下：将64M的block1按64k的packet划分然后将第一个packet发送给host2host2接收完后，将第一个packet发送给host1，同时client想host2发送第二个packethost1接收完第一个packet后，发送给host3，同时接收host2发来的第二个packet以此类推，如图红线实线所示，直到将block1发送完毕host2,host1,host3向NameNode，host2向Client发送通知，说“消息发送完了”。如图粉红颜色实线所示client收到host2发来的消息后，向namenode发送消息，说我写完了。这样就真完成了。如图黄色粗实线发送完block1后，再向host7，host8，host4发送block2，如图蓝色实线所示 说明：

　小结：写入的过程，按hdsf默认设置， 1T文件，我们需要3T的存储 ， 3T的网络流量在执行读或写的过程中，NameNode和DataNode通过HeartBeat进行保存通信，确定DataNode活着。如果发现DataNode死掉了，就将死掉的DataNode上的数据，放到其他节点去。读取时，要读其他节点去挂掉一个节点，没关系，还有其他节点可以备份；甚至，挂掉某一个机架，也没关系；其他机架上，也有备份hdfs读文件： 读到文件示意图如下：客户端通过调用FileSystem对象的open()方法来打开希望读取的文件，对于HDFS来说，这个对象时分布文件系统的一个实例；DistributedFileSystem通过使用RPC来调用NameNode以确定文件起始块的位置，同一Block按照重复数会返回多个位置，这些位置按照 Hadoop集群拓扑结构排序，距离客户端近的排在前 面 ( 详见第三章 ）前两步会返回一个FSDataInputStream对象，该对象会被封装成DFSInputStream对象，DFSInputStream可以方便的管理datanode和namenode数据流，客户端对这个输入流调用read()方法存储着文件起始块的DataNode地址的DFSInputStream随即连接距离最近的DataNode，通过对数据流反复调用read()方法，将数据从DataNode传输到客户端到达块的末端时，DFSInputStream会关闭与该DataNode的连接，然后寻找下一个块的最佳DataNode，这些操作对客户端来说是透明的，客户端的角度看来只是读一个持续不断的流一旦客户端完成读取，就对FSDataInputStream调用close()方法关闭文件读取block持续化结构: DataNode节点上一个Block持久化到磁盘上的物理存储结构，如下图所示：每个Block文件（如上图中blk_1084013198文件）都对应一个meta文件（如上图中blk_1084013198_10273532.meta文件）， Block文件是一个一个Chunk的二进制数据 （每个Chunk的大小是512字节），而meta文件是与 每一个Chunk对应的Checksum数据 ，是序列化形式存储Loading...