因为企业版Redhat是收费的，不能免费使用yum源，导致yum命令不可用。可在本地构建yum repository解决该问题，步骤如下：
第一步：加载安装CD或ISO。
第二步：挂载CDROM至/mnt，命令如下：
# mount /dev/cdrom /mnt
注意事项：
通过DVD挂载ISO，如下：
# mount -o loop -t iso9660 /*/*.iso /mnt
第三步：创建或修改repo文件/etc/yum.repos.d/rhel6.repo，增加或修改内容如下：
[rhel]
name=rhel6
baseurl=file:///mnt
enabled=1
gpgcheck=0
第四步：安装软件。例如：yum install xxx。
第五步：卸载CDROM，命令如下：
# cd ~# umount /mnt

由于RedHat的yum源是收费的，在没有注册的情况下是无法使用该yum源。
针对这种情况，通过进行相关的设置，可以使用CentOS yum源进行软件包管理，具体设置步骤如下：
•删除原有yum源
$ rpm -aq |grep yum |xargs rpm -e –nodeps
•下载新yum源安装包（以32位，V6.0的RedHat为例）
$ wget http://mirror.centos.org/centos/6/os/i386/Packages/python-iniparse-0.3.1-2.1.el6.noarch.rpm
$ wget http://mirror.centos.org/centos/6/os/i386/Packages/yum-metadata-parser-1.1.2-14.1.el6.i686.rpm
$ wget http://mirror.centos.org/centos/6/os/i386/Packages/yum-3.2.27-14.el6.centos.noarch.rpm
$ wget http://mirror.centos.org/centos/6/os/i386/Packages/yum-plugin-fastestmirror-1.1.26-1.el6.noarch.rpm
•安装新yum源安装包
$ rpm -ivh python-iniparse-0.3.1-2.1.el6.noarch.rpm
$ rpm -ivh yum-metadata-parser-1.1.2-14.1.el6.i686.rpm
$ rpm -ivh yum-3.2.27-14.el6.centos.noarch.rpm yum-plugin-fastestmirror-1.1.26-11.el6.noarch.rpm
注意：后两个安装包需要放在一起安装。
•更新yum源（以网易的CentOS镜像源为例）
$ cd /etc/yum.repos.d/
$ wget http://mirrors.163.com/.help/CentOS6-Base-163.repo
$ vi CentOS6-Base-163.repo // 把$releasever替换成操作系统版本号，例如：6，而不是6.1,vi命令为：g/p1/s//p2/g
•清理yum缓存
$ yum clean all
$ yum makecache
$ yum install vim*
至此，RedHat可以通过免费的yum源进行安装、更新软件等操作了。

云计算在电信行业中的渗透正在不断加深。随着2011年下半年三大运营商纷纷发布自己的云战略，2012年“云服务”正成为新的关注热点。而对于电信业软件开发和服务提供商思特奇公司而言，作为业内最早向“云”转型的公司之一，2012年，正是自己的云业务布局大展拳脚、全面开花的一年。通过不断的产品调整，思特奇已经不单单是一家BOSS系统提供商，而是成为了能够同时提供如车辆定位、人员定位、电子社区、掌上行业应用、融合通信以及手机支付等多种应用的ICT方案提供商。而现在，思特奇的这些业务已经走上了“云端”。
新业务中心“腾云”
不久前，记者拜访了思特奇在北京的新业务中心。思特奇新业务中心总经理刘琨介绍说，这是思特奇在2011年5月新成立的部门，由原来的数据和增值业务部门转型而来。而思特奇与云计算相关的业务，目前也由新业务部门全面负责。
思特奇新业务中心总经理刘琨
思特奇的云计算战略规划，并非一朝一夕之功。早在2009年，云计算概念在中国还初露头角，思特奇就敏锐地捕捉到了市场的变化。“公司首先感受到虚拟化应用带来的研发和测试环境的改变，意识到，向云计算转型将成为运营商们的必经之路。”刘琨说。于是，思特奇开始了自己的云计算规划，推出了独特的E3Cloud“三朵云”解决方案：从运营商、软件开发商和最终用户三个角度，对通信行业的云应用进行了分析，将其划分为业务运营云、IT支撑云和应用开发云。而贯穿上述三类云的思特奇云计算战略核心思想，就是E3Cloud：Easy（便捷）、Elastic(弹性)、Efficient(有效)。等到2010年，思特奇在电信领域的解决方案已经成熟并且能够落地部署了。
而就在云计算解决方案的规划过程中，思特奇又进一步抓住了云时代的另一个关键词：云服务。基于云模式，在技术运算之外，把更多的可扩展相关服务带给运营商和用户，不仅降低部署和维护成本，也增加了客户的可用性。在此基础上，新业务中心应运而生。
就在刚刚过去的5月，思特奇从“第一届黑龙江省现代信息服务业创新发展高层论坛暨世界电信和信息社会日研讨大会”载誉归来。在黑龙江省打造的“中国云谷”数据城项目中，思特奇作为第一批主要参与成员，将助力黑龙江搭建云计算创新产业链平台。而黑龙江政务云建设中发挥重要作用的易成云平台，就是出自思特奇之手。“易成云”是基于云模式，完整涵盖云计算三层技术架构，以互联网和移动互联网为载体，面向政府和企业信息化建设提供软件产品和运营服务的平台。在易成云平台的基础上，思特奇新业务中心联合运营商面向政府和企业用户，推出了更多的新应用：易信，专门面向企业、政府机关提供基础信息服务产品；易位，是对公司人员、车辆进行定位管理的位置云服务；易联，为企业提供节约化、平台式的统一通信服务。
除此之外，思特奇还推出了别具特色的Myyule音乐云服务：在易成云平台的基础上通过在SaaS层实现互联网原创音乐的发布和分享运营平台，可为音乐群体提供官网与客户端的定制、分享社区、铃音下载等服务并在移动互联网上进行运营和推广，打造在线数字音乐服务业务模式。“这是我们特有的产品，也是云计算魔力的特有展现。”刘琨说。
打造开放“云生态圈”
谈起思特奇未来云计算战略的长期规划，刘琨表示，思特奇在努力成为云时代领先的服务提供商之外，也一直在致力于传播自己的云计算理念，与不同产业层的企业共同合作，加速“云落地”，打造和谐、开放的 “云生态圈”。
“云时代注定不是封闭的。”刘琨说，“云服务要具有竞争力，必须争取到更多的用户，提供更丰富的服务，而这不是一个公司能够做到的。比如我们的易位，思特奇提供云服务，但是还需要和车载终端企业合作，并联合运营商进行推广。这种和谐共生的局面，将是云时代的常态。”因此，思特奇期望通过自己的云平台，吸引更多的企业进行合作，促成更多的云应用落地。与黑龙江省在“中国云谷”项目上的合作，就是思特奇在此基础上的一次努力，以期在未来能够实现在基于思特奇搭建的云运营平台上，实现众多中小企业集约化、整合化、统一化的经营之路，同时打造开放性的云联盟，营造“多赢”的产业合作格局。
按照思特奇的云计算市场规划，其将发挥自身软件产品和云平台建设与运营的优势，实现对企业、家庭、社会三大用户群的服务。

【1】标准怪。虽说云计算还并未形成统一的标准，但与国外性比，国内在定义云计算时，将明显不是云计算的企业也称为云计算。在这方面，您是怎样的看法？
【2】构成怪。国外云计算是重视软件创新而减少硬件投入，国内则恰恰相反。据不完全统计，国内服务器总量 > 全球其他国家总量、中国服务器产值 > 全球其他国家总产值。您如何看待中国云计算投入的构成情况？
【3】 取名怪。国外云计算是以企业为导向的，因此就有了Amazon云、Google云、Facebook云、苹果云。而国内云计算却往往被命名为城市云、行业云……国内为什么会采用这种做法呢？这样对云计算发展有何作用？
【4】进程怪。与国外正好相反，国内公有云发展缓慢，私有云却进展迅速，部分应用开发商已经深入到企业核心业务层做深入的开发。您认为造成这种状况的原因是什么？
【5】运维怪。在国外，一个管理员通常会管理 2000~3000 台服务器，而国内则只管约 50 台服务器。从数字上看来，“中国人力成本低于美国”不应该成为主要因素，您认为这中间之所以差别那么的大的原因何在？
【6】开放怪。国外是由政府牵头进行数据开放的，而国内的数据很多情况下还是处于“孤岛”状态。要实现数据开放，应该从哪些方面进行努力？
【7】安全怪。国外有专业的审计公司来审计云安全，而国内虽然很多人也在说这种模式，但没有实实在在去做的。我们更多的是将云计算安全等同于互联网安全，并未针对云计算自身特点开发出专门的方案。对此，您有何建议？
【8】意识怪。尽管国人早已接受了银行的保险箱业务，但对在云计算平台中放入核心数据，如财务、客户关系、设计图纸等，并不放心。要解决这个问题，需要做些什么？
【9】地产怪。作为“清洁”、“环保”、“绿色”产业，IT为各地所重视，而云计算作为当前最热门的IT经济增长点，获得了大力支持，设立了不少所谓的 “云地产”。对此，各位怎么看？
【10】转化怪。云计算可以做高性能计算，但高性能计算却难以向云化发展。很多超算中心的收入，甚至都抵不过所耗的电费。对此，各位是怎样的看法？
 

PaaS能力开放安全鉴权，主要关注两点：
1、授权许可：
1）谁可以使用P层的能力？
2）哪些能力能被哪些人使用？
3）你怎么证明你就是你？
2、访问控制：
1）正确的用户获得他可以获得的能力
2）度量
sae:
服务限制与配额
SAE设置服务限制和配额的目的是为了防止个别用户攻击和滥用，从而在公有云计算平台上保证绝大多数开发者的正常使用。
服务限制和配额设定是在门户网站新浪自身长期运维的基础上经过严格计算得出的，所以正常使用一般不会出现问题。经过SAE实际统计，99%的应用不会受到任何影响
每一项服务有不同的限制项
查看 access key 和 secret key 需要输入安全密码，该安全密码和登录密码不一致，也可以采取动态密码。防止从客户这端无意的泄露密码。

在经历了长达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

如何充分利用你的技术知识？学一个技术很花时间，学会了就要充分利用它！拿它做许多项目，培养经验=>拿它讲课累积内容=>写杂志专栏累积教学内容=>把教学内容写成书（简体版）=>把书翻译成繁体出版=>把书翻译成英文出版=>视频讲课=>做成电子书=>修订增补内容，推出新版纸本书=>翻译成繁体 …