Я понимаю преимущество искры в плане обработки данных большого масштаба параллельно и в памяти.Почему искра читается и записывается так быстро с S3
Но как он не попал в узкое место с точки зрения чтения/записи на S3 при чтении/записи данных с/на S3. Это обрабатывается в какой-либо эффективной форме службой хранения S3? Является ли распределенное хранилище S3? Просьба дать некоторое объяснение и, если возможно, ссылки на то, как узнать больше об этом.
Только узкие места в пределах AWS являются:
Пропускная способность в регионе, такие как между Amazon EC2 и Amazon S3, чрезвычайно высока и вряд ли ограничить возможность передачи данных (в стороне от EC2 полосы пропускания сети ширина ограничение упомянутый выше).
Amazon S3 распространяется по многим серверам через несколько зон доступности в пределах региона. На очень высоких скоростях Amazon S3 имеет некоторые рекомендуемые Request Rate and Performance Considerations, но это происходит только при выполнении более 300 запросов PUT/LIST/DELETE в секунду или более 800 запросов GET в секунду для определенного ведра.
Apache Spark обычно развертывается через несколько узлов. Каждый узел имеет доступную полосу пропускания по типу экземпляра. Параметр «» Spark означает, что он может передавать данные в/из Amazon S3 намного быстрее, чем это может быть сделано одним экземпляром.
@jrotenstein спасибо! более конкретно, скажем, я сохраняю X TB/PB данных учебников в S3, и я выполняю типичный пример сокращения числа слов в примере искрового кластера. Предположим также, что половина данных может поместиться в ram (по барабану, определенному как суммарный барабан всех искровых работников). Какой процент времени получал бы данные в памяти по сравнению с временем, выполняемым на карте, и уменьшал бы шаги по сравнению с временем написания кортежей (слово, число) на диск. Что касается скорости процессора каждого рабочего, я бы принял стандартный экземпляр EC2 (т. Е. R3.2xlarge или sthg). – Dnaiel
Вам нужно будет запустить искру и посмотреть статистику, чтобы понять это. Первый запуск данных всегда будет самым медленным, когда он будет загружен в Spark и (предположительно) кэширован. Последующий доступ к этим данным будет намного быстрее. Таким образом, Spark лучше для ситуаций, когда вы обрабатываете одни и те же данные несколько раз (например, машинное обучение). Если вы просто получаете доступ к данным один раз, вы не увидите большой выгоды по сравнению с нерезидентными механизмами запросов. –
Apache Spark ведет переговоры с S3 через клиентскую библиотеку от Amazon по EMR или от команды Apache Hadoop в другом месте. Если вы используете URL-адреса s3a: //, вы используете самый последний клиент ASF.
Мы проводили там большую работу по ускорению процесса, см. HADOOP-11694.
убийцы производительности оказались бы
Избыточное количество запросов HEAD, при работе из файлов существует (тоже много проверок в коде). Исправление: обрезать на них
Закрытие и повторное подключение соединений при поиске. Исправлено: (a) ленивый поиск (только делать поиск по read(), а не по вызову seek()), (b) искать вперед по чтению и отбрасыванию данных. Эффективное даже до нескольких сотен килобайт (YMMV и т.д.)
Для бинарных ORC/Паркетные файлов, добавление специального fadvise = случайный режим, который не пытается полностью GET исходного файла, а не читает в блоках. Если нам нужно искать назад или вперед вперёд, остальные блока отбрасываются и соединение HTTP 1.1 повторно используется: нет необходимости , чтобы прервать соединение и пересмотреть новый.
Некоторые детали в этом разговоре с прошлого месяца: Spark and Object Stores, хотя это не входит в новый материал (в Hadoop 2.8 (готовится к печати), HDP 2,5 (доставка), возможно, в CDH некоторое время) в глубина. Он порекомендует различные настройки производительности, которые действительны и сегодня.
Также убедитесь, что любое сжатие, которое вы используете, является разделяемым (LZO, snappy, ...) и что ваши файлы не настолько малы, что слишком много накладных расходов при перечислении каталога и их открытии.
Смешно, я всегда спрашиваю себя, почему они так медленно :) –
lol. Я имел в виду по сравнению с нераспределенной системой хранения, где скорость ввода-вывода жесткого диска является огромным узким местом. – Dnaiel