NameNode优化笔记 (一)

集群只要规模上了1000台, 问题就会更多。 RPC, NameNode锁、JobTracker锁、及DataNode, TaskTracker的问题都是一大堆。我们于12月初解决了JobTracker的一些性能问题, 但是NameNode的吞吐量一直没有上来。针对这些问题我们开了几次紧急会议, 会议的决定是由我负责开展一个NameNode优化专门项目。经过大约一个月的努力, 我们的NameNode吞吐量已经上升8+倍。接下来的笔记将连载我们是如何发现NameNode的问题, 并进行NameNode优化的，敬请期待!

Hadoop现有测试框架探幽

背景

从使用hadoop的第一天开始，就一直没有离开过对Hadoop自身功能的开发以及hadoop本身bug的修复的相关开发。这样的开发模式已经持续了好几年，但是可以从中发现的一个现象：对于我们修复的bug或者开发的功能，一直都没有一种很规范，很统一，高效，好管理，并且一目了然的测试的方式。常常的现象是：开发了一个功能或修复了一个bug后，就针对该修改进行一些人为手动的环境模拟和测试，然后测试确认没有问题以后，就合入基线版本进行打包上线。这种模式的缺点是：

使用MRUnit实现MapReduce程序的单元测试

Hadoop的MapReduce程序的测试，一直比较麻烦。因为不方便抽取出来，作为独立的Junit测试。所以很多时候，我们都是写一个Main函数，然后在里面手工调用Map或者Reduce，用System.out.println打印出结果，人眼测试，而且还要判断OutputCollector是否为空，不然直接Main调用还会抛NullPointerException。 这样最大的弊端，是无法实现自动化的断言判断，达到测试驱动和检查的目的。那么对程序的任何改动，都需要放到Hadoop集群上，跑个十几分钟才能肯定到底对不对。我们需要一个更快的方法，能够方便的自动化的对MR程序进行测试，从而达到测试驱动和敏捷开发的状态。 What’s MRUnit：

hadoop-0.20.1+120 hive-0.3.99.1+0 试用hwi（hive web interface）

hive迟迟不能支持hadoop 0.20的局面解决了，小试一把。 闲话少说，得益于cloudera团队的努力，hive在昨天9.21号开始能够支持hadoop 0.20.1，下载测试版本软件。 http://archive.cloudera.com/cdh/testing/ http://archive.cloudera.com/cdh/testing/hadoop-0.20.1+120.tar.gz http://archive.cloudera.com/cdh/testing/hive-0.3.99.1+0.tar.gz 非常简单的解压，配置conf即可使用,hadoop的配置见前面的文章。 hive在使用前注意export   HADOOP_HOME=/home/hadoop/hadoop-0.20.1+120,而不是readme里面的export HADOOP,一味跟着readme，将不能体验hive的强大功能，因为hive命令后就没有输出了，呵呵。 建立几个测试表使用一下。