网站收录了被人为删了怎么办,英文网站怎么切换中文,wordpress 不用插件代码高亮,扬州大学第四届网站建设评比Hadoop 主要由HDFS和MapReduce 引擎两部分组成。最底部是HDFS#xff0c;它存储Hadoop 集群中所有存储节点上的文件。HDFS 的上一层是MapReduce 引擎#xff0c;该引擎由JobTrackers 和TaskTrackers组成。一、HDFS基本概念1、数据块HDFS默认的最基本的存储单位是64M的数据块它存储Hadoop 集群中所有存储节点上的文件。HDFS 的上一层是MapReduce 引擎该引擎由JobTrackers 和TaskTrackers组成。一、HDFS基本概念1、数据块HDFS默认的最基本的存储单位是64M的数据块这个数据块可以理解和一般的文件里面的分块是一样的不同于普通文件系统的是HDFS中如果一个文件小于一个数据块的大小那么并不占用整个数据块存储空间。2、元数据节点和数据节点元数据节点是用来管理文件系统的命名空间它将所有的文件和文件夹的元数据保存在一个文件系统树中。数据节点是用来存储数据文件的。从元数据节点(secondarynamenode)不是我们所想象的元数据节点的备用节点其实它主要的功能是主要功能就是周期性将元数据节点的命名空间镜像文件和修改日志合并以防日志文件过大。3、HDFS中的数据流读文件客户端(client)用FileSystem的open()函数打开文件DistributedFileSystem用RPC调用元数据节点得到文件的数据块信息。对于每一个数据块元数据节点返回保存数据块的数据节点的地址。DistributedFileSystem返回FSDataInputStream给客户端用来读取数据。客户端调用stream的read()函数开始读取数据。DFSInputStream连接保存此文件第一个数据块的最近的数据节点。Data从数据节点读到客户端(client)当此数据块读取完毕时DFSInputStream关闭和此数据节点的连接然后连接此文件下一个数据块的最近的数据节点。当客户端读取完毕数据的时候调用FSDataInputStream的close函数。整个过程如图所示写文件客户端调用create()来创建文件DistributedFileSystem用RPC调用元数据节点在文件系统的命名空间中创建一个新的文件。元数据节点首先确定文件原来不存在并且客户端有创建文件的权限然后创建新文件。DistributedFileSystem返回DFSOutputStream客户端用于写数据。客户端开始写入数据DFSOutputStream将数据分成块写入data queue。Data queue由Data Streamer读取并通知元数据节点分配数据节点用来存储数据块(每块默认复制3块)。分配的数据节点放在一个pipeline里。Data Streamer将数据块写入pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。DFSOutputStream为发出去的数据块保存了ack queue等待pipeline中的数据节点告知数据已经写入成功。如果数据节点在写入的过程中失败关闭pipeline将ack queue中的数据块放入data queue的开始。整个过程如图所示二、HDFS的优缺点2.1 HDFS的优点1)处理超大文件这里的超大文件通常是指百MB、设置数百TB大小的文件。目前在实际应用中HDFS已经能用来存储管理PB级的数据了。2)流式的访问数据HDFS的设计建立在更多地响应一次写入、多次读写任务的基础上。这意味着一个数据集一旦由数据源生成就会被复制分发到不同的存储节点中然后响应各种各样的数据分析任务请求。在多数情况下分析任务都会涉及数据集中的大部分数据也就是说对HDFS来说请求读取整个数据集要比读取一条记录更加高效。3)运行于廉价的商用机器集群上Hadoop设计对硬件需求比较低只须运行在低廉的商用硬件集群上而无需昂贵的高可用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。这就要求设计HDFS时要充分考虑数据的可靠性安全性及高可用性。2.2 HDFS的缺点1)不适合低延迟数据访问如果要处理一些用户要求时间比较短的低延迟应用请求则HDFS不适合。HDFS是为了处理大型数据集分析任务的主要是为达到高的数据吞吐量而设计的这就可能要求以高延迟作为代价。改进策略对于那些有低延时要求的应用程序HBase是一个更好的选择。通过上层数据管理项目来尽可能地弥补这个不足。在性能上有了很大的提升它的口号就是goes real time。使用缓存或多master设计可以降低client的数据请求压力以减少延时。还有就是对HDFS系统内部的修改这就得权衡大吞吐量与低延时了HDFS不是万能的银弹。2)无法高效存储大量小文件因为Namenode把文件系统的元数据放置在内存中所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说每一个文件、文件夹和Block需要占据150字节左右的空间所以如果你有100万个文件每一个占据一个Block你就至少需要300MB内存。当前来说数百万的文件还是可行的当扩展到数十亿时对于当前的硬件水平来说就没法实现了。还有一个问题就是因为Map task的数量是由splits来决定的所以用MR处理大量的小文件时就会产生过多的Maptask线程管理开销将会增加作业时间。举个例子处理10000M的文件若每个split为1M那就会有10000个Maptasks会有很大的线程开销若每个split为100M则只有100个Maptasks每个Maptask将会有更多的事情做而线程的管理开销也将减小很多。改进策略要想让HDFS能处理好小文件有不少方法。利用SequenceFile、MapFile、Har等方式归档小文件这个方法的原理就是把小文件归档起来管理HBase就是基于此的。对于这种方法如果想找回原来的小文件内容那就必须得知道与归档文件的映射关系。横向扩展一个Hadoop集群能管理的小文件有限那就把几个Hadoop集群拖在一个虚拟服务器后面形成一个大的Hadoop集群。google也是这么干过的。多Master设计这个作用显而易见了。正在研发中的GFS II也要改为分布式多Master设计还支持Master的Failover而且Block大小改为1M有意要调优处理小文件啊。附带个Alibaba DFS的设计也是多Master设计它把Metadata的映射存储和管理分开了由多个Metadata存储节点和一个查询Master节点组成。3)不支持多用户写入及任意修改文件在HDFS的一个文件中只有一个写入者而且写操作只能在文件末尾完成即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作以及在文件任意位置进行修改。
