HDFS的一致性分析

这篇文章去年4月左右写的, 一直留在我的草稿箱, 一直没有写完

在分析HDFS的一致性之前, 我们先得解决HDFS客户端行为的几个问题。

1. 为什么HDFS不支持多个writer同时写一个文件,即不支持并发写?
首先谈一谈HDFS产生的历史。HDFS是根据Google的GFS论文所实现的, 初期时它的主要设计目标是为了存储MapReduce所操作的大型数据集。我们知道在Hadoop中, 每道Mapreduce作业的写操作一般发生在reduce阶段(如果是只含map的作业,则在map阶段)。一般情况下, 各个reducer的结果将分别写入一个HDFS文件当中。此处可能会产生一个疑问: 为什么不是所有reducer的结果写入同一个HDFS文件呢? 显然, 多个reducer对同一文件执行写操作,即多个writer同时向HDFS的同一文件执行写操作, 这需要昂贵的同步机制不说, 最重要的是这种做法将各reducer的写操作顺序化, 不利于各reduce任务的并行。 因此, HDFS没有必要支持多个writer, 单个writer就可以满足Hadoop的需要。

2. 为什么HDFS在后期加上了对文件追加(append)操作的支持?
我们知道HDFS在0.19.0版以前是不支持文件追加操作的。HDFS设计文档上写着: HDFS的应用程序需要对文件实行一次性写,多次读的访问模式。文件一旦建立,然后写入,关闭, 不需要再更改。这样的假定简化了数据一致性问题并使高数据吞吐量成为可能。MapReduce程序或者网络爬虫程序就很适合使用这样的模型。当然未来计划支持增量写。
https://issues.apache.org/jira/browse/HADOOP-1700
http://lucene.472066.n3.nabble.com/HDFS-appending-writes-status-td648274.html#a648274

3. 为什么追加操作也只能是单个writer?
社区有人希望HDFS能实现原子追加操作, 因为GFS实现了原子追加。但Owen O'malley认为原子追加对于文件系统的设计和文件系统的用户接口来说,都不是件好事。而且, 他们(指Google)在MapReduce之前就已经给GFS加上了原子追加操作。编写MapReduce可以比使用原子追加更好地服务于大多数应用程序。Owen O'malley原文:"My personal inclination is that atomic append does very bad things to both the design of the file system and the user interface to the file system. Clearly they added atomic append to GFS before they had MapReduce. It seems like most applications would be better served by implementing in MapReduce rather than using atomic append anyways..."

以下是对Google工程师关于GFS2.0设计的一段采访问内容
http://queue.acm.org/detail.cfm?id=1594206
QUINLAN At the time, [RecordAppend] must have seemed like a good idea, but in retrospect I think the consensus is that it proved to be more painful than it  was worth. It just doesn't meet the expectations people have of a file system, so they end up getting surprised. Then they had to figure out work-arounds.
那时候,记录追加看上去像是一个不错的主意, 但是回顾以往,我们达成这样的一致: 事实证明它带来的痛苦比带来的好处多。它不符合文件系统用户的期望,所以


MCKUSICK In retrospect, how would you handle this differently?

QUINLAN I think it makes more sense to have a single writer per file.

MCKUSICK All right, but what happens when you have multiple people wanting to append to a log?
好的,  那多个用户需要追加一个日志怎么办?

QUINLAN You serialize the writes through a single process that can ensure the replicas are consistent.
你序列化写操作至单个进程,此进程可以确保副本是保持一致的。

4. 像HDFS这种应用,在一致性上要保证的是什么?
HDFS作为一个文件系统,应当保证文件内容的顺序性.



HDFS加上追加操作会给一致性带来哪些挑战?
在特定时间里,文件最末块的各副本可能会有不同的字节数。HDFS要提供什么样的读一致，以及怎么保证一致性,即使碰到故障。

HDFS的一致性基础

当客户端读取某DataNode上的副本时，此DataNode并不会让其所有接收到的字节对客户端可见。
每个RBW副本维持两个计数器：
1. BA: 下游DataNode已经应答的字节数。即DataNode使其对任何reader可见的那些字节。以下，我们可以用副本的可见长度代指它。
2. BR: 为此块接收到的字节数，包括已经写入至块文件的字节以及缓存在DataNode的字节。
假设初始时管线内所有DataNode有(BA, BR) = (a, a)。则客户端向管线推入一个b字节的包并且在客户端没收到此包的应答之前不向管线推入其它包，有：
1. 完成1.a后, DataNode将其(BA, BR)变为(a, a+b)
2. 完成3.a后, DataNode将其(BA, BR)变为(a+b, a+b).
3. 当代表操作成功的应答发回客户端时，管线上的所有DataNode都有(BA, BR) = (a+b, a+b).
一条具有N个DataNode管线，DN0, …, DNi, …,DNN-1。其中DN0代表管线上的第一个DataNode，即最接近writer的那个DataNode，它在任意指定时间t都有如下属性：



HDFS提供怎么样的写一致性?


HDFS提供怎么样的读一致性?

评论

1 楼 langyu 2011-08-25  

我觉着HDFS的这些业务特征还是由GFS的两条设计需求来决定的：1.大文件。2. 写一次读多次。最终目标目的还是为了大文件的高吞吐量。

而HDFS是开源实现，规避了GFS由DN主导的lease机制，我觉着可能是实现起来太复杂了吧。