DuckLake: SQL as Lakehouse Format

DuckDB запустил новый открытый табличный формат!

Чтобы устранить фундаментальные проблемы существующей архитектуры Lakehouse, DuckDB создали новый открытый табличный формат под названием DuckLake.

Основной принцип DuckLake - перенос всех метаданных в SQL-базу данных, как для каталога, так и для табличных данных.

Таким образом, больше нет разделения на каталог + метаданные + данные.

Только DuckLake + данные.

@data_whisperer

Data Engineering Design Patterns

O’REILLY выпустили свежую книгу с очень многообещающим названием:
"Data Engineering Design Patterns" (Шаблоны проектирования в инженерии данных).

Автор: Bartosz Konieczny - опытный фриланс Data Engineer, энтузиаст Apache Spark, работает со Scala & Python.
Делится знаниями в блоге waitingforcode.com.

В чем суть и почему это важно?

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

Эта книга - практическое руководство, которое учит поставлять реально ценные данные, фокусируясь на ключевых аспектах:

• Сбор данных
• Качество данных
• Идемпотентность

Главная ценность:
Перестаньте изобретать велосипед!
Узнайте проверенные шаблоны проектирования, которые экономят время, снижают ошибки и повышают эффективность ваших data-проектов.

upd: Книгу еще не читал, но в предисловии отметились известные люди из мира data engineering.

Maxime Beauchemin, original creator of Apache Airflow and Superset

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

Matt Housely, coauthor, Fundamentals of Data Engineering

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

dbt FUSION engine (BETA)

Отличная новость для всех, кто работает с dbt!
Команда dbt Labs анонсировала революционный dbt Fusion Engine и новое расширение для VS Code.
Это большой шаг вперед!

dbt Fusion Engine: Скорость и Надежность на Rust

• Переписан с нуля: Полная переработка движка выполнения dbt Core на принципиально новой основе.
• Настоящая скорость: Написан на Rust и скомпилирован в единый бинарник для максимальной производительности.
• Улучшенная корректность: Строже соблюдает спецификации dbt, автоматически выявляя и исправляя неоднозначности (помощь dbt Autofix).
• Глубокое понимание SQL: Нативно работает с разными диалектами SQL (BigQuery, Snowflake, Redshift и др.).
• Современные драйверы: Использует ADBC для быстрых и эффективных подключений к хранилищам данных.
• Простая установка: Легко ставится локально, в Docker или облаке как самодостаточный бинарник без лишних зависимостей.

Новое Расширение dbt для VS Code: Мощь в вашем редакторе

• Не просто синтаксис: Это полноценный языковой сервер (Language Server) для dbt.
• Умные подсказки: Автодополнение моделей, источников, макросов, колонок – прямо в коде.
• Предпросмотр: Визуализация скомпилированного SQL/Core для моделей, анализаторов, тестов.
• Валидация на лету: Раннее обнаружение ошибок в dbt_project.yml, schema.yml и других конфигах.
• Интеграция с Fusion: Задумано для будущей глубокой интеграции с движком Fusion (ускорит работу расширения).

Почему это прорыв?

• Производительность: Rust + бинарник = значительно быстрее выполнения проектов dbt.
• Надежность: Строгая проверка = меньше скрытых ошибок в пайплайнах.
• Удобство разработки: VS Code расширение кардинально улучшает опыт написания кода dbt.
• Современная архитектура: Заложен фундамент для будущих инноваций.

Движок Fusion выкатывается постепенно в открытый репозиторий. Расширение для VS Code уже доступно!
Обязательно к прочтению для всех, кто использует dbt:

👉 Читать полную статью на getdbt.com

@data_whisperer

ConnectorX: Самая быстрая библиотека для загрузки данных из БД в DataFrames

Хотите молниеносно загружать данные из баз данных в Python?

ConnectorX - ваш выбор.
Эта библиотека, написанная на Rust, использует принцип zero-copy, обеспечивая максимальную производительность и минимальный расход памяти.

- Скорость: до 21x быстрее и использует до 3x меньше памяти по сравнению с Pandas.

- Эффективность: данные копируются ровно один раз - прямо из источника в DataFrame.

- Параллелизм: разбивает запросы на части и загружает их одновременно с помощью многопоточности.

- Экспериментально: поддержка federated query для PostgreSQL - объединяйте таблицы из разных БД в одном запросе! (пока без партиционирования)

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

import connectorx as cx
# Простая загрузка
df = cx.read_sql("postgresql://user:pass@server:port/db", "SELECT * FROM table")
# Параллельная загрузка с партиционированием
df = cx.read_sql("postgresql://user:pass@server:port/db", "SELECT * FROM table", partition_on="id", partition_num=10)

Поддерживает:
PostgreSQL, MySQL, SQLite, MSSQL, Oracle

DataFrames: Pandas, Arrow, Modin, Dask, Polars.


@data_whisperer

Apache Gravitino - это высокопроизводительное, геораспределённое и федеративное озеро метаданных. Оно управляет метаданными непосредственно в различных источниках, типах и регионах, предоставляя пользователям унифицированный доступ к метаданным для данных и AI.

Lakekeeper Catalog for Apache Iceberg

Lakekeeper - это Apache Iceberg REST Catalog,
написанный на Rust и доступный под открытой Apache License 2.0.
Он создан, чтобы стать надежным фундаментом для Lakehouse, объединяя хранение, вычисления и управление метаданными.

Lakekeeper решает ключевые задачи современных data-инфраструктур, такие как управление распределенными метаданными и обеспечение безопасности данных, открывая путь к более эффективным и управляемым Lakehouse.

@data_whisperer

AI Dev Tools Zoomcamp

Бесплатный курс по использованию ИИ-инструментов в разработке.

Курс официально запускается! Репозиторий уже готов и будет наполняться новым контентом.

Это проект в стадии разработки, так что вы ещё можете заполнить форму ранней регистрации и предложить, какие темы вы хотите видеть в курсе!

🔗 Регистрация

P.S
А пока можете посмотреть видео как создать DLT проект с помощью Cursor.

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

dlt ai setup cursor



Думаю, что в ближайшее время и остальные инструменты из мира данных будут добавлять такую фичу.

@data_whisperer

Snapchat Data Tech Stack

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

Масштабы поражают:

• 4+ ТБ данных каждый день в BigQuery
• 1.8 ТРИЛЛИОНА событий в пик
• 200+ ПБ данных в хранилище (30k GCS бакетов!)
• 5 миллиардов Snaps ежедневно
• 3,000 DAGs в Airflow с 330,000 задач ежедневно

На чем все держится?

Платформа:

• Google Cloud Platform (GCP): Вся инфраструктура данных Snapchat построена на GCP.

Как данные попадают в систему?

• Pub/Sub (GCP): Главный "
вход для потоковых событий в реальном времени. Масштабируется мгновенно.

Как данные обрабатываются?

• Apache Beam (через GCP Dataflow): Обработка и потоковых, и пакетных данных.

• Apache Spark (через GCP Dataproc): Основа для генерации фичей в рекомендательных системах.

Как всем этим управляют?

• Apache Airflow: состоянию на 2024 год Snap использует более 3000 DAG,
которые ежедневно выполняют более 330 000 экземпляров задач, охватывающих ETL, отчетность/аналитику, машинное обучение и многое другое.

Где хранятся и анализируются данные?

• BigQuery: Центральное хранилище данных. Куда стекаются все события. Используется для аналитики и ad-hoc запросов.

• Lakehouse (GCS + Apache Iceberg): Наряду с централизованным хранилищем данных Snapchat использует архитектуру lakehouse, объединяя Google Cloud Storage (GCS) с Apache Iceberg. Это позволяет им эффективно получать доступ к большим наборам данных без дублирования в BigQuery.

Благодаря интеграции BigLake данные GCS становятся напрямую доступны в BigQuery, предоставляя пользователям нативный опыт.
Команды машинного обучения являются одними из основных пользователей Lakehouse на своей платформе Bento.

Как визуализируют и принимают решения?

• Looker: Ключевой инструмент для дашбордов и data-driven решений по всей компании. Глубокая интеграция с BigQuery.

Snapchat демонстрирует глубокую интеграцию с GCP для решения экстремальных задач по объему и скорости данных. Комбинация managed-сервисов (Pub/Sub, Dataflow, Dataproc, BigQuery, Dataplex, Looker) и гибких OSS-решений (Airflow, Spark, Beam, Iceberg) позволяет им справляться с невероятными масштабами.

@data_whisperer

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

PandasAI позволяет общаться с базой данных или озером данных (SQL, CSV, parquet), делая анализ данных с использованием LLM и RAG.

Heimdall - новый инструмент для оркестрации данных

Heimdall - легковесная платформу для оркестрации данных и выполнения задач, которая абстрагирует сложную инфраструктуру, предоставляя единый API.

▫️ Абстрагирует сложность инфраструктуры
▫️ Единый API для управления задачами
▫️ Безопасность без риска утечки credentials

Ключевые возможности:

• Синхронное и асинхронное выполнение задач
• Плагинная архитектура: Shell, Glue, Snowflake, Spark, DynamoDB, Ping
• REST API + Web UI для визуального управления
• Динамическая маршрутизация по командам/кластерам
• Умная очередь задач

Изначально вдохновлен Netflix Genie, но расширен:

• Поддержка pluggable-команд
• Гибкие режимы выполнения
• Будущий функционал саморегистрирующихся кластеров

The Modern Data Stack Is a Dumpster Fire

Автор поста разносит в пух и прах культ сложности в data-инфраструктуре. В своем посте он рассказывает суроваю правду, которую не покажут вендоры:

Проблема №1: Инструментальный Ад (или Собираем пазл вслепую)

Знакомо? Начинаете не с задачи бизнеса, а с выбора 15 крутых инструментов (Fivetran, Airbyte, dbt, Airflow, Snowflake ).
Перенести CSV-шку превращается в квест через 10 сервисов. На выходе - машина Руба Голдберга для отчетов.
Итог: Красивые презентации, ноль пользы. А фрагментация? Это не баг, ребята, это фича вендорской бизнес-модели!

Проблема №2: Цена Безумия

• Облачные счета выше выручки? Не шутка. Налог на интеграцию – это не только деньги, но и:
◦ Недели на добавление нового источника.
◦ Часы тупой отладки в 5 разных интерфейсах, чтобы поправить одну цифру в дашборде.
◦ Реальная история: $400K и полгода за 3 дашборда. А конкурент на DuckDB + Python сделал это за неделю и выиграл тендер.

Проблема №3: AI-Powered как маркетинговый шум:

Изначально современный стек данных - это уже сложная, перегруженная и дорогая система "помойка на колесах".

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

Миф: Вам Нужны Big Data и Сложный Стек

• 90% компаний работают со средними данными (medium data). Ваш ноутбук-2025 мощнее дата-центра 2012 года
• Маркетинг вендоров раздул Big Data" Но вы – не Netflix. Зачем вам Spark/Snowflake для 80 млн строк?
• Эластичность облака = Мы возьмем с вас больше. И мы это сделаем.

Какое решение предлагает автор?

Ключ не в масштабе, а в снижении сложности. Будущее за:
• DuckDB, Polars, SQLite: Обрабатывают гигабайты/сотни млн строк на одном ноутбуке быстрее и в 10-100 раз дешевле облака (реальные кейсы Watershed, FinQore, Mode).

Принципы:
1. Стройте ТОЛЬКО то, чем можете владеть (объясните стек новичку за час).
2. Усложняйте ТОЛЬКО когда реальность требует.
3. Принимайте локальные/встроенные решения.
4. Мигрируйте постепенно.
5. Безжалостно упрощайте

Вывод:
Современный стек данных для многих - это путь в ад затрат, стресса и бесконечной настройки.
Команды, которые выбрали простые, понятные, локальные инструменты (small data done right), просто побеждают.
Их стек просто работает. Они решают задачи бизнеса, а не обслуживают инфраструктурного Франкенштейна.

"Лучший стек данных – тот, о котором вам не приходится думать."

@data_whisperer

The State of Data and AI Engineering 2025

2025 год стал переломным для индустрии данных и искусственного интеллекта. В ежегодном отчете State of Data and AI Engineering выделено пять ключевых трендов, которые определяют будущее этой динамичной экосистемы. Давайте разберем их подробнее.

---

1️⃣ MLOps уходит в тень: рынок консолидируется

Пространство MLOps переживает спад. Рынок активно консолидируется, а компании перестраивают свои стратегии. Яркий пример — недавнее приобретение лидера категории Weights & Biases компанией CoreWeave. Это сигнализирует о переходе фокуса на инфраструктурные решения для ИИ, которые становятся основой для новых разработок. Компании ищут более интегрированные и масштабируемые подходы, оставляя традиционные MLOps-решения позади.

---

2️⃣ LLM-решения на подъеме: точность и мониторинг в центре внимания.

Мониторинг точности моделей машинного обучения всегда был важной частью ML, но в 2024 году акцент сместился на большие языковые модели (LLM). Теперь компании активно развивают инструменты для контроля качества выходных данных LLM, включая результаты RAG-пайплайнов (Retrieval-Augmented Generation) и автономных агентов. Этот тренд подчеркивает растущую потребность в надежности и прозрачности ИИ-систем, которые становятся все более сложными.

---

3️⃣ AWS Glue как спасение от vendor lock-in?

Проблема зависимости от одного поставщика данных (vendor lock-in) остается актуальной. BigQuery, Databricks и Snowflake поддерживают федерацию каталогов Iceberg REST, но только в режиме чтения. В то же время AWS Glue выделяется, предоставляя возможность как чтения, так и записи при интеграции с Databricks и Snowflake. Это делает AWS Glue ключевым инструментом для гибкости в управлении данными. Но надолго ли? Конкуренция в этой области не стоит на месте.

---

4️⃣ Хранилища данных: гонка за скоростью

Спрос на сверхнизкую задержку (ultra-low-latency) в хранилищах данных растет, особенно для задач ИИ и аналитики. Google Cloud представила GCS Fast Tier - прямой ответ на AWS S3 Express и высокопроизводительные предложения от таких провайдеров, как CoreWeave. Этот тренд показывает, что производительность хранилищ становится критически важной для поддержки современных рабочих нагрузок.

---

5️⃣ BigQuery доминирует: отрыв от конкурентов

BigQuery, появившаяся на рынке еще в 2011 году, в 2025 году достигла невероятных высот. Google сообщила, что у BigQuery в пять раз больше клиентов, чем у Snowflake и Databricks вместе взятых! Это подчеркивает роль BigQuery как основы для стратегии Google Cloud в области данных и ИИ. Такой рост демонстрирует, что компании все чаще выбирают проверенные и масштабируемые решения для своих аналитических задач.

---

Итоги: трансформация на всех уровнях

2025 год стал годом консолидации, инноваций и стратегических изменений в области Data и AI Engineering.

- MLOps сокращается, уступая место инфраструктурным и LLM-ориентированным решениям.

- Мониторинг LLM выходит на передний план, отражая новые приоритеты индустрии.

- AWS Glue предлагает гибкость в борьбе с vendor lock-in.

- Хранилища данных становятся быстрее, чтобы соответствовать требованиям ИИ и аналитики.

- BigQuery укрепляет свои позиции как лидер рынка.

Эти тренды формируют экосистему, которая становится все более ориентированной на ИИ, производительность и стратегическую гибкость.

@data_whisperer

Prefect Introducing Assets: From @task to @materialize

Давно не было новостей от Prefect, а тем временем они стараются не отставать от Airflow и Dagster и так же добавили assets.

Prefect представил новую концепцию - ассеты. Это не просто очередное обновление, а новый способ моделировать данные так, как они существуют в реальном мире. Забудьте о сложных DSL и ручном определении зависимостей - ассеты в Prefect делают всё проще и интуитивнее. Но чем это отличается от Dagster и Airflow?

---

Что такое ассеты?

Ассеты - это способ представления данных (таблиц в базах данных, файлов в S3, моделей в реестрах) с помощью ключей в стиле URI, которые отражают их реальное местоположение. Граф зависимостей строится на основе того, что реально выполняется в ваших процессах.

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

---

Чем Prefect отличается от Dagster и Airflow?

1️⃣ Dagster: Всё крутится вокруг ассетов

В Dagster вы пишете функции, которые производят ассеты, и явно определяете зависимости между ними. Это полноценная оркестрация, где акцент сделан на данных, которые создаются в процессе. Однако это требует принятия их модели мышления, основанной на ассетах, и строгого следования их DSL.

2️⃣ Airflow: Ассеты как дополнение

Airflow 3.0 переименовал свои datasets из версии 2.0 в ассеты и добавил декоратор @asset для удобства. Однако их подход ограничен: функции с декоратором @asset просто создают события материализации. В отличие от Prefect, Airflow не поддерживает динамическую материализацию ассетов или их императивное создание.

3️⃣ Prefect: Динамика и гибкость

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

---

Итог
Ассеты в Prefect- это шаг к более интуитивной и гибкой работе с данными. В отличие от Dagster с его строгой моделью или Airflow с ограниченной динамикой, Prefect позволяет вашим данным самим определять граф зависимостей.

@data_whisperer

Lea - это минималистичный SQL оркестратор, аналог dbt и SQLMesh.

На данный момент поддерживает DuckDb и BigQuery, но проект активно развивается и поддерживает добавление новых фичей.

Из интересного:

- Поддерживает разделение на прод и дев, так же как и SQLMesh.

- Поддерживает Write-Audit-Publish паттерн.

- Тестирование моделей во время запуска.

Harlequin SQL IDE for Your Terminal

Harlequin — минималистичная и мощная SQL IDE для работы в терминале. Идеально для тех, кто любит простоту и скорость.

- Подключение к базам данных, S3 и локальным файлам (CSV, Parquet и др.).

- Экспорт результатов запросов, как в DBeaver, в разные форматы.

- Сохранение истории запросов — легко вернуться к прошлым работам.

- Множество цветовых тем для кастомизации интерфейса.

Простота, скорость и никаких лишних окон — всё в твоем терминале. Для дата-инженеров, аналитиков и фанатов CLI — must-have!

@data_whisperer

Write – Audit – Publish (WAP) – архитектурный шаблон для контроля качества данных в пайплайнах

Недавно углубился в статью на Dagster о паттерне Write‑Audit‑Publish (WAP) в ETL/ELT‑процессах.

Этот паттерн помогает командам обеспечить надёжность и трассируемость данных.
Впервые его популяризировала команда Netflix ещё в 2017 году — в докладе «Whoops, the Numbers are wrong! Scaling Data Quality @ Netflix» от Michelle Ufford на DataWorks/Hadoop Summit, где они представили WAP как способ обеспечить контроль качества данных в масштабных системах.

Что такое Write‑Audit‑Publish?

Этот паттерн делит конвейер на три этапа:

Write — запись данных в staging: временное (непродуктивное) хранилище — своеобразный «черновик» данных.

Audit — проверка качества: схемы, отсутствия дубликатов, бизнес‑валидности (цен ≥ 0, возраст пользователя в разумных пределах и т.п.), статистические и структурные тесты.

Publish — публикация: только чистые и проверенные данные переезжают в продуктив (онлайн-таблицы, даталейты, BI-платформы) .

Если Audit обнаруживает ошибки — процесс останавливается, срабатывает откат или оповещение — никакой грязи не попадёт в продуктив.

Интеграция с инструментами:

Оркестрация: Dagster, Prefect, Airflow — позволяют задавать DAG‑этапы как Write → Audit → Publish и организовывать зависимости для автоматизации 

Branch‑based WAP: инструменты вроде Nessie, LakeFS, Bauplan дают ветвление данных: staging‑ветка → проверки → слияние 

CI/CD‑цепочка: тесты CI покрывают этап Audit (SQL‑тесты, unit‑tests), CD‑задаёт правила публикации уже прошедших проверку моделей .

Write‑Audit‑Publish — это мощный архитектурный паттерн, который обеспечивает:

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

WAP паттерн можно реализовать разными инструментами:

- В dbt через clone или создание audit-таблиц
- В DLT
- В Iceberg через создание branch

Так же детальный разборн паттерна есть в книге Data Engineering Design Patterns глава 9 Data Quality Design Patterns.

Если вы строите надёжные ETL/ELT‑конвейеры с DAG‑оркестрацией — WAP станет вашей базовой практикой.

@data_whisperer

Вы думаете ваш облачный счет слишком большой?
Figma тратит 300к $ в день.

31 мая 2025 года Figma заключила обновлённое соглашение об использовании хостинга с AWS, обязуясь потратить минимум $545 млн на облачные услуги в течение следующих пяти лет. Это составляет $298,466.59 ежедневных расходов для Figma.

Высокие затраты на облачные вычисления — известная проблема при масштабировании компаний, что в некоторых случаях приводит к возвращению части рабочих нагрузок или данных в собственную инфраструктуру. Примечательный пример — компания 37signals, которая проводит широко освещаемый полный выход из AWS и Google. Компания начала отказываться от облака в 2022 году, когда технический директор Дэвид Хайнемайер Ханссон сообщил, что их годовой счёт превысил $3.2 млн. В октябре 2024 года 37signals подсчитала, что сэкономила $2 млн в этом году благодаря уходу из облака. Последний этап репатриации включает выход 37signals из сервиса хранения AWS S3, что, по оценке Ханссона, позволит компании экономить около $1.3 млн в год.

Про 37signals и переход в облака, был пост на канале.

kuqu — SQL для Kubernetes.

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

С kuqu вы легко:
- Фильтруете и группируете данные (например, подсчитываете Pod'ы по условиям).
- Объединяете и отображаете информацию из разных типов ресурсов.

Reladiff

Reladiff — это инструментом с открытым исходным кодом для сравнения (diff) больших наборов данных между разными базами.
Идеально подходит для дата-инженеров, DevOps и администраторов систем.

Основные особенности

Вычисления внутри СУБД:
• Reladiff выполняет сравнение на стороне базы данных, минимизируя передачу данных и давая бешеную производительность.

⇄ Кросс-платформенное сравнение: Поддержка 15+ СУБД (PostgreSQL ↔ Snowflake, MySQL ↔ BigQuery и др.)

Скорость:
◦ 25 млн строк за <10 сек (если нет различий)
◦ 1 млрд строк за ~5 мин
◦ Работает с таблицами на десятки миллиардов строк.

Умное сравнение:
◦ Алгоритм на хешах — качает только измененные данные
◦ Автоматическое округление чисел (напр., timestamp(9) → timestamp(3))

Автоматизация и CI:
◦ Многопоточность
◦ Вывод в JSON или git-стиле (+/-) для CI/CD
◦ Дополнительная статистика по таблицам
◦ Материализация diff в локальную таблицу

Reladiff — форк проекта data-diff. Код, работавший с data-diff, совместим без изменений, но:
• Нет трекинга
• Нет интеграции с DBT

@data_whisperer

MCP Toolbox for Databases

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

---

Как MCP Toolbox экономит время?

1. Запросы на естественном языке
Забудьте про сложные SQL-запросы! Задавайте вопросы прямо на русском или английском в вашем IDE, например:
"Сколько заказов было доставлено в 2024 году и какие товары в них были?"
MCP Toolbox сам преобразуют ваш запрос в SQL, экономя время и нервы.

2. Автоматизация управления базами
Опишите, какие данные вам нужны, и AI-помощник сделает всё за вас:
- Генерация запросов
- Создание таблиц
- Добавление индексов
Всё это без необходимости писать код вручную!

3. Контекстно-зависимый код
MCP Toolbox позволяет вашему AI-помощнику генерировать код приложения и тесты с учетом актуальной схемы базы данных. Это ускоряет разработку и гарантирует, что код будет готов к использованию.

4. Меньше рутины, больше дела
Сократите время на настройку окружения и написание шаблонного кода. MCP Toolbox автоматизирует:
- Настройку подключений
- Управление схемами
- Обработку ошибок миграций

@data_whisperer