Typhoon Orchestrator — отличный способ развернуть рабочий процесс ETL на AWS Lambda. В этом руководстве мы намерены показать, насколько он прост в использовании и универсален, развернув код в Lambda, который получает случайную шутку от https://jokeapi.dev один раз в день и отправляет ее в вашу группу Telegram.

Начиная

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

pip install typhoon-orchestrator[dev] pip install python-telegram-bot pip install requests

Далее мы создаем наш проект, мы назовем наш проект jester (мы можем назвать его как угодно).

typhoon init jester --template minimal cd jester typhoon status

Обратите внимание, что команда состояния выдает следующее предупреждение: Connections YAML not found. To add connections create connections.yml. Это нормально, потому что тайфун обычно использует базу данных метаданных, в которой вы можете хранить соединения и переменные, но мы не хотим создавать и использовать какие-либо таблицы DynamoDB для этого руководства, поэтому мы использовали минимальный шаблон, который не включает ничего, связанного с метаданными. база данных. Если вы видите какие-либо предупреждения о базе данных метаданных в ходе обучения, не беспокойтесь, это по той же причине.

Расскажи мне шутку!

Прежде чем беспокоиться о телеграмме, давайте создадим рабочий процесс, который вызывает API шутки и печатает шутку в вашем CLI. Создайте файл: dags/send_me_a_joke.yml:

В этом рабочем процессе есть три задачи, использующие встроенные функции:

Тег !Py означает, что вместо передачи ему объекта YAML вы передаете ему строку, представляющую код Python для запуска. Например, foo: 4 эквивалентно foo: !Py 2+2. $BATCH — это специальная переменная, которая содержит все, что вернула или выдала предыдущая функция. В случае задачи select_joke_test, где входными данными является задача get_joke, ее функция вернула NamedTuple с ответом и некоторыми метаданными, так что $BATCH.response является объектом request.Response.

Бежим смотреть шутку в наш терминал

typhoon dag run --dag-name send_me_a_joke

Кусок пирога! Но вот самое интересное…

хочу анекдот в телеграмм

В Тайфуне нет встроенной функции для отправки текста в телеграм-чат. К счастью, расширять Typhoon очень просто, так что давайте сделаем это сами.

Создайте следующий файл functions/msg.py:

И обновите файл DAG, который мы создали ранее в dags/send_me_a_joke.yml:

Обратите внимание, что для токена и идентификатора чата у нас есть тег !Var. Это потому, что мы не хотим включать в код секрет, такой как токен, поэтому мы будем считывать его из переменной. Если вы действительно проницательны, вы можете подумать: «Разве вы не говорили, что мы используем минимальное развертывание, в котором нет базы данных метаданных для хранения переменных?» Да, это 100% правильно. Обычно мы храним переменные в базе данных метаданных. Однако мы будем использовать альтернативный метод хранения переменных, который использует переменную среды, начинающуюся с TYPHOON_VARIABLE_.

export TYPHOON_VARIABLE_telegram_token = "MY_SECRET_TELEGRAM_TOKEN" export TYPHOON_VARIABLE_chat_id = "128332492187641"

Теперь, когда у нас все готово, давайте отправим несколько шуток.

typhoon dag run --dag-name send_me_a_joke

Если все было настроено правильно, вы должны получить уведомление со случайной шуткой программиста!

Стремление к облакам

Создайте и загрузите рабочий процесс

Это все хорошо, но мы хотим, чтобы бот рассказывал нам анекдот каждый день без необходимости локального запуска кода. Прежде всего давайте скомпилируем наш код в zip и загрузим его на S3, чтобы Lambda могла его использовать. Это может быть немного утомительно, но, к счастью, Typhoon позаботится об этом за нас. Нам нужно указать, в какую корзину S3 мы хотим выполнить развертывание. Вам также потребуется настроенный профиль AWS. Откройте файл .typhoonremotes и измените его, чтобы использовать свой профиль и корзину S3.

[test] aws-profile=myaws s3-bucket=typhoon-orchestrator

Теперь, когда у нас есть удаленное устройство с именем test, мы готовы создать zip-файлы и отправить их на S3. Для этого шага вам потребуется установить докер, потому что зависимости должны быть встроены в ОС, совместимую с той, которую использует Lambda, иначе они не будут работать. Это очень распространенный источник проблем, которых помогает избежать Typhoon. Если вы уверены, что ваша ОС совместима, вы можете добавить флаг --build-deps-locally, но обычно это не рекомендуется.

typhoon dag push --dag-name send_me_a_joke test

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

test в конце указывает, на какой удаленный сервер развертывать. В будущем мы могли бы добавить другую производственную среду с собственным пультом.

Если вы сейчас проверите свою корзину S3, вы найдете два файла:

  • Лямбда-код: typhoon_dag_builds/send_me_a_joke/lambda.zip
  • Все необходимые зависимости: typhoon_dag_builds/send_me_a_joke/layer.zip

Развертывание инфраструктуры

Для этой части вам нужно будет установить и настроить terraform. Подробнее об инфраструктуре в виде кода здесь.

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

Для этого руководства вам просто нужно обновить файл тестовых переменных, включив в него имя корзины S3 и некоторую информацию о DAG. Мы можем получить информацию обо всех дагах, запустив typhoon dag info --json-output --indent 2, но в этом случае нам нужно будет адаптировать ее, чтобы включить необходимые переменные среды. Это означает, что вам нужно будет добавить следующее в файл terraform/test.tfvars.

dag_info = { "send_me_a_joke": { "schedule_interval": "cron(0 10 * * ? *)", "environment": { "TYPHOON_VARIABLE_telegram_token": "MY_SECRET_TELEGRAM_TOKEN", "TYPHOON_VARIABLE_chat_id": "128332492187641" } } }

Обратите внимание, что формат интервала расписания отличается от того, который мы определили. Это связано с тем, что Terraform сопоставляется с ресурсами AWS, а AWS использует собственный вариант выражений cron, который несовместим со стандартными выражениями cron Unix, используемыми такими инструментами, как cron, crontab, Airflow и многими другими. Typhoon стремится стать фреймворком, который можно развернуть на многих платформах (в настоящее время он поддерживает AWS Lambda и Airflow), поэтому мы решили следовать отраслевому стандарту, а не стандарту AWS. К счастью, когда мы запускаем typhoon dag info ..., Typhoon преобразует его в стандарт AWS, поэтому вам не нужно делать это самостоятельно!

Теперь мы готовы создать инфраструктуру с помощью terraform.

export AWS_PROFILE =my-aws-profile export AWS_DEFAULT_REGION =eu-west-1 cd terraform terraform init terraform plan -var-file =test.tfvars -out =tfplan terraform apply tfplan

И вуаля! Вы можете проверить все ресурсы, созданные в AWS, и оценить, сколько времени мы сэкономили.

Давайте возьмем его за спину

Если все сработало правильно, в 10:00 вы получите шутку в своем телеграм-чате, но мы не хотим ждать так долго, мы хотим услышать ее прямо сейчас! Вы можете вызвать Lambda из консоли AWS, но мы будем вызывать ее с помощью Typhoon.

typhoon dag run --dag-name send_me_a_joke test

Надеюсь, вы получили веселую шутку, отправленную прямо в ваш групповой чат.

Это та же самая команда, которую мы использовали ранее для локального запуска рабочего процесса, но с test в конце, указывающим, что мы хотим запустить ее в удаленной среде. Это вызвало лямбду и показало вам журналы. На самом деле, если быть более точным, он вызвал лямбду, которая затем вызвала другую лямбду, а затем вызвала еще одну лямбду. Почему? Поскольку Typhoon по умолчанию является асинхронным, это означает, что как только функция возвращает или выдает пакет, мы вызываем новую лямбду для его обработки. Это полезно, потому что у вас может быть много задач, выполняющих работу параллельно. Например, представьте, что у вас есть рабочий процесс, который читает CSV-файлы FTP, архивирует их и загружает на S3. Первая задача может перечислить все CSV-файлы на FTP и выдать каждый путь в виде пакета. Затем следующая задача сожмет их, что может занять много времени, но на самом деле мы вызывали новый экземпляр Lambda для каждого пакета, поэтому мы обрабатываем их все параллельно!

Обратите внимание, что, несмотря на то, что рабочий процесс выполнялся с использованием трех лямбда-выражений, вы все равно получили полный журнал в своем терминале. Lambdas может быть сложно отслеживать и отлаживать, но Typhoon пытается упростить этот процесс. Вот почему, когда вы запускаете Typhoon DAG вручную, она ожидает ответа, чтобы распечатать журналы. Каждый вызов, в свою очередь, также будет ожидать ответа от любых Lambda, которые он вызывает, поэтому вы получите полный журнал независимо от того, сколько вызовов Lambda выполнялось в рабочем процессе. Чрезвычайно полезно иметь возможность видеть, правильно ли работает DAG, но это вносит синхронность, поэтому DAG будет работать медленнее. Мы считаем, что это выгодный компромисс для ручных вызовов. Будьте уверены, что когда рабочий процесс запускается по расписанию, он будет работать на полной скорости.

Почему я не могу просто запустить все в одной лямбде?

Отличный вопрос, и нет причин не задавать его, поскольку наш рабочий процесс очень легкий и не выигрывает от параллелизма. Вам просто нужно изменить первые две задачи, чтобы сделать их синхронными с asynchronous: False. Это соответствующая часть кода:

Давайте соберем и развернем код, на этот раз без зависимостей, используя флаг --code.

typhoon dag push --dag-name send_me_a_joke test --code

Вау, это было намного быстрее! Вы можете видеть, что после однократного развертывания рабочего процесса со всеми зависимостями внесение изменений и их развертывание происходит очень быстро и легко. Не стесняйтесь снова запустить DAG, чтобы проверить, как теперь будет вызываться только одна Lambda.

Это слишком хорошо, чтобы быть правдой, могу ли я построить все свои ETL таким образом?

И да, и нет… В зависимости от вашего варианта использования Lambda может подойти, но в настоящее время у этого подхода есть некоторые ограничения:

  • Lambdas может работать только в течение 15 минут. Если у вас есть длительная задача, это не сработает для вас. В будущем мы намерены поддерживать Fargate для выполнения более тяжелых задач и решить эту проблему.
  • Можем ли мы действительно отказаться от планировщика? Мы показали вам утопическое видение будущего ETL. Еще предстоит выяснить, сможем ли мы полностью избежать запуска планировщика, и мы можем столкнуться с суровой реальностью, что если вы хотите реализовать датчики, задачи ограничения скорости и т. д., нам может понадобиться планировщик. Даже если это окажется правдой, это всегда будет добровольно и намного проще, чем традиционное.

Означает ли это, что Тайфун не готов к прайм-тайму?

Конечно, нет! У нас может быть долгий (хотя и захватывающий) путь, чтобы реализовать наше видение испытанного в бою, полностью бессерверного, асинхронного оркестратора рабочих процессов, но AWS — не единственная цель. Typhoon поддерживает компиляцию в собственный код Airflow, самого популярного сегодня оркестратора. Эта функция может преодолеть разрыв между простотой нашего видения и сложной реальностью, в которой мы сейчас живем как инженеры данных.

Мы надеемся, что вы воспользуетесь Typhoon и полюбите простоту нашего видения и развернетесь в Airflow, если текущее состояние развертывания AWS не может удовлетворить ваши потребности.

Убираться

Если вы хотите очистить все ресурсы, созданные в этом руководстве, выполните следующую команду:

terraform plan -var-file =test.tfvars -out =tfplan -destroy terraform apply -destroy tfplan

Спасибо, что следите за нами!

Если вам понравился этот урок, мы надеемся вскоре увидеть вас на https://github.com/typhoon-data-org/typhoon-orchestrator. Проверьте код, оставьте звезду, откройте вопрос или зайдите, чтобы сказать привет в нашем раздоре!

Первоначально опубликовано на https://dev.to 31 марта 2022 г.