Операции чтения на уровне Hadoop и согласованности

Я настраиваю распределенный HBase на HDFS и пытаюсь понять поведение системы во время операций чтения.

Вот как я понимаю высокоуровневые шаги операции чтения.

  1. Клиент подключается к NameNode, чтобы получить список DataNodes, которые содержат реплики интересующих его строк.
  2. Отсюда клиент кэширует список узлов данных и начинает напрямую обращаться к выбранному узлу данных, пока ему не потребуются другие строки из другого узла данных, и в этом случае он снова запрашивает узел имени.

Мои вопросы заключаются в следующем:

  1. Кто выбирает лучшую реплику DataNode для связи? Как клиент выбирает «ближайшую» реплику? Возвращает ли NameNode список относительных узлов данных в отсортированном порядке?
  2. Каковы сценарии (если есть), когда клиент переключается на другой узел данных, который запросил строки? Например, если один из DataNode становится перегруженным/медленным, может ли клиентская библиотека установить связь с другим DataNode из списка, возвращаемого NameNode?
  3. Есть ли вероятность получения устаревших данных с одной из реплик? Например, клиент получил список DataNodes и начал чтение с одного из них. Тем временем от другого клиента к NameNode поступает запрос на запись. У нас есть dfs.replication == 3 и dfs.replication.min = 2. NameNode считает запись успешной после сброса на диск на 2 из 3 узлов, в то время как первый клиент читает с 3-го узла и не знает (пока), что есть другая запись, которая была совершена?
  4. Hadoop поддерживает ту же политику чтения при поддержке HBase?

Спасибо


hadoop consistency hbase
person kirbo    schedule 24.07.2014    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Кто выбирает лучшую реплику DataNode для связи? Как клиент выбирает «ближайшую» реплику? Возвращает ли NameNode список относительных узлов данных в отсортированном порядке?

Клиент сам решает, к кому лучше обратиться. Он выбирает их в таком порядке:

  1. Файл находится на той же машине. В этом случае (при правильной настройке) он замкнет DataNode и перейдет непосредственно к файлу в качестве оптимизации.
  2. Файл находится в той же стойке (если настроена поддержка стойки).
  3. Файл находится где-то в другом месте.

Каковы сценарии (если есть), когда клиент переключается на другой узел данных, который запросил строки? Например, если один из DataNode становится перегруженным/медленным, может ли клиентская библиотека установить связь с другим DataNode из списка, возвращаемого NameNode?

Это не так умно. Он переключится, если посчитает, что DataNode не работает (это означает, что время ожидания истекло), но не в какой-либо другой ситуации, о которой я знаю. Я полагаю, что он просто перейдет к следующему в списке, но может снова связаться с NameNode — я не уверен на 100%.

Есть ли вероятность получения устаревших данных с одной из реплик? Например, клиент получил список DataNodes и начал чтение с одного из них. Тем временем от другого клиента к NameNode поступает запрос на запись. У нас есть dfs.replication == 3 и dfs.replication.min = 2. NameNode считает запись успешной после сброса на диск на 2 из 3 узлов, в то время как первый клиент читает с 3-го узла и не знает (пока), что есть другая запись, которая была совершена?

Устаревшие данные возможны, но не в описанной вами ситуации. Файлы являются однократно записываемыми и неизменяемыми (кроме добавления, но не добавляйте, если вам это не нужно). NameNode не скажет вам, что файл существует, пока он не будет полностью записан. В случае добавления, позор вам тогда. Поведение при чтении из активно добавляемого файла в локальной файловой системе также непредсказуемо. Вы должны ожидать того же в HDFS.

Один из возможных способов устаревания данных — это если вы извлекаете свой список местоположений блоков, а NameNode решает перенести все три из них одновременно, прежде чем вы получите к нему доступ. Я не знаю, что бы там произошло. За 5 лет использования Hadoop у меня никогда не было такой проблемы. Даже при запуске балансировщика одновременно с выполнением каких-либо действий.

Hadoop поддерживает ту же политику чтения при поддержке HBase?

HDFS не обрабатывает HBase особым образом. Ходят слухи о том, что вы используете собственную стратегию размещения блоков с помощью HBase, чтобы стать лучше. местоположение данных, но это в сорняках.

person Donald Miner    schedule 24.07.2014