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
6 шагов, позволяющих избежать беспорядка данных в хранилище
📎 Введение
В большинстве компаний с данными полный бардак. Команды, отвечающие за работу с данными, сталкиваются с множеством проблем, таких как ручное редактирование таблиц, дублирование определённых метрик, некорректные исходные данные, отсутствие управления данными, отсутствие инфраструктуры и т.д. Если тебе в голову приходят такие мысли как:
Тогда цикл следующих постов для тебя! Представь себе, что твоё хранилище данных работает как хорошо отлаженная машина с правильными данными и очень простое в использовании! Твоя работа будет приносить удовлетворение, а карьерный рост будет быстрым - именно на это нацелен этот цикл.
Рассмотрим шесть важнейших шагов по созданию (и поддержке) хранилища данных, которое предоставляет заинтересованным сторонам всё, что им может понадобиться, и при этом позволяет избежать бардака в данных.
В большинстве компаний с данными полный бардак. Команды, отвечающие за работу с данными, сталкиваются с множеством проблем, таких как ручное редактирование таблиц, дублирование определённых метрик, некорректные исходные данные, отсутствие управления данными, отсутствие инфраструктуры и т.д. Если тебе в голову приходят такие мысли как:
Интересно, в каждой ли компании до сих пор царит неразбериха с данными?
Надеюсь найти лучшее место для работы с более совершенными методами обработки данных.
Верю в существование аналитических хранилищ, которые представляют собой сплошной кошмар.
Ищу работу в надежде найти мифическую “зрелую организацию”, где научусь всё делать правильно.
Считаю, что хранилище данных - это повсеместное дерьмо.
Тогда цикл следующих постов для тебя! Представь себе, что твоё хранилище данных работает как хорошо отлаженная машина с правильными данными и очень простое в использовании! Твоя работа будет приносить удовлетворение, а карьерный рост будет быстрым - именно на это нацелен этот цикл.
Рассмотрим шесть важнейших шагов по созданию (и поддержке) хранилища данных, которое предоставляет заинтересованным сторонам всё, что им может понадобиться, и при этом позволяет избежать бардака в данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥5
Хотя некоторые из приведённых ниже разделов не являются техническими, их выполнение позволит команде разработчиков (например DE) получить больше ресурсов (времени и/или денег), что поможет тебе избежать путей, которые могут приводить к беспорядку в данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥3