HDFS小文件问题
小文件过多有什么坏处？
主要是NameNode内存会受限。由于NameNode会将文件系统的元数据都存储在内存中，因此所能存储的文件总量受限于NameNode的内存总容量。每个文件、目录和数据块大约占150个字节，过多的小文件会大量消耗NameNode的内存量增加namenode寻址的时间怎么处理小文件过多的问题？
数据未上传到HDFS前的处理：从根源上解决问题，每小时抽取一次数据改为每天抽取一次数据积累数据量数据已上传到HDFS：通过程序将小文件和并成大文件 HDFS中NameNode内存总共有多大
Hadoop 2.x系列，默认为2000mHadoop 3.x系列，动态分配内存，最小值为1G，每增加100万个Block，增加1G内存 HDFS支持并发写入么？
不支持，客户端想写数据必须续约（许可证），同时只能有一个客户端写数据，直到这个客户端契约过期，下个客户端才可以获取契约并写入数据，详见写数据流程 HDFS的特性与优点
大数据分而治之，主要针对一次写入多次读取的场景分布式，扩容方便高可靠，稳定成本低，只需要几台磁盘大点的服务器 fsimage与editlogs是的作用？
NameNode主要维护了两个文件，fsimage与editlogsfsimage：最近元数据的检查点，包括数据块描述信息、修改时间、访问时间、元数据的权限、副本个数等。相当于快照editlogs：所有元数据，写入、删除、移动的操作，都会记录在这里NameNode 和 SecondaryNameNode的区别与联系
NameNode负责管理元数据SecondaryNameNode见名字像是NameNode的备份，实则不是，这也是hdfs命名的缺陷，SecondaryNameNode主要负责 standby namenode中的checkporint动作，将内存中的fsimage合并到磁盘上的fsimage中HDFS有哪些设计不合理的地方
数据不能实时处理不能并发写入小文件太多会占用过多namenode中的内存，增加namenode的寻址地址的时间命名不规范简述hadoop的二级排序原理
通过自定义分区实现，因为如果采用默认分区策略很有可能产生数据倾斜现象哪个key分配到哪个分区这个过程自定义控制，将key分区好后，将key进行排序再将每个key中的值进行排序MapReduce跑的慢的原因
key设计不合理 或 数据倾斜小文件过多数据太大导致spill和merge的次数过多Map和Reduce的个数设计的不合理数据倾斜
key分布不均匀业务数据本身的特性
数据混乱，空值过多，可将空值的key变成一段字符串+随机数，把倾斜的数据分布到不同的reduce上，由于值是null关联不上( where 值 != null )，不会影响最终结果建表时考虑不周
表设计的不好，没有按照建模思想建表sql 语句本身就有数据倾斜
join
做好列裁剪和数据过滤操作map join ，大小表join ，让小表先进入到内存group bycount distinct
可用sum() + group by 方式替换Hadoop Rpc 原理
Rpc 是远程（不同进程）间过程（方法）的调用 的缩写形式，分为客户端和服务端，服务端会一直开启一个服务等待别人的调用，客户端获取服务端的代理，调用服务端的方法后，方法在服务端上执行Hadoop Rpc是通过构建者设计模式构建的
