Первоначально написано Максимилианом Яворским и Лидией Курасиньской
Вы, вероятно, слышали, что создание конвейеров ETL (извлечение, преобразование, загрузка), особенно сложных, является сложной задачей. Были разработаны различные инструменты, чтобы значительно упростить этот процесс, но большинство из них по-прежнему требуют знания языка программирования (например, Python или R), часто в сочетании с пониманием таких инструментов, как Spark.
В августе 2017 года AWS создала Glue DataBrew — инструмент, идеально подходящий для аналитиков данных и бизнес-аналитиков, поскольку он облегчает подготовку и профилирование данных. Год назад компания выпустила AWS Glue Studio, визуальный инструмент для создания, запуска и мониторинга Glue ETL Jobs.
AWS Glue Studio поддерживает различные типы источников данных, такие как S3, Glue Data Catalog, Amazon Redshift, RDS, MySQL, PostgreSQL и даже потоковые сервисы, включая Kinesis и Kafka. Из коробки он предлагает множество преобразований, например, ApplyMapping, SelectFields, DropFields, Filter, FillMissingValues, SparkSQL и многие другие. Мы можем сохранять результаты наших заданий на Amazon S3 и в таблицах, определенных в AWS Glue Data Catalog.
Также, очевидно, мы можем использовать все это без знания Spark, поскольку Glue Studio сгенерирует для нас код Apache Spark.
Итак, давайте посмотрим на практике, что мы можем сделать с помощью AWS Glue Studio. Я пообещал себе, что постараюсь не написать ни строчки кода при решении своего кейса.
В этой статье я использовал немного измененный набор данных E-Commerce Data.
AWS Glue Studio на практике
Предположим, что вы получили от своих аналитиков данных следующее задание:
Одна система ежедневно загружает CSV-файлы, которые содержат следующую информацию: invoice_no, stock_code, description, quantity, unit_price, customer_id, country, invoice_date. Подсчитайте общее количество проданных товаров (подсчитайте количество) и общую стоимость покупки (сумма за количество товаров, умноженная на цену единицы товара) для каждого клиента и дня. Сохраните результаты в CSV-файл, разделенный запятыми, в ведро S3.
Я знаю, что это звучит скорее как работа для аналитика данных, и некоторые из вас, вероятно, думают, что это простая и скучная задача, но не волнуйтесь, мы добавим немного действий позже.
Мои входные файлы находятся в этой директории: aws-glue-demo-202109/inputsИтак, давайте посмотрим, как мы можем сделать это с помощью AWS Glue Studio.
Чтобы получить к ней доступ, выберите AWS Glue в главной консоли управления AWS Management Console, затем на левой панели (под ETL) нажмите на AWS Glue Studio. Перейдите к Jobs, и в верхней части вы должны увидеть панель Create job — она позволяет создавать новые задания несколькими различными способами: Visual с источником и целью, Visual с чистым холстом, редактор сценариев Spark и редактор сценариев Python Shell.Я выбрал Visual с чистым холстом. Он должен создать новое, пустое задание без названия.
Прежде чем мы начнем строить наш ETL-процесс, давайте перейдем на вкладку Job Details и обсудим некоторые важные свойства, которые определяют, как AWS Glue будет выполнять задание. За исключением названия задания, вы можете изменить эти параметры в любое время.
- Версия Glue — определяет версии Apache Spark и Python, которые доступны для задания. Примечание: некоторые функции могут быть недоступны для определенных версий. Например, на момент написания статьи функция предварительного просмотра данных не работает в последней версии 3.0.
- Язык — либо Python, либо Scala. Я выберу Python.
- Тип рабочего (G.1X или G.2X) — для рабочего типа G.1X каждый рабочий соответствует 1 DPU. Для G.2X — 2 DPU для каждого рабочего. Я выбрал G.1X, так как он имеет гораздо больше ресурсов, чем мне на самом деле понадобится.
- Закладка задания (Включить, Отключить, Приостановить) — вот это довольно важная переменная, особенно то, что Enable является значением по умолчанию. В двух словах: когда вы включаете закладки заданий, после обработки некоторых данных (например, файла S3) эти данные помечаются заданием как обработанные и не будут обрабатываться этим заданием при следующих выполнениях. Закладки привязаны к заданиям, поэтому разные задания могут обрабатывать один и тот же файл. Сейчас я отключаю эту функцию, так как в процессе разработки задания мне, вероятно, придется обрабатывать одни и те же файлы снова и снова. Для более подробного описания закладок заданий, пожалуйста, прочитайте статью Отслеживание обработанных данных с помощью закладок заданий.
- Количество повторных попыток — этот параметр не требует пояснений. Сейчас я меняю это значение с 3 на 0, поскольку не хочу, чтобы Glue повторял выполнение задания, которое не удалось только потому, что я допустил какую-то глупую ошибку, например, использовал пустой файл.
Я не буду углубляться в раздел расширенных свойств, но имейте в виду, что именно здесь вы можете настроить путь к сценарию S3, путь к журналам Spark UI, установить максимальный параллелизм, отключить метрики и т. д.
Примечание: вы должны установить эти параметры для каждого созданного задания, если только вы не клонируете задание — тогда его копия имеет те же параметры, что и оригинал.
Теперь давайте вернемся к разделу Visual.
1.В разделе Источник выберите узел Amazon S3.В свойствах источника данных — S3 установите:
- S3 source type: S3 location — так вы получите прямой доступ к файлам S3.
- S3 url: s3://aws-glue-demo-202109/input/
- Рекурсивный: true
- Формат данных: CSV
- Разделитель: Запятая (,)Примечание: вы ограничены следующими разделителями: Запятая, Ctrl+A, Труба, Точка с запятой, Табуляция.
Теперь перейдем на вкладку Output schema.
Эти типы данных выглядят неправильно — вам придется это изменить. Нажмите кнопку Edit и для каждого ключа установите правильный тип данных (в соответствии с информацией, предоставленной аналитиками данных):
Все выглядит хорошо, нажмите кнопку Next и перейдите к следующему шагу.
2.Делаем агрегации. Здесь кроется первое «препятствие», поскольку Glue Studio не имеет встроенного узла трансформации, который позволяет нам делать агрегаты. Лучшим решением будет использование узла Transform — Spark SQL. Вы можете назвать узел aggByCustomerByDate, а в разделе transform выбрать Amazon S3 (имя родительского узла) в качестве источника ввода и дать ему псевдоним sales, который вы можете использовать в коде SQL в качестве имени таблицы. В блоке Code вы можете поместить простой SQL-запрос, который берет столбец customer_id, получает дату из столбца invoice_date, суммирует quantity и quantity*unit_price и группирует по customer и sale_date.
Предположим, что это не нарушает мое правило «не писать строку кода».
Примечание: этот редактор не проверяет синтаксис, поэтому дважды проверьте свой запрос перед запуском.3.Теперь, когда вы закончили с агрегатами, сохраните их результат на S3. В меню Target выберите Amazon S3, выберите CSV Format. Решите, нужно ли применять какое-либо сжатие, и установите целевое местоположение s3://aws-glue-demo-202109/output/1st-direct.
4.Работа готова. В правом верхнем углу нажмите Save, затем Run и подождите. Вы можете перейти на вкладку Runs и увидеть ход выполнения задания, а также ссылки на журналы и метаданные выполнения.
Через минуту вы увидите, что задание успешно выполнено.Теперь перейдите в целевой каталог S3. Здесь у вас есть 4 файла:
Каждый файл содержит customer_id, sale_date, total_quantity и total_sale.
Хорошо, это было довольно быстро и просто. Но я не удовлетворен этим решением, и вы тоже можете быть не удовлетворены. Правда, я произвел расчеты для всех файлов, но что будет завтра, когда придет новый файл? Как и вы, я не хочу обрабатывать все данные еще раз. Нас интересует только обработка вновь созданных файлов.
Кроме того, у аналитиков данных есть еще несколько пожеланий.
-
Они вспомнили, что иногда количество может быть отрицательным значением, что указывает на то, что товар был возвращен. Они хотели бы, чтобы я исключил эти строки из агрегации и хранил список возвращенных товаров в отдельном файле.
-
Если вы внимательно посмотрите на последнее изображение, то заметите, что во второй строке отсутствует значение customer_id. Аналитики хотели бы избавиться от пустых клиентов.
-
Аналитики хотели бы связать некоторые данные клиентов (имя, фамилия, адрес) с файлом с помощью агрегаций.
-
Работа с четырьмя отдельными файлами немного беспокоит — они предпочли бы иметь только один файл.
Давайте сначала разберемся с моей проблемой. Насколько я понимаю, есть два возможных подхода:
-
Вышеупомянутые закладки заданий. Как сказано в документе: «Закладки заданий используются для отслеживания исходных данных, которые уже были обработаны, предотвращая повторную обработку старых данных. Закладки заданий можно использовать с источниками данных JDBC и некоторыми источниками Amazon Simple Storage Service (Amazon S3). Закладки заданий привязаны к заданиям. Если вы удаляете задание, то удаляется и его закладка. Вы можете перемотать закладки заданий для заданий Glue Spark ETL на любое предыдущее задание, что позволит вашему заданию повторно обработать данные. Если вы хотите переработать все данные с помощью одного и того же задания, вы можете сбросить закладку задания».
-
Вручную или с помощью функции или какого-либо параметра определите, какие файлы (день или диапазон дней) должны быть обработаны.
Первое решение кажется действительно классным, но, допустим, я не уверен на 100%, как загружаются данные — может быть, файлы перезаписываются каждый день? Или они могут внезапно начать это делать? Или вы собираетесь часто изменять наши задания и повторно запускать их для определенных файлов, и вы не хотите помнить о сбросе закладки задания?
В любом случае, допустим, что в рамках этой статьи вы просто не можете или не хотите полагаться на закладки заданий. Что вы можете сделать?
Вы можете отфильтровать данные, например, в Transform — Spark SQL node, но это не решит проблему — задание по-прежнему будет обрабатывать все файлы, вы просто отфильтруете выходные данные или данные, которые пойдут на агрегацию. Вам нужно придумать, как разделить эти файлы «логически».
Вместо того чтобы работать непосредственно с файлами S3, попробуйте организовать файлы S3 в базы данных и таблицы. Возможно, тогда вы сможете более эффективно запрашивать данные. Используйте для этого AWS Glue Crawler.
В двух словах, AWS Glue может объединять файлы S3 в таблицы, которые могут быть разделены на разделы на основе их путей. Например, если ваши файлы организованы следующим образом:
bucket1/year/month/day/file.csv
то AWS Glue может создать одну таблицу из всех файлов в bucket1, которая будет разбита на разделы по годам, месяцам и дням. Уровень создания разделов также является определяемым, и вы можете иметь, например, таблицу для каждого отдельного дня, месяца или года. Более подробную информацию вы найдете в этой статье о работе с разделенными данными в AWS Glue.
На данный момент у вас есть две идеи для тестирования:
-
Создать отдельную таблицу для каждого дня.
-
Создать одну таблицу с разделами по году, месяцу и дню.
Но прежде чем создавать базы данных и таблицы, необходимо реорганизовать структуру вашего ведра S3:
bucket/YYYYMMDD_data.csv
на
bucket/year/month/day/data
Таким образом, вместо:
aws-glue-demo-2021/inputs/20210901_data.csv
aws-glue-demo-2021/inputs/20210902_data.csv
aws-glue-demo-2021/inputs/20210903_data.csv
aws-glue-demo-2021/inputs/20210904_data.csv
aws-glue-demo-2021/inputs/20210905_data.csv
ваши файлы будут организованы таким образом:
aws-glue-demo-2021/inputs/2021/09/01/data.csv
aws-glue-demo-2021/inputs/2021/09/02/data.csv
aws-glue-demo-2021/inputs/2021/09/03/data.csv
aws-glue-demo-2021/inputs/2021/09/04/data.csv
aws-glue-demo-2021/inputs/2021/09/05/data.csv
После этого вы можете начать работу с AWS Glue Crawler (который также доступен из панели AWS Glue Studio на вкладке Glue Console).Сначала настройте краулер, который будет создавать единую таблицу из всех файлов.
Нажмите кнопку Добавить краулер:
- Назовите краулер get-sales-data-partitioned и нажмите Next.
- Оставьте тип источника Crawler на настройках по умолчанию (Crawler source type: Data stores & Crawl all folders), затем снова нажмите Next.
- Выберите S3 в качестве хранилища данных и укажите путь s3://aws-glue-demo-202109/inputs и нажмите Next.
- Нет, вы не хотите добавлять еще одно хранилище данных.
- Теперь вы можете либо выбрать существующую роль, либо создать новую. Давайте создадим новую.
- Пока выберите Частота: Запускать по требованию.
- Для хранения вывода Crawler создайте базу данных под названием sales_partitioned и выберите созданную базу данных из выпадающего меню. В параметрах конфигурации выберите Игнорировать изменение и не обновлять таблицу в каталоге данных и Удалять таблицы и разделы из каталога данных (позже я объясню почему) и нажмите Далее.
- Просмотрите свой краулер и подтвердите.
Для краулера, который будет создавать отдельные таблицы, процесс практически такой же; единственные изменения — в следующих шагах:
- Шаг №1: Назовите его get-sales-data-partitioned-sep.
- Шаг #2: Выберите уже существующую роль (созданную для предыдущего краулера).
- Шаг №7: В разделе Configure the crawler output создайте новую базу данных под названием sales_partitioned_sep. В разделе Group behavior for S3 — Table level введите 5. Почему 5? Ну, если считать с начала: bucket — это первый уровень, inputs — второй, year — третий, month — четвертый, а day — пятый.
Далее просмотрите свой краулер и сохраните его. На этом этапе у вас должно быть два краулера, которые создадут две отдельные базы данных, запустите оба и подождите.
Через некоторое время вы увидите, что краулер get-sales-data-partitioned создал одну таблицу, а get-sales-data-partitioned-sep создал девять таблиц.Почему девять? Скорее всего, потому что за это время кто-то создал новые файлы. Это можно выяснить, зайдя в раздел Databases, где вы должны увидеть свои базы данных:
В sales_partitioned вы должны увидеть одну таблицу:
В то время как в sales_partitioned_sep вы должны увидеть девять таблиц.
Первое, что бросается в глаза, это то, что одна из таблиц, повторяющаяся через два месяца, получила уродливый суффикс. Но давайте перейдем к таблице input_partitioned. Внизу вы должны увидеть столбцы — это и есть ваши разделы:
Как выяснить, что скрывается за разделами partition_0, partition_1 и partition_2? Нажмите на View Partitions: вы увидите, что partition_0 — это год, partition_1 — месяц, а partition_2 — день.
Нажмите на Close Partitions, затем Edit Schema и переименуйте эти столбцы. Сохраните ее, и теперь ваша таблица должна выглядеть следующим образом:
Примечание: теперь важно объяснить, почему я ранее отметил опцию Игнорировать изменение и не обновлять таблицу в каталоге данных во время создания краулера. Если бы я не выбрал эту опцию и запустил краулер завтра, имена столбцов, которые я дал (год, месяц, день), были бы перезаписаны обратно в partition_0, partition_1 и partition_2.
Обновление! Есть одна вещь, которую я упустил при написании этой статьи. Если вы назовете свои разделы S3 следующим образом:
year=2021/month=08/day=30/data.csv
Glue Crawler будет автоматически подбирать имена разделов, и вам не придется переименовывать колонки самостоятельно.
Теперь вернемся к работе — какие есть варианты? Слева видно, что я могу выбрать отдельные таблицы из базы данных sales_partitioned_sep. В правой части у меня есть только одна таблица для выбора, но я могу отправить предикаты разбиения.Оба подхода уменьшают количество исходных данных. Однако есть несколько вещей, которые мне не нравятся во втором варианте:
- названия таблиц не указывают четко (по крайней мере, в моем случае), над какими данными мы работаем,
- когда мне придется работать более чем с одним днем, мне придется добавлять отдельные узлы источников и создавать джойны, тогда как в первом решении мне придется только модифицировать запрос в predicament pushdown.
Итак, меня устраивает первый вариант, но прежде чем мы продолжим, вот несколько заметок.
Теперь, когда мы работаем с таблицей Data Catalog, а не с файлами S3 напрямую, следует отметить, что вывод файла изменился. У нас больше нет полей выбора — теперь типы данных определяются Glue Crawler.
Итак, как вы можете это изменить? Есть три варианта:
- вы можете изменить типы схем в Glue Data Catalog (так же, как мы изменили имя раздела),
- вы можете изменить типы на первом шаге (как в предыдущем задании),
- можно добавить отдельный узел трансформации, который будет изменять типы.
Я выбрал третий вариант. Почему? Во-первых, потому что я хочу, чтобы все видели, что этот шаг выполняется (что мы ожидаем некоторые типы данных). Во-вторых, потому что я хочу показать вам другую трансформацию.
Итак, с предикатом раздела и дополнительным шагом для применения типов данных наша работа выглядит следующим образом:Теперь вернемся к вопросам аналитики.
Во-первых, давайте рассмотрим возвраты элементов. Вы хотите отфильтровать строки с отрицательной unit_price и сохранить их в отдельном файле. Добавьте два дополнительных преобразования — узла Filter после узла setDatatypes. Первое (getSales) берет записи с unit_price >= 0; второе (getReturns) берет записи с unit_price < 0. После getSales выполните агрегацию и сохраните в S3; после getReturns просто сохраните в S3.Примечание: похоже, что вы не можете объединить операторы or и and в одном шаге. Если вам действительно нужно это сделать, следует использовать узел Spark SQL и написать пользовательский SQL-запрос.
Что дальше? Попробуйте удалить из расчета пустых клиентов. Это немного сложно — вы хотите отфильтровать их после установки типов данных с помощью узла Transform — Filter, но этот шаг ограничен «=, !=, <, >, <=, >=», а использование != с Null или пустой строкой не работает…Так может быть, вы могли бы отфильтровать данные перед тем, как задать типы данных? Ну, вы не можете этого сделать — до применения типов данных вы можете только фильтровать столбцы на совпадающие значения с помощью regex.
Итак, что же остается? Снова нужно использовать трансформацию Spark SQL, чтобы написать запрос, который будет отфильтровывать нулевые значения. Ключевая функция — isnotnull(column) = 1. Я поместил этот шаг после применения типов данных и перед фильтрацией скидок.
Далее давайте разберемся с количеством разделов выходных файлов. И здесь я вынужден сдаться — это невозможно сделать без использования пользовательских преобразований (по крайней мере, я не понял, как это сделать). Сложно ли это?
Ну, это зависит от ситуации. Документация (AWS doc: transforms custom) не очень обширна и содержит только один пример. Самое главное, что нужно помнить, это то, что узел Custom Transformation принимает только glueContext и DynamicFrameCollection в качестве входных данных и должен также возвращать DynamicFrameCollections (коллекции DynamicFrames) в качестве выходных данных.
Что это означает? Это значит, что для выполнения любых преобразований на первом шаге необходимо выбрать, с каким DynamicFrame вы хотите работать. Если у преобразования есть только один родитель, то проблем нет — вы выбираете первый и преобразуете DynamicFrame в DataFrame:
def reducePartitionNumber(glueContext, dfc) -> DynamicFrameCollection:
df = dfc.select(list(dfc.keys())[0]).toDF()
Затем вы можете выполнять любые преобразования Spark. В моем случае я хочу уменьшить количество создаваемых разделов, поэтому я делаю следующее:
df_w_less_partitions = df.coalesce(1)
Затем я конвертирую датафрейм обратно в DynamicFrame и возвращаю его как коллекцию DynamicFrames:
df_one_partition = DynamicFrame.fromDF(df_w_less_partitions, glueContext, "one_part_df")
return DynamicFrameCollection({"CustomTransform0": df_one_partition}, glueContext)
В итоге узел должен выглядеть следующим образом:Но это еще не все. Согласно документации и тому, что вы видели выше, «пользовательское преобразование кода возвращает коллекцию DynamicFrames, даже если в наборе результатов есть только один DynamicFrame», и, к сожалению, узлы вывода не принимают DynamicFrameCollection в качестве входных данных, поэтому вам придется добавить еще один шаг, который будет выбирать конкретный DynamicFrame из коллекции.
Для этого шага вы можете использовать узел преобразования SelectFromCollection, который позволяет вам указать, какой набор данных вы хотите использовать. Поскольку здесь только один родительский узел, то и набор данных для выбора только один.
Но если бы у этого узла было несколько родителей или родитель, возвращающий много DynamicFrames (например, преобразование SplitFields, которое разбивает dataframe на два отдельных dataframes), у вас был бы выбор.После этого мы можем перейти к последней задаче: добавлению информации о клиентах в датафрейм с помощью агрегатов. Мои аналитики загрузили файл customers.csv в основную папку aws-glue-demo-202109. Файл содержит следующие данные: id, имя, фамилия, адрес.
В нашем задании мы сначала добавим еще один источник, который будет напрямую ссылаться на CSV-файл, содержащийся в ведре S3. Я даю этому узлу имя Customers. AWS Glue Studio самостоятельно обнаруживает форматы данных, разделители и определяет типы данных.Затем мы воспользуемся узлом Transform — Join для объединения данных из двух источников. Этот тип требует как минимум двух родительских узлов, поэтому я добавляю узел aggByCustomers в качестве второго источника.
Почему я присоединяюсь здесь? Боюсь, что объединение после уменьшения количества разделов (с помощью узла getReducedDynamicFrame) снова приведет к множественным разделам, а объединение раньше (до выполнения агрегации) менее эффективно, поскольку объединение будет выполняться на большем количестве строк.Теперь необходимо выбрать тип объединения и объявить условия объединения. Поскольку мой левый набор данных — это узел Customers, правый — aggByCustomers, и я знаю, что у меня нет данных по всем клиентам, я выбрал правое объединение. Я соединяю эти наборы данных с помощью столбцов id и customer_id.
Последнее, что нужно сделать, это изменить родительский вывод reducePartitionsNumber с aggByCustomers на joinAggregatesWithCustomers, и все готово. Теперь задание должно выглядеть следующим образом:
Давайте запустим его и посмотрим, что произойдет. После завершения работы зайдите в S3 и…
…все работает! Вы получили всего два файла:В первом — клиенты с их данными (если они найдены) и агрегаты:
Во втором — возвращенные товары:
Ну, честно говоря, мне не нравится порядок колонок, потому что когда join не нашел данные клиента, это выглядит вот так:
И я не вижу другого способа изменить их порядок, кроме другого узла Spark SQL, где я бы просто выбрал столбцы в другом порядке. Но давайте оставим все как есть. Как вариант, я также могу использовать узел трансформации FillMissingValues и тип, например, «NOT_FOUND», чтобы заполнить недостающие значения и сделать файл более читабельным.
Как запланировать задание AWS Glue?
На этом этапе вы можете сказать: «Хорошо, но я не хочу редактировать и запускать задание вручную каждый день». Есть две вещи, которые следует настроить, чтобы автоматизировать весь процесс.
- Автоматизировать ползунок, чтобы вновь добавленные файлы были видны как последовательные разделы. Вам не обязательно создавать новый краулер — вы можете отредактировать существующий. Выберите краулер, нажмите Action -> Edit Crawler и нажмите Next, пока не дойдете до шага № 5 (Create a scheduler for this crawler.) Выберите Daily вместо Run from demand и затем вы можете настроить время.
Проходим следующие шаги и сохраняем изменения. Если все прошло успешно, вы должны увидеть, что в краулере появился планировщик:
- Второй момент — автоматизация заданий. Сначала создайте планировщик заданий, что является довольно простой задачей. Зайдите в созданное задание и перейдите на вкладку Планировщик. Вы сразу же увидите опции для создания нового планировщика:
Вы можете задать имя планировщика, выбрать его частоту (почасовая, ежедневная, еженедельная, ежемесячная, пользовательская) и, по желанию, добавить описание. Я настроил планировщик заданий на выполнение через час после планировщика Glue.
Было бы здорово, если бы не нужно было вручную изменять дату, на которую должны быть сделаны агрегаты. Самым простым решением будет изменение функции предиката Partition в узле источника, чтобы она автоматически извлекала год, месяц и день из текущей даты.
year == year(current_date) AND
month == month(current_date) AND
day == day(current_date)
Примечание: пожалуйста, имейте в виду, что месяцы и дни не являются целочисленными значениями (01, 02, 03 и т.д.), а функции Spark извлекают месяц как целое число из заданной даты/временной метки/строки. Таким образом, вам придется еще раз реорганизовать структуру ведра.
Для тех, кто интересуется более продвинутыми решениями, пожалуйста, прочитайте о передаче пользовательских параметров в Glue Job (поскольку AWS Glue Studio также позволяет передавать до 50 пользовательских параметров) в статье Вызов AWS Glue APIs в Python-AWS Glue.
Когда следует использовать AWS Glue Studio?
Возможно, вы задаетесь вопросом, когда следует использовать AWS Glue Studio. Давайте сосредоточимся на Glue Studio, а не на Glue как сервисе в целом.
AWS Glue Studio отлично подходит, если вы хотите:
- быстро создавать задания ETL, которые выполняются регулярно,
- объединять большие объемы данных из разных источников,
- и выполнять простые преобразования, такие как переименование или удаление полей, объединение, разделение или фильтрация фреймов данных.
Поскольку вы можете видеть и копировать код, задание, подготовленное в Studio, может быть использовано в качестве отправной точки для более крупного и сложного задания в Glue.
А когда это не так полезно? Например, если вы ищете оркестратор заданий, позволяющий повторять работу с любого шага, использовать сенсоры для ожидания файла и т. д., вам больше подойдут Step Functions или Airflow. Если вы ищете инструмент подготовки данных, то DataBrew будет лучшим выбором, поскольку он предлагает гораздо больше возможностей преобразования данных.
Также имейте в виду, что AWS Glue Studio не является бесплатной. При создании задания вы должны указать количество рабочих (минимум два) и выбрать один из двух возможных типов экземпляров: G.X1 или G.X2. В G.X1 каждый рабочий соответствует одному DPU и одному исполнителю, который запускается с восемью ядрами Spark и 10 ГБ памяти. В G.X2 эти значения удваиваются. Почасовая оплата взимается в зависимости от количества DPU, используемых для выполнения заданий ETL.
Каковы плюсы и минусы AWS Glue Studio?
Одним из главных преимуществ AWS Glue Studio является тот факт, что, за исключением всего одного шага, мне не потребовалось использовать какой-либо язык программирования для создания вышеупомянутого задания ETL.
То, что не является очевидным, часто можно обыграть с помощью SQL-запроса Spark. Интеграция AWS Glue Studio с S3 или Data Catalog и планирование заданий чрезвычайно просты, то же самое относится и к планированию заданий. Кроме того, не будем забывать, что вы можете получать данные из потоковых сервисов, таких как Kinesis или Kafka.
Более того, в AWS Glue Studio мы можем отслеживать все задания в одном представлении, а закладки заданий — это тоже очень удобная функция.
Главным недостатком, безусловно, является пользовательский интерфейс, который немного неуклюж. Временами он может зависать и вести себя непредсказуемо. Поскольку вы не можете вручную перемещать узлы, большие задания могут в какой-то момент оказаться непонятными.
Для пользователей, не знакомых со Spark, ограниченное количество преобразований в некоторых случаях может стать большой проблемой. Кроме того, последняя версия не поддерживает все функции, такие как Data Preview, о чем вы узнаете, только когда попробуете запустить ее.
Заключительные мысли о построении сложных конвейеров данных с помощью AWS Glue Studio
Вот чего вы достигли, следуя инструкциям в этой статье:
- брали файлы как из Data Glue Catalog, так и из S3 напрямую,
- применили типы данных,
- удалили ненужные данные,
- разделили данные на основе определенных значений,
- сделали несколько объединений и агрегаций,
- уменьшал количество разделов,
- сохранили результаты на нужные пути в ведро S3.
Как вы убедились из этого руководства, создание сложных конвейеров данных не обязательно должно быть сложным. Надеюсь, вам понравилось следовать инструкциям и вы узнали немного больше о AWS Glue Studio.
Вот некоторые другие статьи, которые могут быть вам полезны:
- Python для Data Engineering: Почему инженеры по обработке данных используют Python?
- Как построить кластер Spark с помощью Docker, JupyterLab и Apache Livy — REST API для Apache Spark
- Реализация машинного обучения и управление проектами: Краткое руководство
В статье я использовал набор данных, предоставленный Dua, D. and Graff, C. (2019). UCI Machine Learning Repository [http://archive.ics.uci.edu/ml]. Ирвайн, Калифорния: Калифорнийский университет, Школа информации и компьютерных наук.