【问题标题】:Why doesn't Hadoop file system support random I/O?为什么 Hadoop 文件系统不支持随机 I/O?
【发布时间】:2011-08-11 18:45:17
【问题描述】:

像 Google File System 和 Hadoop 这样的分布式文件系统不支持随机 I/O。
(不能修改之前写入的文件,只能写入和追加。)

他们为什么要设计这样的文件系统?
该设计的重要优势是什么?

P.S 我知道 Hadoop 将支持修改写入的数据。
但是他们说,它的性能会很不好。为什么?

【问题讨论】:

  • 如果您针对一种特定情况进行优化,您希望该情况更快。未考虑的事情可能会在性能上受到影响。例如,我曾经用 Java 编写了一个 RowSet 实现,它对 CSV 文件进行操作。我需要在那里进行随机访问,并且在查找文件的最后一行时大约比只能向前读取的 BufferedReader 慢四倍。

标签: file-io filesystems hadoop distributed-system gfs


【解决方案1】:

Hadoop 分发和复制文件。由于文件被复制,任何写操作都必须在网络上找到每个复制的部分并更新文件。这将大大增加操作时间。更新文件可能会超过块大小,并需要将文件分成 2 个块,然后复制第 2 个块。我不知道内部结构以及它何时/如何拆分一个块......但这是一个潜在的并发症。

如果已经更新并重新运行的作业失败或被杀死怎么办?它可以多次更新文件。

在分布式系统中不更新文件的好处是当你更新文件时你不知道还有谁在使用它,你不知道这些片段存储在哪里。存在潜在的超时(带有块的节点无响应),因此您最终可能会得到不匹配的数据(同样,我不知道 hadoop 的内部结构,并且可能会处理节点关闭的更新,这只是我正在集思广益)

在 HDFS 上更新文件存在很多潜在问题(上面列出了一些)。它们都不是不可克服的,但它们需要性能影响来检查和解释。

由于 HDFS 的主要目的是存储用于 mapreduce 的数据,因此行级更新在此阶段并不那么重要。

【讨论】:

    【解决方案2】:

    我认为这是因为数据的块大小和 Hadoop 的整体理念是您不移动数据,而是将算法移动到数据中。

    Hadoop 专为数据的非实时批处理而设计。如果您正在寻找在响应时间和随机访问方面实现更像传统 RDBMS 的方法,请查看基于 Hadoop 构建的 HBase

    【讨论】:

    • 对,MapReduce 不需要随机访问。它不符合范式。
    猜你喜欢
    • 2012-06-13
    • 2015-08-31
    • 2021-06-29
    • 2010-09-27
    • 1970-01-01
    • 2012-06-09
    • 1970-01-01
    • 2015-01-17
    • 1970-01-01
    相关资源
    最近更新 更多