大数据技术原理及应用
大数据处理架构—Hadoop 简介
Hadoop 项目包括了很多子项目，结构如下图
原名：Core ，包含HDFS, MapReduce 和其他公共项目，从Hadoop 0.21版本后，HDFS 和MapReduce 分离出去，其余部分内容构成Hadoop Common。Common 为其他子项目提供支持的常用工具，主要包括文件系统、RPC(Remote procedure call) 和串行化库。
Avro 是用于数据序列化的系统。它提供了丰富的数据结构类型、快速可压缩的二进制数据格式、存储持久性数据的文件集、远程调用RPC 的功能和简单的动态语言集成功能。其中，代码生成器既不需要读写文件数据，也不需要使用或实现RPC 协议，它只是一个可选的对静态类型语言的实现。Avro 系统依赖于模式（Schema ）
，Avro 数据的读和写是在模式之下完成的。这样就可以减少写入数据的开销，提高序列化的速度并缩减其大小。
Avro 可以将数据结构或对象转化成便于存储和传输的格式，节约数据存储空间和网络传输带宽，Hadoop 的其他子项目（如HBase 和Hive ）的客户端和服务端之间的数据传输。 HDFS ：是一个分布式文件系统，为
Hadoop 项目两大核心之一，是Google file system（GFS ）的开源实现。由于HDFS 具有高容错性（fault-tolerant ）的特点，所以可以设计部署在低廉（low-cost ）的硬件上。它可以通过提供高吞吐率（high throughput）来访问应用程序的数据，适合那些有着超大数据集的应用程序。HDFS 放宽了可移植操作系统接口（POSIX ，Portable Operating System Interface）的要求，这样就可以实现以流的形式访问文件系统中的数据。
Hadoop MapReduce是针对谷歌MapReduce 的开源实现，它是一种编程模型，用于大规模数据集（大于1TB ）的并行运算。“映射”（map ）、“化简”（
reduce ）等概念和它们的主要思想都是从函数式编程语言中借来的。它使得编程人员在不了解分布式并行编程的情况下也能方便地将自己的程序运行在分布式系统上。MapReduce 在执行时先指定一个map （映射）函数，把输入键值对映射成一组新的键值对，经过一定的处理后交给reduce ，reduce 对相同key 下的所有value 进行处理后再输出键值对作为最终的结果。核心思想就是“分而治之”。 HBase 是一个分布式的、面向列的开源数据库，该技术来源于Google 的论文“Bigtable ：一个结构化数据的分布式存储系统”。如同Bigtable
利用了Google 文件系统（Google File System）提供的分布式数据存储方式一样，HBase 在Hadoop 之上提供了类似于Bigtable 的能力。HBase 不同于一般的关系数据库，其一，HBase 是一个适合于存储非结构化数据的数据库；其二，HBase 是基于列而不是基于行的模式。HBase 和Bigtable 使用相同的数据模型。用户将数据存储在一个表里，一个数据行拥有一个可选择的键和任意数量的列。由于HBase 表示疏松的，用户可以给行定义各种不同的列。HBase 主要用于需要随机访问、实时读写的大数据。 Hive 最早是由Facebook 设计的，是一个建立在Hadoop 基础之上的数据仓库，它提供了一些用于数据整理、特殊查询和分析存储在Hadoop 文件中的数据集的工具。Hive 提供的是一
种结构化数据的机制，它支持类似于传统RDBMS 中的SQL 语言来帮助那些熟悉SQL 的用户查询Hadoop 中的数据，该查询语言称为Hive QL 。与此同时，那些传统的MapReduce 编程人员也可以在Mapper 或Reducer 中通过Hive QL查询数据。Hive 编译器会把Hive QL编译成一组MapReduce
任务，从而方便MapReduce 编程人员进行Hadoop 应用的开发。 Pig 是一个对大型数据集进行分析和评估的平台。Pig 最突出的优势是它的结构能够经受住高度并行化的检验，这个特性让它能够处理大型的数据集。目前，Pig 的底层由一个编译器组成，它在运行的时候会产生一些MapReduce 程序序列，Pig 的语言层由一种叫做Pig Latin的正文型语言组成。
Chukwa 是开源的数据收集系统，用于监控和分析大型分布式系统的数据。Chukwa 是在Hadoop 的HDFS 和MapReduce 框架之上搭建的，它同时继承了Hadoop 的可扩展性和健壮性。Chukwa 通过HDFS 来存储数据，并依赖于MapReduce 任务处理数据。Chukwa 中也附带
了灵活且强大的工具，用于显示、监视和分析数据结果，以便更好地利用所收集的数据。
大数据存储
存储的讲解分为四部分：HDFS, HBase, NoSQL 和云数据库
分布式文件系统简介 相对于传统的本地文件系统而言，分布式文件系统是一种通过网络实现文件在多台计算机上进行分布式存储的文件系统。分布式文件系统的设计一般采用“客户机/服务器”（client/server）模式，客户端以特定的通信协议通过网络与服务器建立连接，提出文件访问请求，客户端和服务器可以通过设置访问权来限制请求方对底层数据存储快的访问。
在我们所熟悉的Windows 、Linux 操作系统中，文件系统一般会把磁盘空间划分为每512字节一组，称为“磁盘块”，它是文件系统读写操作的最小单位，文件系统的块（block ）通常是磁盘块的整数倍，即每次读写的数据量必须是磁盘块大小的整数倍。
分布式文件系统也采用了块的概念，HDFS 默认的一个块的大小为64MB 。与普通文件不同的是，在分布式文件系统中，如果一个文件小于一个数据块的大小，它并不占用整个数据块的存储空间。
分布式文件系统在物理结构上由计算机群中的多个节点构成，这些节点分为两类，一类叫“主节点”（master node）或者也称为“名称节点”（name node），另一类叫“从节点”（slave node ）或者也被称为“数据节点”（data node）。
名称节点负责文件和目录的创建、删除和重命名等，同时管理着数据节点和文件块的映
射关系，因此客户端只有访问名称节点才能找到请求的文件块所在的位置。数据节点负责数据的存储和读取，在存储时，由名称节点分配存储位置，然后由客户端把数据直接写入相应的数据节点；在读取时，客户端从名称节点获得数据节点和文件块的映射关系，然后就可以到相应位置访问文件块。
计算机集群中的节点可能发生故障，因此，为了保障数据的完整性，分布式文件系统通常采用多副本存储。文件块会被复制为多个副本，存储在不同的节点上，而且，存储同一文件块的不同副本节点，会分布在不同机架上。
HDFS 简介
在HDFS 中，名称节点（name node ）负责管理分布式文件系统的命名空间，保存了两个核心的数据结构，即FsImage 和EditLog 。
名称节点
FsImage 用于维护文件系统树以及文件树中所有的文件和文件夹的元数据，操作日志文件EditLog 中记录了所有针对文件的创建、删除、重命名等操作。名称节点记录了每个文件中各个块所在的数据节点的位置信息。
FsImage 文件包含文件系统中所有目录和文件inode 的序列化形式。每个inode 是一个文件或目录的元数据的内部表示，并包含此类信息：文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块。对于目录，则存储修改时间、权限和配额元数据。
FsImage 文件没有记录块存储在哪个数据节点。而是由名称节点把这些映射保留在内存中，当数据节点加入HDFS 集群时，数据节点会把自己所包含的块列表告知给名称节点，此后会定期执行这种告。
在名称节点启动的时候，它会将FsImage 文件中的内容加载到内存中，之后再执行EditLog 文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作。
一旦在内存中成功建立文件系统元数据的映射，则创建一个新的FsImage 文件和一个空的EditLog 文件。
名称节点起来之后， HDFS 中的更新操作会重新写到EditLog 文件中，因为FsImage 文件一般都很大（ GB 级别的很常见），如果所有的更新操作都往FsImage 文件中添加，这样会导致系统运行的十分缓慢，但是，如果往EditLog 文件里面写就不会这样，因为EditLog 要小很多。每次执行写操作之后，且在向客户端发送成功代码之前， edits 文件都需要同步更新。
名称节点运行期间EditLog 不断变大的问题
在名称节点运行期间， HDFS 的所有更新操作都是直接写到EditLog 中，久而久之， EditLog 文件将会变得很大。虽然这对名称节点运行时候是没有什么明显影响的，但是，当名称节点重启的时候，名称节点需要先将FsImage 里面的所有内容映像到内存中，然后再一条一条地执行EditLog 中的记录，当EditLog 文件非常大的时候，会导致名称节点启动操作非常慢，而在这段时间内 HDFS 系统处于安全模式，一直无法对外提供写操作，影响了用户的使用。
如何解决？答案是： SecondaryNameNode 第二名称节点
第二名称节点
第二名称节点是HDFS 架构中的一个组成部分，它是用来保存名称节点中对HDFS 元数据信息的备份，并减少名称节点重启的时间。 SecondaryNameNode 一般是单独运行在一台机器上。
数据节点（ DataNode ）
数据节点是分布式文件系统HDFS 的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表。每个数据节点中的数据会被保存在各自节点的本地Linux 文件系统中。
HDFS 体系结构
HDFS 采用了主从（ Master/Slave）结构模型，一个HDFS 集群包括一个名称节点（ NameNode ）和若干个数据节点（ DataNode ）（如图3-4所示）。名称节点作为中心服务器，负责管理文件系统的命名空间及客户端对文件的访问。集群中的数据节点一般是一个节点运行一个数据节点进程，负责处理文件系统客户端的读/写请求，在名称节点的统一调度下进行数据块的创建、删除和复制等操作。每个数据节点的数据实际上是保存在本地Linux 文件系统中的。
HDFS 的命名空间包含目录、文件和块。在
HDFS1. 0体系结构中，在整个HDFS 集群中只有一个命名空间，并且只有唯一一个名称节点，该节点负责对这个命名空间进行管理。HDFS 使用的是传统的分级文件体系，因此，用户可以像使用普通文件系统一样，创建、删除目录和文件，在目录间转移文件，重命名文件等。
HDFS 是一个部署在集群上的分布式文件系统，因此，很多数据需要通过网络进行传输，所有的HDFS 通信协议都是构建在TCP/IP协议基础之上的，客户端通过一个可配置的端口向名称节点主动发起TCP 连接，并使用客户端协议与名称节点进行交互，名称节点和数据节点之间则使用数据节点协议进行交互，客户端与数据节点的交互是通过RPC （ Remote Procedure Call）来实现的。在设计上，名称节点不会主动发起RPC ，而是响应来自客户端和数据节点的RPC 请求。
客户端是用户操作HDFS 最常用的方式， HDFS 在部署时都提供了客户端。HDFS 客户端是一个库，暴露了 HDFS 文件系统接口，这些接口隐藏了HDFS 实现中的大部分复杂性。严格来说，客户端并不算是HDFS 的一部分，客户端可以支持打开、读取、写入等常见的操作，并且提供了类似Shell 的命令行方式来访问HDFS 中的数据。此外， HDFS 也提供了 Java API，作为应用程序访问文件系统的客户端编程接口。
HDFS 存储管理
HDFS 采用了多副本方式对数据进行冗余存储。
如图3-5所示，数据块1 被分别存放到数据节点A 和C 上，数据块2被存放在数据节点A 和B 上。这种多副本方式具有以下几个优点：
（1） 加快数据传输速度：多个用户同时访问一个文件
（2） 容易检查数据错误：多副本比较
（3） 保证数据可靠性：单点故障不会造成数据损失
HDFS 采取了以机架（Rack ）为基础的数据存放策略。HDFS 默认每个数据节点都是在不同机架上的，这让写入数据的时候不能充分利用同一机架内部机器之间的带宽，但是它有更多优点：
首先获得很高的数据可靠性，即使一个机架发生故障，副本仍可用；
其次，在读取数据的时候，可以在多个机架上并行读取数据；
最后可以更容易实现系统内部负载均衡。
HDFS 提供了一个API 可以确定一个数据节点所属的机架ID ，客户端也可以调用API 获取自己所属的机架ID ，当客户端读取数据时，从名称节点获得数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点，可以调用API 来确定客户端和这些数据节点所属的机架ID ，当发现某个数据块副本对应的机架ID 和客户端对应的机架ID 相同时，就优先选择该副本读取数据，如果没有发现，就随机选择一个副本读取数据。
HDFS 具有较高的容错性，可以兼容廉价的硬件，它把硬件出错看作一种常态，而不是异常，并设计了相应的机制检测数据错误和进行自动恢复，主要包括以下几种情形：名称节点出错、数据节点出错和数据出错。
（1） 名称节点出错
名称节点保存了所有的元数据信息，其中，最核心的两大数据结构是FsImage 和Editlog ，如果这两个文件发生损坏，那么整个HDFS 实例将失效。因此， HDFS 设置了备份机制，把这些核心文件同步复制到备份服务器SecondaryNameNode 上。当名称节点出错时，就可以根据备份服务器SecondaryNameNode 中的FsImage 和Editlog 数据进行恢复。
（2） 数据节点出错
每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态。当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自一些数据节点的心跳信息，
这时，这些数据节点就会被标记为“宕机”，节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何I/O请求。这时，有可能出现一种情形，即由于一些数据节点的不可用，会导致一些数据块的副本数量小于冗余因子，名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗余因子，就会启动数据冗余复制，为它生成新的副本，HDFS
和其它分布式文件系统的最大区别就是可以调整冗余数据的位置。
（3） 数据出错
网络传输和磁盘错误等因素，都会造成数据错误，客户端在读取到数据后，会采用md5和sha1 对数据块进行校验，以确定读取到正确的数据。在文件被创建时，客户端就会对每一个文件块进行信息摘录，并把这些信息写入到同一个路径的隐藏文件里面，当客户端读取文件的时候，会先读取该信息文件，然后，利用该信息文件对每个读取的数据块进行校验，如果校验出错，客户端就会请求到另外一个数据节点读取该文件块，并且向名称节点报告这个文件块有错误，名称节点会定期检查并且重新复制这个块。
HDFS 的数据读写过程
大数据技术原理及应用
大数据处理架构—Hadoop 简介
Hadoop 项目包括了很多子项目，结构如下图
原名：Core ，包含HDFS, MapReduce 和其他公共项目，从Hadoop 0.21版本后，HDFS 和MapReduce 分离出去，其余部分内容构成Hadoop Common。Common 为其他子项目提供支持的常用工具，主要包括文件系统、RPC(Remote procedure call) 和串行化库。
Avro 是用于数据序列化的系统。它提供了丰富的数据结构类型、快速可压缩的二进制数据格式、存储持久性数据的文件集、远程调用RPC 的功能和简单的动态语言集成功能。其中，代码生成器既不需要读写文件数据，也不需要使用或实现RPC 协议，它只是一个可选的对静态类型语言的实现。Avro 系统依赖于模式（Schema ）
，Avro 数据的读和写是在模式之下完成的。这样就可以减少写入数据的开销，提高序列化的速度并缩减其大小。
Avro 可以将数据结构或对象转化成便于存储和传输的格式，节约数据存储空间和网络传输带宽，Hadoop 的其他子项目（如HBase 和Hive ）的客户端和服务端之间的数据传输。 HDFS ：是一个分布式文件系统，为
Hadoop 项目两大核心之一，是Google file system（GFS ）的开源实现。由于HDFS 具有高容错性（fault-tolerant ）的特点，所以可以设计部署在低廉（low-cost ）的硬件上。它可以通过提供高吞吐率（high throughput）来访问应用程序的数据，适合那些有着超大数据集的应用程序。HDFS 放宽了可移植操作系统接口（POSIX ，Portable Operating System Interface）的要求，这样就可以实现以流的形式访问文件系统中的数据。
Hadoop MapReduce是针对谷歌MapReduce 的开源实现，它是一种编程模型，用于大规模数据集（大于1TB ）的并行运算。“映射”（map ）、“化简”（
reduce ）等概念和它们的主要思想都是从函数式编程语言中借来的。它使得编程人员在不了解分布式并行编程的情况下也能方便地将自己的程序运行在分布式系统上。MapReduce 在执行时先指定一个map （映射）函数，把输入键值对映射成一组新的键值对，经过一定的处理后交给reduce ，reduce 对相同key 下的所有value 进行处理后再输出键值对作为最终的结果。核心思想就是“分而治之”。 HBase 是一个分布式的、面向列的开源数据库，该技术来源于Google 的论文“Bigtable ：一个结构化数据的分布式存储系统”。如同Bigtable
利用了Google 文件系统（Google File System）提供的分布式数据存储方式一样，HBase 在Hadoop 之上提供了类似于Bigtable 的能力。HBase 不同于一般的关系数据库，其一，HBase 是一个适合于存储非结构化数据的数据库；其二，HBase 是基于列而不是基于行的模式。HBase 和Bigtable 使用相同的数据模型。用户将数据存储在一个表里，一个数据行拥有一个可选择的键和任意数量的列。由于HBase 表示疏松的，用户可以给行定义各种不同的列。HBase 主要用于需要随机访问、实时读写的大数据。 Hive 最早是由Facebook 设计的，是一个建立在Hadoop 基础之上的数据仓库，它提供了一些用于数据整理、特殊查询和分析存储在Hadoop 文件中的数据集的工具。Hive 提供的是一
种结构化数据的机制，它支持类似于传统RDBMS 中的SQL 语言来帮助那些熟悉SQL 的用户查询Hadoop 中的数据，该查询语言称为Hive QL 。与此同时，那些传统的MapReduce 编程人员也可以在Mapper 或Reducer 中通过Hive QL查询数据。Hive 编译器会把Hive QL编译成一组MapReduce
任务，从而方便MapReduce 编程人员进行Hadoop 应用的开发。 Pig 是一个对大型数据集进行分析和评估的平台。Pig 最突出的优势是它的结构能够经受住高度并行化的检验，这个特性让它能够处理大型的数据集。目前，Pig 的底层由一个编译器组成，它在运行的时候会产生一些MapReduce 程序序列，Pig 的语言层由一种叫做Pig Latin的正文型语言组成。
Chukwa 是开源的数据收集系统，用于监控和分析大型分布式系统的数据。Chukwa 是在Hadoop 的HDFS 和MapReduce 框架之上搭建的，它同时继承了Hadoop 的可扩展性和健壮性。Chukwa 通过HDFS 来存储数据，并依赖于MapReduce 任务处理数据。Chukwa 中也附带
了灵活且强大的工具，用于显示、监视和分析数据结果，以便更好地利用所收集的数据。
大数据存储
存储的讲解分为四部分：HDFS, HBase, NoSQL 和云数据库
分布式文件系统简介 相对于传统的本地文件系统而言，分布式文件系统是一种通过网络实现文件在多台计算机上进行分布式存储的文件系统。分布式文件系统的设计一般采用“客户机/服务器”（client/server）模式，客户端以特定的通信协议通过网络与服务器建立连接，提出文件访问请求，客户端和服务器可以通过设置访问权来限制请求方对底层数据存储快的访问。
在我们所熟悉的Windows 、Linux 操作系统中，文件系统一般会把磁盘空间划分为每512字节一组，称为“磁盘块”，它是文件系统读写操作的最小单位，文件系统的块（block ）通常是磁盘块的整数倍，即每次读写的数据量必须是磁盘块大小的整数倍。
分布式文件系统也采用了块的概念，HDFS 默认的一个块的大小为64MB 。与普通文件不同的是，在分布式文件系统中，如果一个文件小于一个数据块的大小，它并不占用整个数据块的存储空间。
分布式文件系统在物理结构上由计算机群中的多个节点构成，这些节点分为两类，一类叫“主节点”（master node）或者也称为“名称节点”（name node），另一类叫“从节点”（slave node ）或者也被称为“数据节点”（data node）。
名称节点负责文件和目录的创建、删除和重命名等，同时管理着数据节点和文件块的映
射关系，因此客户端只有访问名称节点才能找到请求的文件块所在的位置。数据节点负责数据的存储和读取，在存储时，由名称节点分配存储位置，然后由客户端把数据直接写入相应的数据节点；在读取时，客户端从名称节点获得数据节点和文件块的映射关系，然后就可以到相应位置访问文件块。
计算机集群中的节点可能发生故障，因此，为了保障数据的完整性，分布式文件系统通常采用多副本存储。文件块会被复制为多个副本，存储在不同的节点上，而且，存储同一文件块的不同副本节点，会分布在不同机架上。
HDFS 简介
在HDFS 中，名称节点（name node ）负责管理分布式文件系统的命名空间，保存了两个核心的数据结构，即FsImage 和EditLog 。
名称节点
FsImage 用于维护文件系统树以及文件树中所有的文件和文件夹的元数据，操作日志文件EditLog 中记录了所有针对文件的创建、删除、重命名等操作。名称节点记录了每个文件中各个块所在的数据节点的位置信息。
FsImage 文件包含文件系统中所有目录和文件inode 的序列化形式。每个inode 是一个文件或目录的元数据的内部表示，并包含此类信息：文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块。对于目录，则存储修改时间、权限和配额元数据。
FsImage 文件没有记录块存储在哪个数据节点。而是由名称节点把这些映射保留在内存中，当数据节点加入HDFS 集群时，数据节点会把自己所包含的块列表告知给名称节点，此后会定期执行这种告。
在名称节点启动的时候，它会将FsImage 文件中的内容加载到内存中，之后再执行EditLog 文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作。
一旦在内存中成功建立文件系统元数据的映射，则创建一个新的FsImage 文件和一个空的EditLog 文件。
名称节点起来之后， HDFS 中的更新操作会重新写到EditLog 文件中，因为FsImage 文件一般都很大（ GB 级别的很常见），如果所有的更新操作都往FsImage 文件中添加，这样会导致系统运行的十分缓慢，但是，如果往EditLog 文件里面写就不会这样，因为EditLog 要小很多。每次执行写操作之后，且在向客户端发送成功代码之前， edits 文件都需要同步更新。
名称节点运行期间EditLog 不断变大的问题
在名称节点运行期间， HDFS 的所有更新操作都是直接写到EditLog 中，久而久之， EditLog 文件将会变得很大。虽然这对名称节点运行时候是没有什么明显影响的，但是，当名称节点重启的时候，名称节点需要先将FsImage 里面的所有内容映像到内存中，然后再一条一条地执行EditLog 中的记录，当EditLog 文件非常大的时候，会导致名称节点启动操作非常慢，而在这段时间内 HDFS 系统处于安全模式，一直无法对外提供写操作，影响了用户的使用。
如何解决？答案是： SecondaryNameNode 第二名称节点
第二名称节点
第二名称节点是HDFS 架构中的一个组成部分，它是用来保存名称节点中对HDFS 元数据信息的备份，并减少名称节点重启的时间。 SecondaryNameNode 一般是单独运行在一台机器上。
数据节点（ DataNode ）
数据节点是分布式文件系统HDFS 的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表。每个数据节点中的数据会被保存在各自节点的本地Linux 文件系统中。
HDFS 体系结构
HDFS 采用了主从（ Master/Slave）结构模型，一个HDFS 集群包括一个名称节点（ NameNode ）和若干个数据节点（ DataNode ）（如图3-4所示）。名称节点作为中心服务器，负责管理文件系统的命名空间及客户端对文件的访问。集群中的数据节点一般是一个节点运行一个数据节点进程，负责处理文件系统客户端的读/写请求，在名称节点的统一调度下进行数据块的创建、删除和复制等操作。每个数据节点的数据实际上是保存在本地Linux 文件系统中的。
HDFS 的命名空间包含目录、文件和块。在
HDFS1. 0体系结构中，在整个HDFS 集群中只有一个命名空间，并且只有唯一一个名称节点，该节点负责对这个命名空间进行管理。HDFS 使用的是传统的分级文件体系，因此，用户可以像使用普通文件系统一样，创建、删除目录和文件，在目录间转移文件，重命名文件等。
HDFS 是一个部署在集群上的分布式文件系统，因此，很多数据需要通过网络进行传输，所有的HDFS 通信协议都是构建在TCP/IP协议基础之上的，客户端通过一个可配置的端口向名称节点主动发起TCP 连接，并使用客户端协议与名称节点进行交互，名称节点和数据节点之间则使用数据节点协议进行交互，客户端与数据节点的交互是通过RPC （ Remote Procedure Call）来实现的。在设计上，名称节点不会主动发起RPC ，而是响应来自客户端和数据节点的RPC 请求。
客户端是用户操作HDFS 最常用的方式， HDFS 在部署时都提供了客户端。HDFS 客户端是一个库，暴露了 HDFS 文件系统接口，这些接口隐藏了HDFS 实现中的大部分复杂性。严格来说，客户端并不算是HDFS 的一部分，客户端可以支持打开、读取、写入等常见的操作，并且提供了类似Shell 的命令行方式来访问HDFS 中的数据。此外， HDFS 也提供了 Java API，作为应用程序访问文件系统的客户端编程接口。
HDFS 存储管理
HDFS 采用了多副本方式对数据进行冗余存储。
如图3-5所示，数据块1 被分别存放到数据节点A 和C 上，数据块2被存放在数据节点A 和B 上。这种多副本方式具有以下几个优点：
（1） 加快数据传输速度：多个用户同时访问一个文件
（2） 容易检查数据错误：多副本比较
（3） 保证数据可靠性：单点故障不会造成数据损失
HDFS 采取了以机架（Rack ）为基础的数据存放策略。HDFS 默认每个数据节点都是在不同机架上的，这让写入数据的时候不能充分利用同一机架内部机器之间的带宽，但是它有更多优点：
首先获得很高的数据可靠性，即使一个机架发生故障，副本仍可用；
其次，在读取数据的时候，可以在多个机架上并行读取数据；
最后可以更容易实现系统内部负载均衡。
HDFS 提供了一个API 可以确定一个数据节点所属的机架ID ，客户端也可以调用API 获取自己所属的机架ID ，当客户端读取数据时，从名称节点获得数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点，可以调用API 来确定客户端和这些数据节点所属的机架ID ，当发现某个数据块副本对应的机架ID 和客户端对应的机架ID 相同时，就优先选择该副本读取数据，如果没有发现，就随机选择一个副本读取数据。
HDFS 具有较高的容错性，可以兼容廉价的硬件，它把硬件出错看作一种常态，而不是异常，并设计了相应的机制检测数据错误和进行自动恢复，主要包括以下几种情形：名称节点出错、数据节点出错和数据出错。
（1） 名称节点出错
名称节点保存了所有的元数据信息，其中，最核心的两大数据结构是FsImage 和Editlog ，如果这两个文件发生损坏，那么整个HDFS 实例将失效。因此， HDFS 设置了备份机制，把这些核心文件同步复制到备份服务器SecondaryNameNode 上。当名称节点出错时，就可以根据备份服务器SecondaryNameNode 中的FsImage 和Editlog 数据进行恢复。
（2） 数据节点出错
每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态。当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自一些数据节点的心跳信息，
这时，这些数据节点就会被标记为“宕机”，节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何I/O请求。这时，有可能出现一种情形，即由于一些数据节点的不可用，会导致一些数据块的副本数量小于冗余因子，名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗余因子，就会启动数据冗余复制，为它生成新的副本，HDFS
和其它分布式文件系统的最大区别就是可以调整冗余数据的位置。
（3） 数据出错
网络传输和磁盘错误等因素，都会造成数据错误，客户端在读取到数据后，会采用md5和sha1 对数据块进行校验，以确定读取到正确的数据。在文件被创建时，客户端就会对每一个文件块进行信息摘录，并把这些信息写入到同一个路径的隐藏文件里面，当客户端读取文件的时候，会先读取该信息文件，然后，利用该信息文件对每个读取的数据块进行校验，如果校验出错，客户端就会请求到另外一个数据节点读取该文件块，并且向名称节点报告这个文件块有错误，名称节点会定期检查并且重新复制这个块。
HDFS 的数据读写过程