Подтверждение операции записи данных Hadoop 2.0
У меня есть небольшой запрос относительно записи данных Hadoop
Из документации Apache
В общем случае, когда коэффициент репликации равен трем, политика размещения HDFS заключается в размещении одной реплики на одном узле в локальной стойке, другой на узле в другой (удаленной) стойке и последней на другом узле в том же выносная стойка. Эта политика сокращает трафик записи между стойками, что обычно повышает производительность записи. Вероятность отказа стойки намного меньше, чем вероятность отказа узла;
На изображении ниже, когда подтверждение записи считается успешным?
1) Запись данных в первый узел данных?
2) Запись данных в первый узел данных + 2 других узла данных?
Я задаю этот вопрос, потому что я слышал два противоречивых утверждения в видео на YouTube. Одно процитированное видео, которое записывается успешно, после записи данных в один узел данных, а другое процитированное видео о том, что подтверждение будет отправлено только после записи данных на все три узла.
2 ответа
Шаг 1. Клиент создает файл, вызывая метод create() в DistributedFileSystem.
Шаг 2: DistributedFileSystem делает RPC-вызов namenode для создания нового файла в пространстве имен файловой системы, без блоков, связанных с ним.
Namenode выполняет различные проверки, чтобы убедиться, что файл еще не существует и что у клиента есть права на создание файла. Если эти проверки пройдены, наменоде записывает новый файл; в противном случае создание файла завершится неудачно, и клиенту будет выдано исключение IOException. TheDistributedFileSystem возвращает FSDataOutputStream для клиента, чтобы начать запись данных.
Шаг 3: Когда клиент записывает данные, DFSOutputStream разбивает их на пакеты, которые он записывает во внутреннюю очередь, называемую очередью данных. Очередь данных используется DataStreamer, который отвечает за запрос к namenode выделить новые блоки, выбирая список подходящих узлов данных для хранения реплик. Список узлов данных формирует конвейер, и здесь мы предполагаем, что уровень репликации равен трем, поэтому в конвейере три узла. DataStreamer осуществляет потоковую передачу пакетов на первую станцию данных в конвейере, которая сохраняет пакет и пересылает его на вторую станцию данных в конвейере.
Шаг 4: Аналогично, вторая датодода хранит пакет и пересылает его в третью (и последнюю) датодуду в конвейере.
Шаг 5: DFSOutputStream также поддерживает внутреннюю очередь пакетов, которые ожидают подтверждения от датоданных, называемую очередью подтверждения. Пакет удаляется из очереди подтверждения только после того, как он был подтвержден всеми датодами в конвейере.
Шаг 6: Когда клиент завершил запись данных, он вызывает close() в потоке.
Шаг 7: Это действие сбрасывает все оставшиеся пакеты в конвейер данных и ждет подтверждения, прежде чем связаться с namenode, чтобы сообщить, что файл завершен. Namenode уже знает, из каких блоков состоит файл, поэтому ему нужно только ждать блоков быть минимально реплицированным, прежде чем вернуться успешно.
Операция записи данных считается успешной, если одна реплика успешно записана. Он регулируется свойством dfs.namenode.replication.min в файле hdfs-default.xml. Если во время записи реплики произошел сбой в работе datanode, записанные данные не будут считаться неудачными, но будут недостаточно реплицированы, что при балансировке кластера создает эти недостающие реплики. Пакет Ack не зависит от состояния данных, записанных в датододы. Даже если пакет данных не записан, пакет подтверждения доставляется.