随着捕获的数据的数量每年增加，我们的存储也需要增加。很多公司正在认识到“数据为王”这一道理，但是我们如何分析这些数据呢？答案就是“通过Hadoop”。在这篇文章中，也是三部曲中的第一篇，Steven Haines 对Hadoop的架构作了综述，并从一定高度上演示了如何编写MapReduce应用程序。
在数据处理的发展进程中，我们从文件转到关系型数据库，从关系型数据库转到NoSQL数据库。实质上，随着捕获的数据的数据增加，我们的需求也在增加，传统的模式已不能胜任。那些老的数据库能处理好的数据大小是以MB或GB为单位的，但是现在很多公司认识到“数据为王”，捕获的数据数量是以TB和PB为单位的。即使采用NoSQL存储数据，“我们如何分析如此数量的数据？”这一问题依然存在。
对于这一问题最流行的答案就是："Hadoop".Hadoop 是一个开源框架，用于开发和执行用来处理巨大数量数据的分布式应用。Hadoop 用来运行在大型的集群上，集群内的商品机可以是你的数据中心内不正在使用的机器，或者甚至是 Amazon EC2 映像。运行在商品机上的危险当然就是如何处理故障(failure)。Hadoop的架构假设硬件会产生故障，因此，它能够很出色地应对大部分故障。而且，Hadoop的架构允许它近乎线性地伸缩，因此当对处理能力的需求增加时，唯一的限制就是你向集群添加更多机器的预算。
推荐阅读：
提高Hadoop的MapReduce job效率笔记
这篇文章将会对Hadoop的架构作一概述，描述它如何实现上面所说的各种亮点，并从一定高度上演示如何编写MapReduce应用程序。
Hadoop 架构
在一定高度上来说，Hadoop的哲学概念就是推着分析程序靠近它打算分析的数据，而非要求程序跨网络地读取数据。
因此，Hadoop 提供了自己的文件系统，贴切地命名为Hadoop File System(HDFS)。当你上传数据到HDFS时，Hadoop将会在整个集群内分割你的数据(保存数据的多份副本以防硬件故障)，然后会部署你的程序到包含该程序准备操作的数据的机器上。
像许多NoSQL数据库那样，HDFS采用键(key)和值(value)而非关系组织数据。换句话说，每块数据都有一个唯一的键(key)，以及与该键相关联的值。键之间的关系，如果存在的话，由程序定义，而非HDFS。并且实际上，你必须对你的问题域换一种稍微不同的方式思考，才能意识到Hadoop的强大威力(见下面关于MapReduce的章节)。
组成Hadoop的组件为：
* HDFS:Hadoop文件系统是一种分布式文件系统，被设计用来在集群内跨节点地保存海量数据(此处海量被定义为文件的大小为100+TB)。Hadoop提供API及命令行接口与HDFS交互。
* MapReduce Application:下一章节将评论MapReduce的细节，但是在此简单陈述，MapReduce 是一种函数式编程范式，用来分析你HDFS的单个记录。然后它将结果组装成可用的解决方案。Mapper负责数据处理步骤，而Reducer接受Mapper的输出,并对同一键值的数据排序。
* Partitioner:partitioner负责把特定的分析问题划分成可行的数据块以供各种Mapper之用。HashPartioner 是一种partitioner,用来根据HDFS中的数据的行来划分工作，但是你可以随便创作自己的partitioner，如果你需要采用不同的方式划分你的数据。
* Combiner:如果由于某些原因，你想进行local reduce，即在数据送回到Hadoop之前combine数据，那么你需要创作一个combiner。一个combiner执行reduce步骤，即将值(value)根据键(key)分组结合，但是是在返回键/值(key/value)对到Hadoop进行适当的reduction之前，在单一节点上操作。
* InputFormat:大部分时间默认的reader会工作正常，但是如果你的数据不是按照标准的方式进行的格式化，即“key, value”或者“key[tab]value”,那么你将需要定制一个InputFormat实现。
* OutputFormat:你的MapReduce应用将会用InputFormat读取数据，然后通过OutputFormat将数据写出。标准格式，例如“key[tab]value”,是被支持的，但是如果你想作别的事情，那么你需要创作你自己的OutputFormat实现。
又Hadoop应用被部署在支持高度伸缩性和弹性的设施上，以下组件也被包含：