《大规模分布式存储系统》 第4章 分布式文件系统【4.2】

javazx

4.2　Taobao File System
/ ~& J2 V8 a2 u7 D- d0 a$ b; w互联网应用经常需要存储用户上传的文档、图片、视频等，比如Facebook相
册、淘宝图片、Dropbox文档等。文档、图片、视频一般称为Blob数据，存储Blob数
据的文件系统也相应地称为Blob存储系统。每个Blob数据一般都比较大，而且多个
, C# ]5 a( m  ^Blob之间没有关联。Blob文件系统的特点是数据写入后基本都是只读，很少出现更
. N( h0 z( c# e; G$ Q% P5 ?0 n新操作。这两节分别以Taobao File System和Facebook Haystack为例说明Blob文件系统
; K. q$ M+ \1 I0 b: |的架构。
2007年以前淘宝的图片存储系统使用了昂贵的NetApp存储设备，由于淘宝数据
量大且增长很快，出于性能和成本的考虑，淘宝自主研发了Blob存储系统Tabao File
System（TFS）。目前，TFS中存储的图片规模已经达到百亿级别。
) \; S# c, t1 R, M; J2 Z6 eTFS架构设计时需要考虑如下两个问题：
+ U( P3 X7 y- r% }% F/ d1 I; R●Metadata信息存储。由于图片数量巨大，单机存放不了所有的元数据信息，假
设每个图片文件的元数据占用100字节，100亿图片的元数据占用的空间为
* m4 G$ F, l& X5 f5 K4 F6 I/ k$ F10G×0.1KB=1TB，单台机器无法提供元数据服务。
2 M# w2 {: T$ H- }& Y) ]; L●减少图片读取的IO次数。在普通的Linux文件系统中，读取一个文件包括三次
磁盘IO：首先读取目录元数据到内存，其次把文件的inode节点装载到内存，最后读
取实际的文件内容。由于小文件个数太多，无法将所有目录及文件的inode信息缓存
到内存，因此磁盘IO次数很难达到每个图片读取只需要一次磁盘IO的理想状态。
因此，TFS设计时采用的思路是：多个逻辑图片文件共享一个物理文件。
$ L* }  f. ]) L& B2 L4.2.1　系统架构
TFS架构上借鉴了GFS，但与GFS又有很大的不同。首先，TFS内部不维护文件
目录树，每个小文件使用一个64位的编号表示；其次，TFS是一个读多写少的应用，
4 P' g1 J& A5 ^+ s8 h; ^相比GFS,TFS的写流程可以做得更加简单有效。
如图4-4所示，一个TFS集群由两个NameServer节点（一主一备）和多个
DataServer节点组成，NameServer通过心跳对DataSrver的状态进行监测。NameServer
相当于GFS中的Master,DataServer相当于GFS中的ChunkServer。NameServer区分为主
$ [4 r9 S8 J# J  V+ r. N2 bNameServer和备NameServer，只有主NameServer提供服务，当主NameServer出现故障
时，能够被心跳守护进程检测到，并将服务切换到备NameServer。每个DataServer上
会运行多个dsp进程，一个dsp对应一个挂载点，这个挂载点一般对应一个独立磁盘，
. t' M5 q% C$ z6 l从而管理多块磁盘。
! e; K+ ~2 ^; A& X9 D' w图　4-4　TFS整体架构
. s6 s+ G* @7 Q# E8 _, |在TFS中，将大量的小文件（实际数据文件）合并成一个大文件，这个大文件称
) S% h2 {8 v% @. J$ |# D' q为块（Block），每个Block拥有在集群内唯一的编号（块ID），通过＜块ID，块内偏
* X+ C. J% I/ E移＞可以唯一确定一个文件。TFS中Block的实际数据都存储在DataServer中，大小一
: e$ o6 ^! I3 `( p% }+ l+ ?般为64MB，默认存储三份，相当于GFS中的chunk。应用客户端是TFS提供给应用程
3 x2 {' y- e" Z# n+ o' t2 y序的访问接口，应用客户端不缓存文件数据，只缓存NameServer的元数据。
1.追加流程
; L2 ^+ ~8 n8 z3 fTFS中的追加流程相比GFS要简单有效很多。GFS中为了减少对Master的压力，
引入了租约机制，从而将修改权限下放到主ChunkServer，很多追加操作都不需要
* G1 M3 l: l0 h1 @5 wMaster参与。然而，TFS是写少读多的应用，即使每次写操作都需要经过NameNode
! x8 F/ E2 E; o" q4 s& e也不会出现问题，大大简化了系统的设计。另外，TFS中也不需要支持类似GFS的多
& [0 k$ r# |; S* k5 f3 J- N! {客户端并发追加操作，同一时刻每个Block只能有一个写操作，多个客户端的写操作
会被串行化。
: t! u7 j* i" ?7 e6 F$ l8 C如图4-5所示，客户端首先向NameServer发起写请求，NameServer需要根据
6 V9 w% g( C- oDataServer上的可写块、容量和负载加权平均来选择一个可写的Block，并且在该
Block所在的多个DataServer中选择一个作为写入的主副本（Primary），其他的作为
) @  a6 [7 i4 ^1 a% s. V& l备副本（Secondary）。接着，客户端向主副本写入数据，主副本将数据同步到多个
2 v) B: {2 b4 \# G( g8 c& U; g备副本。如果所有的副本都修改成功，主副本会首先通知NameServer更新Block的版
本号，成功以后才会返回客户端操作结果。如果中间发生任何错误，客户端都可以
从第一步开始重试。相比GFS,TFS的写流程不够优化，第一，每个写请求都需要多次
访问NameServer；第二，数据推送也没有采用流水线方式减小延迟。淘宝的系统是
2 p. v4 ^% E9 q4 y1 ?" Z7 R1 q! q需求驱动的，用最简单的方式解决用户面临的问题。
. q- b& |! Z+ C  A1 e图　4-5　TFS追加流程
! @+ P# ?3 B) O/ i7 Y每个写操作返回后，会返回客户端两个信息，小文件在TFS中的Block编号
（Block id）以及Block偏移（Block offset）。应用系统会将这些信息保存到数据库
$ m7 k* m: f+ d8 H中，图片读取的时候首先根据Block编号从NameServer查找Block所在的DataServer，
然后根据Block偏移读取图片数据。TFS的一致性模型保证所有返回给客户端的＜
Blockid,Block offset＞标识的图片数据在TFS中的所有副本都是有效的。
# i, j+ v3 M0 M3 ~2.NameServer
NameServer主要功能是：Block管理，包括创建、删除、复制、重新均衡；Data-
, i$ p4 f3 C" i/ w9 S2 X9 QServer管理，包括心跳、DataServer加入及退出；以及管理Block与所在DataServer之
) B) w3 E0 {3 m3 F' g: K3 j间的映射关系。与GFS Master相比，TFS NameServer最大的不同就是不需要保存文件
目录树信息，也不需要维护文件与Block之间的映射关系。
, ]: F" b- _" l. j4 n( w( U% bNameServer与DataServer之间保持心跳，如果NameServer发现某台DataServer发
生故障，需要执行Block复制操作；如果新DataServer加入，NameServer会触发Block
负载均衡操作。和GFS类似，TFS的负载均衡需要考虑很多因素，如机架分布、磁盘
: v/ W9 o+ T& V' G: C利用率、DataServer读写负载等。另外，新DataServer加入集群时也需要限制同时迁
3 h" g: L, e$ p& p* f' I6 F3 C6 A入的Block数量防止被压垮。
! Y7 q+ [' G4 S. z( qNameServer采用了HA结构，一主一备，主NameServer上的操作会重放至备
NameServer。如果主NameServer出现问题，可以实时切换到备NameServer。
! U. Q* r# W( a# q5 B4.2.2　讨论
图片应用中有几个问题，第一个问题是图片去重，第二个问题是图片更新与删
除。
由于用户可能上传大量相同的图片，因此，图片上传到TFS前，需要去重。一般
0 @: f7 `: G) h+ J# m, Y在外部维护一套文件级别的去重系统（Dedup），采用MD5或者SHA1等Hash算法为
图片文件计算指纹（FingerPrint）。图片写入TFS之前首先到去重系统中查找是否存
在指纹，如果已经存在，基本可以认为是重复图片；图片写入TFS以后也需要将图片
7 \1 j8 }* o1 n的指纹以及在TFS中的位置信息保存到去重系统中。去重是一个键值存储系统，淘宝
内部使用5.2节中的Tair来进行图片去重。
, ?8 e. ^3 M+ r; g3 L& t* f, H2 M图片的更新操作是在TFS中写入新图片，并在应用系统的数据库中保存新图片的
位置，图片的删除操作仅仅在应用系统中将图片删除。图片在TFS中的位置是通过＜
1 n$ q  `4 H8 }. _& t' U0 P  NBlock id,Block offset＞标识的，且Block偏移是在Block文件中的物理偏移，因此，每
个Block中只要还有一个有效的图片文件就无法回收，也无法对Block文件进行重整。
如果系统的更新和删除比较频繁，需要考虑磁盘空间的回收，这点会在Facebook
Haystack系统中具体说明。
& A$ M7 [. v% }2 b* z9 g+ H

2 A3 V' U5 X# ]. C  `( Y' [