hadoop到底是什么玩意？0经验菜鸟的顿悟
昨天看见一个表结构的后缀，
STORED AS PARQUET
LOCATION 'hdfs://abc/user/hive/warehouse/fin_dw_dev.db/dwd_rsk_court_announ_dd'
TBLPROPERTIES ('transient_lastDdlTime'='')
我就想这是个什么玩意？然后。。。。
一张表莫名的尾部引发的灾难 -- 什么是spark --哎spark和hadoop相似 -- 哎hadoop干啥的 -- 哎hive是啥 -- 哎HDFS为啥叫分布式系统 -- 哎啥是集群 -- 哎啥是信道 -- 哎卧槽还有完没完。。
来吧，开头开好了，
相信刚看见hadoop的同学和我昨天一样，一脸懵逼，只知道和大数据有关系，但具体的就啥也不知道了。。来和我一起搞搞它。
首先了解几个概念，因为接下来你会用到它，不能好好了解这几个概念，你绝对懵的一逼，
集群：顾名思义，一个集合一个群体，就是一堆一样的东西，比如一堆苹果；10个厨师的集合；官方解释：同一个业务部署在多个服务器上，比如做菜，让10个厨师做菜
分布式（HDFS）：一个业务拆分成多个性质不同的子业务，再部署到不同服务器上，就好比做菜过程中，有洗菜的，切菜的，炒菜的，做这些事的人是不同的3个人，这个就叫分布式。
既然都说了是处理大数据吗，有多大量呢？就是如图的n*n。。。当然太多了，这个考虑到负载均衡 像什么网络吞吐量啥的，就有点崩溃的感觉，反正你想嘛！你最多背十块砖，再给你来100块让你背，是不你就炸了！！！同理同理。
然后来到hadoop下的几个概念：
在Hadoop部署中，有三种服务器角色，他们分别是客户端、Masters节点以及Slave 节点，是不是懵逼了，没事没事接着看
客户端就是干啥的呢，发送请求的呗，比如，它说：我要把file.txt文件分成3块添加到集群中去，就是发号施令，
然后这个Masters节点，它里面有俩核心的东西，HDFS和MapReduce，hdfs就是分布式系统了么，就是以分布式的形式处理数据的系统，MapReduce它呢，你储存确实牛逼，你储存了多少，还不得我给你算数量，它就是并行计算的，啥是并行？你算你的我算我的，咱俩同时算。
还剩Slave 节点这货了，负责具体工作和数据存储，具体工作是啥？你往下看啊你啊你。。
然后hadoop中还有成员呢，像那个谁，Name Node、DataNode、Secondary NameNode；Name Node很牛逼，就是个没有皮肤的王者，就是你客户端干点啥都得先来我这报道，然后我告诉你你去发数据给谁，谁给你处理数据，这个datanode处理数据处理到哪里了，数据处理完了你到哪里去取，反正干啥Name Node都知道，对于hadoop的所有成员的蛛丝马迹，它都有记录，如数家珍，namenode的官方名称说是叫元数据配置，就是描述数据的数据。Secondary
NameNode就是她的替补，有一天Name Node这哥们正在办事的过程中坏了，咋办，那事就不办了？不行啊，Secondary NameNode你上！！
对了，还有一个概念，叫做 机架，它是干啥的呢，其实我也不是很明白，你就知道这个机架意识，客户端下有机架，机架下有集群，集群下分布式系统，系统下有DataNode，你看它的位置，你是不是明白了什么，后续会有一个博客地址，你看完我的再看他的，很多事就好理解了。
客户端给HDFS分配任务并得到任务结果的过程：
【客户端已经准备好将 FILE.txt 分成三块添加到集群中（分别给 Block A
、 Block B、
Block C）。客户端会先告诉 Name Node 它将要把数据写入到集群中，从 Name Node处得到允许后，并受到 Name Node 为其分配的 Data Node 清单，当所有的 Data Node 已经成功的接收到了数据块，它们将会报告给 Name Node，同时也会告知客户端一切准备就绪并关闭回话，此时客户端也会返回一个成功的信息给 Name Node。Name Node 开始更新元数据信息将
Block A 在 File.txt 中的位置记录下来。】【当客户端打算从 HDFS 中取数据的时候，例如一个作业的结果，同样需要首先与 Name Node 打交道，得知想取的数据被存放在哪里，Name Node 同样会给客户端一个清单，然后客户端去 Name Node 指定的某个 Data Node 中拿数据（客户端不会逐个 Data Node 去拿数据，而是由 Name Node 指定的那个 Data Node 分别去其他的 Data Node 那里拿数据）】
Hadoop 是具体如何使用 Map Reduce 框架来进行快速运算：
第一步是 Map 阶段，在我们的例子中，我们要求我们的 Hadoop 集群计算出邮件中“Refund”单词的数量。 在一开始，客户端会提交一个 Map Reduce 作业，例如：“在 File.txt 中有多少个 Refund？”当然，这句话是翻译自 Java 语言，通过 Java 编写好一个 Map Reduce 作业并提交作业给 Job Tracker。Job Tracker 与 Name Node 协调得到哪些 Data Node 包含 File.txt 的数据块。 然后 Job Tracker 开始在这些
Data Node 上激活 Task Tracker。 Task Tracker 开始 Map 作业并监视任务进度。Task Tracker同时也提供心跳和任务状态给 Job Tracker。当所有的 Map 任务完成后，每个节点都会存放一个结果在其本地物理磁盘上，这被称为“中间数据”。接下来，就是将这些中间数据通过网络发送给一个执行 Reduce 任务的节点。 Job Tracker 总会尽量挑选处理 Map 任务的节点来处理 Reduce 任务，因为 Map 处理的数据就在本地，不需要通过网络来传输，但是，Job
Tracker 并不保证一定会挑选本地节点，因为可能 Map 任务较多，没有资源来运行 Reduce 任务，这样就会挑选其他的节点（同样Job Tracker 会根据机架意识来挑选同一机架内的其他节点来完成 Reduce 任务）
第二步就是 Reduce，当 Map 生成了中间数据后，现在我们需要将所有的这些中间数据汇总计算生成最终的数据。 Job Tracker 可能会挑选集群中任意一个节点来作为 Reduce 任务的处理服务器，此时可能会一次性有大量的数据涌向 Reduce 任务所在的节点服务器，这种情况通常被称为“Incast”或“fan-in”。这需要牛逼点的交换机以及内部流量管理和足够的缓冲区（不要太大，也不要太小）。缓冲区的大小最终可能会造成不必要的附带损害（流量相关）。现在 Reduce 已经收集到了所有从 Map 计算得到的中间数据，并可以开始最后阶段的计算，在本文的例子中，我们仅仅是简单的将各个结果相加即可得到“Refund”的数量。然后将结果写入到
Results.txt 文件。客户端可以从HDFS中读取Results.txt 文件，并将工作视为完成。
hadoop也面临着很多问题，这个你就去这哥们这里好好看看吧，相信看完我的你再看他的就事半功倍了。
http://blog.sina.com.cn/s/blog_4acavuxo.html
没有更多推荐了，
(window.slotbydup=window.slotbydup || []).push({
id: '5865575',
container: s,
size: '300,250',
display: 'inlay-fix'初始Hadoop
1、什么是Hadoop
hadoop是一个开源软件框架（面向大数据处理），可编写和运行分布式应用处理大规模数据，hadoop的数据来源可以是任何形式，在处理半结构化和非结构化数据上与关系型数据库相比有更好的的性能，擅长离线数据分析（不是在生产系统上对数据进行实时处理，比如：把生产线上的数据导入到专门的数据存储环境）。
hadoop就是一个分布式计算的解决方案。2、Hadoop的组成
hadoop是由分布式文件系统HDFS（Hadoop Distributed File System）和分布式计算框架MapReduce组成。3、Hadoop生态系统
hadoop生态系统主要包括：Hive、Habase、Pig、Sqoop、Flume、ZooKeeper、Mahout、Spark、Storm、Phoenix、Tez、Ambari，先介绍列入学习目标的Hive和Hbase。
Hive：用于Hadoop的一个数据仓库系统，他提供了类似于SQL的查询语言，通过使用 该语言可以方便的进行数据汇总、特定查询以及分析存放在Hadoop兼容文件系统中的大数据。
Hbase：一种分布的、可伸缩的、大数据存储库，支持随机、实时读写访问。
hadoop初始化和测试
Hadoop系列之初始Hadoop
hadoop 搭建后初始化及运行出现错误 cannot execute binary file
学习Hadoop第六课（初识HDFS原理）
学习Hadoop第四课（Hadoop初始化和测试）
Hadoop 键值对的mapreduce过程剖析
没有更多推荐了，
(window.slotbydup=window.slotbydup || []).push({
id: '5865575',
container: s,
size: '300,250',
display: 'inlay-fix'温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
Security is off.Safe
mode is ON. The reported blocks 0 needs additional 452 blocks to reach
the threshold 0.9990 of total blocks 452.
The number of live datanodes 0 has reached the minimum number 0. Safe
mode will be turned off automatically once the thresholds have been
reached.353 files and directories, 452 blocks = 805 total filesystem object(s).Heap Memory used 49.5 MB of 480 MB Heap Memory. Max Heap Memory is 889 MB. Non Heap Memory used 33.09 MB of 33.94 MB Commited Non Heap Memory. Max Non Heap Memory is 130 MB. DFS Used%:100% DFS Remaining%:0% Block Pool Used:0 B Block Pool Used%:100% DataNodes usages% (Min/Median/Max/stdDev): 0.00% / 0.00% / 0.00% / 0.00%0 (Decommissioned: 0)0 (Decommissioned: 0)0Number of Under-Replicated Blocks0Number of Blocks Pending Deletion0Block Deletion Start Time 上午11:25:012，controller日记信息：5-04-29 14:16:33,191 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Rescanning after 30000 m&&&&&& illiseconds5-04-29 14:16:33,191 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Scanned 0 directive(s) a&&&&&& nd 0 block(s) in 1 millisecond(s).5-04-29 14:17:03,190 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Rescanning after 30000 m&&&&&& illiseconds5-04-29 14:17:03,190 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Scanned 0 directive(s) a&&&&&& nd 0 block(s) in 0 millisecond(s).5-04-29 14:17:12,774 INFO org.apache.hadoop.ipc.Server: IPC Server handler 5 on 9000, call org.apache.hadoop.hdfs.server.&&&&&& protocol.NamenodeProtocol.rollEditLog from 127.0.0.1:32817 Call#319 Retry#0: org.apache.hadoop.hdfs.server.namenode.SafeMode&&&&&& Exception: Log not rolled. Name node is in safe mode.432155 The reported blocks 0 needs additional 452 blocks to reach the threshold 0.9990 of total blocks 452.432156 The number of live datanodes 0 has reached the minimum number 0. Safe mode will be turned off automatically once the thresho&&&&&& lds have been reached.5-04-29 14:17:33,191 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Rescanning after 30000 m&&&&&& illiseconds5-04-29 14:17:33,191 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Scanned 0 directive(s) a&&&&&& nd 0 block(s) in 0 millisecond(s).5-04-29 14:18:03,191 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Rescanning after 30000 m&&&&&& illiseconds5-04-29 14:18:03,191 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Scanned 0 directive(s) a&&&&&& nd 0 block(s) in 1 millisecond(s).
阅读(103)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
在LOFTER的更多文章
loftPermalink:'',
id:'fks_',
blogTitle:'hadoop崩溃记录',
blogAbstract:'1，HDFS web界面信息：SummarySecurity is off.Safe\n mode is ON. The reported blocks 0 needs additional 452 blocks to reach \nthe threshold 0.9990 of total blocks 452.\nThe number of live datanodes 0 has reached the minimum number 0. Safe \nmode will be turned off automatically once the thresholds have been \nreached.353 files and directories,',
blogTag:'hadoop',
blogUrl:'blog/static/',
isPublished:1,
istop:false,
modifyTime:0,
publishTime:9,
permalink:'blog/static/',
commentCount:0,
mainCommentCount:0,
recommendCount:1,
bsrk:-100,
publisherId:0,
recomBlogHome:false,
currentRecomBlog:false,
attachmentsFileIds:[],
groupInfo:{},
friendstatus:'none',
followstatus:'unFollow',
pubSucc:'',
visitorProvince:'',
visitorCity:'',
visitorNewUser:false,
postAddInfo:{},
mset:'000',
remindgoodnightblog:false,
isBlackVisitor:false,
isShowYodaoAd:false,
hostIntro:'',
hmcon:'0',
selfRecomBlogCount:'0',
lofter_single:''
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}以供DBA技术的交流，学习，解决问题！！
为Hadoop集群选择合适的硬件配置
存储，学习，共享
最近3天一直在搞hadoop集群CDH的安装，本来很easy的事情，搞了3天崩溃。。。。
最后在最信任，技术最牛的领导的帮助下，总算搭建成功，服务都跑起来，而且监控显示绿色的。。。。很开心。。。
但是，在hbase上创建表时，发现。。。无法创建成功，而且，日志也不报错。。。最后发现hdfs,hbase
，data节点，不在同一个组内，调整到同一个组内后，创建表成功，但是在put
数据时，又遇到了毫无反应的结果。。。数据写入不成功，而且报错。master,hdfs
上的日志只是一直重复报错如下：
最后我们反思总结如下：我们在云虚拟机上创建hadoop集群本身就是有问题的。在虚拟化的基础上虚拟化就造成如下问题：
15:59:00,316 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: there are no corrupt file blocks.
15:59:00,353 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* allocateBlock: /tmp/.cloudera_health_monitoring_canary_files/.canary_file_-15_59_00. BP-.105.33.34-3 blk__1250{blockUCState=UNDER_CONSTRUCTION,
primaryNodeIndex=-1, replicas=[ReplicaUnderConstruction[[DISK]DS-fbf7c49f-0eac-481c-a85c-b32fa7e4e876:NORMAL|RBW], ReplicaUnderConstruction[[DISK]DS-109ff584-e6cb-f5f8b4cd70:NORMAL|RBW], ReplicaUnderConstruction[[DISK]DS-022f1e9a-27a4-48c3-be3a-d3a179b6fd78:NORMAL|RBW]]}
15:59:00,374 INFO BlockStateChange: BLOCK* addStoredBlock: blockMap updated: 10.143.34.48:50010 is added to blk__1250{blockUCState=UNDER_CONSTRUCTION, primaryNodeIndex=-1, replicas=[ReplicaUnderConstruction[[DISK]DS-fbf7c49f-0eac-481c-a85c-b32fa7e4e876:NORMAL|RBW],
ReplicaUnderConstruction[[DISK]DS-109ff584-e6cb-f5f8b4cd70:NORMAL|RBW], ReplicaUnderConstruction[[DISK]DS-022f1e9a-27a4-48c3-be3a-d3a179b6fd78:NORMAL|RBW]]} size 0
15:59:00,376 INFO BlockStateChange: BLOCK* addStoredBlock: blockMap updated: 10.105.33.34:50010 is added to blk__1250{blockUCState=UNDER_CONSTRUCTION, primaryNodeIndex=-1, replicas=[ReplicaUnderConstruction[[DISK]DS-fbf7c49f-0eac-481c-a85c-b32fa7e4e876:NORMAL|RBW],
ReplicaUnderConstruction[[DISK]DS-109ff584-e6cb-f5f8b4cd70:NORMAL|RBW], ReplicaUnderConstruction[[DISK]DS-022f1e9a-27a4-48c3-be3a-d3a179b6fd78:NORMAL|RBW]]} size 0
15:59:00,377 INFO BlockStateChange: BLOCK* addStoredBlock: blockMap updated: 10.237.142.111:50010 is added to blk__1250{blockUCState=UNDER_CONSTRUCTION, primaryNodeIndex=-1, replicas=[ReplicaUnderConstruction[[DISK]DS-fbf7c49f-0eac-481c-a85c-b32fa7e4e876:NORMAL|RBW],
ReplicaUnderConstruction[[DISK]DS-109ff584-e6cb-f5f8b4cd70:NORMAL|RBW], ReplicaUnderConstruction[[DISK]DS-022f1e9a-27a4-48c3-be3a-d3a179b6fd78:NORMAL|RBW]]} size 0
15:59:00,379 INFO org.apache.hadoop.hdfs.StateChange: DIR* completeFile: /tmp/.cloudera_health_monitoring_canary_files/.canary_file_-15_59_00 is closed by DFSClient_NONMAPREDUCE_
15:59:00,386 INFO BlockStateChange: BLOCK* addToInvalidates: blk__.142.111:.33.34:.34.48:50010
15:59:01,545 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* BlockManager: ask 10.237.142.111:50010 to delete [blk__1185, blk__1250]
15:59:04,545 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* BlockManager: ask 10.143.34.48:50010 to delete [blk__1185, blk__1250]
15:59:07,546 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* BlockManager: ask 10.105.33.34:50010 to delete [blk__1250]
15:59:25,293 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Rescanning after 30000 milliseconds
15:59:25,294 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Scanned 0 directive(s) and 0 block(s)
随着 的起步，云客户的增多面临的首要问题就是如何为他们新的的集群选择合适的硬件。
尽管Hadoop被设计为运行在行业标准的硬件上，提出一个理想的集群配置不想提供硬件规格列表那么简单。 选择硬件，为给定的负载在性能和经济性提供最佳平衡是需要测试和验证其有效性。（比如，IO密集型工作负载的用户将会为每个核心主轴投资更多）。
在这个博客帖子中，你将会学到一些工作负载评估的原则和它在硬件选择中起着至关重要的作用。在这个过程中，你也将学到Hadoop管理员应该考虑到各种因素。
结合存储和计算
过去的十年，IT组织已经标准化了刀片服务器和存储区域网(SAN)来满足联网和处理密集型的工作负载。尽管这个模型对于一些方面的标准程序是有相当意义 的，比如网站服务器，程序服务器，小型结构化数据库，数据移动等，但随着数据数量和用户数的增长，对于基础设施的要求也已经改变。网站服务器现在有了缓存 层；数据库需要本地硬盘支持大规模地并行；数据迁移量也超过了本地可处理的数量。
大部分的团队还没有弄清楚实际工作负载需求就开始搭建他们的Hadoop集群。
硬件提供商已经生产了创新性的产品系统来应对这些需求，包括存储刀片服务器，串行SCSI交换机，外部SATA磁盘阵列和大容量的机架单元。然 而，Hadoop是基于新的实现方法，来存储和处理复杂数据，并伴随着数据迁移的减少。 相对于依赖SAN来满足大容量存储和可靠性，Hadoop在软件层次处理大数据和可靠性。
Hadoop在一簇平衡的节点间分派数据并使用同步复制来保证数据可用性和容错性。因为数据被分发到有计算能力的节点，数据的处理可以被直接发送到存储有数据的节点。由于Hadoop集群中的每一台节点都存储并处理数据，这些节点都需要配置来满足数据存储和运算的要求。
工作负载很重要吗？
在几乎所有情形下，MapReduce要么会在从硬盘或者网络读取数据时遇到瓶颈（称为IO受限的应用），要么在处理数据时遇到瓶颈（CPU受限）。排序是一个IO受限的例子，它需要很少的CPU处理（仅仅是简单的比较操作），但是需要大量的从硬盘读写数据。模式分类是一个CPU受限的例子，它对数据进行复杂的处理，用来判定本体。
下面是更多IO受限的工作负载的例子：
索引分组数据导入导出数据移动和转换
下面是更多CPU受限的工作负载的例子：
聚类/分类复杂文本挖掘自然语言处理特征提取
Cloudera的客户需要完全理解他们的工作负载，这样才能选择最优的Hadoop硬件，而这好像是一个鸡生蛋蛋生鸡的问题。大多数工作组在没有彻底剖 析他们的工作负载时，就已经搭建好了Hadoop集群，通常Hadoop运行的工作负载随着他们的精通程度的提高而完全不同。而且，某些工作负载可能会被 一些未预料的原因受限。例如，某些理论上是IO受限的工作负载却最终成为了CPU受限，这是可能是因为用户选择了不同的压缩算法，或者算法的不同实现改变 了MapReduce任务的约束方式。基于这些原因，当工作组还不熟悉要运行任务的类型时，深入剖析它才是构建平衡的Hadoop集群之前需要做的最合理
接下来需要在集群上运行MapReduce基准测试任务，分析它们是如何受限的。完成这个目标最直接的方法是在运行中的工作负载中的适当位置添加监视器来 检测瓶颈。我们推荐在Hadoop集群上安装Cloudera Manager，它可以提供CPU，硬盘和网络负载的实时统计信息。（Cloudera Manager是Cloudera 标准版和企业版的一个组件，其中企业版还支持滚动升级）Cloudera Manager安装之后，Hadoop管理员就可以运行MapReduce任务并且查看Cloudera Manager的仪表盘，用来监测每台机器的工作情况。
第一步是弄清楚你的作业组已经拥有了哪些硬件
在为你的工作负载构建合适的集群之外，我们建议客户和它们的硬件提供商合作确定电力和冷却方面的预算。由于Hadoop会运行在数十台，数百台到数千台节 点上。通过使用高性能功耗比的硬件，作业组可以节省一大笔资金。硬件提供商通常都会提供监测功耗和冷却方面的工具和建议。
为你的CDH(Cloudera distribution for Hadoop)
Cluster选择硬件
选择机器配置类型的第一步就是理解你的运维团队已经在管理的硬件类型。在购买新的硬件设备时，运维团队经常根据一定的观点或者强制需求来选择，并且他们倾 向于工作在自己业已熟悉的平台类型上。Hadoop不是唯一的从规模效率上获益的系统。再一次强调，作为更通用的建议，如果集群是新建立的或者你并不能准 确的预估你的极限工作负载，我们建议你选择均衡的硬件类型。
Hadoop集群有四种基本任务角色:名称节点（包括备用名称节点），工作追踪节点，任务执行节点，和数据节点。节点是执行某一特定功能的工作站。大部分你的集群内的节点需要执行两个角色的任务，作为数据节点（数据存储）和任务执行节点（数据处理）。
这是在一个平衡Hadoop集群中，为数据节点/任务追踪器提供的推荐规格：
在一个磁盘阵列中要有12到24个1~4TB硬盘2个频率为2~2.5GHz的四核、六核或八核CPU64~512GB的内存有保障的千兆或万兆以太网（存储密度越大，需要的网络吞吐量越高）
名字节点角色负责协调集群上的数据存储，作业追踪器协调数据处理（备用的名字节点不应与集群中的名字节点共存，并且运行在与之相同的硬件环境上。）。 Cloudera推荐客户购买在RAID1或10配置上有足够功率和企业级磁盘数的商用机器来运行名字节点和作业追踪器。
NameNode也会直接需要与群集中的数据块的数量成比列的RAM。一个好的但不精确的规则是对于存储在分布式文件系统里面的每一个1百万的数据块，分 配1GB的NameNode内存。于在一个群集里面的100个DataNodes而言，NameNode上的64GB的RAM提供了足够的空间来保证群集 的增长。我们也推荐把HA同时配置在NameNode和JobTracker上，
这里就是为NameNode／JobTracker／Standby NameNode节点群推荐的技术细节。驱动器的数量或多或少，将取决于冗余数量的需要。
4–6 1TB 硬盘驱动器 采用 一个
JBOD 配置 (1个用于OS, 2个用于文件系统映像[RAID 1], 1个用于 ZooKeeper,
1个用于Journal节点)2 4-/16-/8-核心 CPUs, 至少运行于 2-2.5GHz64-128GB 随机存储器Bonded Gigabit 以太网卡 or 10Gigabit 以太网卡
记住, 在思想上，Hadoop 体系设计为用于一种并行环境。
如果你希望Hadoop集群扩展到20台机器以上，那么我们推荐最初配置的集群应分布在两个机架，而且每个机架都有一个位于机架顶部的10G的以太网交 换。当这个集群跨越多个机架的时候，你将需要添加核心交换机使用40G的以太网来连接位于机架顶部的交换机。两个逻辑上分离的机架可以让维护团队更好地理 解机架内部和机架间通信对网络需求。
Hadoop集群安装好后，维护团队就可以开始确定工作负载，并准备对这些工作负载进行基准测试以确定硬件瓶颈。经过一段时间的基准测试和监视，维护团队 将会明白如何配置添加的机器。异构的Hadoop集群是很常见的，尤其是在集群中用户机器的容量和数量不断增长的时候更常见-因此为你的工作负载所配置的 “不理想”开始时的那组机器不是在浪费时间。Cloudera管理器提供了允许分组管理不同硬件配置的模板，通过这些模板你就可以简单地管理异构集群了。
下面是针对不同的工作负载所采用对应的各种硬件配置的列表，包括我们最初推荐的“负载均衡”的配置：
轻量处理方式的配置(1U的机器）:两个16核的CPU，24-64GB的内存以及8张硬盘（每张1TB或者2TB)。负载均衡方式的配置(1U的机器）:两个16核的CPU，48-128GB的内存以及由主板控制器直接连接的12-16张硬盘（每张1TB或者2TB)。通常在一个2U的柜子里使用2个主板和24张硬盘实现相互备份。超大存储方式的配置(2U的机器）:两个16核的CPU，48-96GB的内存以及16-26张硬盘（每张2TB-4TB)。这种配置在多个节点/机架失效时会产生大量的网络流量。强力运算方式的配置(2U的机器）:两个16核的CPU，64-512GB的内存以及4-8张硬盘（每张1TB或者2TB)。
（注意Cloudera期望你配置它可以使用的2×8,2×10和2×12核心CPU的配置。)
下图向你展示了如何根据工作负载来配置一台机器：
其他要考虑的
记住Hadoop生态系统的设计是考虑了并行环境这点非常重要。当购买处理器时，我们不建议购买最高频率(GHZ)的芯片，这些芯片都有很高的功耗 （130瓦以上）。这么做会产生两个问题：电量消耗会更高和热量散发会更大。处在中间型号的CPU在频率、价格和核心数方面性价比是最好的。
当我们碰到生成大量中间数据的应用时-也就是说输出数据的量和读入数据的量相等的情况-我们推荐在单个以太网接口卡上启用两个端口，或者捆绑两个以太网 卡，让每台机器提供2Gbps的传输速率。绑定2Gbps的节点最多可容纳的数据量是12TB。一旦你传输的数据超过12TB，你将需要使用传输速率为捆 绑方式实现的4Gbps(4x1Gbps)。另外，对哪些已经使用10Gb带宽的以太网或者无线网络用户来说，这样的方案可以用来按照网络带宽实现工作负 载的分配。如果你正在考虑切换到10GB的以太网络上，那么请确认操作系统和BIOS是否兼容这样的功能。
当计算需要多少内存的时候，记住本身要使用高达10%的内存来管理虚拟机。我们建议把Hadoop配置为只使用堆，这样就可以避免内存与磁盘之间
的切换。切换大大地降低MapReduce任务的性能，并且可以通过给机器配置更多的内存以及给大多数发布版以适当的内核设置就可以避免这种切
优化内存的通道宽度也是非常重要的。例如，当我们使用双通道内存时，每台机器就应当配置成对内存模块（DIMM）。当我们使用三通道的内存时，每台机器都应当使用三的倍数个内存模块（DIMM）。类似地，四通道的内存模块（DIMM)就应当按四来分组使用内存。
超越MapReduce
Hadoop不仅仅是HDFS和MapReduce；它是一个无所不包的数据平台。因此CDH包含许多不同的生态系统产品（实际上很少仅仅做为 MapReduce使用）。当你在为集群选型的时候，需要考虑的附加软件组件包括Apache HBase、Cloudera Impala和Cloudera Search。它们应该都运行在DataNode中来维护数据局部性。
关注资源管理是你成功的关键。
HBase是一个可靠的列数据存储系统，它提供一致性、低延迟和随机读写。Cloudera Search解决了CDH中存储内容的全文本搜索的需求，为新类型用户简化了访问，但是也为Hadoop中新类型数据存储提供了机会。Cloudera Search基于Apache Lucene/Solr Cloud和Apache Tika，并且为与CDH广泛集成的搜索扩展了有价值的功能和灵活性。基于Apache协议的Impala项目为Hadoop带来了可扩展的并行数据库技 术，使得用户可以向HDFS和HBase中存储的数据发起低延迟的SQL查询，而且不需要数据移动或转换。
由于垃圾回收器（GC）的超时，HBase 的用户应该留意堆的大小的限制。别的JVM列存储也面临这个问题。因此，我们推荐每一个区域服务器的堆最大不超过16GB。HBase不需要太多别的资源 而运行于Hadoop之上，但是维护一个实时的SLAs，你应该使用多个调度器，比如使用fair and capacity 调度器，并协同Linux Cgroups使用。
Impala使用内存以完成其大多数的功能，在默认的配置下，将最多使用80％的可用RAM资源，所以我们推荐，最少每一个节点使用96GB的RAM。与MapReduce一起使用Impala的用户，可以参考我们的建议 －
也可以为Impala指定特定进程所需的内存或者特定查询所需的内存。
搜索是最有趣的订制大小的组件。推荐的订制大小的实践操作是购买一个节点，安装Solr和Lucene，然后载入你的文档群。一旦文档群被以期望的方式来 索引和搜索，可伸缩性将开始作用。持续不断的载入文档群，直到索引和查询的延迟，对于项目而言超出了必要的数值 － 此时，这让你得到了在可用的资源上每一个节点所能处理的最大文档数目的基数，以及不包括欲期的集群复制此因素的节点的数量总计基数。
购买合适的硬件，对于一个Hapdoop群集而言，需要性能测试和细心的计划，从而全面理解工作负荷。然而，Hadoop群集通常是一个形态变化的系统， 而Cloudera建议，在开始的时候，使用负载均衡的技术文档来部署启动的硬件。重要的是，记住，当使用多种体系组件的时候，资源的使用将会是多样的， 而专注与资源管理将会是你成功的关键。
我们鼓励你在留言中，加入你关于配置Hadoop生产群集服务器的经验！
Kevin O‘Dell 是一个工作于Cloudera的系统工程师。
英文原文：
翻译：http://www.oschina/translate/how-to-select-the-right-hardware-for-your-new-hadoop-cluster
淘宝Hadoop集群机器硬件配置
国内外使用Hadoop的公司比较多，全球最大的Hadoop集群在雅虎，有大约25000个节点，主要用于支持广告系统与网页搜索。国内用Hadoop的主要有百度、淘宝、腾讯、华为、中国移动等，其中淘宝的Hadoop集群属于较大的（如果不是最大）。
淘宝Hadoop集群现在超过1700个节点，服务于用于整个阿里巴巴集团各部门，数据来源于各部门产品的线上数据库（, ）备份，系统日志以及爬虫数据，截止2011年9月，数量总量已经超过17个PB，每天净增长20T左右。每天在Hadoop集群运行的MapReduce任务有超过4万（有时会超过6万），其中大部分任务是每天定期执行的统计任务，例如数据魔方、量子统计、推荐系统、排行榜等等。这些任务一般在凌晨1点左右开始执行，3-4个小时内全部完成。每天读数据在2PB左右，写数据在1PB左右。
this picture is from Taobao
Hadoop包括两类节点Master和Slave节点，
Master节点包括Jobtracker，Namenode, SecondName, Standby，
硬件配置：16CPU*4核，96G内存。Slave节点主要是TaskTracker和DataNode，
硬件配置存在一定的差别：8CPU*4核-16CPU*4核，16G-24G内存（注：通常是一个slave节点同时是TaskTracker和DataNode，目的是提高数据本地性data locality）。每个slave节点会划分成12~24个slots。整个集群约34,916个slots，其中Map slots是19,643个，Reduce slots是15，273个
所有作业会进行分成多个Group，按照部门或小组划分，总共有38个Group。整个集群的资源也是按各个Group进行划分，定义每个Group的最大并发任务数，Map slots与Reduce slots的使用上限。每个作业只能使用自己组的slots资源。
Hadoop集群硬件标准配置
如何为Hadoop集群选择正确的硬件
内存小于16GG搭建Hadoop集群的一些个人观点
没有更多推荐了，
(window.slotbydup=window.slotbydup || []).push({
id: '5865575',
container: s,
size: '300,250',
display: 'inlay-fix'