| 编辑推荐: |
本文首先介绍一下分布式的相关概念和知识，然后介绍HDFS的架构与组成，接着会详细分析HDFS读写数据的过程与元数据的管理，最后会总结操作HDFS文件的方式。
本文来自csdn，由火龙果软件Anna编辑、推荐。 |
|
hdfs全程是Hadoop Distributed File System，是一个分布式文件系统。
分布式 分布式是近几年非常火的技术概念，无论是云计算、大数据还是高并发的互联网架构话题都会频频出现这个词语，特别是这个大谈“大规模”的时代，分布式貌似成了高大上技术的代名词。引的许多刚入行的技术人员趋之若鹜，其实世界上不会有凭空出现的事物，都是慢慢演化的，新事物一定可以找到旧事物的影子。只要打好基础，抓住技术演进的主线，结合实践慢慢积累就可以了。但是话又说回来，分布式系统确实在实现上难度上确实要高于一般的业务系统，门槛也要高一些。
那么我们就先看看“一般的”分布式系统需要解决那些问题、这些问题的通用解决方案和特性。限于篇幅，如要深入了解某个协议和算法请参考相关文献。
1.定义
分布式系统会划分成多个子系统或模块，各自运行在不同的机器上，子系统或模块之间通过网络通信进行协作，实现最终的整体功能。比如分布式操作系统、分布式程序设计语言及其编译(解释)系统、分布式文件系统和分布式数据库系统等。利用多个节点共同协作完成一项或多项具体业务功能的系统就是分布式系统。
举例：SolrCloud
A. 一个solrcloud集群通常有多台solr服务器
B. 每一个solr服务器节点负责存储整个索引库的若干个shard（数据分片）
C. 每一个shard又有多台服务器存放若干个副本互为主备用
D. 索引的建立和查询会在整个集群的各个节点上并发执行
E. SolrCloud集群作为整体对外服务，而其内部细节可对客户端透明
2.问题及方案
1）CAP的权衡
分布式领域有一个非常著名的CAP理论，是由 Eric Brewer 提出的分布式系统中最为重要的理论之一。其定义很好理解，CAP
三个字母分别代表了分布式系统中三个相互矛盾的属性。CAP分别代表Consistency、Availiablity、Tolerance
to the partition of network即一致性、可用性、网络分区容忍性。
一致性（Consistency）：在CAP理论中的一致性是强一致性，即每个节点上的数据时刻保持一致。
可用性（Availiablity）：是指分布式系统在出现异常情况的时候的可用度。
分区容忍性（Tolerance…）：是指分布式系统对网络分区的容错度。
CAP 理论指出：无法设计一种分布式协议，使得同时完全具备 CAP 三个属性，即该种协议下的副本始终是强一致性&服务始终是可用的&协议可以容忍任何网络分区异常；分布式系统协议只能在
CAP 这三者间所有折中。
CAP折中的实现可以体现在分布式协议中：
a. Lease 机制牺牲了部分异常情况下的 A，从而获得了完全的 C 与很好的 P。
b. Quorum 机制，即总共有 N 个副本，成功更新 W 个副本则算成功提交，读取时读 R 个副本。这种一般的
Quorum 机制，在 CAP 三大因素中都各做了折中，有一定的 C，有较好的 A，也有较好的 P，是一种较为平衡的分布式协议。
c. 两阶段提交系统具有完全的 C，很不好 A，很不好 P。
d. Paxos 协议具有完全的 C，较好的 A，较好的 P。
2）负载均衡
在某些有多个节点的分布式系统中需要对服务请求进行负载均衡，根据业务需求的不同也可以使用不同的负载均衡算法，例如一致性Hash。
3）高并发
有些分布式系统对并发性有很高的要求，通常是使用MVCC:Multiversion concurrency
control，多版本并发控制技术。本质是使用COW+Version+CAS这个技术组合来提升系统并发性。
HDFS的架构与设计 分布式服务主要有分布式存储、计算、协调服务，HDFS是作为最底层的分布式存储服务而存在的，是Hadoop的分布式文件系统组件，它与现有的分布式文件系统有很多相似之处。然而与其他的分布式文件系统的差异也是显着的。HDFS是高容错的，被设计成在低成本硬件上部署。HDFS为应用数据提供高吞吐量的访问，适用于具有大规模数据集的应用程序。HDFS放松了一些POSIX的要求，以便提供流式方式来访问文件系统数据。HDFS的最初是作为Apache
Nutch网络搜索引擎项目的基础。目前HDFS是一个Apache Hadoop的子项目。
1.HDFS设计目标
1）硬件错误是常态，而非异常情况，HDFS可能是有成百上千的server组成，任何一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是HDFS的核心架构目标。
2）跑在HDFS上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。
3）HDFS以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至T字节，一个单一HDFS实例应该能支撑数以千万计的文件。
4）HDFS应用对文件要求的是write-one-read-many访问模型。一个文件经过创建、写，关闭之后就不需要改变。这一假设简化了数据一致性问
题，使高吞吐量的数据访问成为可能。典型的如MapReduce框架，或者一个web crawler应用都很适合这个模型。
5）移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好，HDFS提供给应用这样的接口。
6）在异构的硬件和软件平台上的可移植性。
2.HDFS核心组件-NameNode和DataNode
HDFS采用master/slave架构。一个HDFS集群是有一个Namenode和一定数目的Datanode组成。Namenode是一个中心服务器，负责管理文件系统的namespace和客户端对文件的访问。Datanode在集群中一般是一个节点一个，负责管理节点上它们附带的存储。在内部，一个文件其实分成一个或多个block，这些block存储在Datanode集合里。Namenode执行文件系统的namespace操作，例如打开、关闭、重命名文件和目录，同时决定block到具体Datanode节点的映射。Datanode在Namenode的指挥下进行block的创建、删除和复制。Namenode和Datanode都是设计成可以跑在普通的廉价的运行Linux的机器上。HDFS采用java语言开发，因此可以部署在很大范围的机器上。一个典型的部署场景是一台机器跑一个单独的Namenode节点，集群中的其他机器各跑一个Datanode实例。这个架构并不排除一台机器上跑多个Datanode，不过这比较少见。集群中单一Namenode的结构大大简化了系统的架构。Namenode是所有HDFS元数据的仲裁者和管理者，这样，用户数据永远不会流过Namenode。
HDFS架构图：
3.名字空间（NameSpace）
HDFS支持传统的层次型文件组织结构。用户或者应用程序可以创建目录，然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似：用户可以创建、删除、移动或重命名文件。当前，HDFS不支持用户磁盘配额和访问权限控制，也不支持硬链接和软链接。但是HDFS架构并不妨碍实现这些特性。Namenode负责维护文件系统的名字空间，任何对文件系统名字空间或属性的修改都将被Namenode记录下来。应用程序可以设置HDFS保存的文件的副本数目。文件副本的数目称为文件的副本系数，这个信息也是由Namenode保存的。
4.通信协议
所有的HDFS通讯协议都是建立在TCP/IP协议之上。客户端通过一个可配置的TCP端口连接到Namenode，通过ClientProtocol协议与Namenode交互。而Datanode使用DatanodeProtocol协议与Namenode交互。一个远程过程调用(RPC)模型被抽象出来封装ClientProtocol和Datanodeprotocol协议。在设计上，Namenode不会主动发起RPC，而是响应来自客户端或
Datanode 的RPC请求。
5.数据完整性和数据错误（心跳检测和重新复制）
每个Datanode节点周期性地向Namenode发送心跳信号。网络分区可能导致一部分Datanode跟Namenode失去联系。Namenode通过心跳信号的缺失来检测这一情况，并将这些近期不再发送心跳信号Datanode标记为宕机，不会再将新的IO请求发给它们。任何存储在宕机Datanode上的数据将不再有效。Datanode的宕机可能会引起一些数据块的副本系数低于指定值，Namenode不断地检测这些需要复制的数据块，一旦发现就启动复制操作。在下列情况下，可能需要重新复制：某个Datanode节点失效，某个副本遭到损坏，Datanode上的硬盘错误，或者文件的副本系数增大。
从某个Datanode获取的数据块有可能是损坏的，损坏可能是由Datanode的存储设备错误、网络错误或者软件bug造成的。HDFS客户端软件实现了对HDFS文件内容的校验和(checksum)检查。当客户端创建一个新的HDFS文件，会计算这个文件每个数据块的校验和，并将校验和作为一个单独的隐藏文件保存在同一个HDFS名字空间下。当客户端获取文件内容后，它会检验从Datanode获取的数据跟相应的校验和文件中的校验和是否匹配，如果不匹配，客户端可以选择从其他Datanode获取该数据块的副本。
6.数据块&客户端缓存&流水线复制
HDFS被设计成支持大文件，适用HDFS的是那些需要处理大规模的数据集的应用。这些应用都是只写入数据一次，但却读取一次或多次，并且读取速度应能满足流式读取的需要。HDFS支持文件的“一次写入多次读取”语义。一个典型的数据块大小是64MB。因而，HDFS中的文件总是按照64M被切分成不同的块，每个块尽可能地存储于不同的Datanode中。
客户端创建文件的请求其实并没有立即发送给Namenode，事实上，在刚开始阶段HDFS客户端会先将文件数据缓存到本地的一个临时文件。应用程序的写操作被透明地重定向到这个临时文件。当这个临时文件累积的数据量超过一个数据块的大小，客户端才会联系Namenode。Namenode将文件名插入文件系统的层次结构中，并且分配一个数据块给它。然后返回Datanode的标识符和目标数据块给客户端。接着客户端将这块数据从本地临时文件上传到指定的Datanode上。当文件关闭时，在临时文件中剩余的没有上传的数据也会传输到指定的Datanode上。然后客户端告诉Namenode文件已经关闭。此时Namenode才将文件创建操作提交到日志里进行存储。如果Namenode在文件关闭前宕机了，则该文件将丢失。上述方法是对在HDFS上运行的目标应用进行认真考虑后得到的结果。这些应用需要进行文件的流式写入。如果不采用客户端缓存，由于网络速度和网络堵塞会对吞估量造成比较大的影响。
当客户端向HDFS文件写入数据的时候，一开始是写到本地临时文件中。假设该文件的副本系数设置为3，当本地临时文件累积到一个数据块的大小时，客户端会从Namenode获取一个Datanode列表用于存放副本。然后客户端开始向第一个Datanode传输数据，第一个Datanode一小部分一小部分(4
KB)地接收数据，将每一部分写入本地仓库，并同时传输该部分到列表中第二个Datanode节点。第二个Datanode也是这样，一小部分一小部分地接收数据，写入本地仓库，并同时传给第三个Datanode。最后，第三个Datanode接收数据并存储在本地。因此，Datanode能流水线式地从前一个节点接收数据，并在同时转发给下一个节点，数据以流水线的方式从前一个Datanode复制到下一个。
HDFS的基础特性 HDFS是一个文件系统，用于存储和管理文件，通过统一的命名空间（类似于本地文件系统的目录树）。是分布式的，服务器集群中各个节点都有自己的角色和职责。
1.HDFS中的文件在物理上是分块存储（block），块的大小可以通过配置参数( dfs.blocksize)来规定，默认大小在hadoop2.x版本中是128M，之前的版本中是64M。
2.HDFS文件系统会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件，形如：
hdfs://namenode:port /dir-a/dir-b/dir-c/file.data
3.**目录结构及文件分块位置信息(元数据)**的管理由namenode节点承担，namenode是HDFS集群主节点，负责维护整个hdfs文件系统的目录树，以及每一个路径（文件）所对应的数据块信息（blockid及所在的datanode服务器）
4.文件的各个block的存储管理由datanode节点承担，datanode是HDFS集群从节点，每一个block都可以在多个datanode上存储多个副本（副本数量也可以通过参数设置dfs.replication，默认是3）
5.Datanode会定期向Namenode汇报自身所保存的文件block信息，而namenode则会负责保持文件的副本数量，HDFS的内部工作机制对客户端保持透明，客户端请求访问HDFS都是通过向namenode申请来进行。
6.HDFS是设计成适应一次写入，多次读出的场景，且不支持文件的修改。需要频繁的RPC交互，写入性能不好。
HDFS组成部分 namenode 和 datanode 构成主从结构。
namenode负责存储文件的元数据信息，包括一个文件的block块的位置信息。
datanode负责存储文件的具体block数据。
datanode会向namenode汇报文件块信息，并且遵从心跳检测协议。
为了防止namenode挂掉，会存在一个secondarynamenode进程，负责备份namenode上的元数据信息。
hdfs结构图：
HDFS数据读写与元数据管理
HDFS写数据分析
1. 概述 客户端要向HDFS写数据，首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode，然后客户端按顺序将文件逐个block传递给相应datanode，并由接收到block的datanode负责向其他datanode复制block的副本。
2. 写数据步骤详解
1）客户端向namenode发送上传文件请求，namenode对要上传目录和文件进行检查，判断是否可以上传，并向客户端返回检查结果。
2）客户端得到上传文件的允许后读取客户端配置，如果没有指定配置则会读取默认配置（例如副本数和块大小默认为3和128M，副本是由客户端决定的）。向namenode请求上传一个数据块。
3）namenode会根据客户端的配置来查询datanode信息，如果使用默认配置，那么最终结果会返回同一个机架的两个datanode和另一个机架的datanode。这称为“机架感知”策略。
机架感知：HDFS采用一种称为机架感知(rack-aware)的策略来改进数据的可靠性、可用性和网络带宽的利用率。大型HDFS实例一般运行在跨越多个机架的计算机组成的集群上，不同机架上的两台机器之间的通讯需要经过交换机。在大多数情况下，同一个机架内的两台机器间的带宽会比不同机架的两台机器间的带宽大。通过一个机架感知的过程，Namenode可以确定每个Datanode所属的机架id。一个简单但没有优化的策略就是将副本存放在不同的机架上。这样可以有效防止当整个机架失效时数据的丢失，并且允许读数据的时候充分利用多个机架的带宽。这种策略设置可以将副本均匀分布在集群中，有利于当组件失效情况下的负载均衡。但是，因为这种策略的一个写操作需要传输数据块到多个机架，这增加了写的代价。在大多数情况下，副本系数是3，HDFS的存放策略是将一个副本存放在本地机架的节点上，一个副本放在同一机架的另一个节点上，最后一个副本放在不同机架的节点上。这种策略减少了机架间的数据传输，这就提高了写操作的效率。机架的错误远远比节点的错误少，所以这个策略不会影响到数据的可靠性和可用性。于此同时，因为数据块只放在两个（不是三个）不同的机架上，所以此策略减少了读取数据时需要的网络传输总带宽。在这种策略下，副本并不是均匀分布在不同的机架上。三分之一的副本在一个节点上，三分之二的副本在一个机架上，其他副本均匀分布在剩下的机架中，这一策略在不损害数据可靠性和读取性能的情况下改进了写的性能。
4）客户端在开始传输数据块之前会把数据缓存在本地，当缓存大小超过了一个数据块的大小，客户端就会从namenode获取要上传的datanode列表。之后会在客户端和第一个datanode建立连接开始流式的传输数据，这个datanode会一小部分一小部分（4K）的接收数据然后写入本地仓库，同时会把这些数据传输到第二个datanode，第二个datanode也同样一小部分一小部分的接收数据并写入本地仓库，同时传输给第三个datanode，依次类推。这样逐级调用和返回之后，待这个数据块传输完成客户端后告诉namenode数据块传输完成，这时候namenode才会更新元数据信息记录操作日志。
5）第一个数据块传输完成后会使用同样的方式传输下面的数据块直到整个文件上传完成。
细节 a.请求和应答是使用RPC的方式，客户端通过ClientProtocol与namenode通信，namenode和datanode之间使用DatanodeProtocol交互。在设计上，namenode不会主动发起RPC，而是响应来自客户端或
datanode 的RPC请求。客户端和datanode之间是使用socket进行数据传输，和namenode之间的交互采用nio封装的RPC。
b.HDFS有自己的序列化协议。
c.在数据块传输成功后但客户端没有告诉namenode之前如果namenode宕机那么这个数据块就会丢失。
d.在流式复制时，逐级传输和响应采用响应队列来等待传输结果。队列响应完成后返回给客户端。
c.在流式复制时如果有一台或两台（不是全部）没有复制成功，不影响最后结果，只不过datanode会定期向namenode汇报自身信息。如果发现异常namenode会指挥datanode删除残余数据和完善副本。如果副本数量少于某个最小值就会进入安全模式。
安全模式：Namenode启动后会进入一个称为安全模式的特殊状态。处于安全模式的Namenode是不会进行数据块的复制的。Namenode从所有的
Datanode接收心跳信号和块状态报告。块状态报告包括了某个Datanode所有的数据块列表。每个数据块都有一个指定的最小副本数。当Namenode检测确认某个数据块的副本数目达到这个最小值，那么该数据块就会被认为是副本安全(safely
replicated)的；在一定百分比（这个参数可配置）的数据块被Namenode检测确认是安全之后（加上一个额外的30秒等待时间），Namenode将退出安全模式状态。接下来它会确定还有哪些数据块的副本没有达到指定数目，并将这些数据块复制到其他Datanode上。
HDFS读数据分析
1.概述 客户端将要读取的文件路径发送给namenode，namenode获取文件的元信息（主要是block的存放位置信息）返回给客户端，客户端根据返回的信息找到相应datanode逐个获取文件的block并在客户端本地进行数据追加合并从而获得整个文件。
2.读数据步骤详解
1）客户端向namenode发起RPC调用，请求读取文件数据。
2）namenode检查文件是否存在，如果存在则获取文件的元信息（blockid以及对应的datanode列表）。
3）客户端收到元信息后选取一个网络距离最近的datanode，依次请求读取每个数据块。客户端首先要校检文件是否损坏，如果损坏，客户端会选取另外的datanode请求。
4）datanode与客户端简历socket连接，传输对应的数据块，客户端收到数据缓存到本地，之后写入文件。
5）依次传输剩下的数据块，直到整个文件合并完成。
从某个Datanode获取的数据块有可能是损坏的，损坏可能是由Datanode的存储设备错误、网络错误或者软件bug造成的。HDFS客户端软件实现了对HDFS文件内容的校验和(checksum)检查。当客户端创建一个新的HDFS文件，会计算这个文件每个数据块的校验和，并将校验和作为一个单独的隐藏文件保存在同一个HDFS名字空间下。当客户端获取文件内容后，它会检验从Datanode获取的数据跟相应的校验和文件中的校验和是否匹配，如果不匹配，客户端可以选择从其他Datanode获取该数据块的副本。
HDFS删除数据分析
HDFS删除数据比较流程相对简单，只列出详细步骤:
1）客户端向namenode发起RPC调用，请求删除文件。namenode检查合法性。
2）namenode查询文件相关元信息，向存储文件数据块的datanode发出删除请求。
3）datanode删除相关数据块。返回结果。
4）namenode返回结果给客户端。
当用户或应用程序删除某个文件时，这个文件并没有立刻从HDFS中删除。实际上，HDFS会将这个文件重命名转移到/trash目录。只要文件还在/trash目录中，该文件就可以被迅速地恢复。文件在/trash中保存的时间是可配置的，当超过这个时间时，Namenode就会将该文件从名字空间中删除。删除文件会使得该文件相关的数据块被释放。注意，从用户删除文件到HDFS空闲空间的增加之间会有一定时间的延迟。只要被删除的文件还在/trash目录中，用户就可以恢复这个文件。如果用户想恢复被删除的文件，他/她可以浏览/trash目录找回该文件。/trash目录仅仅保存被删除文件的最后副本。/trash目录与其他的目录没有什么区别，除了一点：在该目录上HDFS会应用一个特殊策略来自动删除文件。目前的默认策略是删除/trash中保留时间超过6小时的文件。将来，这个策略可以通过一个被良好定义的接口配置。
当一个文件的副本系数被减小后，Namenode会选择过剩的副本删除。下次心跳检测时会将该信息传递给Datanode。Datanode遂即移除相应的数据块，集群中的空闲空间加大。同样，在调用setReplication
API结束和集群中空闲空间增加间会有一定的延迟。
NameNode元数据管理原理分析
1.概述 首先明确namenode的职责：响应客户端请求、管理元数据。
namenode对元数据有三种存储方式：
内存元数据(NameSystem)
磁盘元数据镜像文件
数据操作日志文件（可通过日志运算出元数据）
细节：HDFS不适合存储小文件的原因，每个文件都会产生元信息，当小文件多了之后元信息也就多了，对namenode会造成压力。
2.对三种存储机制的进一步解释 内存元数据就是当前namenode正在使用的元数据，是存储在内存中的。
磁盘元数据镜像文件是内存元数据的镜像，保存在namenode工作目录中，它是一个准元数据，作用是在namenode宕机时能够快速较准确的恢复元数据。称为fsimage。
数据操作日志文件是用来记录元数据操作的，在每次改动元数据时都会追加日志记录，如果有完整的日志就可以还原完整的元数据。主要作用是用来完善fsimage，减少fsimage和内存元数据的差距。称为editslog。
3.checkpoint机制分析 因为namenode本身的任务就非常重要，为了不再给namenode压力，日志合并到fsimage就引入了另一个角色secondarynamenode。secondarynamenode负责定期把editslog合并到fsimage，“定期”是namenode向secondarynamenode发送RPC请求的，是按时间或者日志记录条数为“间隔”的，这样即不会浪费合并操作又不会造成fsimage和内存元数据有很大的差距。因为元数据的改变频率是不固定的。
每隔一段时间，会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程称为checkpoint）。
1）namenode向secondarynamenode发送RPC请求，请求合并editslog到fsimage。
2）secondarynamenode收到请求后从namenode上读取（通过http服务）editslog（多个，滚动日志文件）和fsimage文件。
3）secondarynamenode会根据拿到的editslog合并到fsimage。形成最新的fsimage文件。（中间有很多步骤，把文件加载到内存，还原成元数据结构，合并，再生成文件，新生成的文件名为fsimage.checkpoint）。
4）secondarynamenode通过http服务把fsimage.checkpoint文件上传到namenode，并且通过RPC调用把文件改名为fsimage。
namenode和secondary namenode的工作目录存储结构完全相同，所以，当namenode故障退出需要重新恢复时，可以从secondary
namenode的工作目录中将fsimage拷贝到namenode的工作目录，以恢复namenode的元数据。
关于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之间最大的操作记录
editslog和fsimage文件存储在$dfs.namenode.name.dir /current目录下，这个目录可以在hdfs-site.xml中配置的。这个目录下的文件结构如下：
包括edits日志文件（滚动的多个文件），有一个是edits_inprogress_*是当前正在写的日志。fsimage文件以及md5校检文件。seen_txid是记录当前滚动序号，代表seen_txid之前的日志都已经合并完成。
$dfs.namenode.name.dir/current/seen_txid非常重要，是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾数，namenode重启的时候，会按照seen_txid的数字恢复。所以当你的hdfs发生异常重启的时候，一定要比对seen_txid内的数字是不是你edits最后的尾数，不然会发生重启namenode时metaData的资料有缺少，导致误删Datanode上多余Block的信息。
操作HDFS文件的方式
命令行 使用hadoop fs <command>命令就可以操作hdfs文件系统上的文件，command和linux本文文件系统的上面的命令类似。
例如，查看文件信息：
其实还可以使用另外一种格式：
效果都是一样的
webUI 还可以访问namenode所在节点的网页进行访问。默认网址是http://master:50070/。选择浏览文件系统就可以了。
编程API方式 还可以通过编程API的方式访问hdfs上的文件，重点掌握通过java访问。
总结 虽然大部分内容都是从网上参看的，但是也是自己的一个学习过程，自己算是清楚了解HDFS的基础组成与特性，看到namenode/current/下的目录结构时也不会那么的茫然了。
|
