distributed filesystem

⼤大数据之分布式⽂文件系统

Why, what and how

好⾖豆⺴⽹网

赵卫国@mlsx

2013-9-14

13年9⽉月16⽇日星期⼀一

Google

> 100 PB> 1T indexed URLs> 3 million servers

> 7.2B PV/day13年9⽉月16⽇日星期⼀一

Facebook

> 1 billion users> 300PB; +>500TB/day

>35% of world’s photographs


YouTube

> 1000PB+> 72 hours/minute

> 37 million hours/year> 4 billion views/day


Twitter

> 124 B tweets/year> 390M/day~4500/sec


World Population

>7,057,065,162


⼤大数据是

http://www.businessinsider.com/cia-presentation-on-big-data-2013-3?op=113年9⽉月16⽇日星期⼀一

http://www.businessinsider.com/cia-presentation-on-big-data-2013-3?op=1


⼤大数据是

+




⼤大数据是

+ +




⼤大数据是

+ +


CTO of CIA




⼤大数据的价值

http://www.mckinsey.com/insights/business_technology/big_data_the_next_frontier_for_innovation13年9⽉月16⽇日星期⼀一

http://www.mckinsey.com/insights/business_technology/big_data_the_next_frontier_for_innovation



美国医疗服务

• 每年价值3000亿美元• ⼤大约0.7%的年⽣生产率增⻓长





美国医疗服务


欧洲公共部门管理

• 每年价值2500亿欧元• ⼤大约0.5%的年⽣生产率增⻓长





美国医疗服务




制造业

• 产品开发、组装成本降低达50%• 运⾏行资本降低达7%





美国医疗服务




全球个人位置数据

• 服务提供商收⼊入1000亿美元或以上• 最终⽤用户价值达7000亿美元

制造业






美国医疗服务






美国零售业

• 可能的净利润增⻓长⽔水平为60%或以上• 0.5~1.0%的年⽣生产率增⻓长

制造业






美国医疗服务






美国零售业

• 可能的净利润增⻓长⽔水平为60%或以上• 0.5~1.0%的年⽣生产率增⻓长

制造业


“大数据在政府公共服务、医疗服务、零售业、制造业、以及设计个人位置服务等领域都将带来可观的价值”

-- 麦肯锡全球研究院




⼤大数据的特征


⼤大数据的特征“所涉及的数据量规模巨⼤大到⽆无法通过⺫⽬目前主流软件⼯工具，在合理时间内达到获取、管理、处理、并整理成为帮助企业经营决策更积极⺫⽬目的的信息的程度”

- 中⽂文维基百科


⼤大数据来源


⼤大数据来源

•互联⺴⽹网企业：社交⺴⽹网站、微博客、视频、电⼦子商务


⼤大数据来源


•物联⺴⽹网、移动设备、终端、个⼈人位置、传感器采集的数据


⼤大数据来源



•通信和互联⺴⽹网运⾏行商


⼤大数据来源



•通信和互联⺴⽹网运⾏行商•天⽂文、⽓气象、医疗数据


⼤大数据带来的挑战

http://mmdays.com/wp-content/uploads/2013/03/Bigdata.jpg13年9⽉月16⽇日星期⼀一

http://mmdays.com/wp-content/uploads/2013/03/Bigdata.jpg



• 数据采集• 数据存储• 数据搜索• 数据共享• 数据传输• 数据分析• 数据可视化

http://mmdays.com/wp-content/uploads/2013/03/Bigdata.jpg13年9⽉月16⽇日星期⼀一





数据如何存储




传统存储


传统存储

• 问题


传统存储

• 问题

• 纵向扩展受阵列空间限制


传统存储

• 问题


• 横向扩展受交换设备限制


传统存储

• 问题


• 横向扩展受交换设备限制

• 节点受⽂文件系统限制


分布式存储

Interconnection Network

Node 1 Node 1 Node 1...


分布式存储

• 挑战• 节点间通信• 数据存储• 数据空间平衡• 容错• ⽂文件系统⽀支持

Interconnection Network

Node 1 Node 1 Node 1...


分布式⽂文件系统设计⺫⽬目标

http://en.wikipedia.org/wiki/Distributed_file_system#Distributed_file_systems13年9⽉月16⽇日星期⼀一

http://en.wikipedia.org/wiki/Distributed_file_system#Distributed_file_systems


分布式⽂文件系统设计⺫⽬目标“分布式⽂文件系统在众多概念中瞄准“透明”这个理念，也即对客户端或者客户端程序它是透明的，客户端或客户端程序就像使⽤用本地⽂文件系统⼀一样可以使⽤用分布式⽂文件系统，在其幕后，由分布式⽂文件系统来处理⽂文件定位、数据传输以及更多的功能:”






•访问透明

“分布式⽂文件系统在众多概念中瞄准“透明”这个理念，也即对客户端或者客户端程序它是透明的，客户端或客户端程序就像使⽤用本地⽂文件系统⼀一样可以使⽤用分布式⽂文件系统，在其幕后，由分布式⽂文件系统来处理⽂文件定位、数据传输以及更多的功能:”






•访问透明•位置透明







•访问透明•位置透明•并发透明







•访问透明•位置透明•并发透明•失效透明








•硬件透明








•硬件透明•可扩展性








•硬件透明•可扩展性•复制透明








•硬件透明•可扩展性•复制透明•迁移透明






⼀一些理论准备

http://tinyurl.com/nqdsayj




CAP理论(Brewer的猜想）2000 Prof.Eric Brewer,PoDC Conference Keynote2002 Seth Gilbert and Nancy Lynch ACM SIGACT News 33(2)

http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf


http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf


http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf


CAP理论(Brewer的猜想）2000 Prof.Eric Brewer,PoDC Conference Keynote2002 Seth Gilbert and Nancy Lynch ACM SIGACT News 33(2)

“ Of three properties of shared-data systems - data Consistency,system Availability and tolerance to network Partitions - only two can be achieved at any given moment in time.”

http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf






CAP

C13年9⽉月16⽇日星期⼀一

• ⼀一致性(Consistency)

• 任何⼀一个读操作总能读取到之前完成的写操作结果

CAP




• 可⽤用性(Availability)

• 每⼀一个操作总是能在确定的时间内返回

CAP






• 分区可容忍性(Tolerance of network Partition)

• 在出现⺴⽹网络分区的情况下，仍然能够满⾜足⼀一致性和可⽤用性

CAP






• 分区可容忍性(Tolerance of network Partition)

• 在出现⺴⽹网络分区的情况下，仍然能够满⾜足⼀一致性和可⽤用性

CAP

C

picktwo

C

A P


分区容忍性-可⽤用性

http://codahale.com/you-cant-sacrifice-partition-tolerance/ http://pl.atyp.us/wordpress/?p=2521


http://pl.atyp.us/wordpress/?p=2521


分区容忍性-可⽤用性“The network will be allowed to lose arbitrarily many messages sent from one node to another” [...]

“For a distributed system to be continuously availability,every request received by non-failing node in the system must result in a response”

- Gillbert and Lynch,SIGACT 2002





分区容忍性-可⽤用性“The network will be allowed to lose arbitrarily many messages sent from one node to another” [...]

“For a distributed system to be continuously availability,every request received by non-failing node in the system must result in a response”

- Gillbert and Lynch,SIGACT 2002


HIGH LATENCY≈

NETWORK PARTITION

http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html






⼀一致性

http://www.allthingsdistributed.com/2008/12/eventually_consistent.html




⼀一致性

• 强⼀一致性(类似ACID)





⼀一致性

• 强⼀一致性(类似ACID)• 弱⼀一致性（⽆无保证）- 不⼀一致窗⼝口





⼀一致性

• 强⼀一致性(类似ACID)• 弱⼀一致性（⽆无保证）- 不⼀一致窗⼝口•最终⼀一致性(⽐比如DNS）





⼀一致性 NWR模型


⼀一致性 NWR模型N = 数据副本的节点数



W = 成功写操作的最少节点数




R = 成功读操作的最少节点数





W + R > N





W + R > N 强⼀一致性(通常 N=3,W=R=2)






W + R ≤ N






W + R ≤ N 弱⼀一致性






W=N,R=1 最佳读

W=1,R=N 最佳写

W + R ≤ N 弱⼀一致性


基于模的哈希N1 N2 N3 N4


基于模的哈希

?

N1 N2 N3 N4


基于模的哈希

?

partition = key % n_servers

N1 N2 N3 N4


基于模的哈希


N1 N2 N3 N4


基于模的哈希


N1 N2 N3 N4

partition = key % (n_servers -‐ 1)


基于模的哈希


N1 N2 N3 N4

partition = key % (n_servers -‐ 1)

当n_servers改变时，重新计算所有的资源(i.e 节点改变时，资源需要全部重新分布)


⼀一致哈希

http://en.wikipedia.org/wiki/Consistent_hashing13年9⽉月16⽇日星期⼀一

http://en.wikipedia.org/wiki/Consistent_hashing


Ring(Key space)

02160

⼀一致哈希




Ring(Key space)

02160

⼀一致哈希

创建⼀一个针对数据以及节点的hash函数

idx = hash(key)

协调器: 延顺指针⽅方向的第⼀一个有效节点




Ring(Key space)

02160

⼀一致哈希


idx = hash(key)



A

E

F

B

CD




Ring(Key space)

02160

⼀一致哈希


idx = hash(key)



A

E

F

B

CD

节点B hold住节点A⾄至节点B之间的数据




Ring(Key space)

02160

⼀一致哈希


idx = hash(key)



A

E

F

B

CD




Ring(Key space)

02160

⼀一致哈希


idx = hash(key)



A

E

F

CD




Ring(Key space)

02160

⼀一致哈希


idx = hash(key)



A

E

F

CD

节点C此时hold住节点A到C之间的数据




Ring(Key space)

02160

⼀一致哈希


idx = hash(key)



A

E

F

CD

仅影响A B节点之间的数据

节点C此时hold住节点A到C之间的数据




⼀一致哈希：复制

Ring(Key space)

A

B

CD

E

F

http://horicky.blogspot.com/2009/11/nosql-patterns.html13年9⽉月16⽇日星期⼀一

http://horicky.blogspot.com/2009/11/nosql-patterns.html



Ring(Key space)

A

B

CD

E

F


数据延顺指针⽅方向分布到N -1 有效节点上





Ring(Key space)

A

E

F


KeyAB 分布到节点

B,C,D上


B

CD





Ring(Key space)

A

E

F


KeyAB 分布到节点

B,C,D上


B

CD

节点hold住KeyFA , KeyAB , KeyBC




⼀一致哈希：节点改变

A

B

CD

E

F


当有节点加⼊入或者离开⺴⽹网络时，数据关系以及副本需要更新。

⺴⽹网络内所有副本数据保持⼀一致。





A

CD

E

F








A

CD

E

F


拷⻉贝节点E，F之间的所有数据







A

CD

E

F



拷⻉贝节点F，A之间的所有数据







A

CD

E

F



拷⻉贝节点F，A之间的所有数据

拷⻉贝节点A，B之间的所有数据






⼀一致哈希：数据倾斜

Ring(Key space)

A

B

http://news.shangdu.com/102/20121019/P_5714444_0__297724710.jpg13年9⽉月16⽇日星期⼀一

http://news.shangdu.com/102/20121019/P_5714444_0__297724710.jpg


⼀一致哈希：数据倾斜

Ring(Key space)

A

B


元芳，此事你怎么看？

⼤大⼈人，我看还得赶紧想别的办法




⼀一致哈希：虚拟节点

Ring(Key space)

A

B

C

D

EF

G

H

I

02160

每个物理节点⽣生成随机tokens，然后根据token值分区

Node 1: tokens A, E, G

Node 2: tokens C, F, H

Node 3: tokens B, D, I


分布式⽂文件系统



• Google Filesystem




• Taobao Filesystem





• Hadoop Distributed Filesystem






• Mogile Filesystem






• Mogile Filesystem

• Moose Filesystem


Google File system


Why


Why

• Google需要⼀一个分布式⽂文件系统

•在廉价和不可靠的机器上存储巨量数据


Why

• Google需要⼀一个分布式⽂文件系统

•在廉价和不可靠的机器上存储巨量数据•为什么不使⽤用已经存在的⽂文件系统？• Google有和其他任何⼈人都不相同的问题

• GFS 专为Google应⽤用和负载设计

• Google应⽤用专为GFS设计


GFS 设计思路


GFS 设计思路

• ⺫⽬目标• 性能、可伸缩性、可靠性、可⽤用性


GFS 设计思路

• ⺫⽬目标• 性能、可伸缩性、可靠性、可⽤用性

• 应⽤用特定场景• 组件故障是常态⽽而不是异常• 处理的⽂文件都是巨型的• ⼤大部分⽂文件的变化都是追加⽽而不是覆盖，随机写⼏几乎不存在。


前提设定


前提设定

• 组件失败是常态


前提设定

• 组件失败是常态• 存储的绝⼤大部分都是⼤大⽂文件

• ⽂文件数在百万级别• 每个⽂文件都在100M以上，⼀一般都是GB级别


前提设定



• ⽂文件只写⼀一次，绝⼤大部分是追加


前提设定



• ⽂文件只写⼀一次，绝⼤大部分是追加• ⼤大量的流式读


前提设定



• ⽂文件只写⼀一次，绝⼤大部分是追加• ⼤大量的流式读• 低延迟，⾼高吞吐


GFS 架构

http://research.google.com/archive/gfs-sosp2003.pdf13年9⽉月16⽇日星期⼀一

http://research.google.com/archive/gfs-sosp2003.pdf


GFS 架构


单⼀一，维护所有元数据，负责主导⼀一些影响整个系统的活动




GFS 架构



多节点，将chunk存储为Linux⽂文件




GFS 架构



多节点，将chunk存储为Linux⽂文件

专⽤用客户端，类似传统⽂文件系统API，负责和Master以及Chunkserver通信




GFS: Master


GFS: Master• 存储元数据


GFS: Master• 存储元数据• 命名空间管理、锁定


GFS: Master• 存储元数据• 命名空间管理、锁定• 和chunkservers的周期通信

• 发出指令，状态收集，集群健康追踪



• 发出指令，状态收集，集群健康追踪• Chunk创建、重复制、重平衡

• 在空间和访问速度之间平衡• 传播副本到不同机架，以防⽌止关联失败• 如果副本冗余度低于阀值，重复制• 重新平衡数据来消除存储和请求负载





• 垃圾回收• 简化，相⽐比传统⽂文件删除更可靠• master记录删除，然后重命名⽂文件为隐藏⽂文件(dot file)

• 惰性垃圾回收隐藏⽂文件





• 垃圾回收• 简化，相⽐比传统⽂文件删除更可靠• master记录删除，然后重命名⽂文件为隐藏⽂文件(dot file)

• 惰性垃圾回收隐藏⽂文件• 腐化副本删除

• 使⽤用版本号来删除腐化副本


GFS：Chunkserver


GFS：Chunkserver

• 把64MB⼀一个的chunk当做普通Linux⽂文件存储到本地磁盘，每个chunk都有版本号以及校验和(checksum)


GFS：Chunkserver


• 按照chunk句柄和字节范围读写chunk数据


GFS：Chunkserver



• 复制可配置的chunk数量到其他chunkserver(缺省：3)


GFS：Chunkserver



• 复制可配置的chunk数量到其他chunkserver(缺省：3)

• 不缓存⽂文件数据


GFS: Client


GFS: Client

•使⽤用GFS的客户端API，类似传统⽂文件系统API


GFS: Client


•发出控制请求给master server


GFS: Client



•发送数据请求到chunk servers


GFS: Client




•缓存元数据（时效性）


GFS: Client




•缓存元数据（时效性）•不缓存⽂文件数据


GFS: metadata


GFS: metadata

• 全局metadata保存在master

• ⽂文件和chunk命名空间

• ⽂文件到chunk的映射

• 每个chunk的副本位置


GFS: metadata





• 保存在内存中(≈64Bytes /chunk)

• 快速• 更容易访问


GFS: metadata





• 保存在内存中(≈64Bytes /chunk)

• 快速• 更容易访问

• 通过操作⽇日志持久化来保存关键元数据更新• 在本地磁盘实现持久化• ⽇日志跨节点复制• 利⽤用checkpoint实现快速恢复


Client Read


Client Read

• Client发送给Master:

• read(file name,chunk index)


Client Read



• Master回应:

• chunk ID,chunk version number,locations of replicas


Client Read



• Master回应:


• Client给“最近”的chunk server发出请求

• read(chunk ID,byte range)


Client Read



• Master回应:


• Client给“最近”的chunk server发出请求

• read(chunk ID,byte range)

• Chunk server⽤用数据回应给客户端


Client Write

图例:控制流数据流


Client Write

Client



Client Write

Client Masterstep 1



Client Write

Client Masterstep 1

2



Client Write

Client Master

Secondary Replica A

Primary Replica

Secondary Replica B

step 1

23



Client Write

Client Master

Secondary Replica A

Primary Replica

Secondary Replica B

step 1

23

4



Client Write

Client Master

Secondary Replica A

Primary Replica

Secondary Replica B

step 1

23

4

5



Client Write

Client Master

Secondary Replica A

Primary Replica

Secondary Replica B

step 1

23

4

5

6

6



Client Write

Client Master

Secondary Replica A

Primary Replica

Secondary Replica B

step 1

23

4

5

6

6

7



Client Record Append



• Client提供追加的数据




• GFS原⼦子⽅方式追加到⽂文件

• GFS选择偏移，⼀一般是⽂文件末尾

• ⽀支持并⾏行写




• GFS原⼦子⽅方式追加到⽂文件

• GFS选择偏移，⼀一般是⽂文件末尾

• ⽀支持并⾏行写• Google应⽤用程序重度使⽤用

• 多⽣生产者-单消费者队列


GFS 松散⼀一致性模型

Write Record Append

Serial success defined defined interspersed with inconsistentConcurrent successes consistent but undefined

defined interspersed with inconsistent

Failure inconsistentinconsistent



• “Consistent” = 所有的副本有相同的值

Write Record Append






• “Consistent” = 所有的副本有相同的值

• “Defined” = “Consistent” +可以看到完整变更的数据

Write Record Append





容灾


容灾

• HA

• 快速恢复• master和chunkserver在⼏几秒内重启完毕

• chunk 复制

• 默认3份，不同命名空间可以复制不同版本

• shadow master


容灾

• HA

• 快速恢复• master和chunkserver在⼏几秒内重启完毕

• chunk 复制

• 默认3份，不同命名空间可以复制不同版本

• shadow master

• 数据完整性• 针对chunk，每64KB块做⼀一个checksum


GFS 实例

集群 A B

chunkserver数 342 227

有效磁盘空间已⽤用磁盘空间

72 TB55 TB

180 TB155 TB

⽂文件数⽆无效⽂文件数chunk数

735 k22 k992 k

737 k232 k1550 k

chunkserver上的元数据⼤大⼩小master上的元数据⼤大⼩小

13 GB48 MB

21 GB60 MB

http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google/gfs-sosp2003.pdf13年9⽉月16⽇日星期⼀一

http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google

http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google

Taobao Filesystem


Taobao Filesystem

• 2007年6⽉月创建


Taobao Filesystem

• 2007年6⽉月创建

•⾼高可扩展、⾼高可⽤用、⾼高性能、⾯面向互联⺴⽹网服务


Taobao Filesystem

• 2007年6⽉月创建


•为海量⾮非结构化数据优化


Taobao Filesystem

• 2007年6⽉月创建


•为海量⾮非结构化数据优化•⽀支持海量⼩小⽂文件存储


TFS-动机


TFS-动机

• 系统需求• 淘宝的影响越来越⼤大，数据的安全越来越重要• 数据存储量每年2倍的速度增⻓长


TFS-动机

• 系统需求• 淘宝的影响越来越⼤大，数据的安全越来越重要• 数据存储量每年2倍的速度增⻓长

• 商⽤用存储产品• 对⼩小⽂文件的存储⽆无法优化• ⽂文件数量⼤大，NAS⽆无法⽀支持

• 连接的服务器越来越多，⺴⽹网络连接达到NAS设备极限

• 扩展成本⾼高，10T的存储容量需要上百万⼈人民币

• 单点，容灾和安全性⽆无法得到很好的保证


TFS - 架构

http://code.taobao.org/p/tfs/wiki/intro/




TFS - 特性


TFS - 特性

• 集群由⼀一对NameServer和多台DataServer构成


TFS - 特性


• 以block⽂文件的形式存储数据⽂文件（⼀一般64MB⼀一个block）


TFS - 特性



• block有多个副本


TFS - 特性




• DataServer上⽤用Linux⽂文件系统存储数据⽂文件


TFS - 特性





• non-RAID，每个进程管理⼀一块磁盘


TFS - 特性





• non-RAID，每个进程管理⼀一块磁盘

• ⽂文件名内置元数据信息，⽤用户⾃自⼰己保存TFS⽂文件名与实际⽂文件的对照关系


TFS - ⽂文件名结构


TFS - ⽂文件名结构• ⽂文件名由块号和⽂文件号通过某种关系组成，最⼤大⻓长度18字节



• ⽂文件 = T+[1-9]+encode(<block_id> + <file_id>) + hash(.<suffix>)



• ⽂文件 = T+[1-9]+encode(<block_id> + <file_id>) + hash(.<suffix>)

• ⽂文件名由客户端程序进⾏行编码和解码


Nameserver职责


Nameserver职责

•管理维护Block和DataServer的相关信息


Nameserver职责


•负责Block的创建、删除、复制、均衡、整理


Nameserver职责


•负责Block的创建、删除、复制、均衡、整理

•不负责实际数据的读写


DataServer 职责


DataServer 职责

•负责实际数据的存储和读写


TFS - 元数据


TFS - Read


TFS - Write


TFS - 容灾


TFS - 容灾

• 集群容灾• TFS配置主辅集群，防⽌止不同机房，辅集群提供只读。主集群把所有操作重放到辅集群


TFS - 容灾


• NameServer容灾

• HA架构，使⽤用vip，主从同步


TFS - 容灾


• NameServer容灾

• HA架构，使⽤用vip，主从同步

• DataServer容灾

• Block多副本，跨⺴⽹网段。

• 所有副本写⼊入成功，才返回成功• 有腐化副本，TFS启动复制流程

• 每个⽂文件记录校验CRC


Hadoop Distributed Filesystem

http://hadoop.apache.org/docs/r0.18.0/hdfs_design.pdf





•灵感来⾃自Goole Filesystem




•⾼高容灾特性




•⾼高容灾特性•设计为可部署在廉价硬件上




•⾼高容灾特性•设计为可部署在廉价硬件上•为Apache Hadoop的⼦子项⺫⽬目


HDFS - 架构

!


HDFS - NameNode


HDFS - NameNode

•⼀一个集群中只有⼀一个，简化设计


HDFS - NameNode

•⼀一个集群中只有⼀一个，简化设计•负责管理⽂文件系统的名字空间并协调客户对⽂文件的访问


HDFS - NameNode


•执⾏行⽂文件系统的名字空间操作(create,open,rename)


HDFS - NameNode


•执⾏行⽂文件系统的名字空间操作(create,open,rename)

•管理数据块到数据节点的映射


HDFS - DataNode(s)


HDFS - DataNode(s)

•⼀一个服务节点上部署⼀一个DataNode


HDFS - DataNode(s)


•负责该物理节点上的存储管理


HDFS - DataNode(s)


•负责该物理节点上的存储管理•负责提供客户的读写请求


HDFS - DataNode(s)


•负责该物理节点上的存储管理•负责提供客户的读写请求•根据NameNode的指令执⾏行数据块的创建、删除、复制⼯工作。


HDFS - 数据副本


HDFS - 数据副本

• ⽂文件块通过复制保证容错


HDFS - 数据副本

• ⽂文件块通过复制保证容错• ⽂文件块⼤大⼩小及副本数量可配置


HDFS - 数据副本

• ⽂文件块通过复制保证容错• ⽂文件块⼤大⼩小及副本数量可配置

• 平衡副本位置对读写、⺴⽹网络传输的影响


HDFS -健壮性


HDFS -健壮性

• DataNode磁盘故障，⼼心跳和重复制


HDFS -健壮性


•机群的重平衡


HDFS -健壮性


•机群的重平衡•数据完整性


HDFS -健壮性


•机群的重平衡•数据完整性•元数据磁盘失效


HDFS -健壮性


•机群的重平衡•数据完整性•元数据磁盘失效•快照(将来⽀支持)


Mogile Filesystem


MogileFS 架构

Client(API)

Trackers(mogilefsd)

Storage nodes(mogstored)

Tracker'sdatabase(MySQL)


MogileFS 架构

• 应⽤用层：⽆无需特殊核⼼心组件Client(API)

Trackers(mogilefsd)




MogileFS 架构

• 应⽤用层：⽆无需特殊核⼼心组件

• ⽆无单点失败 Client(API)

Trackers(mogilefsd)




MogileFS 架构


• ⽆无单点失败

• ⾃自动⽂文件复制

Client(API)

Trackers(mogilefsd)




MogileFS 架构




• 传输中⽴立，⽆无特殊协议

Client(API)

Trackers(mogilefsd)




MogileFS 架构





• 简单命名空间

Client(API)

Trackers(mogilefsd)




MogileFS 架构






• Shared-Nothing

Client(API)

Trackers(mogilefsd)




MogileFS 架构






• Shared-Nothing

• non-RAID

Client(API)

Trackers(mogilefsd)




MogileFS 架构






• Shared-Nothing

• non-RAID

• 不能追加写、随机写

Client(API)

Trackers(mogilefsd)




MogileFS 架构






• Shared-Nothing

• non-RAID


• Tracker Client传输(mogilefsd)，管理数据复制、删除、查询、修复以及监控

Client(API)

Trackers(mogilefsd)




MogileFS 架构






• Shared-Nothing

• non-RAID



• 数据通过HTTP/WebDAV服务上传到Storage node(mogstored)

Client(API)

Trackers(mogilefsd)




MogileFS 架构






• Shared-Nothing

• non-RAID




• MySQL 存储MogileFS 元数据（命名空间、位置)

Client(API)

Trackers(mogilefsd)




MogileFS 架构

• 应⽤用层：⽆无需特殊核⼼心组件Client(API)

Trackers(mogilefsd)




MogileFS 架构


• ⽆无单点失败 Client(API)

Trackers(mogilefsd)




MogileFS 架构




Client(API)

Trackers(mogilefsd)




MogileFS 架构





Client(API)

Trackers(mogilefsd)




MogileFS 架构






Client(API)

Trackers(mogilefsd)




MogileFS 架构






• Shared-Nothing

Client(API)

Trackers(mogilefsd)




MogileFS 架构






• Shared-Nothing

• non-RAID

Client(API)

Trackers(mogilefsd)




MogileFS 架构






• Shared-Nothing

• non-RAID


Client(API)

Trackers(mogilefsd)




MogileFS 架构






• Shared-Nothing

• non-RAID



Client(API)

Trackers(mogilefsd)




MogileFS 架构






• Shared-Nothing

• non-RAID




Client(API)

Trackers(mogilefsd)




MogileFS 架构






• Shared-Nothing

• non-RAID




• MySQL 存储MogileFS 元数据（命名空间、位置)

Client(API)

Trackers(mogilefsd)




MogileFS ⾼高可⽤用

http://www.slideshare.net/PhilippeJulio/mogilefs-architecture

0 0'��

Database

Metadata

ActiveClusterNode

PassiveClusterNode 1 2 3 4 5 6 7

Tracker Tracker Tracker Storage Storage Storage Storage

4 Storage Nodes2 Trackers nodes for HA Clusterand more than 2 for Load Balancing




MogileFS Internal

MogileFS

Domain(key的名字空间)

Class(最⼩小复制单元)

http://www.php-oa.com/2010/09/26/perl-mogilefs-3.html13年9⽉月16⽇日星期⼀一

http://www.php-oa.com/2010/09/26/perl-mogilefs-3.html


MogileFS Internal

• Domain

• ⼀一个MogileFS可以有多个Domain，

• ⽤用来存放不同⽂文件（⼤大⼩小、类型）

• 同⼀一个Domain内，可以必须唯⼀一

• 不同Domain内，key可以相同

MogileFS






MogileFS Internal

• Domain





• Class

• ⽂文件属性管理• 定义⽂文件存储在不同设备上的份数

MogileFS






MogileFS Internal

• Domain





• Class

• ⽂文件属性管理• 定义⽂文件存储在不同设备上的份数

• Domain + Fid 定位⽂文件

MogileFS






MogileFS 数据流


MogileFS 数据流

• 应⽤用程序请求打开⼀一个⽂文件 (通过RPC 通知到 tracker, 找到⼀一个可⽤用的机器). 做⼀一个 “create_open” 请求


MogileFS 数据流


• tracker 做⼀一些负载均衡(load balancing)处理，决定应该去哪⼉儿，然后给应⽤用程序⼀一些可能⽤用的位置


MogileFS 数据流



• 应⽤用程序写到其中的⼀一个位置去 (如果写失败，他会重新尝试并写到另外⼀一个位置去）


MogileFS 数据流




• 应⽤用程序通过”create_close” 告诉tracker⽂文件写到哪⾥里去了


MogileFS 数据流





• tracker 将该名称和域命的名空间关联 (通过数据库来做的)


MogileFS 数据流






• tracker, 在后台, 开始复制⽂文件，知道他满⾜足该⽂文件类别设定的复制规则


MogileFS 数据流







• 然后,应⽤用程序通过 “get_paths” 请求 domain+key (key == “filename”) ⽂文件, tracker基于每⼀一位置的I/O繁忙情况回复(在内部经过 database/memcache/etc 等的⼀一些抉择处理), 该⽂文件可⽤用的完整 URLs地址列表.


MogileFS 数据流







• 然后,应⽤用程序通过 “get_paths” 请求 domain+key (key == “filename”) ⽂文件, tracker基于每⼀一位置的I/O繁忙情况回复(在内部经过 database/memcache/etc 等的⼀一些抉择处理), 该⽂文件可⽤用的完整 URLs地址列表.

• 应⽤用程序然后按顺序尝试这些URL地址


Moose Filesystem


MooseFS 特性

• MooseFS可以充当类Unix的⽂文件系统

• 层次结构（⺫⽬目录树）• 存储POSIX⽂文件属性(权限、最后访问时间，修改时间等）

• ⽀支持特殊⽂文件（块设备、字符设备、管道以及套接字）• 符号链接、硬链接• ⽂文件访问可受限于IP地址和(或)密码

• 分布式特性• ⾼高可靠性（数据多副本）• 通过增加节点或者磁盘动态扩容• 惰性⽂文件删除（⽂文件系统级别的垃圾桶）• 提供⼀一致的⽂文件快照，即使⽂文件正在访问或者写⼊入

http://www.moosefs.org/13年9⽉月16⽇日星期⼀一

http://www.moosefs.org/


MooseFS 组件




MooseFS 组件

• Manager Server (master server)

• 单个节点管理整个⽂文件系统，存储所有⽂文件的元数据信息（包括⼤大⼩小、属性、⽂文件位置）




MooseFS 组件



• Data servers (chunk server)

• 任意数量的普通服务器，⽤用于存储⽂文件，并在他们之间进⾏行⽂文件同步（多副本⽤用途）




MooseFS 组件





• Metadata backup server(s) (metalogger server)

• 周期性的从master server下载元数据信息以及changelogs。⽤用于将来master server故障后，恢复




MooseFS 组件





• Metadata backup server(s) (metalogger server)

• 周期性的从master server下载元数据信息以及changelogs。⽤用于将来master server故障后，恢复

• client (mount)

• 使⽤用mfsmount⼯工具挂载MooseFS

• mfsmount基于FUSE机制实现，所以client是可以跨平台的




MooseFS 读⽂文件


MooseFS 写⽂文件


参考资料 (1/2)1. http://www.google.com.hk

2. http://hadoop.apache.org

3. http://www.slideshare.net/quipo/nosql-databases-why-what-and-when

4. http://static.googleusercontent.com/external_content/untrusted_dlcp/gfs-sosp2003.pdf

5. http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf

6. http://en.wikipedia.org/wiki/Google_File_System

7. http://www.ibm.com/systems/software/gpfs

8. http://www.amazon.com/Understanding-Big-Data-Enterprise-ebook/dp/B0069QEHOE

9. http://en.wikipedia.org/wiki/Big_data

10.http://blog.csdn.net/NevePioneer/article/details/3540607

11.http://www.oracle.com/technetwork/server-storage/engineered-systems/exadata/exadata-technical-whitepaper-134575.pdf

12.http://public.dhe.ibm.com/software/cn/downloads/IMW14584CNZH_IBM_Netezza_Data_Appliance_Architecture.pdf

13.http://www.businessinsider.com/cia-presentation-on-big-data-2013-3?op=1


http://www.google.com.hk

http://www.google.com.hk

http://www.wikipedia.org

http://www.wikipedia.org

http://www.slideshare.net/quipo/nosql-databases-why-what-and-when

http://www.slideshare.net/quipo/nosql-databases-why-what-and-when

http://static.googleusercontent.com/external_content/untrusted_dlcp/gfs-sosp2003.pdf

http://static.googleusercontent.com/external_content/untrusted_dlcp/gfs-sosp2003.pdf

http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-

http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-

http://en.wikipedia.org/wiki/Google_File_System

http://en.wikipedia.org/wiki/Google_File_System

http://www.ibm.com/systems/software/gpfs

http://www.ibm.com/systems/software/gpfs

http://www.amazon.com/Understanding-Big-Data-Enterprise-ebook/dp/B0069QEHOE




http://en.wikipedia.org/wiki/Big_data














参考资料 (2/2)


参考资料 (2/2)

14.http://www.nosqlnotes.net/archives/71


http://www.nosqlnotes.net/archives/71


参考资料 (2/2)


15.http://www.importnew.com/3491.html




http://www.importnew.com/3491.html


参考资料 (2/2)



16.http://hadoop.apache.org/docs/r0.18.0/hdfs_design.pdf








参考资料 (2/2)




17.http://datasearch.ruc.edu.cn/course/advancedDataManagement/slides/Lec03.ppt








http://datasearch.ruc.edu.cn/course/advancedDataManagement/slides/Lec03.ppt




参考资料 (2/2)





18.http://www.nosqlnotes.net/wp-content/uploads/Distributed_System_Engineering_Practice.pdf












http://www.nosqlnotes.net/wp-content/uploads/Distributed_System_Engineering_Practice.pdf




参考资料 (2/2)






19.http://www.ece.ubc.ca/~matei/EECE417/googleFS.ppt
















http://www.ece.ubc.ca/~matei/EECE417/googleFS.ppt


参考资料 (2/2)







20.https://code.google.com/p/mogilefs/


















https://code.google.com/p/mogilefs/


参考资料 (2/2)








21.http://www.moosefs.org/






















参考资料 (2/2)








21.http://www.moosefs.org/

22.http://s3.amazonaws.com/ppt-download/12110083hdfspresentedbyvijaypratapsingh-130820030700-phpapp02.odp






















http://s3.amazonaws.com/ppt-download/12110083hdfspresentedbyvijaypratapsingh-130820030700-phpapp02.odp




⼤大数据之分布式⽂文件系统

Why, what and how

好⾖豆⺴⽹网

赵卫国@mlsx

2013-9-14


distributed filesystem

Documents