CharlesCFA的博客

哎，鹅厂面试问到这个题一时间没想出很好的答案，就说了运用CombineInputTextFormat的方法，其实还有别的方法，现在总结一下，纪念一下自己惨痛的经历1.最简单的是避免产生小文件，在数据采集的时候，就将小文件或小批数据合成大文件再上传HDFS。2.Hadoop Archive为了缓解大量小文件带给namenode内存的压力，Hadoop 0.18.0引入了Hadoop Archives(HAR files)，其本质就是在HDFS之上构建一个分层文件系统。通过执行hadoop archive

一、block块举例：block块官方设置的是64m,现在多数用的是128m(Hadoop 2.0x)举例：一个文件130M % 128M=1…2m结果是1个块128m，1个块2m一碗水130ml 一个瓶子规格容量128ml只能2个瓶子：第1个装满128ml 第二个装不满，实为2ml二、小文件的危害HDFS 适应场景: 大文件存储，小文件是致命的举例:接上个例子130m的文件10m的10个文件 10块30m的1个文件 1块共有11个文件： 11块系统维护一般轻量级会比较好，本

思考：NameNode中的元数据是存储在哪里的？首先，我们做个假设，如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦NameNode节点断电，就会产生数据丢失。因此，引入Edits文件(

HDFS中的文件在物理上是分块存储（Block），块的大小可以通过配置参数(dfs.blocksize）来规定，默认大小在Hadoop2.x版本中是128M，老版本中是64M。那么，问题来了，为什么一个block的大小就是128M呢？默认为128M的原因，基于最佳传输损耗理论！不论对磁盘的文件进行读还是写，都需要先进行寻址！最佳传输损耗理论：在一次传输中，寻址时间占用总传输时间的1%时，本次传输的损耗最小，为最佳性价比传输！目前硬件的发展条件，普通磁盘写的速率大概为100M/S, 寻址时间一般为1

在linux下，我们经常需要两台机器之间拷贝文件，或者由于业务需要备份文件，那就不得不用到scp和rsync两个命令。1.scpcp 在本机复制文件，这个命令我们经常使用，但是跨机器复制cp就不行了，scp可以跨机器复制文件，示例：scp -Crvp -l 1 test/ test@10.16.88.88:/usr/local## test/ 源文件 test@10.16.88.88:/usr/local 目标地址参数解释:-C(大写): 允许传输过

Hadoop出错了怎么办？找日志！环境：[root@hadp-master hadoop-2.7.4]# hadoop versionHadoop 2.7.4Hadoop的日志大致可以分为两类：（1）Hadoop系统服务输出的日志；（2）Mapreduce程序输出来的日志(应用程序日志)。这两类的日志存放的路径是不一样的。本文基于Hadoop 2.x版本进行说明的，其中有些地方在Hadoop 1.x中是没有的，请周知。一、Hadoop系统服务输出的日志 诸如Nodemanger、Resou