从架构角度而言，hadoop HDFS 是一个master/slave架构的系统。
NameNode类似于master的身份，负责管理文件系统的名字空间(namespace)以及客户端对文件meta信息的访问。所谓meta信息，就是指文件存储路径，复制因子，名称等信息以及修改日志等。同时NameNode还通过侦听客户端发送过来的心跳信息，维护整个hadoop Cluster的节点状态。
HDFS中的实际数据则由DataNode负责存储和维护，DataNode是一个slave身份。
向HDFS写入一个文件数据时，默认情况下hadoop系统Block Szie=64MB，将当前文件切分成多个数据块。除了该文件的最后一个数据块可能小于64MB之外，其他均等于64MB。hadoop HDFS的replication机制则根据文件复制因子数量，将该文件切分的Block复制多份，分别复制到其它DataNode。
HDFS Replication机制有点类似于cassandra的机制，不过比起cassandra仍然逊色不少。例如cassandra默认首先向远程datacenter复制一份，然后向同一个机房的另外一个机架复制。而Hadoop HDFS仅仅向另外一个机架进行数据复制。当出现硬件错误时，通过这种策略尽可能的减少数据丢失的风险。
当然还会记录其校验信息，用于验证数据完整性。默认使用CRC32算法。不过根据taobao相关技术人员说法，认为自带的crc32算性能较差。
DataNode在分布式环境中基本都是每台机器一个jvm进程。而NameNode则始终只分布在一台机器，只有一个JVM进程。
当客户端进行HDFS数据访问时，首先需要访问NameNode，获取访问目标文件的meta信息以及block分布信息，对于实际数据的IO，则直接通过DataNode进行。因此HDFS Master/Slave架构中的Master，如果设计优化，即便是海量数据，IO的压力仍然相对会比较小。
而真正进行数据访问时，主要是DataNode负责并行读写，因此虽然单台机器的硬盘假设读写90MB/s，如果1000台机器，则读写IO每秒可以达到90*1000的吞吐量。因此对于互联网公司例如taobao接近3000台的hadoop cluster规模，每秒IO超过250G还是非常轻松的。对于类似集群，处理1T数据，延迟大多数都小于2分钟。显然对于这种离线型的海量数据分析，显然具有很大的应用前景。
影响NameNode一个最终要的因素主要是小文件数量以及文件更改，迁移等操作影响，这个我们将在后面介绍