Hadoop之小文件

小文件问题

Hadoop被设计用来存储TB甚至更大级别的数据集

file ==> block ==> 3

                      ==> DN      directory

上述的信息在hadoop中称为元数据信息，这些信息会加载到NN上，NN启动的时候会将这些信息加载到内存里面，则每一个文件怎么拆的、存在哪里、副本信息都要存在内存里面。

举个

一个100M的文件和1个1K的文件，都需要存储元数据信息，设想一下这类小文件如果有很多，NN的压力会不会很大。

什么是小文件

CDH版本的默认的blocksize=128M，1.x版本的默认是64M，自然了blocksize可以设置。

200M的文件，当默认的是64M会被拆成几个block？当默认的是128M会被拆成几个block？当默认的是256M会被拆成几个block？

block的数量决定了元数据信息的多少。

关于多大的算小文件，1M？10M？目前没有标准答案。但是可以从生产环境的NN的内存是多少？能存储多少个block？来推该生产环境下的小文件是多大。这些肯定要做好监控呀。

小文件怎么产生的

1. 通过某种手段把数据采集过来的，若不做调优的话，采集到HDFS的数据是会有很多小文件的，即源数据小文件就很多了
   1. Flume
   2. Logstash
   3. WebServer ==>  HDFS
2. MR/Hive/Spark（Core / SQL / Streaming）
   1. ETL     有可能会产生很多小文件
   2. Stat（表到表：SQL）      若用类似数据仓库的思想，分好几层，若不把控好，层级越多，则每个层级有可能会有一堆小文件
   3. MR启动Map作业或者reduce作业都是通过进程级别的方式启动的，启动进程，销毁进程的时间消耗比较大
   4. Spark底层是一个线程池，一个文件相当于对应一个Task，相当于一个partition，小文件太多也要跑很多轮。

reducer个数==> 文件输出的个. 

• 多     ==> 文件个数多
• 少     ==> skew

小文件解决方案

删？ 合？

删：

• 原始数据处理完了可以删，但是ETL和统计数据通常是要保存一定时间的，不可以删。
• 那些不可以删的，可以尝试迁移（distcp：大的集群之间的copy，是MR作业，不需要reduce）到冷集群等地方去，在迁移的时候可以做一些合并

合：

• SequenceFile：貌似近几年的场景下没啥用处
• CombinerFileInputFormat：文本、列式（ORC/Parquet）能否真通过这种方式解决
• Hive合并小文件的参数控制：性能可能不高，若没有使用Hive的场景如何解决
• Hadoop追加：也得分场景
  • 离线处理1天的数据 ==> 目录，若数据是错误的，需要重跑，还能追加么？
• HBase：
• Spark / Flink：通过他们的蒜子解决，例如一个Task处理多少数据
• SQL：Hive可以设置reducer个数，Spark可以设置并行度

仅有map，不需要reduce的场景：MapJoin、 ETL、sqoop等

可以去Hadoop的官网，了解一下WebHDFS(REST API)，Federation，Snapshots，Quotas and HDFS，Short-Circuit Local Reads，Centralized Cache Management 

 

狭义的Hadoop：HDFS MR YARN，这些都是有竞品的

HDFS VS 

MR VS Spark

YARN VS Mesos

 

 

参考：慕课网：Hadoop 系统入门+核心精讲