dbt-af

🔥 Подход к интеграции dbt и airflow. Ребята недавно заопенсорсили либу. Есть туториал.

Можно накидывать ишью, препарировать в форках, использовать, ставить звёздочки ⭐️

#dbt #airflow

DuckDB in action 🦆

Команда MotherDuck предлагает бесплатный PDF-файл с ранним доступом к книге "DuckDB в действии". Первые несколько глав помогут понять основы DuckDB, и со временем авторы будут добавлять новые главы [по таким темам, как интеграция с Python, WASM, пайплайны передачи данных], которые будут высланы бесплатно.

В DuckDB легко обрабатывать гигабайты данных — и всё это без хранилища данных. Звучит как кликбейт, но надо проверить 🙃

Обещают, что не нужно дорогостоящее оборудование или развёртывание целого нового кластера, когда нужно проанализировать большой набор данных. Просто нужен DuckDB! Современная и быстрая встроенная БД работает на ноуте и позволяет легко обрабатывать данные практически из любого источника, включая JSON, CSV, Parquet, SQLite и Postgres. В DuckDB in action описано всё, что нужно знать, чтобы максимально эффективно использовать этот инструмент, обеспечить безопасность данных локально и сэкономить сотни долларов на счетах за облако. Верим? 🙂

Книгу можно скачать с сайта MotherDuck

#book

Learn Streaming Data Fundamental with Redpanda

Отличный способ изучить основы потоковой передачи данных — запишись в Университет Redpanda для бесплатного онлайн-обучения. Курсы включают в себя 8 уроков и заканчиваются небольшим квизом.

Начни с курса «Основы потоковой передачи данных», чтобы получить прочную базу знаний в этой области. Помимо этого есть более продвинутые курсы, такие как управление кластерами. ⚡️

Redpanda это аналог Kafka, что обещает сервис?

🟡 никакой java – сервис написан на c++ с тулингом на go. На выходе у нас 2 бинарных файла и всё
🟡полная совместимость с протоколом Apache Kafka. Ни надо ничего переписывать на стороне клиентов, подмены транспорта никто не заметит
🟡своя реализация raft протокола – не нужны никакие сторонние сервисы
🟡очень эффективное использование ресурсов – это общий тренд такого рода инструментов-заместителей
🟡самостоятельное лечение кластера при потерях брокеров
🟡встроенная schema registry и http proxy

✏️ Полезные SQL-запросы для очистки данных


1️⃣ Удаляем дубликаты записей

DELETE FROM your_table
WHERE rowid NOT IN (
    SELECT MAX(rowid)
    FROM your_table
    GROUP BY column1, column2, ...
);

2️⃣ Удаляем строки с NULL-значениями

DELETE FROM your_table
WHERE column1 IS NULL OR column2 IS NULL;

3️⃣ Заменяем NULL-значения на дефолтное выражение

UPDATE your_table
SET column1 = 'default_value'
WHERE column1 IS NULL;

4️⃣ Переводим текст в верхний регистр

UPDATE your_table
SET column1 = UPPER(column1);

5️⃣ Обрезаем лишнее

UPDATE your_table
SET column1 = TRIM(column1);

6️⃣Конвертируем строки в формат дат

UPDATE your_table
SET date_column = TO_DATE(date_string, 'YYYY-MM-DD');

7️⃣ Извлекаем год/месяц/день

SELECT EXTRACT(YEAR FROM date_column) AS year,
       EXTRACT(MONTH FROM date_column) AS month,
       EXTRACT(DAY FROM date_column) AS day
FROM your_table;

⏩Эти запросы могут помочь тебе привести данные в порядок.

🌟 RisingWave - Масштабируемый Postgres для потоковой обработки, аналитики и управления. Альтернатива KsqlDB и Apache Flink.

🚀 В 10 раз производительнее.
🚀 В 10 раз экономичнее.

Завтра пройдёт воркшоп по работе с инструментом.

👩‍💻 Чистый SQL-код

Ты можешь писать SQL так:

coalesce("Фамилия", '') || ' ' || coalesce("Имя", '') || ' ' || coalesce("Отчество", '')

Но лучшая версия тебя будет использовать функцию concat_ws:

concat_ws(' ', "Фамилия", "Имя", "Отчество")

#база #sql

Dolt — первая в мире база данных SQL с системой контроля версий.

Управление версиями в БД в стиле Git предоставляет ряд полезных функций, включая:

🔘мгновенный откат к любому предыдущему состоянию
🔘полный лог аудита всех данных с возможностью запроса до начала работы с данными
🔘несколько эволюционирующих веток данных
🔘возможность объединения веток данных
🔘быстрая синхронизация с удаленными версиями для резервного копирования или децентрализованной совместной работы
🔘доступные для запроса различия (т.е. diffs) между версиями


Под капотом Dolt использует Prolly Tree-хранилище схемы и данных, представленных в виде графа. Таким образом достигается контроль версий БД на уровне хранилища.

Механизм хранения Dolt построен на графе коммитов Prolly Trees в стиле Git. Схема таблицы и данные хранятся в Prolly Trees. Корни этих деревьев Prolly вместе с другими метаданными хранятся в графе коммитов, чтобы обеспечить контроль версий в стиле Git.

Блогпост о движке Dolt.

Методы оптимизации SQL-запросов в высоконагруженных приложениях

Успех высоконагруженных приложений зависит от эффективной работы БД, лежащих в их основе. По мере роста сложности SQL-запросов, особенно тех, которые включают в себя сложные соединения и проблемы индексирования, оптимизация запросов приобретает первостепенное значение.

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

👇👇👇

1️⃣ Ключевые аспекты плана выполнения запроса

2️⃣ Продвинутые стратегии индексирования

3️⃣ Переписывание и оптимизация запросов

4️⃣ Денормализация данных для повышения производительности

5️⃣ Использование временных таблиц для оптимизации запросов

6️⃣ Оптимизация подзапросов и агрегаций

7️⃣ Избегай курсоров и циклов для повышения производительности

1️⃣-й пост из цикла.

Ключевые аспекты плана выполнения запроса


🟢 Использование индексов:

Обрати пристальное внимание на индексы, используемые в плане выполнения. Убедись, что для столбцов, участвующих в выражениях WHERE, условиях JOIN и выражениях ORDER BY, доступны соответствующие индексы. Если индексы используются не так, как ожидалось, подумай о создании покрывающих индексов или пересмотри дизайн индексов.

🟢 Типы соединений:

В плане выполнения показано, как происходит соединение таблиц. Определи используемые типы соединений (например, NNER JOIN, LEFT JOIN) и оцени влияние на производительность. Убедись, что условия соединения оптимизированы и подходят для данного запроса.

🟢 Операции фильтрации и сортировки:

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

🟢 Вложенные циклы против хэш-соединений:

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

〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️

Использование EXPLAIN для анализа запросов

В большинстве баз данных SQL для анализа плана выполнения можно использовать оператор EXPLAIN:

EXPLAIN
SELECT *
FROM orders
WHERE true
  AND customer_id = 123
  AND order_date BETWEEN '2023-01-01' AND '2023-06-30';

Внимательно изучи результаты работы EXPLAIN, уделяя внимание вышеупомянутым аспектам. Ищи узкие места в производительности, операции сканирования таблиц и возможности использования индексов.

Помимо изучения текста ответа удобно использовать визуализаторы планов запросов, об одном из таких писал в одном из своих предыдущих постов.

2️⃣-й пост из цикла.

Продвинутые стратегии индексирования

Оптимизация индексов — способ повысить производительность запросов. Помимо стандартного индексирования, давай рассмотрим продвинутые техники.


🟡 Пересмотр покрывающих индексов

В дополнение к покрывающим индексам рассмотри использование столбцов INCLUDE, позволяющее охватить больше сценариев запросов. Включённые столбцы хранятся в индексе, но не используются для сортировки или фильтрации. Они могут ускорить выполнение запроса за счёт уменьшения необходимости поиска в таблице.

CREATE INDEX idx_covering
ON products (product_id)
INCLUDE (product_name, unit_price);

С этим индексом запрос, упомянутый ранее, может получить ещё больше преимуществ от покрытия индекса.

🟡 Частичные индексы для отфильтрованных данных

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

CREATE INDEX idx_region_orders 
ON orders (order_date)
WHERE region = 'West';

Этот отфильтрованный индекс фокусируется на заказах из региона 'West', улучшая производительность запроса для этого условия.

🟡 Стратегии индексирования для соединений

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

Dagster University - Dagster & dbt

✏️ Бесплатный онлайн курс по Dagster и dbt.

В курсе ты узнаешь, как интегрировать dbt и управлять проектами dbt с помощью Dagster. Ты загрузишь модели dbt в Dagster в качестве assets, создашь зависимости и подготовишь свой проект к production deployment.

3️⃣-й пост из цикла.

Переписывание и оптимизация запросов

Переписывание запросов подразумевает преобразование запросов в эффективные эквивалентные формы. Это мощная техника для повышения производительности запросов. Давай рассмотрим её подробнее.


🟣 Пересмотр подзапросов к JOIN'ам

Важно учитывать природу подзапроса. Некоторые подзапросы лучше оставить как подзапросы, если они включают коррелированные или антикоррелированные подзапросы. Важно проанализировать каждый случай и определить, что больше подходит — JOIN или подзапрос. Например:

Оригинальный подзапрос:

SELECT * 
FROM employees
WHERE department_id IN (
    SELECT department_id 
    FROM departments 
    WHERE region = 'West'
);

Переписан с использованием JOIN:

SELECT e.* 
FROM employees e
INNER JOIN departments d 
ON e.department_id = d.department_id
WHERE d.region = 'West';

JOIN часто эффективнее подзапросов, что приводит к улучшению выполнения запросов.

🟣 Общие табличные выражения (CTE) и рекурсивные запросы

CTE предоставляют удобный способ упростить сложные запросы и улучшить их читаемость. Кроме того, CTE могут помочь оптимизировать рекурсивные запросы, когда запрос ссылается сам на себя, чтобы обойти иерархические данные. Например:

WITH RecursiveCTE AS (
    SELECT employee_id, first_name, manager_id, 0 AS depth
    FROM employees
    WHERE manager_id IS NULL
    UNION ALL
    SELECT e.employee_id, e.first_name, e.manager_id, rc.depth + 1
    FROM employees e
    INNER JOIN RecursiveCTE rc
    ON e.manager_id = rc.employee_id
)
SELECT * FROM RecursiveCTE;

Этот рекурсивный CTE извлекает сотрудников и менеджеров в иерархической структуре, показывая глубину иерархии.

🟣 Ограничение наборов результатов с помощью OFFSET-FETCH

При работе с большими наборами результатов можно использовать условие OFFSET-FETCH (или эквивалентный синтаксис в твоём диалекте SQL), чтобы ограничить количество возвращаемых строк. Это удобно для страничных запросов, в которых ты получаешь подмножество строк на каждой странице:

SELECT * 
FROM products
ORDER BY product_name
OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;

Этот запрос извлекает строки с 21 по 30 из таблицы products, упорядоченные по названию продукта.

Серьёзный конкурент DuckDB 🦆

Ты уже видел аналог DuckDB от ребят из ClickHouse? Называется это чудо chDB. Представляет из себя встроенную OLAP базу данных под капотом которой работает движок ClickHouse. Умеет в Parquet, Arrow, ORC и многие другие форматы, есть биндинги для Python, Go, Rust, NodeJS, Bun. Работает на Linux и MacOS, Windows не поддерживает.

Подробности в новости о том, что chDB присоединяется к ClickHouse

🔜 С момента выхода psycopg3 прошло уже почти три года. Несмотря на это, многие проекты до сих пор предпочитают использовать версию psycopg2, и причин у этого может быть масса. Однако недавно привлекли моё внимание результаты сравнения производительности этих двух версий, и мне кажется, они заслуживают отдельного поста.


➡️ Сравнительный анализ показал, что psycopg3 опережает psycopg2 в три раза по скорости выполнения простых SELECT FROM запросов. Это значительное улучшение, которое может сыграть ключевую роль для проектов, опирающихся на интенсивное чтение данных из базы. Таким образом, для большинства разработчиков переход на новую версию может стать не просто желательным, но и полезным шагом в плане оптимизации своих приложений.


🔜 Тем не менее, в более специфических случаях, таких как пакетная запись данных или извлечение blob-объектов, psycopg2 показывает себя лучше. Это указывает на то, что новая версия, несмотря на значительные улучшения в некоторых областях, может пока не подходить для всех сценариев использования.


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

〰️〰️〰️〰️〰️〰️〰️〰️

Подробнее о сравнении psycopg2 и psycopg3 ты можешь прочитать на Timescale, где обсуждаются эти результаты и предлагаются размышления о том, как выбор версии может влиять на ваши проекты.