为什么不用mysql做数据仓库hdfs_为什么hadoop 不直接采用 lustre 而要用hdfs？

开发环境吧，lustre没有副本机制，如果不是san，坏了盘数据不就丢了？lustre的特点是支持mandaroy lock，对单个大文件的并行读写支持比较好；锁的状态需要在meta data server里面做持久化和复制，还需要有死锁检测的机制，实现起来比较麻烦。这些都是传统科学计算的场景下的需求。一般组网结构是计算存储分类的，存储一般是Fiber channel或者InfiniBand组成一个local的san共享集群。

hadoop的hdfs是用来做map reduce输入输出的共享存储，或者hbase的持久化存储。big data一般是计算存储合一，以太网的普通x86服务器，扩展性很高，但是网络时延达不到FC或者IB的效果。计算存储合一的话需要考虑把计算节点放到存储节点以节省带宽，因此hdfs实现了查询副本位置的接口。hdfs多了个副本复制功能，但write只支持append，不支持随机写或者sparse write等标准的posix语义。hdfs的append写足够支持hbase，因为hbase只有log file和sst file，两者都是append写的。

两个是完全不同的需求和使用场景。spark用s3接口也一样的。lustre走标准的posix挂载，有很好的page cache性能。hdfs的client cache比较晚的版本才合进来，s3之类就没有cache。databricks做了一个alluxio作为统一的cache层，对外宣称性能提高x倍，但实际上并不是一个分布式文件系统，而是一个distributed memory cache。传统的存储厂家，有看到bigdata这块新兴领域，对传统DFS做过一些改造主打高性能的商业级支持，比如IBM的GPFS和EMC的Isillon。