1、谈谈对HDFS的理解？HDFS这种存储适合哪些场景？

HDFS即Hadoop Distributed File System，Hadoop 分布式文件系统。它为的是解决海量数据的存储与分析的问题，它本身是源于Google在大数据方面的论文，GFS-->HDFS;

HDFS由Client、NameNode、DataNode、Secondary NameNode组成；Client负责响应用户的各种请求比如上传、下载等；NameNode负责存储HDFS的元数据和处理用户的读写请求，比如数据块存储在DataNode的哪个地方；DataNode负责存储实际的数据块和数据的读写功能，Secondary NameNode主要是辅助NameNode，分担其工作量；定期合并fsimage和fsedits，推送给NameNode；在紧急情况下，可辅助恢复NameNode。

适合场景

低成本：Hadoop不需要特别贵的机器，可运行于普通廉价机器，所以比较节约成本。

高容错：适合存储需要高容错性的文件存储，文件安全（HDFS高可用和高容错性体现之一就是block的副本机制和主备思想）

大数据：这里非常大指的是几百GB、TB、或者PB级别，需要高吞吐量，对数据读写延时没有要求。

高吞吐：扩展能力强：集群可以很快速拓展到很大规模，满足存放海量数据，这里一般是指PB,EB级别。

 单次写入多次读取：适合一次写入、多次读取，既适合数据分析场景（适合OLAP场景）。但是数据读写延迟高，以及不支持单条update，不适合那些对数据访问毫秒级低延迟的应用。

2、HDFS小文件问题

定义

数据大小远小于默认数据块大小文件。

原因

hadoop设计之初是为了OLAP用的，后来越来越多的人，希望hadoop能朝着OLTP的方向发展，并产生了很多工具，例如spark,flink等。实时性要求越高，小文件就会越多。当然这也跟量也有关系，量越大，小文件越少，小文件问题越小。

影响

存储层面：因为元数据存储于内存当中，大量小文件占用大量内存。

计算层面：每个小文件都会起一个MapTask，1个MapTask默认内存1G。浪费资源。

解决方式

入库前：数据采集或标准入库之前，将小文件进行合并大文件再上传入库

存储：Hadoop Archive归档–>将多个小文件打包成一个HAR文件，减少对NN内存的使用

计算方面：CombineTextInputFormat用于将多个小文件在切片过程中生成一个单独的切片或者少量的切片

其他：自己写一个MR程序将产生的小文件合并成一个大文件。如果是Hive或者Spark有merge功能自动帮助我们合并。有小文件场景开启JVM重用；如果没有小文件，不要开启JVM重用，因为会一直占用使用到的Task卡槽，直到任务完成才释放。JVM重用可以使得JVM实例在同一个job中重新使用N次，N的值可以在Hadoop的mapred-site.xml文件中进行配置。通常在10-20之间