共计 3165 个字符，预计需要花费 8 分钟才能阅读完成。
在分析 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 提供怎么样的读一致性?
相关阅读：
将本地文件拷到 HDFS 中 http://www.linuxidc.com/Linux/2013-05/83866.htm
从 HDFS 下载文件到本地 http://www.linuxidc.com/Linux/2012-11/74214.htm
将本地文件上传至 HDFS http://www.linuxidc.com/Linux/2012-11/74213.htm
HDFS 基本文件常用命令 http://www.linuxidc.com/Linux/2013-09/89658.htm
Hadoop 中 HDFS 和 MapReduce 节点基本简介 http://www.linuxidc.com/Linux/2013-09/89653.htm
《Hadoop 实战》中文版 + 英文文字版 + 源码【PDF】http://www.linuxidc.com/Linux/2012-10/71901.htm
Hadoop: The Definitive Guide【PDF 版】http://www.linuxidc.com/Linux/2012-01/51182.htm
更多 Hadoop 相关信息见Hadoop 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=13
