performance - 小文件的 HDFS 性能

Question

我是 Hadoop 新手。最近我正在尝试处理(仅读取)hdfs/hadoop 上的许多小 文件。平均文件大小约为1 kb，文件数量超过10M。由于某些限制，该程序必须用 C++ 编写。

这只是一个性能评估，所以我只使用 5 台机器作为数据节点。每个数据节点有5个数据盘。

我编写了一个小型 C++ 项目来直接从硬盘读取文件(而不是从 HDFS)以构建性能基线。该程序将为每个磁盘创建 4 个读取线程。性能结果是每个磁盘大约有 14MB/s。总吞吐量约为 14MB/s * 5 * 5 = 350MB/s(14MB/s * 5 磁盘 * 5 台机器)。

但是，当这个程序(仍然使用 C++，动态链接到 libhdfs.so，创建 4*5*5=100 个线程)从 hdfs 集群读取文件时，吞吐量大约只有 55MB/秒。

如果在 mapreduce 中触发此编程(hadoop streaming，5 个作业，每个作业有 20 个线程，线程总数仍然是 100)，吞吐量下降到大约 45MB/s。 (我猜它会因为一些簿记过程而变慢)。

我想知道 HDFS 可以提供的合理性能是多少。可以看到，与原生代码相比，数据吞吐量只有1/7左右。是我配置的问题吗？还是 HDFS 限制？还是Java限制？我的场景的最佳方式是什么？序列文件会有帮助吗(很多)？与我们预期的 native IO 读取相比，合理的吞吐量是多少？

这是我的一些配置:

NameNode 堆大小 32G。

Job/Task 节点堆大小 8G。

NameNode 处理程序计数:128

DataNode 处理程序数:8

DataNode最大传输线程数:4096

1GBps 以太网。

谢谢。

Answer 1

HDFS 确实不是为很多小文件设计的。

对于您读取的每个新文件，客户端必须与名称节点对话，名称节点会提供文件 block 的位置，然后客户端从数据节点流式传输数据。

现在，在最好的情况下，客户端这样做一次，然后发现它是有数据的机器，并且可以直接从磁盘读取数据。这将很快:与直接磁盘读取相当。

如果不是机器上有数据，那么它必须通过网络传输数据。然后你会受到网络 I/O 速度的限制，这应该不是很糟糕，但仍然比直接磁盘读取慢一点。

但是，您遇到了更糟糕的情况——与名称节点通信的开销变得很大。对于只有 1KB 的文件，您将达到交换元数据与实际数据一样多的地步。客户端必须进行两次独立的网络交换才能从每个文件中获取数据。除此之外，namenode 可能会受到所有这些不同线程的攻击，因此它可能成为瓶颈。

所以要回答你的问题，是的，如果你将 HDFS 用于它不是设计用于的东西，它会很慢。合并您的小文件，并使用 MapReduce 获取数据局部性，您将获得更好的性能。事实上，因为您将能够更好地利用顺序磁盘读取，所以如果从一个大的 HDFS 文件中读取比读取许多小的本地文件更快我也不会感到惊讶。