Я пытаюсь понять, какое влияние может оказать кодирование стирания на чтение производительности файла.
Перед этим краткий обзор кодирования стирания Hadoop 3.0 с использованием метода Рида-Соломона. Если файл, разбитый на k блоков, закодирован в p блоков четности, то из k + p блока по крайней мере любые k блоков должны быть доступны для восстановления файла. В Hadoop 2.0 по умолчанию использовалась репликация 3, поэтому для файла из 10 блоков требуется 30 блоков пространства в кластере. Hadoop 3.0 заявляет, что он обеспечивает сокращение пространства на 50%, поэтому для тех же 10 блоков, которые хранятся в версии 3.0, потребуется только 15 блоков, т. Е. Дополнительные 5 блоков можно использовать как блоки четности.
В Hadoop 3.0 - файл (файл1) с 10 блоками приведет к 5 блокам четности (при улучшении данных с EC в 3,0 будет 50%). Скажем, исходные 10 блоков данных хранятся в узлах с n0 по n9, а 5 блоков четности хранятся на узлах с n10 по n14.
Теперь операция чтения этого файла должна определенно извлекать данные из первых 10 узлов, то есть с n0 по n9, так как извлечение данных из узлов с блоками четности может потребовать больше времени, так как включает в себя декодирование (верно ??).
Далее допустимое количество отказов узлов для этого файла - 5.
Если узлы n10 - n14 выходят из строя (это узлы с блоками четности). Производительность операции чтения (из-за сбоя узлов) не будет затронута, и производительность будет такой же, как в сценарии выше.
Но если узлы с n5 по n9 выходят из строя, то я предполагаю, что производительность чтения в этом случае будет ниже производительности в вышеупомянутых случаях.
Но в версии 2.0 можно ожидать одинаковой производительности независимо от того, какие узлы вышли из строя, если число отказов узлов меньше, чем ReplicationFactor-1.
Вопрос заключается в следующем: стоит ли добавлять вышеуказанный фактор (кодирование стирания) также к набору факторов, которые могут повлиять на производительность чтения в 3.0