Hadoop上小文件如何存储？
Block是文件块，HDFS中是以Block为单位进行文件的管理的，一个文件可能有多个块，每个块默认是3个副本，这些块分别存储在不同机器上。块与文件之前的映射关系会定时上报Namenode。HDFS中一个块的默认大小是64M，其大小由参数dfs.block.size控制。这里面先引申几个问题出来：
问题1：块大小要怎么设置为一个合理值，过大设置和过小设置有什么影响？
问题2：如果一个文件小于所设置的块大小，实际占用空间会怎样？
问题3：一个Namenode最多能管理多少个块，什么时候会达到瓶颈？
针对这些问题，后面会展开介绍，这里还是先关注下架构方面。针对块方面，有几个单位概念需要弄清楚： Block、Packet和Chunk。Block上面有描述，Packet和Chunk如下：
1 Packet: 其比块要小很多，可以理解为Linux操作系统最小盘块概念，一般为64KB，由参数dfs.write.packet.size控制，是client向Datanode写入数据的粒度，即client向Datanode写数据时不是一次以Block为单位写的，而是被分成若干Packet，放入pipeline顺序追加写入到Block中，示意图如下：
2 Chunk: 比Packet更小，是针对Packet数据校验粒度来设计的，一般是512B,由参数io.bytes.per.checksum控制，同时还带有一个4B的校验值，所以可以认为一个Chunk是516B
上面说到Chunk是针对数据校验的，那一个Packet有多少个chunk校验呢，如果Packet默认是64KB, 那计算公式为：chunk个数=64KB/516B=128。也就是对于一个Packet来说，数据值与校验值比例大概为128:1, 对于一个块来说，假设是64M，会对应512KB的校验文件。
Packet的示意图中还一个Header信息，实际存储的是Packet的元数据信息，包括Packet在block中的offset, 数据长度，校验编码等。
HDFS块设计原则
有人可能会问，集群存储有大文件也有小文件，那块大小该如何设计呢，这里应该要考虑2个准则：
1.减少内存占用：对于Namenode来说，单机内存毕竟有限，文件块越多，元数据信息越大，占用内存越多，如果文件数量级很大的话，单机将无法管理；
2.减少硬盘寻道时间： 数据块在硬盘为连续存储，对于普通SATA盘，随机寻址较慢， 如果块设置过小，一个文件的块总数会越多，意味着硬盘寻址时间会加长，自然吞吐量无法满足要求；如果块设置过大，一方面对于普通盘来说IO性能也比较差，加载时会很慢，另一方面，块过大，对于多副本来说，在副本出问题时，系统恢复时间越长。
所以设置合理的块大小也很重要，一般来说根据集群的需求来设定，比如对于使用到HBase的场景，一般数据量会比较大，块不宜设置太小，参考值一般为128MB或256MB，这样能尽量避免频繁块刷写和块元数据信息的膨胀；对于存储小文件的场景，如图片，块可设置成默认64MB大小，一个块中存储多个图片文件，后面会详细介绍。
