File io 为什么'；Hadoop文件系统是否支持随机I/O？

像Google文件系统和Hadoop这样的分布式文件系统不支持随机I/O。
（它无法修改以前写入的文件。只能写入和追加。）

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

另外，我知道Hadoop将支持修改写入的数据。

---

但他们说，它的性能将非常不好。为什么？

我认为这是因为数据的块大小，而Hadoop的整个思想是不移动数据，而是将算法移动到数据中

---

Hadoop是为数据的非实时批处理而设计的。如果您正在寻找在响应时间和随机访问方面更像传统RDBMS的实现方法，那么可以看看哪个是构建在Hadoop之上的。

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

如果已经更新并重新运行的作业失败或被终止，该怎么办？它可以多次更新该文件

在分布式系统中不更新文件的优点是，当您更新文件时，您不知道还有谁在使用该文件，您也不知道文件的存储位置。存在潜在的超时（带块的节点没有响应），因此您可能会得到不匹配的数据（同样，我不知道hadoop的内部结构，可能会处理一个节点关闭的更新，这是我正在进行的头脑风暴）

更新HDFS上的文件有很多潜在问题（上面列出了一些）。这些都不是不可克服的，但它们需要一个性能测试来检查和解释

---

由于HDFS的主要用途是存储数据，以便在mapreduce中使用，因此行级更新在此阶段并不重要。

如果您针对某个特定情况进行优化，则希望该情况更快。未经考虑的事情可能会影响性能。例如，我曾经用Java编写了一个对CSV文件进行操作的

行集
实现。我需要在那里进行随机访问，查找文件最后一行的速度大约是只能向前读取的
BufferedReader
的四倍。对，MapReduce不需要进行随机访问。它不符合这种模式。