前段时间，公司Hadoop集群整体的负载很高，查了一下原因，发现原来是客户端那边在每一个作业上擅自配置了很大的堆空间，从而导致集群负载很高。下面我就来讲讲怎么来现在客户端那边的JVM堆大小的设置。 我们知道，在mapred-site.xml配置文件里面有个mapred.child.java.opts配置，专门来配置一些诸如堆、垃圾回收之类的。看 w397090770 10年前 (2014-03-18) 19025℃ 0评论10喜欢
先来了解一下Hadoop中何为小文件：小文件指的是那些文件大小要比HDFS的块大小(在Hadoop1.x的时候默认块大小64M，可以通过dfs.blocksize来设置；但是到了Hadoop 2.x的时候默认块大小为128MB了，可以通过dfs.block.size设置)小的多的文件。如果在HDFS中存储小文件，那么在HDFS中肯定会含有许许多多这样的小文件(不然就不会用hadoop了)。而HDFS的 w397090770 10年前 (2014-03-17) 15261℃ 1评论10喜欢
如果你想知道Spark作业运行日志，可以查看这里《Spark应用程序运行的日志存在哪里》 Hadoop的日志有很多种，很多初学者往往遇到错而不知道怎么办，其实这时候就应该去看看日志里面的输出，这样往往可以定位到错误。Hadoop的日志大致可以分为两类：（1）、Hadoop系统服务输出的日志；（2）、Mapreduce程序输出来的日志 w397090770 10年前 (2014-03-14) 52720℃ 5评论40喜欢
在《Hadoop 1.x中fsimage和edits合并实现》文章中提到，Hadoop的NameNode在重启的时候，将会进入到安全模式。而在安全模式，HDFS只支持访问元数据的操作才会返回成功，其他的操作诸如创建、删除文件等操作都会导致失败。 NameNode在重启的时候，DataNode需要向NameNode发送块的信息，NameNode只有获取到整个文件系统中有99.9%（可以配 w397090770 10年前 (2014-03-13) 17217℃ 3评论16喜欢
在《Hadoop 1.x中fsimage和edits合并实现》文章中，我们谈到了Hadoop 1.x上的fsimage和edits合并实现，里面也提到了Hadoop 2.x版本的fsimage和edits合并实现和Hadoop 1.x完全不一样，今天就来谈谈Hadoop 2.x中fsimage和edits合并的实现。 我们知道，在Hadoop 2.x中解决了NameNode的单点故障问题；同时SecondaryName已经不用了，而之前的Hadoop 1.x中是通过Se w397090770 10年前 (2014-03-12) 12374℃ 0评论20喜欢
在《Hadoop文件系统元数据fsimage和编辑日志edits》文章中谈到了fsimage和edits的概念、作用等相关知识，正如前面说到，在NameNode运行期间，HDFS的所有更新操作都是直接写到edits中，久而久之edits文件将会变得很大；虽然这对NameNode运行时候是没有什么影响的，但是我们知道当NameNode重启的时候，NameNode先将fsimage里面的所有内容映像到 w397090770 10年前 (2014-03-10) 9718℃ 2评论18喜欢
在《Hadoop NameNode元数据相关文件目录解析》文章中提到NameNode的$dfs.namenode.name.dir/current/文件夹的几个文件：[code lang="JAVA"]current/|-- VERSION|-- edits_*|-- fsimage_0000000000008547077|-- fsimage_0000000000008547077.md5`-- seen_txid[/code] 其中存在大量的以edits开头的文件和少量的以fsimage开头的文件。那么这两种文件到底是什么，有什么用 w397090770 10年前 (2014-03-06) 20290℃ 1评论45喜欢
下面所有的内容是针对Hadoop 2.x版本进行说明的，Hadoop 1.x和这里有点不一样。 在第一次部署好Hadoop集群的时候，我们需要在NameNode（NN）节点上格式化磁盘：[code lang="JAVA"][wyp@wyp hadoop-2.2.0]$ $HADOOP_HOME/bin/hdfs namenode -format[/code] 格式化完成之后，将会在$dfs.namenode.name.dir/current目录下如下的文件结构[code lang="JAVA"]c w397090770 10年前 (2014-03-04) 13236℃ 1评论17喜欢
Snappy是用C++开发的压缩和解压缩开发包，旨在提供高速压缩速度和合理的压缩率。Snappy比zlib更快，但文件相对要大20%到100%。在64位模式的Core i7处理器上，可达每秒250~500兆的压缩速度。 Snappy的前身是Zippy。虽然只是一个数据压缩库，它却被Google用于许多内部项目程，其中就包括BigTable，MapReduce和RPC。Google宣称它在这个库本 w397090770 10年前 (2014-03-03) 13432℃ 1评论2喜欢
分布式计算开源框架Hadoop近日发布了今年的第一个版本Hadoop-2.3.0，新版本不仅增强了核心平台的大量功能，同时还修复了大量bug。新版本对HDFS做了两个非常重要的增强：（1）、支持异构的存储层次；（2）、通过数据节点为存储在HDFS中的数据提供了内存缓存功能。 借助于HDFS对异构存储层次的支持，我们将能够在同一个Hado w397090770 10年前 (2014-03-02) 4106℃ 0评论1喜欢
