1. 背景介绍
谈到分布式系统，就不得不提到Google的三驾马车:GFS[1],MapReduce[2]和BigTable[3]。虽然Google没有开源这三个技术的实现源码，但是基于这三篇开源文档, Nutch项目子项目之一的Yahoo资助的Hadoop分别实现了三个强有力的开源产品：HDFS，MapReduce和HBase。在大数据时代的背景下，许多公司都开始采用Hadoop作为底层分布式系统，而Hadoop的开源社区日益活跃，Hadoop家族不断发展壮大，已成为IT届最炙手可热的产品。
本文将在简单介绍Hadoop主要成员的基础上，探讨Hadoop在应用中的改进。
第一部分是对Hadoop诞生和现状的简单描述。
第二部分将简单介绍hadoop的主要成员，主要包括他们的基本特性和优势。分别是分布式文件系统HDFS，NoSQL家族之一的HBase，分布式并行编程方式MapReduce以及分布式协调器Zookeeper。
第三、四、五部分分别介绍了Hadoop的不同改进和使用。按次序分别是facebook的实时化改进，HadoopDB，以及CoHadoop。
最后是我的总结和体会。
如果对Hadoop的基本架构和基础知识熟悉，可以从第三部分看起。
2. 关于Hadoop
Hadoop本身起源于Apache Nutch项目，曾也是Lucene项目的一部分。从结构化数据，到半结构化数据和非结构化数据，从关系型数据库到非结构化数据库（NoSQL），更高性能的并行计算/批处理能力和海量数据存储成为现代主流IT公司的一致需求。
2.1 HDFS
HDFS，全称Hadoop Distributed Filesystem，是Hadoop生态圈的分布式文件系统。分布式文件系统跨多台计算机存储文件，该系统架构于网络之上，诞生即具备了网络编程的复杂性，比普通磁盘文件系统更加复杂。
2.1.1 HDFS数据块
HDFS以流式数据访问模式来存储超大文件，运行于商用硬件集群上。数据集通常由数据源生成或从数据源复制而来，接着长时间在此数据集上进行格类分析处理。每次都将涉及该数据集的大部分数据甚至全部，因此读取整个数据集的时间延迟比读取第一条记录时间的延迟更重要。而一次写入、多次读取是最高效的访问模式。有一点要说明的是，HDFS是为高数据吞吐量应用优化的，而这可能会以高时间延迟为代价。
HDFS默认的最基本的存储单元是64M的数据块(block)。HDFS的块比磁盘块(512字节)大得多，目的是为了最小化寻址开销。HDFS上的文件也被划分为多个分块(chunk)，作为独立存储单元。与其他文件系统不同的是，HDFS中小于一个块大小的文件不会占据整个块的空间。
块抽象给分布式文件系统带来的好处：
Ø 文件的大小可以大于网络中任意一个磁盘的容量。
Ø 使用块抽象而非整个文件作为存储单元，大大简化了存储子系统的设计，同时也消除了对元数据的顾虑。
Ø 块非常适合用于数据备份进而提供数据容错能力和可用性。
2.1.2 Namenode和Datanode
namenode和datanode的管理者-工作者模式有点类似主从架构。namenode对应多个datanode。namenode管理文件系统的命名空间，维护文件系统和内部的文件及目录。datanode是文件系统的真正工作节点，根据需要存储并检索数据块（一般受namenode调度），并且定期向namenode发送它们所存储的块的列表。
namenode一旦挂掉，文件系统的所有文件就丢失了，不知道如何根据datanode的块来重建文件。因此，namenode的容错或者备份是很重要的。在HDFS中存在secondarynamenode（虽然不完全是个namenode的备份，更确切的是个辅助节点）周期性将元数据节点的命名控件镜像文件和修改日志合并。
2.2 HBase
跟传统的关系型数据库（RDBMS）基于行存储不同，HBase是一个分布式的，在HDFS上开发的面向列的分布式数据库。HBase行中的列分成“列族”（column family），所有的列族成员有相同的前缀。所有列族成员都一起存放在文件系统中。
2.2.1 与RDBMS比较
HBase通过在HDFS上提供随机读写来解决Hadoop不能处理的问题。HBase自底层设计开始即聚焦于各种可伸缩性问题：表可以很“高”，有数十亿个数据行；也可以很“宽”，有数百万个列；水平分区并在上千个普通商用机节点上自动复制。表的模式是物理存储的直接反映，使系统有可能提高高效的数据结构的序列化、存储和检索。
而RDBMS是模式固定、面向行的数据库且具有ACID性质和复杂的SQL查询处理引擎，强调事物的强一致性（strong consistency）、参照完整性（referential integrity）、数据抽象与物理存储层相对独立，以及基于SQL语言的复杂查询支持。
2.2.2 HBase特性
简单列举下HBase的关键特性。
Ø 没有真正的索引：行是顺序存储的，每行中的列也是，所以不存在索引膨胀的问题，而且插入性能和表的大小有关。
Ø 自动分区：在表增长的时候，表会自动分裂成区域（region），并分布到可用的节点上。
Ø 线性扩展：对于新增加的节点，区域自动重新进行平衡，负载会均匀分布。
Ø 容错：大量的节点意味着每个节点重要性并不突出，所以不用担心节点失效问题。
Ø 批处理：与MapReduce的集成可以全并行地进行分布式作业。
2.3 MapReduce
MapReduce是一种可用于数据处理的编程模型，是一个简单易用的软件框架，基于它写出来的应用程序能够运行在由上千个商用机器组成的大型集群上，并以一种可靠容错的方式并行处理上T级别的数据集。
2.3.1 Map & Reduce
一个Map/Reduce 作业（job）通常会把输入的数据集切分为若干独立的数据块，由 map任务以完全并行的方式处理它们。框架会对map的输出先进行排序，然后把结果输入给reduce任务。通常作业的输入和输出都会被存储在文件系统（一般为HDFS）中。整个框架负责任务的调度和监控（jobtracker协调作业的运作，tasktracker运行作业划分后的任务），以及重新执行已经失败的任务。
通常，Map/Reduce框架和分布式文件系统是运行在一组相同的节点上的，也就是说，计算节点和存储节点通常在一起。这种配置允许框架在那些已经存好数据的节点上高效地调度任务，这可以使整个集群的网络带宽被非常高效地利用。
2.3.2 Matser/Slave架构
Map/Reduce框架由一个单独的master JobTracker 和每个集群节点一个slave TaskTracker共同组成。master负责调度构成一个作业的所有任务，这些任务分布在不同的slave上，master监控它们的执行，重新执行已经失败的任务。而slave仅负责执行由master指派的任务。
应用程序至少应该指明输入/输出的位置（路径），并通过实现合适的接口或抽象类提供map和reduce函数。再加上其他作业的参数，就构成了作业配置（jobconfiguration）。然后，Hadoop的 job client提交作业（jar包/可执行程序等）和配置信息给JobTracker，后者负责分发这些软件和配置信息给slave、调度任务并监控它们的执行，同时提供状态和诊断信息给job-client。
2.4 Zookeeper
Zookeeper是一个高可用的分布式数据管理与系统协调框架。简单的说，就是个分布式协调器。它以主从的架构，基于Paxos算法实现，保证了分布式环境中数据的强一致性，也因此各种分布式开源项目中都有它的身影。
2.4.1 Zookeeper机制
Zookeeper的核心是一个精简的文件系统，它的原语操作是一组丰富的构件（building block），可用于实现很多协调数据结构和协议，包括分布式队列、分布式锁和一组同级节点中的“领导者选举”（leader election）。
Zookeeper实现的是Paxos算法。Zookeeper集群启动后自动进行leader selection，投票选出一台机器作为Leader，其他的都是Follower。通过heartbeat的机制，Follower从Leader获取命令或者消息，同步自己的数据，和Leader保持一致。为了保证数据的一致性，只有当半数以上的Follower的状态和Leader成功同步了之后，才认为这次数据更新是成功的。为了选举方便，Zookeeper集群数目是奇数。