一、HDFS的局限性：
1.不支持实时处理的任务需求。但Hbase满足实时处理需求。
2.无法高效存储大量的小文件，因为是以索引结构保存到内存当中去。
3.不支持多用户写入以及任意修改文件、只允许追加不允许修改。
二、HDFS的相关概念
1.块: 块存储，就是把一个物体分成很多块的意思。
2.采用块设计的好处：
支持大规模文件存储(把其切割然后存储)；方便元数据的管理(因为块的大小是固定的)；比较适合备份。
3.名称节点(主节点)和数据节点：
在整个HDFS文件系统当中，包含非常多的机器(也就是非常多的节点)，其中一个是主节点，其他节点是从节点。主节点是名称节点，名称节点是整个HDFS集群的管家，相当于数据目录，表面那些数据存储在哪里，提供元数据服务。而DataNode(数据节点)负责存储实际数据。
4.元数据：名称节点要存储元数据。其内容包含：
(1)文件是什么(文件名)
(2)文件被分成多少块
(3)每个块和文件是怎么映射的
(4)每个块被存储在哪个服务器上面
5.数据节点：（负责数据的存和取）
(1)存储实际的数据。
(2)数据被保存到本数据节点本地的Linux文件系统当中。
6.名称节点：
块到底具体存储在哪个节点地信息不是由FsImage保存的，而是单独在内存中某个区域单独维护的，是通过名称节点和数据节点不断地交互沟通连接来实时地维护这些信息、保存在内存当中。
名称节点包含FsImage、EditLog两个核心数据结构。
(1)FsImage:保存系统文件树以及文件树中所有的文件和文件夹的元数据。
(2)EditLog：记录对数据进行的诸如创建、删除、重命名等操作，相当于日志。
(3)名称节点的两大数据结构处理流程：
shell命令启动系统。然后把FsImage文件从底层磁盘加载到内存当中，名称节点的所有元数据的信息都是保存在内存当中，每次启动时首先把底层FsImage里面的内容全部加载到内存里。当对FsImage进行修改之后，就会把修改的操作写到EditLog里面去，然后把FsImage和EditLog合并之后得到最新的元数据，此时名称节点会把新版的FsImage保留下来、把旧版的删掉，然后创建生成一个空的EdiLog文件。此时，所有数据结构信息都保存在FsImage中，EditLog会不断的清空和根据往后地操作不断地保存修改信息。
EditLog会不断增大！后面会影响整个系统地性能！
(4). 如何解决EditLog不断增大影响系统性能地问题？
解决方法：第二名称节点(Secondary NameNode)，不仅可以解决EditLog增大占用空间影响性能地问题(对E ditLog的处理)，还起到了冷备份的作用(名称节点的冷备份、因为名称节点可能会出现问题)。第二名称节点处理机制：
下图左边是主名称节点，右边是第二名称节点。
EditLog在整个运行期间会不断增大，而第二名称节点会定期的和名称节点进行通信，在某个阶段会请求名称节点停止使用EditLog文件(即不再往EditLog里面写了)，名称节点收到请求后就停止写入EditLog文件，会生成一个新的edits.new文件(相当于生成新的EditLog文件)，然后把新到达的更新全部写到edits.new文件里面去，把旧版的EditLog放在一边，让第二名称节点以http get的方式把旧版的EditLog和FsLmage下载到第二名称节点的本地，下载到第二名称节点的本地之后把这两个做合并操作得到一个新的FsImage，然后再发送这个合并出来的文件给名称节点，之后名称节点将得到比较大的FsImage，然后名称节点就把edits.new更改为Edit(EditLog)。所以就解决了EditLog在整个运行期间会不断增大影响性能的问题。