搜索
HadoopHDFSHDFS原理•什么是分布式文件系统和HDFS•HDFS设计目标•HDFS的基本组件•HDFS架构图和工作原理•HDFS服务进程•HDFS的未来发展什么是分布式文件系统•分布式文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。•分布式文件系统的基于客户机/服务器模式。通常，一个分布式文件系统提供多个供用户访问的服务器。•分布式文件系统一般都会提供备份和容错的功能•分布式文件系统一般都基于操作系统的本地文件系统–ext3,ext4–NTFS为什么需要分布式文件系统•传统文件系统最大的问题是容量和吞吐量的限制•多用户多应用的并行读写是分布式文件系统产生的根源–一块硬盘的读写性能，比不上多块硬盘同时读写的性能–1HDD=75MB/sec–1000HDDs=75GB/sec•扩充存储空间的成本低廉•可提供冗余备份•可以为分布式计算提供基础什么是HDFS•HDFS=HadoopDistributedFileSystem•HDFS是一个使用Java实现的、分布式的、可横向扩展的文件系统•是Hadoop的核心组件•基于*nixHDFS设计目标•基于廉价的普通硬件，可以容忍硬件出错–系统中的某一台或几台服务器出现故障的时候，系统仍可用且数据保持完整•大数据集（大文件）–HDFS适合存储大量文件，总存储量可以达到PB,EB级–HDFS适合存储大文件，单个文件大小一般在百MB级之上–文件数目适中•简单的一致性模型–HDFS应用程序需要一次写入，多次读取一个文件的访问模式–支持追加(append)操作，但无法更改已写入数据•顺序的数据流访问–HDFS适合用于处理批量数据，而不适合用于随机定位访问•侧重高吞吐量的数据访问，可以容忍数据访问的高延迟•为把“计算”移动到“数据”提供基础和便利HDFS基本概念•块•元数据•NameNode•DataNode•客户端块(Block)的概念•在传统的块存储介质中，块是读写的最小数据单位(扇区)•传统文件系统基于存储块进行操作–为了节省文件分配表空间，会对物理存储块进行整合，一般大小为4096字节•HDFS也使用了块的概念，但是默认大小设为64M字节–可针对每个文件配置，由客户端指定–每个块有一个自己的全局ID•HDFS将一个文件分为一个或数个块来存储–每个块是一个独立的存储单位–以块为单位在集群服务器上分配存储•与传统文件系统不同的是，如果实际数据没有达到块大小，则并不实际占用磁盘空间–如果一个文件是200M，则它会被分为4个块:64+64+64+8使用块的好处•当一个文件大于集群中任意一个磁盘的时候，文件系统可以充分利用集群中所有的磁盘•管理块使底层的存储子系统相对简单•块更加适合备份，从而为容错和高可用性的实现带来方便块的冗余备份•每个块在集群上会存储多份(replica)–默认复制份数为3–可针对每个文件配置，由客户端指定–可动态修改•某个块的所有备份都是同一个ID–系统无需记录“哪些块其实是同一份数据”•系统可以根据机架的配置自动分配备份位置–第一份在集群的某个机架的某台机器上–其他两份在另外的一个机架的两台机器上•此策略是性能与冗余性的平衡–机架信息需要手工配置HDFS的元数据•元数据包括–文件系统目录树信息•文件名，目录名•文件和目录的从属关系•文件和目录的大小，创建及最后访问时间•权限–文件和块的对应关系•文件由哪些块组成–块的存放位置•机器名，块ID•HDFS对元数据和实际数据采取分别存储的方法–元数据存储在一台指定的服务器上(NameNode)–实际数据储存在集群的其他机器的本地文件系统中(DataNode)NameNode•NameNode是用来管理文件系统命名空间的组件•一个HDFS集群只有一台NameNode–一个HDFS集群只有一个命名空间，一个根目录•NameNode上存放了HDFS的元数据–一个HDFS集群只有一份元数据–目前有单点故障的问题•元数据保存在NameNode的内存当中，以便快速查询–1G内存大致可以存放1,000,000个块对应的元数据信息•按缺省每块64M计算，大致对应64T实际数据DataNode•块的实际数据存放在DataNode上•每个块会在本地文件系统产生两个文件，一个是实际的数据文件，另一个是块的附加信息文件，其中包括数据的校验和，生成时间•DataNode通过心跳包(Heartbeat)与NameNode通讯•客户端读取/写入数据的时候直接与DataNode通信HDFS客户端•需要访问HDFS文件服务的用户或应用•命令行客户端–同一个Hadoop安装包•API客户端–Java库–非POSIX接口–封装了通信细节HDFS架构图元数据的持久化•NameNode里使用两个非常重要的本地文件来保存元数据信息：–fsimage•fsimage里保存了文件系统目录树信息•fsimage里保存了文件和块的对应关系–edits•edits保存文件系统的更改记录(journal)•当客户端对文件进行写操作(包括新建或移动)的时候，操作首先记入edits，成功后才会更改内存中的数据•并不会立刻更改硬盘上的fsimage•块的位置信息并不做持久化元数据的载入和更新•NameNode启动时–通过fsimage读取元数据，载入内存–执行edits中的记录，在内存中生成最新的元数据–清空edits，保存最新的元数据到fsimage–收集DataNode汇报的块的位置信息•NameNode运行时–对文件创建和写操作，记录到edits–更新内存中的元数据–收集DataNode汇报的块的创建和复制信息HDFS创建文件流程•客户端–客户端请求NameNode在命名空间中建立新的文件元信息–如果不能创建文件则NameNode会返回失败•文件已存在•资源不足–如创建成功，客户端得到此文件的写保护锁•NameNode–Namenode检查集群和文件状态–创建写保护锁来保证只有一个客户端在操作该文件–建立该文件的元信息–把创建文件这个事件加入edits–为该文件分配块，以及块的冗余备份位置HDFS写操作流程•客户端写一个文件并不是直接写到HDFS上•HDFS客户端接收用户数据，并把内容缓存在本地•当本地缓存收集足够一个HDFS块大小的时候，客户端同NameNode通讯注册一个新的块•注册块成功后，NameNode会给客户端返回一个DataNode的列表–列表中是该块需要存放的位置，包括冗余备份•客户端向列表中的第一个DataNode写入块–当完成时，第一个DataNode向列表中的下个DataNode发送写操作，并把数据已收到的确认信息给客户端，同时发送确认信息给NameNode–之后的DataNode重复之上的步骤–当列表中所有DataNode都接收到数据并且由最后一个DataNode校验数据正确性完成后，返回确认信息给客户端•收到所有DataNode的确认信息后，客户端删除本地缓存•客户端继续发送下一个块，重复以上步骤•当所有数据发送完成后，写操作完成HDFS写操作流程图HDFS的读操作流程•客户端与NameNode通讯获取文件的块位置信息，其中包括了块的所有冗余备份的位置信息：DataNode的列表•客户端获取文件位置信息后直接同有文件块的DataNode通讯，读取文件•如果第一个DataNode无法连接，客户端将自动联系下一个DataNode•如果块数据的校验值出错，则客户端需要向NameNode报告，并自动联系下一个DataNodeHDFS追加写(append)的操作流程•客户端与NameNode通讯，获得文件的写保护锁及文件最后一个块的位置(DataNode列表)•客户端挑选一个DataNode作为主写入节点，并对其余节点上的该数据块加锁•开始写入数据–与普通写入流程类似，依次更新各个DataNode上的数据•更新时间戳和校验和•最后一个块写满，并且所有备份块都完成写入后，向NameNode申请下一个数据块客户端和HDFS服务器端配置文件的关系•客户端的配置文件名与服务器端相同，字段名也相同•客户端不会从HDFS集群端同步配置文件•客户端只使用部分配置信息–fs.default.name–dfs.block.size–dfs.replication•如果客户端没有配置信息，则使用客户端Hadoop程序包里的缺省值–而不是服务器端的值HDFS的安全性和用户认证•缺省情况下，Hadoop不启用认证–采用客户端系统的登录用户名–或可以通过API设置–从而，虽然HDFS有权限控制，但并没有安全性可言•可以在NameNode上启用用户认证–目前只支持Kerberos–可以与LDAP集成一个特殊的角色:SecondaryNameNode•SecondaryNameNode不是备份节点•SecondaryNameNode的主要的工作是阶段性的合并fsimage和edits文件，以此来控制edits的文件大小在合理的范围–为了缩短集群重启时NameNode重建fsimage的时间–在NameNode硬盘损坏的情况下，SecondaryNameNode也可用作数据恢复，但绝不是全部•一般情况下SecondaryNamenode运行在不同与NameNode的主机上，并且它的内存需求和NameNode是一样的SecondaryNameNode的运行过程•SecondaryNameNode根据配置好的策略决定多久做一次合并–fs.checkpoint.period和fs.checkpoint.size•通知NameNode现在需要回滚edits日志，此时NameNode的新操作将写入新的edits文件•SecondaryNameNode通过HTTP从NameNode取得fsimage和edits•SecondaryNameNode将fsimage载入内存，执行所有edits中的操作，新建新的完整的fsimage•SecondaryNameNode将新的fsimage传回NameNode•NameNode替换为新的fsimage并且记录此checkpoint的时间NameNode与SecondaryNameNodeHDFS服务进程–NameNode–SecondaryNameNode–DataNode–使用jps查看HDFS服务进程24913NameNode16566SecondaryNameNode15744DataNodeHDFS的未来发展•高可用性•多NameNode自治•目前已在2.0Alpha版本中•但还不够成熟，在生产环境使用前需要多做测试HDFS高可用性–HDFS中所有对文件的操作都需要先通过NameNode，如果NameNode出现问题，这个集群将不可用•维护•硬件失效•软件失效•操作失误–解决方案：为NameNode提供备份节点HDFS高可用性的实现方式HDFS高可用性实现细节–把元数据信息存在第三方地点•只需保存fsimage和edits•ActiveNN和StandbyNN通过开源组件ZooKeeper来决定主从•StandbyNN从第三方地点实时读取edits•当ActiveNN失败，切换到StandbyNN时，StandbyNN需要确保读取完所有edits之后才能对外提供服务–块位置信息•Datanode同时汇报给两个NameNode–客户端需要知道有两个NameNode存在•如果ActiveNamenode失效，客户端可以自动的将操作发往Standby节点NameNode的自治(Federation)•NameNode的瓶颈–内存–客户端的并发访问•解决方案–拆分目录树–共享DataNode资源池普通NameNode的架构层次NameNode自治的实现方式HDFS实战•Hadoop运行模式•Hadoop伪分布式安装•HDFS命令行工具•HDFS安全模式•启动、停止HDFS服务•如何查看HDFS日志•如何查看HDFSWeb控制台•HDFS参数配置Hadoop运行模式•单机–在一个Java进程内模拟Hadoop的各个角