Welcome to my personal place for love, peace and happiness 🤖

Hugr: Data Mesh-платформа и GraphQL-бэкенд на базе DuckDB

1. Что такое Hugr и зачем он нужен

Hugr — это open-source платформа класса Data Mesh и высокопроизводительный GraphQL-бэкенд, построенный поверх аналитического движка DuckDB. Проект развивается командой hugr-lab под руководством Владимира Грибанова и распространяется под лицензией MIT.

Назначение — решить конкретную инженерную боль: данные в организации разбросаны по десяткам систем (PostgreSQL, SQL Server, S3, REST API, Kafka, Redis), и каждая команда строит собственный слой доступа. Классические ETL-пайплайны и дублирование данных в единое хранилище дают задержку актуальности, удваивают инфраструктуру и создают узкое горлышко на дата-инженерах.

Hugr предлагает иную модель: данные остаются на месте, а поверх них выстраивается единый GraphQL-слой, который компилирует декларативные схемы в исполняемые запросы к каждому источнику. Для аналитика — один интерфейс вместо десятков коннекторов. Для разработчика — типизированный GraphQL API без ручного CRUD. Для дата-инженера — декларативное описание схемы через SDL-директивы вместо поддержки ETL.

Ключевые характеристики:

Параметр Значение
Лицензия MIT
Ядро DuckDB (in-process, колоночный, OLAP)
Интерфейс GraphQL (queries, mutations, subscriptions)
Язык реализации Go
Репозитории `hugr-lab/hugr`, `hugr-lab/query-engine`
Развёртывание Docker, Kubernetes, embedded в Go-сервисы

2. Архитектура: почему именно такая

2.1. Мотивация

Традиционный подход «единое хранилище» (Data Warehouse / Lakehouse) предполагает перемещение данных в одну точку. Это создаёт три проблемы:

  1. Задержка актуальности — данные в хранилище отстают от источника.
  2. Дублирование и стоимость — копирование петабайтов дорого и медленно.
  3. Схема-каплинг — потребители привязаны к физической структуре хранилища.

Data Mesh инвертирует модель: каждый домен владеет своими данными и публикует их как продукт, а платформа обеспечивает федеративный доступ. Hugr — инфраструктура этого доступа.

2.2. Компоненты

┌────────────────────────────────────────────────┐
│                  Клиенты                       │
│   Web · BI · Python · MCP/AI                   │
└───────────────────────┬────────────────────────┘
                        │ GraphQL / IPC / REST
┌───────────────────────▼────────────────────────┐
│              Hugr Server (Go)                  │
│  ┌──────────┐ ┌──────────┐ ┌────────────────┐  │
│  │ GraphQL  │ │ Schema   │ │ Access Control │  │
│  │ API+Subs │ │ Compiler │ │ OAuth2 / RBAC  │  │
│  └──────────┘ └──────────┘ └────────────────┘  │
│  ┌──────────────────────────────────────────┐  │
│  │     DuckDB Analytical Engine (Go)        │  │
│  │  In-process · Колоночный · Vectorized    │  │
│  └──────────────────────────────────────────┘  │
│  ┌──────────┐ ┌──────────┐ ┌────────────────┐  │
│  │  Cache   │ │  CoreDB  │ │ IPC Protocol   │  │
│  │Mem+Redis │ │ metadata │ │  (Arrow)       │  │
│  └──────────┘ └──────────┘ └────────────────┘  │
└──┬──────────┬──────────┬───────────┬───────────┘
   │          │          │           │
┌──▼───┐  ┌───▼────┐ ┌───▼────┐ ┌────▼──────┐
│ PG / │  │SQL Srv │ │DuckLake│ │ REST API  │
│MySQL │  │Azure   │ │Iceberg │ │Arrow Fl.  │
│Parq. │  │        │ │S3/CSV  │ │ Redis KV  │
└──────┘  └────────┘ └────────┘ └───────────┘

DuckDB как ядро — in-process колоночная СУБД для OLAP. Не требует отдельного процесса и сетевого порта, работает с десятками форматов (Parquet, CSV, JSON, GeoParquet, Delta Lake), обеспечивает векторизованное исполнение. Для Hugr это нулевая сетевая задержка между движком и логикой и возможность кросс-источниковых JOIN’ов в памяти.

CoreDB хранит метаданные: источники, каталоги схем, роли, политики доступа. Может быть DuckDB-файлом или PostgreSQL (обязателен для кластера).

Компилятор схем преобразует GraphQL SDL с директивами (`@table`, `@view`, `@function`, `@field_references`, `@join`, `@module`) в логическую модель, из которой генерируются типы, фильтры, агрегации, мутации и sub-query поля для связей.


3. Источники данных: единая точка входа

3.1. Поддерживаемые типы

Категория Источники Особенности
Реляционные PostgreSQL (PostGIS, TimescaleDB, pgvector), MySQL, SQL Server / Azure SQL Pushdown фильтров, сортировки, агрегаций и JOIN’ов
Озёра данных DuckLake, Apache Iceberg (REST, Glue, S3 Tables) Time-travel, snapshot-based DDL/DML
Файлы Parquet, Delta Lake, CSV, JSON, GeoParquet, Shapefiles Через DuckDB, поддержка S3 и Hive-партиционирования
Сервисы REST API, Arrow Flight gRPC, GraphQL (в разработке) Basic, ApiKey, OAuth2
AI/ML Embeddings, LLM (OpenAI, Anthropic, Gemini) Единый tool calling, streaming
Key-Value Redis Pub/Sub, keyspace events, TTL
Расширения Extension-источник, Hugr Apps Кросс-источниковые представления, кастомные функции

3.2. Декларативная регистрация

Источник описывается мутацией `insert_data_sources`, после чего его схема компилируется и попадает в общее GraphQL-дерево. Адаптеры и коннекторы писать не нужно.

mutation {
  core {
    insert_data_sources(data: {
      name: "my_llm"
      type: "llm-openai"
      prefix: "my_llm"
      path: "http://localhost:1234/v1/chat/completions?model=gemma-4&timeout=120s"
    }) { name }
  }
}

Новый источник появляется в API за одну мутацию, без пересборки и перезапуска.


4. GraphQL как универсальный слой доступа

4.1. Автогенерация из схемы

Для каждого табличного объекта компилятор создаёт:

  • запросы с `filter`, `order_by`, `distinct_on`, `limit`, `offset`;
  • запрос по первичному ключу (`object_name_by_pk`) и уникальным полям;
  • агрегации (`object_name_aggregation`) и корзинные агрегации (`object_name_bucket_aggregation`);
  • мутации `insert`, `update`, `delete` с типизированными входными структурами;
  • фильтровые типы с операторами `eq`, `in`, `gt`, `lt` и вложенными фильтрами по связям;
  • sub-query поля для связей (включая M2M), query-time JOIN’ы и пространственные JOIN’ы.

Дата-инженер описывает логическую модель — полный CRUD, агрегации и связи появляются автоматически.

4.2. Подписки

  • Streaming LLM completions — токены с событиями `content_delta`, `reasoning`, `tool_use`, `finish`, `error`.
  • Pub/Sub — подписка на каналы Redis.
  • Keyspace events — мониторинг изменений ключей по паттерну.

4.3. JQ-трансформации

Серверные JQ-преобразования: встроенный `jq()` в GraphQL, REST-эндпоинт `/jq-query`, доступ к переменным через `$var_name`, вложенные GraphQL-запросы из JQ через `queryHugr()`. Это постобработка без выгрузки в Python — группировка, фильтрация, реструктуризация на сервере.


5. AI-возможности: LLM и Embeddings

5.1. Модуль `core.models`

Функция Назначение
`embedding` / `embeddings` Векторные эмбеддинги (одиночный и батч)
`completion` Простая генерация текста
`chat_completion` Многооборотный диалог с tool calling
`model_sources` Список зарегистрированных моделей

Провайдеры: OpenAI (и совместимые: Ollama, LM Studio, vLLM, Mistral, Qwen, Azure OpenAI), Anthropic (Claude), Google Gemini. Различия форматов абстрагированы.

5.2. Tool Calling и Round-trip

Вызовы инструментов нормализованы. Для Gemini 2.5+ поддерживается `thought_signature` — обязательное поле при отправке результатов инструментов обратно модели. Пайплайн: запрос → `tool_calls` + `thought_signature` → исполнение инструмента → сообщение с `role: “tool”` → полная история в `chat_completion`.

5.3. Thinking Budget

Параметр `thinking_budget` управляет chain-of-thought: задаётся на уровне источника (максимум) и запроса (кап). Модель сначала выдаёт `reasoning`-события, затем `content_delta`.

5.4. MCP-интеграция

Поддержка Model Context Protocol позволяет AI-ассистентам (Claude, Cursor) исследовать схему, выполнять семантический поиск и генерировать/валидировать GraphQL-запросы. Основа для «vibe-аналитики»: LLM строит запросы на естественном языке, Hugr их исполняет.


6. Hugr Apps: расширяемость через Arrow Flight

6.1. Концепция

Hugr Apps — внешние Go-приложения, подключаемые через DuckDB Airport extension (Apache Arrow Flight gRPC). Публикуют в общую GraphQL-схему скалярные функции, таблицы, табличные функции и собственные источники данных (например, PostgreSQL с миграциями).

6.2. Жизненный цикл

Сценарий Обнаружение Восстановление Потеря данных
Graceful shutdown Немедленно N/A Нет
Краш приложения Heartbeat (~90 сек) Мгновенно при рестарте Нет
Рестарт Hugr Startup load LoadDataSource Нет
Обновление версии Изменение пути Мгновенно (миграция) Нет

Heartbeat: интервал 30 сек, таймаут 10 сек, 3 неудачи → приостановка каталога. При восстановлении каталог перекомпилируется.

6.3. Практический смысл

Бизнес-логику (геокодирование, скоринг, расчёты) можно вынести в отдельный сервис и опубликовать как SQL/GraphQL-функции без изменения основного конвейера.


7. Production-readiness и работа под нагрузкой

7.1. Кластерный режим

  • CLUSTER_ROLE: `management` или `worker`.
  • Management-нода координирует синхронизацию схем, жизненный цикл источников и конфигурацию хранилищ.
  • Worker-ноды получают обновления через push (broadcast) и pull (polling).
  • PostgreSQL CoreDB обязателен — все ноды разделяют единую метабазу.

7.2. Кеширование

  1. In-memory — горячие данные на каждой ноде.
  2. Внешний кеш (Redis / Memcached) — разделяемый, инвалидация при мутациях.

Директива `@cache` управляет кешированием на уровне схемы.

7.3. Производительность

  • Нулевая сетевая задержка между логикой и движком.
  • Векторизованное колоночное исполнение.
  • Поддержка десятков форматов без конвертации.
  • Кросс-источниковые JOIN’ы в памяти.
  • Filter pushdown — условия `WHERE` передаются на сторону источника (особенно PostgreSQL).

7.4. Безопасность

OAuth2 / OpenID Connect, field-level и row-level security, ролевая модель с предопределёнными фильтрами, автозаполнение контекста пользователя/роли в мутациях.

7.5. Развёртывание

  • Docker: `docker run -d --name hugr -p 15000:15000 -v ./schemas:/schemas ghcr.io/hugr-lab/automigrate:latest`
  • Kubernetes: Helm-чарты в `hugr-lab/docker` (multi-node, load balancing, кеширование).
  • Embedded: Go-пакет `hugr-lab/query-engine`.

7.6. Ограничения

  • Планируются коннекторы к SQLite (через DuckDB) и ClickHouse.
  • GraphQL как источник данных — в разработке.
  • «Talk-to-data» (естественный язык) — анонсирован.

Для высоких нагрузок рекомендуется кластерный режим с PostgreSQL CoreDB и Redis-кешем.


8. Области применения и примеры

8.1. Бэкенд данных для приложений

Единый GraphQL-слой поверх существующих БД: быстрый запуск API, централизованная схема, контроль доступа.

{
  marketing {
    campaigns_aggregation_bucket {
      key { channel { name } }
      aggregations { payments { amount { sum } } }
    }
  }
}

8.2. Data Mesh-платформа

Каждый домен публикует свою схему как модуль. Федеративный доступ через единый API, децентрализованное владение.

8.3. Аналитика и MLOps

OLAP-запросы и пространственные агрегации через GraphQL, экспорт в Arrow IPC → Python (pandas, GeoDataFrame, Jupyter), JQ-трансформации на сервере, цикл Ingestion → Processing → ML → API Access.

8.4. Агентная аналитика (Vibe Analytics)

Через MCP-эндпоинт LLM-агент исследует схему, генерирует запросы, выполняет цепочки и строит JQ-преобразования. Пользователь задаёт вопрос на естественном языке — агент возвращает результат.

8.5. Реал-тайм дашборды

Подключение Grafana/Metabase к Hugr → данные обновляются на каждый запрос, без ETL-задержек, с комбинацией нескольких источников.

8.6. Геопространственные задачи

Нативные пространственные типы, кросс-источниковые spatial JOIN’ы, поддержка GeoParquet, GeoJSON, Shapefiles, агрегации по пространственным отношениям.


9. Итог

Hugr занимает нишу между «тяжёлыми» платформами данных (Databricks, Snowflake) и лёгкими GraphQL-обёртками над одной БД. Его ценность:

  • Декларативность — схема через SDL-директивы, полный CRUD генерируется автоматически.
  • Федеративность — данные не перемещаются, доступ на месте.
  • Производительность — DuckDB in-process даёт колоночную векторизацию без сетевых накладных расходов.
  • Расширяемость — Hugr Apps, Extension-источники, AI-модуль, Redis.
  • Открытость — MIT, Go-стек, Docker/K8s, embedded-режим.

Для команды, которая хочет дать аналитикам и приложениям единый доступ к разнородным данным без ETL-империи, Hugr — зрелый и прагматичный выбор с понятной траекторией масштабирования.


10. Что ещё: другие инструменты и события из рассылки DuckDB (сентябрь 2026)

Ежемесячная рассылка DuckDB #45 (16 сентября 2026) принесла несколько значимых новостей.

Крупные события

  • AWS приобретает DuckLabs (компанию-создателя DuckDB). Проекты DuckDB, DuckLake, Quack остаются под MIT-лицензией и управлением DuckDB Foundation. Сообщество восприняло новость со сдержанным оптимизмом благодаря независимому фонду и открытой лицензии. Однако аналитики предупреждают: «разработчики не должны путать неизменность лицензии с неизменностью проекта — люди, пишущие код DuckDB, теперь получают зарплату от AWS, а зарплата влияет на дорожную карту».
  • MotherDuck приобретает Tower.dev для интеграции рантайм-инфраструктуры в MotherDuck Flights — AI-агенты смогут выполнять задачи дата-инжиниринга и публиковать данные как API. Tower — это hosted-рантайм для Python-пайплайнов, обеспечивающий песочницу, планирование и наблюдаемость для кода, написанного LLM.

DuckDB 2.0 preview (кодовое имя «Cyanoptera»)

Доступна preview-версия с клиент/серверным режимом через Quack и `CONNECT`, новым PEG-парсером SQL, переработанным C API для расширений, новым форматом хранения по умолчанию. Асинхронный I/O для S3, переписанный движок рекурсивных CTE и оптимизированный тип VARIANT. Релиз запланирован на октябрь 2026.

Экосистема

Инструмент / Статья Суть
sql.garden Open-source бесконечный холст для данных на Wails (Go + Vue 3) с MCP-сервером для AI-взаимодействия
DuckDB Table Functions in Java Регистрация табличных функций на чистом Java без C++ расширений; векторизованный батч 2048 строк, pushdown предикатов
JetBrains Parquet/Avro/ORC Viewer Плагин для IDE: 1 млрд строк / 29 ГБ Parquet открывается за ~1 сек
Bulk Load в SQL Server (В. Грибанов) Параллельные писатели и явные типы (`MSSQL_NVARCHAR(200)`) ускоряют загрузку 38 млн строк с 933 до 96 сек
DuckLake vs Iceberg (CDC) DuckLake решает проблему мелких файлов в Postgres→DuckDB CDC: 6 576 мс против 269 344 мс у Iceberg COW
duckdb-zarr Rust-расширение для запросов к Zarr-хранилищам (N-мерные массивы) через SQL, поддержка S3/GCS
DuckDB for Apache Iceberg Полноценный read/write lifecycle через REST-каталоги, MERGE INTO, ALTER TABLE, Iceberg V3
SQLite vs DuckDB на $16-железе Для observability-данных DuckDB отодвигает «обрыв чтения» в 100 раз дальше и даёт 4× на метриках, 15× на логах

Эти новости подтверждают вектор: экосистема DuckDB стремительно расширяется от аналитического движка в сторону полноценной платформы данных — с клиент/серверным режимом, AI-интеграцией и корпоративными сценариями. Hugr органично встраивается в эту экосистему, используя DuckDB как вычислительное ядро и добавляя слой декларативного доступа, который превращает сырой движок в управляемую платформу данных.

Follow this blog
Send
Share
Tweet