hdfs/hadoop的默认数据块大小是64mb。磁盘中的块大小通常为4kb。64mb块大小是什么意思？->这是否意味着从磁盘读取的最小单位是64mb？如果是，那么这样做的好处是什么？->在hdfs中可以方便地连续访问大文件？我们可以用磁盘中原来的4kb块大小来做同样的事情吗？
kmbjn2e31#
如果将块大小设置为小于64，则整个集群中会有大量块，这会导致namenode管理大量元数据。因为每个块都需要一个Map器，所以会有很多Map器，每个Map器处理一段数据，这是不高效的。
vq8itlhq2#
hdfs的设计最初是受到google文件系统（gfs）设计的启发。以下是原始gfs论文中提到的大数据块大小的两个原因（gfs术语与hdfs术语的注解1:chunk=block，chunkserver=datanode，master=namenode；注2：粗体格式是我的）：大的块大小提供了几个重要的优点。首先，它减少了客户机与主机交互的需要，因为对同一块的读写只需要向主机发出一个初始请求，请求获取块位置信息。这种减少对于我们的工作负载尤其重要，因为应用程序大多是按顺序读写大文件。[…]其次，由于在一个大数据块上，客户机更有可能在一个给定的数据块上执行许多操作，因此它可以通过在一段较长的时间内保持与chunkserver的持久tcp连接来减少网络开销。第三，它减少了存储在主机上的元数据的大小。这允许我们将元数据保存在内存中，这反过来又带来了我们将在第2.6.1节中讨论的其他优势。最后，我应该指出，ApacheHadoop中当前的默认大小是128MB（请参阅dfs.blocksize）。
qltillow3#
What does 64MB block size mean?
块大小是文件系统可以存储的最小数据单位。如果你存储一个1k或60mb的文件，它会占用一个街区。一旦越过64mb边界，就需要第二个块。
If yes, what is the advantage of doing that?
hdfs是用来处理大文件的。假设您有一个1000mb的文件。对于4k块大小，您必须发出256000个请求才能获取该文件（每个块1个请求）。在hdfs中，这些请求通过一个网络并带来大量开销。每个请求都必须由name节点进行处理，以确定在何处可以找到该块。交通太拥挤了！如果使用64mb块，请求数将减少到16个，从而大大降低了name节点的开销和负载成本。
pprl5pva4#
它更多地与硬盘驱动器（hdd）的磁盘寻道有关。随着时间的推移，与磁盘吞吐量相比，磁盘寻道时间的进展不大。因此，当块大小很小（这导致块太多）时，将有太多的磁盘寻道，这不是很有效。随着我们从hdd到sdd的发展，磁盘寻道时间没有多大意义，因为它们是ssd中的移动部件。此外，如果有太多的块，它将紧张的名称节点。注意，name节点必须在内存中存储整个元数据（关于块的数据）。在apachehadoop中，默认块大小是64mb，在clouderahadoop中，默认块大小是128mb。
yrwegjxp5#
以下是“hadoop：权威指南”一书第3版的解释（第45页）。为什么hdfs中的块这么大？与磁盘块相比，hdfs块比较大，其原因是最小化寻道成本。通过使一个块足够大，从磁盘传输数据的时间可以明显长于寻找到块开始的时间。因此，传输由多个块组成的大文件的时间以磁盘传输速率运行。快速计算表明，如果寻道时间在10ms左右，传输速率为100mb/s，要使寻道时间占传输时间的1%，就需要使块大小在100mb左右。默认值实际上是64MB，尽管许多hdfs安装使用128MB块。随着新一代磁盘驱动器传输速度的提高，这一数字将继续向上修正。然而，这一论点不应过分。mapreduce中的Map任务通常一次只在一个块上运行，因此如果任务太少（少于群集中的节点），则作业的运行速度会比其他任务慢。
txu3uszq6#
在hdfs中，块大小控制复制取消群集的级别。块大小越小，块在数据节点上的分布就越均匀。块大小越大，数据在集群中的分布就越不均匀。那么，选择更高的块大小而不是一些较低的值又有什么意义呢？虽然理论上数据的均匀分布是一件好事，但是块大小太小有一些明显的缺点。namenode的容量是有限的，因此将128mb改为4kb块大小意味着要存储的信息是32768倍。mapreduce还可以通过在更多的nodemanager和更多的cpu内核上启动更多的map任务来从均匀分布的数据中获益，但实际上，由于无法执行顺序的缓冲读取以及每个map任务的延迟，理论上的好处将丢失。
5f0d552i7#
hadoop选择64mb的原因是google选择了64mb。谷歌之所以选择64mb，是因为一个金发姑娘的论点。具有更小的块大小将导致查找开销增加。具有适度较小的块大小可以使map任务运行得足够快，使调度它们的成本与运行它们的成本相当。块大小显著增大会降低可用的读取并行性，并可能最终导致难以在任务的本地调度任务。参见谷歌研究出版物：mapreducehttp://research.google.com/archive/mapreduce.html
olqngx598#
在正常操作系统中，块大小是4k，在hadoop中是64mb。因为为了方便维护namenode中的元数据。假设我们在hadoop中只有4k的块大小，并且我们试图将100mb的数据加载到这个4k中，那么我们需要越来越多的4k块。namenode需要维护所有这些4k的元数据块。如果我们使用64mb的块大小，那么数据将只加载到两个块（64mb和36mb）中，因此元数据的大小会减小。结论：为了减轻namenode hdfs的负担，hdfs首选64mb或128mb的块大小。在hadoop1.0中，块的默认大小是64mb，在hadoop2.0中是128mb。
8条答案
按热度按时间kmbjn2e31#
如果将块大小设置为小于64，则整个集群中会有大量块，这会导致namenode管理大量元数据。
因为每个块都需要一个Map器，所以会有很多Map器，每个Map器处理一段数据，这是不高效的。
vq8itlhq2#
hdfs的设计最初是受到google文件系统（gfs）设计的启发。以下是原始gfs论文中提到的大数据块大小的两个原因（gfs术语与hdfs术语的注解1:chunk=block，chunkserver=datanode，master=namenode；注2：粗体格式是我的）：
大的块大小提供了几个重要的优点。首先，它减少了客户机与主机交互的需要，因为对同一块的读写只需要向主机发出一个初始请求，请求获取块位置信息。这种减少对于我们的工作负载尤其重要，因为应用程序大多是按顺序读写大文件。[…]其次，由于在一个大数据块上，客户机更有可能在一个给定的数据块上执行许多操作，因此它可以通过在一段较长的时间内保持与chunkserver的持久tcp连接来减少网络开销。第三，它减少了存储在主机上的元数据的大小。这允许我们将元数据保存在内存中，这反过来又带来了我们将在第2.6.1节中讨论的其他优势。
最后，我应该指出，ApacheHadoop中当前的默认大小是128MB（请参阅dfs.blocksize）。
qltillow3#
块大小是文件系统可以存储的最小数据单位。如果你存储一个1k或60mb的文件，它会占用一个街区。一旦越过64mb边界，就需要第二个块。
hdfs是用来处理大文件的。假设您有一个1000mb的文件。对于4k块大小，您必须发出256000个请求才能获取该文件（每个块1个请求）。在hdfs中，这些请求通过一个网络并带来大量开销。每个请求都必须由name节点进行处理，以确定在何处可以找到该块。交通太拥挤了！如果使用64mb块，请求数将减少到16个，从而大大降低了name节点的开销和负载成本。
pprl5pva4#
它更多地与硬盘驱动器（hdd）的磁盘寻道有关。随着时间的推移，与磁盘吞吐量相比，磁盘寻道时间的进展不大。因此，当块大小很小（这导致块太多）时，将有太多的磁盘寻道，这不是很有效。随着我们从hdd到sdd的发展，磁盘寻道时间没有多大意义，因为它们是ssd中的移动部件。
此外，如果有太多的块，它将紧张的名称节点。注意，name节点必须在内存中存储整个元数据（关于块的数据）。在apachehadoop中，默认块大小是64mb，在clouderahadoop中，默认块大小是128mb。
yrwegjxp5#
以下是“hadoop：权威指南”一书第3版的解释（第45页）。
为什么hdfs中的块这么大？
与磁盘块相比，hdfs块比较大，其原因是最小化寻道成本。通过使一个块足够大，从磁盘传输数据的时间可以明显长于寻找到块开始的时间。因此，传输由多个块组成的大文件的时间以磁盘传输速率运行。
快速计算表明，如果寻道时间在10ms左右，传输速率为100mb/s，要使寻道时间占传输时间的1%，就需要使块大小在100mb左右。默认值实际上是64MB，尽管许多hdfs安装使用128MB块。随着新一代磁盘驱动器传输速度的提高，这一数字将继续向上修正。
然而，这一论点不应过分。mapreduce中的Map任务通常一次只在一个块上运行，因此如果任务太少（少于群集中的节点），则作业的运行速度会比其他任务慢。
txu3uszq6#
在hdfs中，块大小控制复制取消群集的级别。块大小越小，块在数据节点上的分布就越均匀。块大小越大，数据在集群中的分布就越不均匀。
那么，选择更高的块大小而不是一些较低的值又有什么意义呢？虽然理论上数据的均匀分布是一件好事，但是块大小太小有一些明显的缺点。namenode的容量是有限的，因此将128mb改为4kb块大小意味着要存储的信息是32768倍。mapreduce还可以通过在更多的nodemanager和更多的cpu内核上启动更多的map任务来从均匀分布的数据中获益，但实际上，由于无法执行顺序的缓冲读取以及每个map任务的延迟，理论上的好处将丢失。
5f0d552i7#
hadoop选择64mb的原因是google选择了64mb。谷歌之所以选择64mb，是因为一个金发姑娘的论点。
具有更小的块大小将导致查找开销增加。
具有适度较小的块大小可以使map任务运行得足够快，使调度它们的成本与运行它们的成本相当。
块大小显著增大会降低可用的读取并行性，并可能最终导致难以在任务的本地调度任务。
参见谷歌研究出版物：mapreducehttp://research.google.com/archive/mapreduce.html
olqngx598#
在正常操作系统中，块大小是4k，在hadoop中是64mb。因为为了方便维护namenode中的元数据。
假设我们在hadoop中只有4k的块大小，并且我们试图将100mb的数据加载到这个4k中，那么我们需要越来越多的4k块。namenode需要维护所有这些4k的元数据块。
如果我们使用64mb的块大小，那么数据将只加载到两个块（64mb和36mb）中，因此元数据的大小会减小。
结论：为了减轻namenode hdfs的负担，hdfs首选64mb或128mb的块大小。在hadoop1.0中，块的默认大小是64mb，在hadoop2.0中是128mb。