Почему файловая система Hadoop не поддерживает произвольный ввод-вывод?

Hadoop распространяет и реплицирует файлы. Поскольку файлы реплицируются, любая операция записи должна будет найти каждый реплицированный раздел в сети и обновить файл. Это значительно увеличивает время операции. Обновление файла может привести к превышению размера блока и потребовать разделения файла на 2 блока, а затем репликации 2-го блока. Я не знаю внутренностей и того, когда и как он разделит блок... но это потенциальное осложнение.

Что делать, если задание не удалось или было уничтожено, которое уже выполнило обновление и было запущено повторно? Он может обновлять файл несколько раз.

Преимущество отсутствия обновления файлов в распределенной системе состоит в том, что вы не знаете, кто еще использует файл, когда вы его обновляете, вы не знаете, где хранятся фрагменты. Существуют потенциальные тайм-ауты (узел с блоком не отвечает), поэтому вы можете получить несоответствующие данные (опять же, я не знаю внутренностей хаупа, и обновление с отключенным узлом может быть обработано, просто я думаю )

Существует множество потенциальных проблем (некоторые из них описаны выше) с обновлением файлов в HDFS. Ни одна из них не является непреодолимой, но для их проверки и учета потребуется снижение производительности.

Поскольку основная цель HDFS — хранить данные для использования в mapreduce, обновление на уровне строк на данном этапе не так важно.

Я думаю, это из-за размера блока данных, и вся идея Hadoop заключается в том, что вы не перемещаете данные, а вместо этого перемещаете алгоритм в данные.

Hadoop предназначен для пакетной обработки данных не в реальном времени. Если вы ищете способы реализации чего-то более похожего на традиционную СУБД с точки зрения времени отклика и произвольного доступа, взгляните на HBase., созданный поверх Hadoop.