DataGrip встроил DuckDB для запросов через базы

JetBrains добавила в DataGrip возможность выполнять один SQL-запрос сразу по нескольким подключениям. Вместо разработки собственного движка кросс-базовых запросов команда встроила DuckDB и передала ему выполнение через собственные табличные функции. Такое решение позволило получить работающую функциональность без поддержки отдельного query engine и без изменения архитектуры IDE. Теперь пользователи могут писать join между PostgreSQL, MySQL, MongoDB и другими источниками, а IDE подсказывает, что запрос исполняется именно в диалекте DuckDB.

Почему выбрали DuckDB, а не другие варианты

Команда рассматривала Apache Calcite, собственную обработку через PSI и несколько встраиваемых движков. DuckDB победил по простоте интеграции: регистрация кастомной табличной функции давала прямой доступ к уже существующему механизму выполнения запросов DataGrip. Лёгкие альтернативы вроде H2 не обеспечивали нужного набора оптимизаций, включая projection pushdown, а расширение их функциональности требовало либо нативного кода, либо сложной обвязки. Участник команды, ранее работавший над Trino, отметил, что DuckDB оказался наиболее гибким решением для подобной задачи. В итоге JetBrains избежала создания и поддержки собственного кросс-базового движка.

Чтобы понять выбор, важно знать ключевые термины. Apache Calcite — это фреймворк для построения SQL-движков с поддержкой федеративных запросов, однако он требует значительных усилий по интеграции и настройке. PSI (Program Structure Interface) в экосистеме JetBrains отвечает за разбор и анализ кода внутри IDE, но самостоятельная реализация кросс-базовой логики через него означала бы разработку и дальнейшую поддержку полноценного query engine. Projection pushdown — это оптимизация, при которой часть вычислений (например, фильтрация или выбор колонок) выполняется как можно ближе к источнику данных, что снижает объём передаваемой информации. Trino (ранее PrestoSQL) — распределённый SQL-движок для федеративных запросов, и опыт работы с ним помог оценить, насколько DuckDB проще встраивается без создания отдельной инфраструктуры. Для тех, кто решает, стоит ли использовать новую возможность, важно понимать: решение избавляет от необходимости разворачивать и администрировать дополнительный слой вроде Trino или Calcite, но требует привыкания к тому, что часть логики теперь живёт в DuckDB.

Как работает интеграция на практике

Запросы к нескольким источникам выполняются через табличные функции DuckDB, поэтому пользователь пишет SQL в диалекте DuckDB. IDE явно подсвечивает этот факт, чтобы разработчик понимал контекст. Помимо кросс-базовых join, DuckDB добавили как полноценный диалект с подсветкой синтаксиса, включая возможности версии 2.0. Это упрощает отладку и снижает риск ошибок при переносе выражений. В текущей реализации функция уже позволяет соединять данные без дополнительной инфраструктуры, однако пока не задействует все оптимизации DuckDB.

DuckDB здесь выступает как встраиваемый аналитический движок, который принимает данные из разных источников DataGrip и выполняет над ними операции. Табличные функции — это механизм DuckDB, позволяющий обращаться к внешним данным как к обычным таблицам. Поскольку запрос выполняется в диалекте DuckDB, важно учитывать, что некоторые конструкции, привычные в PostgreSQL или MySQL, могут требовать адаптации. Подсветка диалекта помогает избежать ошибок на этапе написания. Для принятия решения о внедрении стоит оценить, насколько часто в команде возникают задачи с join между разнородными источниками: если такие запросы редки, overhead от смены диалекта может перевесить пользу; если же они регулярны, то возможность обойтись без отдельного федеративного сервера становится заметным преимуществом.

Что важно учесть при переносе в свой контур

Решение полностью локальное и не требует внешних сервисов, что важно для изолированных сред. Нужно заранее оценить накладные расходы на marshaling данных между DataGrip и DuckDB при больших объёмах. Также стоит проверить совместимость существующих скриптов с диалектом DuckDB, особенно если используются специфичные для других СУБД конструкции. В российских командах, где часто встречаются смешанные стеки из PostgreSQL, ClickHouse и файловых источников, такая схема даёт быстрый способ объединить данные без развертывания отдельного федеративного слоя. При этом остаётся возможность позже добавить оптимизации DuckDB, не меняя архитектуру IDE.

Marshaling — это процесс сериализации и передачи данных между DataGrip и DuckDB, который при больших объёмах может создавать заметную нагрузку на память и время выполнения. Федеративный слой — это дополнительный компонент (например, на базе Trino или Apache Drill), который обычно требуется для кросс-базовых запросов; его отсутствие снижает операционные расходы и упрощает безопасность в закрытых контурах. Перед внедрением рекомендуется протестировать типичные запросы на реальных объёмах данных, чтобы понять, приемлем ли текущий уровень переноса информации. В смешанных стеках, характерных для многих российских компаний, возможность быстро связать PostgreSQL с ClickHouse или файловыми источниками без установки новых сервисов может стать решающим фактором «за».

Планы развития и ограничения первой версии

Сейчас реализована базовая схема, и команда намерена наблюдать реальное использование перед добавлением новых оптимизаций. В roadmap два направления: более полное использование внутренних оптимизаторов DuckDB и поддержка файловых источников через тот же механизм. До тех пор, пока не появятся эти улучшения, пользователи могут столкнуться с избыточным переносом данных при сложных join. Тем не менее уже сейчас решение закрывает запрос, который пользователи DataGrip формулировали годами, без необходимости становиться вендором query engine.

Query engine — это специализированный компонент для выполнения и оптимизации SQL-запросов; JetBrains избегает роли его разработчика, что снижает риски поддержки. Избыточный перенос данных возникает, когда DuckDB пока не применяет все возможные оптимизации, такие как predicate pushdown или column pruning. При оценке стоит учитывать, что текущая версия подходит для задач среднего объёма и не слишком сложных join; для тяжёлых аналитических сценариев может потребоваться дождаться будущих улучшений. В то же время отсутствие необходимости становиться вендором query engine делает решение более устойчивым с точки зрения долгосрочной поддержки.

Источник

Это краткий разбор материала DuckDB. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: DataGrip встроил DuckDB для запросов через базы.

Курс по теме — Каталог курсов Школы Больших Данных