S3 параллельное чтение и запись производительности?

Question

Рассмотрим сценарий, в котором Spark (или любая другая среда Hadoop) считывает большой (скажем, 1 ТБ) файл с S3. Как несколько искровых исполнителей параллельно читают очень большой файл из S3. В HDFS этот очень большой файл будет распределен по нескольким узлам, причем каждый узел будет иметь блок данных. В хранилище объектов я предполагаю, что весь этот файл будет в одном узле (без учета реплик). Это должно резко снизить пропускную способность чтения / производительность.

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

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

Answer 1

Да, 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 = правда.
• Пропускная способность загрузки по сети, опять же, функция типа виртуальной машины, за которую вы платите.

Фиксируйте производительность и правильность

Когда вывод фиксируется с помощью rename() файлов, записанных во временную папку, время копирования каждого объекта в его окончательный путь составляет 6-10 МБ / с.

Еще большая проблема заключается в том, что он очень плохо справляется с непоследовательными списками каталогов или сбоями задач во время процесса фиксации. Вы не можете безопасно использовать S3 как прямое назначение для работы с обычным алгоритмом переименования при фиксации без чего-либо, что могло бы дать вам согласованное представление о хранилище (непротиворечивые emrfs, s3mper, s3guard).

Для максимальной производительности и безопасного совершения работы вам нужен выходной коммиттер, оптимизированный для S3. У блоков данных есть свои особенности, в Apache Hadoop 3.1 добавлен "коммиттер вывода S3A". EMR теперь, видимо, тоже кое-что здесь.

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