myeclipse配置hadoop服务器,如何配置,请教,我使用的是hadoop-0.20.2.插件

myeclipse配置hadoop服务器,如何配置,请教,我使用的是hadoop-0.20.2.插件,第1张

配置hadoop服务器?我是用eclipse对HADOOP程序进行开发,可以直接hadoop/contrib/eclipse-plugin/hadoop-0202-eclipse-pluginjar拷贝到eclipse的plugins目录下就可以了。

Hadoop分布式文件系统(HDFS)是一种运行在通用硬件上的分布式文件系统。它与传统的分布式文件系统有很多相似之处,但是也有显著的不同。HDFS是高容错的,可以部署在低成本硬件上。HDFS提供了对应用数据的高吞吐量访问,适用于具有大数据集的应用。HDFS为了流数据访问放松了一些POSIX的限制。

HDFS是主从结构。一个HDFS集群由一个NameNode和一组DataNode组成。NameNode是主服务器,负责管理文件系统命名空间以及客户端对文件的访问。DataNode通常每个节点一个,负责管理存储。HDFS对外暴露了一个文件系统命名空间并允许用户数据作为文件存储。在内部实现上,一个文件会被分割成一个或多个block,这些block存储在一组DataNode上。NameNode负责执行文件系统命名空间 *** 作,例如打开,关闭,重命名文件和目录等。此外NameNode还维护着block和DataNode之间的映射关系。DataNode负责处理来自客户端的读写请求,并根据NameNode的指令创建,删除,备份block。

NameNode和DataNode都是运行在通用机器上的软件。这些机器通常使用Linux系统。HDFS使用Java构建,任何支持Java的机器都可以运行NameNode和DataNode。一种典型的集群部署方式是使用一台机器运行NameNode,其它机器每台运行一个DataNode实例。

HDFS使用传统的分层文件结构。用户可以创建目录并在目录下存储文件。文件系统命名空间结构与传统文件系统类似,用户可以创建,删除文件,将文件从一个目录移动到另一个目录,重命名文件。HDFS支持用户限额和访问权限。

NameNode维护整个文件系统命名空间,它会记录任何对命名空间的修改。应用程序可以指定HDFS中文件的备份数量。文件的拷贝数称为该文件的备份因子。这个信息也存储在NameNode中。

HDFS可以跨机器存储海量文件。每个文件分成一个block的序列存储。为了容错,文件的block会被备份。每个文件的block大小和备份因子都是可配置的。

文件中所有block的大小是相等的(除了最后一个),而对append和hsync提供可变长block支持后,用户可以直接创建一个新block,不必继续填充最后一个block。

应用程序可以指定文件的备份数。备份因子可在文件创建时指定,也可以稍后修改。HDFS的文件都是一次写入的(除了append和truncate),并且任何时候都只有一个写入器。

NameNode决定如何备份block。它周期性的接收来自DataNode的心跳检测和block报表。收到心跳检测说明DataNode工作正常,block报表包含该DataNode上的所有block。

备份文件的位置对HDFS的可用性和性能至关重要。对备份的优化让HDFS从众多分布式系统中脱颖而出。这个工作需要大量的优化和经验。机架感知备份放置策略的目的是提高数据的可靠性,可用性和网络带宽利用率。目前的备份放置策略实现是这个方向上的第一步。短期目标是在生产环境上对其进行验证,更多的了解它的行为,为测试和研究更复杂的策略奠定基础。

大型HDFS集群的机器通常隶属于多个机架。两个不同机架上的节点进行通信必须通过交换机。一般来说,同一机架机器之间的网络带宽要优于不同机架机器间的网络带宽。

NameNode通过Hadoop Rack Awareness进程确定每个DataNode所属的机架ID。一个简单但是并非最优的策略是将备份放置在独立的机架上。这种策略可以避免机架故障时丢失数据,读数据时也可以利用多个机架的网络带宽。这种策略在集群中平均分配备份文件,这样组件发生故障时可以平衡负载。但是这种策略会增加写入成本,因为数据需要跨机架传输。

最常见的情况,备份因子是3。HDFS的放置策略是:如果写入器位于DataNode上,则将副本放置在本地计算机,否则随机选择一个DataNode,另一个副本放置在另一个远程机架的节点上,最后一个副本放在同一个远程机架的另一个节点上。这种策略减少了机架间的写入流量,从而提高写性能。机架发生故障的几率远小于节点故障几率。这种策略并不影响数据可靠性和可用性,但是它确实减少了读 *** 作时的聚合网络带宽,因为一个block被放置到两个机架上而不是三个。这种策略的文件副本并不是均匀的分布在所有机架上,副本的三分之一位于一个节点,剩下的三分之二位于另一个机架上。这种策略可以提高写性能,而不会影响数据可靠性和读性能。

如果备份因子大于3,那么第四个和之后的副本随机放置,同时要保证副本数量不能超过机架的上限(公式: (replicas - 1) / racks + 2 )。

由于DataNode不能放置同一个block的多个副本,所以最大备份因子就是最大DataNode数。

在提供了存储类型和存储策略的支持之后,除了机架感知,NameNode放置副本时也会考虑放置策略。NameNode首先根据机架感知选择节点,然后根据备份文件的放置策略检查该节点的存储类型,如果该候选节点没有要求的存储类型,NameNode会查找下一个节点。如果第一轮没有找到足够的节点放置备份,NameNode会使用后备存储类型开始第二轮查找。

目前,副本放置策略依然在开发中。

为了减少带宽消耗和读延迟,HDFS会尝试找寻一个离读请求最近的副本。如果读请求节点所在机架有这样一个副本,HDFS就优先使用这个副本。如果HDFS集群跨越多个数据中心,则本地数据中心的副本优先于远程副本。

启动HDFS时,NameNode会进入一种称为安全模式的特殊状态。安全模式下数据block无法备份。NameNode会从DataNode接收心跳检测和block报表。block报表包含该DataNode下所有数据block的列表信息。每个block都有一个指定的最小备份数。只有block的最小备份数登记到NameNode中后,block才可以备份。备份登记结束后,NameNode退出安全模式。这是如果还有block不满足最小备份数的条件,NameNode才开始备份这些block。

HDFS命名空间由NameNode保存,NameNode使用一个称为EditLog的事务日志记录对文件系统元数据的所有更改。例如,创建一个新文件会在EditLog中插入一条对应记录,同样的,修改文件备份因子也会插入一条记录。NameNode使用本地文件存储EditLog。整个文件系统命名空间,包括文件与block之间的映射关系,文件系统数据等,都保存在FsImage文件中。

NameNode在内存中维护文件系统命名空间和文件block映射关系的镜像。当NameNode启动,或者某个阈值触发了检查点时,NameNode从磁盘上读取FsImage和EditLog的内容,将所有EditLog中的事务 *** 作应用到FsImage的内存镜像中,然后在磁盘上生成一个全新的FsImage。之后可以截断EditLog,因为所有事务都已持久化到FsImage。这个过程称为检查点。检查点的目的是通过获取文件系统元数据的快照并保存到FsImage来保证HDFS文件系统元数据的一致性。读取FsImage可能很快,但是持续编辑FsImage就不同了。因此我们将 *** 作记录到EditLog中,而不是直接修改FsImage。在检查点期间,所有EditLog *** 作应用到FsImage。检查点可以按周期触发( dfsnamenodecheckpointperiod ),也可以按事务数触发( dfsnamenodecheckpointtxns )。如果两个属性都设置了,第一个满足的阈值会触发检查点。

DataNode在本地文件系统中存储HDFS数据。DataNode对HDFS文件一无所知,它以block为单位存储HDFS数据。DataNode不会在同一个目录下保存所有文件。相反,它使用启发式方法来确定每个目录的最佳文件数,并适时创建子目录。在同一个目录下创建所有文件并不是最佳选择,因为本地文件系统可能无法支持一个目录下的大量文件。DataNode启动时,它会扫描整个本地文件系统,生成一个本地文件与数据block之间的关系列表,将其发送给NameNode,这个列表称为block报告。

所有HDFS通信协议都构建在TCP/IP协议之上。客户端通过TCP端口与NameNode建立连接,它使用ClientProtocol与NameNode交互。DataNode使用DataProtocol与NameNode交互。一个RPC抽象封装了客户端协议和DataNode协议。NameNode从不初始化任何RPC,它只是响应来自的客户端和DataNode的请求。

HDFS的主要目标是即使出现故障也可以可靠的存储数据。三种常见的故障分别是:NameNode故障,DataNode故障和网络分区。

DataNode周期性的发送心跳检测给NameNode。网络分区可能导致某些DataNode无法连接NameNode。NameNode无法收到DataNode的心跳检测后,它会把这样的DataNode标记为dead,并不在发送新的I/O请求。注册到死亡DataNode上的数据对HDFS来说不再可用,也会导致某些block的备份数少于文件指定的最小备份数。NameNode持续追踪block的备份情况并在必要时初始化备份 *** 作。重备份的原因是多种多样的:DataNode不可用,某个备份文件损坏,DataNode磁盘故障,或者文件的备份因子增大。

为了避免DataNode状态抖动引起的备份风暴,标记DataNode死亡的超时时间设置的很长(默认超过10分钟)。用户可以设置一个更短的时间将DataNode标记为陈旧(stale),这样可以避免对性能敏感的工作负载的陈旧DataNode的读写 *** 作。

HDFS架构与数据重平衡scheme兼容。scheme可以在DataNode的磁盘空间低于某个阈值时将数据移动到另一个DataNode上。如果对某个文件的需求特别高,scheme还可以动态创建额外的副本并平衡到整个集群中。这些数据平衡scheme还未实现。

从DataNode中读取的block可能是损坏的。损坏的原因有多种:磁盘故障,网络故障,或者软件问题。HDFS客户端会对文件内容进行校验和检查。当客户端创建一个HDFS文件时,它会计算出文件所有block的校验和并保存在同一个命名空间的一个独立的隐藏文件中。当客户单检索文件时还要检查对应校验和文件中的值。如果校验和不匹配,客户端会尝试该block其它节点上的副本。

FsImage和EditLog是HDFS的核心数据结构。如果它们发生损坏,HDFS就无法使用了。因此,可以通过配置让NameNode维护多个FsImage和EditLog的拷贝。对两个文件的修改会同步到所有拷贝中。这种同步 *** 作会降低NameNode的TPS,但是这种牺牲是可接受的,因为HDFS是数据密集,不是元数据密集。NameNode重启时,它会选择最一致的FsImage和EditLog使用。

另一种减低故障的办法是使用HA。

(略)

HDFS的目的是支持大型文件。HDFS支持一次写入多次读取。一个典型的block大小是128MB。因此,HDFS文件按照128MB的大小分割,每个block可能分布在不同的节点上。

客户端向HDFS文件写入数据时,如果备份因子是三,NameNode使用备份目标选择算法检索出一组DataNode。这个列表是可以存储副本的DataNode。客户端先向第一个DataNode写入数据,DataNode接收数据并将数据传输到列表中的第二个DataNode。第二个DataNode开始接收数据并继续传输数据到第三个DataNode。这样,数据通过管道从一个DataNode传输到下一个。

(略)

如果开启了trash配置,从FS shell中删除的文件并不会立刻从HDFS中删除,HDFS将它移动到一个trash目录(每个用户都有自己的trash目录, /user/<username>/Trash )。只要文件还在trash目录中就可以快速恢复。

最近删除的文件移动到 /user/<username>/Trash/Current 目录中,每隔一段时间,HDFS会为这些文件创建检查点文件( /user/<username>/Trash/<date> )并删除旧检查点文件。

如果trash中的文件过期了,NameNode将这些文件从命名空间中删除。与文件关联的block被释放。删除文件和空间释放之间可能会有延迟。

下面是一个例子,首先创建两个文件:

然后删除test1,该文件会被移到Trash目录:

接着跳过Trash删除test2:

现在可以查看Trash目录:

文件的备份因子降低后,NameNode选择可以删除的副本,在下次心跳检测时把信息发送给DataNode,之后DataNode删除block并释放空间。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/10885417.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-12
下一篇 2023-05-12

发表评论

登录后才能评论

评论列表(0条)

保存