深入浅出Hadoop之HDFS

166次阅读

共计 4296 个字符，预计需要花费 11 分钟才能阅读完成。

Hadoop 生态系统一直是大数据领域的热点，其中包括今天要聊的 HDFS，和计划以后想聊的 yarn, mapreduce, spark, hive, hbase, 已经聊过的 zookeeper，等等。

深入浅出 Hadoop 之 HDFS

今天主聊 HDFS，hadoop distributed file system, 起源于 Google 的 GFS，只不过 GFS 是用 c ++ 写的，Hadoop 是 Doug Cutting 在 yahoo 用 Java 写的。2008 年 Hadoop 成为 Apache top-level project。

HDFS 适用于什么场景呢？非常大的文件存储，比如以 G 或 T 为单位，因为 HDFS 内部的 block 的基本单位已经是 128MB。注意这里有一个小文件问题，误区是说怕 1K 的小文件也能占用 128MB 的硬盘，其实不是的，它还是占用 1K 硬盘，但是小文件问题的 bottle neck 是在 name node 里，因为 name node 要存储文件和 block 的相关信息在内存里，文件数量一多，name node 的内存就不够了（比如，百万小文件要占用 300MB 内存），当然 hdfs federation 能够通过 sharding 的方式解决 name node 内存不够用的问题，接下来会细说。HDFS 还适用于“write once，read-many”的场景，而且它的写是 append only，所以想改也没法改。如果是多次写的话，应该考虑一下 cassandra（参见我的上一篇文章）。同时 HDFS 的文件通常只能允许 single writer 写入（是通过 lease 的方式来保证只有一个 writer 能够当前写某个文件）。HDFS 因为只需要普通的 commodity hardware 而不需要昂贵的高可用硬件而被企业欢迎。HDFS 不适用于需要 low latency 的数据访问方式，因为 HDFS 是拿延迟交换高 throughput。

HDFS 里，文件是被分割成 block 大小的 chunk，每个 block 是 128MB，有人会问了，为什么非要搞这么大，主要是要缩短寻道时间在总硬盘读写时间中的比例，比如寻道时间需要 5 ms，而寻到时间只能占总时间 0.5% 的比例，那么硬盘读写时间差不多在 1s 左右，1s 中能穿多少文件呢，如果硬盘的读写为 128MB/s，那么就能传 128MB，所以 block 大小就定义为 128MB，这样可以保证硬盘操作的时间有效的应用在读写上而不是花费在寻道上。当然太大了也不行，mapreduce 的 map 通常是以 block 为单位，如果 block 太少，mapreduce 的效率会比较低。

hdfs fsck $path -files -blocks -locations

上面的命令可以用来提供文件的 block 信息，比如 block 在哪台机器，名字是什么，方便你进一步查询 block 的具体信息。

深入浅出 Hadoop 之 HDFS

namenode 管理 namespace，管理文件系统树状结构和文件/目录的 metadata，这些信息以如下方式持久化在硬盘里：namespace image 和 edit log。同时 block 的 metadata 也存放在 namd node，存放于内存中。前面提到过百万小文件，会占用 300MB 内存的例子。block 信息为什么不持久化呢，因为它会变动，系统重启的时候会从 datanode 那里重新构建。

name node 的备份有几种方式，一种是把持久化存放于硬盘的信息既写到本地硬盘也同时写到远程 NFS mount。另一种方式是运行 secondary namenode，它其实并没有扮演 namenode 的角色，而是周期性的 merge namesapce image 以及 edit log 来防止 edit log 过大。它会保存一份 merged namespace image，一旦 primary fail 了，就把 NFS 上的 metadata copy 到 secondary namenode 上，这样 secondary 就成为了新的 primary。

具体过程如下图所示，edit log 和 fsimage 都是在硬盘中，edit log 就是 WAL（cassandra 写操作也用到了 WAL 的手段，WAL 很流行，可以单拉出来讲一次），fsimage 是 check point of the filesystem metadata。写的时候先写 edit log，然后 update in-memory representation of filesystem metadata（用来 serve 读请求），图中没有画出这部分操作。

深入浅出 Hadoop 之 HDFS

有没有更好的方法呢？上述方法没能提供 HA，namenode 仍然是 single point of failure。新的 primary 需要（1）load namespace image into memory（2）replay edit log（3）从 datanode 那边接收足够的 block reports（前文提到 block 信息是在内存中的）。这个过程有可能会话费 30 分钟或更久。client 等不了啊～～

Hadoop 2 提供了 HA 的 support。namenode 采用 active-standby 的配置方式：

namenodes 使用高可用共享存储来存 edit log。active 每次写入都会被 standby 读出并 synchronize 到自己的内存中。
datanodes 在发送 block reports 时会同时发给所有的 name nodes，记住 block mapping 是在内存中。
客户端需要配置来 handle namenode failover，其实就是 watch zookeeper 的 leader election（参见我之前讲的 zookeeper）
这样就不需要 secondary namenode 啦，standby 取代了它的作用会周期性的产生 check points

上面提到的共享存储主要指的是 QJM（quorum journal manager），通常配置 3 个（当然我也见过 50 个 node 配 5 个 journal nodes），写的时候需要满足 quorum。

这样当 active namenode fail 时，standby 可以马上扛住，因为 latest edit log 和 up-to-date block mapping 都在内存中。

深入浅出 Hadoop 之 HDFS

touch test.txt
hdfs dfs -mkdir /user/qingge/testdir
hdfs dfs -copyFromLocal ./test.txt /user/qingge/testdir/
hdfs dfs -ls /user/qingge/testdir/test.txt
hdfs dfs -chmod o-r /user/qingge/testdir/test.txt hdfs dfs -cat /user/qingge/testdir/test.txt | head -10
hdfs dfs -mv /user/qingge/testdir/test.txt /user/qingge/testdir/test2.txt

hdfs fsck /data/lalala -files -blocks -locations
hdfs fsck -blockId blk_10101010