Hadoop 中块大小的设置

https://www.cnblogs.com/Dhouse/p/6901028.html

小文件BLOCK占用

【小于块大小的小文件不会占用整个HDFS块空间。也就是说，较多的小文件会占用更多的NAMENODE的内存（记录了文件的位置等信息）；再者，在文件处理时，可能会有较大的网络开销】

一个常被问到的一个问题是： 如果一个HDFS上的文件大小(file size) 小于块大小(block size) ，那么HDFS会实际占用Linux file system的多大空间？

答案是实际的文件大小，而非一个块的大小。

1、往hdfs里面添加新文件前，hadoop在linux上面所占的空间为 464 MB：

xx

2、往hdfs里面添加大小为2673375 byte(大概2.5 MB)的文件：

2673375 derby.jar

3、此时，hadoop在linux上面所占的空间为 467 MB—— 增加了一个实际文件大小(2.5 MB)的空间，而非一个block size(128 MB) ：

4、使用hadoop dfs -stat查看文件信息：

这里就很清楚地反映出： 文件的实际大小(file size)是2673375 byte， 但它的block size是128 MB。

5、通过NameNode的web console来查看文件信息:

结果是一样的： 文件的实际大小(file size)是2673375 byte， 但它的block size是128 MB。

6、不过使用‘hadoop fsck’查看文件信息，看出了一些不一样的内容—— ‘1（avg.block size 2673375 B）’:

值得注意的是，结果中有一个 ‘1（avg.block size 2673375 B）’的字样。这里的 ‘block size’ 并不是指平常说的文件块大小(Block Size)—— 后者是一个元数据的概念，相反它反映的是文件的实际大小(file size)。以下是Hadoop Community的专家给我的回复：

“The fsck is showing you an “average blocksize”, not the block size metadata attribute of the file like stat shows. In this specific case, the average is just the length of your file, which is lesser than one whole block.”

最后一个问题是： 如果hdfs占用Linux file system的磁盘空间按实际文件大小算，那么这个”块大小“有必要存在吗？

其实块大小还是必要的，一个显而易见的作用就是当文件通过append操作不断增长的过程中，可以通过来block size决定何时split文件。以下是Hadoop Community的专家给我的回复：

“The block size is a meta attribute. If you append tothe file later, it still needs to know when to split further - so it keeps that value as a mere metadata it can use to advise itself on write boundaries.”

Mac下handoop 的安装

可以参考如下博客

hadoop 的基本组成

Hadoop的基本组成包含了分布式存储模块HDFS和计算模块MapReduce。

1. HDFS

HDFS借鉴的是Google的GFS系统，是一个基于Key/Value的分布式存储系统。HDFS是为了大文件、一次写多次读的应用场景而设计的。所有要存储在HDFS中的文件需要按块（默认64M）切分，每个数据块有在不同的机器上（默认是本机，本机架，不同机架）有多个备份（默认为3份）。系统通过对失败机器数据文件的再分配、复制来自动保证文件的数据安全。HDFS并不适合大量小文件或者对写要求高的场景。这样，我们可以有个概念，Hadoop中处理的数据会分块备份三分存在不同的机器上。

2. MapReduce

MapReduce是Hadoop的数据处理模块，Hadoop对数据的处理都被抽象成Map和Reduce这两个函数的操作。

• map

  通常地，Map函数的工作是从HDFS中读取上输入文件，读入的数据是一个个（MapInputKey/MapInputValue）对，根据作业需求处理后输出一个个（MapOutputKey/MapOutputValue)对，后台的输出线程会把输出的文件按照MapOutputKey把对应的MapOutputValue合并起来（MapOutputKey–>MapOutputValue0,MapOutputValue1,…)，同时还会将输出按照MapOutputKey排序（注意，每一个Map都会有同样的样的输出，不同的Map会有同样的Key值输出）。逻辑上，我们可以将不同Map输出的同一个Key的数据合起来看做一个小Partition（Finer Partition，FP）

• reduce
  reduce函数则是对map提取出来的数据进行处理。

3. 具体的一个mapReduce job 执行过程,下图还是很清楚的

mapreduce 的执行过程是有中间数据落地的，也就是内从和磁盘来回交换数据，以后会有Spark的介绍，其中Spark执行一个MapReduce操作数据是不落地的所有数据都会被拉进内存执行操作。