Please open Telegram to view this post
VIEW IN TELEGRAM
🎉7👍1😁1👨💻1
Superset 2.1.1 LTS
While that new (3.0.0) major release has been tested fairly extensively, 2.1.1 is officially our “stable” release and will continue to receive patches alongside 3.0. Superset 2.X will continue to receive such patches at least until the release of Superset 3.1.0 or 4.0.0 in the future.
https://preset.io/blog/superset-2-1-1-a-more-secure-and-stable-patch-release/
While that new (3.0.0) major release has been tested fairly extensively, 2.1.1 is officially our “stable” release and will continue to receive patches alongside 3.0. Superset 2.X will continue to receive such patches at least until the release of Superset 3.1.0 or 4.0.0 in the future.
https://preset.io/blog/superset-2-1-1-a-more-secure-and-stable-patch-release/
Forwarded from DataEng
Run periodic jobs in PostgreSQL
Недавно открыл для себя интересное расширение для БД PostgreSQL: pg_cron. Балалайка позволяет запускать периодические задачи внутри базы данных: SQL запросы, процедуры и т.д. Удобно, вдруг кому пригодится 💡
Недавно открыл для себя интересное расширение для БД PostgreSQL: pg_cron. Балалайка позволяет запускать периодические задачи внутри базы данных: SQL запросы, процедуры и т.д. Удобно, вдруг кому пригодится 💡
GitHub
GitHub - citusdata/pg_cron: Run periodic jobs in PostgreSQL
Run periodic jobs in PostgreSQL. Contribute to citusdata/pg_cron development by creating an account on GitHub.
Forwarded from DataEng
На Хабре вышла статья про Airflow в Kubernetes. Статья мне понравилась, целевая аудитория это новички в кубах, которые хотят развернуть Airflow. Сам я такой деплой не использую, но мне было полезно знать как оно там работает. Напомню, что у Airflow есть официальный helm chart: https://airflow.apache.org/docs/helm-chart/stable/index.html, если вдруг вы решите копнуть эту тему чуть глубже.
Хабр
Airflow в Kubernetes. Часть 1
Приветствую! На пути инженера данных часто встречаются задачи связанные с DevOps. Одна из таких - развернуть Airflow в Kubernetes кластере. Если до этого похожего опыта работы не было, то эта задача...
❤🔥2
Про пулы в Airflow
Celery использует разные способы выполнения задач, которые называются пулами (pools). Стандартным пулом является prefork. Каждая задача в этом пуле выполняется в отдельном процессе, поэтому память может быть затрачена, особенно на виды работ, которые занимают в основном время ожидания.
Введение gevent/eventlet в состав Celery дало возможность использовать зеленые потоки (green threads) вместо процессов. Зеленые потоки - это корутины, по сути - легковесные потоки, которые многократно снижают использование памяти в режиме ожидания.
Переход на gevent/eventlet довольно простой процесс, нужно указать опцию -P gevent или -P eventlet при запуске воркера Celery. Но есть одно "но" - это работает только с кодом, который не блокируется. Если у вас есть блокирующий код, который не может быть асинхронным, тогда это может вызвать проблемы. Поэтому перед переходом убедитесь, что ваш код подходит для асинхронных параметров.
Теперь о pool=threads. В Celery, threads pool (-P threads) - это другой тип пула, который использует потоки, а не процессы. Использование потоков может снижать использование памяти, т.к. они разделяют эту память, а не создают новую в каждом процессе, как это происходит в prefork. Однако, задачи в потоках будут разделять те же системные ресурсы и блокировки GIL (Global Interpreter Lock) как и основной процесс. По этой причине, threads pool часто используются для I/O-bound типов работ или тех, которые много времени проводят в ожидании данных. Но с обычными проблемами синхронизации при работе с потоками стоит быть осторожным.
И как всегда, важно не забывать!Airflow предназначен для выполнения кода по расписанию, а не для выполнения нескольких задач одновременно. Если вам нужно выполнять много задач одновременно, возможно, стоит рассмотреть другие инструменты, такие как Dask или Ray.
Celery использует разные способы выполнения задач, которые называются пулами (pools). Стандартным пулом является prefork. Каждая задача в этом пуле выполняется в отдельном процессе, поэтому память может быть затрачена, особенно на виды работ, которые занимают в основном время ожидания.
Введение gevent/eventlet в состав Celery дало возможность использовать зеленые потоки (green threads) вместо процессов. Зеленые потоки - это корутины, по сути - легковесные потоки, которые многократно снижают использование памяти в режиме ожидания.
Переход на gevent/eventlet довольно простой процесс, нужно указать опцию -P gevent или -P eventlet при запуске воркера Celery. Но есть одно "но" - это работает только с кодом, который не блокируется. Если у вас есть блокирующий код, который не может быть асинхронным, тогда это может вызвать проблемы. Поэтому перед переходом убедитесь, что ваш код подходит для асинхронных параметров.
Теперь о pool=threads. В Celery, threads pool (-P threads) - это другой тип пула, который использует потоки, а не процессы. Использование потоков может снижать использование памяти, т.к. они разделяют эту память, а не создают новую в каждом процессе, как это происходит в prefork. Однако, задачи в потоках будут разделять те же системные ресурсы и блокировки GIL (Global Interpreter Lock) как и основной процесс. По этой причине, threads pool часто используются для I/O-bound типов работ или тех, которые много времени проводят в ожидании данных. Но с обычными проблемами синхронизации при работе с потоками стоит быть осторожным.
И как всегда, важно не забывать!
❤🔥2