{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Yuriy Gavrilov: posts tagged Dev", "_rss_description": "Welcome to my personal place for love, peace and happiness 🤖 Yuiry Gavrilov", "_rss_language": "en", "_itunes_email": "yvgavrilov@gmail.com", "_itunes_categories_xml": "", "_itunes_image": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic-square@2x.jpg?1643451008", "_itunes_explicit": "no", "home_page_url": "https:\/\/gavrilov.info\/tags\/dev\/", "feed_url": "https:\/\/gavrilov.info\/tags\/dev\/json\/", "icon": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008", "authors": [ { "name": "Yuriy Gavrilov - B[u]g - for charity.gavrilov.eth", "url": "https:\/\/gavrilov.info\/", "avatar": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008" } ], "items": [ { "id": "354", "url": "https:\/\/gavrilov.info\/all\/hugr-data-mesh-platforma-i-graphql-bekend-na-baze-duckdb\/", "title": "Hugr: Data Mesh-платформа и GraphQL-бэкенд на базе DuckDB", "content_html": "

1. Что такое Hugr и зачем он нужен<\/h3>\n

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

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

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

Ключевые характеристики:<\/b><\/p>\n\n\n\n\n\n\n\n\n
Параметр<\/td>\nЗначение<\/td>\n<\/tr>\n
Лицензия<\/td>\nMIT<\/td>\n<\/tr>\n
Ядро<\/td>\nDuckDB (in-process, колоночный, OLAP)<\/td>\n<\/tr>\n
Интерфейс<\/td>\nGraphQL (queries, mutations, subscriptions)<\/td>\n<\/tr>\n
Язык реализации<\/td>\nGo<\/td>\n<\/tr>\n
Репозитории<\/td>\n`hugr-lab\/hugr`, `hugr-lab\/query-engine`<\/td>\n<\/tr>\n
Развёртывание<\/td>\nDocker, Kubernetes, embedded в Go-сервисы<\/td>\n<\/tr>\n<\/table>\n

2. Архитектура: почему именно такая<\/h3>\n

2.1. Мотивация<\/h4>\n

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

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

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

    2.2. Компоненты<\/h4>\n
    ┌────────────────────────────────────────────────┐\n│                  Клиенты                       │\n│   Web · BI · Python · MCP\/AI                   │\n└───────────────────────┬────────────────────────┘\n                        │ GraphQL \/ IPC \/ REST\n┌───────────────────────▼────────────────────────┐\n│              Hugr Server (Go)                  │\n│  ┌──────────┐ ┌──────────┐ ┌────────────────┐  │\n│  │ GraphQL  │ │ Schema   │ │ Access Control │  │\n│  │ API+Subs │ │ Compiler │ │ OAuth2 \/ RBAC  │  │\n│  └──────────┘ └──────────┘ └────────────────┘  │\n│  ┌──────────────────────────────────────────┐  │\n│  │     DuckDB Analytical Engine (Go)        │  │\n│  │  In-process · Колоночный · Vectorized    │  │\n│  └──────────────────────────────────────────┘  │\n│  ┌──────────┐ ┌──────────┐ ┌────────────────┐  │\n│  │  Cache   │ │  CoreDB  │ │ IPC Protocol   │  │\n│  │Mem+Redis │ │ metadata │ │  (Arrow)       │  │\n│  └──────────┘ └──────────┘ └────────────────┘  │\n└──┬──────────┬──────────┬───────────┬───────────┘\n   │          │          │           │\n┌──▼───┐  ┌───▼────┐ ┌───▼────┐ ┌────▼──────┐\n│ PG \/ │  │SQL Srv │ │DuckLake│ │ REST API  │\n│MySQL │  │Azure   │ │Iceberg │ │Arrow Fl.  │\n│Parq. │  │        │ │S3\/CSV  │ │ Redis KV  │\n└──────┘  └────────┘ └────────┘ └───────────┘<\/code><\/pre>
    DuckDB как ядро<\/b> — in-process колоночная СУБД для OLAP. Не требует отдельного процесса и сетевого порта, работает с десятками форматов (Parquet, CSV, JSON, GeoParquet, Delta Lake), обеспечивает векторизованное исполнение. Для Hugr это нулевая сетевая задержка между движком и логикой и возможность кросс-источниковых JOIN’ов в памяти.<\/p>\n
    CoreDB<\/b> хранит метаданные: источники, каталоги схем, роли, политики доступа. Может быть DuckDB-файлом или PostgreSQL (обязателен для кластера).<\/p>\n
    Компилятор схем<\/b> преобразует GraphQL SDL с директивами (`@table`, `@view`, `@function`, `@field_references`, `@join`, `@module`) в логическую модель, из которой генерируются типы, фильтры, агрегации, мутации и sub-query поля для связей.<\/p>\n
    \n
    3. Источники данных: единая точка входа<\/h3>\n
    3.1. Поддерживаемые типы<\/h4>\n\n\n\n\n\n\n\n\n\n
    Категория<\/td>\nИсточники<\/td>\nОсобенности<\/td>\n<\/tr>\n
    Реляционные<\/td>\nPostgreSQL (PostGIS, TimescaleDB, pgvector), MySQL, SQL Server \/ Azure SQL<\/td>\nPushdown фильтров, сортировки, агрегаций и JOIN’ов<\/td>\n<\/tr>\n
    Озёра данных<\/td>\nDuckLake, Apache Iceberg (REST, Glue, S3 Tables)<\/td>\nTime-travel, snapshot-based DDL\/DML<\/td>\n<\/tr>\n
    Файлы<\/td>\nParquet, Delta Lake, CSV, JSON, GeoParquet, Shapefiles<\/td>\nЧерез DuckDB, поддержка S3 и Hive-партиционирования<\/td>\n<\/tr>\n
    Сервисы<\/td>\nREST API, Arrow Flight gRPC, GraphQL (в разработке)<\/td>\nBasic, ApiKey, OAuth2<\/td>\n<\/tr>\n
    AI\/ML<\/td>\nEmbeddings, LLM (OpenAI, Anthropic, Gemini)<\/td>\nЕдиный tool calling, streaming<\/td>\n<\/tr>\n
    Key-Value<\/td>\nRedis<\/td>\nPub\/Sub, keyspace events, TTL<\/td>\n<\/tr>\n
    Расширения<\/td>\nExtension-источник, Hugr Apps<\/td>\nКросс-источниковые представления, кастомные функции<\/td>\n<\/tr>\n<\/table>\n
    3.2. Декларативная регистрация<\/h4>\n
    Источник описывается мутацией `insert_data_sources`, после чего его схема компилируется и попадает в общее GraphQL-дерево. Адаптеры и коннекторы писать не нужно.<\/p>\n
    mutation {\n  core {\n    insert_data_sources(data: {\n      name: "my_llm"\n      type: "llm-openai"\n      prefix: "my_llm"\n      path: "http:\/\/localhost:1234\/v1\/chat\/completions?model=gemma-4&timeout=120s"\n    }) { name }\n  }\n}<\/code><\/pre>
    Новый источник появляется в API за одну мутацию, без пересборки и перезапуска.<\/p>\n
    \n
    4. GraphQL как универсальный слой доступа<\/h3>\n
    4.1. Автогенерация из схемы<\/h4>\n
    Для каждого табличного объекта компилятор создаёт:<\/p>\n