再谈HDFS中的不同的节点
HDFS 是一个分布式文件系统，我们在前面也稍微讨论了一下集中式文件系统的一些弊端，我们还是从之前的那张HDFS架构图出发。
当我们开始关注线条所代表的数据流向后，其实上图就可以看作是一个HDFS数据读写的流程图了。在探讨具体的读写之前，我们先看看不同节点中存储的数据。
应用程序所在的Client端先过滤掉，因为这个端只是承载了与用户的交互作用，其实就是一台接口机。用户在这台机器写代码、调用API与HDFS进行交互。
我们前面说过，NameNode是集群的主控节点，管理HDFS的目录树和文件元数据信息。这样看来，NameNode中存储的就是一些元数据，包括：1）命名空间，也就是整个文件系统的目录结构，即目录树；2）数据块与文件名的映射表，这也很好理解，因为数据真正存储的地方其实位于DataNode，并且DataNode是以块为基本单位组织文件内容的，所以必须要有数据到具体数据块的映射信息，这些信息保存在了HDFS中；3）每个数据块的副本信息，前面提过，HDFS采用了多副本方式存储数据，因此我们必须要了解一个数据的副本信息。发现了没有，说白了，不存储具体的数据的NameNode中保存了具体数据在文件系统的位置。也是因此，我们说NameNode可以作为集群的主控节点。因为，既然所以的映射信息都在NameNode，那么所有关于数据的操作自然都必须经过NameNode。
DataNode是集群中存有具体数据的节点，那么不管什么操作，不和如何与NameNode交互，那么最后具体的实施必须交由DataNode来完成。这一点应该不难理解，因为具体数据是在DataNode上的。因此，DataNode是用来实际存储和管理数据的。
到这，我们会有一个总观，即，NameNode拥有至高的权利，可以下发命令，但是这些命令他不用自己去做（也是因为做不了，因为数据不在他这里），具体的实施都有DataNode这一个小兵来完成。
谈到这里，我们最起码明白了两点：（1）NameNode是HDFS中元数据的唯一拥有者；（2）DataNode是HDFS中具体数据的拥有者。但是，程序在访问文件的时候，Client和HDFS的数据交互并不会通过NameNode，而是让Client直接和DataNode交互数据。
我们不妨先假设，我们将HDFS设计为Client和HDFS的交互数据都必须流经NameNode，那么首先：Client和NameNode交互，获取了数据实际所在的数据块，NameNode到对应的DataNode上获取数据，再将该数据传输给Client。访问量小当然没问题，但是高并发的场合呢？大量的用户同时存取大量数据，NameNode很容易就成为了性能瓶颈，桎梏集群的服务能力。
从这样的分析来看，让Client和DataNode交互来读写数据会有两点好处：
可以允许同一份数据在不同的DataNode上被并发访问，因为数据是多副本存储在不同的DataNode上的，这样会提升数据访问的速度。
可以大大减少NameNode的负担，避免NameNode成为数据访问的瓶颈。
这里可能有人会有疑问，为什么NameNode传输具体数据就会成为性能瓶颈，只为Client提供数据块信息就不会？它和Client传输数据块信息不也是数据的传输吗？
根源在于数据量。我们不能百分之百保证NameNode仅仅传输元数据信息一定不会出现单点瓶颈（虽然确实很少会），但是在大数据传输的场合，用户与HDFS交互的数据可能会到达GB、TB，如果所有的数据都经过NameNode来进行，NameNode这一单一节点显然难以支持成百上千的用户的GB、TB级别的数据。但是，如果仅仅是元数据信息，数据量很小，让NameNode成为瓶颈的可能也很小。