为啥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。
■网友
因为hadoop和hdfs是一家的，当然默认用他了。hadoop里面的存储层用哪个都可以啊。
■网友
一句话，hdfs性能不如lustre,但是不折腾，而且对于一般big data应用够用了。Lustre毕竟是超算出身的底子，配上ib性能绝对高，还有lustre over zfs, burst buffer之类各种花样让你在性能/可靠性上更上一层楼。但是为啥搞big data的和搞hpc的不一样？用不上啊（或者说性价比不值啊） 一般big data的还有用1gbe的呢，这种情况下lustre性能没啥优势。还有你拿几台机器玩玩可能看不出来，lustre要是有了一定规模，坑相当大，要么买商业的解决方案，要么雇真正能玩转的高人才行，hdfs 相比之下坑小不少。最后一句话，机器是用来干活的，不是用来折腾的。能解决实际问题就是最好的。
■网友
【为啥hadoop 不直接采用 lustre 而要用hdfs】 可以的 没问题，只是当时发明hadoop的人自己写的hdfs 并且很好用而已
推荐阅读
- 为啥看到书柜上的藏书会有心旷神怡的感觉
- 为啥知乎上普便有一种【我在北上广深打工，所以拥有更好的视野】这样的错觉
- 为啥工商银行的用户体验如此之差
- 汽车|看了中消协4S店服务测评调查结果，终于知道法系车为啥卖不好了
- 你为啥从窝窝商城离职?
- 孕妇到了预产期，小孩还没有入盆，请问是该等下去还是直接剖腹产
- 为啥5G和2.4G默认的BSSID是相同的
- 为啥电器实体店的价格比淘宝贵那么多
- 现在在线学习视频有很多了，为啥大部分人还是喜欢下载下来观看
- 为啥到现在你还没有女朋友 ?