Блог

В AWS Glue job мы можем написать некоторый скрипт и выполнить скрипт через job.

В AWS Lambda мы также можем написать тот же сценарий и выполнить ту же логику, что и в предыдущем задании.

Итак, мой вопрос не в том, в чем разница между AWS Glue Job и AWS Lambda, НО я пытаюсь определить, когда AWS Glue job следует предпочесть AWS Lambda, особенно когда оба выполняют одну и ту же работу? Если оба выполняют одну и ту же работу, то в идеале я бы слепо предпочел использовать саму AWS Lambda, верно?

Пожалуйста, попытайтесь понять мой запрос..

Дополнительные моменты:

Согласно этому источнику и Часто задаваемые вопросы по Lambda и Часто задаваемые вопросы о клеях

Lambda может использовать несколько разных языков (Node.js , Python, Go, Java и т.д.), Поскольку Glue может выполнять задания только с использованием кода Scala или Python.

Lambda может выполнять код из триггеров других сервисов (SQS, Kafka, DynamoDB, Kinesis, CloudWatch и т.д.) По сравнению с Glue, который может запускаться событиями lambda, другими заданиями Glue вручную или по расписанию.

Lambda работает намного быстрее для небольших задач по сравнению с Задания на склеивание, инициализация которых занимает больше времени из-за того, что в них используется распределенная обработка. При этом Glue использует свою параллельную обработку для выполнения больших рабочих нагрузок быстрее, чем Lambda.

Похоже, что Lambda требует большей сложности / кода для интеграции в источники данных (Redshift, RDS, S3, DBS, работающие на экземплярах ECS, DynamoDB и т.д.), В то время как Glue может легко интегрироваться с ними. Однако с добавлением функций Step несколько функций lambda могут быть написаны и упорядочены последовательно из-за снижения сложности и улучшения модульности, когда каждая функция может интегрироваться в сервис aws (Redshift, RDS, S3, DBS, работающие на экземплярах ECS, DynamoDB и т.д.).

Похоже, что у Glue есть ряд дополнительных компонентов, таких как Каталог данных, который является центральным хранилищем метаданных для просмотра ваших данных, гибкий планировщик, который обрабатывает разрешение зависимостей / мониторинг заданий / повторные попытки, AWS Glue DataBrew для очистки и нормализации данных с помощью визуального интерфейса, AWS Glue Elastic Views для объединения и репликации данных в нескольких хранилищах данных, AWS Glue Schema Registry для проверки схемы потоковых данных.

Есть и другие примеры, которых мне не хватает, поэтому не стесняйтесь комментировать, и я могу обновить.

Срок службы Lambda составляет пятнадцать минут. Его можно использовать для запуска задания на склеивание как действия, основанного на событии. То есть, например, когда файл попадает в S3, у нас может быть триггер события, который может запускать задание склеивания. Glue — это управляемый сервис для всей обработки данных.

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

Ответ на этот вопрос может включать в себя некоторые основополагающие дизайнерские решения. Что делает эта работа? С какими данными вы имеете дело? Необходимо ли принять решение о том, следует ли выполнять задачу в пакетной или событийно-ориентированной парадигме?

Пакет

Это может быть необходимо или желательно, поскольку задача:

• Выполняется над большими монолитными данными (например, двоичными).
• Зависит от контекста нескольких записей в наборе данных, так что они должны быть загружены в одно задание.
• Порядок имеет значение.

Мне кажется, что так же часто я вижу, что пакетная обработка выбирается по умолчанию, потому что «мы всегда так делали», но стоит подумать об отказе от этого подхода.

Glue создан для пакетных операций. При текущем максимальном времени выполнения 15 минут и максимальной памяти 10 ГБ Lambda также стала способна обрабатывать довольно большие наборы данных за одно выполнение. Может быть сложно провести прямое сравнение затрат без учета специфики рабочей нагрузки. Когда дело доходит до разработки, я чувствую, что у Lambda есть преимущество в том, что касается инструментов для сборки, тестирования, развертывания.

Событие

В случае, когда ваши данные состоят из набора записей, вам может потребоваться проанализировать и «передать» их в Lambda. Рассмотрим поток, подобный:

• CSV попадает в S3.
• Событие S3 запускает Lambda.
• Lambda считывает и анализирует CSV в отдельные события, отправляет в другой Lambda или публикует в SNS для последующей обработки. Для ускорения приема можно использовать одновременные экземпляры этого Lambda, где каждый экземпляр отвечает за определенные строки объекта S3.

Это переводит всю логику и обработку ошибок, а также требуемые ресурсы на уровень отдельного события / записи. Часто для исправления используются такие механизмы, как очереди с просроченными письмами. В то время как контекст данного контейнера сохраняется при вызовах — при условии, что контейнер не простаивал и не был снесен — Lambda, как правило, следует считать не имеющим состояния, так что обработка события / записи рассматривается как происходящая в его собственной области, за пределами других в наборе данных.