Hadoop Operations(Hadoop操作) 详解(二) HDFS

Hadoop Operations(Hadoop操作) 详解(二) HDFS

Goals and Motivation(目的和方向)

        Apache Hadoop的前半部分是一种称为Hadoop分布式文件系统或简单的HDFS的文件系统。 HDFS是为了支持高吞吐量、流读和写超大文件而构建的。 传统的大型存储区域网络(san)和网络附加存储(NAS)提供集中的、低延迟的访问，可以以tb级的大小来访问块设备或文件系统。 这些系统非常棒，因为它们支持关系数据库、内容交付系统和类似类型的数据存储需求，因为它们可以支持全功能的POSIX语义、规模以满足这些系统的大小要求，并提供低延迟的数据访问。 但是，想象一下，成百上千的机器同时在同一时间起床，同时从一个集中的存储系统中拉出数百兆兆字节的数据。 这就是传统存储不需要扩展的地方。

        通过创建一个系统组成的独立的机器,每个都有自己的I / O子系统、磁盘、内存、网络接口、和cpu和放松(有时是删除)的一些POSIX需求,可以构建一个系统优化,性能和成本,对我们感兴趣的特定类型的工作负载。对于HDFS有很多具体的目标:

• 存储数以百万计的大型文件，每个文件的大小都超过了几十gb，文件系统的大小也达到了几十个pb。
• 使用带有内部JBOD(“仅仅是一堆磁盘”)的廉价商品服务器，而不是RAID来实现大规模的存储。通过应用程序级的数据复制来完成可用性和高吞吐量。
• 对大量的、流媒体的读和写进行优化，而不是对许多小文件的低延迟访问。批处理性能比交互式响应时间更重要。
• 优雅地处理机器和磁盘的组件故障。.
• 支持MapReduce处理的功能和规模需求。

        虽然HDFS可以独立使用MapReduce来存储大型数据集，但是当它们一起使用时，它确实会发光。例如，MapReduce利用了HDFS中的数据是如何被分割成块的，并将计算推到可以在本地读取块的机器上。

Design(设计)

       在许多方面，HDFS都遵循传统的文件系统设计。文件以不透明的块和元数据的形式存在，这些元数据可以跟踪文件名以阻止映射、目录树结构、权限等等。这类似于常见的Linux文件系统，如ext3。那么，HDFS有什么不同呢?

        传统的文件系统是作为内核模块(至少在Linux中)实现的，并且与userland工具一起使用，可以对终端用户进行安装和使用。HDFS就是所谓的用户空间文件系统。这是一种很奇特的说法，即文件系统代码在内核之外运行，作为OS进程，并且通过扩展，没有通过Linux VFS层注册或公开。虽然这样做更简单、更灵活、更安全，但这意味着您不会像ext3那样挂载HDFS，而且它要求应用程序显式地为其构建。

        HDFS和其他文件系统的另一个主要区别是它的块大小。一般的目的文件系统使用4 KB或8 KB的块大小作为数据。另一方面，Hadoop默认使用了更大的64 MB的块大小。实际上，集群管理员通常会将其提高到128 MB，256 MB，甚至高达1 GB。增加块大小意味着数据将被写入磁盘上的更大的连续块中，这意味着数据可以在更大的顺序操作中写入和读取。这最小化了驱动器查找操作——这是一个机械磁盘可以进行的最慢的操作之一，并且在进行大型的流/输出操作时可以获得更好的性能。

       当然，应用程序不需要担心块、元数据、磁盘、扇区和其他低层次的细节。相反，开发人员希望使用诸如文件和流之类的高级抽象来执行输入/输出操作。HDFS将文件系统作为一种高级的、类似于posix的API，提供了熟悉的操作和概念

Daemons(守护进程)

有三个守护程序组成一个标准的HDFS集群，每个守护进程都有一个独特的角色，如表2-1所示。

        块只不过是一个文件的块，二进制的数据块。在HDFS中，负责存储和检索块数据的守护进程被称为datanode(DN)。datanode可以直接访问一个或多个称为数据磁盘的磁盘，在服务器上，它可以存储块数据。在生产系统中，这些磁盘通常只预留给Hadoop。存储可以通过添加更多的datanodes附加磁盘容量，或者甚至向现有的datanodes添加磁盘来添加到集群中。

        HDFS最引人注目的一个方面是，它的设计方式是不需要对其块数据进行RAID存储。这与商品硬件设计目标保持在一起，并随着集群规模的增长而降低成本。而不是依靠RAID控制器来进行数据安全，块数据被简单地写入到多台机器中。这就满足了对原始储存成本的安全考虑;然而，这也有一个性能方面的问题。在不同的机器上拥有多个副本意味着，如果机器消失，我们不仅可以防止数据丢失，而且在处理过程中，可以使用这些数据的任何副本。通过拥有多个选项，决定何处执行处理的调度程序更有可能找到具有可用计算资源和数据副本的机器。这在第三章中更详细地介绍了。

        虽然datanodes负责存储块数据，但是namenode(NN)是存储文件系统元数据并维护文件系统的完整图像的守护进程。客户端连接到namenode来执行文件系统操作;虽然，我们稍后会看到，块数据是直接从datanodes传输的，因此带宽不受单个节点的限制。Datanodes定期向namenode报告他们的状态。这意味着，在任何给定的时间，namenode都有一个完整的视图，包括集群中的所有datanodes，它们当前的健康状况，以及它们可用的块。图2-1为HDFS体系结构的示例。

        当datanode最初启动时，以及此后的每小时，它都会向namenode发送所谓的“块报告”。这个块报告只是一个列表，它列出了当前在磁盘上的datanode的所有块，并允许namenode跟踪任何更改。这也是必要的，因为尽管namenode上的映射文件存储在磁盘上，但是块的位置并没有写到磁盘上。乍一看，这似乎是违反直觉的，但这意味着任何datanodes的IP地址或主机名的更改都不会影响文件系统元数据的底层存储。另一个好的副作用是，如果有一个datanode在主板上的失败，管理员可以简单地移除它的硬盘，把它们放到一个新的机箱里，然后启动新的机器。就namenode而言，这些块只是移动到一个新的datanode。缺点是，当最初启动一个集群(或重新启动它时)，namenode必须等待接收来自所有datanodes的块报告以了解所有的块。

       namenode的文件系统元数据完全由RAM提供，用于快速查找和检索，从而为namenode可以处理的元数据设置了上限。粗略估计，100万个块的元数据占用了大约1 GB的堆(在硬件选择中更多的是这样的)。稍后我们将看到如何克服这个限制，即使它只在一个非常大的范围内(数千个节点)。

       最后，第三个HDFS进程被称为第二个namenode，并为namenode执行一些内部管理。尽管它的名称是，但是第二个namenode并不是namenode的一个备份，它执行一个完全不同的函数。

Reading and Writing Data(读写数据)

        客户端可以使用各种工具和api(查看访问和集成)对HDFS进行读写，但是它们都遵循相同的过程。在某种程度上，客户端总是使用一个知道HDFS及其语义的Hadoop库。这个库封装了在必要时与namenode和datanodes通信的大部分细节，以及处理在处理分布式文件系统时可能出现的大量故障案例。

The Read Path

       首先，让我们看一下执行HDFS读取操作的逻辑。 为此，我们假设有一个文件/用户/esammer/foo。 txt已经在HDFS。 除了使用Hadoop的客户library-usually Java JAR每客户机还必须指定集群配置数据的副本的位置namenode(见第五章),如图2 - 2所示,客户端首先联系namenode,表示它将喜欢读哪些文件。 客户端标识是首先确认的，要么信任客户机，允许它指定用户名，要么使用Kerberos之类的强身份验证机制(见第6章)，然后对文件的所有者和权限进行检查。 如果该文件存在，并且用户可以访问它，namenode将使用第一个块ID和datanodes的列表来响应客户端，该列表可以根据客户的距离对该块进行排序。 与客户机的距离是根据Hadoop的拓扑配置数据来测量的，该数据表示主机位于哪个机架。 (在机架拓扑结构中可以使用更多的拓扑配置。)

     使用块id和datanode主机名，客户端现在可以直接联系最合适的datanode，并读取它需要的块数据。 这个过程会重复，直到文件中所有的块被读取或者客户端关闭文件流。

        也有可能，当从datanode读取数据时，它运行的进程或主机就会死亡。 该库将自动尝试从另一个datanode读取另一个数据副本，而不是放弃。 如果所有的副本都不可用，则读取操作失败，客户端收到一个异常。 另一个可能发生的情况是，当客户端尝试联系datanode时，namenode返回的信息可能会过时，在这种情况下，如果有其他副本或读取失败，重试将会发生。 虽然这种情况很少见，但这类角落的案例使得像Hadoop这样的大型分布式系统出现故障。 请参阅第9章，了解可能出现的问题以及如何诊断问题。

The Write Path

       将文件写入HDFS比执行读操作要复杂一些。我们将考虑最简单的情况，即客户机正在创建一个新文件。请记住，客户端不需要实际实现这个逻辑;这只是简单地概述了底层Hadoop库如何将数据写入集群。应用程序开发人员使用(主要是)熟悉的api来打开文件、写入流，并将它们与传统本地文件的方式相似。

       最初，客户机发出请求，使用Hadoop文件系统api打开指定的文件。 如果用户有必要的权限，则将请求发送到namenode，以创建文件元数据。 新文件的元数据条目; 但是，它最初没有相关的块。 对客户机的响应表明打开的请求是成功的，并且它现在可能开始写入数据。 在API级别，返回一个标准的Java流对象，尽管实现是特定于hdfs的。 当客户端将数据写入到流中时，它被分割成包(不与TCP包或HDFS块混淆)，后者在内存中排队。 客户端中的一个单独的线程将从这个队列中使用数据包，并且，必要时，联系namenode，请求一组datanodes，以便编写下一个块的副本。 然后，客户端直接连接到列表中的第一个datanode，它连接到第二个，连接到第三个。 这将形成用于此数据块的复制管道，如图2-3所示。 然后，数据信息包被流到第一个datanode，它将数据写到磁盘，然后发送到管道中的下一个datanode，该数据写到磁盘上，等等。 复制管道中的每个datanode都在成功地编写了每个数据包。 客户端应用程序维护一个未接收到应答的包列表，当它收到响应时，它知道已经将数据写入了管道中的所有节点。 这种将包写入管道的过程一直持续到达到了块大小，这时客户端返回到namenode，以供下一组datanodes的写入。 最终，客户端表明它通过关闭流来完成发送数据的操作，该流将所有剩余的数据包发送到磁盘，并更新namenode以指示文件当前

        当然，事情并不总是那么简单，失败也会发生。 最常见的失败类型是，复制管道中的datanode由于某个原因或另一个原因而无法写入数据——例如，磁盘死亡或datanode完全失败。 当发生这种情况时，管道将立即关闭，并且在最后一次确认之后发送的所有数据包都被重新发送到队列中，以便通过管道中的任何数据发送者都可以接收到数据。 当前的块在剩余的健康的datanodes上得到一个新的ID。 这样做，如果失败的datanode返回，被丢弃的块将不属于任何文件，并自动丢弃。 一个包含其余datanodes的新复制管道被打开，然后写简历。 此时，大多数情况都回到正常状态，写操作将继续，直到文件被关闭为止。 namenode会注意到文件中的一个块没有被复制，并且会安排一个异步创建的新副本。 客户端可以从多个失败的datanodes中恢复过来，至少提供了最少数量的副本(默认情况下，这是一个)。

Managing Filesystem Metadata(管理系统数据)

       namenode在一些不同的文件中存储它的文件系统元数据，其中两个最重要的文件是fsimage和编辑。 就像数据库一样，fsimage包含文件系统元数据的完整快照，而编辑只包含对元数据的增量修改。 对于高吞吐量数据存储的一种常见做法，使用前面的日志(WAL)，比如编辑文件，可以减少对顺序的、只应用程序的操作(在namenode的上下文中，因为它直接来自RAM)，从而避免了代价高昂的查找操作，并产生更好的整体性能。 在namenode启动时，fsimage文件被加载到RAM中，编辑文件中的任何更改都会被重新播放，从而使文件系统的内存视图更新到最新。

       在最近的Hadoop版本中(特别是Apache Hadoop 2.0和CDH4; 更多关于Hadoop的不同版本的Hadoop在选择Hadoop的发行版和版本)，底层的元数据存储被更新，以更适应于腐败，并支持namenode高可用性。 从概念上讲，元数据存储是类似的，尽管事务不再存储在单个编辑文件中。 相反，namenode会周期性地滚动编辑文件(关闭一个文件并打开一个新文件)，通过事务ID编号，namenode还可以保留原来的fsimage和编辑的旧副本，以更好地支持及时回滚的能力。 大多数这些更改不会影响您，尽管它有助于理解磁盘上的文件的目的。 也就是说，除非你真的知道你在做什么，否则你不应该对这些文件进行直接的修改。 本书的其余部分将简单地引用这些文件，使用它们的基本名称、fsimage和编辑，通常是指它们的功能。

        回想一下，namenode只在写前面的日志、编辑的时候写修改。 随着时间的推移，编辑文件会不断增长和增长，与任何基于日志的系统一样，如果服务器出现故障，则需要很长时间才能重放。 与关系数据库类似，编辑文件需要定期地应用到fsimage文件。 问题是，namenode可能没有可用的资源-cpu或ram-以便在继续为集群提供服务时执行此操作。 这就是第二个namenode的用武之地。

       namenode和第二个namenode之间发生的确切交互(如图2-4所示)如下:3

1.  namenode指示namenode滚动它的编辑文件，并开始写入edis.new。
2.  namenode将namenode的fsimage复制到它的本地检查点目录中。
3. namenode加载fsimage，在其上重新编辑编辑，并将一个新的、压缩的fsimage文件写到磁盘上。
4. namenode将新的fsimage文件发送到namenode，它采用它。第二个namenode将新的fsimage文件发送到namenode，并采用它
   
5. namenode 重命名编辑。新编辑。

        这个过程每小时(默认情况下)发生，或者任何时候namenode的编辑文件达到64 MB(也是默认值)。 通常没有一个很好的理由来修改这个内容，尽管我们稍后会讨论这个问题。 新版本的Hadoop使用定义的事务数量，而不是文件大小来决定什么时候执行检查点。

Namenode High Availability(Namenode高可用性)

        作为对大规模系统的健康和服务负责的管理员，单点故障的概念应该会让我们感到不安(或者更糟)。 不幸的是，在很长一段时间内，HDFS namenode就是这样:一个单点故障。 最近，Hadoop社区作为一个整体投入了大量的资金，使namenode获得了很高的可用性，从而为额外的关键任务部署打开了Hadoop。

        Namenode高可用性(或HA)被部署为主动/被动对namende。 前面的编辑日志需要对两个名称空间都可用，因此存储在一个共享存储设备上。 目前，需要一个NFS文件作为共享存储，尽管有一些计划要删除这个依赖项。 当活动的namenode写到编辑日志时，备用namenode会不断地重新运行事务，以确保它是最新的，并准备在失败的情况下接管事务。 Datanodes也意识到HA配置的两个名称，并向两个服务器发送块报告。

       可以为手动或自动故障转移配置一个高可用性的名称组。 在默认的手动故障转移模式中，必须发送一个命令来影响从一个namenode到另一个namenode的状态转换。 当配置为自动故障转移时，每个namenode都运行一个附加的进程，称为故障转移控制器，它监控进程的健康，并协调状态转换。 与其他HA系统一样，故障转移有两种主要类型:一种是由管理员发起的优雅故障转移，另一种是不优雅的故障转移，这是活动过程中检测到的故障的结果。 在这两种情况下，都不可能真正知道namenode是否已经放弃了活动状态，或者只是从备用服务器无法访问。 如果两个进程都被允许继续运行， 它们既可以写入共享状态，也可以损坏文件系统元数据。 这通常被称为分裂的大脑场景。 由于这个原因，系统可以使用一系列越来越激烈的技术来确保失败的节点(仍然可以认为它是活动的)实际上已经停止了。 这可以从一些简单的事情开始，比如让它通过RPC停止，但是可以用所有的击剑技巧的母亲来结束:STONITH，或者“在头部的另一个节点射击”。 “STONITH可以通过IPMI进行重新引导，甚至可以通过编程的方式在短时间内将电源切断到机器上，如果数据中心的电力分配单元(PDUs)支持这样的功能。 大多数想要高可用性的管理员也希望配置自动故障转移。 请参阅图2-5，以获得自动故障转移的示例。

        在使用高可用性时，备用namenode将接管第二个namenode的角色，这是前面描述的。 换句话说，在HA集群中没有单独的namenode进程，只有一对namenode进程。 已经运行Hadoop集群的那些拥有专用机器的集群，它们运行第二个namenode进程，可以在大多数情况下将该机器重新定位为第二个namenode。 在Namenode高可用性中，详细介绍了高可用性的各种配置选项。

在撰写本文时，namenode高可用性(有时缩写为NN HA)在Apache Hadoop 2.0.0和CDH4中可用。

Namenode Federation(Namenode联合)

        Hadoop的大规模用户还遇到了另一个障碍:namenode在内存中可以存储多少元数据。 为了将namenode扩展到可以填充到单个服务器的物理内存的数量，需要有一种方法从扩展到扩展到扩展的方法。 就像我们在HDFS中看到的块存储一样，可以将文件系统元数据分散到多台机器上。 这种技术称为命名空间联合，它指的是从许多自治系统中装配一个逻辑名称空间。 联邦名称空间的一个例子是Linux文件系统:许多设备可以挂载在不同的点上，以形成一个单一的名称空间，客户端可以在不关心底层设备实际包含数据的情况下进行处理。

        Namenode联合(图2-6)在Namenode的内存限制中工作，它允许将文件系统命名空间分解为多个部分，并在多个Namenode中传播。 正如它听起来的那样，这实际上就像运行许多单独的nam烯，每一个都负责目录结构的不同部分。 namenode联合与运行几个离散集群不同的主要方式是，每个datanode都存储多个namenode。 更准确地说，每个datanode都有一个针对每个名称空间的块池。 当来自不同的池的块被存储在同一个磁盘上(没有物理隔离)，它们在逻辑上是独占的。 每个datanode都向每个namenode发送心跳和阻塞报告。

        客户端通常不需要担心多个namenode，因此可以使用一个名为ViewFS的特殊客户端API实现，将文件系统的切片映射到适当的namenode。 从概念上讲，这与Linux/etc/fstab文件几乎完全相同，除了将路径映射到物理设备之外，ViewFS将路径映射到HDFS名称。 例如，我们可以配置ViewFS来查看路径/日志和路径/hbase的nam诺de2。 联邦还允许我们使用名称空间分区来控制文件系统的不同部分的可用性和容错。 在我们之前的示例中，/hbase可能位于一个namenode上，它需要极高的正常运行时间，而可能/日志只能由MapReduce中的批处理操作使用。

        最后，值得注意的是HA和联邦是正交的特性。 也就是说，当他们谈到两个不同的问题时，他们可以彼此独立地启用它们。 这意味着可以对名称空间进行分区，其中的一些分区(或全部)可能由HA对名称空间提供。

Access and Integration(访问和集成)

       访问HDFS的唯一方法是它的Java API。 所有其他访问方法都是在这个API之上构建的，根据定义，可以只公开尽可能多的功能。 为了简化应用程序的采用和开发，HDFS API对于开发人员来说是简单而熟悉的，他们利用了Java的输入/输出流等概念。 为了提供功能和保证，API确实有所不同，但其中大多数都是明显的或文档化的。

       为了访问HDFS，针对api编写的客户机-应用程序必须有一个配置数据副本，告诉它们在哪里运行namenode。 这类似于需要tnsname的Oracle客户机应用程序。 ora文件。 每个应用程序都必须访问Hadoop库JAR文件。 同样，这相当于数据库客户机应用程序对JDBC驱动程序JAR的依赖。 客户端可以与任何Hadoop守护进程在同一台物理机器上，也可以与集群分离。 例如，MapReduce任务和HBase区域服务器可以像任何其他普通客户机一样访问HDFS。 它们刚好在相同的物理机器上运行，而HDFS会存储它的块数据。

        重要的是要认识到，作为直接客户端到datanode通信的结果，客户端和所有集群节点的相关端口之间的网络访问必须是不受限制的。 这对网络设计、安全性和带宽的影响有一定的影响。

Command-Line Tools(命令行工具)

        Hadoop附带了许多命令行工具，这些工具可以支持基本的文件系统操作。 与所有Hadoop工具一样，HDFS命令是Hadoop命令行实用工具的子命令。 运行hadoop fs将显示基本的使用信息，如2-1所示。

        对于具有基本shell经验的管理员，这些命令中的大多数将立即变得明显。 主要的区别在于，因为HDFS是一个用户空间文件系统，所以没有当前工作目录的概念。 所有路径都是绝对的(推荐的)或相对于HDFS中用户的主目录。 [5]一个绝对路径可以/日志/ 2012/01/25 /的形式,也可以包括完整的URL指定的位置namenode,如hdfs:/ / mynamenode.mycompany.com:8020 / logs / 2012/01/25 /。 如果没有使用完整的URL语法，则从核心站点的fs.default.name参数中获取值。 xml配置文件(见示例2-2)。

       为了向自己证明HDFS名称空间与主机操作系统完全不同，我们可以尝试使用标准ls命令来列出相同的路径(见示例2-3)。

        在许多方面，HDFS更像是一个远程文件系统，而不是一个本地操作系统文件系统。 例如，将文件复制到或从HDFS复制的行为更像是SCP或FTP，而不是与NFS装载的文件系统一起工作。 使用-put或同义词-copyFromLocal上传文件，并通过-get或-copylocal下载。 为了方便起见，-moveFromLocal和-movetollocal命令将分别复制一个文件或到HDFS，然后删除源文件(见示例2-4)。

        对于HDFS来说，惟一的特性是能够设置文件的复制因子。 这可以通过使用-setrep命令来完成，该命令使用一个复制因子和一个可选标志(-R)来表示它应该递归地操作(参见示例2-5)。

        在示例2-5中，我们将tmp目录中的文件a和b的复制因子更改为5。 接下来，使用fsck检查文件系统完整性的fsck，用于检查文件的健康，但是对于每个文件显示块位置信息具有良好的副作用。 在这里，每个块的5个副本在集群中分布在5个不同的datanodes中，就像预期的那样。 您可能会注意到只有文件有一个块列表。 HDFS中的目录是纯元数据条目，没有块数据。

FUSE

        用户空间中的文件系统，即FUSE，是一种允许开发人员在用户空间中实现可挂载文件系统的系统。 也就是说，不需要对内核模块进行开发。 这不仅更简单，因为开发人员可以在熟悉的环境中使用标准库，而且它也更安全，因为开发人员的错误不一定会导致内核恐慌。

Apache Hadoop和CDH都支持FUSE HDFS，正如您可能已经猜到的那样，它允许您像任何其他设备一样安装Hadoop分布式文件系统。 这使得遗留应用程序和系统能够继续在由HDFS支持的Linux服务器上读写文件到一个常规目录。 虽然这很有用，但并不是万能药。 HDFS的所有属性仍然存在:没有对文件进行修改，相对较高的延迟，糟糕的随机访问性能，对大型流媒体操作的优化，以及巨大的规模。 需要明确的是，FUSE并不使HDFS成为一个posix兼容的文件系统。 它只是一个兼容层，可以将HDFS暴露给只执行基本文件操作的应用程序。

REST Support

        在过去的几年里，具象状态传输(REST)已经成为一种越来越受欢迎的以语言无关的方式与服务交互的方式。 Hadoop的本地api都是基于java的，这给非java客户机带来了问题。 应用程序可以使用hadoop fs命令进行炮击和使用，但这是低效且容易出错的(更不用提美学上的不公平了)。 从Apache Hadoop 1.0.0和CDH4开始，WebHDFS是一个用于HDFS的RESTful API，现在是该软件的标准部分。 WebHDFS在每个Hadoop HDFS守护进程中使用已经嵌入的web服务器来运行一组REST API，这些API模仿Java文件系统API，包括读写方法。 完整的身份验证，包括Kerberos SPNEGO，由WebHDFS支持。 请参见示例2-6示例，用于对WebHDFS的类似hadoop fs-ls/hbase命令的示例调用。

        大约在同一时间，创建了一个独立的RESTful HDFS代理服务，称为HttpFS。乍一看，WebHDFS和HttpFS都解决了同样的问题，但HttpFS与WebHDFS是100%兼容的——它们解决了两个单独的架构问题。通过在每个守护进程中使用嵌入式web服务器，WebHDFS客户端必须能够与集群的每个节点进行通信，就像本地Java客户端一样。HttpFS主要是用来解决这个问题的，它可以作为一个可以跨网络段的网关服务。客户端只需要连接到HttpFS守护进程，然后使用标准的Java api执行与HDFS集群的所有通信。HttpFS的好处是它最小化了与集群通信所需的内存占用，但代价是总规模和容量，因为客户机和HDFS之间的所有数据现在必须通过单个节点进行传输。当然，运行多个HttpFS代理来解决这个问题是完全可以的。此外，由于WebHDFS和HttpFS都是完全兼容的，所以编写客户机应用程序的开发人员需要关注这些细节。这个决定可以完全基于所需的数据吞吐量和网络设计和安全需求。   

       这是我Hadoop的系列文章以及学习路线，后续还有连载，尽情期待。

       Github地址：https://github.com/noseparte 

       Email：noseparte@aliyun.com     有java与hadoop相关的技术问题，可以发私信与我交流。

       NPM地址：https://www.npmjs.com/~noseparte

       个人网站 ： http://www.noseparte.com/   Copyright © 2017 noseparte