|
|
4.2 Taobao File System
# l* L( E+ {! @4 T( ?, m' n# ?互联网应用经常需要存储用户上传的文档、图片、视频等，比如Facebook相" u% M. v% l. R5 v
册、淘宝图片、Dropbox文档等。文档、图片、视频一般称为Blob数据，存储Blob数( O4 F3 C& Z ?$ R- C$ v
据的文件系统也相应地称为Blob存储系统。每个Blob数据一般都比较大，而且多个
1 k% _$ N6 Z5 Z9 MBlob之间没有关联。Blob文件系统的特点是数据写入后基本都是只读，很少出现更, a4 h4 v0 M' n+ U5 j' p8 C# H
新操作。这两节分别以Taobao File System和Facebook Haystack为例说明Blob文件系统) F) }- U5 j! \. i: k8 a8 u
的架构。
b# j0 M0 |" O; Z, `1 e( b2007年以前淘宝的图片存储系统使用了昂贵的NetApp存储设备，由于淘宝数据 N8 D0 R5 w" ^: c9 r+ z4 c
量大且增长很快，出于性能和成本的考虑，淘宝自主研发了Blob存储系统Tabao File) J9 f1 m+ ?7 O, i# }+ P9 [
System（TFS）。目前，TFS中存储的图片规模已经达到百亿级别。
8 p' M, V. W9 C& y4 d+ P: k# _( `& tTFS架构设计时需要考虑如下两个问题：
) |; q$ r& y: p- N9 V5 V1 E, t●Metadata信息存储。由于图片数量巨大，单机存放不了所有的元数据信息，假2 k- r3 f) @& d; ]9 ~
设每个图片文件的元数据占用100字节，100亿图片的元数据占用的空间为
. {" e% W3 c4 o2 Z2 [( }10G×0.1KB=1TB，单台机器无法提供元数据服务。7 H/ w' J8 k# a( u5 R
●减少图片读取的IO次数。在普通的Linux文件系统中，读取一个文件包括三次
4 y2 N* u5 z! j3 q0 Y& b磁盘IO：首先读取目录元数据到内存，其次把文件的inode节点装载到内存，最后读
( x% u7 H" c- w9 t! S$ ^+ M$ k取实际的文件内容。由于小文件个数太多，无法将所有目录及文件的inode信息缓存% d% t, t9 g" l9 n3 ~# P
到内存，因此磁盘IO次数很难达到每个图片读取只需要一次磁盘IO的理想状态。
' `* ?2 i4 e' r( Z* O因此，TFS设计时采用的思路是：多个逻辑图片文件共享一个物理文件。, L5 K* B* {1 H
4.2.1 系统架构
8 z. r2 d/ v% B& R4 QTFS架构上借鉴了GFS，但与GFS又有很大的不同。首先，TFS内部不维护文件4 C" m, P$ v9 Y* D" Q& z) s& |
目录树，每个小文件使用一个64位的编号表示；其次，TFS是一个读多写少的应用，. i- ^9 R. `* W1 H
相比GFS,TFS的写流程可以做得更加简单有效。: u6 `) Y, |% w5 m; M6 k4 a! ^2 F9 Q6 }
如图4-4所示，一个TFS集群由两个NameServer节点（一主一备）和多个
P a: b# A/ QDataServer节点组成，NameServer通过心跳对DataSrver的状态进行监测。NameServer; |# Z4 O& g( H' `3 l3 ]* A
相当于GFS中的Master,DataServer相当于GFS中的ChunkServer。NameServer区分为主
( C: k5 H: O$ h1 ^- k. PNameServer和备NameServer，只有主NameServer提供服务，当主NameServer出现故障8 p' d s$ c7 W9 F- }# V; ~
时，能够被心跳守护进程检测到，并将服务切换到备NameServer。每个DataServer上- ?0 r+ L' H$ [1 N1 T
会运行多个dsp进程，一个dsp对应一个挂载点，这个挂载点一般对应一个独立磁盘，
/ B+ E* {3 P. X8 S/ f: \从而管理多块磁盘。
8 \0 v7 D' G( p+ i7 M5 v4 A6 L; x图 4-4 TFS整体架构
9 p. i$ j- s2 Q1 X3 A* P/ I在TFS中，将大量的小文件（实际数据文件）合并成一个大文件，这个大文件称6 K9 j5 k/ ~0 K6 S( D
为块（Block），每个Block拥有在集群内唯一的编号（块ID），通过＜块ID，块内偏
: D! F9 l, A$ y2 m; y, K. L7 D {" C移＞可以唯一确定一个文件。TFS中Block的实际数据都存储在DataServer中，大小一
% \- Q) s! o; I/ F8 P) w9 }般为64MB，默认存储三份，相当于GFS中的chunk。应用客户端是TFS提供给应用程
* n. R/ b) A9 u) G4 H5 @: Q# c6 J' n序的访问接口，应用客户端不缓存文件数据，只缓存NameServer的元数据。
6 o9 B0 H7 h( C5 x: B- d1.追加流程5 w, B3 h7 _3 R; a! h8 p
TFS中的追加流程相比GFS要简单有效很多。GFS中为了减少对Master的压力，
# f, P# ^( j# M5 z+ i4 k4 L- l9 }引入了租约机制，从而将修改权限下放到主ChunkServer，很多追加操作都不需要
$ p, m. Z/ U H( l/ gMaster参与。然而，TFS是写少读多的应用，即使每次写操作都需要经过NameNode! s+ j: [- T& ]. X2 F `- W6 [( w
也不会出现问题，大大简化了系统的设计。另外，TFS中也不需要支持类似GFS的多. {4 O e2 b+ X6 S* R' r, y! z
客户端并发追加操作，同一时刻每个Block只能有一个写操作，多个客户端的写操作
; F- ^( t/ f7 Q$ |1 B: A% ]会被串行化。
7 d' i, f; n3 H. q& S如图4-5所示，客户端首先向NameServer发起写请求，NameServer需要根据
! M- ^9 I9 t) X; E" L: D, RDataServer上的可写块、容量和负载加权平均来选择一个可写的Block，并且在该
# q# W0 f0 [, ^Block所在的多个DataServer中选择一个作为写入的主副本（Primary），其他的作为. h8 s6 A/ _1 ^/ ^3 c' a
备副本（Secondary）。接着，客户端向主副本写入数据，主副本将数据同步到多个+ o( i3 T; ?! T6 x
备副本。如果所有的副本都修改成功，主副本会首先通知NameServer更新Block的版8 }. j0 d; S# L1 Q! O- A' n
本号，成功以后才会返回客户端操作结果。如果中间发生任何错误，客户端都可以
( X5 t8 g4 Z. s* ^从第一步开始重试。相比GFS,TFS的写流程不够优化，第一，每个写请求都需要多次
# J) q2 a/ M( g$ C访问NameServer；第二，数据推送也没有采用流水线方式减小延迟。淘宝的系统是
- U8 N4 Y+ r8 `/ ~/ @* _需求驱动的，用最简单的方式解决用户面临的问题。' Z; g# J9 M, n
图 4-5 TFS追加流程
) V- D9 Q$ c9 Z: a每个写操作返回后，会返回客户端两个信息，小文件在TFS中的Block编号& o/ z7 M7 q# c, t& N h, N
（Block id）以及Block偏移（Block offset）。应用系统会将这些信息保存到数据库
( r0 ~( Y) t2 h! f中，图片读取的时候首先根据Block编号从NameServer查找Block所在的DataServer，& ~/ x+ A! j( G
然后根据Block偏移读取图片数据。TFS的一致性模型保证所有返回给客户端的＜* x/ @& s3 u. }/ v6 m& e1 z
Blockid,Block offset＞标识的图片数据在TFS中的所有副本都是有效的。: N" U+ ^+ }; F' [, m" s* _2 f
2.NameServer2 N+ [0 c4 U8 J
NameServer主要功能是：Block管理，包括创建、删除、复制、重新均衡；Data-9 V+ N4 f8 f" c: _6 Y4 g7 K
Server管理，包括心跳、DataServer加入及退出；以及管理Block与所在DataServer之" u& [; ^% d$ ]# l0 S! L- X. O$ Y
间的映射关系。与GFS Master相比，TFS NameServer最大的不同就是不需要保存文件
& U2 f3 S. w! r5 l- t: I目录树信息，也不需要维护文件与Block之间的映射关系。( k: z7 o) p) X) d! k- m
NameServer与DataServer之间保持心跳，如果NameServer发现某台DataServer发
/ W$ D. o, s& y9 i9 i2 \生故障，需要执行Block复制操作；如果新DataServer加入，NameServer会触发Block2 J3 l% k$ q* Z$ F4 m$ U
负载均衡操作。和GFS类似，TFS的负载均衡需要考虑很多因素，如机架分布、磁盘
& ]+ Z, ]# i6 Q' d, ]2 t8 D利用率、DataServer读写负载等。另外，新DataServer加入集群时也需要限制同时迁
1 @- j. I* Q" y) r入的Block数量防止被压垮。
! G, _6 M7 A4 s h3 t* A2 D4 ?NameServer采用了HA结构，一主一备，主NameServer上的操作会重放至备
: _- h3 J; U' ~' r$ w# b0 WNameServer。如果主NameServer出现问题，可以实时切换到备NameServer。
- }: b& [" ?% {4.2.2 讨论
7 n$ i$ ]: Q+ o: j图片应用中有几个问题，第一个问题是图片去重，第二个问题是图片更新与删
3 N/ X% p3 _" w) I+ M& a# u( n除。
4 X* ^, ~0 v! v t9 `* [由于用户可能上传大量相同的图片，因此，图片上传到TFS前，需要去重。一般
! \: f* o& O- {0 z5 M" Z. ~* z在外部维护一套文件级别的去重系统（Dedup），采用MD5或者SHA1等Hash算法为
- y* d( w0 A$ J/ D2 G# G图片文件计算指纹（FingerPrint）。图片写入TFS之前首先到去重系统中查找是否存
: d0 F, C- U+ M7 _; F- P在指纹，如果已经存在，基本可以认为是重复图片；图片写入TFS以后也需要将图片/ n8 p5 t6 E6 Y2 L7 ]) \5 w% F* s; c
的指纹以及在TFS中的位置信息保存到去重系统中。去重是一个键值存储系统，淘宝4 d' A7 V8 H/ K5 I) G! C
内部使用5.2节中的Tair来进行图片去重。; k7 K# n R9 r) M
图片的更新操作是在TFS中写入新图片，并在应用系统的数据库中保存新图片的( K' r1 X! |; r8 T
位置，图片的删除操作仅仅在应用系统中将图片删除。图片在TFS中的位置是通过＜
7 V; O# k' k* w( J& ^& F1 N! K2 _Block id,Block offset＞标识的，且Block偏移是在Block文件中的物理偏移，因此，每
) f2 u* |1 J( `5 r个Block中只要还有一个有效的图片文件就无法回收，也无法对Block文件进行重整。
1 J V+ M, {; O如果系统的更新和删除比较频繁，需要考虑磁盘空间的回收，这点会在Facebook
7 P3 v, c6 ^4 t% ZHaystack系统中具体说明。; n% h& z" o0 w( b/ j: P, H
$ M1 K, m4 R4 r7 K x2 d: ~. s( P% s- h2 x, i, e
|
|
发表于 2017-3-3 20:23:20
