修改hadoop配置文件
1.hadoop-env.sh
export JAVA_HOME=/usr/local/jdk/
2.core-site.xml
<configuration>
<property>
<name>fs.default.name</name>
<value>hdfs://hadoop0:9000</value>
</property>
<property>
<name>hadoop.tmp.dir</name>
<value>/usr/local/hadoop/tmp</value>
</property>
</configuration>
3.hdfs-site.xml
<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.permissions</name>
<value>false</value>
</property>
</configuration>
4.mapred-site.xml
<configuration>
<property>
<name>mapred.job.tracker</name>
<value>hadoop0:9001</value>
</property>
</configuration>
启动hadoop: hadoop namenode -format,再执行./start-all.sh
hadoop核心组成是什么，安装伪分布模式步骤，hadoop目录有哪些，如果运行jar包中的hadoop程序。
集群环境搭建过程
scp -rq source destination
适合大数据的分布式存储和计算平台.Hadoop中的核心就是HDFS(Hadoop Distributed File System)hadoop分布式文件系统，还有一个就是MapReduce并行计算框架.
Hadoop分布式文件系统：
当数据集的大小超过一台独立物理计算机的存储能力时，就有必要对它进行分区(Partition)，并存储到若干台单独的计算机上，管理网络中跨多台计算机存储的文件系统称为分布式文件系统(Distributed File System)。
Hadoop有一个称为HDFS的分布式文件系统,全程Hadoop Distributed File System。在非正式文档或旧文档以及配置文件中，有时也简称为DFS。
Hadoop中的MapReduce计算框架：
在Hadoop中，其实处理数据都是由MapReduce来进行处理，首先由Map过滤数据或其他操作，在Map的输出时Reduce端的输入，Reduce端拿到Map端的输出后，分别对数据进行分区，排序，分组，聚合等操作，最后Reduce端把处理后的数据输出到HDFS中进行存储，再后可以把处理的数据提取并做其他相应需求操作。
HDFS体系结构简介及优缺点
体系结构简介
HDFS是一个主/从(Master、Slave)体系结构，从最终用户的角度来看，它就像传统的文件系统一样，可以通过目录路径对文件执行CRUD(创建，读取，修改，删除)等操作。但由于分布式存储的性质，HDFS集群拥有一个NameNode和多个DataNode。NameNode管理文件系统的元数据，DataNode存储实际的数据。客户端通过同NameNode和DataNode的交互访问文件系统。客户端联系NameNode以获取文件的元数据，而真正的文件I/O操作是直接和DataNode进行交互的。
NameNode：
NameNode是整个文件系统的管理节点.
作用：
1、负责管理文件系统的命名空间、集群配置信息和存储块的复制；
2、维护着整个文件系统的文件目录树和文件根目录的元信息和每个文件对应的数据块列表；
3、接收用户的操作请求；
4、管理文件与block之间的关系，block与DataNode之间的关系；
NameNode会将文件系统的Meta-Data存储在内存中，这些信息主要包括了文件信息、每一个文件对应的文件块的信息和每一个文件块在DataNode的信息等。没有NameNode，文件系统将无法使用。实现上，如果运行NameNode服务的机器毁坏，文件系统上所有的文件将会丢失，因为我们不知道如果根据DataNode的块来重建文件。因此，对NameNode实现容错非常重要，Hadoop为此提供了2种机制：
第一种机制：备份哪些组成文件系统元数据持久状态的文件。Hadoop可以通过配置使NameNode在多个文件系统上保存元数据的持久状态，这些写操作是实时同步的，是原子操作，一般的配置是将持久状态写入本地磁盘的同时，写入一个远程挂载的网络文件系统(NFS)。
第二种机制：运行一个辅助NameNode，但它不能被用作NameNode.这个辅助NameNode的重要作用是定期通过编辑日志合并命名空间镜像，以防止编辑日志过大。这个辅助NameNode一般在另一台单独的物理计算机上运行，因为它需要占用大量CPU时间与NameNode相同容量的内存来执行合并操作。它会报出合并后的命名空间镜像的副本，并在NameNode发送故障时启用，但是，辅助NameNoDE报错的状态总数滞后于主节点，所以在主节点全部失效时，难免会丢失部分数据。在这种情况下，一般把存储在NFS上的NameNode元数据复制到辅助NameNode并作为新的主NameNode运行。
NameNode中的文件：
fsimage：元数据镜像文件。存储某一时段NameNode内存中的元数据信息。
edits：操作日志文件。
fstime：保存最近一次checkpoint的时间。
SecondaryNameNode：
HA(双机集群系统简称)的一个解决方案，并非NameNode的热备。
作用：
1、辅助NameNode分担其工作量；
2、定期合并fsimage和edits，并推送给NameNode；
3、减少NameNode启动时间；
4、在紧急情况下，可辅助恢复NameNode；
执行过程：
从NameNode上下载元数据信息(fsimage,edits)，然后把二者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，同时重置NameNode的edits。
DataNode：
DataNode是提供真实文件数据的存储服务，是文件存储的基本单元，它将Block存储在本地文件系统中，保存了Block的Meta-data，同时周期性地将所有存在的Block信息发送给NameNode。
DataNode也是文件系统的工作节点，它们根据需要存储并检索数据库(受客户端或NameNode调度)，并且定期向NameNode发送它们所在存储的块的列表。
块(Block)是DataNode中最基本的存储单位。
数据块的概念：
对于文件内存而言，一个文件的长度大小是size，那么从文件的0偏移开始，按照固定的大小，顺序对文件进行划分并编号，划分好的每一个块称为一个Block。
在HDFS中，HDFS默认Block大小是64MB，不同于普通文件系统的是，HDFS中，如果一个文件小于一个数据块的大小，并不会占用整个block的存储空间。
为什么HDFS中的数据块如此之大？
HDFS的块比磁盘块大，其目的是为了最小化寻址开销。如果块设置得足够大，从磁盘传输数据的时间可以明显大于这个快开始位置所需的时间。这样，传输一个由多个块组成的文件的时间取决于磁盘传输速率。
在很多情况下HDFS使用128MB的设置。但是该参数也不会设置得过大，MapReduce中的map任务通常一次处理一个块中的数据，因此如果任务数太少(少于集群中的节点数据)，作业的运行速度就会比较慢。
每个文件有多个复本，HDFS中默认是3个。可在hdfs-site.xml中配置（dfs.replication属性）。
HDFS中的Master：
在Hadoop中的conf下的Master配置文件中，在此文件中的节点主要的作用：
1、管理HDFS的名称空间；
2、管理数据块映射信息；
3、配置复本策略；
4、处理客户端读写请求；
HDFS中的Slave：
配置在Hadoop中conf目录下的Slaves文件中的节点主要作用：
1、存储实际的数据块；
2、执行数据块读/写；
HDFS中的Client：
作用：
1、文件切分与NameNode交互，获取文件位置信息；
2、与DataNode交互，读取或者写入数据；
3、管理HDFS；
4、访问HDFS；
HDFS的优点：
1、处理超大文件
这里的超大文件通常是指百MB、甚至数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据了。
2、流式的访问数据
HDFS的设计建立在“一次写入、多次读写”任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。
3、运行于廉价的商用机器集群上
Hadoop设计对应急需求比较低，只须运行在低廉的商用硬件集群上，而无需在昂贵的高可用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。HDFS遇到了上述故障时，被设计成能够继续运行且不让用户察觉到明显的中断。
HDFS的缺点：
1、不适合低延迟数据访问
如果要处理一些用户要求时间比较短的低延迟应用请求，则HDFS不适合。HDFS是为了处理大型数据集分析任务的，主要是为达到高的数据吞吐量而设计的，这就可能要求以高延迟作为代价。
改进策略：
对于那些有低延时要求的应用程序，HBase是一个更好的选择，通过上层数据管理项目尽可能地弥补这个不足。在性能上有了很大的提升，它的口号是goes real time。使用缓存或多个master设计可以降低Clinet的数据请求压力，以减少延时。
2、无法高效存储大量的小文件
因为NameNode把文件系统的元数据放置在内存中，所有文件系统所能容纳的文件数目是由NameNode的内存大小来决定。还有一个问题就是，因为MapTask的数量是由Splits来决定的，所以用MR处理大量的小文件时，就会产生过多的MapTask，线程管理开销将会增加作业时间。当Hadoop处理很多小文件(文件大小小于HDFS中Block大小)的时候，由于FileInputFormat不会对小文件进行划分，所以每一个小文件都会被当做一个Split并分配一个Map任务，导致效率底下。
例如：一个1G的文件，会被划分成16个64MB的Split，并分配16个Map任务处理，而10000个100Kb的文件会被10000个Map任务处理。
改进策略：
要想让HDFS能处理好小文件，有不少方法。利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。
3、不支持多用户写入及任意修改文件
在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作，目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。
HDFS是一个不错的分布式文件系统，它有很多的优点，但也存在有一些缺点。目前而言，它在以下几个方面就效率不佳： 低延时访问 HDFS不太适合于那些要求低延时（数十毫秒）访问的应用程序
HDFS是一个不错的分布式文件系统，它有很多的优点，但也存在有一些缺点。目前而言，它在以下几个方面就效率不佳：
低延时访问
HDFS不太适合于那些要求低延时（数十毫秒）访问的应用程序，因为HDFS是设计用于大吞吐量数据的，这是以一定延时为代价的。HDFS是单Master的，所有的对文件的请求都要经过它，当请求多时，肯定会有延时。当前，对于那些有低延时要求的应用程序，HBase是一个更好的选择。现在HBase的版本是0.20，相对于以前的版本，在性能上有了很大的提升，它的口号就是goes real time。
使用缓存或多master设计可以降低client的数据请求压力，以减少延时。还有就是对HDFS系统内部的修改，这就得权衡大吞吐量与低延时了，HDFS不是万能的银弹。
大量小文件
因为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。
要想让HDFS能处理好小文件，有不少方法：
1、利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。对于这种方法，如果想找回原来的小文件内容，那就必须得知道与归档文件的映射关系。
2、横向扩展，一个Hadoop集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大的Hadoop集群。google也是这么干过的。
3、多Master设计，这个作用显而易见了。正在研发中的GFS II也要改为分布式多Master设计，还支持Master的Failover，而且Block大小改为1M，有意要调优处理小文件啊。
附带个Alibaba DFS的设计，也是多Master设计，它把Metadata的映射存储和管理分开了，由多个Metadata存储节点和一个查询Master节点组成。
多用户写，任意文件修改
目前Hadoop只支持单用户写，不支持并发多用户写。可以使用Append操作在文件的末尾添加数据，但不支持在文件的任意位置进行修改。这些特性可能会在将来的版本中加入，但是这些特性的加入将会降低Hadoop的效率，就拿GFS来说吧，这篇文章里就说了google自己的人都用着Multiple Writers很不爽。
利用Chubby、ZooKeeper之类的分布式协调服务来解决一致性问题。
Hadoop并非完美：8个代替 HDFS 的绝佳方案
HDFS（Hadoop Distributed File System）是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，坦白说HDFS是一个不错的分布式文件系统，它有很多的优点，但也存在有一些缺点，包括：不适合低延迟数据访问、无法高效存储大量小文件、不支持多用户写入及任意修改文件。0
Apache软件基金会成立的时候，HDFS就一直在想办法提高它的性能和可用性，坦白说，这也许对试点项目、非常规项目、要求不严格的大环境中比较适用，但是对于某些Hadoop用户来说，他们对于性能、可用性、企业级特性有较高的要求，且注重直接附加存储(DAS)架构，特别是老版本的Hadoop没有高性能的主节点，那么接下来8个产品就是代替HDFS的绝佳方案。
1. Cassandra (DataStax)
并非一个完全的文件系统，而是一个开源、NoSQL 键值（key-value）商店。这给依靠快速数据访问的Web 应用多了一个HDFS选择。简单来说它把Hadoop融合在Cassandra里面，支持Web应用通过Hadoop快速访问数据, 而Hadoop可以快速访问流入Cassandra的数据。
2. Ceph
Ceph 是一个开源、多管齐下的操作系统，因为其高性能并行文件系统的特性，有人甚至认为它是基于Hadoop环境下的HDFS的接班人，因为自2010年就有研究者在寻找这个特性。
3. Cleversafe：分散存储网络
本周一Cleversafe宣布将融合Hadoop的并行编程技术和自己的分散存贮网络。其原理是通过把整个元数据分布在集群中（不是依靠单个主节点、不是依靠复制），Cleversafe表示这比HDFS更快、更稳定、更具扩展性。
IBM一直在向高性能要求的用户销售其并行文件系统，包括世界上最快的超级电脑，2010年它推出了基于Hadoop的GPFS, 并宣布GPFS不共享集群版本比Hadoop快多了，因为
它在内核级别中运行，而不是在操作系统中运行例如HDFS。
5. Isilon (EMC)
EMC提供Hadoop发行版已经一年了，但2012年1月转型为HDFS企业级别的新方案——Isilon 的 OneFS文件系统。因为Isilon可以读取 NFS, CIFS以及 HDFS 协议, 一个单独的 Isilon NAS系统可以摄入、处理、分析数据。
6. Lustre
HPC存储提供商Xyratex 增在2011年的一份报道中写到， 基于Lustre的集群会比基于HDFS的集群更快更便宜。
7. MapR 文件系统
MapR 文件系统在业内已经具有一定知名度了，不仅MapR宣布它自己的文件系统比HDFS快2-5倍（实际上有20倍），它还具有镜像、快照、高性能这些企业用户喜欢的特点。
8. NetApp Hadoop开放方案
NetApp重新改版了物理Hadoop结构：把HDFS放在磁盘阵列中，通过这样来达到更快、更稳定、更安全的Hadoop工作。
