我正在使用 webhdfs 在 hadoop hdfs 中加载 28 GB 文件，加载大约需要 25 分钟。
我尝试使用 hdfs put 加载相同的文件，它花了大约 6 分钟。为什么性能差别这么大？
推荐使用什么？有人可以解释或指导我找到一些好的链接，这将非常有帮助。
下面是我正在使用的命令
curl -i --negotiate -u: -X PUT "http://$hostname:$port/webhdfs/v1/$destination_file_location/$source_filename.temp?op=CREATE&overwrite=true"
这将重定向到我在下一步中用于写入数据的数据节点地址。
Hadoop 提供了几种访问 HDFS 的方法
以下所有内容都支持文件系统的几乎所有功能 -
1. FileSystem (FS) shell 命令：提供对 Hadoop 文件系统操作以及 Hadoop 支持的其他文件系统的轻松访问，例如 Local FS、HFTP FS、S3 FS。
这需要安装 hadoop 客户端，并且需要客户端将块直接写入一个数据节点。并非所有版本的 Hadoop 都支持在文件系统之间进行复制的所有选项。2. WebHDFS： 它定义了一个公共的HTTP REST API，它允许客户端在不安装Hadoop的情况下从多种语言访问Hadoop，优势是语言不可知的方式（curl，php等......）。
WebHDFS 需要访问集群的所有节点，当读取一些数据时，它会直接从源节点传输，但是 ** 有 http 的开销 ** (1)FS Shell 但工作不可知，不同的 hadoop 集群没有问题和版本。3. HttpFS。在防火墙后面的集群中读取和写入数据到 HDFS。单个节点将充当网关节点，所有数据都将通过该节点进行传输，并且在性能方面我相信这可能会更慢，但当需要将数据从公共源提取到安全集群时是首选。
因此，请正确选择！.. 当您无法选择上面的选择时，从列表中向下永远是一种选择。
Hadoop 提供了一个 FileSystem Shell API 来支持文件系统操作，例如创建、重命名或删除文件和目录，打开、读取或写入文件。FileSystem shell 是一个 java 应用程序，它使用 java FileSystem 类来提供 FileSystem 操作。FileSystem Shell API 为操作创建 RPC 连接。
如果客户端在 Hadoop 集群中，那么这很有用，因为它使用hdfsURI 方案连接到 hadoop 分布式文件系统，因此客户端会进行直接 RPC 连接以将数据写入 HDFS。
这对于在 Hadoop 集群中运行的应用程序来说是很好的，但可能存在外部应用程序需要操作 HDFS 的用例，例如它需要创建目录并将文件写入该目录或读取存储在 HDFS 上的文件的内容。Hortonworks 基于称为 WebHDFS 的标准 REST 功能开发了一个 API 来支持这些要求。
WebHDFS 提供 REST API 功能，任何外部应用程序都可以通过 HTTP 连接连接 DistributedFileSystem。无论外部应用程序是 Java 还是 PHP。
WebHDFS 概念基于 HTTP 操作，如 GET、PUT、POST 和 DELETE。OPEN、GETFILESTATUS、LISTSTATUS 等操作使用 HTTP GET，其他操作如 CREATE、MKDIRS、RENAME、SETPERMISSIONS 依赖于 HTTP PUT
它通过 HTTP 提供对 HDFS 的安全读写访问。它基本上是为了替代 HFTP（HTTP 上的只读访问）和 HSFTP（HTTPS 上的只读访问）。它使用webhdfsURI 方案连接分布式文件系统。
如果客户端在 Hadoop 集群之外并试图访问 HDFS。WebHDFS 对它很有用。此外，如果您尝试连接两个不同版本的 Hadoop 集群，那么 WebHDFS 很有用，因为它使用 REST API，因此它独立于 MapReduce 或 HDFS 版本。
HDFS 访问和 WebHDFS 之间的区别在于可扩展性，这是由于 HDFS 的设计以及 HDFS 客户端将文件分解为位于不同节点的拆分的事实。当 HDFS 客户端访问文件内容时，它会在后台进入 NameNode 并获取文件拆分列表及其在 Hadoop 集群上的物理位置。
然后，它可以执行所有这些位置上的 DataNode，以并行获取拆分中的块，将内容直接传送到客户端。
WebHDFS 是一个存在于 HDFS 集群中的代理，它在 HDFS 上分层，因此所有数据在中继到 WebHDFS 客户端之前都需要流式传输到代理。从本质上讲，它变成了单点访问和 IO 瓶颈。