Google File System学习笔记

        先贴上GFS Architecture示意图：

        Google云架构是基于Google公司的实际应用需求而设计的，主要针对大型分布式数据密集型应用。因为这个设计太给力了，所以Apache基金会实现了一个开源版本，就是Hadoop，目前貌似Hadoop性能只有Google商业版的1/10。

        如上图，数量众多的数据密集型应用通过GFS client接口，使用file name和chunk index查询GFS master。在GFS中文件都比较大(一般是几个G，上T的也常见)，每个文件分为大小固定的若干chunk，chunk是分布式存储的调度单元。从图上看，chunk index的计算是在GFS client中进行的。

        在GFS master中，用一张树形表来维护文件目录结构，叶子节点可能是文件，一个文件对应一张chunk表，表中内容大概是(chunk index, chunk handle, chunk location)；叶子节点也可能是chunk，一个chunk对应一张(chunk handle, chunk location)表。chunk handle我猜是全局的资源句柄，每个chunk在若干台Linux集群服务器上有冗余备份，所以一个chunk index对应多个(chunk handle, chunk location)。对GFS client的请求返回哪个chunk handle？这个调度应该是在GFS master做的。至于chunk location信息，在系统启动时GFS master会轮询各个chunkserver，之后能够保持动态更新，因为是GFS master来控制chunk的位置分配并通过规律性的heart beat message来监控chunkserver状态。

        在一台Linux集群服务器上分为两层，上层是GFS chunkserver，是GFS与Linux file system之间的接口层，一方面与linux file system交互执行底层数据传输，一方面与GFS client交互执行GFS数据传输，一方面还与GFS master交互以实现一些GFS管理服务。

        图中GFS master与GFS chunkserver之间还有两个箭头：(1) Instructions to chunkserver. 比如，假设系统设置一个chunk应该有3个冗余备份，如果某台Linux服务器崩溃了，其上的chunk都从系统中无法访问，必然导致一些chunk的冗余备份不足3个，GFS master需要指示在其它合适的服务器上建立冗余备份。(2) Chunkserver state. GFS master必然要监控chunkserver的状态，上面提到了，通过heart beat message.

        上面这个结构存在一个明显的中枢脆弱点就是GFS master，不像OpenStack Object Storage中文件metadata是分布式的，理论上这是不够robust，但是Google的设计是从实际应用的需求发展起来的，不需要理论上完美，只追求现实上够用。比如GFS针对大文件进行了优化，文件只能写入一次即只能在文件后面附加数据；而Swiff则被设计为可以存储任意大小的文件，而且文件可以多次写入，感觉上Swiff更尽善尽美。其实，GFS主要针对大数据应用，一般是信息的搜集然后进行检索和分析，Google对最主要的部分进行优化对整体性能提升明显，而Swiff兼顾所有必然会在其它方面承担代价。没有尽善尽美的设计，只有如何取舍。GFS master中枢就不需要分布式控制节点之间的通信，简单高效，而且最重要的metadata唯一需要持久保存的operation log在远程服务器上有备份。

// 附：《The Google File System》1. Introduction节选

//--------------------------------------------------

        设计上有以下几个特点：

        (1) 因为使用的是廉价Linux服务器的大规模集群，有某个节点失效是很寻常的事情。因此GFS将组件失效作为寻常事件而不是异常事件。与之相应地，系统集成了持续监控、出错检测、灾难冗余和自动恢复等功能。

        (2) 大文件存储。一般都是几G的文件，甚至有上T大小的文件。比如，需要将巨多网页文件及相关信息组织在一起，而且还在不断增长，而且还要频繁访问，使用巨多几M的小文件就不合适了。因此，设计的假设条件和参数就需要重新考虑，比如IO操作和block的尺寸。

        (3) Google的业务需求决定了他们对文件的操作主要是在文件末尾appending，在文件中间随机写入数据在实际中几乎不存在。一旦写入，对文件的操作只有读取，而且主要是顺序的读取操作而非随机读取，比如让数据分析程序扫描，或者是生成的中间文件用来作为其它程序的输入。对于这种针对海量数据的访问模式，在客户端缓存数据不能满足需求，因此数据的追加操作是性能优化和原子性保证的主要考虑因素。

        (4) GFS是和上层应用共同设计的，这样让整个系统更加具有灵活性。比如GFS引入了原子性的数据追加操作，多个客户端可以同时进行数据追加操作，不需要额外的同步操作来保证数据的一致性。