HDFS适合做：
1.存储大文件。上G、T甚至P。
2.一次写入，多次读取。并且每次作业都要读取大部分的数据。
3.搭建在普通商业机群上就可以了。虽然会经常宕机，但HDFS有良好的容错机制。
HDFS不适合做：
1.实时数据获取。如果有这个需求可以用HBase。
2.很多小文件。因为namenode要存储HDFS的metadata（ 比如目录的树状结构，每个文件的文件名、ACL(权限管理)、长度、owner、文件内容存放的位置等等信息），所以HDFS上文件的数目受到namenode内存的限制。
3.并发环境下的写入和修改。
hadoop中存储文件以HDFS形式存储,HDFS拥有自己的设计原则：
1：文件大小以block块的形式存储
2：每个块至少分配到三台DataNode（看集群情况而定）
3：通过副本机制提高可靠度和吞吐量
4：hadoop1.0使用单一的master（NameNode）来协调存储元数据（metadata）
5：最有意思的是hadoop设计者没有设置客户端缓存机制，因为我们对处理数据有足够的信心。
下图为HDFS的系统结构
NameNode:主要存储元数据：例如：文件名，拷贝几份，分别备份到哪里；
过程大概如下：
client要向集群中写入数据，首先询问Master（NameNode）,Master告知客户端向哪些DataNode写入数据，在往DataNode写入数据的同时，DataNode与NameNode保持心跳，如果DataNode在执行任务失败，NameNode会通过心跳机制得知DataNode死掉，将重新分配新的任务到其他的DataNode。
2：Block之副本放置策略
第一副本：放置在上传文件DataNode，如果是集群外提交，由NameNode选择一台磁盘不太满，CPU不太忙的节点。
第二副本：放置在于第一副本不同的机架的节点上
第三副本：与第二个副本相同集群的节点
也许根据业务的需要我们需要更多地副本，其他副本随机分配
3：Block的存储形式
1：Block默认大小64M，如果上传文件小于64M，那么仍然占用一个命名空间（NameNode metadata），
但是物理存储不会占用64M空间； （这也是hadoop为什么不太适合处理小数据的原因之一）
2： Block大小和副本数由Client端上传文件到HDFS时设置，其中副本数可以变更，Block是不可以再上传后变更的。
转自： http://www.cnblogs.com/zhanghuijunjava/archive/2013/04/22/hadoop-block_hdfs.html