hdfs存储空间

‘壹’ hadoop中存储文件系统hdfs的冗余机制是怎么进行的有什么特点

可以只用一行代码来运行MapRece作业：JobClient.runJon(conf)，Job作业运行时参与的四个实体：

1.JobClient 写代码，配置作业，提交作业。

2.JobTracker:初始化作业，分配作业，协调作业运行。这是一个java程序，主类是JobTracker。

3.TaskTracker：运行作业划分后的任务，即分配数据分配上执行Map或Rece任务。

4.HDFS：保存作业数据、配置信息等，保存作业结果。

Map/Rece 作业总体执行流程：

代码编写 ----> 作业配置 ---->作业提交---->Map任务分配和执行---->处理中间结果----> Rece任务分配与执行----> 输出结果

而对于每个作业的执行，又包含：

输入准备---->任务执行---->输出结果

作业提交JobClient：

JobClient的runJob方法产生一个Jobclient实例并调用其submitJob方法，然后runJob开始循环吗，并在循环中调用getTaskCompetionEvents方法，获得TaskCompletionEvent实例，每秒轮询作业进度（后面有介绍进度和状态更新），把进度写到控制台，作业完成后显示作业计数器，若失败，则把错误记录到控制台。

submitJob方法作业提交的过程：

1.向JobTracker请求一个新的JobId。

2.检查作业相关路径，如果路径不正确就会返回错误。

3.计算作业输入分片及其划分信息。

4.将作业运行需要的资源（jar文件、配置文件等）复制到Shared HDFS，并

复制多个副本（参数控制，默认值为10）供tasktracker访问，也会将计算的分片复制到HDFS。

5.调用JobTracker对象的submitJob()方法来真正提交作业，告诉JobTracker作业准备执行。

作业的初始化JobTracker：

JobTracker收到submitJob方法调用后，会把调用放入到一个内部队列，由作业调度器（Job scheler）进行调度并对其初始化。Job初始化即创建一个作业对象。

当作业被调度后，JobTracker会创建一个代表这个作业的JobInProgress对象，并将任务和记录信息封装在这个对象中，以便跟踪任务状态和进程。

初始化过程就是JobInProgress对象的initTasks方法进行初始化的。

初始化步骤：

1.从HDFS中读取作业对应的job.split信息，为后面的初始化做好准备。

2.创建并初始化map和rece任务。根据数据分片信息中的个数确定map task的个数，然后为每个map task生成一个TaskInProgress对象来处理数据分片，先将其放入nonRunningMapCache,以便JobTracker分配任务的时候使用。接下来根据JobConf中的mapred.rece.tasks属性利用setNumReceTasks()方法设置rece task的数量，然后同map task创建方式。

3.最后就是创建两个初始化task，进行map和rece的初始化。

任务的分配JobTracker：

消息传递HeartBeat： tasktracker运行一个简单循环定期发送心跳（heartbeat）给JobTracker。由心跳告知JobTracker自己是否存活，同时作为消息通道传递其它信息（请求新task）。作为心跳的一部分，tasktracker会指明自己是否已准备好运行新的任务，如果是，jobtracker会分配它一个任务。

分配任务所属于的作业：在Jobtracker分配任务前需先确定任务所在的作业。后面会介绍到各种作业调度算法，默认是一个FIFO的作业调度。

分配Map和Rece任务：tasktracker有固定数量的任务槽,一个tasktracker可以同时运行多个Map和Rece任务，但其准确的数量由tasktracker的核的数量和内存大小决定。默认调度器会先填满Map任务槽，再填Rece任务槽。jobtracker会选择距离离分片文件最近的tasktracker，最理想情况下，任务是数据本地化（data-local）的,当然也可以是机架本地化（rack-local），如果不是本地化的，那么他们就需要从其他机架上检索数据。Rece任务分配很简单，jobtracker会简单的从待运行的rece任务列表中选取下一个来执行，不用考虑数据本地化。

任务的执行TaskTracker：

TaskTracker收到新任务后，就要在本地运行任务了，运行任务的第一步就是通过localizedJob将任务本地化所需要的注入配置、数据、程序等信息进行本地化。

1.本地化数据：从共享文件系统将job.split 、job.jar (在分布式缓存中)复制本地，将job配置信息写入job.xml。

2.新建本地工作目录：tasktracker会加压job.jar文件到本工作目录。

3.调用launchTaskForJob方法发布任务（其中会新建TaskRunner实例运行任务），如果是Map任务就启用MapTaskRunner，对于Rece就是ReceTaskRunner。

在这之后，TaskRunner会启用一个新的JVM来运行每个Map/Rece任务，防止程序原因而导致tasktracker崩溃，但不同任务间重用JVM还是可以的，后续会讲到任务JVM重用。

对于单个Map，任务执行的简单流程是：

1.分配任务执行参数

2.在Child临时文件中添加map任务信息（Child是运行Map和Rece任务的主进程）

3.配置log文件夹，配置map任务的通信和输出参数

4.读取input split，生成RecordReader读取数据

5.为Map生成MapRunnable,依次从RecordReader中接收数据，并调用Map函数进行处理。

6.最后将map函数的输出调用collect收集到MapOutputBuffer（参数控制其大小）中。

Streaming和Pipes:

Streaming和Pipes都运行特殊的Map和Rece任务，目的是运行用户提供的可执行程序并与之通信。

Streaming:使用标准输入输出Streaming与进程进行通信。

Pipes:用来监听套接字，会发送一个端口号给C++程序，两者便可建立链接。

进度和状态更新：

一个作业和它的任务都有状态（status），其中包括：运行成功失败状态、Map/Rece进度、作业计数器值、状态消息。

状态消息与客户端的通信：

1.对于Map任务Progress的追踪：progress是已经处理完的输入所占的比例。

2.对于Rece：稍复杂，rece任务分三个阶段（每个阶段占1/3），复制、排序和Rece处理，若rece已执行一半的输入的话，那么任务进度便是1/3+1/3+1/6=5/6。

3.任务计数器：任务有一组计数器，负责对任务运行各个事件进行计数。

4.任务进度报告：如果任务报告了进度，便会设置一个标记以表明状态将被发送到tasktracker。有一个独立线程每隔三秒检查一次此标记，如果已设置，则告知tasktracker当前状态。

5.tasktracker进度报告：tasktracker会每隔5秒（这个心跳是由集群大小决定，集群越大时间会越长）发送heartbeat到jobtracker，并且tasktracker运行的所有状态都会在调用中被发送到jobtracker。

6.jobtracker合并各任务报告：产生一个表明所有运行作业机器所含任务状态的全局视图。

前面提到的JobClient就是通过每秒查询JobTracker来接收最新状态，而且客户端JobClient的getJob方法可以得到一个RunningJob的实例，其包含了作业的所以状态信息。

作业的完成：

当jobtracker收到作业最后一个任务已完成的通知后，便把作业状态设置成成功。JobClient查询状态时，便知道任务已成功完成，于是JobClient打印一条消息告知用户，然后从runJob方法返回。

如果jobtracker有相应设置，也会发送一个Http作业通知给客户端，希望收到回调指令的客户端可以通过job.end.notification.url属性来进行设置。

jobtracker情况作业的工作状态，指示tasktracker也清空作业的工作状态，如删除中间输出。

失败

实际情况下，用户的代码存在软件错误进程会崩溃，机器也会产生故障，但Hadoop能很好的应对这些故障并完成作业。

1.任务失败

子任务异常：如Map/Rece任务中的用户代码抛出异常，子任务JVM进程会在退出前向父进程tasktracker发送错误报告，错误被记录用户日志。tasktracker会将此次task attempt标记为tailed，并释放这个任务槽运行另外一个任务。

子进程JVM突然退出：可能由于JVM bug导致用户代码造成的某些特殊原因导致JVM退出，这种情况下，tasktracker会注意到进程已经退出，并将此次尝试标记为failed。

任务挂起：一旦tasktracker注意一段时间没有收到进度更新，便会将任务标记为failed，JVM子进程将被自动杀死。任务失败间隔时间通常为10分钟，可以以作业或者集群为基础设置过期时间，参数为mapred.task.timeout。注意：如果参数值设置为0，则挂起的任务永远不会释放掉它的任务槽，随着时间的推移会降低整个集群的效率。

任务失败尝试次数：jobtracker得知一个tasktracker失败后，它会重新调度该任务执行，当然，jobtracker会尝试避免重新调度失败过的tasktracker任务。如果一个任务尝试次数超过4次，它将不再被重试。这个值是可以设置的，对于Map任务，参数是mapred.map.max.attempts,对于rece任务，则由mapred.rece.max.attempts属性控制。如果次数超过限制，整个作业都会失败。当然，有时我们不希望少数几个任务失败就终止运行的整个作业，因为即使有些任务失败，作业的一些结果可能还是有用的，这种情况下，可以为作业设置在不触发作业失败情况下的允许任务失败的最大百分比，Map任务和Rece任务可以独立控制，参数为mapred.max.map.failures.percent 和mapred.max.rece.failures.percent。

任务尝试中止（kill）：任务终止和任务失败不同，task attempt可以中止是因为他是一个推测副本或因为它所处的tasktracker失败，导致jobtracker将它上面的所有task attempt标记为killed。被终止的task attempt不会被计入任务运行尝试次数，因为尝试中止并不是任务的错。

2.tasktracker失败

tasktracker由于崩溃或者运行过慢而失败，他将停止向jobtracker发送心跳（或很少发送心跳）。jobtracker注意已停止发送心跳的tasktracker（过期时间由参数mapred.tasktracker.expiry.interval设置，单位毫秒），并将它从等待调度的tasktracker池中移除。如果是未完成的作业，jobtracker会安排次tasktracker上已经运行成功的Map任务重新运行，因为此时rece任务已无法访问（中间输出存放在失败的tasktracker的本地文件系统上）。

即使tasktracker没有失败，也有可能被jobtracker列入黑名单。如果tasktracker上面的失败任务数量远远高于集群的平均失败任务次数，他就会被列入黑名单，被列入黑名单的tasktracker可以通过重启从jobtracker黑名单中移除。

3.jobtracker失败

老版本的JobTracker失败属于单点故障，这种情况下作业注定失败。

作业调度：

早期作业调度FIFO：按作业提交顺序先进先出。可以设置优先级，通过设置mapred.job.priority属性或者JobClient的setJobPriority()方法制定优先级（优先级别：VERY_HIGH,HIGH,NORMAL,LOW,VERY_LOW）。注意FIFO调度算法不支持抢占（preemption）,所以高优先级作业仍然会被那些已经开始的长时间运行的低优先级作业所阻塞。

Fair Scheler：目标是让每个用户公平地共享集群能力。当集群存在很多作业时，空闲的任务槽会以”让每个用户共享集群“的方式进行分配。默认每个用户都有自己的作业池。FairScheler支持抢占，所以，如果一个池在特定的一段时间未得到公平地资源共享，它会终止池中得到过多的资源任务，以便把任务槽让给资源不足的池。FairScheler是一个后续模块，使用它需要将其jar文件放在Hadoop的类路径下。可以通过参数map.red.jobtracker.taskScheler属性配置（值为org.apache.hadoop.mapred.FairScheler）

Capacity Scheler：

集群由很多队列组成，每个队列都有一个分配能力，这一点与FairScheler类似，只不过在每个队列内部，作业根据FIFO方式进行调度。本质上说，Capacity Scheler允许用户或组织为每个用户模拟一个独立使用FIFO的集群。

shuffle和排序：

MapRece确保每个Recer的输入都是按键排序的。系统执行排序的过程-将map输出作为输入传给recer的过程称为shuffle。shuffle属于不断被优化和改进的代码库的一部分，从许多方面来看，shuffle是MapRece的心脏。

整个shuffle的流程应该是这样：

map结果划分partition 排序sort 分割spill 合并同一划分 合并同一划分 合并结果排序 rece处理 输出

Map端：

写入缓冲区：Map函数的输出，是由collector处理的，它并不是简单的将结果写到磁盘。它利用缓冲的方式写到内存，并处于效率的考虑进行预排序。每个map都有一个环形的内存缓冲区，用于任务输出，默认缓冲区大小为100MB（由参数io.sort.mb调整），一旦缓冲区内容达到阈值（默认0.8），后台进程边开始把内容写到磁盘（spill），在写磁盘过程中，map输出继续被写到缓冲区，但如果缓冲区被填满，map会阻塞知道写磁盘过程完成。写磁盘将按照轮询方式写到mapred.local.dir属性制定的作业特定子目录中。

写出缓冲区：collect将缓冲区的内容写出时，会调用sortAndSpill函数，这个函数作用主要是创建spill文件，按照key值对数据进行排序，按照划分将数据写入文件，如果配置了combiner类，会先调用combineAndSpill函数再写文件。sortAndSpill每被调用一次，就会写一个spill文件。

合并所有Map的spill文件：TaskTracker会在每个map任务结束后对所有map产生的spill文件进行merge，merge规则是根据分区将各个spill文件中数据同一分区中的数据合并在一起，并写入到一个已分区且排序的map输出文件中。待唯一的已分区且已排序的map输出文件写入最后一条记录后，map端的shuffle阶段就结束了。

在写磁盘前，线程首先根据数据最终要传递到的recer把数据划分成响应的分区（partition），在每个分区中，后台线程按键进行内排序，如果有一个combiner,它会在排序后的输出上运行。

内存达到溢出写的阈值时，就会新建一个溢出写文件，因为map任务完成其最后一个输出记录之后，会有几个溢出写文件。在任务完成前，溢出写文件会被合并成一个已分区且已排序的输出文件。配置属性io.sort.facor控制一次最多能合并多少流，默认值是10。

如果已经指定combiner,并且写次数至少为3（通过min.mum.spills.for.combine设置）时，则combiner就会在输出文件写到磁盘之前运行。运行combiner的意义在于使map输出更紧凑，舍得写到本地磁盘和传给recer的数据更少。

写磁盘时压缩：写磁盘时压缩会让写的速度更快，节约磁盘空间，并且减少传给recer的数据量。默认情况下，输出是不压缩的，但可以通过设置mapred.compress.map.output值为true，就可以启用压缩。使用的压缩库是由mapred.map.output.compression.codec制定。

recer获得文件分区的工作线程：recer通过http方式得到输出文件的分区，用于文件分区的工作线程数量由tracker.http.threads属性指定，此设置针对的是每个tasktracker，而不是每个map任务槽。默认值为40，在大型集群上此值可以根据需要而增加。

Rece端：

复制阶段：rece会定期向JobTracker获取map的输出位置，一旦拿到输出位置，rece就会从对应的TaskTracker上复制map输出到本地（如果map输出很小，则会被复制到TaskTracker节点的内存中，否则会被让如磁盘），而不会等到所有map任务结束（当然这个也有参数控制）。

合并阶段：从各个TaskTracker上复制的map输出文件（无论在磁盘还是内存）进行整合，并维持数据原来的顺序。

Rece阶段：从合并的文件中顺序拿出一条数据进行rece函数处理，然后将结果输出到本地HDFS。

Map的输出文件位于运行map任务的tasktracker的本地磁盘，现在，tasktracker要为分区文件运行rece任务。每个任务完成时间可能不同，但是只要有一个任务完成，rece任务就开始复制其输出，这就是rece任务的复制阶段（ phase）。rece任务有少量复制线程，因此能够并行取得map输出。默认值是5个线程，可以通过mapred.rece.parallel.copies属性设置。

Recer如何得知从哪个tasktracker获得map输出：map任务完成后会通知其父tasktracker状态已更新，tasktracker进而通知（通过heart beat）jobtracker。因此，JobTracker就知道map输出和tasktracker之间的映射关系，recer中的一个线程定期询问jobtracker以便获知map输出位置。由于recer有可能失败，因此tasktracker并没有在第一个recer检索到map输出时就立即从磁盘上删除它们，相反他会等待jobtracker告示它可以删除map输出时才删除，这是作业完成后最后执行的。

如果map输出很小，则会被直接复制到rece tasktracker的内存缓冲区（大小由mapred.job.shuffle.input.buffer.percent控制，占堆空间的百分比），否则，map输出被复制到磁盘。一旦内存缓冲区达到阈值大小（由mapred.iob.shuffle.merge.percent）

或达到map输出阈值大小（mapred.inmem.threadhold），则合并后溢出写到磁盘中。

随着磁盘上副本增多，后台线程会将他们合并为更大的、排好序的文件。注意：为了合并，压缩的map输出必须在内存中被解压缩。

排序阶段：复制阶段完成后，rece任务会进入排序阶段，更确切的说是合并阶段，这个阶段将合并map输出，维持其顺序排列。合并是循环进行的，由合并因子决定每次合并的输出文件数量。但让有可能会产生中间文件。

rece阶段：在最后rece阶段，会直接把排序好的文件输入rece函数，不会对中间文件进行再合并，最后的合并即可来自内存，也可来自磁盘。此阶段的输出会直接写到文件系统，一般为hdfs。

细节：这里合并是并非平均合并，比如有40个文件，合并因子为10，我们并不是每趟合并10个，合并四趟。而是第一趟合并4个，后三趟合并10，在最后一趟中4个已合并的文件和余下6个未合并会直接并入rece。

‘贰’ hadoop存储容量，计算时需要多少容量

如果文件小于64MB，存储按该文件的块大小等于该文件的大小。
读取时是根据存在namenode上面的映射表来读取的。
按实际存储的大小来读取，不是从硬盘上面读取的，是从HDFS
上面读取的。
另外，在文件上传时，就会根据块的大小将各个块分布到各个
datanode节点上面的。如果文件已经上传，需要修改默认块的大小，
那么需要执行一条语句将HDFS上面的原有文件重新分块并存储。

‘叁’ Hbase与HDFS是个什么关系

他们的关系是：hbase是一个内存数据库，而hdfs是一个存储空间；是物品和房子的关系。

hdfs只是一个存储空间，他的完整名字是分布式文件系统。从名字可知他的作用了。
hbase是一个内存数据库，简单点说hbase把表啊什么的存在hdfs上。

‘肆’ HDFS 上每个数据节点最多能存多少，多大的数据

hadoop 的datanode上存储多少数据就是由该datanode的磁盘空间决定的，配置文件中dfs.data.dir参数指定了hdfs数据存放目录（多个目录由逗号分隔），设置好该参数后，这个datanode节点的最大存储空间就由设定目录的空间决定。hadoop各个datanode节点的数据量基本是一致的，可以通过balancer.sh来平衡各个节点的空间利用率。

‘伍’ HDFS由什么组成

大数据平台包含了采集层、存储层、计算层和应用层，是一个复杂的IT系统，需要学会Hadoop等分布式系统的开发技能。
1.1采集层：Sqoop可用来采集导入传统关系型数据库的数据、Flume对于日志型数据采集，另外使用Python一类的语言开发网络爬虫获取网络数据；
1.2储存层：分布式文件系统HDFS最为常用；采用了主从（Master/Slave）结构模型，一个HDFS集群是由一个NameNode和若干个DataNode组成的。其中NameNode作为主服务器，管理文件系统的命名空间和客户端对文件的访问操作；集群中的DataNode管理存储的数据。
1.3计算层：有不同的计算框架可以选择，常见的如MapRece、Spark等，一般来讲，如果能使用计算框架的“原生语言”，运算效率会最高（MapRece的原生支持Java，而Spark原生支持Scala）；
1.4应用层：包括结果数据的可视化、交互界面开发以及应用管理工具的开发等，更多的用到Java、Python等通用IT开发前端、后端的能力；

‘陆’ 什么是HDFS硬盘分布式存储

Namenode 是一个中心服务器，单一节点（简化系统的设计和实现），负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。
文件操作，NameNode 负责文件元数据的操作，DataNode负责处理文件内容的读写请求，跟文件内容相关的数据流不经过NameNode，只会询问它跟哪个DataNode联系，否则NameNode会成为系统的瓶颈。
副本存放在哪些DataNode上由 NameNode来控制，根据全局情况做出块放置决定，读取文件时NameNode尽量让用户先读取最近的副本，降低带块消耗和读取时延
Namenode 全权管理数据块的复制，它周期性地从集群中的每个Datanode接收心跳信号和块状态报告(Blockreport)。接收到心跳信号意味着该Datanode节点工作正常。块状态报告包含了一个该Datanode上所有数据块的列表。

NameNode支持对HDFS中的目录、文件和块做类似文件系统的创建、修改、删除、列表文件和目录等基本操作。 块存储管理，在整个HDFS集群中有且只有唯一一个处于active状态NameNode节点，该节点负责对这个命名空间（HDFS）进行管理。

1、Name启动的时候首先将fsimage（镜像）载入内存，并执行（replay）编辑日志editlog的的各项操作；
2、一旦在内存中建立文件系统元数据映射，则创建一个新的fsimage文件（这个过程不需SecondaryNameNode） 和一个空的editlog；
3、在安全模式下，各个datanode会向namenode发送块列表的最新情况；
4、此刻namenode运行在安全模式。即NameNode的文件系统对于客服端来说是只读的。(显示目录，显示文件内容等。写、删除、重命名都会失败)；
5、NameNode开始监听RPC和HTTP请求
解释RPC:RPC（Remote Procere Call Protocol）——远程过程通过协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议；
6、系统中数据块的位置并不是由namenode维护的，而是以块列表形式存储在datanode中；
7、在系统的正常操作期间，namenode会在内存中保留所有块信息的映射信息。
存储文件，文件被分成block存储在磁盘上，为保证数据安全，文件会有多个副本 namenode和client的指令进行存储或者检索block，并且周期性的向namenode节点报告它存了哪些文件的blo
文件切分成块（默认大小128M），以块为单位，每个块有多个副本存储在不同的机器上，副本数可在文件生成时指定（默认3）
NameNode 是主节点，存储文件的元数据如文件名，文件目录结构，文件属性（生成时间,副本数,文件权限），以及每个文件的块列表以及块所在的DataNode等等
DataNode 在本地文件系统存储文件块数据，以及块数据的校验和。
可以创建、删除、移动或重命名文件，当文件创建、写入和关闭之后不能修改文件内容。

NameNode启动流程
1、Name启动的时候首先将fsimage（镜像）载入内存，并执行（replay）编辑日志editlog的的各项操作；
2、一旦在内存中建立文件系统元数据映射，则创建一个新的fsimage文件（这个过程不需SecondaryNameNode） 和一个空的editlog；
3、在安全模式下，各个datanode会向namenode发送块列表的最新情况；
4、此刻namenode运行在安全模式。即NameNode的文件系统对于客服端来说是只读的。(显示目录，显示文件内容等。写、删除、重命名都会失败)；
5、NameNode开始监听RPC和HTTP请求
解释RPC:RPC（Remote Procere Call Protocol）——远程过程通过协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议；
6、系统中数据块的位置并不是由namenode维护的，而是以块列表形式存储在datanode中；
7、在系统的正常操作期间，namenode会在内存中保留所有块信息的映射信息。
HDFS的特点

优点：
1）处理超大文件
这里的超大文件通常是指百MB、数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据了。

2）流式的访问数据
HDFS的设计建立在更多地响应"一次写入、多次读取"任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。

3）运行于廉价的商用机器集群上
Hadoop设计对硬件需求比较低，只须运行在低廉的商用硬件集群上，而无需昂贵的高可用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。这就要求设计HDFS时要充分考虑数据的可靠性，安全性及高可用性。

缺点：
1）不适合低延迟数据访问
如果要处理一些用户要求时间比较短的低延迟应用请求，则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将会有更多的事情做，而线程的管理开销也将减小很多。

1280M 1个文件 10block*150字节 = 1500 字节 =1.5KB
1280M 12.8M 100个 100个block*150字节 = 15000字节 = 15KB

3）不支持多用户写入及任意修改文件
在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。

四、HDFS文件 读写流程
4.1 读文件流程

（1） 打开分布式文件
调用 分布式文件 DistributedFileSystem.open()方法。
（2） 从 NameNode 获得 DataNode 地址
DistributedFileSystem 使用 RPC 调用 NameNode， NameNode返回存有该副本的 DataNode 地址， DistributedFileSystem 返回一个输入流 FSDataInputStream对象， 该对象封存了输入流DFSInputStream。
（3） 连接到DataNode
调用 输入流 FSDataInputStream 的 read() 方法， 从而输入流DFSInputStream 连接 DataNodes。
（4） 读取DataNode
反复调用 read()方法， 从而将数据从 DataNode 传输到客户端。
（5） 读取另外的DataNode直到完成
到达块的末端时候， 输入流 DFSInputStream 关闭与DataNode 连接，寻找下一个 DataNode。
（6） 完成读取， 关闭连接
即调用输入流 FSDataInputStream.close() 。

4.2 写文件流程

（1） 发送创建文件请求： 调用分布式文件系统DistributedFileSystem.create()方法；
（2） NameNode中创建文件记录： 分布式文件系统DistributedFileSystem 发送 RPC 请求给namenode， namenode 检查权限后创建一条记录， 返回输出流 FSDataOutputStream， 封装了输出流 DFSOutputDtream；
（3） 客户端写入数据： 输出流 DFSOutputDtream 将数据分成一个个的数据包， 并写入内部队列。 DataStreamer 根据 DataNode 列表来要求 namenode 分配适合的新块来存储数据备份。一组DataNode 构成管线(管线的 DataNode 之间使用 Socket 流式通信)
（4） 使用管线传输数据： DataStreamer 将数据包流式传输到管线第一个DataNode， 第一个DataNode 再传到第二个DataNode ,直到完成。
（5） 确认队列： DataNode 收到数据后发送确认， 管线的DataNode所有的确认组成一个确认队列。 所有DataNode 都确认， 管线数据包删除。
（6） 关闭： 客户端对数据量调用close（） 方法。 将剩余所有数据写入DataNode管线， 并联系NameNode且发送文件写入完成信息之前等待确认。
（7） NameNode确认
（8） 故障处理： 若过程中发生故障， 则先关闭管线， 把队列中所有数据包添加回去队列， 确保数据包不漏。 为另一个正常DataNode的当前数据块指定一个新的标识， 并将该标识传送给NameNode, 一遍故障DataNode在恢复后删除上面的不完整数据块. 从管线中删除故障DataNode 并把余下的数据块写入余下正常的DataNode。 NameNode发现复本两不足时， 会在另一个节点创建一个新的复本

‘柒’ HbBase可以随机写入为什么还要依赖于HDFS

他们的关系是：hbase是一个内存数据库，而hdfs是一个存储空间；是物品和房子的关系。
hdfs只是一个存储空间，他的完整名字是分布式文件系统。从名字可知他的作用了。hbase是一个内存数据库，简单点说hbase把表啊什么的存在hdfs上。
所以即使HbBase可以随机，它还是要依赖于HDFS。
希望可以帮到您，感谢您的采纳！