5 minutes of data

MCP for Beginners Бесплатный курс по MCP для начинающих от Microsoft. В курсе есть актуальный перевод на русский язык. Так же в примерах используются разные языки программирования.

MCP Toolbox for Databases Это инструмент, который помогает разработчикам создавать приложения для работы с базами данных быстрее, безопаснее и удобнее. Он упрощает взаимодействие с данными и автоматизирует рутинные задачи, позволяя сосредоточиться на логике проекта. --- Как MCP Toolbox экономит время? 1. Запросы на естественном языке Забудьте про сложные SQL-запросы! Задавайте вопросы прямо на русском или английском в вашем IDE, например: "Сколько заказов было доставлено в 2024 году и какие товары в них были?" MCP Toolbox сам преобразуют ваш запрос в SQL, экономя время и нервы. 2. Автоматизация управления базами Опишите, какие данные вам нужны, и AI-помощник сделает всё за вас: - Генерация запросов - Создание таблиц - Добавление индексов Всё это без необходимости писать код вручную! 3. Контекстно-зависимый код MCP Toolbox позволяет вашему AI-помощнику генерировать код приложения и тесты с учетом актуальной схемы базы данных. Это ускоряет разработку и гарантирует, что код будет готов к использованию. 4. Меньше рутины, больше дела Сократите время на настройку окружения и написание шаблонного кода. MCP Toolbox автоматизирует: - Настройку подключений - Управление схемами - Обработку ошибок миграций @data_whisperer

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

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

Вы думаете ваш облачный счет слишком большой? 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 и переход в облака, был пост на канале.

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

Harlequin SQL IDE for Your Terminal Harlequin — минималистичная и мощная SQL IDE для работы в терминале. Идеально для тех, кто любит простоту и скорость. - Подключение к базам данных, S3 и локальным файлам (CSV, Parquet и др.). - Экспорт результатов запросов, как в DBeaver, в разные форматы. - Сохранение истории запросов — легко вернуться к прошлым работам. - Множество цветовых тем для кастомизации интерфейса. Простота, скорость и никаких лишних окон — всё в твоем терминале. Для дата-инженеров, аналитиков и фанатов CLI — must-have! @data_whisperer

Lea - это минималистичный SQL оркестратор, аналог dbt и SQLMesh. На данный момент поддерживает DuckDb и BigQuery, но проект активно развивается и поддерживает добавление новых фичей. Из интересного: - Поддерживает разделение на прод и дев, так же как и SQLMesh. - Поддерживает Write-Audit-Publish паттерн. - Тестирование моделей во время запуска.

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

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

🤩🤩🤩 Новый тренажер DLT – Python ETL для реальных задач Что такое DLT и зачем он нужен? DLT – это Python-библиотека, которая берёт на себя до 90% рутинной работы с данными: - Подключается к разным источникам (API, базы, файлы) - Автоматически обрабатывает сложные JSON-структуры - Создаёт и обновляет таблицы на основе входящих данных - Интегрируется с Dagster и легко запускается в CI/CD Кому будет полезно? ✅ Data Engineer'ам – устали писать однотипный код для каждого источника данных ✅ Аналитикам – нужно быстро собрать данные для отчёта или модели ✅ Backend-разработчикам – требуется надёжный способ синхронизации данных Программа тренажёра 6 практических модулей — от простого к сложному: - Первый пайплайн — установка DLT, загрузка данных в DuckDB - Ресурсы и источники — работа с CSV и ClickHouse - REST API — подключение к GitHub API, пагинация - Файлы и облако — загрузка Parquet с S3 - Интеграция с Dagster — ассеты, конфиги, токены - Итоговый проект — объединённый пайплайн API + БД + файлы Автор тренажера: Иван Матвеев, Data Engineer с опытом построения дата-платформ. Эксперт по современному стеку: Dagster, DBT, DLT, Trino. Автор популярных материалов об экосистеме больших данных. 📱 Автор Telegram-канала Data Whisperer

Специальная цена до конца июня! 5 500₽ вместо 10 500₽ — скидка 48%

Начать погружение в DLT →

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

Heimdall - новый инструмент для оркестрации данных Heimdall - легковесная платформу для оркестрации данных и выполнения задач, которая абстрагирует сложную инфраструктуру, предоставляя единый API. ▫️ Абстрагирует сложность инфраструктуры ▫️ Единый API для управления задачами ▫️ Безопасность без риска утечки credentials Ключевые возможности: • Синхронное и асинхронное выполнение задач • Плагинная архитектура: Shell, Glue, Snowflake, Spark, DynamoDB, Ping • REST API + Web UI для визуального управления • Динамическая маршрутизация по командам/кластерам • Умная очередь задач Изначально вдохновлен Netflix Genie, но расширен: • Поддержка pluggable-команд • Гибкие режимы выполнения • Будущий функционал саморегистрирующихся кластеров

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

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

AI Dev Tools Zoomcamp Бесплатный курс по использованию ИИ-инструментов в разработке. Курс официально запускается! Репозиторий уже готов и будет наполняться новым контентом. Это проект в стадии разработки, так что вы ещё можете заполнить форму ранней регистрации и предложить, какие темы вы хотите видеть в курсе! 🔗 Регистрация P.S А пока можете посмотреть видео как создать DLT проект с помощью Cursor. Самое интересное, что разработчики DLT уже позаботились о всех правилах для Cursor и теперь вы можете добавить их в свой проект одной командой.

dlt ai setup cursor

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

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

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

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

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