AWS Glue First Experience – Часть 4 – развертывание и упаковка

В этом эпизоде мы собираемся изучить, как мы можем повторно использовать наш код и как развернуть приложение AWS Glue, которое состоит из более чем одного файла. Я ожидал, что рабочий процесс будет очень похож на AWS Lambda, который уже хорошо известен и оптимизирован для Python, но из -за участия искры это не совсем верно для клея AWS.

Задача номер 5: оставайтесь сухой

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

Из -за характера различных типов зависимостей каждый тип работы требуется. Pyspark – .py , .zip , Python Shell – .яйцо , .whl . И тот факт, что весь наш код находится в Монорепо.

Я решил создать простой пакет Python с Setuptools и следуйте Структура SRC Анкет

Это дает мне достаточную гибкость, чтобы создать необходимые форматы, а также ссылку на библиотеку изнутри Требования.txt Анкет

Задача № 6: развертывание и упаковка

Итак, теперь, когда у меня есть все необходимые компоненты, давайте собрать их вместе и развернуть с Terraform Анкет

Для каждого источника данных мы определили два перехода сырой до утонченного и усовершенствовано в куратор Анкет

AWS -клей требует 1 .py Файл как точка входа, а остальные файлы должны быть простыми .py или содержится внутри .zip или .whl и каждая работа должна иметь различный набор требований.

Другое требование от AWS -клея заключается в том, что файл скрипта точки входа и зависимости должны быть загружены на S3.

Все, что загружено на S3, затем также должно быть перечислено в Terraform как Специальный параметр -Extra-Py-Files в форме запятой, разделенной списком URL -адресов S3, например. s3://bucket/dep1.zip, s3://bucket/deb2.zip или s3://bucket/dep1.whl, s3://bucket/deb2.whl .

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

/
├── glue/
│   ├── data_sources/
│   ├── ├── ds1/
│   │   └── ├── raw_to_refined/
│   │       │   ├── Makefile
│   │       │   ├── config.py
│   │       │   ├── raw_to_refined.py
│   │       │   └── requirements.txt
│   │       └── refined_to_curated/
│   │           ├── Makefile
│   │           ├── config.py
│   │           ├── another_dependency.py
│   │           ├── refined_to_curated.py
│   │           └── requirements.txt
│   └── shared/
│       └── glue_shared_lib/
│           ├── Makefile
│           ├── setup.py
│           ├── src
│           │   └── glue_shared/__init__.py
│           └── tests/
└── terraform/

Давайте опишем структуру выше.

• /клей/ удерживает весь код Python

• /glue/data_sources/ Удерживает код заданий для каждого источника данных

• /glue/data_sources/ds1/ – это каталог из 1 конкретного источника данных, содержащего преобразование

• /glue/data_sources/ds1/raw_to_refined и /glue/data_sources/ds1/raw_to_refined преобразования, содержание которого затем используется как конкретная задача AWS -клея

• /клей/общий/ – Содержит общие элементы среди клея (задания, файлы и т. Д.)

• /glue/shared/glue_shared_lib – Является ли библиотека, используемая заданиями, содержит интерфейс конфигурации и другие полезные функции

• /terraform/ Владеет все ресурсы, необходимые для развертывания наших рабочих мест, роли IAM, Lambda функций и т. Д.

Теперь, когда мы понимаем структуру, мы можем посмотреть на определенную работу.

Структура работы клей

Это стандартный план, который соответствует моей цели разработки и развертывания нескольких заданий AWS.

ds1/
└── raw_to_refined/
   ├── Makefile
   ├── config.py
   ├── raw_to_refined.py
   └── requirements.txt

В этом случае мы смотрим на работу по трансформации из зоны сырой в рафинированную зону.

• Makefile – Содержит несколько целей, которые имена являются общими для всех заданий, Чистые, пакет, тестирование, загрузка, загрузка, развертывание тогда реализация каждой цели зависит от работы.

  • чистый – Очищает локальные временные файлы.
  • Пакет – Для Pyspark Job создает .zip Файл с зависимостью. Для работы Python Shell он работает Pip и загружает все файлы колеса.
  • upload-job – Загружает скрипт точки входа в S3 – полезно для быстрых обновлений во время разработки, если вы не вносите никаких изменений внутри зависимых файлов.
  • загрузить – Загрузите все связанные файлы .zip , .whl и intrypoint .py Файл в S3.
  • развернуть – выполняет чистый , Пакет и загрузить

• config.py – отвечает за создание объекта конфигурации. Это Extra .py Файл, который позже упакован и используется в качестве зависимости. Для экономии некоторого времени я использовал словарь Python, но с растущей сложностью работы я бы порекомендовал тратить время на создание лучшего подхода.

• raw_to_refined.py – Это основной файл точки входа, выполненный AWS Glue. Вы можете использовать этот файл, выполнить код в зависимости или напрямую реализовать логику преобразования. Имя этого файла намеренно такое же, как и родительский каталог, который будет объяснен позже.

• Требования.txt – стандартный Файл требований Это очень простой способ управления вашими зависимостями.

Эта настройка дает мне достаточную гибкость в качестве разработчика для запуска и обновления заданий в облаке из моей локальной среды, а также использования CI/CD. Другое преимущество заключается в том, что если у вас есть Pyspark с клей, работающим локально, вы также можете использовать это!

Terraform Part

Это пример развертывания работы Pyspark через Terraform, работа Python Shell следует тому же процессу с небольшой разницей (упомянутая позже).

Чтобы создать или обновить задание с помощью Terraform, нам нужно предоставить несколько параметров API, которые требуются ресурсом Terraform. Плюс Параметры нашей работы ожидают.

Нам нужно предоставить:

• Командование ScriptLocation – представлен как ds1_raw_to_refined_job_script_location – Это наш сценарий входа

• Defaultarguments – представлен как карта ds1_raw_to_refined_job_default_arguments – Это содержит основную конфигурацию

Ключ -Extra-Py-Files На карте ds1_raw_to_refined_job_default_arguments это запятая отделенная строка URL -адресов S3, указывающая на наши зависимости, например. s3://bucket/dep1.zip,s3://bucket/deb2.zip

Все дополнительные зависимости вписываются в 1 .zip файл И как только вы получите форму этих параметров, нет необходимости менять ее.

Это приводит к потенциальной проблеме человеческого надзора, особенно с рабочих мест Python Shell. Где зависимости колеса и по умолчанию, имя колеса содержит номер версии numpy-1.19.0-cp36-cp36m-manylinux2010_x86_64.whl Анкет

Тогда любое изменение в Требования.txt Или рабочие аргументы также требуют изменения ресурса Terraform, который поддерживается в другом каталоге.

Я не решил эту проблему во время проекта, но это может быть потенциально избежать, сохранив список зависимостей в ведре S3 в виде файла, который можно сгенерировать во время сделать Анкет И тогда Terraform просто загрузит эту информацию. Однако это теоретическое решение может привести к проблемам с куриным яйцом, и я бы хотел, чтобы AWS Glue имел лучший вариант поддержания зависимостей и конфигурации работы. Просто позволить использовать префикс S3 вместо полного URL -адреса было бы хорошим началом.

Код для примеров в этой статье можно найти в моем репозитории GitHub AWS-GLUE-MONOREPO-стиль

Оригинал: “https://dev.to/1oglop1/aws-glue-first-experience-part-4-deployment-packaging-5708”