Hadoop小文件抛析

1、小文件问题
Hadoop存储TB甚至更大级别的数据集
文件file—》拆分成块back–> 3–>存放在 DN directory–〉这些信息 叫做元数据信息
100MB vs 1kb 100MB要加载那 1kb还是要加载元数据
这些元数据 加载在NN 的内存中如果文件特别小特别多NN主机的压力就会特别大

2、什么是小文件
CDH blocksize 2.x 128MB 1.x 64MB 当然这个blocksize是可以调的
128MB 一个200MB的文件会被拆分成多少个？？？？
64MB 一个200MB的文件会被拆分成多少个？？？？
234MB 一个200MB的文件会被拆分成多少个？？？？
所以blacks的多少决定了原数据的大小
1KB 算是小文件？？？ 1MB算是小文件？？？ 2MB 算是小文件？？
拿什么事小文件，这个根据不同公司的不同业务，不同硬件的内存来决定小文件的大小
可以根据业务的数据和内存来推算适合你的小文件
NN的内存是多少？能存储多少个小文件
3、小文件怎么产生的
小文件怎么产生的？？出现了故障—》分析为什么会出现这个故障—〉解决或者规避这个故障
1、通过某种手段把数据采集过来
Flume 采集到HDFS的数据如果处理不好本身就会有许多许多的小文件。
Logstash
WebServer ===>HDFS

2、MR/Hive/Spark（core/sql/streaming）
ETL 清洗数据时会产生很多小文件
stat 统计结果 分成好几成又是好多小文件
4、小文件解决方案

1、删除？
原始数据：原始数据确实是可以删除的
ETL数据那：这个根据不通公司的不同业务 一般都是要保存一段时间的 也就是说在1年或者2年以后是可以删除的。---->spark/flink
stat统计结果那：最好保留 ，倒是也可以删除但倒是要回溯数据难道还要用ETL在跑一遍？ETL数据如果也删除了那，原始数据也没了那？---->sql hive —迁移

2、合数据？
SequenceFile 优点、缺点、提示：基本没有他合本前和合本后大小没啥区别
CombineFileInputFormat 提示 文本、列式（ORC/Parquet）能否处理
Hive 合并小文件的参数控制 这个倒是可以控制一点而且性能不怎么样 再有如果 没有使用到Hive那
Hadoop追加：离线处理 1天处理一批—》ETL ==〉目录
数据错了—》重跑 append 到最后数据还对吗？
Hbase 也能决绝一些问题但问题在于如果生产上用不到Hbase，单位解决小文件装一个也不怎么样
spark/flink:可以设置他的算子一个tasks能处理多少任务量

那些场景不需要reduce, mapjoin ETL sqoop

需要了解的：WebHDFS(REST API)\Federation\Snapshhts\Quotas and HDFS\Short Circuit local reads
Centralized Cache Management