随着捕获的数据的数量每年增加，我们的存储也需要增加。很多公司正在认识到“数据为王”这一道理，但是我们如何分析这些数据呢？答案就是“通过Hadoop”。在这篇文章中，也是三部曲中的第一篇，Steven Haines 对Hadoop的架构作了综述，并从一定高度上演示了如何编写MapReduce应用程序。
在数据处理的发展进程中，我们从文件转到关系型数据库，从关系型数据库转到NoSQL数据库。实质上，随着捕获的数据的数据增加，我们的需求也在增加，传统的模式已不能胜任。那些老的数据库能处理好的数据大小是以MB或GB为单位的，但是现在很多公司认识到“数据为王”，捕获的数据数量是以TB和PB为单位的。即使采用NoSQL存储数据，“我们如何分析如此数量的数据？”这一问题依然存在。
对于这一问题最流行的答案就是：”Hadoop”.Hadoop 是一个开源框架，用于开发和执行用来处理巨大数量数据的分布式应用。Hadoop 用来运行在大型的集群上，集群内的商品机可以是你的数据中心内不正在使用的机器，或者甚至是 Amazon EC2 映像。运行在商品机上的危险当然就是如何处理故障(failure)。Hadoop的架构假设硬件会产生故障，因此，它能够很出色地应对大部分故障。而且，Hadoop的架构允许它近乎线性地伸缩，因此当对处理能力的需求增加时，唯一的限制就是你向集群添加更多机器的预算。
这篇文章将会对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应用被部署在支持高度伸缩性和弹性的设施上，以下组件也被包含：
* NameNode: NameNode是HDFS的主节点，控制从节点的DataNode的守护进程(daemon);它知道你所有的数据存放在何处，知道数据如何被拆分成块，知道这些数据块被部署在哪个节点上，知道分布式文件系统的整体工作状态。简而言之，它是整个Hadoop集群中最重要的节点。每个集群都有一个NameNode,并且NameNode是Hadoop集群中的single-point of failure(SPOF)。
* Secondary NameNode:Secondary NameNode监视HDFS集群的状态，并且对保存在NameNode中的数据拍摄快照(snapshot)。如果NameNode产生故障，Secondary NameNode将会被用来取代NameNode的位置。然而，这确实需要人工干预，因此没有从NameNode到Secondary NameNode的自动失效备援(failover)，但是，拥有Secondary NameNode将会确保数据丢失最小化。同NameNode一样，每个集群也仅有一个Secondary NameNode。
* DataNode:Hadoop集群中的每个从节点包含一个DataNode。DataNode负责进行数据管理:它从HDFS读取它的数据块，管理每个物理节点上的数据，向NameNode报告数据管理状态。
* JobTracker:JobTracker守护进程是你的应用与Hadoop本身之间的连线。每个Hadoop集群都有一个配置好的JobTracker,当你提交代码到Hadoop集群执行时，JobTracker负责构建执行计划。执行计划包括决定包含操作数据的节点、安排节点之间的数据通信、监视正在运行的任务(task)和重新开启任务如果任务失败。
* TaskTracker:同数据存储采用主/从(master/slave)架构一样，代码执行也采用了主/从(mater/slave)架构。每个从节点拥有一个TaskTracker守护进程(daemon)，该进程负责由JobTracker发送过来的任务，并同其他JobTracker通信job状态及心跳包。
图1尝试讲所有这些组件一起放在一张图中。
图1显示了主节点与从节点之间的关系。主节点包含两个重要组件:NameNode,管理集群及负责所有数据;JobTracker,负责管理被执行的代码和所有TaskTracker守护进程。每个从节点都有TaskTracker守护进程和DataNode守护进程:TaskTracker从JobTracker处接收指令并执行map和reduce步骤,而DataNode从NameNode处接收数据并管理被从节点包含的数据。并且理所当然存在一个Secondary NameNode监听NameNode的更新。
注意：
注意图1仅仅显示JobTracker及NameNode同单一从节点通信，但实际上，它同集群内的所有从节点通信。
本文采用「CC BY-SA 4.0 CN」协议转载自互联网、仅供学习交流，内容版权归原作者所有，如涉作品、版权和其他问题请给「我们」留言处理。
