Hadoop文件系统概念
Hadoop定义了一组抽象的文件系统接口，HDFS只是其中的一个实现，也就是说，HDFS只是可用于Hadoop数据存储的一种方式，这个很符合JAVA这门语言的一贯作风，先发布接口，然后对应的有很多种实现。另外实现了Hadoop的文件系统接口的有HFTP(基于HTTP对HDFS进行只读访问的文件接口)，HSFTP(基于HTTPS对HDFS进行只读访问的文件系统)。
HDFS
HDFS架构图
特点
- 流式数据访问：一次写入，多次读取，每次分析都将读取数据集中的大部分数据，因此读取记录所带来的延迟更大程度上的取决于整体，而不是一个单个的数据。
- 超大文件：HDFS可以存储TB，PB以及更大的数据文件，通过将数据文件拆分为大量的小文件重复存储，提供了很高的可靠性，但是这其中的过程对于用户透明，自动实现文件的可靠存储。
- 不适用于低延时要求应用：HDFS是为数据分析而设计，这其中必然要花费大量的时间，对于要求低延时的需求，HBASE是更好的选择。
- 不支持多用户写入：HDFS只能支持一个用户在文件末尾写入数据，不支持多用户或者单用户在文件任意位置写入数据。
设计
- 对于一个超大的文件，如果直接存储的话，那么读取该文件时的传输时间将会很长，HDFS将大文件拆分为很多小文件，并且设置合理的数据块大小，实现了大大减少传输时间，并且不会产生较高的寻址时间。数据块的大小影响着传输时间和寻址时间占数据读取过程中总时间的比例。
- datanode和namenode的设计，namenode作为datanode的管理者，记录着datanode的元数据，datanode则记录这各个数据块的数据。namenode通过命名空间镜像文件和编辑日志文件记录这HDFS文件系统中的文件目录结构和其中所有的文件和目录以及一个文件的某个数据块在哪个datanode上面，正因为namanode记录着这些信息，所以，一旦namenode宕机的话将导致整个HDFS文件系统不可用，因此需要对namanode做高可靠的容错容灾机制。
可用性
- 备份命名空间镜像文件和编辑日志文件。通过配置Hadoop可以实现把namebode文件实时同步的保存在其他文件系统中，例如一个远程的网络文件系统，并且这个操作是同步的。
- 主从namenode。另一种保证namenode可用性的方法就是使用主从的namanode，从namenode通过读取主namanode的编辑日志更新命名空间镜像文件，但是这个操作是滞后于主namenode的，所以在主namenode发生故障时，还是会有一部分的编辑日志没有被从namenode合并到命名空间镜像文件中。另外一方面，从namenode也要占用和主namenode一样的硬件资源，相对而言成本较高。
- 多个namenode挂载。单独namenode的方式对于拥有大量数据的集群来说，内存是一个很大的限制，所以另一种设计是多个namanode和多个datanode。类似域linux的文件系统方式，datanode相当于硬盘，每个namenode记录一个数据池的元数据，数据池相当于/usr这种是一个目录，数据池中的数据块可以放在一个或者多个datanode上面，相当于磁盘的不同扇区，至于具体放在哪个datanode上面，对应数据池的namenode有相应的记录啦~感觉这种设计很巧妙。
- 增加备用namenode。这种方案听上去感觉和第二种一样，他们之间的区别在于，这种发难是通过一个高可用的共享存储（例如构建与ZooKeeper之上的BookKeeper）实现编辑日志的实时共享，并且datanode需要同时向这两个namenode发送数据处理报告，而2中的方案只需要向一个namenode发送就可以了~至于怎样进行故障切换，则可以通过ZooKeeper这种故障转移控制器来实现，ZooKeeper通过心跳检测来监视namenode是否正常工作，不正常工作时则进行故障切换。
数据访问方式
- HTTP访问。客户端直接访问namenode和datanode，客户端通过代理服务器访问namenode和datanode，第二种方式可以很方便的增加各种限制策略。
- 通过Hadoop URL读取数据。例如new URL("hdfs://host/path").openStream();
-
通过文件系统API访问数据。类似于java的文件系统访问，只不过增加了部分配置和方法。
写操作
读操作
详细参见或者自行百度
http://www.cnblogs.com/laov/p/3434917.html、
