Да, S3 медленнее, чем HDFS. но интересно посмотреть, почему и как перенести воздействие. Ключевой момент: если вы читаете намного больше данных, чем пишете, тогда производительность чтения имеет решающее значение; разъем S3A в Hadoop 2.8+ действительно помогает, так как он был настроен для чтения файлов Parquet / ORC на основе следов реальных тестов. Производительность записи также страдает, и чем больше данных вы генерируете, тем хуже становится. Люди жалуются на это, когда им действительно нужно беспокоиться о том, что без особых усилий вы можете на самом деле получить неверный результат. Это, как правило, более важная проблема - просто менее очевидная.
Производительность чтения
Чтение с S3 страдает из-за
- пропускная способность между S3 и вашей виртуальной машиной. Чем больше вы платите за виртуальную машину EC2, тем больше пропускная способность сети, тем лучше
- задержка запросов HEAD / GET / LIST, особенно всех тех, которые используются в работе, чтобы хранилище объектов выглядело как файловая система с каталогами. Это может особенно повредить фазе разделения запроса, когда перечислены все исходные файлы и идентифицированы те, которые нужно прочитать на самом деле.
- Стоимость
seek() ужасна, если HTTP-соединение для чтения прервано и новое соединение было пересмотрено. Без разъема, который оптимизировал поиск () для этого, ввод ORC и Parquet сильно страдает. разъем s3a в Hadoop 2.8+ делает именно это, если вы установите fs.s3a.experimental.fadvise в random.
Spark разделит работу над файлом, если формат разделяемый, и любой формат сжатия также можно разделить (gz нет, snappy есть). Это будет сделано с размером блока, который вы можете настроить / настроить для конкретной работы (fs.s3a.block.size).
Если> 1 клиент читает тот же файл, то да, вы получаете некоторую перегрузку дискового ввода-вывода в этот файл, но , как правило, его незначительное по сравнению с остальными. Один маленький секрет: для загружаемых файлов, состоящих из нескольких частей, чтение отдельных частей, по-видимому, этого не позволяет, поэтому загружайте и скачивайте с тем же настроенным размером блока.
Запись производительности
Производительность записи страдает от
- кэширование некоторых / многих МБ данных в блоках перед загрузкой, при этом загрузка не начинается до завершения записи. S3A для hadoop 2.8+: установите
fs.s3a.fast.upload = true.
- Пропускная способность загрузки по сети, опять же, функция типа виртуальной машины, за которую вы платите.
Совершенная работа и правильность
Когда вывод фиксируется с помощью rename () файлов, записанных во временную папку, время копирования каждого объекта в его окончательный путь составляет 6-10 МБ / с.
Еще большая проблема заключается в том, что он очень плохо справляется с непоследовательными списками каталогов или сбоями задач во время процесса фиксации. Вы не можете безопасно использовать S3 как прямое назначение для работы с обычным алгоритмом переименования при фиксации без чего-либо, что могло бы дать вам согласованное представление о хранилище (согласие emrfs, s3mper, s3guard).
Для максимальной производительности и безопасного совершения работы вам необходим модуль вывода, оптимизированный для S3. У блоков данных есть свои особенности, в Apache Hadoop 3.1 добавлен «коммиттер вывода S3A». У EMR теперь тоже есть что-то здесь.
Подробнее об этой проблеме см. Коммиттер с нулевым переименованием . После этого, надеюсь, вы либо перейдете к безопасному механизму фиксации, либо будете использовать HDFS в качестве места назначения работы.