Коллеги, здравствуйте! Подскажите пожалуйста, можно ли каким-то образом в PostgreSQL, в

качестве ETL запускать скрипт Python?

Скрипт должен по API получать данные и передавать их в БД.

Зачем запускать скрипт именно в postgres?

Почему бы не использовать airflow, а внутри скрипта питона уже обращаться к СУБД

Рассказываю. Мне необходимо «решение» Python+БД, которое можно использовать как «образ» и по триггеру автоматом разворачивать это решение. Если скрипт Python поместить в саму БД, то условно нужен только образ этой БД. Если их не совмещать, то необходимо уже иметь 2 образа: Python и отдельно БД. И ещё потребуется отлаживать их взаимодействие.

Какая-то экономия на спичках

И что выступает в качестве «спички»? Просто если есть какой-то другой способ разворачивания и запуска «решения» без трудозатрат специалиста, то я только рад узнать как.

Если под образом подразумевается докер образ, то поднимаешь через docker-compose контейнер с базой и ETL (python + скрипт/Airflow + зависимости), в переменных окружения указываешь название базы, в скрипте к ней подключаешься через psycopg2. Все. Если в будущем понадобится что-то дорабатывать, то достаточно будет обновить образ с ETL. Если нужно будет запускать ETL по сложному расписанию, добавлять интеграции с другими базами, инструментами - этот подход гораздо более расширяем. Если ты хочешь делать все это на PL/Python, тебе и так придется устанавливать python, а также устанавливать разные зависимости для работы с API. Вот только обновление процедуры будет требовать хождения в базу под админской учеткой (pl/Python является untrusted языком, обычные пользователи не могут писать на нем процедуры). И более сложные интеграции оно может и не вывести

Либо через docker-compose, как выше предложили, либо через Ansible

Могу посоветовать только найти спецыалиста, который это будет разворачивать и посоветоваться с ним. (Поскольку нет вообще никакой разницы, один там образ, два, питон внутри СУБД или вне её. Всё или разворачивается само или требует пинания руками.).

Замечу, что я бы посоветовал в первую очередь подумать -- нужна ли будет база без этих ETL скриптов. И если нет -- то вообще сделать всё в одном образе, пусть там и питон и postgres лежат. Компоуз тожэ довольно плохое решэние, незачем его тащить без особой необходимости.

Под «образом» что подразумевается?

Контэйнер докера.

Зависит от того, как этот ETL запускается. Если извне (docker exec), то можно и в один контейнер. Если нужен резидентный процесс внутри контейнера (а-ля крон/Airflow), то нужно два контейнера, в один их пихать не стоит. Композ простой, легко учится

В итоге, в самом Postgre можно содержать скрипты Python и запускать их по расписанию или по триггеру?

Композ тупой, и при этом не так легко переносится на kubernetes, как просто docker image.

Не запрещено.

docker-compose не делает ничего кроме того что умеет докер, нету никакой разницы переносить композ или чистый докер

Автор боится двух отдельных образов, а ты кубер предлагаешь)

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

с swarm-ом путаете, композ не умеет ничего, он просто врапер над docker engine api, как в общем то и сам docker cli

Я не предлагаю, я высказываю одну из причин, по которым я композ нелюблю. (Не, я и докер нелюблю, чо уж там). (А к куберу с подозрением отношусь, но всяко лучшэ докера).

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

С отсутствием запрета? Ну, вот например, http://www.constitution.ru/10003000/10003000-4.htm статья 34.

?

Очень не советую так делать. Допустим, это сработает сейчас. А если думать на пару месяцев вперёд? Что если скрипту нужно будет обновить/добавить зависимости? Обновить версию Python? Пересобирать образ и пересоздавать весь контейнер с базой ради одного скрипта?

Да, пожалуй соглашусь. При этом возможно понадобиться переделать всё то, что у же работает, верно?

Выходит, скрипт нужно содержать отдельно.

Сложно сказать наверняка, но вполне вероятно. Допустим, в какая-то из зависимостей сильно поменялась, соответственно скрипт нужно будет дорабатывать

Хорошо. Т.е можно сделать 1 или 2 контейнера - это и будет «решение». Ещё один вопрос. Я чуть-чуть знаком с Docker. Что будет оптимальнее для Azure, Docker или Kubernetes? Или это 2 разных продукта и сравнивать их между собой не стоит? Понимаю, что вопрос может быть задан некорректно, но мне необходимо определиться в какую сторону капать.

Понятия не имею, с Azure не сталкивался

@dolfinus, у меня уточняющий вопрос. Если копировать (разворачивать по триггеру) только БД. Могут ли они все одновременно использовать один скрипт Python?

Я не понимаю, зачем тебе стрелочка из postgres в python

Я предположил, что БД использует Python скрипт как ETL. Соответсвенно, от БД должен быть триггер на выполнение скрипта. Предположим, что у меня 5 версий скрипта Python под разные API запросы. И у меня есть 2 образа БД. Одна БД использует все 5 скриптов Python. Вторая - только один. Соотвественно, именно на стороне БД должнен быть триггер. Логично? Или что-то нужно учесть?

Зачем postgres сам запускает ETL, почему не скрипт запускается чем-то типа крона и перекладывает данные из API в Postgres? Как ты собрался запускать скрипт из Postgres, который лежит в другом контейнере?

Зачем Postgre сам запускает ETL? - разве ETL процедура запускается не в БД? Исходя из Ваших сообщений, я понимаю, что эта логика нивелируется, если ETL выполняется «на стороне».

Зачем она должна запускаться на стороне БД? Какую проблему ты хочешь этим решить?

«Как ты собрался запускать скрипт из Postgres, который лежит в другом контейнере?» - это невозможно? Т.е. это ограничение.

Это возможно, но не нужно, поскольку ломает основную логику контейнеров - воспроизводимое поведение, доставка приложения вместе зависимостями, изоляция окружения

Я выше описал: Предположим, что у меня 5 версий скрипта Python под разные API запросы. И у меня есть 2 образа БД. Одна БД использует все 5 скриптов Python. Вторая - только один. Т.е. есть условие, что могут быть созданы разные конфигурации БД. Эти разные конфигурации БД должны получать данные от разных Скриптов Python. Где содержать подобную логику?

Начнем сначала. Что должно триггерить твой ETL? Что, откуда и куда он должен перекладывать?

Подключаться по API к интернет-сервису и получать оттуда данные по API. Возможно предварительно нормализовав.

Триггерить его должно что? Какое-то действие в базе, запуск по расписанию?

Запуск по расписанию.

И зачем тогда вызывать скрипт из базы?

Потому что именно в БД будет заложена логика того, какие таблицы / данные в неё должны поступать.

Что?

Расскажу на примере. Представим, что есть 2 скрипта Python. Первый: собирает информацию по погоде. Второй: собирает информацию по объёмам продаж сахара. Представим, что у нас есть 2 образа БД. Первый: для того, чтобы содержать информацию по погоде. Второй: для того, чтобы содержать информацию по погоде и по сахару. Разворачиваем 2 БД на основании образов. Первая БД обращается к первому скрипту Python. Вторая БД обращается к первому и второму скрипту Python. Т.о. логика запуска скрипта находится на стороне БД. Верно?

Зачем она должна быть в БД? Почему не запускать по расписанию скрипт (где угодно и как угодно) и передавать в скрипт (через аргументы или конфиг) данные для подключения к API и БД, чтобы он и тянул инфу, и складывал ее в нужную базу? Зачем для всего этого нужно что-то делать на уровне самой базы? С чего база вообще должна что-то знать о том, откуда в нее приходят данные?

Может быть и так, Максим. Я не бью себя в грудь и не отстаиваю ни один из подходов. Я просто хочу знать мнение сообщества на подобные задачи. Спасибо Вам за обратную связь! Я сейчас поищу ссылку на один сервис, предлагаю порассуждать над тем, что там под капотом.

@dolfinus, пример сервиса (другой не вспомнил): https://www.cdata.com/drivers/

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

Хорошо. Вот представим, что я зарегистрировался на этом сервисе. И попросил их передавать для меня данные из Google аналитики. Они развернут под меня БД (есть такие, что могут дать доступ к БД, я что-то подобное видел) и предоставят к ней доступ. Может быть я не смогу в этой БД, что-то делать, но данные забрать смогу. Как это примерно организовано?

У Вас на примете какие-то есть? Можно ссылку?

Airflow

Тянешь скриптом данные из одной базы и перекладываешь в другую

Т.е. во всей архитектуре, должен быть "скрипт-администратор", который знает в какую БД какие данные необходимо записывать. Этот "скрипт-администратор" запускает соотвествующие скрипты для разных БД. Верно?

Именно это и представляет собой Airflow, он оркестрирует ETL, знает что, когда и с какими параметрами запускать

Благодарю!