毫无疑问，Hadoop已经赢得了大量投资者和IT媒体的青睐，但却很少看到任何的实际产出。即将过去的2011是风暴来袭前的准备阶段，为很多新公司新用户建立了一个海量数据的分析平台。就连微软这样的互联网巨头都已放弃其他平台而选择Hadoop，看来Hadoop风暴来袭已指日可待。
2012年，Hadoop必将风靡世界。以下是六个具体的理由：
1.投资者看好Hadoop
目前，投资者十分看好Hadoop，并开始纷纷投资相关技术。从分布式层面上来说，Hadoop开源软件整体方案供应商Cloudera已获得7600万美元投资，分布式架构新成员MapR和Hortonworks分别融资2900万美元和5000万美元；而从栈的层面上来看，Hadoop海量数据分析平台Datameer、 Karmasphere和Hadapt已分别获得了1000万美元左右投资。大量专注这一技术的初创公司（如Zettaset、Odiago和Platfora等）更是如雨后春笋般迅速涌现。另外，投资机构Accel Partners最近还成立了一个总额为1亿美金的大型数据基金，专门用于投资基于Hadoop和其他核心大型数据技术的应用。
2.竞争孕育成功
Hadoop必将是未来的发展趋势，尤其是当涉及到集成管理等业务问题时。Hadoop也是Cloudera、MapR和Hortonworks能在赢取客户资源方面具有明显竞争优势的原因。
3.学习曲线
除了改善在分布式层面的管理和支持能力外，Cloudera、MapR和Hortonworks等公司已经开始着手提高Hadoop的易用性。同时，Karmasphere和Concurrent公司也已开始提供编写Hadoop流程和应用服务，而Datameer和IBM等公司正在努力将Hadoop普及到普通商业用户。随着越来越多的Hapdoop创业公司涌现，通过各种创新方法简化繁重的数据分析工作也将变得越来越常见。
4.用户是永远的黄金准则
懂得任何管理Hadoop集群和编写Hadoop应用是一回事，而将它有效地用于实际的分析管理却是另外一回事。在Hadoop World大会和网络博客上经常可以看到Walt Disney、Orbitz、LinkedIn、和Etsy等很多大公司通过讲述自己的亲身实践大赞Hadoop。用户口碑永远是最有效的宣传途径。这些大用户的“亲身试法”，对很多潜在用户来说是一种无形的鼓励，也能在一定程度上帮助他们认识“从何开始、去往何处”的问题。
5.无处不在的用武之地
像Oracle、MySQL和SQL Server等老牌数据库一样，虽然人们对此了解不多也不深，且容易被忽视，但它们无处不在，几乎所有人都听过。从长远来看，Hadoop也将发展到类似阶段。一旦遇到涉及大量非结构化的数据采集和处理时，Hadoop就有了用武之地。
6.内容多，功能强大
除了核心设计思想MapReduce和HDFS（Hadoop Distributed File System）外，Hadoop还包括了从类SQL查询语言HQL，到NoSQL HBase数据库，以及机器学习库Mahout等内容。Cloudera、Hortonworks和MapR都已在他们的分布式系统中加入了Hadoop项目。最近，Cloudera还成立一个名为Bigtop的项目，集成了所有Hadoop相关项目。作为一个幕后英雄，Hadoop未来必将应用于越来越多的领域，风靡全球。

基于英特尔平台的Hadoop私有云架构
提到云计算，我们通常能够与Google、微软、雅虎这样的业界大腕相联系，与中小企业无缘。而实际上，得益于诸如Hadoop这样的开源软件，广大中小企业也可以搭建自己的私有云，并相当程度的满足自身需求。这篇文章会从实践出发，谈一谈企业如何在基于英特尔的开放架构上架设Hadoop私有云系统，以及测试实施的效果到底如何。
目前系统面临的问题
从过去来看，企业系统当中存在相当数量的应用，各自承载不同类型的大计算量任务，比如分词、产品分析、新词发现等等。
而目前的系统由于是基于单机的实现的，尽管单服务器性能也足够强，但对于多任务的执行，效率实在相当低下，某物流公司仅当月的产品分析一项就花了近300个机时。
如果沿着现在的方式走下去的话，那么开发成本，维护成本，硬件投入，以及跨项目组的沟通协调成本都会持续提升；而硬件使用效率跟开发人员生产率却会下降。从这点出发，需要构造一个通用的分布式计算框架引擎作为新的基础计算架构，来满足任务需求。
系统需求
1、通用性——系统需要实现任务分发，负载平衡，错误恢复等分布式计算的基础工作，一个计算密集型的任务可以通过简易的封装，部署在系统执行，在同一时间内，系统可以执行不同类型的任务，由此达到对服务器资源的最有效利用，从这一点上来看，系统需要的是一个开放式的基础架构。
2、稳定性——系统本身的运行稳定；
3、可扩展性——主要是指Scale Out的能力，需要新的服务器资源可以简易的集成进集群，投入应用；
4、灵活性，除去通过API或者通过扩展框架来将任务部署在系统中外，也要支持利用Python等脚本语言进行轻量级的开发，来应对一些ad-hoc的任务；
5、支持对大规模数据量的处理，以及对最终结果的集中收集。
英特尔平台的Hadoop私有云解决方案
从开放行、稳定性和扩展性等多方面角度考虑，基于Intel至强处理器平台是新的系统架构的选择，整个系统建立在Intel至强5600架构平台之上，在开源的分布式计算框架Hadoop上定制开发。Hadoop是一套对Google著名MapReduce模式的实现，用最简单的话说，MapReduce就是把任务数据拆分成多块，分别在不同的服务器上进行处理，最后再把中间结果聚合起来，得到最终结果。
从应用加载来看，所有的服务器资源根据应用被划分，运行稳定可靠，如果中间因为网络或者小部分服务器本身故障，Hadoop的内部机制可以自动将任务分配到正常机器上运行，以保证所有任务最终的顺利完成。
另外，由于所有的计算任务会在单独的线程中进行，所以可以充分利用至强5600的多线程和超线程技术。此外，配合英特尔QPI总线设计，处理器间的连接带宽提升至25.6GB/s，CPU与内存的数据带宽也达到了32GB/s，经在四核的服务器上测试，由于应用本身没有对多核进行优化，因此在主程序执行时，即便是单机性能也提高了近50%。
总结
基于Hadoop的开放平台私有云架构的战略意义
1、大幅减少现有计算密集型任务的时间，大幅提高服务器利用效率；
2、使未来对计算要求更高的业务成为可能，这样的架构允许任意添加新的X86服务器就能扩充计算资源，而不会增加额外的管理和维护成本。
3. 最后，系统除了支持Java，也支持Python和Bash Shell这样轻量级的脚本语言，也使得开发人员能够利用廉价而高性能的计算平台进行业务创新。

最近，在Hadoop最新版本的发布会上，Cloudera COO Kirk Dunn和业内一些专家指出了Hadoop在不同领域的应用案例。这与我近些年来关注的方向相同。为此，特别总结出在线旅游、移动数据、电子商务、能源发现、能源节省、基础设施管理、图像处理、欺诈检测、IT安全和医疗保健这十个领域，这其中，几乎每个领域都有我曾采访过的创新企业。当然，我也相信，在这些企业之外，还有更多的应用空间等待挖掘。
1. 在线旅游（Online travel）。Dunn表示，目前Cloudera的Hadoop架构正在为80%左右的全球在线旅游预定服务。尽管其并没有提及这些客户的名字，但是去年的时候我曾对应用了Hadoop的一家企业Orbitz Worldwide做了采访。Orbitz CEO Barney Harford当时表示，受益于Hadoop架构，他们极为轻松地实现了诸多的数据分析工作，并在其中得出“MAC用户比Windows用户愿意支付20美元的成本来预订酒店”，这样的影响范围很广的调查结论。当然，在他看来，Hadoop本身并不能带来如此的神奇效应，但是其可以帮助发现以前从来没有发现的数据点，进而使分析和挖掘成为了可能。
2. 移动数据（Mobile data）。这是Dunn的另一项“匿名”统计，Cloudera为“70%美国智能手机”提供服务。我认为他谈论的是通过无线方式存储和处理移动数据，以及有关市场份额的数学可以帮助他们锁定客户。
3. 电子商务（E-commerce）。Dunn所谈的Cloudera第三个市场是美国超过10,000,000家网上商店。Dunn说一家大型零售商（我认为说的是eBay，作为一个主要的Hadoop用户并且成功经营着大型零售卖场来帮助数百万商人销售）在使用了Hadoop后仅90天内就增加了3%的净利润。
4. 能源发现（Energy discovery）。在Cloudera的圆桌会议上，来自行业的一位代表 Chevron 解释了为什么他们选择了Hadoop：我们采用Hadoop来对数据进行排序和整理，而这些数据全部来自从海洋深处地震时产生的数据，而其背后有可能意味着石油储量。
5. 能源节省（Energy savings）。与 Chevron目标截然相反，Opower使用Hadoop来提升电力服务，尽量为用户节省在资源方面的投入。一个代表小组注意到，某些特定功能，如精确并长期的费用预测如果没有Hadoop几乎很难完成。据了解，Opower现在管理着30TB的信息，其中包括来自5000万用户（横跨60个公共事业部）能源数据，气象与人口方面的公共及私人数据，历史信息，地理数据及其他。这些都是通过超过20个MySQL数据库和一个Hadoop集群来存储和处理的。
6. 基础设施管理（Infrastructure management）。这是一个比较常见的应用方向，实际上，随着更多的公司（Esty，我最近采访过）从服务器、交换机及其他IT设备商收集并分析数据，Hadoop更有市场。在Cloudera发布会中，NetApp代表指出他们公司收集设备日志（现在已经超过1PB的容量了），并将它们存储在Hadoop中。事实上，Esty是专门从事国产与复古商品的电子商务网站，现在已经超过110万的用户，250万的独立访问量和11亿的页面浏览量。举个例子，通过Splunk管理和分析的集群数据已经到了每天1TB的量级。Esty每晚都要在以 Elastic MapReduce Hadoop service为基础的亚马逊云计算平台上运行数十种Hadoop工作流程。根据一些详细技术报告，其运行差不多5000 Hadoop job是在2011年5月份来分析来自内部运行数据和外部活动数据如用户行为变化。
7. 图像处理（Image processing）。一家创业型企业Skybox Imaging，利用Hadoop来存储和处理高来自卫星捕捉的高分辨率图像，并尝试将这些信息及图像与地理格局的变化相对应。
8. 欺诈检测（Fraud detection）。这已经是老生常谈了，在金融服务机构和情报机构中，欺诈检测一直都是关注的重点。一家企业，Zions Bancorporation向我讲述了他们是如何利用Hadoop来存储所有数据，并对客户交易和现货异常进行判断，对可能存在欺诈行为提前预警的。
9. IT安全（IT security）。如基础设施管理一样，企业通过使用Hadoop来处理机器产生的数据，以识别恶意软件和网络攻击模式。去年，ipTrus通过使用Hadoop来指定IP地址的名誉得分（在0-1之间的得分，O等于没有防线或未知的风险），从而使其他安全产品可以判断是否接受来自这些来源的通信，IBM和HP都使用ipTrust的安全产品。
10. 医疗保健（Health care）。我认为有很多方法可使更多的医疗保健医生从Hadoop中受益。但是最常见的仍然在搜索领域。去年，我介绍的Apixio，利用Hadoop平台开发了语义分析服务，可以对病人的健康提供医生、护士、及其他相关人士的回答。Apixio试图通过对医疗记录进行先进的技术分析，与一个简单的基于云计算的搜索引擎来帮助医生迅速了解病人相关病史，挽救生命。

众所周知，积极的参加各类的培训并获得相关的认证是IT专业人士的显著特征。而在2012年哪种技术会成为热点?毫无疑问是Hadoop。Apache Hadoop作为开源数据管理软件主要用来在分布式环境中的分析大量的结构化和非结构化数据。Hadoop已被用在包括Yahoo，Facebook，LinkedIn和eBay等众多流行的网站之中。
Hadoop大潮正在逐渐席卷所有美国的垂直行业，包括金融、传媒、零售、能源、以及制药等。Hadoop在树立大数据概念的同时，还对海量数据进行实时分析，并从分析得出的数据发现趋势，以提高企业赢利的能力。
IT专业人士对一些Hadoop开发和管理培训课程以及认证非常感兴趣。同时，IT经理(如CIO或CTO)也可以从大数据相关课程中受益良多。包括Cloudera、Hortonworks、IBM、MapR和Informatica都提供了相关的Hadoop培训。总部设在加州一家公司则提供四个不同受众(程序员、数据库分析师、系统管理员以及IT经理)的Hadoop相关课程。
Cloudera产品副总裁Charles Zedlewski表示Hadoop正在影响越来越的的行业。Cloudera所提供Hadoop服务已经持续了三年，同时也为自身企业级Hadoop软件做出了有力的补充。在过去几个月中，通过Cloudera Hadoop培训的相关人才极其抢手。相比于2011年第一季度，2012年第一季度参与培训的人预计会增长4倍。
Cloudera培训服务总监Sarah Sproehnle表示“公司也在努力聘请Hadoop人才，我们的Hadoop培训已经进行了一段时间。我们将最佳实践融入到我们课程之中，这驱使我们可以加快Hadoop从业人员快速成长。获得我们认证的从业人员也受到很多企业的欢迎，在企业中他们负责管理PB级数据”。Cloudera的Hadoop培训持续4天，大约需要2000美元费用。
事实上Cloudera的培训课程的名额在去年十一月纽约举行的第三次Hadoop全球年度大会(近2000人出席了会议)上被抢购一空。在过往的三年内，Cloudera已经培训超过10000名技术从业者。Cloudera计划在2012年底再培训10000名。
Hortonworks在二月也推出了被称为Hortonworks大学的Hadoop培训项目，并为IT专业人士提供标准课程和认证。Hortonworks的Hadoop认证分为开发人员认证与管理员认证。Hadoop开发者认证培训需要4天，费用约为2500美元。Hadoop管理员培训需要两天，费用大约1400美元。
“我们看到相关的Hadoop培训的需求在成倍增长，企业开始将收集的信息细化(客户信息、交易信息)，企业都在争先恐后的寻找缩减成本的方法。”Hortonworks全球服务领域高级总监Bob Mahan说道。
相关的Hadoop开发培训需要被培训人具备Java编程经验，而对于Hadoop管理培训而言则需要被培训人具备Linux或Unix的管理经验。IT人员争先恐后参加Hadoop认证培训无非是想获取更高的薪资。据Mahan预测在未来3-5年，全球将有一半的数据通过Hadoop处理。
而IBM则提出了新的倡议，IBM呼吁在大学时代开始培养本科生和研究生，旨在让他们在大学时期就接触大数据概念以及Hadoop。IBM这一倡议自去年十月以来已经吸引了14000学生参与其中。IBM提供了六个在线课程，涉及Hadoop基础上下篇。IBM表示，在庞大的注册人群中，约有1成学生在5个月内完成了相关资格认证。
与此同时，MIT更要求计算机系的学生使用Hadoop MapReduce构建程序。而加州伯克利分校更是使用Hadoop致力于数据科学领域的研究。
最后Cloudera产品副总裁Charles Zedlewski表示“现今Hadoop所处的状况让我想起了1995年时的Java”。

在经历了长达25年的统治地位后，关系型数据库正面临越来越火的“NoSQL”挑战，而挑战者是以Hadoop为代表的分布式计算开源架构。可以看到，越来越多的消息表明，不管NoSQL是被解释为“No SQL”还是“Not Only SQL”，如果你面临海量数据的挑战，那么你最应该选的海量数据架构是Hadoop。
但是Hadoop就能代表一切吗？答案显然是否定的，Hadoop的MapReduce在性能上的确是有局限性的：比如MapReduce没有索引，只有靠强大的运算能力来处理；此外，MapReduce本身存在一些lower-level实现的问题, 特别是skew和数据交换等等。
因此有些人开始回到关系型数据库上，因为相比较Hadoop的处理能力，一些SQL架构依然呈现数量级的优势。
也许，我们现在正处于一个新的“NoHadoop”时代，因为越来越多的企业开始认识到，海量数据处理仅有Hadoop是不够的。在他们看来，简单的批处理工具比如MapReduce和Hadoop恐怕并不足以应付将来更大的数据结构。诚然，大多数的比较复杂的海量数据处理我们也许能够用Hadoop就足以对付——也许更多的是一个无奈选择。它们可能涉及更复杂的连接，比如ACID需求、实时要求、超级计算的算法、图形计算、互动分析或者连续增量的需求等等。
事实上，Hadoop之所以受到越来越多的人欢迎，原因在于它对于海量数据的处理方式，而且，最重要的是，它是免费的。
但是随着对海量数据处理的应用程序性能需求不断增加，我们会发现，在很多领域，我们需要除了Hadoop以外的更多的海量数据处理方式。
那么，我们应该怎样看待下一代分布式计算架构呢？或者说，“NoHadoop”的架构应该是怎样的呢？从性能上而言，下一代的架构需要在MapReduce/Hadoop的基础上有10——10000倍的性能提高。
在每一种应用下，都有新一代的数据架构，可以提供所需的规模和效能。在未来的几年内，这些架构中的某些也许会成为主流。
1、SQL：数据库已经有了25年的发展历史。大量的创新正在围绕数据库技术，比如VoltDB、Clustrix等等（也许下一代产品不应该再称为数据库），但当你需要处理复杂的连接，或需要ACID需求时，数据库依然是你最好的选择。
应用场景：复杂的业务查询、在线交易处理。
2、Cloudscale：在海量数据上的实时分析，它打破了自由批量处理的限制。比如，当你打算分析一台百万次的服务器中发生的事件流，你需要一个真正的实时数据流体系结构。而Cloudscale架构提供的这种实时数据分析能力，比Hadoop的批处理系统快了近10000倍。
应用场景：商业算法，欺诈检测，手机广告、位置服务、市场情报。
3、MPI和BSP：相当多的超级计算机应用中，需要在海量数据上建立复杂的算法，为了实现规模效应，需要对处理器的直接访问调用以提高计算的速度。在并行计算中，MPI和BSP这些工具是进行高性能计算的必要。
应用场景：建模与仿真系统，流体动力学。
4、Pregel：当你需要分析一个复杂的社交网，或者是要分析网络的时候，面对的不是数据的问题，而是一个很大的图形。我们面临的现状是，大规模的动态图形正成为一些应用的关键。Google的Pregel结构采用了BSP模型，以便能够进行规模化、高效的图形计算。
应用场景：算法，算法的结构图，地理位置图，网络优化等
5、Dremel：这是一个需要与网络进行大规模交互的数据集。Google的Dremel的设计原理在于支持几秒内万亿行命令的执行，并提供即时查询。而它的查询执行并没有采用MapReduce 的功能。自从2006年以来Dremel诞生以来，已经有了成千上万的用户。
应用场景：数据搜索、客户支持、数据中心监控。
6、Percolator (Caffeine) ：如果需要对庞大的数据增量进行不断更新，你会发现，Percolator是一种很好的实现方式，这也是Google在新的索引系统上采用的架构，Google的即时搜索引擎Instant不能没有它。“由于索引内容可以逐步增加，采用以Percolator的Google Caffeine系统检索速度将百倍于之前采用Hadoop的分布式数据处理方式。”
应用场景：实时搜索
原文链接：http://www.sys-con.com/node/1573226
作者简介：Bill McColl：Cloudscale创始人和首席执行官，牛津大学计算科学系主任，负责并行计算研究中心。

Hadoop分布式文件系统：架构和设计要点
原文：http://hadoop.apache.org/core/docs/current/hdfs_design.html
一、前提和设计目标
1、硬件错误是常态，而非异常情况，HDFS可能是有成百上千的server组成，任何一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是HDFS的核心架构目标。
2、跑在HDFS上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。
3、HDFS以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至T字节，一个单一HDFS实例应该能支撑数以千万计的文件。
4、 HDFS应用对文件要求的是write-one-read-many访问模型。一个文件经过创建、写，关闭之后就不需要改变。这一假设简化了数据一致性问 题，使高吞吐量的数据访问成为可能。典型的如MapReduce框架，或者一个web crawler应用都很适合这个模型。
5、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好，HDFS提供给应用这样的接口。
6、在异构的软硬件平台间的可移植性。
二、Namenode和Datanode
HDFS采用master/slave架构。一个HDFS集群是有一个Namenode和一定数目的Datanode组成。Namenode是一个中心服 务器，负责管理文件系统的namespace和客户端对文件的访问。Datanode在集群中一般是一个节点一个，负责管理节点上它们附带的存储。在内 部，一个文件其实分成一个或多个block，这些block存储在Datanode集合里。Namenode执行文件系统的namespace操作，例如 打开、关闭、重命名文件和目录，同时决定block到具体Datanode节点的映射。Datanode在Namenode的指挥下进行block的创 建、删除和复制。Namenode和Datanode都是设计成可以跑在普通的廉价的运行linux的机器上。HDFS采用java语言开发，因此可以部 署在很大范围的机器上。一个典型的部署场景是一台机器跑一个单独的Namenode节点，集群中的其他机器各跑一个Datanode实例。这个架构并不排 除一台机器上跑多个Datanode，不过这比较少见。

单一节点的Namenode大大简化了系统的架构。Namenode负责保管和管理所有的HDFS元数据，因而用户数据就不需要通过Namenode（也就是说文件数据的读写是直接在Datanode上）。
三、文件系统的namespace
HDFS支持传统的层次型文件组织，与大多数其他文件系统类似，用户可以创建目录，并在其间创建、删除、移动和重命名文件。HDFS不支持user quotas和访问权限，也不支持链接（link)，不过当前的架构并不排除实现这些特性。Namenode维护文件系统的namespace，任何对文 件系统namespace和文件属性的修改都将被Namenode记录下来。应用可以设置HDFS保存的文件的副本数目，文件副本的数目称为文件的 replication因子，这个信息也是由Namenode保存。
四、数据复制
HDFS被设计成在一个大集群中可以跨机器地可靠地存储海量的文件。它将每个文件存储成block序列，除了最后一个block，所有的block都是同 样的大小。文件的所有block为了容错都会被复制。每个文件的block大小和replication因子都是可配置的。Replication因子可 以在文件创建的时候配置，以后也可以改变。HDFS中的文件是write-one，并且严格要求在任何时候只有一个writer。Namenode全权管 理block的复制，它周期性地从集群中的每个Datanode接收心跳包和一个Blockreport。心跳包的接收表示该Datanode节点正常工 作，而Blockreport包括了该Datanode上所有的block组成的列表。

1、副本的存放，副本的存放是HDFS可靠性和性能的关键。HDFS采用一种称为rack-aware的策略来改进数据的可靠性、有效性和网络带宽的利 用。这个策略实现的短期目标是验证在生产环境下的表现，观察它的行为，构建测试和研究的基础，以便实现更先进的策略。庞大的HDFS实例一般运行在多个机 架的计算机形成的集群上，不同机架间的两台机器的通讯需要通过交换机，显然通常情况下，同一个机架内的两个节点间的带宽会比不同机架间的两台机器的带宽 大。
通过一个称为Rack Awareness的过程，Namenode决定了每个Datanode所属的rack id。一个简单但没有优化的策略就是将副本存放在单独的机架上。这样可以防止整个机架（非副本存放）失效的情况，并且允许读数据的时候可以从多个机架读 取。这个简单策略设置可以将副本分布在集群中，有利于组件失败情况下的负载均衡。但是，这个简单策略加大了写的代价，因为一个写操作需要传输block到 多个机架。
在大多数情况下，replication因子是3，HDFS的存放策略是将一个副本存放在本地机架上的节点，一个副本放在同一机架上的另一个节点，最后一 个副本放在不同机架上的一个节点。机架的错误远远比节点的错误少，这个策略不会影响到数据的可靠性和有效性。三分之一的副本在一个节点上，三分之二在一个 机架上，其他保存在剩下的机架中，这一策略改进了写的性能。
2、副本的选择，为了降低整体的带宽消耗和读延时，HDFS会尽量让reader读最近的副本。如果在reader的同一个机架上有一个副本，那么就读该副本。如果一个HDFS集群跨越多个数据中心，那么reader也将首先尝试读本地数据中心的副本。
3、SafeMode
Namenode启动后会进入一个称为SafeMode的特殊状态，处在这个状态的Namenode是不会进行数据块的复制的。Namenode从所有的 Datanode接收心跳包和Blockreport。Blockreport包括了某个Datanode所有的数据块列表。每个block都有指定的最 小数目的副本。当Namenode检测确认某个Datanode的数据块副本的最小数目，那么该Datanode就会被认为是安全的；如果一定百分比（这 个参数可配置）的数据块检测确认是安全的，那么Namenode将退出SafeMode状态，接下来它会确定还有哪些数据块的副本没有达到指定数目，并将 这些block复制到其他Datanode。
五、文件系统元数据的持久化
Namenode存储HDFS的元数据。对于任何对文件元数据产生修改的操作，Namenode都使用一个称为Editlog的事务日志记录下来。例如， 在HDFS中创建一个文件，Namenode就会在Editlog中插入一条记录来表示；同样，修改文件的replication因子也将往 Editlog插入一条记录。Namenode在本地OS的文件系统中存储这个Editlog。整个文件系统的namespace，包括block到文件 的映射、文件的属性，都存储在称为FsImage的文件中，这个文件也是放在Namenode所在系统的文件系统上。
Namenode在内存中保存着整个文件系统namespace和文件Blockmap的映像。这个关键的元数据设计得很紧凑，因而一个带有4G内存的 Namenode足够支撑海量的文件和目录。当Namenode启动时，它从硬盘中读取Editlog和FsImage，将所有Editlog中的事务作 用（apply)在内存中的FsImage ，并将这个新版本的FsImage从内存中flush到硬盘上,然后再truncate这个旧的Editlog，因为这个旧的Editlog的事务都已经 作用在FsImage上了。这个过程称为checkpoint。在当前实现中，checkpoint只发生在Namenode启动时，在不久的将来我们将 实现支持周期性的checkpoint。
Datanode并不知道关于文件的任何东西，除了将文件中的数据保存在本地的文件系统上。它把每个HDFS数据块存储在本地文件系统上隔离的文件中。 Datanode并不在同一个目录创建所有的文件，相反，它用启发式地方法来确定每个目录的最佳文件数目，并且在适当的时候创建子目录。在同一个目录创建 所有的文件不是最优的选择，因为本地文件系统可能无法高效地在单一目录中支持大量的文件。当一个Datanode启动时，它扫描本地文件系统，对这些本地 文件产生相应的一个所有HDFS数据块的列表，然后发送报告到Namenode，这个报告就是Blockreport。
六、通讯协议
所有的HDFS通讯协议都是构建在TCP/IP协议上。客户端通过一个可配置的端口连接到Namenode，通过ClientProtocol与 Namenode交互。而Datanode是使用DatanodeProtocol与Namenode交互。从ClientProtocol和 Datanodeprotocol抽象出一个远程调用(RPC），在设计上，Namenode不会主动发起RPC，而是是响应来自客户端和 Datanode 的RPC请求。
七、健壮性
HDFS的主要目标就是实现在失败情况下的数据存储可靠性。常见的三种失败：Namenode failures, Datanode failures和网络分割（network partitions)。
1、硬盘数据错误、心跳检测和重新复制
每个Datanode节点都向Namenode周期性地发送心跳包。网络切割可能导致一部分Datanode跟Namenode失去联系。 Namenode通过心跳包的缺失检测到这一情况，并将这些Datanode标记为dead，不会将新的IO请求发给它们。寄存在dead Datanode上的任何数据将不再有效。Datanode的死亡可能引起一些block的副本数目低于指定值，Namenode不断地跟踪需要复制的 block，在任何需要的情况下启动复制。在下列情况可能需要重新复制：某个Datanode节点失效，某个副本遭到损坏，Datanode上的硬盘错 误，或者文件的replication因子增大。
2、集群均衡
HDFS支持数据的均衡计划，如果某个Datanode节点上的空闲空间低于特定的临界点，那么就会启动一个计划自动地将数据从一个Datanode搬移 到空闲的Datanode。当对某个文件的请求突然增加，那么也可能启动一个计划创建该文件新的副本，并分布到集群中以满足应用的要求。这些均衡计划目前 还没有实现。
3、数据完整性
从某个Datanode获取的数据块有可能是损坏的，这个损坏可能是由于Datanode的存储设备错误、网络错误或者软件bug造成的。HDFS客户端 软件实现了HDFS文件内容的校验和。当某个客户端创建一个新的HDFS文件，会计算这个文件每个block的校验和，并作为一个单独的隐藏文件保存这些 校验和在同一个HDFS namespace下。当客户端检索文件内容，它会确认从Datanode获取的数据跟相应的校验和文件中的校验和是否匹配，如果不匹配，客户端可以选择 从其他Datanode获取该block的副本。
4、元数据磁盘错误
FsImage和Editlog是HDFS的核心数据结构。这些文件如果损坏了，整个HDFS实例都将失效。因而，Namenode可以配置成支持维护多 个FsImage和Editlog的拷贝。任何对FsImage或者Editlog的修改，都将同步到它们的副本上。这个同步操作可能会降低 Namenode每秒能支持处理的namespace事务。这个代价是可以接受的，因为HDFS是数据密集的，而非元数据密集。当Namenode重启的 时候，它总是选取最近的一致的FsImage和Editlog使用。
Namenode在HDFS是单点存在，如果Namenode所在的机器错误，手工的干预是必须的。目前，在另一台机器上重启因故障而停止服务的Namenode这个功能还没实现。
5、快照
快照支持某个时间的数据拷贝，当HDFS数据损坏的时候，可以恢复到过去一个已知正确的时间点。HDFS目前还不支持快照功能。
八、数据组织
1、数据块
兼容HDFS的应用都是处理大数据集合的。这些应用都是写数据一次，读却是一次到多次，并且读的速度要满足流式读。HDFS支持文件的write- once-read-many语义。一个典型的block大小是64MB，因而，文件总是按照64M切分成chunk，每个chunk存储于不同的 Datanode
2、步骤
某个客户端创建文件的请求其实并没有立即发给Namenode，事实上，HDFS客户端会将文件数据缓存到本地的一个临时文件。应用的写被透明地重定向到 这个临时文件。当这个临时文件累积的数据超过一个block的大小（默认64M)，客户端才会联系Namenode。Namenode将文件名插入文件系 统的层次结构中，并且分配一个数据块给它，然后返回Datanode的标识符和目标数据块给客户端。客户端将本地临时文件flush到指定的 Datanode上。当文件关闭时，在临时文件中剩余的没有flush的数据也会传输到指定的Datanode，然后客户端告诉Namenode文件已经 关闭。此时Namenode才将文件创建操作提交到持久存储。如果Namenode在文件关闭前挂了，该文件将丢失。
上述方法是对通过对HDFS上运行的目标应用认真考虑的结果。如果不采用客户端缓存，由于网络速度和网络堵塞会对吞估量造成比较大的影响。
3、流水线复制
当某个客户端向HDFS文件写数据的时候，一开始是写入本地临时文件，假设该文件的replication因子设置为3，那么客户端会从Namenode 获取一张Datanode列表来存放副本。然后客户端开始向第一个Datanode传输数据，第一个Datanode一小部分一小部分（4kb)地接收数 据，将每个部分写入本地仓库，并且同时传输该部分到第二个Datanode节点。第二个Datanode也是这样，边收边传，一小部分一小部分地收，存储 在本地仓库，同时传给第三个Datanode，第三个Datanode就仅仅是接收并存储了。这就是流水线式的复制。
九、可访问性
HDFS给应用提供了多种访问方式，可以通过DFSShell通过命令行与HDFS数据进行交互，可以通过java API调用，也可以通过C语言的封装API访问，并且提供了浏览器访问的方式。正在开发通过WebDav协议访问的方式。具体使用参考文档。
十、空间的回收
1、文件的删除和恢复
用户或者应用删除某个文件，这个文件并没有立刻从HDFS中删除。相反，HDFS将这个文件重命名，并转移到/trash目录。当文件还在/trash目 录时，该文件可以被迅速地恢复。文件在/trash中保存的时间是可配置的，当超过这个时间，Namenode就会将该文件从namespace中删除。 文件的删除，也将释放关联该文件的数据块。注意到，在文件被用户删除和HDFS空闲空间的增加之间会有一个等待时间延迟。
当被删除的文件还保留在/trash目录中的时候，如果用户想恢复这个文件，可以检索浏览/trash目录并检索该文件。/trash目录仅仅保存被删除 文件的最近一次拷贝。/trash目录与其他文件目录没有什么不同，除了一点：HDFS在该目录上应用了一个特殊的策略来自动删除文件，目前的默认策略是 删除保留超过6小时的文件，这个策略以后会定义成可配置的接口。
2、Replication因子的减小
当某个文件的replication因子减小，Namenode会选择要删除的过剩的副本。下次心跳检测就将该信息传递给Datanode， Datanode就会移除相应的block并释放空间，同样，在调用setReplication方法和集群中的空闲空间增加之间会有一个时间延迟。
参考资料：
HDFS Java API: http://hadoop.apache.org/core/docs/current/api/
HDFS source code: http://hadoop.apache.org/core/version_control.html

目的

先决条件

下载

运行Hadoop集群的准备工作

单机模式的操作方法

伪分布式模式的操作方法

完全分布式模式的操作方法

Hadoop集群搭建–Hadoop安装

目的

先决条件

安装

配置

Hadoop的机架感知

启动Hadoop

停止Hadoop

导读：Yahoo CTO Raymie Stata是领导海量数据分析引擎的关键人物。IBM和Hadoop将更多的精力专注在海量数据上，海量数据正在潜移默化的改变企业和IT部门。
 
越来越多的大企业的数据集以及创建需要的一切技术，包括存储、网络、分析、归档和检索等，这些被认为是海量数据。这些大量信息直接推动了存储、服务器以及安全的发展。同时也是给IT部门带来了一系列必须解决的问题。
信息技术研究和分析的公司Gartner认为海量数据处理应该是将大量的不同种类以及结构化和非结构化的数据通过网络汇集到处理器和存储设备之中，并伴随着将这些数据转换为企业的商业报告。
海量数据处理的三个主要因素：大容量数据、多格式数据和速度
大容量数据（TB级、PB级甚至EB级）：人们和机器制造的越来越多的业务数据对IT系统带来了更大的挑战，数据的存储和安全以及在未来访问和使用这些数据已成为难点。
多格式数据：海量数据包括了越来越多不同格式的数据，这些不同格式的数据也需要不同的处理方法。从简单的电子邮件、数据日志和信用卡记录，再到仪器收集到的科学研究数据、医疗数据、财务数据以及丰富的媒体数据（包括照片、音乐、视频等）。
速度：速度是指数据从端点移动到处理器和存储的速度。
 
Kusnetzky集团的分析师Dan Kusnetzky在其博客表示“简单的说，大数据是指允许组织创建、操作和管理的庞大的数据集和存储设施工具”。这是否意味着将来将会出现比TB和PB更大的数据集吗？供应商给出的回应是“会出现”。
他们也许会说“你需要我们的产品来管理和组织利用大规模的数据，只是想想繁杂大量的维护动态数据集带来的麻烦就使人们头疼“。此外海量数据的另外一个价值是它可以帮助企业在适当的时机作出正确决策。
 
从历史上看，数据分析软件面对当今的海量数据已显得力不从心，这种局面正在悄然转变。新的海量数据分析引擎已经出现。如Apache的Hadoop、LexisNexis的HPCC系统和1010data（托管、海量数据分析的平台供应商）的以云计算为基础的分析服务。
101data的高级副总裁Tim Negris表示海量数据的收集以及存放和利用海量数据实际上完全是两回事。在做任何事前需要大量（准备数据）的工作是像Oracle和大多数数据库厂商所面临的难题之一。我们正是要消除这个难题，并把数据直接交到分析师的手中。Hadoop和HPCC系统做到了这一点。这三个平台都着眼于海量数据并提供支持。
开源的Hadoop已经在过去5年之中证明了自己是市场中最成功的数据处理平台。目前Cloudera的首席执行官和Apache基金会的Doug Cutting是Hadoop的创始人，他曾在Yahoo工作过。
Hadoop将海量数据分解成较小的更易访问的批量数据并分发到多台服务器来分析（敏捷是一个重要的属性，就像你更容易消化被切成小块的食物）Hadoop再处理查询。
“Gartner和IDC的分析师认为海量数据的处理速度和处理各种数据的能力都是Hadoop吸引人们的地方”。Cloudera的产品副总裁Charles Zedlewski说到。
在Cutting和他的Yahoo团队提出Hadoop项目之后，在Yahoo IT系统测试并广泛使用了很多年。随后他们将Hadoop发布到开源社区，这使得Hadoop逐渐产品化。
在Cutting和Yahoo在开发、测试并内部运行代码时，他们了解到使用起来还是很复杂的。这导致他们马上意识到如果在未来提供周边服务（例如提供直观的用户界面、定制部署和附加功能软件）可赚取更多的资金。
 
在2009年Cloudera作为一家独立公司开始运营，公司产品采用开源并产品化Hadoop分析引擎和Cloudera企业版（Cloudera Enterprise整合了更多的工具，包括Hive、HBase、Sqoop、Oozie、Flume、Avro、Zookeeper、Pig和Cloudera Desktop）。
Cloudera得到了大量投资者的青睐，这其中包括VMware的创始人和前首席执行官Diane Greene、Flickr的联合创始人Caterina Fake、MySQL前首席执行官Marten Mickos、Linkedln总裁Jeff Weiner和Facebook CFO Gideon Yu。
自从Cloudera成立以来，只有少数的顶级公司和初创公司免费提供他们基于Hadoop开放源代码架构制作的自己的版本。
这是一场真正的企业科技的竞争。就像在一场接力赛中，所有选手都必须使用同一种类型的接力棒（Hadoop的代码）。企业竞争主要集中在处理数据的速度、敏捷性和创造性上。这场竞争是迫使大多数企业在海量数据分析市场有所作为最有效的方法。
IBM提供了基于Hadoop的InfoSphere BigInsights（IBM InfoSphere BigInsights 是用于分析和虚拟化海量数据的软件和服务，这款新产品由 Apache Hadoop 提供技术支持。）基本版和企业版。但公司有更大的计划。
IBM CEO Sam Palmisano表示IBM正在将新一代数据分析作为公司的研发重点，IBM在此项目上投资了1亿美元。IBM院士和计算机科学研究室主任Laura Haas表示IBM实验室的研究远远超出了海量数据的范围，并已经着手”Exadata“分析研究。Watson就是IBM在数据海量数据研究的成果，Watson将用于更多用途，包括卫生保健、科学研究等。
其他Hadoop版本
MapR发布了一个分布式文件系统和MapReduce引擎，MapR还与存储和安全的领导厂商EMC合作向客户提供了Greenplum HD企业版Hadoop存储组件 。EMC Hadoop的另一个独特之处在于它没有采用官方版本的Apache代码，而是采用Facebook的Hadoop代码，后者在可扩展性和多站点部署上进行了优化。
另一家厂商 Platform Computing，Platform提供了与Apache Hadoop MapReduce编程模型完全兼容的分布式分析平台，并支持多种分布式文件系统。
 
SGI（Silicon Graphics International ）提供基于SGI Rackable和CloudRack服务器产品实施服务的Hadoop优化解决方案。
戴尔也开始出售预装该开源数据处理平台的服务器。 该产品成本随支持选项不同而异，基础配置价格在11.8万美元至12.4万美元之间，包含为期一年的Cloudera支持和更新，6个PowerEdge C2100服务器（2个管理节点，1个边缘节点和3个从站节点，以及6个戴尔PowerConnect 6248交换机）。
替代品浮出水面。包括1010data的云服务、LexusNexis公司的Risk，该系统在10年间帮助LexusNexis公司分析大量的客户数据，并在金融业和其他重要的行业中应用。LexusNexis最近还宣布要在开源社区分享其核心技术以替代Hadoop。LexisNexis公司发布一款开源的数据处理方案，该技术被称为HPCC系统。
HPCC可以管理、排序并可在几秒钟内分上亿条记录。HPCC提供两种数据处理和服务的方式——Thor Data Refinery Cluster和Roxy Rapid Data Delivery Cluster。Escalante表示如此命名是因为其能像Thor(北欧神话中司雷、战争及农业的神)一样解决困难的问题，Thor主要用来分析和索引大量的Hadoop数据。而Roxy则更像一个传统的关系型数据库或数据仓库，甚至还可以处理Web前端的服务。
LexisNexis CEO James Peck表示我们认为在当下这样的举动是对的，同时我们相信HPCC系统会将海量数据处理提升到更高高度。
 
在2011年6月Yahoo和硅谷风险投资公司Benchmark Capital周二联合宣布，他们将联合成立一家名为Hortonworks的新公司，接管被广泛应用的数据分析软件Hadoop的开发工作。
据一些前Yahoo员工透露，从商业角度来看Hortonworks将保持独立运营，并发展其自身的商业版。
在转型时期，Yahoo CTO Raymie Stata成为关键人物，他将负责公司所有IT项目的发展。Stata表示相对于Yahoo，在Hortonworks我们会投入更多的精力在Hadoop的工作和相关技术上，我们认为应加大对Hadoop的投资。我们会将一些关键人员指派到Hortonworks公司，但这既不是裁员也不是分拆。这是在加大对Hadoop的投入。Yahoo将继续为Hadoop的发展做出更大的贡献。
Stata解释说，Yahoo一直有一个梦想，就是将Hadoop变为大数据分析软件的行业标准。但是这必须将Hadoop商业化。Stata表示创建Hortonworks的主要原因是因为Yahoo已经看到了未来企业分析（感谢Hadoop 6年以来的发展）的未来，并知道该怎样去做。我们看到海量数据分析将很快成为企业非常普遍的需求。
我们将Hadoop部署在企业之中，我不认为所有人都否定这样的解决方案。我们要通过Hadoop为我们的股东创造价值。如果某一天Hadoop成为海量数据处理的行业标准，这将是对我们最好的奖赏。

Hadoop为何物？
虽说Hadoop的名声很大，但是总还是有同学不太了解的，这里一笔带过一下。
Google分布式计算三驾马车：
Hadoop的创始源头在于当年Google发布的3篇文章，被称为Google的分布式计算三驾马车（Google还有很多很牛的文章，但是在分布式计算方面，应该这三篇的影响力最大了）：，链接的文章比我介绍得更清晰，当然最好还是看看原文了，这是做分布式系统、分布式计算的工程师必修课。
Google File System用来解决数据存储的问题，采用N多台廉价的电脑，使用冗余（也就是一份文件保存多份在不同的电脑之上）的方式，来取得读写速度与数据安全并存的结果。
Map-Reduce说穿了就是函数式编程，把所有的操作都分成两类，map与reduce，map用来将数据分成多份，分开处理，reduce将处理后的结果进行归并，得到最终的结果。但是在其中解决了容错性的问题。
BigTable是在分布式系统上存储结构化数据的一个解决方案，解决了巨大的Table的管理、负载均衡的问题。
Google就靠着这几样技术，在搜索引擎和广告方面取得了举世瞩目的成就。不过Google不是傻的，这三篇文章虽然都是干货，但是不是直接就可以用的。话说Google发表了这三篇文章后，在学术界引起了轩然大波，大家对这三样东西提起了浓厚的兴趣，都想着是不是可以实现一下，以为己用。
Doug Cutting：
Doug Cutting之前是一个非常有名的开源社区的人，创造了nutch与lucene（现在都是在Apache基金会下面的），nutch之前就实现了一个分布式的爬虫抓取系统。等Google的三驾马车发布后，Doug Cutting一看，挖靠这么厉害的技术，于是就实现了一个DFS(distributed file system)与Map-Reduce（大牛风范啊），集成进了Nutch，作为Nutch的一个子项目存在。那时，是2004年左右。
在互联网这个领域一直有这样的说法：
“如果老二无法战胜老大，那么就把老大赖以生存的东西开源吧”
当年与Google还是处在强烈竞争关系的Yahoo!于是招了Doug兄进来，把老大赖以生存的DFS与Map-Reduce开源了。开始了Hadoop的童年时期。差不多在2008年的时候，Hadoop才算逐渐成熟。
现在的Hadoop:
现在的Hadoop不仅是当年的老二Yahoo的专用产品了，从Hadoop长长的用户名单中，可以看到Facebook,可以看到Linkedin，可以看到Amazon，可以看到EMC, eBay，Tweeter，IBM, Microsoft, Apple, HP…(后面的一些未必是完全使用)。国内的公司有淘宝、百度等等。
我来定义一下Hadoop：
Hadoop是一套开源的、基础是Java的、目前能够让数千台普通、廉价的服务器组成一个稳定的、强大的集群，使其能够对pb级别的大数据进行存储、计算。已经具有了强大稳定的生态系统，也具有很多使用的延伸产品。比如做查询的Pig, 做分布式命名服务的ZooKeeper, 做数据库的Hive等等。
为什么世界上只有一个Hadoop？
我的前公司是国内某一个著名互联网公司的子公司，专注做云计算，我也在这个公司最兴盛的时候进入，当时宣传的口号是“做最好的云计算”，就是希望自己开发一套存储计算系统（就是类似于前面提到过的dfs与map-reduce），并且克服一些Hadoop的缺点（比如说用c++去实现，克服Java的一些性能问题）。后来结局可能大家也猜到了，投入了很多钱，招了不少牛人，确实也做出了还算不错的云计算（至少在国内是数一数二的）。但是最终不管从稳定性还是效率上还是scalable来说，都远远被Hadoop甩在了后面。虽然我前公司这个云计算项目是否会成功，这里没办法预测，但是前途终究还是比较黯淡的。
最近一年还听说国内不少的互联网巨头都成立了云计算部门，做“自己的”云计算，有些小得像创业时期一样的公司，都宁愿自己写一套map-reduce框架，不愿意直接使用Hadoop。可能这个跟国人的想法，武功秘笈一定要自己藏着，不让别人学，传男不传女。对别人白给你的东西，非常不放心，觉得大家都能学到的东西，肯定竞争力是不够的。
除开心态问题不谈，但从技术实力上来说，一般国内公司的核心开发团队的能力和当年的Yahoo!比，还是有非常大的差距的，至少像是Doug兄这样的大牛是很罕见的，从开发者的实力来说，就差了不止一个档次。
其次从积累来说，Hadoop从初创到现在也经过了至少7年的积累的，碰到过很多刁钻客户的问题都慢慢克服了（比如Facebook的超大数据存储），带给用户的经验教训是很充足的，比如说性能调优这一块，就有非常多的文章去介绍。而自己开发一个，什么都需要从头再来。
最后也是最重要的是，Hadoop形成了一个强大稳定的生态系统，里面有生产者（共享改进的代码、fix bug），也有消费者（使用项目并且反馈经验），Hadoop的用户也可以获得较大的经济利益（不花钱买软件，还可以增加效率）。对于一个开源社区来说，构建出一个完整的生态系统是非常非常的困难，一旦构造出来了，项目就会很稳定的往前去进步。
Hadoop的优势
之前分析了一些“虚”的东西，比如生态系统什么的，这里说说一些实际的东西。
Benchmark:
Hadoop现在保持了很多漂亮的记录：
存储：现在世界上最大的Hadoop集群目前在Facebook，可以存储30PB的数据
计算：Hadoop是目前Terasort记录的保持者（参见：http://sortbenchmark.org/)，Terasort是给出1TB的随机数据，看谁能够在最短的时间内完成排序，Hadoop使用了1400多个节点，在2分钟内完成1T的数据排序。
这里顺便说一下，之前给出网站里面有很多的benchmark，可以看到Hadoop的集群是最大的，使用的机器最多的，像是TritonSort这样的集群，使用了区区50多个节点，最终的结果并不比Hadoop差太多，但是这里得注意一下。TritonSort是专门用来做排序的，里面加入了相当多的优化，但是Hadoop是一个通用的集群，并没有为了一种任务进行如此多的优化。从用户的角度上来说，愿意花钱去买一个只会排序的电脑是意义不那么大的。
注：左右两边属于两种不同的terasort，hadoop是其中一种的记录保持者
能做什么？
前面说的基本的存储和计算Hadoop是一定能胜任的，下面谈谈一些“高级”的功能。
常见的数据库操作，比如orderby、select这样的操作都可以的，Hive就是支持这样的Sql模型，能够将Sql语句最终转化到Map-Reduce程序中去。其性能和可用性已经得到了证明，Facebook就用它做了不少的数据分析的工作
常见的机器学习、矩阵分析算法，目前Mahout作为一个发展迅速的项目，在逐渐填补Hadoop在机器学习领域的空白，现在常见的分类、聚类、推荐、主成分分析算法（比如SVD）都已经有相应的Map-Reduce实现了。虽然目前从用户群和效率上来说是不够的，但是从它的发展来说应该会很快的达到工业界的标准
Hadoop的劣势
现在Hadoop依然有很多的问题没有解决，这让有些人非常的怀疑Hadoop的未来，这里谈谈Hadoop的一些重要的劣势
HA(High Availability)高可用性:
这一点是Hadoop非常弱的一个缺点，不管是Hdfs还是Map-reduce，都是采用单master的方式，集群中的其他机器都是与一台中心机器进行通信，如果这个中心机器挂了，集群就只有不工作了（不一定数据会丢失，但是至少需要重启等等工作)，让可用性变得更低。这个一般叫做单点失败(single point of failure,SPOF)。
虽然现在有些公司已经给出了解决方案，比如EMC就有用Vmware搭建虚拟集群，对master节点进行镜像备份，如果master挂掉，那么立刻换上镜像备份的机器，使其可用性变高，不过这个终究不是一个内置的解决方案，而且Vmware这一套东西也并不便宜。
不过之后这个问题将会得到非常好的解决，我在Hadoop的未来这一章将说以说。
Hadoop目前解决得不那么好的一些算法：
Join等:
Map-Reduce还有一个问题是，对于Join这个最常见的数据库操作，支持力度还是不够，特别是针对那种上TB的数据，Join将会很不给力，现在已经有了一些解决方案，比如说SIGMOD’2010的这篇文章：
A Comparison of Join Algorithms for Log Processing in MapReduce
不过在现在的情况下，只有尽量的避免大数据库的Join操作
需要进行很多轮迭代、循环的算法：
对于循环，Map-Reduce稍好，比如矩阵计算，高斯消元法这样的，循环的次数的确定的算法，实现起来还是不难，只是有点慢。但是迭代就更麻烦了，因为现在的Map-Reduce的mapper和reducer是不太方便去弄这样的终止条件。
还有就是迭代次数超多的算法（比如说矩阵的SVD分解），在超大矩阵的情况下，迭代次数可能会上亿次。而Map-Reduce在每次迭代的时候都会把数据往文件里面读写一遍，这样的浪费的时间是巨大的。
其实Map-Reduce不是绝对没有办法去解决这些问题，而只是现在这个还不是最重要的日程，Hadoop还有很多很多的东西可以优化，比如说前面提到的HA，这些东西只有往后放放，我将在之后的Hadoop的未来部分，谈谈未来版的Hadoop怎么去解决这些问题。
编程复杂，学习曲线陡峭：
对于一般的map-reduce框架，hello world程序就变成了word count，就是给出一堆的文本文件，最终统计出里面每一个不同的单词出现的次数，这样一个简单的任务（可能在linux shell下一行就写出来了），在Map-reduce中需要几十行，一般新人从理解word count到写出自己的word count，到跑通，一个星期是肯定需要的。这样陡峭的学习曲线让许多人难以深入。
另外还有一点Hadoop被人所诟病的是，代码丑陋，虽然Hadoop是用高级语言Java写成的，但是里面对每一个步骤都要分成mapper和reducer，这个被戏称为新时代的汇编语言。
一般来说，做数据分析的人程序都写得不咋地（强哥这样的达人除外），能写写matlab，R，或者spss就差不多了，如果要让他们去写map-reduce，那就等于叫他们别干活了。而大数据的重要的作用就是用来做数据分析，Hadoop的未来发展必须得抓住这群数据分析师的心。
其实现在已经有一些实验中的产品，让用户可以用高级语言编程，不会再看到丑丑的map-reduce了。我在前公司的时候就与团队一起做了还不错的尝试，至少，数据分析师可以用Python来编程了。map-reduce变成了一个底层的东西，现在不是某些人在分析性能的时候就贴上汇编代码吗，之后可能会变成在前段的程序效率不行的时候，就贴上后端Java的map-reduce程序。
所以对这个难题之后肯定会解决掉，底层分布式程序开发与用户将被清楚的分开，之后想要写word-count一定会像hello world一样简单。
Hadoop的未来怎么样？
http://www.slideshare.net/hortonworks/apache-hadoop-023 (hadoop 0.23)
给出这样的一个官方文档，谈谈之后的hadoop的发展。目前的hadoop的稳定版是0.20.x，这个0.23是个未来版，估计将在今年的Q4进行beta的发布（目前看起来，至少代码是写了很多了） 。
HDFS Federation
首先是一个叫做HDFS Federation的东西，它将hdfs的命名空间进行了扩展，目前的HDFS的所有文件的meta信息都保存在一台机器的内存中，使得HDFS支持的文件数目是有限的，现在进行了这样改动后，将hdfs的命名空间做成了分布式的，对之后方便对不同的用户文件夹进行管理，还有从HDFS的实现上来说，都会更为简单。
下一代的Map-Reduce：
节点数：从目前的4000增加到6000-10000台
并发的任务数:从目前的40000增加到100000
更高级的硬件支持，目前支持的硬件主要是8core, 16G ram, 4T disk, 之后将会支持16+core, 48/96G ram, 24/48T disk
架构的改变，对现在的JobTracker-TaskTracker的结构做了很大的改进，现在会用ZooKeeper去保存master的状态，避免了之前提到的SPOF
更多的编程模式的支持（这个很重要）
比如MPI，迭代程序的处理，并且在Hadoop中运行这些类型的编程模式，并且这些程序将会被Hadoop统一管理
总结
之前谈了Hadoop的优势、劣势等等，综合来说就是，优势是很明显的（比如这么多牛公司在用，并且也贡献了很多的代码），远远超出了其他的分布式系统，劣势虽然不小，但是改进这些不足的地方是在计划中，已经在实施了。而且Hadoop不仅在学术界或者是工业界，都有很高的地位，综合了这些天时地利人和，那前途还是非常光明的
http://www.uplook.cn/kbase-Index-show-view13434.html?uid=173