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/day

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=1

⼤大数据是
+

⼤大数据是
+ +

⼤大数据是
+ +
CTO of CIA

⼤大数据的价值
http://www.mckinsey.com/insights/business_technology/big_data_the_next_frontier_for_innovation

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

美国医疗服务
欧洲公共部门管理
• 每年价值2500亿欧元

美国医疗服务
制造业
• 产品开发、组装成本降
低达50%
• 运⾏行资本降低达7%

美国医疗服务
全球个人位置数据
• 服务提供商收⼊入1000亿美元或以上
• 最终⽤用户价值达7000亿美元
制造业
低达50%

美国医疗服务
美国零售业
• 可能的净利润增⻓长⽔水平为60%或以上
• 0.5~1.0%的年⽣生产率增⻓长
制造业
低达50%

美国医疗服务
美国零售业
• 可能的净利润增⻓长⽔水平为60%或以上
• 0.5~1.0%的年⽣生产率增⻓长
制造业
低达50%
“大数据在政府公共服务、医疗服务、零售业、制造业、以及设计个人位置服务等领域都将带来可
观的价值”
-- 麦肯锡全球研究院

⼤大数据的特征

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

⼤大数据来源

⼤大数据来源
•互联⺴⽹网企业：社交⺴⽹网站、微博客、视频、
电⼦子商务

⼤大数据来源
电⼦子商务
•物联⺴⽹网、移动设备、终端、个⼈人位置、传
感器采集的数据

⼤大数据来源
电⼦子商务
•通信和互联⺴⽹网运⾏行商

⼤大数据来源
电⼦子商务
•通信和互联⺴⽹网运⾏行商
•天⽂文、⽓气象、医疗数据

⼤大数据带来的挑战
http://mmdays.com/wp-content/uploads/2013/03/Bigdata.jpg

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

数据如何存储

传统存储

传统存储
• 问题

传统存储
• 问题
• 纵向扩展受阵列空间限制

传统存储
• 问题
• 横向扩展受交换设备限制

传统存储
• 问题
• 横向扩展受交换设备限制
• 节点受⽂文件系统限制

分布式存储
Interconnection Network
Node 1 Node 1 Node 1...

分布式存储
• 挑战
• 节点间通信
• 数据存储
• 数据空间平衡
• 容错
• ⽂文件系统⽀支持
Interconnection Network
Node 1 Node 1 Node 1...

分布式⽂文件系统设计⺫⽬目标
http://en.wikipedia.org/wiki/Distributed_ﬁle_system#Distributed_ﬁle_systems

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

•访问透明

•访问透明
•位置透明

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

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

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

•访问透明
•位置透明
•并发透明
•失效透明
•硬件透明
•可扩展性

•访问透明
•位置透明
•并发透明
•失效透明
•硬件透明
•可扩展性
•复制透明

•访问透明
•位置透明
•并发透明
•失效透明
•硬件透明
•可扩展性
•复制透明
•迁移透明

⼀一些理论准备
http://tinyurl.com/nqdsayj

CAP理论(Brewer的猜想）
2000 Prof.Eric Brewer,PoDC Conference Keynote
2002 Seth Gilbert and Nancy Lynch ACM SIGACT News 33(2)
http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
http://lpd.epﬂ.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

CAP理论(Brewer的猜想）
2000 Prof.Eric Brewer,PoDC Conference Keynote
2002 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.epﬂ.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

CAP

• ⼀一致性(Consistency)
• 任何⼀一个读操作总能读取到之前完
成的写操作结果
CAP

• 可⽤用性(Availability)
• 每⼀一个操作总是能在确定的时间内
返回
CAP

返回
• 分区可容忍性(Tolerance of network
Partition)
• 在出现⺴⽹网络分区的情况下，仍然能
够满⾜足⼀一致性和可⽤用性
CAP

返回
• 分区可容忍性(Tolerance of network
Partition)
• 在出现⺴⽹网络分区的情况下，仍然能
够满⾜足⼀一致性和可⽤用性
CAP
pick
two
C
A P

分区容忍性-可⽤用性
http://codahale.com/you-cant-sacriﬁce-partition-tolerance/
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)

⼀一致性
• 弱⼀一致性（⽆无保证）- 不⼀一致窗⼝口

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

⼀一致性 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

基于模的哈希
partition
=
key
%
n_servers
N1 N2 N3 N4

基于模的哈希
partition
=
key
%
n_servers
N1 N2 N3 N4
partition
=
key
%
(n_servers
-‐
1)

基于模的哈希
partition
=
key
%
n_servers
N1 N2 N3 N4
partition
=
key
%
(n_servers
-‐
1)
当n_servers改变时，重新计算所有的资源
(i.e 节点改变时，资源需要全部重新分布)

⼀一致哈希
http://en.wikipedia.org/wiki/Consistent_hashing

Ring
(Key space)
02160
⼀一致哈希

Ring
(Key space)
02160
⼀一致哈希
创建⼀一个针对数据以及节点的
hash函数
idx = hash(key)
协调器: 延顺指针⽅方向的第⼀一个有
效节点

Ring
(Key space)
02160
⼀一致哈希
hash函数
idx = hash(key)
效节点
A
E
F
B
CD

Ring
(Key space)
02160
⼀一致哈希
hash函数
idx = hash(key)
效节点
A
E
F
B
CD
节点B hold住节点A
⾄至节点B之间的数据

Ring
(Key space)
02160
⼀一致哈希
hash函数
idx = hash(key)
效节点
A
E
F
CD

Ring
(Key space)
02160
⼀一致哈希
hash函数
idx = hash(key)
效节点
A
E
F
CD
节点C此时hold住
节点A到C之间的数据

Ring
(Key space)
02160
⼀一致哈希
hash函数
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.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.jpg

⼀一致哈希：数据倾斜
Ring
(Key space)
A
B
http://news.shangdu.com/102/20121019/P_5714444_0__297724710.jpg
元芳，此事
你怎么看？
⼤大⼈人，我
看还得赶紧想别
的办法

⼀一致哈希：虚拟节点
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.pdf

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

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

GFS 架构
多节点，将chunk存储为
Linux⽂文件
专⽤用客户端，类似传统⽂文
件系统API，负责和Master以
及Chunkserver通信

GFS: Master

GFS: Master
• 存储元数据

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

GFS: Master
• 存储元数据
• 和chunkservers的周期通信
• 发出指令，状态收集，集群健康追踪

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

GFS: Master
• 存储元数据
• 垃圾回收
• 简化，相⽐比传统⽂文件删除更可靠
• master记录删除，然后重命名⽂文件为隐藏⽂文件(dot file)
• 惰性垃圾回收隐藏⽂文件

GFS: Master
• 存储元数据
• 垃圾回收
• 简化，相⽐比传统⽂文件删除更可靠
• master记录删除，然后重命名⽂文件为隐藏⽂文件(dot file)
• 惰性垃圾回收隐藏⽂文件
• 腐化副本删除
• 使⽤用版本号来删除腐化副本

GFS：Chunkserver

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

GFS：Chunkserver
(checksum)
• 按照chunk句柄和字节范围读写chunk数据

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

GFS：Chunkserver
(checksum)
• 复制可配置的chunk数量到其他chunkserver(缺
省：3)
• 不缓存⽂文件数据

GFS: Client

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

GFS: Client
API
•发出控制请求给master server

GFS: Client
API
•发送数据请求到chunk servers

GFS: Client
API
•缓存元数据（时效性）

GFS: Client
API
•缓存元数据（时效性）
•不缓存⽂文件数据

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 Master
step 1
图例:
控制流
数据流

Client Write
Client Master
step 1
2
图例:
控制流
数据流

Client Write
Client Master
Secondary
Replica A
Primary
Replica
Secondary
Replica B
step 1
2
3
图例:
控制流
数据流

Client Write
Client Master
Secondary
Replica A
Primary
Replica
Secondary
Replica B
step 1
2
3
4
图例:
控制流
数据流

Client Write
Client Master
Secondary
Replica A
Primary
Replica
Secondary
Replica B
step 1
2
3
4
5
图例:
控制流
数据流

Client Write
Client Master
Secondary
Replica A
Primary
Replica
Secondary
Replica B
step 1
2
3
4
5
6
6
图例:
控制流
数据流

Client Write
Client Master
Secondary
Replica A
Primary
Replica
Secondary
Replica B
step 1
2
3
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
interspersed with
defined
interspersed with
inconsistent

• “Consistent” = 所有的副本有相同的值
• “Defined” = “Consistent” +可以看到完整变更的数据
Write Record Append
interspersed with
defined
interspersed with
inconsistent

容灾

容灾
• HA
• 快速恢复
• master和chunkserver在⼏几秒内重启完毕
• chunk 复制
• 默认3份，不同命名空间可以复制不同版本
• shadow master

容灾
• HA
• 快速恢复
• master和chunkserver在⼏几秒内重启完毕
• chunk 复制
• 默认3份，不同命名空间可以复制不同版本
• shadow master
• 数据完整性
• 针对chunk，每64KB块做⼀一个checksum

GFS 实例
集群 A B
chunkserver数 342 227
有效磁盘空间
已⽤用磁盘空间
72 TB
55 TB
180 TB
155 TB
⽂文件数
⽆无效⽂文件数
chunk数
735 k
22 k
992 k
737 k
232 k
1550 k
chunkserver上的元数据⼤大⼩小
master上的元数据⼤大⼩小
13 GB
48 MB
21 GB
60 MB
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google/gfs-sosp2003.pdf

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）
• block有多个副本

TFS - 特性
⼀一个block）
• DataServer上⽤用Linux⽂文件系统存储数据⽂文件

TFS - 特性
⼀一个block）
• non-RAID，每个进程管理⼀一块磁盘

TFS - 特性
⼀一个block）
• non-RAID，每个进程管理⼀一块磁盘
• ⽂文件名内置元数据信息，⽤用户⾃自⼰己保存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's
database
(MySQL)

MogileFS 架构
• 应⽤用层：⽆无需特殊核⼼心组件
Client(API)
Trackers
(mogilefsd)
Storage nodes
(mogstored)
Tracker's
database
(MySQL)

MogileFS 架构
• ⽆无单点失败 Client(API)
Trackers
(mogilefsd)
Storage nodes
(mogstored)
Tracker's
database
(MySQL)

MogileFS 架构
• ⽆无单点失败
• ⾃自动⽂文件复制
Client(API)
Trackers
(mogilefsd)
Storage nodes
(mogstored)
Tracker's
database
(MySQL)

MogileFS 架构
• 传输中⽴立，⽆无特殊协议
Client(API)
Trackers
(mogilefsd)
Storage nodes
(mogstored)
Tracker's
database
(MySQL)

MogileFS 架构
• 简单命名空间
Client(API)
Trackers
(mogilefsd)
Storage nodes
(mogstored)
Tracker's
database
(MySQL)

MogileFS 架构
• Shared-Nothing
Client(API)
Trackers
(mogilefsd)
Storage nodes
(mogstored)
Tracker's
database
(MySQL)

MogileFS 架构
• Shared-Nothing
• non-RAID
Client(API)
Trackers
(mogilefsd)
Storage nodes
(mogstored)
Tracker's
database
(MySQL)

MogileFS 架构
• Shared-Nothing
• non-RAID
• 不能追加写、随机写
Client(API)
Trackers
(mogilefsd)
Storage nodes
(mogstored)
Tracker's
database
(MySQL)

MogileFS 架构
• Shared-Nothing
• non-RAID
• Tracker Client传输(mogilefsd)，管理
数据复制、删除、查询、修复以及
监控
Client(API)
Trackers
(mogilefsd)
Storage nodes
(mogstored)
Tracker's
database
(MySQL)

MogileFS 架构
• Shared-Nothing
• non-RAID
监控
• 数据通过HTTP/WebDAV服务上传到
Storage node(mogstored)
Client(API)
Trackers
(mogilefsd)
Storage nodes
(mogstored)
Tracker's
database
(MySQL)

MogileFS 架构
• Shared-Nothing
• non-RAID
监控
• 数据通过HTTP/WebDAV服务上传到
Storage node(mogstored)
• MySQL 存储MogileFS 元数据（命名
空间、位置)
Client(API)
Trackers
(mogilefsd)
Storage nodes
(mogstored)
Tracker's
database
(MySQL)

MogileFS ⾼高可⽤用
http://www.slideshare.net/PhilippeJulio/mogilefs-architecture
0 0'
Database
Metadata
Active
Cluster
Node
Passive
Cluster
Node
1 2 3 4 5 6 7
Tracker Tracker Tracker Storage Storage Storage Storage
4 Storage Nodes
2 Trackers nodes for HA Cluster
and more than 2 for Load Balancing

MogileFS Internal
MogileFS
Domain(key的名字空间)
Class(最⼩小复制单元)
http://www.php-oa.com/2010/09/26/perl-mogilefs-3.html

MogileFS Internal
• Domain
• ⼀一个MogileFS可以有多个
Domain，
• ⽤用来存放不同⽂文件（⼤大
⼩小、类型）
• 同⼀一个Domain内，可以必
须唯⼀一
• 不同Domain内，key可以
相同
MogileFS

MogileFS Internal
• Domain
Domain，
⼩小、类型）
须唯⼀一
相同
• Class
• ⽂文件属性管理
• 定义⽂文件存储在不同设备
上的份数
MogileFS

MogileFS Internal
• Domain
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/

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

参考资料 (2/2)

参考资料 (2/2)
14.http://www.nosqlnotes.net/archives/71

参考资料 (2/2)
15.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

参考资料 (2/2)
slides/Lec03.ppt
18.http://www.nosqlnotes.net/wp-content/uploads/
Distributed_System_Engineering_Practice.pdf

参考资料 (2/2)
slides/Lec03.ppt
19.http://www.ece.ubc.ca/~matei/EECE417/googleFS.ppt

参考资料 (2/2)
slides/Lec03.ppt
20.https://code.google.com/p/mogilefs/

参考资料 (2/2)
slides/Lec03.ppt
21.http://www.moosefs.org/

参考资料 (2/2)
slides/Lec03.ppt
21.http://www.moosefs.org/
22.http://s3.amazonaws.com/ppt-download/
12110083hdfspresentedbyvijaypratapsingh-130820030700-phpapp02.odp

Distributed filesystem

Recommended

Recommended

More Related Content

Featured

Featured (20)

Distributed filesystem