Лучшая практика для организации небольшой задачи python (в основном это выполнение SQL в BigQuery)

Question

Мы используем функции pubsub и cloud в GCP для организации нашего рабочего процесса данных.

Наш рабочий процесс выглядит примерно так:

workflow_gcp

pubsub1 и pubsub3 может быть запущен в разное время (например, 1:00 и 4:00). Они запускаются ежедневно из внешнего источника (наш ETL, Talend).

Наши облачные функции в основном выполняют SQL в BigQuery.

Это работает хорошо, но нам пришлось вручную создать базу данных оркестровки, чтобы регистрировать, когда функции начинаются и заканчиваются (чтобы ответить на вопрос «функция X выполнена нормально?»). И логика оркестровки c тесно связана с нашей бизнес-логикой c, поскольку наша облачная функция должна знать, какие функции необходимо выполнить до, а какой pubsub вызывать после.

Итак, мы ищем для решения, которое разделяет логики оркестровки c и бизнес-логики c.

Я обнаружил, что composer (поток воздуха) может быть решением, но:

• он не может запускать облачную функцию изначально (а с API он очень ограничен, 16 вызовов по 100 секунд на проект)

• мы можем использовать BigQuery внутри воздушного потока с операторами BigQuery, но логика оркестровки и бизнес-логики снова будут тесно связаны

Так что же является лучшим опытом в нашем случае?

Спасибо за вашу помощь

Answer 1

В качестве альтернативы воздушному потоку я бы посмотрел на "ar go workflows" -> https://github.com/argoproj/argo

Это не связано с накладными расходами, которые composer имеет, особенно для небольших рабочих нагрузок.

У меня будет:

Создано развертывание, которое читает сообщения pubsub из внешнего инструмента и развернуто в kubernetes.

На основании сообщения, выполненного рабочим процессом. Каждый шаг в рабочем процессе может быть облачной функцией, упакованной в docker.

(я бы заменил облачную функцию на задание kubernetes, которое затем запускается рабочим процессом.)

Довольно просто упаковать облачную функцию с помощью docker и запустить ее в kuberentes.

Существуют предварительно созданные docker изображения с помощью gsutil / bq / gcloud, так что вы можете создавать bash сценарии, которые использует командную строку "bq" для выполнения вещи внутри bigquery.

Answer 2

Вы можете использовать Cloud Composer (Airflow) и по-прежнему повторно использовать большинство существующих настроек.

Во-первых, вы можете сохранить все существующие облачные функции и использовать HTTP-триггеры (или другие, которые вы предпочитаете) для запуска их в Airflow. Единственное изменение, которое вам нужно будет сделать, - внедрить датчик PubSub в Airflow, чтобы он запускал ваши облачные функции (следовательно, вы можете контролировать оркестровку от начала до конца вашего процесса).

Вашим решением будет Airflow DAG , который запускает облачные функции на основе сообщений PubSub, сообщает Airflow, если функции были успешными, а затем, если обе были успешными, запускает третью Облачная функция с HTTP-триггером или аналогичным, точно такая же.

Последнее замечание, которое не является интуитивно понятным. Воздушный поток не предназначен для запуска самих заданий, он предназначен для организации и управления зависимостями. Тот факт, что вы используете облачные функции, запускаемые Airflow, не является анти-паттерном, на самом деле это лучшая практика.

В вашем случае вы могли бы на 100% переписать несколько вещей и использовать операторы BigQuery, так как вы не выполняете никакой обработки, просто запускаете запросы / задания, но концепция остается верной, лучшая практика - используя Airflow, чтобы убедиться, что все происходит, когда и в нужном вам порядке, а не обрабатывать эти вещи самостоятельно. (Надеюсь, это имело смысл)