Проблема.
Вы хотите, чтобы лямбда-выражение инициировало прием данных через рабочий процесс AWS Glue из источника за пределами AWS. Данные могут быть доступны в любое время между часами X и Y, но вам необходимо принять их как можно скорее.

В следующем примере я буду использовать таблицу в BigQuery в качестве источника данных за пределами AWS.

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

Доступен пример кода: https://github.com/MurrayCode/Reschedule-Lambda-Example

Решение:

Чтобы решить эту проблему, можно использовать запланированное Cron правило EventBridge для запуска Lambda, затем lambda может идти по различным путям с помощью AWS SDK. Лямбда либо обнаружит, что предполагаемые данные существуют, и запустит рабочий процесс Glue, либо создаст новое правило, которое нацелено на повторный запуск лямбда через X минут. Примечание. В этом примере X – 5 минут.

Сначала создайте лямбду с триггером правила Cron Scheduled EventBridge, запланированным на самое раннее возможное время, когда данные могут стать доступными. Затем для лямбды требуются следующие разрешения, чтобы она могла выполнять все необходимые действия.

Требуемые разрешения IAM:

"клей:НачатьПрогонПроцедуры"

«События: Удалить цели»

«события:Путруле»

«события:УдалитьRule»

"лямбда:GetFunctionConfiguration"

Необходимые политики на основе ресурсов

Политика, которая разрешает lambda:InvokeFunction как для исходного правила lambda cron, так и для правила повторного планирования, обрабатываемого лямбда-выражением.

Лямбда-код:

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

Этап 1. Используйте AWS SDK, чтобы удалить правило переноса расписания из лямбда-выражения.

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

Этап 2. Проверка существования данных:

В этом примере мы будем проверять существование ежедневно создаваемой таблицы в BigQuery. Сначала мы создаем клиент BigQuery с помощью Google Cloud SDK, затем извлекаем набор данных, а в наборе данных получаем таблицу.

В рамках try/catch мы пытаемся получить таблицу, если она существует, мы возвращаем true. Если мы обнаруживаем ошибку, мы затем проверяем, является ли код ошибки 404 (не найдено), что означает, что данные в настоящее время недоступны, и затем мы возвращаем false. Что-нибудь еще, и мы выбрасываем новую ошибку.

Затем мы вызываем нашу функцию и настраиваем 2 пути, по которым может пройти лямбда.

Путь 1 — таблица существует:

Если таблица существует, мы создаем новый клиент клея и запускаем предполагаемый рабочий процесс.

Путь 2 — Таблица не существует:

В случае, если таблица не существует, мы используем клиентскую функцию CloudWatchEvents putRule для создания нового правила с желаемым временем перепланирования, в данном случае 5 минут, и устанавливаем состояние «ВКЛЮЧЕНО».

Затем мы создаем новый лямбда-клиент с помощью SDK и используем функцию getFunctionConfiguration, передавая имя, которое мы дали лямбда-выражению при его создании на AWS. Затем мы извлекаем Lambda ARN из результатов этого с помощью «data.FunctionArn» и предоставляем его как часть наших параметров для следующего вызова SDK клиента CloudWatchEvents putTargets, который принимает имя правила и цель лямбда ARN и идентификатор.

Ниже приведено полное изображение примера лямбда-кода:

https://github.com/MurrayCode/Reschedule-Lambda-Example

Повышение уровня кодирования

Спасибо, что являетесь частью нашего сообщества! Больше контента в публикации Level Up Coding.
Подписывайтесь: Twitter, LinkedIn, Информационный бюллетень
Level Up меняет рекрутинг в сфере технологий ➡️ Присоединяйтесь к нашему коллективу талантов