Использование pyspark на AWS EMR - PullRequest
Новая
       4

Использование pyspark на AWS EMR

0 голосов
/ 14 января 2020

Я новичок в PySpark и AWS EMR. Мне дали небольшой проект, в котором мне нужно каждый час очищать большие объемы файлов данных и создавать на их основе агрегированные наборы данных. Эти файлы данных хранятся на S3, и я могу использовать некоторые основные функции c в Spark (например, фильтр и отображение) для получения агрегированных данных. Чтобы сэкономить на исходящих затратах и ​​после некоторого анализа CBA, я решил создать EMR-кластер и делать вызовы pypark. Концепция работает нормально, используя лямбда-функции, запускаемые файлом, созданным в корзине S3. Я записываю выходные файлы обратно на S3.

  1. Но я не в состоянии понять необходимость создания кластера EMR из трех узлов, который я создал, и его использование для меня. Как я могу использовать файловую систему Had oop для своего преимущества здесь и всего хранилища, доступного на узлах?
  2. Как мне просмотреть (если это возможно) использование подчиненных / основных узлов в кластер? Откуда я знаю, что они используются, как часто и так далее c и c? Я выполняю код pyspark на главном узле.
  3. Существуют ли альтернативы EMR, которые я могу использовать с pyspark?

Есть ли хорошая документация для лучшего понимания.

Спасибо

1 Ответ

1 голос
/ 15 января 2020

  1. Spark - это платформа для распределенных вычислений. Он может обрабатывать наборы данных, превышающие объем памяти, и распределять рабочую нагрузку по частям на несколько рабочих параллельно. По умолчанию EMR создает 1 мастер-узел и 2 рабочих узла. Дисковое пространство на искровых узлах обычно не используется напрямую. Spark может использовать пространство для кэширования временных результатов.
    Чтобы использовать файловую систему Had oop, вам нужно запустить службу hdfs в aws. Однако s3 также является распределенным хранилищем. Поддерживается библиотеками oop. Spark EMR поставляется с драйверами oop и поддержкой S3 из коробки. Использование spark с S3 - это идеальное решение для хранения данных, которое подойдет для многих базовых c задач обработки данных.

  2. Это пользовательский интерфейс диспетчера искры в AWS EMR. Вы можете увидеть каждый запущенный сеанс приложения и текущее задание. Нажав на работу, вы можете увидеть, сколько исполнителей используется. Работают ли эти исполнители на всех узлах, зависит от вашей искровой памяти и конфигурации процессора. Настройка - это действительно большой топи c. На SO здесь good hints . Существует также вкладка аппаратного мониторинга, показывающая использование процессора и памяти для каждого узла. Код искры всегда выполняется на главном узле. Но он просто создает план DAG на этом узле и переносит фактическую работу на рабочие узлы в соответствии с планом. Следовательно, в руководствах говорится о подаче искровой заявки, а не о ее выполнении.

  3. Да. Вы можете запустить свой собственный искровой кластер на обычных экземплярах ec2. Существует даже автономный режим , позволяющий запускать искру только на одной машине. Это довольно большой след, который устанавливается тогда. И вам все еще нужно настроить память, процессор и настройки исполнителя. Так что это довольно сложно по сравнению с простой реализацией многопроцессорной обработки в python или использованием dask. Однако есть веские причины для этого. Это позволяет использовать все ядра на одной машине. И это позволяет вам использовать хорошо известный, хорошо документированный API. Тот самый, который можно использовать для обработки петабайт данных. Связанная статья выше объясняет мотивацию.

    Другая возможность - использовать AWS Клей. Это безсерверная искра. Служба будет отправлять ваши задания некоторым искровым узлам по требованию на AWS, где вы не сможете контролировать их. Подобно тому, как лямбда-функции выполняются на случайных AWS EC2 экземплярах. Однако клей имеет некоторые ограничения. При использовании pyspark на клей вы не можете установить python libs с c -extensions, например, numpy, pandas, большинство ml libs. Также Glue заставляет вас создавать схемы отображения ваших данных в каталоге Athena. Но автономная искра может просто обрабатывать их на лету.

    Databricks также предлагает отдельное безсерверное искровое решение вне AWS. Это более сложный на мой взгляд. Он также допускает пользовательские расширения c.

    Большая часть официальной документации посвящена различным API обработки данных, а не внутренним элементам apache spark. Есть несколько хороших замечаний по внутренним свечам на github . Я предполагаю, что каждая хорошая книга расскажет о некоторых внутренних работах по искре. AWS EMR - это просто автоматический искровой кластер с оркестратором пряжи. (К сожалению, никогда не читал какую-нибудь хорошую книгу об искре, получил кое-какую информацию, поэтому не могу ее порекомендовать)

...