看看大数据架构师是如何设计分布式文件系统的-分布式文件系统

489034603

从2003年Google公布自家分布式文件系统相关技术（论文The Google File System）后，便涌现出众多的开源实现，包括HDFS、Quantcast File System（QFS）、MooseFS等，都采用了类似GFS分块的架构，但确有各自的不同特性，如HDFS发展最快，但只支持append-only写，不支持随机写，而QFS以支持erasure coding为主要特性，从而性价比最高，MooseFS其支持随机写特性最好，则在今年进入了快速发展时期，一年内十几个版本发布，企业版的多Master方案更使得其可用性大大提高。

2006年Sage A. Weil设计的CEPH提出了无中心化的架构，其通过CRUSH算法而不是Master来找到数据，其可用性更高。此外，Glusterfs采用弹性哈希解除了对元数据服务器的需求，消除了单点故障和性能瓶颈。

2014年提出的RAMCloud更是激进的提出了全内存的存储架构。

此外，FaceBook提出了Haystack架构来应对大量的小文件存储，提出f4来解决温数据的问题。Microsoft提出了Pelican来解决大量冷数据存储问题。

下面我举几个架构师设计的时候遇到的问题，他们是如何解决的呢?

1、异构存储（磁盘、SSD、内存）以及冷温热数据存储架构如何设计？比如数据热度由热到温最后到冷，对应的存储如何自适应的将数据转换和保存？

冷数据存入机械 SATA 盘，热数据存入 SSD + 内存，如果是非重要的热数据，直接存入内存，比如 Cache，如果是重要的热数据，可存入 SSD，如果对性能要求并不是很高，可以考虑存入 SATA，新写入的数据可以存入 SSD 或者内存，如果热度很低，可以切换至存储到 SATA，不重要的基本上可以直接删掉，根据业务场景设计，不同的业务的需求也不同。

2、有的应用读写并发并不大，而对元数据的操作确异常频繁，如何设计一个以读为主的元数据服务架构或者设计一个以写为主的元数据服务架构？

读写并发不大，对元数据操作频繁这种一般很有可能是小文件，开销主要用在对元数据操作部分了，根据场景不同设计的也不同，一般都是元数据集群，元数据存储在 SSD + 内存做元数据 Cache，跟设计的算法也有关系。

3、当前无论是 CEPH 还是GFS，都存在IO路径过长的问题，有什么方法能缓解这种情况?

Ceph 的性能还不错， GFS 没有用过，不过 Ceph 使用 API 方式性能还不错，但是稳定性确实不太好说，目前我没遇到问题，但是也没商用过，因为我不太喜欢API方式，一般还是 Posix 接口操作，方便，直接 mount 就当本地盘使用了。

4、使用分布式文件系统后，如何快速的检索数据？

最快的方式当然还是 Hash 表，O(1), 也有其他的方式应该，只不过我没有用过，因为我还是比较喜欢 Gluster 这种 Hash 计算文件存储位置的方式，加上一直以来都是做大文件，所以这个并不是太大的问题。

5、云存储的数据分享、隔离和安全性怎么做？

这个主要还是在应用层去做，直接从业务部分去划分好些，如果必须在文件系统层做，可以增加 ACL ，或者根据 UID 进行权限控制，因为 GNU/Linux 本身就有相关的控制设计了

489034603

如果小伙伴想学习大数据技术，可以加下图片下面的交流群，群里有很多学习视频都可以下载，而且每天大数据架构师马士兵老师都会在群里分享大数据的技术。。