如今，分布式文件系统是大型分析非常重要的一环，即使在使用Spark仍然需要将大量的数据快速存入内存，所以文件系统一定是高速率的。但其实HDFS并不像标榜的那样好，它是大数据分析的薄弱环节。

我们知道，HDFS中的文件分配表的核心是NameNode，客户端主要通过NameNode执行数据操作，DataNode会与其他DataNode进行通信并复制数据块以实现冗余，这样单一的DataNode损坏就会导致集群的数据丢失。但是NameNode一旦发生故障，后果就会非常严重。虽然NameNode可以故障转移，但是花费大量的时间，这也意味着序列中会有更多的等待时间。此外，HDFS的垃圾回收，尤其是Java垃圾回收还需要占用大量的内存，一般是本机有效内存的10倍左右。

因为HDFS的设计更多是建立在响应“一次写入、多次读写”任务的基础上，多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说对HDFS而言，请求读取整个数据集要比读取一条记录更加高效，所以HDFS在语言选择方面更偏向于基础语言，而不是高级语言。

传统的操作可以用更短的时间来开发部署，维护成本更低、安全性更好。业内有这样一种说法，大多数操作系统支持C语言、汇编和Java的原因是文件系统处于一个较低水平。HDFS的工具和其他文件系统工具相較存在差距，比起曾经处理的任何文件系统或分布式存储，HDFS周围的工具表现不佳。基于Java的文件系统只能搭上IT人员最喜爱的POSIX工具的末班车，尝试过NFS挂载HDFS吗？其它的HDFS工具的安装也相对较复杂，相反如果使用REST bridge Tool和客户端命令行就会非常容易。……