hadoop中什么样的JBOD？和 COW 与 hadoop？

Question

刚接触hadoop，只设置了3个debian服务器集群来练习。

我在研究 hadoop 的最佳实践时遇到了： JBOD 无 RAID 文件系统：ext3、ext4、xfs - 没有你在 zfs 和 btrfs 中看到的那些花哨的 COW 东西

所以我提出这些问题...

---

我在任何地方读到 JBOD 都比 hadoop 中的 RAID 好，最好的文件系统是 xfs 和 ext3 和 ext4。除了文件系统的东西，这完全有道理，为什么那些是最好的......你如何实现这个 JBOD？如果你自己进行谷歌搜索，你会看到我的困惑，JBOD 暗示了一个线性附件或只是一堆磁盘的组合，有点像逻辑卷，至少有些人是这样解释的，但 hadoop 似乎想要一个不结合的 JBOD。没有人在这上面展开...

• 问题 1) Hadoop 世界中的每个人都对 JBOD 意味着什么？您如何实现它？
• 问题 2) 是不是就像把每个磁盘挂载到不同的目录一样简单？
• 问题 3) 这是否意味着 hadoop 在 JBOD 上运行最好，其中每个磁盘都简单地挂载到不同的目录？

• 问题 4）然后您只需将 hadoop 指向那些 data.dirs？

• 问题5) 我看到 JBODS 有两种方式，要么每个磁盘单独挂载，要么磁盘线性连接，可以通过 mdadm --linear 模式完成，或者 lvm 我打赌也可以，所以我看不出有什么大不了的那...如果是这种情况，可以使用 mdadm --linear 或 lvm 因为JBOD人们指的是磁盘的连接，那么这是“JBOD”或hadoop线性连接磁盘的最佳方法？

---

这是题外话，但是有人可以验证这是否正确吗？使用cow，写时复制的文件系统，如zfs和btrfs只会减慢hadoop，但不仅cow实现对hadoop来说是浪费。

• 问题 6) 为什么 COW 和 RAID 之类的东西在 hadoop 上是一种浪费？ 我认为它好像您的系统崩溃了，并且您使用 if 来恢复它，当您恢复系统时，hdfs 已经发生了如此多的更改，它可能只会认为那台机器有故障，最好从头开始重新加入它（将它作为一个新的数据节点启动）......或者hadoop系统将如何看到旧的数据节点？我的猜测是它不会认为它是旧的或新的，甚至是数据节点，它只会将其视为垃圾...... Idk......

• 问题 7) 如果 hadoop 发现一个数据节点从集群中脱落，然后该数据节点重新上线，数据稍旧，会发生什么情况？数据必须有多旧？这个题目怎么样？

---

重新提出问题 1 到 4

• 我刚刚意识到我的问题是如此简单，但我很难解释它，我不得不将它分成 4 个问题，但我仍然没有得到我正在寻找的答案，来自听起来像是非常聪明的人，所以我必须以不同的方式重新询问..

• 在纸上我可以轻松地或通过绘图...我会再次尝试用文字..

• 如果对我在 JBOD 问题中提出的问题感到困惑...

• ** 只是想知道大家在 hadoop 世界中一直提到的 JBOD 是什么类型的都是 **

• JBOD 与 hadoop 的定义不同，然后在正常世界中，我想知道实现 hadoop 的最佳方法是在 jbods(sda+sdb+sdc+sdd) 的 concat 上如何实现，或者只保留磁盘(sda,sdb,sdc,sdd)

• 我认为下面的图形表示最能解释我的要求

（JBOD 方法 1）

• 普通世界：jbod 是磁盘的串联 - 如果您要使用 hadoop，您会将 data.dir（hdfs 虚拟站点所在的位置）覆盖到此磁盘串联内的目录上，以及所有磁盘将显示为 1... 因此，如果您将 sda 和 sdb 和 sdc 作为节点中的数据磁盘，您将使 em 显示为某个实体 1（使用主板的硬件或 mdadm 或 lvm），这是一个线性 concat sda 和 sdb 和 sdc。然后，您可以将此 entity1 挂载到 Unix 命名空间中的文件夹，例如 /mnt/jbod/，然后设置 hadoop 以在其中运行。

• 文本摘要：如果磁盘 1 和磁盘 2 和磁盘 3 分别为 100gb 和 200gb 和 300gb，那么这个 jbod 将是 600gb 大，来自这个节点的 hadoop 将获得 600gb 的容量

  李>

* TEXTO-GRAPHICAL OF LINEAR CONCAT OF DISKS BEING A JBOD: * disk1 2 and 3 used for datanode for hadoop * disk1 is sda 100gb * disk2 is sdb 200gb * disk3 is sdc 300gb * sda + sdb + sdc = jbod of name entity1 * JBOD MADE ANYWAY - WHO CARES - THATS NOT MY QUESTION: maybe we made the jbod of entity1 with lvm, or mdadm using linear concat, or hardware jbod drivers which combine disks and show them to the operating system as entity1, it doesn't matter, either way its still a jbod * This is the type of JBOD I am used to and I keep coming across when I google search JBOD * cat /proc/partitions would show sda,sdb,sdc and entity1 OR if we used hardware jbod maybe sda and sdb and sdc would not show and only entity1 would show, again who cares how it shows * mount entity1 to /mnt/entity1 * running "df" would show that entity1 is 100+200+300=600gb big * we then setup hadoop to run its datanodes on /mnt/entity1 so that datadir property points at /mnt/entity1 and the cluster just gained 600gb of capacity

..另一个视角是这个..

（JBOD 方法 2）

• 在 hadoop 中，在我看来，他们希望每个磁盘都是分开的。因此，我会将 unix 命名空间中的磁盘 sda 和 sdb 和 sdc 挂载到 /mnt/a 和 /mnt/b 和 /mnt/c ......从网上阅读看来，许多 hadoop 专家将 jbods 归类为只是一个一堆磁盘，所以对于 unix，它们看起来像磁盘而不是磁盘的连接......然后当然我可以结合成为一个实体，或者使用逻辑卷管理器（lvm）或 mdadm（以 raid 或线性方式， jbod 首选线性）......但是......不，我们不要将它们组合起来，因为在 hadoop 世界中，jbod 似乎只是它们自己坐在一堆磁盘......

  李>

• 如果磁盘 1 和磁盘 2 和磁盘 3 分别为 100gb 和 200gb 和 300gb，则每个挂载 disk1->/mnt/a 和 disk2->/mnt/b 和 disk3->/mnt/c 将每个分别为 100gb 和 200gb 和 300gb 大，来自该节点的 hadoop 将获得 600gb 容量

TEXTO-GRAPHICAL OF LINEAR CONCAT OF DISKS BEING A JBOD * disk1 2 and 3 used for datanode for hadoop * disk1 is sda 100gb * disk2 is sdb 200gb * disk3 is sdc 300gb * WE DO NOT COMBINE THEM TO APPEAR AS ONE * sda mounted to /mnt/a * sdb mounted to /mnt/b * sdc mounted to /mnt/c * running a "df" would show that sda and sdb and sdc have the following sizes: 100,200,300 gb respectively * we then setup hadoop via its config files to lay its hdfs on this node on the following "datadirs": /mnt/a and /mnt/b and /mnt/c.. gaining 100gb to the cluster from a, 200gb from b and 300gb from c... for a total gain of 600gb from this node... nobody using the cluster would tell the difference..

问题摘要

** 大家指的哪个方法是hadoop的BEST PRACTICE这个组合jbod还是磁盘分离 - 根据在线文档，这仍然是一个jbod？ **

• 这两种情况都将获得 hadoop 600gb...它只是 1。看起来像一个 concat 或一个实体，它是所有磁盘的组合，我一直认为这是一个 jbod...或者它会像 2系统中的每个磁盘都挂载到不同的目录，最终结果与 hadoop 容量方面的结果都是一样的......只是想知道这是否是提高性能的最佳方式

Answer 1

我可以尝试回答几个问题 - 如果您不同意，请告诉我。

1.JBOD：只是一堆磁盘；驱动器阵列，每个驱动器都作为独立驱动器直接访问。 来自 Hadoop Definitive Guide 的主题 Why not use RAID? 表示 RAID 读写性能受到阵列中最慢磁盘的限制。 此外，在 HDFS 的情况下，数据复制发生在驻留在不同机架中的不同机器上。即使机架发生故障，这也可以处理潜在的数据丢失。所以，RAID 没那么必要。 Namenode 可以使用链接中提到的 RAID。

2.是这意味着独立磁盘 (JBOD) 安装在每台机器上（例如 /disk1、/disk2、/disk3 等）但未分区。

3、4 和 5 阅读附录

6 & 7. Check this link 看看如何复制块

评论后的补充：

第一季度。大家指的哪个方法是hadoop这种组合jbod的BEST PRACTICE还是磁盘分离-根据在线文档这仍然是一个jbod？

可能的答案： 来自 Hadoop 权威指南 -

您还应该设置 dfs.data.dir 属性，该属性指定一个列表 数据节点存储其块的目录。不像 namenode，它使用多个目录进行冗余，一个datanode 循环写入在它的存储目录之间，所以对于 性能你应该为每个本地指定一个存储目录 磁盘。读取性能也受益于拥有多个磁盘 存储，因为块将分布在它们之间，并且并发 对不同块的读取将相应地分布在磁盘上。

为了获得最佳性能，您应该使用 noatime 选项。此设置表示上次访问时间信息 不会写入文件读取，从而显着提高性能。

第二季度。为什么 LVM 不是一个好主意？

避免在 TaskTracker 和 DataNode 机器上使用 RAID 和 LVM——通常 降低性能。

这是因为 LVM 在机器中的各个挂载磁盘上创建了逻辑层。

Check this link 获取提示 1 更多详情。在某些用例中，运行 Hadoop 作业时使用 LVM 执行速度很慢。

Answer 2

我迟到了，但也许我可以插话：

JBOD

问题 1) hadoop 世界中的每个人都对 JBOD 意味着什么？您如何实现它？

只是一堆磁盘...您只需格式化整个磁盘并将其包含在数据节点上的“hdfs-site.xmlandmapred-site.xmloryarn-site-xml”中。 Hadoop 负责跨磁盘分配块。

问题2）是否就这么简单，把每个磁盘挂载到不同的目录就可以了？

是的。

问题 3）这是否意味着 hadoop 在 JBOD 上运行最好，其中每个磁盘都简单地挂载到不同的目录？

是的。 Hadoop 对数据进行校验和并定期验证这些校验和。

问题 4）然后您只需将 hadoop 指向那些 data.dirs？

没错。但是有用于数据存储 (HDFS) 和计算（MapReduce、YARN、..）的目录，您可以为某些任务配置不同的目录和磁盘。

问题 5）我看到 JBODS 有两种方式，每个磁盘单独挂载，或者磁盘的线性连接，可以通过 mdadm --linear 模式完成，或者 lvm 我敢打赌也可以，所以我看不出有什么大不了的......如果是这样的话，可以使用 mdadm --linear 或 lvm 因为JBOD人们指的是这个磁盘连接，那么这是“JBOD”的最佳方式或hadoop 的线性连接磁盘？

问题是磁盘有问题。如果您保持简单并且一次只安装每个磁盘，则只需更换此磁盘。如果您在 ja JBOD 配置中使用 mdadm 或 LVM，您很容易丢失更多数据，以防磁盘死机，因为条带或连续配置可能无法在磁盘故障中幸存下来。随着更多块的数据分布在多个磁盘上。

问题 6) 为什么 COW 和 RAID 之类的东西在 hadoop 上是一种浪费？我认为它好像您的系统崩溃了，并且您使用 if 来恢复它，当您恢复系统时，hdfs 已经发生了如此多的更改，它可能只会认为那台机器有故障，最好从头开始重新加入它（将它作为一个新的数据节点启动）......或者hadoop系统将如何看到旧的数据节点？我的猜测是它不会认为它是旧的或新的，甚至是数据节点，它只会将其视为垃圾...... Idk......

HDFS 是原生文件系统之上的一个独立层。磁盘故障是意料之中的，这就是为什么所有数据块在多台机器上至少复制 3 次的原因。 HDFS 也进行自己的校验和，因此如果块的校验和不匹配，则使用该块的副本，并且 HDFS 将删除损坏的块。

所以理论上对 Hadoop 驱动器使用 RAID 或 COW 是没有意义的。

如果您必须处理无法立即更换的故障磁盘，这可能是有意义的。

问题 7）如果 hadoop 发现一个数据节点从集群中掉下来，然后该数据节点重新上线，数据稍微旧一点，会发生什么？数据必须有多旧？这个题目怎么样？

NameNode 有一个块列表及其在数据节点上的位置。每个块都有一个校验和和位置。如果集群中的一个数据节点出现故障，名称节点会将这个数据节点的块复制到其他数据节点。

如果一个较旧的数据节点上线，它会将它的块列表发送到 NameNode，并且根据已经复制的块的数量，它将删除该数据节点上不需要的块。

数据的年龄并不重要，它只与块有关。如果 NameNode 仍然维护这些块并且 datanode 有它们，它们将被再次使用。

ZFS/btrfs/COW

理论上，Hadoop 不需要这些文件系统提供的附加功能。但是，由于您通常使用便宜且巨大的 4TB+ 桌面驱动器来存储数据节点，因此如果这些磁盘开始出现故障，您可能会遇到问题。

ext4 在失败时以只读方式重新挂载自己，此时您将看到磁盘从数据节点上的 HDFS 中退出，它被配置为松动驱动器，或者如果不允许出现磁盘故障，您将看到数据节点死亡.这可能是一个问题，因为现代驱动器经常出现 一些 坏扇区，但在大多数情况下仍能正常运行，并且 fsck 磁盘并重新启动数据节点需要大量工作。

另一个问题是通过 YARN/MapReduce 进行的计算。它们还会在磁盘上写入中间数据，如果这些数据损坏或无法写入，您将遇到错误。我不确定 YARN/MapReduce 是否也校验了它们的临时文件——我认为它是通过实现的。

ZFS 和 btrfs 为现代驱动器上的这种错误提供了一些弹性，因为它们能够更好地处理损坏的元数据并避免由于内部校验和而导致冗长的 fsck 检查。

我正在 ZFS 上运行一个 Hadoop 集群（只是带有 LZ4 的 JBOD），其中有很多磁盘显示出一些坏扇区并且超出了保修范围，但仍然运行良好，尽管有这些错误，它仍然可以正常工作。

如果您可以立即更换有故障的磁盘，那也没关系。如果您需要使用部分损坏的磁盘，ZFS/btrfs 会在更换磁盘之前为您争取一些时间。

不需要 COW，因为 Hadoop 负责复制和安全性。如果您将未压缩的数据存储在集群上，压缩会很有用。 ZFS 中的 LZ4 不应该提供性能损失，并且可以加速顺序读取（就像 HDFS 和 MapReduce 一样）。

性能

反对 RAID 的情况是，至少 MapReduce 实现了类似的东西。HDFS 可以同时读取和写入所有磁盘，并且通常多个 map 和 reduce 作业正在运行，它们可以使用整个磁盘来写入和读取数据.

如果您将 RAID 或条带化置于 Hadoop 之下，这些作业都必须将它们的读取和写入排队到单个 RAID 控制器，总体而言它可能会更慢。

根据您的工作，将 RAID-0 之类的东西用于磁盘对可能是有意义的，但请务必首先确认顺序读取或写入确实是您工作的瓶颈（而不是网络、HDFS 复制、CPU , ..) 但首先要确保你所做的事情是值得的工作和麻烦。