Yuriy Gavrilov

Мастерская новатора: цифровое искусство Константина Худякова

Sun, 20 Sep 2026 21:27:50 +0300

Вчера, 19 сентября 2026 года, мне посчастливилось побывать в парке «Зарядье» на выставке «Мастерская новатора. Константин Худяков». Это событие стало для меня не просто очередным культурным выходом, а настоящим погружением в мир, где технологии и искусство сплетаются в единое целое. Выставка, посвященная памяти художника-визионера и одного из основоположников цифрового искусства в России, открылась 18 сентября и продлится до 8 ноября.

Спасибо организаторам 🙏🤗🤝

🖼️ Два образа, которые не отпускают

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

«Стрекоза» — это не просто изображение насекомого, а целая вселенная, застывшая в хрупком панцире. Меня восхитила филигранная точность, с которой прорисована каждая деталь: переливы крыльев, грани фасеточных глаз, тончайшие прожилки. Казалось, что это не цифровая печать, а живой организм, пойманный в момент полета. В этой работе чувствуется рука архитектора, который видит мир в структурах и формах, но при этом наполняет их невероятной эмоциональностью.

Стерео-лайт-панель — это уникальное технологичное произведение цифрового искусства, созданное российским художником Константином Худяковым. Эта техника соединяет многоракурсную стереофотографию, компьютерную графику и внутреннюю светодиодную подсветку, создавая эффект живого объемного изображения без очков.

«Глаз ангела» — работа, которая завораживает с первого взгляда. Это не просто глаз, а портал в иную реальность, где каждый отраженный луч, каждая частица света рассказывают свою историю. Меня поразила глубина и многослойность этого образа и детализация. Когда смотришь на него, кажется, что видишь не только саму картину, но и время, в которое она была создана, и мысли автора, вложенные в нее. Эти две работы понравились мне одинаково сильно, и я до сих пор нахожусь под их впечатлением.

🧬 Код цифрового искусства

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

Каждый слой — это не просто технический элемент. Это образ жизни художника, его мировоззрение, технологии, которые были доступны на момент создания, и само время, которое диктовало свои условия. Раскрывая эти слои один за другим, начинаешь видеть, как автор превосходил свое время, заглядывая в будущее и предугадывая то, что станет доступно лишь десятилетия спустя. Худяков начал работать с цифровыми технологиями еще в конце 1990-х, когда многие даже не представляли, что компьютер может быть инструментом искусства. Его авторская техника «искусства высокого разрешения» позволяла создавать графику, которая по качеству и глубине не уступала живописи.

В конце концов, все эти слои сливаются воедино, в одну работу. Это как небольшой генетический код произведения. В нем одновременно есть что-то живое, пульсирующее, и частица самого автора — его душа, мастерство и интеллект.

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

🌱 Ученики и последователи

На выставке также были представлены работы учеников и последователей Худякова. Мое внимание привлекли проекты, созданные командой студии Synticate. Эта арт-группа, основанная Владиславом Ткачуком и Романом Цукановым, занимается созданием цифровых форм жизни и исследованием будущего симбиоза природы и технологий. Их концепция «экофутуризма» очень близка идеям Худякова о синтезе искусства и науки.

Особенно интересной мне показалась работа из серии «Киберорганика». В этой работе чувствуется тот же подход, что и у Худякова: синтез природы и технологий, создание новой формы жизни на стыке реального и цифрового. Synticate интегрируют компьютерную графику в реальные съемки, что позволяет им рассказывать истории о будущем, не отрываясь от настоящего.

🤝 Коллективное творчество

Отдельно хочется сказать о том, как Худяков работал над своими масштабными проектами. Художник создавал цифровые портреты, используя фотографии реальных людей, а затем объединял их в единое многоликое произведение. Например, в проекте «Биохакинг» приняли участие 250 человек — Худяков сделал более 150 снимков лица каждого, чтобы затем создать собирательный образ. Этот подход — использование коллективного опыта и множества человеческих лиц для создания одного образа — как нельзя лучше отражает его философию: искусство создается не в вакууме, а из живого опыта многих людей и становятся их кодом.

💎 Заключение

Посещение «Мастерской новатора» стало для меня не просто знакомством с творчеством Константина Худякова, но и глубоким размышлением о природе цифрового искусства. Работы, увиденные вчера, — это не просто картинки. Это многослойные коды, в которых зашифрована жизнь их создателя, его время и его взгляд в будущее.

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

https://discovery-ru.livejournal.com/14183.html

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

Sun, 20 Sep 2026 09:00:00 +0300

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) предполагает перемещение данных в одну точку. Это создаёт три проблемы:

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

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. Кеширование

In-memory — горячие данные на каждой ноде.
Внешний кеш (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 как вычислительное ядро и добавляя слой декларативного доступа, который превращает сырой движок в управляемую платформу данных.

Работа — боль: как «мазохистическое лидерство» становится системной ловушкой российских компаний — и как из неё выйти

Wed, 16 Sep 2026 22:44:45 +0300

В российской управленческой культуре до сих пор силён образ «настоящего руководителя»: человека, который всегда на связи, спит по четыре часа, лично решает все кризисы и держит команду в постоянном напряжении. Такой начальник не просто работает много — он демонстрирует страдание как доказательство собственной ценности.

Наткнулся на эту статейку, но доступа не имел к сожалению, а написал с ИИшечкой. Не знаю как получилось, вам оценивать.

https://www.rbc.ru/business/16/09/2026/6aa39f109a7947237af8c218

Кстати там есть еще интересные исследования, вот например такое

можно скачать тут – Игра на нервах Есть еще 28 файлов.

Вот тут еще небольшое введение https://www.kommersant.ru/doc/8956332

https://www.kommersant.ru/doc/8956332

Исследование СберУниверситета описывает этот феномен как мазохистическое лидерство. Важно подчеркнуть: речь идёт не о клиническом диагнозе и не о характеристике конкретного человека, а о системной роли, которую организация нередко сама подпитывает и воспроизводит. Логика этой роли проста: если всё спокойно, значит, я недостаточно нужен. Поэтому вокруг лидера регулярно возникают авралы, срочные совещания, ночные переписки и «героические» спасательные операции. Проблема в том, что часто эти пожары создаются самой системой управления — или самим руководителем.

Масштаб явления

По данным исследования СберУниверситета «Игра на нервах? Деструктивные проявления в коммуникациях руководителя» (осень 2024 года, 518 респондентов), 72% сотрудников регулярно сталкиваются хотя бы с одним из девяти видов деструктивного поведения со стороны руководителя. Самое распространённое — отсутствие эмпатии и сочувствия: с этим систематически сталкиваются 54% респондентов, а 87% испытывают негативное воздействие из-за такого поведения — например, когда работают по ночам или в выходные. При этом 42% указывают на слабые управленческие навыки начальства, а 47% демотивирует обесценивание их работы.

Почему такие лидеры появляются

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

Есть и психологический фактор. Для мазохистического лидера перегрузка становится способом самоутверждения. Он привыкает быть незаменимым, получать признание через жертву и контролировать команду через постоянное напряжение. Иногда такой руководитель искренне уверен, что иначе люди «расслабятся» и работа развалится. Как отмечают эксперты СберУниверситета, за таким поведением часто стоят неосознанные защитные механизмы: руководитель может выступать одновременно в роли «жертвы» обстоятельств и «преследователя» по отношению к подчинённым.

Как страдание становится нормой

Опасность в том, что подобная модель быстро заражает организацию. Сотрудники начинают понимать: ценится не качество результата, а демонстрация вовлечённости. Значит, нужно отвечать ночью, приходить больным, жаловаться на перегрузку, но не отказываться от новых задач. Так формируется негласное правило: хороший работник — тот, кому тяжело.

Со временем компания теряет способность отличать продуктивность от суеты. Совещаний становится больше, решений — меньше. Люди боятся брать паузу, признавать ошибки и говорить о реальных рисках. Хронический стресс снижает внимание, ухудшает качество решений и повышает текучесть кадров. По данным исследования Русской Школы Управления, к концу 2025 года 48% работающих россиян отмечали у себя симптомы эмоционального выгорания, а 68% говорили о постоянной усталости. Выгорание перестаёт быть личной проблемой конкретного человека и становится управленческим дефектом всей системы.

Героизм в кризисе и героизм как норма — не одно и то же

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

Патология начинается тогда, когда аврал становится хроническим режимом. Если каждая неделя заканчивается «спасением», если дедлайны постоянно сдвигаются, если «ночной созвон» — привычная практика, а не исключение, — значит, проблема не в людях, а в системе. Разовый героизм — это ресурс. Хронический героизм — это его истощение. Компания, которая живёт в режиме постоянного подвига, на самом деле живёт в режиме постоянного управленческого сбоя.

Методика диагностики: диаграмма Исикавы

Чтобы разорвать порочный круг, важно сначала понять, какие именно факторы подпитывают мазохистическое лидерство в конкретной организации. Здесь может помочь диаграмма Исикавы («рыбья кость») — инструмент причинно-следственного анализа, который позволяет структурировать корневые причины проблемы.

«Голова рыбы» — это сама проблема: устойчивое воспроизводство мазохистического лидерства. «Рёбра» — пять узловых блоков, по которым распределяются провоцирующие факторы:

Блок	Примеры факторов
Личностный аспект	Страх потерять контроль, потребность в признании через жертву, неумение выдерживать неопределённость
Процессы	Отсутствие приоритизации, размытые зоны ответственности, культура «тушения пожаров» вместо предотвращения
Среда	Героизм вознаграждается, спокойная работа не замечается, страх признать ошибку
Время	Хронические переработки, отсутствие пауз, невозможность восстановления
Ресурсы	Недоукомплектованность, нехватка полномочий, вынуждающая «всё брать на себя»

Практический алгоритм: соберите рабочую группу из 5–7 человек (руководители, HR, сотрудники), за 30–40 минут сформулируйте проблему в «голове рыбы», затем предложите участникам записать факторы на стикерах и распределить их по блокам. После этого выберите три корневые причины, которые получают больше всего голосов, и под каждую определите одно конкретное действие с ответственным и сроком. Такой анализ позволяет увидеть, что мазохистическое лидерство — не личная патология, а системный сбой, в котором сходятся культурные, управленческие и психологические факторы.

Что могут сделать компании

Первый шаг — перестать поощрять героизм как норму. Компании стоит оценивать руководителей не только по итоговым показателям, но и по тому, какой ценой эти показатели достигнуты. Вот минимальный набор метрик здоровья организации, который стоит отслеживать регулярно:

Текучесть кадров — особенно в тех подразделениях, где руководитель демонстрирует мазохистический стиль. Резкий рост — первый сигнал.
Уровень выгорания — измеряется через короткие пульс-опросы (например, раз в квартал): «Как часто за последний месяц вы чувствовали эмоциональное истощение?»
Доля переработок — процент сотрудников, регулярно работающих сверх нормы. Если он стабильно высок, это не «преданность», а системный сбой.
Количество задач, закрытых без аврала — позитивная метрика, которая смещает фокус с «тушения пожаров» на предотвращение.
eNPS — полезен, но с оговоркой: он измеряет лояльность, а не выгорание. Исследования показывают, что «промоутеры» могут увольняться чаще всех: парадокс «удовлетворённого увольняющегося». Поэтому eNPS стоит дополнять прямым вопросом: «Планируете ли вы остаться в компании через год?».

Второй шаг — менять систему признания. Награждать нужно не только тех, кто «потушил пожар», но и тех, кто сделал так, чтобы он не начался. Хороший менеджмент часто незаметен: процессы работают, сотрудники понимают цели, риски обсуждаются заранее, решения принимаются без истерики. Именно это и должно считаться профессионализмом.

Третий шаг — учить руководителей работать с тревогой и контролем. Многим начальникам сложно делегировать не потому, что команда слаба, а потому, что они сами не умеют выдерживать неопределённость. Здесь помогают управленческое обучение, коучинг, регулярная обратная связь и честные разговоры о стиле лидерства. Программы психологической поддержки и коучинга для руководителей снижают риск их выгорания и повышают эффективность управления.

Что делать сотрудникам

Если человек оказался в команде мазохистического лидера, важно не подыгрывать культуре страдания. Вот чек-лист красных флагов, которые стоит отслеживать:

Срочность без причины — задачи объявляются «горящими», хотя объективных оснований для этого нет.
Культ переработок — работать допоздна и в выходные считается нормой, а не исключением.
Обесценивание — ваши результаты принижаются или игнорируются, компетентность ставится под сомнение.
Наказание за границы — попытка обозначить рабочее время или отказаться от внеурочной задачи воспринимается как нелояльность.
Хронический кризис — авралы повторяются каждую неделю, а «герои» регулярно «спасают» проекты.

Если человек оказался в такой среде, важно постепенно переводить разговор из эмоциональной плоскости в управленческую. Например, вместо «мы опять ничего не успеваем» — спрашивать: какие задачи приоритетны? Что можно перенести? Кто принимает решение? Какие риски мы видим заранее? Такой подход возвращает ответственность в систему, а не оставляет её на уровне личного героизма. Полезно фиксировать договорённости письменно, обозначать границы рабочего времени и показывать связь между хаосом и потерей качества. Если руководитель готов к диалогу, это может изменить ситуацию. Если нет — у сотрудника появляется более ясная картина: проблема не в его слабости, а в токсичной управленческой модели.

Что почитать по теме

Дэвид Дотлих, Питер Кейро. «Темная сторона силы» — о том, как сильные стороны руководителя превращаются в критические недостатки, и о 11 наиболее распространённых деструкторах.
Лора Ловетт. «Токсичный начальник» — практические стратегии для выживания и обретения контроля над карьерой, включая чек-лист для определения типа токсичного руководителя.
Кэри Купер. «Организационный стресс» — фундаментальный труд о выгорании как особой форме стресса и организационных условиях его возникновения.
Эрих Фромм. «Бегство от свободы» — классический психоаналитический анализ садо-мазохистских механизмов в отношениях власти и подчинения.
Исследования СберУниверситета — «Игра на нервах? Деструктивные проявления в коммуникациях руководителя» и «Демотивирующее поведение руководителей» — доступны на сайте организации.

Вместо вывода

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

Мазохистическое лидерство может выглядеть ярким, самоотверженным и даже искренне преданным делу. Но если компания зависит от постоянных подвигов, значит, она плохо управляется. Настоящая сила руководителя — не в том, чтобы каждый день спасать всех из огня, а в том, чтобы однажды перестать его разводить. И путь к этому начинается с честного взгляда на систему: какие условия мы создаём — и какие условия мы готовы менять.

Бежит кучка ежиков, вдруг вожак орёт: «Стой!!!» — все ежи встали, снова вожак орёт: «Пастись!!!» — все ежи пасутся, а вожак про себя думает: «Хы… Ну чем не кони!»

Помогать легко – DoBro!

Tue, 15 Sep 2026 23:10:22 +0300

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

День первый: поездка в детский хоспис

Всю ту неделю я чувствовал, что мне катастрофически не хватает физической активности. Сидячая работа, встречи, дедлайны — тело требовало движения и какой-то разрядки. Но тратить время и силы на спортзал не хотелось — хотелось чего-то нового и свежего. И тут подвернулась возможность съездить от компании в Московский областной хоспис для детей – ГБУЗ МО «МОХД» — помочь с благоустройством территории и по хозяйству.

Это учреждение — первое в Подмосковье и одно из первых в России, оно открылось в 2019 году при поддержке благотворительного фонда «Бумажная птица». Хоспис оказывает паллиативную помощь, и здесь важно всё: не только медицинская, но и социальная, психологическая и духовная поддержка.

Территория оказалась невероятно красивой. Ухоженный парк, аккуратные дорожки, здание в усадебном стиле — на фотографиях, которые я сделал, это отлично видно. Мы помогали по хозяйству приводить в порядок территорию: что-то подстригали, что-то убирали, где-то просто наводили красоту и красили. Физическая работа на свежем воздухе — именно то, что было нужно. Приехал без задних лап.

А после — «по-императорски» откушали на террасе. Честно, это был один из самых вкусных и желанных обедов за последнее время. Не потому, что кухня была ресторанной или фуршетной (всё было очень достойно), а потому, что после реального дела и на таком красивом фоне еда воспринимается иначе. В тот день я спал как убитый — коллегам я этого не говорил, но это было фактом. Надо будет повторить — и пользу принёс, и сам отвлёкся от города и текущих дел.

Кстати, если вы тоже хотите найти подобные мероприятия, очень удобно пользоваться платформой dobro.ru (DoBro — «Просто Делай Бро», звучит! :) ) — там собраны тысячи волонтёрских событий: от помощи приютам до экологических акций. Заполняете профиль, выбираете то, что цепляет, подаёте заявку — и вперёд.

День второй: ярмарка RWB Участие в офисе

А сегодня в офисе прошла благотворительная ярмарка RWB Участие. Это уже не первая такая ярмарка. Два раза утром я проходил мимо, а на третий раз выкроилось время — заглянул и не прогадал. Все три раза, кстати, коллеги толпились вокруг и разглядывали все.

На первой ярмарке я приобрёл стакан для очков «Самое время жить» — маме он очень нравится, пользуется до сих пор. От сегодняшнего визита я не ждал чего-то особенного, но хотелось чего-то необычного, как и в прошлый раз.

И не прогадал. Во-первых, случайно встретил Татьяну Владимировну Ким — основателя Wildberries, главу РВБ. Встреча была неожиданной, но очень тёплой. Ну и посчастливилось сделать фото на память.

Во-вторых, купил книгу. И да, я знал, что книги есть на Wildberries, но не думал, что их можно купить прямо на ярмарке в офисе. Бумажные книги приятнее покупать физически — прикоснуться к бумаге, полистать. Теперь у меня есть экземпляр с автографом — но его я вам не покажу, это личное :).

О какой книге речь? О сборнике историй партнёров Wildberries. В предисловии Татьяна Ким пишет:

«Эта книга не о брендах, а о людях, которые изменили свою жизнь раз и навсегда… Дело не в удаче, а в подходе и отношении, в ваших усилиях и желании сделать самое лучшее. Можно сказать, что эта книга о мечте — большой, искренней, исполнимой!»

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

Вторая книга — «Я — Сания» Дианы Машковой и Сании Испергеновой. Это история сироты, написанная в соавторстве с известной писательницей. Книга вышла в рамках проекта «Библиотека благотворительного фонда “Арифметика добра”». Тяжёлая, но важная история. Записал в план на чтение и в закладки.

Почему это важно

Всё это — и поездка в хоспис, и ярмарка — для меня не просто «мероприятия». Это напоминание о том, что помогать легко. Можно найти мероприятие на dobro.ru и поехать волонтёрить. Можно зайти на ярмарку в офисе и купить что-то у фонда. Можно просто перевести деньги через платформу RWB Участие — там собраны верифицированные НКО, и за каждый благотворительный перевод начисляется кешбэк 3% ягодками.

Лето закончилось, но добрые дела не имеют сезонности. Я точно знаю, что буду повторять этот опыт — и в хосписе, и на ярмарках. Потому что после таких дней действительно лучше спишь. И это не только про физическую усталость. Это про ощущение, что день прожит не зря. Кстати, ещё не скоро, но зимой организуется «Ёлка желаний» — тоже очень интересное благотворительное мероприятие, где можно подарить подарки детям и сделать реальностью чью-то мечту.

Trino + OTP верификация запросов в bi – параноя.mode = true

Fri, 11 Sep 2026 01:17:04 +0300

Представьте: дашборд в BI видят все сотрудники. Закрыть его нельзя — так исторически сложилось. Но данные нужно скрыть. Решение — динамическая фильтрация на уровне SQL: пользователь вводит логин и одноразовый код (TOTP), а запрос показывает только те строки, которые ему разрешены.

Это не полноценная система безопасности, но это работающий барьер, который можно внедрить без изменения BI-системы. В статье — пошаговая инструкция: от демо-таблиц до настройки прав в Trino, генерации QR-кодов и увеличения окна действия OTP.

Архитектура

`catalog.schema.dashboard_users` — справочник сотрудников: логин, имя, отдел, должность, руководитель, TOTP-секрет, флаг активности.
`catalog.schema.dashboard_data` — данные дашборда. У каждой строки есть политика доступа: `ALL`, `OWNER`, `DEPARTMENT`, `MANAGER`, `DIRECTOR`.
Функция `verify_totp` — Python UDF, проверяет OTP-код по секрету и текущему времени.
Итоговый запрос — аутентифицирует пользователя и фильтрует строки по атрибутам.

Пользователь вводит логин и OTP как параметры BI. Если они верны — получает свои данные. Если нет — пустой результат.

Шаг 1. Демо-таблицы

Создадим две таблицы в вымышленной схеме `catalog.schema`.

CREATE TABLE catalog.schema.dashboard_users (
    login         VARCHAR,
    employee_name VARCHAR,
    department    VARCHAR,
    position_name VARCHAR,
    manager_login VARCHAR,
    totp_secret   VARCHAR,
    is_active     BOOLEAN
);

INSERT INTO catalog.schema.dashboard_users VALUES
    ('vasya', 'Василий', 'sales',    'manager',  'ivan',  'JBSWY3DPEHPK3PXP', true),
    ('petya', 'Пётр',    'sales',    'analyst',  'vasya', 'KRSXG5CTMVRXEZLU', true),
    ('masha', 'Мария',   'finance',  'analyst',  'ivan',  'NB2W45DFOIZA',     true),
    ('ivan',  'Иван',    'management','director', null,   'MFRGGZDFMZTWQ2LK', true);

CREATE TABLE catalog.schema.dashboard_data (
    row_id        BIGINT,
    row_title     VARCHAR,
    amount        DECIMAL(12,2),
    owner_login   VARCHAR,
    department    VARCHAR,
    manager_login VARCHAR,
    access_policy VARCHAR
);

INSERT INTO catalog.schema.dashboard_data VALUES
    (1, 'Личная строка Васи',       1000.00, 'vasya', 'sales',   'ivan',  'OWNER'),
    (2, 'Личная строка Пети',       2000.00, 'petya', 'sales',   'vasya', 'OWNER'),
    (3, 'Общая строка отдела Sales',3000.00, null,    'sales',   null,    'DEPARTMENT'),
    (4, 'Общая строка Finance',     4000.00, null,    'finance', null,    'DEPARTMENT'),
    (5, 'Строка команды Васи',      5000.00, 'petya', 'sales',   'vasya', 'MANAGER'),
    (6, 'Строка команды Ивана',     6000.00, 'masha', 'finance', 'ivan',  'MANAGER'),
    (7, 'Директорская строка',      7000.00, null,    null,      null,    'DIRECTOR'),
    (8, 'Публичная строка',         8000.00, null,    null,      null,    'ALL');

Либо можно сгенерировать коды разово прямо в запросе.

Шаг 1.1. Массовая генерация TOTP-секретов и QR-кодов

Когда пользователей много, вручную придумывать Base32-секреты неудобно. Можно сгенерировать их прямо в Trino при вставке в таблицу `dashboard_users`. Ниже — готовый блок для демо и тестов.

Важно: `random()` в Trino не является криптостойким генератором. Для продакшена секреты лучше генерировать вне Trino (например, через `openssl rand -base64 20` или Python `pyotp.random_base32()`) и вставлять уже готовыми. Для демонстрации и параноидального режима «лишь бы закрыть дашборд» этого достаточно.

Вставка пользователей с автоматической генерацией секретов

INSERT INTO catalog.schema.dashboard_users (
    login,
    employee_name,
    department,
    position_name,
    manager_login,
    totp_secret,
    is_active
)
SELECT
    login,
    employee_name,
    department,
    position_name,
    manager_login,

    -- Генерация Base32-секрета длиной 16 символов (80 бит)
    array_join(
        transform(
            sequence(1, 16),
            i -> substr(
                'ABCDEFGHIJKLMNOPQRSTUVWXYZ234567',
                CAST(floor(random() * 32) + 1 AS INTEGER),
                1
            )
        ),
        ''
    ) AS totp_secret,

    true AS is_active
FROM (
    VALUES
        ('vasya', 'Василий', 'sales',     'manager',  'ivan'),
        ('petya', 'Пётр',    'sales',     'analyst',  'vasya'),
        ('masha', 'Мария',   'finance',   'analyst',  'ivan'),
        ('ivan',  'Иван',    'management','director', CAST(NULL AS VARCHAR))
) AS src (
    login,
    employee_name,
    department,
    position_name,
    manager_login
);

Как получить строку для QR-кода

После вставки можно сразу сформировать URI формата `otpauth://`, который останется только превратить в QR-код любым генератором:

SELECT
    login,
    totp_secret,
    'otpauth://totp/DemoBI:' || login
        || '?secret=' || totp_secret
        || '&issuer=DemoBI' AS otpauth_uri
FROM catalog.schema.dashboard_users;

Пример результата:

login	totp_secret	otpauth_uri
vasya	JBSWY3DPEHPK3PXP	otpauth://totp/DemoBI:vasya?secret=JBSWY3DPEHPK3PXP&issuer=DemoBI
petya	KRSXG5CTMVRXEZLU	otpauth://totp/DemoBI:petya?secret=KRSXG5CTMVRXEZLU&issuer=DemoBI

Эту строку можно вставить в любой генератор QR-кодов (онлайн или офлайн), а затем отсканировать приложением:

Google Authenticator,
Yandex ID,
KeePass (с плагином TOTP),
и любым другим менеджером паролей, поддерживающим TOTP.

Настройка длины секрета

`sequence(1, 16)` — 16 символов Base32 = 80 бит. Этого достаточно для большинства случаев и именно такую длину часто используют по умолчанию.
Если хотите более длинный секрет, замените `16` на `32`. Тогда получится 160 бит.
Алфавит `’ABCDEFGHIJKLMNOPQRSTUVWXYZ234567’` — это стандартный Base32-алфавит (без цифр 0, 1, 8, 9). Менять его не нужно.

Если нужен детерминированный секрет (не рекомендуется)

Иногда для тестов хотят, чтобы секрет зависел от логина. Можно использовать хеш:

substr(
    upper(to_base32(from_utf8(login || 'some_salt'))),
    1, 16
) AS totp_secret

Но это небезопасно: зная логин и соль, можно вычислить секрет. Для реальной эксплуатации используйте случайную генерацию вне Trino.

Шаг 2. Inline-функция для тестов в DBeaver

В DBeaver можно использовать `WITH FUNCTION` — Python-код прямо в запросе. Это удобно для отладки, но не работает в BI, потому что BI схлопывает запрос в одну строку и ломает форматирование Python.

WITH FUNCTION verify_totp(secret VARCHAR, code VARCHAR, time_step BIGINT)
RETURNS BOOLEAN
LANGUAGE PYTHON
WITH (handler = 'verify_handler')
AS $$
import hmac, hashlib, struct, base64

def verify_handler(secret_b32, code, time_step):
    if secret_b32 is None or code is None or time_step is None:
        return False

    code = str(code).strip()
    if not code.isdigit() or len(code) != 6:
        return False

    secret = str(secret_b32).strip().replace(" ", "").upper()
    padding = "=" * ((8 - len(secret) % 8) % 8)

    try:
        key = base64.b32decode(secret + padding, casefold=True)
    except Exception:
        return False

    current = int(time_step // 30)   # 30 секунд — стандарт TOTP
    for offset in (-1, 0, 1):
        counter = current + offset
        msg = struct.pack(">Q", counter)
        digest = hmac.new(key, msg, hashlib.sha1).digest()
        o = digest[19] & 15
        expected = (struct.unpack(">I", digest[o:o+4])[0] & 0x7fffffff) % 1000000
        expected_code = f"{expected:06d}"
        if hmac.compare_digest(expected_code, code):
            return True
    return False
$$
SELECT verify_totp('JBSWY3DPEHPK3PXP', '123456', CAST(to_unixtime(now()) AS BIGINT));

Важно: тело функции должно начинаться с новой строки после `$$`. Если BI отправляет всё в одну строку — будет ошибка `Function definition must start with a newline after opening quotes`.

Шаг 3. Регистрация функции администратором

Чтобы BI-запросы не содержали Python-код, функцию нужно создать один раз на стороне Trino. Это делает администратор или пользователь с правами на создание функций.

Сразу еще скажу, что регистрация не во всех каталогах работает, в iceberg например не работает, а вот в iceberg + rest надо проверять. Такая фича давно в плане, но не уверен готова ли. Можно регать функции в каталоге memory конектора, но это придется делать каждую загрузку.

DROP FUNCTION IF EXISTS catalog.schema.verify_totp(VARCHAR, VARCHAR, BIGINT);

CREATE FUNCTION catalog.schema.verify_totp(
    secret VARCHAR,
    code VARCHAR,
    time_step BIGINT
)
RETURNS BOOLEAN
LANGUAGE PYTHON
WITH (handler = 'verify_handler')
AS $$
import hmac, hashlib, struct, base64

def verify_handler(secret_b32, code, time_step):
    if secret_b32 is None or code is None or time_step is None:
        return False

    code = str(code).strip()
    if not code.isdigit() or len(code) != 6:
        return False

    secret = str(secret_b32).strip().replace(" ", "").upper()
    padding = "=" * ((8 - len(secret) % 8) % 8)

    try:
        key = base64.b32decode(secret + padding, casefold=True)
    except Exception:
        return False

    current = int(time_step // 30)
    for offset in (-1, 0, 1):
        counter = current + offset
        msg = struct.pack(">Q", counter)
        digest = hmac.new(key, msg, hashlib.sha1).digest()
        o = digest[19] & 15
        expected = (struct.unpack(">I", digest[o:o+4])[0] & 0x7fffffff) % 1000000
        expected_code = f"{expected:06d}"
        if hmac.compare_digest(expected_code, code):
            return True
    return False
$$;

Проверка:

SELECT catalog.schema.verify_totp(
    'JBSWY3DPEHPK3PXP',
    '465617',
    CAST(to_unixtime(now()) AS BIGINT)
) AS is_valid;

Примечание: в вашей среде создание функции может быть не разрешено без настройки прав. Об этом — следующий шаг.

Шаг 4. Настройка прав доступа

Нужно разрешить группе admins создавать функции в схеме `catalog.schema`, а группе bi_users — только вызывать `verify_totp`. В Trino это делается через system access control.

Вариант A. File-based ACL

Файл `/etc/trino/access-control.properties`:

access-control.name=file
security.config-file=/etc/trino/rules/access-control.json
security.refresh-period=1m

Файл `access-control.json`:

{
  "catalogs": [
    {
      "group": "admins",
      "catalog": "catalog",
      "allow": "all"
    },
    {
      "group": "bi_users",
      "catalog": "catalog",
      "allow": "read-only"
    }
  ],
  "schemas": [
    {
      "group": "admins",
      "catalog": "catalog",
      "schema": "schema",
      "owner": true
    },
    {
      "group": "bi_users",
      "catalog": "catalog",
      "schema": "schema",
      "owner": false
    }
  ],
  "functions": [
    {
      "group": "admins",
      "catalog": "catalog",
      "schema": "schema",
      "function": ".*",
      "privileges": ["EXECUTE", "GRANT_EXECUTE", "OWNERSHIP"]
    },
    {
      "group": "bi_users",
      "catalog": "catalog",
      "schema": "schema",
      "function": "verify_totp",
      "privileges": ["EXECUTE"]
    }
  ]
}

Вариант B. OPA (Rego)

Если Trino использует OPA, политика может выглядеть так:

package trino

default allow := false

is_admin {
    input.context.identity.groups[_] == "admins"
}

is_bi_user {
    input.context.identity.groups[_] == "bi_users"
}

is_target_schema {
    input.action.resource.catalog.name == "catalog"
    input.action.resource.schema.name == "schema"
}

is_verify_totp {
    input.action.resource.catalog.name == "catalog"
    input.action.resource.schema.name == "schema"
    input.action.resource.function.name == "verify_totp"
}

allow {
    is_admin
    is_target_schema
    input.action.operation == "CreateFunction"
}

allow {
    is_admin
    is_target_schema
    input.action.operation == "DropFunction"
}

allow {
    is_admin
    is_target_schema
    input.action.operation == "ExecuteFunction"
}

allow {
    is_bi_user
    is_verify_totp
    input.action.operation == "ExecuteFunction"
}

Точные названия операций (`CreateFunction`, `ExecuteFunction`) лучше уточнить в логах OPA при тестовом запросе.

Шаг 5. Запрос для BI (без Python)

После регистрации функции BI-запрос становится обычным SQL. Пользователь вводит `:login` и `:otp` как параметры.

WITH auth_user AS (
    SELECT
        login,
        employee_name,
        department,
        position_name,
        manager_login
    FROM catalog.schema.dashboard_users
    WHERE login = lower(trim(':login'))
      AND is_active = true
      AND catalog.schema.verify_totp(
            totp_secret,
            trim(':otp'),
            CAST(to_unixtime(now()) AS BIGINT)
          )
    LIMIT 1
)
SELECT
    d.row_id,
    d.row_title,
    d.amount,
    d.owner_login,
    d.department,
    d.manager_login,
    d.access_policy,
    a.login AS current_login,
    a.employee_name AS current_employee_name,
    a.department AS current_department,
    a.position_name AS current_position_name,
    CASE
        WHEN d.access_policy = 'ALL' THEN 'Видно всем авторизованным'
        WHEN d.access_policy = 'OWNER' AND d.owner_login = a.login THEN 'Видно владельцу строки'
        WHEN d.access_policy = 'DEPARTMENT' AND d.department = a.department THEN 'Видно сотруднику отдела'
        WHEN d.access_policy = 'MANAGER' AND d.manager_login = a.login THEN 'Видно руководителю'
        WHEN d.access_policy = 'DIRECTOR' AND a.position_name = 'director' THEN 'Видно директору'
        ELSE null
    END AS access_reason
FROM catalog.schema.dashboard_data d
CROSS JOIN auth_user a
WHERE
       d.access_policy = 'ALL'
    OR (d.access_policy = 'OWNER' AND d.owner_login = a.login)
    OR (d.access_policy = 'DEPARTMENT' AND d.department = a.department)
    OR (d.access_policy = 'MANAGER' AND d.manager_login = a.login)
    OR (d.access_policy = 'DIRECTOR' AND a.position_name = 'director');

Важно про параметры: если BI подставляет их как сырой текст, нужны кавычки: `’:login’`, `’:otp’`. Если BI использует bind-параметры — кавычки не нужны: `:login`, `:otp`. В предыдущих ошибках (`Column ‘jbswy3dpehpk3pxp’ cannot be resolved`) видно, что в вашем случае нужны именно кавычки.

Шаг 6. Логика доступа

`auth_user` — возвращает 0 строк, если логин не найден, пользователь неактивен или OTP неверный.
`CROSS JOIN auth_user` — если `auth_user` пуст, результат всего запроса пуст.
`WHERE` с `OR` — оставляет только те строки, которые разрешены политикой:
- `ALL` — всем авторизованным;
- `OWNER` — владельцу (`owner_login = a.login`);
- `DEPARTMENT` — сотруднику того же отдела;
- `MANAGER` — руководителю (`manager_login = a.login`);
- `DIRECTOR` — директору (`position_name = ‘director’`).

Пример: `vasya` увидит свои строки, строки отдела `sales`, строки, где он руководитель, и публичные. `petya` — только свои, отдел `sales` и публичные.

Шаг 7. Генерация QR-кода для OTP

Каждому пользователю нужно выдать TOTP-секрет и удобно передать его в приложение-аутентификатор. Стандартный способ — использовать URI формата `otpauth://`.

Пример для пользователя `vasya`:

otpauth://totp/DemoBI:vasya?secret=JBSWY3DPEHPK3PXP&issuer=DemoBI

Здесь:

`DemoBI:vasya` — метка, которая отобразится в приложении. Можно заменить на название отчёта, отдела или что угодно, например `SalesDashboard:vasya`.
`secret=JBSWY3DPEHPK3PXP` — Base32-секрет.
`issuer=DemoBI` — имя издателя, обычно название компании или системы.

Эту строку можно вставить в любой генератор QR-кодов (онлайн или офлайн). После генерации QR-код сканируется приложением:

Google Authenticator,
Yandex ID,
KeePass (с плагином TOTP),
и любым другим менеджером паролей, поддерживающим TOTP.

Это стандарт, поэтому совместимость широкая. QR-код можно распечатать или отправить пользователю.

Совет: если у вас много пользователей, сгенерируйте QR-коды автоматически из таблицы `dashboard_users`, подставляя логин и секрет.

Шаг 8. Увеличение окна действия OTP (2–5 минут)

По умолчанию TOTP-код действует 30 секунд. Это может быть неудобно: пользователь не успевает ввести код. Можно увеличить окно действия, изменив функцию.

В Python-коде есть строка:

current = int(time_step // 30)

Здесь `30` — это количество секунд в одном временном шаге. Если заменить `30` на `300`, то код будет действителен 5 минут (300 секунд). При этом приложение-аутентификатор продолжит генерировать коды каждые 30 секунд, но сервер будет принимать любой код, сгенерированный в течение этих 5 минут. Это удобно и безопасно: окно не бесконечное, но достаточное, чтобы успеть ввести код.

Пример изменённой функции:

current = int(time_step // 300)   # 5 минут
for offset in (-1, 0, 1):
    ...

Если оставить смещения `-1, 0, 1`, то общее окно станет 15 минут (5 минут назад, текущие 5 минут, 5 минут вперёд). Это может быть избыточно. Лучше убрать смещения и проверять только текущий интервал:

current = int(time_step // 300)
counter = current
msg = struct.pack(">Q", counter)
...
# без цикла for

Тогда код будет действителен ровно 5 минут.

Если хотите 2 минуты — используйте `120` вместо `300`.

Важно: после изменения функции её нужно пересоздать ( `DROP FUNCTION` и `CREATE FUNCTION` ). Все пользователи автоматически начнут работать с новым окном.

Шаг 9. Безопасность

Секреты TOTP нельзя хранить в открытой схеме. Лучше вынести `dashboard_users` в закрытую схему, например `security.users`.
BI-пользователи не должны иметь прямой доступ к таблице с секретами. Только к функции и к данным.
OTP-код попадает в логи Trino и BI. Логи могут быть доступны администраторам или храниться в системе. Это не смертельно, потому что код короткоживущий, но помните: любой, кто видит лог, может увидеть введённый OTP. Если окно действия увеличено до 5 минут, риск возрастает. По возможности используйте реального пользователя из аутентификации BI, а не ручной ввод логина.
Права на создание функций — только у группы `admins`. BI-пользователям — только `EXECUTE` на конкретную функцию.

Заключение

Мы построили параноидальный, но рабочий механизм: OTP-аутентификация + динамическая фильтрация строк на уровне SQL. Это не заменяет полноценный RBAC, но позволяет быстро закрыть дашборд от посторонних глаз без изменения BI-системы.

Что проверено: inline-функция в DBeaver, запрос с фильтрацией, логика доступа.
Что требует настройки: регистрация функции и права в Trino. После настройки прав (шаг 4) функция создаётся один раз, а BI-запросы становятся чистыми и безопасными.

Удачи в паранойе! :)

Современный семантический слой на dbt + MetricFlow + DuckDB: макросы вместо пакетов

Wed, 09 Sep 2026 22:52:12 +0300

В этой статье мы построим полностью рабочий семантический слой для аналитики на данных Superstore.csv (от Tableau Desktop, можно скачать его где-то), используя dbt, MetricFlow и DuckDB. Вместо устаревшего пакета `dbt_metrics` (который несовместим с dbt 1.12+), мы применим современный подход — вынесем логику метрик в макросы dbt. Это позволяет централизованно управлять расчётами, автоматически обновлять витрины при изменении метрик и использовать семантический слой для ad-hoc-запросов через `mf`. Все шаги проверены на последних версиях инструментов и готовы к использованию в реальных проектах.

1. Зачем нужен семантический слой и почему макросы — это современный подход?

Семантический слой решает ключевые проблемы аналитики:

Единое место определения метрик — бизнес-логика хранится в одном файле.
Автоматическая генерация SQL — не нужно писать `GROUP BY`, `JOIN` и агрегации вручную для ad-hoc-запросов.
Согласованность — аналитики и BI-инструменты используют одни и те же метрики.

Ранее для использования метрик в моделях применялся пакет `dbt_metrics`, но он несовместим с dbt 1.12 и выше (требует версию <1.6.0). Современный подход — **выносить выражения метрик в макросы dbt**. Это:

Не требует внешних пакетов.
Работает с любой версией dbt.
Даёт полный контроль над SQL.
Легко поддерживается и версионируется.

Мы будем использовать:

dbt 1.12.4 — для управления моделями и витринами.
MetricFlow (встроенный в dbt) — для семантического слоя и ad-hoc-запросов через `mf`.
DuckDB 1.5.5 — лёгкая БД для разработки.
Макросы dbt — для переиспользования логики метрик в витринах.

2. Установка инструментов и создание проекта

Используем `uv` — быстрый менеджер пакетов Python.

mkdir dbtflow_duck
cd dbtflow_duck

uv init
uv venv
source .venv/bin/activate

uv pip install dbt-duckdb dbt-metricflow pandas duckdb

Проверяем версии (на момент написания):

dbt-core: 1.12.4
duckdb: 1.5.5
metricflow: 0.212.0

3. Загрузка данных Superstore

Скачайте `Superstore.csv` (например, с Kaggle) и поместите в корень проекта.

Создайте `load_data.py`:

import pandas as pd
import duckdb

df = pd.read_csv('Superstore.csv', sep='\t', encoding='latin1')
df.columns = [col.lower().replace(' ', '_').replace('/', '_').replace('-', '_') for col in df.columns]

for col in ['sales', 'discount', 'profit']:
    if col in df.columns:
        df[col] = df[col].astype(str).str.replace(',', '.').astype(float)

df['order_date'] = pd.to_datetime(df['order_date'], dayfirst=True)
df['ship_date'] = pd.to_datetime(df['ship_date'], dayfirst=True)
df['postal_code'] = df['postal_code'].astype(str)

db_path = 'dbtflow_duck.duckdb'
con = duckdb.connect(db_path)

con.execute("DROP TABLE IF EXISTS superstore")
con.execute("""
CREATE TABLE superstore (
    row_id INTEGER, order_id VARCHAR, order_date DATE, ship_date DATE,
    ship_mode VARCHAR, customer_id VARCHAR, customer_name VARCHAR, segment VARCHAR,
    country_region VARCHAR, city VARCHAR, state VARCHAR, postal_code VARCHAR,
    region VARCHAR, product_id VARCHAR, category VARCHAR, sub_category VARCHAR,
    product_name VARCHAR, sales DOUBLE, quantity INTEGER, discount DOUBLE, profit DOUBLE
)
""")

con.execute("INSERT INTO superstore SELECT * FROM df")
print(f"✅ Загружено {len(df)} строк в {db_path}")
con.close()

Запуск:

python load_data.py

4. Инициализация dbt-проекта вручную

Создаём папку проекта и файлы конфигурации (без `dbt init`, чтобы избежать проблем):

mkdir dbt_project
cd dbt_project

dbt_project.yml:

name: 'dbt_project'
version: '1.0.0'
profile: 'dbt_project'

model-paths: ["models"]
analysis-paths: ["analyses"]
test-paths: ["tests"]
seed-paths: ["seeds"]
macro-paths: ["macros"]
snapshot-paths: ["snapshots"]

clean-targets:
  - "target"
  - "dbt_packages"

models:
  dbt_project:
    +materialized: table

profiles.yml:

dbt_project:
  target: dev
  outputs:
    dev:
      type: duckdb
      path: ../dbtflow_duck.duckdb
      schema: main
      threads: 4

Создаём структуру папок:

mkdir -p models analyses tests seeds macros snapshots
export DBT_PROFILES_DIR=$(pwd)
dbt debug   # должно быть All checks passed!

5. Модели данных

models/sources.yml:

version: 2

sources:
  - name: default
    schema: main
    tables:
      - name: superstore

models/superstore_clean.sql:

{{ config(materialized='table') }}

SELECT
    row_id,
    order_id,
    order_date,
    ship_date,
    ship_mode,
    customer_id,
    customer_name,
    segment,
    country_region,
    city,
    state,
    postal_code,
    region,
    product_id,
    category,
    sub_category,
    product_name,
    sales,
    quantity,
    discount,
    profit
FROM {{ source('default', 'superstore') }}

models/time_spine.sql:

{{ config(materialized='table') }}

SELECT 
    CAST(generate_series AS DATE) AS date_day
FROM generate_series(DATE '2020-01-01', DATE '2026-12-31', INTERVAL '1' DAY)

models/metricflow_time_spine.yml (обязательно для MetricFlow):

models:
  - name: time_spine
    description: "A time spine with one row per day for MetricFlow."
    time_spine:
      standard_granularity_column: date_day
    columns:
      - name: date_day
        granularity: day

6. Семантическая модель и метрики

models/superstore.yml:

semantic_models:
  - name: superstore
    model: ref('superstore_clean')
    description: "Superstore sales data"
    defaults:
      agg_time_dimension: order_date
    
    entities:
      - name: order_id
        type: primary
        
    dimensions:
      - name: order_date
        type: time
        type_params:
          time_granularity: day
      - name: category
        type: categorical
      - name: region
        type: categorical
    
    measures:
      - name: total_sales
        agg: sum
        expr: sales
      - name: total_profit
        agg: sum
        expr: profit
      - name: total_discount
        agg: average          # Внимание: не "avg", а "average"!
        expr: discount

metrics:
  - name: total_sales
    label: Total Sales
    type: simple
    type_params:
      measure: total_sales
  - name: total_profit
    label: Total Profit
    type: simple
    type_params:
      measure: total_profit
  - name: avg_discount
    label: Average Discount
    type: simple
    type_params:
      measure: total_discount
  - name: profit_margin
    label: Profit Margin
    type: derived
    type_params:
      expr: total_profit / total_sales
      metrics:
        - total_profit
        - total_sales

Выполняем сборку и генерацию артефактов:

dbt run
dbt parse

7. Ad-hoc-запросы через MetricFlow CLI (`mf`)

Проверяем конфигурацию:

mf validate-configs

Список метрик:

mf list metrics

Вывод:

• avg_discount: metric_time, order_id__category, order_id__order_date, order_id__region
• profit_margin: metric_time, order_id__category, order_id__order_date, order_id__region
• total_profit: metric_time, order_id__category, order_id__order_date, order_id__region
• total_sales: metric_time, order_id__category, order_id__order_date, order_id__region

Примеры запросов:

mf query --metrics total_sales --group-by order_id__category
mf query --metrics profit_margin --group-by order_id__region
mf query --metrics avg_discount --group-by order_id__category

MetricFlow генерирует SQL автоматически — мы не пишем ни строчки кода для этих запросов.

8. Современный подход: макросы для переиспользования метрик в витринах

Вместо устаревшего пакета `dbt_metrics` мы создадим макросы, которые возвращают SQL-выражение для каждой метрики. Это позволяет:

Централизованно управлять логикой расчёта.
Использовать одну и ту же логику во всех витринах.
Легко изменять метрику в одном месте.

macros/get_metric_expr.sql:

{% macro get_total_sales_expr() %}
    SUM(sales)
{% endmacro %}

{% macro get_total_profit_expr() %}
    SUM(profit)
{% endmacro %}

{% macro get_avg_discount_expr() %}
    AVG(discount)
{% endmacro %}

{% macro get_profit_margin_expr() %}
    {{ get_total_profit_expr() }} / NULLIF({{ get_total_sales_expr() }}, 0)
{% endmacro %}

Теперь мы можем строить витрины, используя эти макросы.

models/sales_by_category.sql:

{{ config(materialized='table') }}

SELECT
    category,
    {{ get_total_sales_expr() }} AS total_sales
FROM {{ ref('superstore_clean') }}
GROUP BY category

models/profit_by_region.sql:

{{ config(materialized='table') }}

SELECT
    region,
    {{ get_total_profit_expr() }} AS total_profit,
    {{ get_profit_margin_expr() }} AS profit_margin
FROM {{ ref('superstore_clean') }}
GROUP BY region

models/avg_discount_by_category.sql:

{{ config(materialized='table') }}

SELECT
    category,
    {{ get_avg_discount_expr() }} AS avg_discount
FROM {{ ref('superstore_clean') }}
GROUP BY category

После добавления новых моделей выполняем `dbt run` — все витрины создаются с актуальной логикой метрик.

9. Преимущества подхода с макросами

Совместимость — работает с любой версией dbt, без внешних пакетов.
Гибкость — можно легко добавлять фильтры, условия, использовать оконные функции.
Прозрачность — SQL-код виден и контролируется, его легко отлаживать.
Единый источник истины — метрики определены как в YAML (для `mf`), так и в макросах (для витрин).
Автоматизация — изменения в макросах автоматически обновляют все витрины при следующем `dbt run`.

10. Расширенный пример: добавление фильтра в метрику

Предположим, нам нужна выручка только для категории “Technology”. Мы можем создать отдельный макрос:

{% macro get_tech_sales_expr() %}
    SUM(CASE WHEN category = 'Technology' THEN sales ELSE 0 END)
{% endmacro %}

И использовать его в витрине:

{{ config(materialized='table') }}

SELECT
    region,
    {{ get_tech_sales_expr() }} AS tech_sales
FROM {{ ref('superstore_clean') }}
GROUP BY region

Это демонстрирует, насколько легко расширять систему без изменения основной семантической модели.

11. Автоматизация пайплайнов

Настройте регулярный запуск `dbt run` в CI/CD или Airflow. При каждом запуске:

Обновляются сырые данные (если они загружаются заново).
Пересчитываются модели `superstore_clean` и `time_spine`.
Пересчитываются все витрины с актуальной логикой метрик из макросов.

Таким образом, ваши отчёты всегда актуальны, а бизнес-логика централизована.

12. Заключение

Мы построили современный семантический слой на стеке dbt + MetricFlow + DuckDB, используя макросы для переиспользования логики метрик в витринах. Этот подход:

Не требует устаревших пакетов.
Совместим с последними версиями dbt.
Даёт полный контроль над SQL.
Легко масштабируется и поддерживается.

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

Полезные ссылки:

Huawei Mate XT 2 и Huawei Pura X View

Mon, 07 Sep 2026 22:48:56 +0300

Huawei скоро весь рынок переформатирует :) точнее форм-фрагментирует потом фиг загонят всех обратно в прямоугольники. Ждем телефон для кружочкаф :))

Apache Airflow или Temporal: выбор между оркестрацией данных и бизнес-логикой

Mon, 07 Sep 2026 22:11:01 +0300

В мире разработки и инженерии данных инструменты Apache Airflow и Temporal часто могут восприниматься как конкуренты, поскольку оба решают задачу управления многошаговыми процессами. Однако на практике их философия, архитектура и сценарии использования настолько разные, что сравнивать их корректно можно лишь с четким пониманием контекста задачи.

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

1. В чем суть каждого инструмента?

Apache Airflow — это классический оркестратор batch-процессов. Он создавался как решение для управления ETL/ELT-пайплайнами, регулярной загрузки данных, построения отчетов и ML-циклов. Центральная концепция Airflow — DAG (направленный ациклический граф), который описывает зависимости между задачами и обычно запускается по расписанию (например, ежедневно в 6 утра).

Temporal — это платформа для надежного исполнения распределенных бизнес-процессов. Она не просто «запускает задачи», а управляет долгоживущими workflow с сохранением состояния, автоматическими повторами, обработкой сбоев и возможностью ждать внешние события (ответ пользователя, платеж, подтверждение от другой системы). Workflow в Temporal пишутся на обычном коде и выполняются детерминированно.

2. Главное различие

Airflow — это продвинутый планировщик для задач по расписанию в мире данных.
Temporal — это движок надежного исполнения бизнес-логики в распределенных системах, который «помнит» состояние процесса даже через неделю.

3. Сравнительная таблица

Критерий	Apache Airflow	Temporal
Основное назначение	Оркестрация batch-задач и data pipeline’ов	Надежное выполнение бизнес-процессов и workflow
Типичные сценарии	ETL, загрузка данных, отчеты, ML-обучение, backfill	Оформление заказов, платежи, onboarding, Saga-паттерны, фоновые операции
Модель выполнения	DAG из задач (Task)	Workflow + Activities
Основной фокус	Планирование и запуск по расписанию	Состояние, устойчивость, ретраи, долгие ожидания
Работа с расписанием	Отлично (родная функциональность)	Возможна, но не основная цель
Долгоживущие процессы (дни/недели)	Не подходит (сложно и неэффективно)	Одно из ключевых преимуществ
Управление состоянием	Ограниченное (обычно через внешние хранилища)	Встроенная, полная история выполнения
Повторные попытки (retries)	Есть, на уровне задач	Гибкие стратегии, таймауты, компенсации
Устойчивость к сбоям	Хорошая для batch-задач	Исключительная (продолжает с места сбоя)
Язык разработки	Python (DAG-файлы)	Go, Java, TypeScript, Python и другие
Наблюдаемость	UI для DAG, логи, статусы задач	UI с историей событий, ретраями и состоянием workflow
Сложность внедрения	Относительно низкая для data-команд	Выше (требует проектирования workflow и инфраструктуры)
Идеально подходит для Data Engineering	✅ Да	❌ Часто избыточно
Идеально подходит для микросервисов	❌ Ограниченно	✅ Да
Масштабирование	Хорошее, но требует тонкой настройки	Рассчитан на распределенные системы с рождения
Основная аудитория	Data Engineers, ML Engineers, аналитики	Backend Engineers, Platform Engineers, команды микросервисов

4. Сложности и подводные камни

4.1. Когда Airflow становится тяжелым

На старте Airflow кажется простым, но по мере роста числа DAG’ов и их сложности возникают типичные проблемы:

Зоопарк DAG’ов — тысячи графов трудно поддерживать и отлаживать.
Жесткая привязка к расписанию — неудобно моделировать процессы, зависящие от событий, а не от времени.
Слабая работа с долгими процессами — если задача выполняется несколько часов, Airflow справится, но если процесс длится дни с ожиданием внешнего действия — начнутся трудности.
Промежуточное состояние — его нужно сохранять во внешних системах (S3, Redis, БД), что усложняет архитектуру.
Риск превращения в «универсальный Cron» — когда в Airflow пытаются запихнуть всё подряд, поддержка становится кошмаром.

Вывод: Airflow хорош для периодических, четко структурированных задач с понятным началом и концом. Для сложной бизнес-логики он не предназначен.

4.2. Когда Temporal требует дисциплины

Temporal дает суперспособности, но платой за них является более высокая инженерная культура:

Детерминированность — код Workflow обязан быть детерминированным (например, нельзя использовать `time.Now()` или случайные числа без специальной обертки).
Управление версиями — обновление логики workflow требует аккуратной миграции, иначе сломаются уже запущенные процессы.
Инфраструктура — Temporal требует собственного кластера (Cassandra/PostgreSQL + сервисы), это сложнее, чем поднять Airflow с локальной БД.
Порог входа — разработчикам нужно усвоить модель Workflow/Activity, понять, как работают таймауты и сигналы.

Вывод: Temporal не нужен для простых ETL-задач, но незаменим там, где процесс должен «жить» и не умирать при сбоях.

5. Temporal на платформах данных: когда он может быть полезен

Хотя в классическом data‑инжиниринге безраздельно правит Airflow, современные платформы данных становятся всё более распределёнными, событийно‑ориентированными и критичными к задержкам. В таких экосистемах появляются сценарии, где Temporal оказывается не избыточным, а очень даже востребованным.

Вот несколько примеров, когда Temporal может усилить вашу data‑платформу:

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

Координация распределённых трансформаций
В архитектурах типа Data Mesh или при использовании множества независимых сервисов (например, микросервисы, каждый из которых обновляет свои витрины) Temporal выступает как надёжный координатор, гарантирующий согласованность обновлений даже при частичных отказах.

Event‑driven data pipelines
Вместо жёсткого расписания вы можете запускать workflow по событиям — поступление нового файла в S3, сообщение в Kafka или завершение внешнего процесса. Temporal отлично поддерживает ожидание сигналов, что делает его естественным выбором для реактивных пайплайнов.

Компенсации и исправление данных
Если в процессе загрузки обнаруживается ошибка в уже обработанных данных, Temporal позволяет реализовать компенсирующие действия (откат, дозагрузка, пересчёт) как часть workflow, с полным сохранением контекста.

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

Обеспечение exactly‑once семантики в критичных data‑операциях
Когда повторная обработка одних и тех же данных недопустима (финансовые отчёты, списания), Temporal с его идемпотентными Activity и уникальными идентификаторами workflow даёт высокие гарантии.

При этом Temporal не заменяет Airflow для стандартных ETL по расписанию. Однако если на вашей платформе данных есть процессы, которые:

длятся дольше пары часов,
требуют строгого состояния,
зависят от внешних событий,
должны безупречно восстанавливаться после сбоев,

— то Temporal может стать вторым (и очень мощным) инструментом в вашем арсенале, работающим плечом к плечу с Airflow.

6. Рекомендации по выбору

Выбирайте Airflow, если:

Ваша задача — регулярный запуск batch-процессов (ежедневно, почасово).
Вы строите ETL/ELT, витрины данных, ML-пайплайны.
Процесс укладывается в DAG с четкими шагами.
Команда хорошо знает Python и работает в среде data-инженерии.
Вам нужен backfill (перезапуск за прошлые периоды).

Примеры: загрузка из CRM в DWH, пересчет отчетов, обучение модели по ночам.

Выбирайте Temporal, если:

Процесс длится часы, дни или недели.
Важен строгий контроль состояния — система должна запомнить, на каком шаге остановилась.
Требуются сложные retries, таймауты и компенсационные транзакции (Saga).
Есть ожидание событий от пользователя или внешнего сервиса.
Вы строите микросервисную архитектуру или современную событийно‑управляемую платформу данных.

Примеры: оформление заказа, прохождение KYC, обработка платежей, доставка товара, долгий процесс верификации, а также упомянутые выше сложные data‑пайплайны с внешними зависимостями.

7. Можно ли использовать их вместе?

Да, и это частая практика в крупных компаниях:

Airflow берет на себя все data-пайплайны и подготовку данных для аналитики.
Temporal отвечает за критичные бизнес-процессы, а также за те data‑процессы, которые требуют повышенной надёжности и управления долгим состоянием.

Например, Airflow утром подготавливает агрегированные данные, а Temporal запускает workflow их распределённой валидации и отправки во внешние системы с гарантией доставки. Инструменты не конфликтуют, а дополняют друг друга.

Итог

	Airflow	Temporal
Слоган	Планировщик для data-задач	Движок надежных процессов (бизнес и data)
Сила	Расписание, простота, Python-экосистема	Состояние, устойчивость, долгие workflow, события
Слабость	Сложность с долгими процессами, состоянием	Высокий порог входа, избыточен для простого расписания

Коротко:

Нужны данные, расписание, отчёты → Airflow.
Нужны бизнес-логика, надёжность, долгие операции, событийная оркестрация (включая сложные сценарии на платформе данных) → Temporal.

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

Генерация синтетических данных с помощью SDV: от идеи до готовой таблицы в ClickHouse

Thu, 03 Sep 2026 00:49:26 +0300

Синтетические данные давно перестали быть просто «искусственной картинкой» — сегодня это полноценный инструмент для тестирования, разработки и даже обучения моделей машинного обучения. В этой статье я на примере реального кода покажу, как с помощью библиотеки SDV ( Synthetic Data Vault ) можно сгенерировать синтетическую копию существующей таблицы из ClickHouse, сохранив её статистические свойства и взаимосвязи.

Весь код, который мы разберём, написан на Python и использует актуальную версию SDV. Спойлер: итоговый скрипт занимает меньше 80 строк, а результат — полностью готовая синтетическая таблица в вашей базе данных.

Что такое SDV и зачем он нужен

Synthetic Data Vault (SDV) — это Python-библиотека с открытым исходным кодом, которая стала фактическим стандартом для генерации синтетических табличных данных. Она была создана в MIT, а сегодня развивается компанией DataCebo.

Главная идея SDV проста: вы даёте ей реальные данные, она обучает генеративную модель, а затем эта модель создаёт новые данные, которые статистически неотличимы от оригинала, но при этом не содержат реальных записей.

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

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

SDV умеет работать с одиночными таблицами, связанными таблицами и даже последовательными данными.

Какие синтезаторы предлагает SDV

SDV предлагает несколько алгоритмов (синтезаторов) на выбор. В нашем примере мы используем `GaussianCopulaSynthesizer` — и вот почему.

Синтезатор	Принцип работы	Скорость	Когда использовать
GaussianCopulaSynthesizer	Классический статистический метод, моделирует данные через многомерное распределение	Очень быстрый	Рекомендуется для старта: быстрая работа, хорошее качество, прозрачность
CTGANSynthesizer	Генеративно-состязательная сеть (GAN)	Медленнее	Для данных со сложными зависимостями или большим количеством категориальных признаков
TVAESynthesizer	Вариационный автокодировщик	Средняя	Альтернатива GAN, требующая больше данных для обучения

`GaussianCopulaSynthesizer` отлично справляется со смешанными типами данных, которые встречаются в реальных таблицах: числа, строки, даты. При этом он обучается за секунды даже на десятках тысяч строк. Именно поэтому мы выбрали его для нашего примера.

Настройка окружения

Перед запуском кода нам потребуется установить несколько пакетов. В нашем проекте мы использовали `uv` — быстрый менеджер пакетов для Python.

uv pip install torch==2.2.2
uv pip install "numpy<2"
uv pip install "scipy<1.13"
uv pip install sdv
uv pip install clickhouse-connect

Важно: версии пакетов подобраны так, чтобы избежать конфликтов. На момент написания статьи `torch` версии 2.13.0 не имеет готовых сборок для macOS на Intel, поэтому мы используем `2.2.2`. Также важно зафиксировать `numpy<2` и `scipy<1.13` — более новые версии несовместимы с текущей версией `torch`.

Полный код генерации синтетических данных

Ниже представлен итоговый скрипт `sdv_py_v5.py`, который мы будем разбирать. Он подключается к ClickHouse, загружает реальные данные, обучает синтезатор, генерирует синтетическую копию и сохраняет результат обратно в базу.

import clickhouse_connect
import pandas as pd
import os
import warnings
from sdv.single_table import GaussianCopulaSynthesizer
from sdv.metadata import SingleTableMetadata

# Подавляем предупреждения (включая депрекацию)
warnings.filterwarnings("ignore")

# Правильный импорт для однотабличных отчётов
from sdmetrics.reports.single_table import QualityReport, DiagnosticReport

# ========== НАСТРОЙКИ ==========
CLICKHOUSE_HOST = 'localhost'
CLICKHOUSE_PORT = 18123
CLICKHOUSE_USER = 'default'
CLICKHOUSE_PASSWORD = 'changeme'
CLICKHOUSE_DATABASE = 'default'

SOURCE_TABLE = 'superstore'
SYNTHETIC_TABLE = f'{SOURCE_TABLE}_synt'
LIMIT_ROWS = 10000
NUM_SYNTHETIC_ROWS = None

# ========== ПОДКЛЮЧЕНИЕ ==========
client = clickhouse_connect.get_client(
    host=CLICKHOUSE_HOST,
    port=CLICKHOUSE_PORT,
    username=CLICKHOUSE_USER,
    password=CLICKHOUSE_PASSWORD,
    database=CLICKHOUSE_DATABASE
)

# ========== ЗАГРУЗКА ==========
query = f"SELECT * FROM {SOURCE_TABLE} LIMIT {LIMIT_ROWS}"
real_df = client.query_df(query)
print(f"Загружено {len(real_df)} строк")

# Преобразуем числовые колонки (запятая → точка)
numeric_cols = ['sales', 'discount', 'profit']
for col in numeric_cols:
    if col in real_df.columns and real_df[col].dtype == 'object':
        real_df[col] = real_df[col].str.replace(',', '.').astype(float)

# ========== МЕТАДАННЫЕ ==========
metadata = SingleTableMetadata()
metadata.detect_from_dataframe(real_df)

if os.path.exists('metadata.json'):
    os.remove('metadata.json')
metadata.save_to_json('metadata.json')
print("Метаданные сохранены в metadata.json")

# ========== ОБУЧЕНИЕ ==========
print("Начинаем обучение синтезатора...")
synthesizer = GaussianCopulaSynthesizer(metadata)
synthesizer.fit(real_df)
print("Обучение завершено")

# ========== ГЕНЕРАЦИЯ ==========
if NUM_SYNTHETIC_ROWS is None:
    NUM_SYNTHETIC_ROWS = len(real_df)
synthetic_df = synthesizer.sample(NUM_SYNTHETIC_ROWS)
print(f"Сгенерировано {len(synthetic_df)} строк")

# ========== ПРЕДПРОСМОТР ==========
print("\nОригинальные данные (первые 5 строк):")
print(real_df.head())
print("\nСинтетические данные (первые 5 строк):")
print(synthetic_df.head())

# ========== ОЦЕНКА КАЧЕСТВА ==========
print("\n--- Диагностика (проверка ошибок) ---")
diagnostic = DiagnosticReport()
diagnostic.generate(real_df, synthetic_df, metadata.to_dict())
print(diagnostic)

print("\n--- Оценка качества (статистическое сходство) ---")
quality = QualityReport()
quality.generate(real_df, synthetic_df, metadata.to_dict())
print(quality)

# ========== СОХРАНЕНИЕ В CLICKHOUSE ==========
client.command(f"CREATE TABLE IF NOT EXISTS {SYNTHETIC_TABLE} AS {SOURCE_TABLE}")
client.insert_df(SYNTHETIC_TABLE, synthetic_df)
print(f"\nСинтетические данные загружены в таблицу {SYNTHETIC_TABLE}")

# ========== СОХРАНЕНИЕ В CSV ==========
synthetic_df.to_csv('synthetic_table.csv', index=False)
print("Синтетические данные также сохранены в synthetic_table.csv")

Разбор кода по шагам

1. Подключение к ClickHouse и загрузка данных

client = clickhouse_connect.get_client(
    host=CLICKHOUSE_HOST,
    port=CLICKHOUSE_PORT,
    username=CLICKHOUSE_USER,
    password=CLICKHOUSE_PASSWORD,
    database=CLICKHOUSE_DATABASE
)

query = f"SELECT * FROM {SOURCE_TABLE} LIMIT {LIMIT_ROWS}"
real_df = client.query_df(query)

Мы подключаемся к ClickHouse через библиотеку `clickhouse-connect` и загружаем данные из таблицы-источника в Pandas DataFrame. Лимит в 10 000 строк — разумный компромисс между качеством обучения и скоростью. Для большинства задач этого объёма достаточно, чтобы синтезатор уловил основные закономерности.

2. Предобработка числовых данных

numeric_cols = ['sales', 'discount', 'profit']
for col in numeric_cols:
    if col in real_df.columns and real_df[col].dtype == 'object':
        real_df[col] = real_df[col].str.replace(',', '.').astype(float)

В нашем примере числовые колонки хранятся в ClickHouse как строки с запятой в качестве десятичного разделителя (европейский формат). Перед обучением мы преобразуем их в числа с плавающей точкой — иначе SDV не сможет корректно обработать эти данные.

3. Создание метаданных

metadata = SingleTableMetadata()
metadata.detect_from_dataframe(real_df)
metadata.save_to_json('metadata.json')

SDV автоматически определяет типы каждой колонки: числовые, категориальные, даты и т.д.. Метаданные сохраняются в JSON-файл — это полезно для воспроизводимости: в следующий раз вы сможете загрузить их, а не пересоздавать заново.

4. Обучение синтезатора

synthesizer = GaussianCopulaSynthesizer(metadata)
synthesizer.fit(real_df)

Синтезатор «изучает» ваши данные: анализирует распределения каждой колонки, корреляции между ними, паттерны пропусков. Этот процесс занимает секунды даже на 10 000 строк.

5. Генерация синтетических данных

synthetic_df = synthesizer.sample(NUM_SYNTHETIC_ROWS)

Метод `sample()` создаёт нужное количество новых записей. В нашем случае мы генерируем столько же строк, сколько было в оригинале. При желании можно увеличить или уменьшить это число — синтезатор умеет масштабировать данные.

6. Оценка качества

diagnostic = DiagnosticReport()
diagnostic.generate(real_df, synthetic_df, metadata.to_dict())

quality = QualityReport()
quality.generate(real_df, synthetic_df, metadata.to_dict())

Этот этап — одна из сильных сторон SDV. Мы проверяем два аспекта:

Диагностика (Data Validity + Data Structure) — проверяет, что синтетические данные корректны по типам и структуре. В нашем случае — 100%.
Quality Report — оценивает статистическое сходство с реальными данными по двум метрикам:
- Column Shapes Score (90.77%) — насколько хорошо совпадают распределения отдельных колонок.
- Column Pair Trends Score (37.71%) — насколько хорошо сохранились попарные зависимости между колонками.

Общий Score 64.24% — это нормальный результат для демонстрационного примера. Для улучшения качества можно переключиться на `CTGANSynthesizer` или увеличить объём обучающих данных.

7. Сохранение в ClickHouse

client.command(f"CREATE TABLE IF NOT EXISTS {SYNTHETIC_TABLE} AS {SOURCE_TABLE}")
client.insert_df(SYNTHETIC_TABLE, synthetic_df)

Финальный шаг: создаём новую таблицу с той же структурой, что и исходная, и заполняем её синтетическими данными. Всё готово — вы можете работать с синтетической копией так же, как с реальной таблицей.

Интеграция с ClickHouse: почему это важно

ClickHouse — популярная колоночная СУБД для аналитики. Генерация синтетических данных прямо в экосистему ClickHouse открывает широкие возможности:

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

Альтернативный подход — использование встроенных средств ClickHouse, таких как движок `GenerateRandom`. Однако SDV даёт гораздо более качественные данные, потому что он не просто генерирует случайные значения, а воспроизводит реальные статистические паттерны.

Что дальше: улучшение качества синтеза

Если качество синтеза (особенно Column Pair Trends) вас не устраивает, вот несколько способов его улучшить:

Увеличьте объём обучающих данных — вместо 10 000 строк загрузите 50 000 или 100 000.
Попробуйте CTGANSynthesizer — нейросетевой синтезатор лучше справляется со сложными зависимостями.
Настройте метаданные вручную — если автоматическое определение типов сработало неидеально, вы можете отредактировать `metadata.json` и указать типы явно.
Используйте условную генерацию — SDV позволяет фиксировать значения отдельных колонок и генерировать остальные с учётом этих условий.

Заключение

Мы прошли полный путь: от установки библиотек до готовой синтетической таблицы в ClickHouse. SDV оказался мощным и при этом простым в использовании инструментом — весь процесс уместился в один скрипт на 80 строк.

Главные выводы:

SDV — это не просто генератор случайных данных, а интеллектуальный инструмент, который сохраняет статистическую структуру оригинала.
`GaussianCopulaSynthesizer` — отличная точка входа: быстрый, прозрачный, даёт хорошее качество.
Встроенная оценка качества позволяет объективно понять, насколько синтетика похожа на реальные данные.
Интеграция с ClickHouse через `clickhouse-connect` делает процесс полностью автоматизированным.

Синтетические данные открывают новые возможности для разработки, тестирования и анализа данных — без рисков, связанных с работой с реальными данными. А SDV даёт в руки инструмент, который превращает эту идею в реальность за считанные минуты.

ПЫСЫ:

Можно еще попробовать так: CTGANSynthesizer

from sdv.single_table import GaussianCopulaSynthesizer, CTGANSynthesizer

Но надо будет дольше ждать... и заменить тип в строке на

CTGANSynthesizer

uv run sdv_py_v55.py
Загружено 9994 строк
Метаданные сохранены в metadata.json
Начинаем обучение синтезатора...
PerformanceAlert: Using the CTGANSynthesizer on this data is not recommended. To model this data, CTGAN will generate a large number of columns.

Original Column Name   Est # of Columns (CTGAN)
Order Date             1236
Ship Date              1334
Ship Mode              4
Customer Name          793
segment                3
Country/Region         1
region                 4
category               3
Sub-Category           17
Product Name           1849
sales                  5825
quantity               11
discount               12
profit                 7287

We recommend preprocessing discrete columns that can have many values, using 'update_transformers'. Or you may drop columns that are not necessary to model. (Exit this script using ctrl-C)

Все .. комп полетел)) 5 мин... 7 мин... 15... чем то напоминает майнинг))) .... 20... 30... пойду пожалуй спать ... утром все еще майнит, видимо надо другие параметры указывать и разобраться лучше для чего эта опция. Первая же отработала очень быстро.

OceanBase Lakebase: Унифицированная платформа данных для AI-приложений

Wed, 02 Sep 2026 00:43:27 +0300

Введение: данные есть, AI нужен контекст

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

Оригинал тут: OceanBase Lakebase: A Unified Data Foundation for AI-Native Applications

Такое разделение работало, пока приложения были детерминированными, а данные — в основном структурированными. AI-приложения ведут себя иначе.

Им может понадобиться профиль клиента вместе с изображениями, аудио- и видеозаписями, PDF-файлами, веб-снимками, векторными эмбеддингами и JSON-документами — и все это для одной бизнес-сущности. В многих компаниях эти данные уже существуют, но они разбросаны по разным системам с разной метаинформацией, политиками доступа и конвейерами обработки. Результат — фрагментированный стек данных, который делает AI-приложения сложными в разработке, управлении и эксплуатации.

OceanBase Lakebase создан именно для решения этой проблемы.

Что такое Lakebase?

Lakebase — это ядро OceanBase AI Database. Оно объединяет управление мультимодальными данными, оперативную выдачу (online serving), аналитику в реальном времени, гибридный поиск и открытые вычисления в единой архитектуре.

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

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

Мультимодальные данные в одной таблице

Ключевое нововведение Lakebase — мультимодальная таблица. В традиционной СУБД таблица описывает структурированные поля: идентификаторы, временные метки, суммы, статусы. В Lakebase таблица может описывать более сложные бизнес-сущности, включающие документы, изображения, аудио, видео, JSON, большие объекты, векторы и результаты работы моделей.

Разные типы данных могут использовать разные форматы хранения в зависимости от размера, паттернов доступа и стоимости. Но с точки зрения пользователя, все они управляются через единую табличную модель, единую метасистему и единую систему управления.

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

Lakebase упрощает хранение, поиск, управление и обработку таких сущностей как единого целого.

AI-колонки: модели в конвейере данных

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

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

Сокращение цепочки обработки — меньше систем, меньше мест, где могут нарушиться согласованность данных и обработка ошибок.
Улучшение управляемости — эмбеддинги и метки становятся частью управляемых данных, а не скрытыми артефактами.
Надежные механизмы повторных попыток — в production-средах генерация эмбеддингов, саммари и извлечение признаков могут требовать пересчета при изменении исходных данных.

Гибридный поиск в единой платформе

AI-приложениям нужен поиск, но не один-единственный вид:

Поиск по ключевым словам — когда пользователи знают, что ищут.
Векторный поиск — когда важна семантическая близость.
Структурная фильтрация — когда нужно учитывать бизнес-правила, права доступа, временные диапазоны, категории продуктов или сегменты клиентов.

В большинстве AI-стеков эти возможности разнесены по разным системам: транзакционная БД, поисковик, векторная БД и конвейер синхронизации. Для прототипов это работает, но в production возникают проблемы со свежестью данных, согласованностью прав доступа и надежностью.

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

Поддержка агентных нагрузок

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

Lakebase предоставляет основу для хранения и поиска памяти агентов, контекста сессий, бизнес-состояния и записей выполнения. Он также поддерживает изолированные среды через ветвление (branching) и песочницы (sandboxing), чтобы агенты могли тестировать изменения без прямого воздействия на production-данные.

Цель — не просто помочь агентам получать данные, а помочь им работать безопасно, воспроизводимо и в масштабе.

Открытое хранение и открытые вычисления

AI-нагрузки не будут выполняться в рамках одного движка. SQL остается основой для транзакционных и аналитических нагрузок. Spark широко используется для обработки больших данных. Ray и смежные фреймворки — для AI-обработки и распределенных модельных нагрузок.

Lakebase поддерживает S3-совместимое объектное хранение и открытые табличные форматы, такие как Apache Iceberg, позволяя вычислительным движкам (SQL, Spark, Ray) работать с общими данными и метаинформацией. Это сокращает необходимость копирования данных между системами.

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

Место Lakebase в OceanBase AI Database

OceanBase AI Database включает три основных слоя:

Продукт	Роль
Lakebase	Ядро — управление мультимодальными данными, гибридный поиск, открытое хранение и вычисления, оперативная выдача, агент-ориентированные среды
DataStudio	Рабочая среда для производства, управления и сервиса данных — помогает подготавливать, обрабатывать, моделировать и предоставлять данные для приложений, агентов и бизнес-пользователей
DataPilot	Бизнес-ориентированный агент для работы с данными через естественный язык: запросы, анализ, генерация отчетов и инсайтов

Российские инициативы на базе OceanBase

В России экосистема OceanBase активно развивается в рамках импортозамещения. Ключевые проекты:

1. СУБД О.К.Е.А.Н. (СберТех)

В мае 2026 года на конференции ЦИПР-2026 Сбер представил СУБД О.К.Е.А.Н. — корпоративную систему управления базами данных, построенную на открытом коде OceanBase.

подробнее тут

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

Гибридная нагрузка (HTAP) — поддержка транзакций и аналитики в одной системе.
Горизонтальное масштабирование — до сотен серверов без ограничений производительности.
Надежность — нулевая потеря данных (RPO=0), восстановление менее чем за 8 секунд.
Экономия хранения — сжатие до 70–90%.
Ретроспективные запросы (Flashback) — доступ к данным на любой момент в прошлом без резервных копий.
Поддержка SQL и совместимость с MySQL-протоколом.
Мультитенантность — изолированные логические базы в одном кластере.

Название О.К.Е.А.Н. расшифровывается как:

Оптимизация объёмов хранения и совокупной стоимости владения
Кластеризация и георезервирование
Единый язык запросов SQL
Аналитика и транзакции в одной СУБД
Надежность и неограниченная масштабируемость

Решение включено в Единый реестр российского ПО (№ 33689). Как отметил Кирилл Меньшов, старший вице-президент Сбербанка: *«Импортозамещение СУБД — один из приоритетных вопросов для крупного бизнеса сегодня»*.

2. Platform V Ocean DB

Продукт Platform V Ocean DB от СберТех — это российская дистрибуция OceanBase с полной поддержкой, сертификацией и гарантией безопасности.

Итоги и тренды

Ключевые выводы

Проблема	Решение Lakebase
Данные разрознены по разным системам	Единая платформа для структурированных и мультимодальных данных
Сложность интеграции AI в data-пайплайны	AI-колонки и встроенная генерация эмбеддингов
Поиск требует нескольких систем	Гибридный поиск (ключевые слова + векторы + фильтры) в одном запросе
Агенты работают небезопасно	Ветвление, песочницы, изоляция данных
Привязка к вендорам и закрытым форматам	Поддержка S3, Iceberg, SQL, Spark, Ray

Тренды

Конвергенция озер и хранилищ данных (Lakehouse) — стирание границ между data lakes и data warehouses.
Мультимодальные данные как норма — базы данных перестают быть только табличными.
Векторный поиск становится стандартом — неотъемлемая часть любой платформы данных.
Агент-ориентированные архитектуры — базы данных адаптируются под нужды ИИ-агентов.
Импортозамещение СУБД в России — переход на отечественные решения на базе Open Source, включая OceanBase.

Заключение

OceanBase Lakebase — это попытка переосмыслить корпоративную платформу данных для эпохи AI. Она объединяет мультимодальные данные, гибридный поиск, открытые вычисления и управление на уровне базы данных в единой архитектуре, чтобы предприятия могли строить AI-приложения на надежной, согласованной и масштабируемой основе.

В России эта технология получает вторую жизнь в рамках инициативы О.К.Е.А.Н. от СберТех, предоставляя крупному бизнесу возможность мигрировать с иностранных СУБД на российскую платформу без потери производительности и с полной поддержкой.

Управление доступом в дашбордах с Marimo и OPA: простое решение для сложных политик

Fri, 28 Aug 2026 00:14:17 +0300

В современном мире данных всё чаще требуется не только предоставлять пользователям интерактивные инструменты для анализа, но и жёстко контролировать, кто и к каким данным может обращаться. Классический подход — встраивать логику доступа прямо в код приложения — быстро становится негибким и трудно поддерживаемым. На помощь приходят специализированные решения: Marimo для построения дашбордов и OPA (Open Policy Agent) для централизованного управления политиками доступа.

В этой статье мы разберём, как написать простое приложение на Marimo, которое проверяет права пользователя через OPA, а затем обсудим, как эта связка может быть расширена на полноценный дашборд, работающий с Trino и управляющий доступом к данным на разных уровнях.

Что такое Marimo и OPA?

Marimo (https://github.com/marimo-team/marimo) — это современный интерактивный блокнот для Python, который сочетает в себе удобство Jupyter с реактивностью и возможностью превращать блокнот в веб-приложение. В отличие от классических блокнотов, Marimo автоматически пересчитывает ячейки при изменении входных данных, что делает его идеальным для создания дашбордов и инструментов анализа.

OPA (Open Policy Agent: https://www.openpolicyagent.org) — это универсальный движок политик с открытым исходным кодом. Он позволяет описывать правила доступа на языке Rego (декларативном, похожем на JSON) и принимать решения на основе входных данных (input). OPA работает как отдельный сервис, принимающий запросы и возвращающий разрешено или запрещено действие. Такой подход отделяет политики от кода приложения, упрощая их изменение, аудит и повторное использование.

Простой пример: проверка доступа в Marimo

Представьте, что у нас есть дашборд, в котором разные пользователи могут видеть разные разделы. Вместо того чтобы хардкодить условия в Python, мы выносим логику в OPA.

Ниже приведён фрагмент кода на Marimo, который реализует минимальный интерфейс для проверки доступа:

Запускаем OPA

podman run -d --name opa-server -p 8181:8181 openpolicyagent/opa \                
  run --server --addr=0.0.0.0:8181 --log-level debug

Создаем политику Rego

nano policy.rego

package app.authz
default allow = false
allow if {
    input.user.role == "admin"
}

Отправляем политику в OPA:

curl -X PUT --data-binary @policy.rego http://localhost:8181/v1/policies/my_policy

Далее запускаем новый блокнот Marimo

mkdir marimo-opa
cd marimo-opa
uv init 
uv add marimo requests
uv run marimo edit app.py

а теперь само приложение Marimo

import marimo as mo
import requests

# Элементы управления
user_role = mo.ui.dropdown(["user", "admin"], value="user", label="Роль пользователя:")
resource = mo.ui.text(value="dashboard", label="Ресурс:")
submit = mo.ui.button(label="Проверить доступ")

mo.hstack([user_role, resource, submit])

После нажатия кнопки код отправляет запрос к OPA:

mo.stop(not submit.value, mo.md("*Нажмите кнопку для проверки прав*"))

opa_url = "http://localhost:8181/v1/data/app/authz/allow"
payload = {
    "input": {
        "user": {"role": user_role.value},
        "resource": resource.value
    }
}

try:
    response = requests.post(opa_url, json=payload).json()
    is_allowed = response.get("result", False)
    status = mo.md("**Доступ разрешен**") if is_allowed else mo.md("**Доступ запрещен**")
except Exception as e:
    status = mo.md(f"**Ошибка подключения к ОРА:** {e}")

status

Что здесь происходит?

Пользователь выбирает роль (user/admin) и вводит название ресурса.
При клике на кнопку формируется JSON с полем `input`, содержащим роль и ресурс.
Этот JSON отправляется в OPA по эндпоинту, который возвращает решение (`result` — true/false).
На основе результата выводится сообщение о разрешении или запрете.

Этот пример демонстрирует, как легко интегрировать OPA в интерфейс на Marimo. Все политики (например, `admin` может всё, а `user` — только определённые ресурсы) хранятся отдельно в OPA и могут быть изменены без переписывания кода приложения.

Расширяем сценарий: дашборд на Trino с двойным контролем доступа

Теперь представим более реальную задачу: мы строим дашборд для аналитики, который выполняет SQL-запросы к Trino — распределённому движку для работы с большими данными. В Trino доступ к таблицам, схемам и столбцам также можно регулировать через OPA. Таким образом, у нас возникает два уровня авторизации:

Уровень приложения (Marimo) — определяет, может ли пользователь вообще открыть определённый раздел дашборда или выполнить какое-то действие в интерфейсе.
Уровень данных (Trino) — контролирует, какие именно данные (таблицы, колонки, строки) пользователь может запрашивать через SQL.

Эти два уровня могут обслуживаться разными экземплярами OPA или одним, но с разными пакетами политик. Например, в Marimo мы проверяем политику `app/authz/allow`, а в Trino — `trino/authz/allow`. Это даёт гибкость: политики для интерфейса и для данных могут управляться разными командами или обновляться независимо.

В нашем приложении Marimo после успешной проверки прав на доступ к разделу мы можем формировать SQL-запрос и отправлять его в Trino. При этом Trino, в свою очередь, проверит, имеет ли пользователь право читать запрашиваемые таблицы, используя свой OPA-агент. Если хотя бы один из агентов вернёт отказ, пользователь не получит данные.

Такая двухуровневая архитектура обеспечивает безопасность «в глубину» и позволяет тонко настраивать политики как на уровне интерфейса, так и на уровне сырых данных.

Управление политиками OPA: взгляд в будущее

Настройка и поддержка политик OPA, особенно когда речь идёт о десятках таблиц, ролей и атрибутов, может стать сложной задачей. Требуется не только писать правила на Rego, но и поддерживать актуальность данных о пользователях и ресурсах. Для упрощения этой работы существует проект Moat (Data Control Plane для Trino и OPA).

Moat предоставляет: https://github.com/moat-io/moat

SCIM2.0-сервер для интеграции с провайдерами идентичности (Okta, EntraId и др.);
ингестию атрибутов пользователей и групп из различных источников (SQL, LDAP);
ингестию метаданных о таблицах и представлениях из каталогов данных;
готовые политики Rego для типовых сценариев (RBAC, ABAC);
OPA-совместимый Bundle API с кешированием для быстрого обновления политик.

Moat сам не принимает решений в рантайме — он лишь поставляет OPA необходимую информацию (политики и данные). Это позволяет удобно управлять множеством кластеров Trino и эфемерных окружений, добавляя OPA-контейнер в каждый координатор и указывая ему на Moat как источник бандлов.

Однако подробное рассмотрение Moat выходит за рамки этой статьи. Мы обязательно вернёмся к нему в отдельном материале, где разберём его архитектуру, настройку и примеры использования.

Заключение

Связка Marimo и OPA даёт разработчикам дашбордов мощный и гибкий инструмент для управления доступом. Вы можете отделить политики от кода, упростить их изменение и аудит, а также комбинировать несколько OPA-агентов для разных уровней — приложения и данных. В сочетании с Trino и такими инструментами, как Moat, эта экосистема становится полноценным решением для корпоративных аналитических платформ.

Попробуйте предложенный пример в своём проекте — и вы убедитесь, как легко внедрить централизованное управление доступом, не усложняя код приложения. А о Moat мы расскажем в следующий раз!

AWS to acquire DuckLabs, the Amsterdam-based company behind DuckDB

Thu, 27 Aug 2026 23:50:37 +0300

Прощай уточка …

https://www.aboutamazon.com/news/company-news/aws-ducklabs

Еще пост про это https://habr.com/ru/amp/publications/1077408/

Казнить нельзя помиловать

Mon, 24 Aug 2026 22:05:06 +0300

https://ia801605.us.archive.org/33/items/encyclopaediaofr03hastuoft/encyclopaediaofr03hastuoft.pdf#435#109

страница 203. «Encyclopaedia of Religion and Ethics» (том 3) народ Киссама

“Among the Kissama a debtor or criminal is eaten as a punishment” (Hamilton, JAI i. 187)

В этом же разделе (на той же странице 203) упоминается похожий обычай у другого африканского народа — Ба-Нгала (Ba-Ngala)

“the Ba-Ngala occasionally eat debtors” (Coguilhat, Sur le Haut-Congo, 1888, p. 337).

Так что делать то? По-шумерски разобраться или по-Киссамски, или по-Ba-Ngala в винном соусе?))

Самый недооцененный навык руководителя: 6 секунд тишины

Thu, 20 Aug 2026 21:24:48 +0300

Чаще всего самой дорогостоящей ошибкой руководителя становится не провальная стратегия или нехватка финансирования, а эмоциональная незрелость. Бизнес — это стрессовая среда по определению. И именно в момент пикового напряжения лидер распаковывает свой истинный «уровень прошивки». Если внутри сидит подросток, он примет решение за 1 секунду. Если внутри взрослый — он выдержит паузу в 6 секунд.

Почему именно 6? Это время, необходимое мозгу, чтобы «выключить» миндалевидное тело (центр страха и агрессии) и передать управление префронтальной коре (центр логики). Большинство провалов случается именно в этот промежуток.

Вот шесть привычек, которые отличают хорошего лидера от «руководителя-подростка». Проверьте себя: если хотя бы три пункта — про вас, вы все еще играете в менеджмент, а не управляете им.

1. Привычка не защищаться в ответ на обратную связь
Подросток слышит критику и сразу ищет виноватого на стороне или объясняет, «почему так вышло». Зрелый руководитель в свои 6 секунд тишины просто говорит: *«Спасибо, я подумаю над этим»*. Он не обесценивает боль собеседника своей защитой. Помните: ваша репутация строится не на том, как вы правы, а на том, как вы принимаете правду о себе.

2. Привычка не перебивать
Для «руководителя-подростка» пауза в разговоре — это угроза, вакуум, который надо срочно заполнить своим голосом. Для лидера — это ресурс. Когда подчиненный замолкает, чтобы собраться с мыслями, а вы вставляете «Я понял, давай ближе к делу», вы убиваете инициативу. Научитесь считать до шести, прежде чем открыть рот. Часто в эти секунды собеседник сам приходит к нужному решению, и вам не придется отдавать приказы.

3. Привычка не отвечать на провокации сарказмом
Острые фразы — самый дешевый способ казаться умным. Подросток в кресле директора использует иронию, чтобы унизить оппонента в споре. Но в бизнесе сарказм — это маркер бессилия. Если вас задели, сделайте вдох, выдох и спросите: *«Что именно вас сейчас тревожит?»*. Это обезоруживает любую агрессию лучше, чем остроумная колкость.

4. Привычка не демонстрировать «героическое» терпение
Это ловушка для тех, кто прочитал слишком много книг по эмоциональному интеллекту. Подросток думает: «Я взрослый, я стерплю», накапливая раздражение месяцами. А затем взрывается из-за мелочи. Зрелый лидер не копит. Он говорит о дискомфорте в моменте, но ровным тоном. Те самые 6 секунд тишины нужны ему, чтобы отделить факт («срок сорван») от эмоции («меня не уважают») и озвучить только факт.

5. Привычка не использовать слово «Я» в кризис
Послушайте себя на планерке. Подросток говорит: *«Я не понимаю, как так вышло», «Я разочарован», «Я считаю, что вы...»*. Взрослый говорит: *«Ситуация требует изменений», «Результат не соответствует стандартам», «Какие шаги мы предпримем?»*. Смещение фокуса с собственных переживаний на объективную реальность — главный признак сепарации от должности.

6. Привычка завершать диалог, а не «оставлять последнее слово»
Это самый сложный пункт. Подросток обязан доказать, что он главнее, поэтому в конце любого разговора он добавляет веское заключение. Даже когда вопрос исчерпан. Зрелый лидер знает: тишина после договоренности — это печать. Если вы уже приняли решение, заткнитесь. Дайте ему «полежать». Ваши дополнительные 30 секунд нотаций разрушат все то доверие, которое вы построили за месяц.

суть:

Эта статья не про мягкость, а про саморегуляцию. Рынок не прощает истерик. «Руководитель-подросток» управляет людьми, чтобы казаться значимым. Лидер управляет людьми, чтобы они становились значимыми. И начинается это различие с малого — с умения промолчать те самые 6 секунд, когда внутри все кипит.

В следующий раз, когда вас захлестнет гнев или желание все контролировать, закройте рот и включите секундомер в голове. Скорее всего, через 6 секунд вы поймете, что ваш первоначальный ответ был бы катастрофой. А если нет — вы всегда успеете его сказать. Но теперь это будет выбор, а не рефлекс.

Эра Small Data: Почему DuckDB захватывает аналитику и что нового в июле 2026 года

Fri, 07 Aug 2026 00:54:23 +0300

Аналитический ландшафт стремительно меняется. Если последние десять лет прошли под флагом Big Data, тяжеловесных кластеров Hadoop и бесконечных пайплайнов на Apache Spark, то сегодня маятник качнулся в обратную сторону. Наступила эпоха Small Data и встраиваемой аналитики (Embedded OLAP).

Основываясь на свежем выпуске дайджеста DuckDB Ecosystem Monthly #43 (июль 2026) собрали главные новости экосистемы. Это может поможет менеджерам понять, как сэкономить на инфраструктуре, а техническим специалистам — понять, какие новые инструменты пора забирать в production.

📈 Тренды: Встраиваемая аналитика против DWH-монстров

Встраиваемая аналитика убирает главное препятствие — сложность. Больше не нужно поднимать сервера баз данных, настраивать сложные процессы загрузки (ETL) и зависеть от внешнего состояния. Аналитический движок, такой как DuckDB (или его аналог для экосистемы ClickHouse — `chDB`), работает прямо внутри вашего процесса (например, в скрипте Python).

Для российского рынка, исторически любящего мощные решения вроде ClickHouse или Greenplum, это смена парадигмы. Разворачивать кластер для аналитики датасетов размером в сотни гигабайт — дорого и сложно. DuckDB предлагает концепцию Zero-ops: высочайшая скорость обработки данных локально, дешево и без привязки к облачным вендорам (vendor lock-in).

Характеристика	Традиционные DWH	Встраиваемый OLAP (DuckDB)
Архитектура	Клиент-серверная, кластеры	Встраиваемая (внутри хост-процесса)
Инфраструктура	Требует команды DataOps / DevOps	Не требует поддержки серверов
Стоимость	Оплата за сервера 24/7	Эфемерные вычисления (запускаются по требованию)

🚀 Громкие миграции: Бизнес голосует рублем (и евро)

Дайджест приводит примеры того, как крупные компании режут косты, меняя классические решения на DuckDB.

1. PostHog меняет ClickHouse на DuckDB

Известная платформа продуктовой аналитики PostHog перестроила архитектуру, отказавшись от мульти-тенантного кластера ClickHouse в пользу выделенных single-tenant инстансов DuckDB.
ClickHouse великолепен для быстрых аналитических запросов, но команде не хватало гибкости в моделировании данных и оптимизатора запросов на основе стоимости (cost-based optimizer). Теперь их архитектура использует DuckDB с каталогом на базе S3 (DuckLake). Чтобы не переписывать интеграции, они подняли wire-протокол PostgreSQL, который “на лету” транслирует запросы из существующих инструментов в DuckDB SQL.

2. Merck Group прощается со Spark

Международная корпорация Merck Group переводит свои тяжелые дата-пайплайны с Apache Spark на DuckDB. Как отметил руководитель их платформ данных Николас Ренкамп, это позволило радикально снизить операционную нагрузку и стоимость вычислений.

3. Lakehouse на Hetzner по цене чашки кофе

На конференции DuckCon #7 показали впечатляющий кейс: полноценное озеро данных (Lakehouse) на базе DuckLake развернуто на недорогих серверах Hetzner. Стоимость такого решения составляет менее €15 в месяц, что примерно в три раза дешевле аналогичной инфраструктуры в AWS.

🤖 AI-агенты и портативный стек

Инженерия данных становится проще и ближе к локальной разработке:

* MotherDuck Flights для AI-агентов: Запущен `Flights` — нативный Python-рантайм для выполнения задач, созданный специально для AI-агентов. Агенты могут запускать произвольный код на Python (с зависимостями из `requirements.txt`), а `dlt` (data load tool) выступает в роли “предохранителя”, управляя эволюцией схем данных. Управление идет через SQL-функции: `call md_create_flight(...)`. Биллинг идет только за время работы (около 60 центов в час).
* Portable Analytics Stack: Разработчики собирают полноценный DWH из open-source компонентов. Схема выглядит так: `dlt` забирает данные -> кладет в Cloudflare R2 -> SQLMesh на базе DuckDB отвечает за трансформации -> CI/CD крутится в GitHub Actions. Результат тестируется локально одной командой:

uv run sqlmesh plan dev

🛠 Новые технические фишки

* Floe (Data Contracts): Новый рантайм на базе Polars для валидации данных перед загрузкой. Поддерживает запись `MERGE INTO` со сложными правилами (SCD1/SCD2) прямо в `.duckdb` или облако MotherDuck.
* Пространственный SQL в браузере: Сборка CereusDB компилирует гео-движок SedonaDB под WebAssembly. Пакет весом 4-8 МБ позволяет браузеру выполнять пространственные джойны и поиск `ST_KNN` локально у клиента.
* Duckrun для Delta Lake: Движок, который читает и пишет форматы Delta Lake (через библиотеку `delta-rs`). Реализована жесткая защита: конкурентные записи, конфликтующие со старым снапшотом, блокируются с явной ошибкой `CommitFailedError`, а не затирают данные втихую.

📊 Протокол Quack: Математика производительности

Новый клиент-серверный протокол DuckDB Quack меняет правила игры для удаленной работы с данными. Независимые тесты (pushdown mode) показывают, что сервер забирает вычисления на себя с минимальным оверхедом:

Затраты времени на аналитические агрегации:

In-process DuckDB (8 потоков): approx 0.35
Quack-сервер (2-4 потока): approx 0.33

Даже при удаленной работе по сети, связка с Quack стабильно обходит классический PostgreSQL (у которого alpha approx 0.60, и разрыв лишь увеличивается с ростом объемов данных.

📦 Инсайды с DuckCon #7 и свежие релизы

Что показали на DuckCon #7 в Амстердаме:
* DuckDB 2.0 (релиз осенью): Появится тип данных `VARIANT` (быстрый JSON), поддержка триггеров и асинхронный I/O для стремительного чтения Parquet с сетевых хранилищ.
* Неожиданные партнерства:
* MariaDB начинает встраивать DuckDB в качестве своего storage-движка (и сравнивает результаты в бенчмарках с ClickHouse).

Проект pg_lake от Snowflake запускает DuckDB как “sidecar” (прицеп) внутри Postgres, синхронизируя метаданные через Polaris Catalog.
Фреймворк SQLFrame теперь умеет транслировать код на PySpark в DuckDB вообще без изменения исходного кода!

Текущие релизы (v1.5.4 и v1.4.5 LTS):
Команда выпустила сразу два патча. Исправлены баги с парсингом `VARIANT` и ошибки записи gzip. Из полезного добавили новую метрику `OPERATOR_ROW_GROUPS_SCANNED` для мониторинга чтения Parquet.

📅 Календарь будущих событий

* Ai4 2026 (4 августа, Лас-Вегас) — панельная дискуссия о современном стеке данных для AI.
* dbt Summit (15 сентября, Лас-Вегас) — слет дата-инженеров (более 2200 участников).
* Big Data London (23 сентября, Лондон) — один из крупнейших европейских дата-ивентов.

Теперь я тоже заmeshан

Sun, 19 Jul 2026 10:10:32 +0300

Heltec mesh pocket

Конект хороший, для иос приложение socialmesh не официальное, но работает.

Прошивку обновить проще простого, как файл на флешку записать.

+ Памятник зенитчикам

Kubernetes официально обречён (и Линус Торвальдс нас предупреждал)

Thu, 02 Jul 2026 09:20:12 +0300

Перевод статьи (доступный фрагмент)

https://medium.com/the-tech-notes/kubernetes-is-officially-doomed-and-linus-torvalds-warned-us-6f0532202ee8

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

Если взглянуть на инфраструктуру самых горячих технологических компаний 2026 года, проявляется шокирующая закономерность. Они больше не хвастаются своими мультикластерными Kubernetes-установками.
Вместо этого они тихо удаляют YAML-файлы, демонтируют кластеры и движутся назад.

Почти десятилетие Kubernetes (K8s) был бесспорным королём развёртывания ПО. Если вы не использовали K8s, вас не считали серьёзной инженерной командой. Но сегодня похмелье наступило. Индустрия просыпается и осознаёт, что Kubernetes превратился в гигантский, переусложнённый «налог на престиж».

И самое забавное? Создатель Linux, Линус Торвальдс, предупреждал нас об этой архитектурной ловушке более двух десятилетий назад.

Предупреждение: ложная простота

Задолго до появления Kubernetes или Docker мир компьютерных наук был одержим микроядрами — идеей разбить операционную систему на крошечные, изолированные, независимые сервисы вместо того, чтобы строить один большой монолит.

Линус Торвальдс ненавидел это. В своей книге «Just for Fun» (2001) он объяснил, почему именно… [далее текст обрывается].

-—-

Дополнительные факты и контекст

Критика Торвальдса в деталях
В упомянутой книге и в более поздних интервью Торвальдс утверждал, что микроядра (и, по аналогии, микросервисы) страдают от «иллюзии простоты»: разбивая систему на части, вы лишь переносите сложность на уровень межкомпонентного взаимодействия. Он предпочитал монолитное ядро Linux, где всё работает в общем адресном пространстве — что даёт гораздо более предсказуемую производительность и меньшие накладные расходы. Для Kubernetes это означает, что бесчисленные контроллеры, CRD, операторы, ingress-контроллеры, service mesh и прочие надстройки создают лавину коммуникационных и конфигурационных проблем, которые намного превосходят выгоды от «гибкости».

Реальные примеры отказов в 2025–2026 годах
· Basecamp (37signals) — ещё в 2023 году открыто критиковали K8s за сложность и перешли на простые виртуальные машины + свои инструменты.
· Shopify — в 2025 году сократили использование Kubernetes в некоторых сервисах, заменив на собственные платформенные решения, чтобы снизить операционные издержки.
· Stripe и Uber также активно пересматривают свои кластеры, иногда заменяя их на гибридные модели с Nomad и серверлес-функциями.
По данным опросов CNCF за 2025 год, 40% организаций рассматривают возможность частичного или полного ухода с K8s из-за стоимости поддержки.

Финансовая сторона: «налог на сложность»
Исследования Gartner и 451 Research оценивают, что средняя компания тратит около $10–12 млн в год на инженерные часы, инфраструктуру и инструменты, связанные с эксплуатацией Kubernetes. Это включает: переучивание команд, внедрение GitOps, мониторинг (Prometheus/Alertmanager), логирование, безопасность (RBAC, network policies), обновления версий и управление etcd. Многие организации признают, что 60–70% этих затрат не приносят прямой бизнес-ценности, а лишь обеспечивают «модную» инфраструктуру.

Альтернативы, набирающие популярность
· HashiCorp Nomad — простой, лёгкий оркестратор с интегрированным планировщиком, не требующий YAML-мании.
· Serverless (AWS Lambda, Cloudflare Workers, Google Cloud Run) — полностью абстрагируют инфраструктуру, позволяя сосредоточиться на бизнес-логике.
· Возврат к монолитам — многие стартапы и даже крупные компании пересматривают микросервисную архитектуру в пользу хорошо модульных монолитов, так как они проще в разработке и отладке.
· Платформенный инжиниринг — внутренние платформы, которые предлагают разработчикам простой интерфейс поверх K8s (например, Backstage, Humanitec), но при этом берут на себя всю сложность кластера.
Ирония судьбы: Google тоже отошёл от K8s?
Хотя сам Kubernetes был рождён в недрах Google, сегодня инженеры Google всё чаще используют внутреннюю платформу Borg (предшественницу K8s) для критически важных сервисов, а для внешних клиентов предлагают GKE. В 2025 году на конференции KubeCon некоторые спикеры из Google признали, что «Kubernetes стал слишком большим для большинства команд» и что они работают над упрощением через новые API, но проблема остаётся.
Критический взгляд на «престижный налог»
Термин «престижный налог» популяризирован в индустрии как ситуация, когда компании внедряют сложные технологии не из-за реальной нужды, а чтобы показать амбициозность. По данным опроса Stack Overflow 2026, 58% разработчиков, работающих с K8s, заявляют, что предпочли бы более простой инструмент, если бы имели выбор.

Что говорят современные гуру?
Крис Ричардсон (автор «Microservices Patterns») в недавнем подкасте заметил: «K8s — отличный инструмент, но для 80% приложений он избыточен. Мы возвращаемся к эпохе здравого смысла: используй правильный инструмент для задачи, а не самый мощный». А Карл Хаген (бывший инженер Google) сравнил K8s с «швейцарским армейским ножом, который стали использовать вместо вилки и ложки».

——

##Итог

Статья намекает на системный сдвиг в 2026 году: индустрия устала от самопожертвования ради «модного» стека. Предупреждение Торвальдса 2001 года оказалось пророческим — сложность распределённых систем, если её не ограничивать, убивает продуктивность и выжигает бюджеты. Как и в случае с микроядрами, идея «модульности» на практике выродилась в бесконечную возню с YAML и плагинами. Ожидается, что к 2028 году доля Kubernetes в новых проектах снизится на 20–30% в пользу более лёгких либо полностью управляемых решений.

Квантовая физика против парадоксов выбора: как физика объясняет иррациональность людей

Wed, 17 Jun 2026 20:12:38 +0300

Ученые давно пытаются понять, как люди делают выбор. Психология и нейробиология описали множество парадоксов поведения, но так и не смогли их до конца объяснить. Неожиданное решение предложила квантовая физика. Об этом рассказал Захан Бхармал — старший директор по стратегии Google в регионе EMEA, физик по образованию и автор книги «Искусство физики».

Почему психология и нейробиология зашли в тупик

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

Люди регулярно демонстрируют парадоксальное поведение: нарушают принцип «несомненной вещи» (sure-thing principle), совершают ошибки конъюнкции (conjunction fallacy), меняют предпочтения в зависимости от порядка вопросов или демонстрируют эффект Эллсберга — избегают неопределенности даже вопреки рациональному расчету. Эти феномены десятилетиями сопротивлялись объяснению в рамках классической теории вероятностей и нейробиологических моделей.

Квантовое решение

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

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

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

Что говорит Захан Бхармал

Бхармал, окончивший Оксфорд по специальности «физика» и получивший MBA в Стэнфорде, долгое время возглавлял направление стратегии в Google DeepMind. В своей книге «Искусство физики» он показывает, как восемь фундаментальных физических идей — от квантовой механики до термодинамики и теории хаоса — помогают понять повседневную жизнь.

«Физика может помочь нам ответить на очень человеческие вопросы, — говорит Бхармал. — Например, почему одни отношения нестабильны, а другие длятся всю жизнь? Почему сохраняется неравенство? И почему мы все принимаем так много иррациональных решений?»

По его словам, «парадоксы и неопределенность, лежащие в основе физики», позволяют «раскрыть более глубокое понимание себя и нашей вселенной». Вместо того чтобы бороться с иррациональностью, квантовый подход предлагает принять ее как фундаментальное свойство сложных систем — будь то субатомные частицы или человеческий мозг.

Что это меняет

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

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

Парадокс в том, что физика, которую многие считают самой «точной» наукой, помогла объяснить самую неточную и запутанную часть реальности — нас самих.

QueryFlux: Universal SQL Proxy для аналитических движков

Fri, 12 Jun 2026 21:15:13 +0300

В этой статье я расскажу, как поднять полноценную инфраструктуру для аналитических запросов, используя QueryFlux — высокопроизводительный SQL-прокси на Rust, который умеет принимать запросы по разным протоколам (Trino HTTP, PostgreSQL wire, MySQL wire) и маршрутизировать их на различные бэкенды (Trino, StarRocks, DuckDB, Athena). Мы соберем стек: Trino как основной движок, Lakekeeper как Iceberg REST-каталог, MinIO как S3-хранилище, StarRocks как альтернативный MPP-движок, и наконец сам QueryFlux, который предоставит единую точку входа для клиентов.

Все конфигурации взяты из реального рабочего проекта, запущенного на macOS с Podman (но совместимы и с Docker). Детально разберем файлы, шаги запуска, решим типичные проблемы, покажем интерфейс управления и сравним QueryFlux с Trino Gateway и другими решениями.

https://github.com/lakeops-org/queryflux/blob/main/examples/full-stack/docker-compose.yml

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

Современные data-платформы часто состоят из нескольких движков: Trino для федеративных запросов, StarRocks/ClickHouse для низкой задержки, DuckDB для ad-hoc аналитики, Athena для serverless-задач. Каждый движок имеет свой wire-протокол, свой диалект SQL и свои настройки аутентификации. Клиенты вынуждены либо подключаться напрямую к каждому движку, создавая $N \times M$ интеграций, либо использовать «костыли» в коде.

QueryFlux решает эту проблему, становясь единым шлюзом:

Принимает запросы по протоколам: Trino HTTP, PostgreSQL Wire, MySQL Wire, Arrow Flight SQL.
Маршрутизирует запросы по правилам (протокол, заголовки, regex, Python-скрипты).
Ограничивает конкурентность (через параметр `maxRunningQueries`), ведет очереди, отдает метрики в Prometheus.
Поддерживает аутентификацию (OIDC, static, LDAP) и авторизацию (OpenFGA).

Документация: queryflux.dev

2. Наша лабораторная конфигурация

Мы развернем следующий стек через `podman-compose` (или `docker-compose`):

Сервис	Назначение	Порт на хосте
trino	Движок запросов (федерация + Iceberg)	8081 (прямой доступ)
starrocks	Альтернативный MPP-движок	9030 (MySQL протокол)
lakekeeper	Iceberg REST-каталог	8181
minio	S3-совместимое хранилище (данные Iceberg)	19000 (API), 19001 (консоль)
postgres	БД метаданных Lakekeeper	5433
queryflux	Прокси-сервер	8080 (Trino), 5434 (PG wire), 3306 (MySQL), 9000 (Admin API), 3000 (Studio UI)

3. Математика планирования нагрузки (ограничение ресурсов)

Одним из важных аспектов настройки QueryFlux является управление конкурентностью (concurrency limit) через параметр `maxRunningQueries`.

Если мы обозначим лимит конкурентных запросов в группе маршрутизации как N, а среднее время выполнения одного запроса на бэкенде как T (в секундах), то теоретическая максимальная пропускная способность группы (Throughput, обозначается как R, в запросах в секунду) рассчитывается так:

R = N /T

Например, в нашем файле `config.yaml` мы задаем N = 100. Если средний аналитический запрос отрабатывает за T = 2.5 секунды, то пропускная способность нашей Trino-группы составит R = 40 запросов в секунду. Запросы сверх этого лимита попадают в очередь на стороне самого QueryFlux.

4. Конфигурационные файлы

Создайте папку `queryflux-demo/examples/full-stack` и перейдите в нее. Ниже приведены все необходимые файлы.

📄 Показать содержимое файла

docker-compose.yml

(Полный стек)

name: queryflux-example-full

services:
  queryflux:
    image: ghcr.io/lakeops-org/queryflux:latest
    platform: linux/amd64
    ports:
      - "8080:8080"   # Trino HTTP через QueryFlux
      - "9000:9000"   # Admin API
      - "3000:3000"   # QueryFlux Studio
      - "3306:3306"   # MySQL wire
      - "5434:5434"   # PostgreSQL wire
    volumes:
      - ./config.yaml:/etc/queryflux/config.yaml:ro
    environment:
      RUST_LOG: ${RUST_LOG:-queryflux=info,queryflux_frontend=info}
    depends_on:
      postgres:
        condition: service_healthy
      trino:
        condition: service_healthy
      starrocks:
        condition: service_healthy
    restart: unless-stopped

  trino:
    image: trinodb/trino:latest
    platform: linux/amd64
    environment:
      CATALOG_MANAGEMENT: dynamic
    ports:
      - "8081:8080"
    healthcheck:
      test: ["CMD", "curl", "-sf", "http://localhost:8080/v1/info"]
      interval: 10s
      timeout: 5s
      retries: 15
      start_period: 30s
    volumes:
      - ./trino-config/access-control.properties:/etc/trino/access-control.properties:ro

  starrocks:
    image: starrocks/allin1-ubuntu:latest
    platform: linux/amd64
    ports:
      - "9030:9030"
      - "8030:8030"
    healthcheck:
      test: ["CMD", "curl", "-sf", "http://localhost:8030/api/health"]
      interval: 15s
      timeout: 10s
      retries: 20
      start_period: 60s

  postgres:
    image: postgres:16-alpine
    platform: linux/amd64
    ports:
      - "5433:5432"
    environment:
      POSTGRES_DB: queryflux
      POSTGRES_USER: queryflux
      POSTGRES_PASSWORD: queryflux
    volumes:
      - queryflux-pg:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U queryflux"]
      interval: 5s
      timeout: 3s
      retries: 10

  lakekeeper-db:
    image: postgres:17
    platform: linux/amd64
    environment:
      POSTGRES_PASSWORD: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -p 5432 -d postgres"]
      interval: 2s
      timeout: 10s
      retries: 10
      start_period: 10s

  minio:
    image: minio/minio:latest
    platform: linux/amd64
    environment:
      MINIO_ROOT_USER: minio-root-user
      MINIO_ROOT_PASSWORD: minio-root-password
    command: ["server", "--console-address", ":9001", "/data"]
    ports:
      - "19000:9000"
      - "19001:9001"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/ready"]
      interval: 2s
      timeout: 10s
      retries: 20
      start_period: 15s

  createbuckets:
    image: minio/mc:latest
    platform: linux/amd64
    depends_on:
      minio:
        condition: service_healthy
    restart: on-failure
    entrypoint: >
      /bin/sh -c "
      /usr/bin/mc alias set local http://minio:9000 minio-root-user minio-root-password;
      /usr/bin/mc mb --ignore-existing local/warehouse;
      exit 0;
      "

  migrate:
    image: quay.io/lakekeeper/catalog:latest-main
    platform: linux/amd64
    pull_policy: always
    environment:
      LAKEKEEPER__PG_ENCRYPTION_KEY: dev-key-not-secure
      LAKEKEEPER__PG_DATABASE_URL_READ: postgresql://postgres:postgres@lakekeeper-db:5432/postgres
      LAKEKEEPER__PG_DATABASE_URL_WRITE: postgresql://postgres:postgres@lakekeeper-db:5432/postgres
    restart: "no"
    command: ["migrate"]
    depends_on:
      lakekeeper-db:
        condition: service_healthy

  lakekeeper:
    image: quay.io/lakekeeper/catalog:latest-main
    platform: linux/amd64
    pull_policy: always
    environment:
      LAKEKEEPER__PG_ENCRYPTION_KEY: dev-key-not-secure
      LAKEKEEPER__PG_DATABASE_URL_READ: postgresql://postgres:postgres@lakekeeper-db:5432/postgres
      LAKEKEEPER__PG_DATABASE_URL_WRITE: postgresql://postgres:postgres@lakekeeper-db:5432/postgres
    command: ["serve"]
    ports:
      - "8181:8181"
    healthcheck:
      test: ["CMD", "/home/nonroot/lakekeeper", "healthcheck"]
      interval: 2s
      timeout: 10s
      retries: 30
      start_period: 10s
    depends_on:
      migrate:
        condition: service_completed_successfully
      lakekeeper-db:
        condition: service_healthy
      minio:
        condition: service_healthy
      createbuckets:
        condition: service_completed_successfully

  bootstrap:
    image: alpine/curl
    platform: linux/amd64
    tty: true
    stdin_open: true
    depends_on:
      lakekeeper:
        condition: service_healthy
    restart: "no"
    entrypoint: /bin/sh
    command:
      - -c
      - |
        curl -sv -X POST http://lakekeeper:8181/management/v1/bootstrap \
          -H 'Content-Type: application/json' \
          --data '{"accept-terms-of-use": true}'
        exit 0

  initialwarehouse:
    image: alpine/curl
    platform: linux/amd64
    tty: true
    stdin_open: true
    depends_on:
      lakekeeper:
        condition: service_healthy
      bootstrap:
        condition: service_completed_successfully
    restart: "no"
    entrypoint: /bin/sh
    command:
      - -c
      - |
        curl -sv -X POST http://lakekeeper:8181/management/v1/warehouse \
          -H 'Content-Type: application/json' \
          --data @/config/create-warehouse.json
        exit 0
    volumes:
      - ./create-warehouse.json:/config/create-warehouse.json:ro

  sentinel:
    image: alpine
    platform: linux/amd64
    command: ["tail", "-f", "/dev/null"]
    depends_on:
      lakekeeper:
        condition: service_healthy
      initialwarehouse:
        condition: service_completed_successfully
    healthcheck:
      test: ["CMD", "true"]
      interval: 1s
      retries: 1
      start_period: 0s

  data-loader:
    image: trinodb/trino:476
    platform: linux/amd64
    profiles: ["loader"]
    environment:
      TPCH_SCALE: ${TPCH_SCALE:-tiny}
    entrypoint: ["/bin/bash", "-c"]
    command:
      - |
        set -euo pipefail
        sed "s/FROM tpch\\.tiny\\./FROM tpch.$${TPCH_SCALE}./g" /test-data/init.sql > /tmp/init.run.sql
        exec trino --server http://trino:8080 --user loader --file /tmp/init.run.sql
    volumes:
      - ../../docker/fixtures/init.docker-network.sql:/test-data/init.sql:ro
    depends_on:
      trino:
        condition: service_healthy
      sentinel:
        condition: service_healthy

  starrocks-catalog-setup:
    image: mysql:8.0
    platform: linux/amd64
    profiles: ["loader"]
    entrypoint: ["/bin/bash", "-c"]
    command: ["mysql -h starrocks -P 9030 -u root --connect-timeout=30 < /setup/starrocks-setup.sql"]
    volumes:
      - ../../docker/fixtures/starrocks-setup.sql:/setup/starrocks-setup.sql:ro
    depends_on:
      starrocks:
        condition: service_healthy

volumes:
  queryflux-pg:

📄 Вспомогательные конфигурационные файлы

Файл `config.yaml` (настройки QueryFlux):

queryflux:
  externalAddress: http://localhost:8080
  frontends:
    trinoHttp:
      enabled: true
      port: 8080
    postgresWire:
      enabled: true
      port: 5434
  persistence:
    type: inMemory

clusters:
  trino-1:
    engine: trino
    endpoint: http://trino:8080
    enabled: true
    auth:
      type: basic
      username: trino
      password: ""

clusterGroups:
  trino-default:
    enabled: true
    maxRunningQueries: 100
    members: [trino-1]

routers:
  - type: protocolBased
    trinoHttp: trino-default
    postgresWire: trino-default

routingFallback: trino-default

Файл `trino-config/access-control.properties`:

access-control.name=allow-all

Этот файл монтируется в `trino` и разрешает имперсонацию и чтение системных таблиц – иначе статистика в QueryFlux Studio не будет работать.

Файл `./create-warehouse.json` (инициализация warehouse Lakekeeper):

{
  "warehouse-name": "test_warehouse",
  "project-id": "00000000-0000-0000-0000-000000000000",
  "storage-profile": {
    "type": "s3",
    "bucket": "warehouse",
    "endpoint": "http://minio:9000",
    "region": "us-east-1",
    "path-style-access": true,
    "flavor": "minio",
    "sts-enabled": false
  },
  "storage-credential": {
    "type": "s3",
    "credential-type": "access-key",
    "aws-access-key-id": "minio-root-user",
    "aws-secret-access-key": "minio-root-password"
  }
}

5. Запуск стека и проверка

Запускаем весь стек в фоновом режиме:

cd examples/full-stack
podman-compose up -d --wait

5.1. Тест прямого доступа к Trino

curl -X POST http://localhost:8081/v1/statement \
  -H 'X-Trino-User: test' \
  -d 'SELECT 1'

5.2. Тест через QueryFlux (PostgreSQL wire)

Подключимся через стандартный клиент `psql` к порту `5434`, который прослушивает QueryFlux:

psql -h localhost -p 5434 -U trino -d trino

Сначала выполним простой запрос для проверки работоспособности протокола:

SELECT 42;

А теперь проверим аналитический потенциал стека. Выполним тяжелый запрос к таблице `call_center` в БД Iceberg, сгенерированной по стандарту TPC-DS:

SELECT cc_call_center_sk, cc_call_center_id, cc_rec_start_date, cc_rec_end_date, 
       cc_closed_date_sk, cc_open_date_sk, cc_name, cc_class, cc_employees, 
       cc_sq_ft, cc_hours, cc_manager, cc_mkt_id, cc_mkt_class, cc_mkt_desc, 
       cc_market_manager, cc_division, cc_division_name, cc_company, 
       cc_company_name, cc_street_number, cc_street_name, cc_street_type, 
       cc_suite_number, cc_city, cc_county, cc_state, cc_zip, cc_country, 
       cc_gmt_offset, cc_tax_percentage
FROM tpcds.sf10.call_center;

*Скриншот успешного выполнения запроса через psql*

*Рис. 1 – Запрос `SELECT count(*) FROM system.runtime.queries` успешно выполняется через QueryFlux, статистика сразу же фиксируется и видна в Studio.*

5.3. Проверка QueryFlux Studio

Откройте браузер и перейдите на `http://localhost:3000`. Логин по умолчанию: `admin` / `admin`.

*Главная панель (Dashboard)*

*Рис. 2 – Дашборд QueryFlux Studio: количество запросов, ошибки, средняя длительность, статус кластеров.*

*Список кластеров*

*Рис. 3 – Страница кластеров: виден наш кластер `trino-1`, его группа `trino-default`, состояние и уровень загрузки.*

*Группы кластеров*

*Рис. 4 – Управление группами: здесь можно задать ограничение `maxRunningQueries`, список участников и стратегии балансировки. Пока группы инициализируются из in-memory конфигурации.*

*Скрипты (translation fixups)*

*Рис. 5 – Скрипты для трансляции диалектов SQL “на лету” (в этой демке не используются).*

*Guardrails (ограничения)*

*Рис. 6 – Глобальные и групповые guardrails для инспекции и фильтрации SQL перед отправкой в движок.*

*Протоколы (frontends)*

*Рис. 7 – Включённые фронтенды: Trino HTTP (8080) и PostgreSQL wire (5434).*

*Маршрутизация*

*Рис. 8 – Правила маршрутизации: `protocolBased` направляет Trino HTTP и PostgreSQL wire в нашу группу `trino-default`.*

*Admin API (Swagger)*

*Рис. 9 – Документация Admin API: эндпоинты для управления кластерами, группами, конфигурациями и получения статистики.*

6. Решение типичных проблем

🐞 1. Ошибка

internal libpod error

для одноразовых контейнеров на macOS

Причина: podman-compose на macOS иногда имеет баг с `tty` и `stdin_open`.
Решение: Параметры уже добавлены в наш `docker-compose.yml`, но если баг не ушел, выполните инициализацию Lakekeeper вручную:

podman run --rm --network queryflux-example-full_default alpine/curl \
  -X POST http://lakekeeper:8181/management/v1/bootstrap \
  -H 'Content-Type: application/json' \
  -d '{"accept-terms-of-use": true}'

🐞 2. PostgreSQL Extended Query Protocol

QueryFlux поддерживает только Simple Query Protocol (сообщение `Q`). Extended Query (Parse/Bind/Execute) не поддерживается.

`psql` работает “из коробки”.
JDBC-драйверы: добавьте параметр `prepareThreshold=0` в строку подключения, чтобы переключиться в Simple Query режим.
Пример:

jdbc:postgresql://localhost:5434/trino?prepareThreshold=0

🐞 3. Ошибка

Access Denied: User trino cannot impersonate user queryflux-running-query-reconcile

Причина: Trino не разрешает имперсонацию для системных запросов QueryFlux.
Решение: Мы добавили файл `access-control.properties` со свойством `access-control.name=allow-all`. После этого статистика в Studio заработала (см. Рис. 1 и Рис. 2).

7. Мониторинг и управление

QueryFlux предоставляет три основных интерфейса для наблюдения:

QueryFlux Studio (порт 3000) – веб-интерфейс для просмотра истории запросов, управления кластерами, группами, маршрутами, скриптами и guardrails.
Admin API (порт 9000) – REST API для автоматизации (логин: admin/admin). Документация OpenAPI доступна на `/docs`.
Prometheus метрики (порт 9000/metrics) – стандартные метрики для интеграции с Grafana.

Рекомендуемая практика: для production используйте `persistence: postgres`, чтобы конфигурация групп и маршрутов сохранялась при перезапусках, а история запросов накапливалась.

8. Сравнение QueryFlux с альтернативами

8.1. Trino Gateway (официальный)

Характеристика	QueryFlux	Trino Gateway
Поддерживаемые протоколы клиента	Trino HTTP, PostgreSQL wire, MySQL wire, Arrow Flight SQL	Только Trino HTTP
Бэкенды	Trino, DuckDB, StarRocks, Athena, ClickHouse (planned)	Только Trino
Маршрутизация	По протоколу, заголовкам, тегам, regex, Python скриптам	По весам, группам, header `X-Trino-Routing-Group`
SQL трансляция	Да (sqlglot) – из PostgreSQL в Trino и наоборот	Нет
Конкурентность и очереди	`maxRunningQueries` на группу, очередь на прокси, spillover	`maxConcurrentQueries` на кластер, очереди нет
Auth/AuthZ	OIDC, LDAP, Static, OpenFGA	Базовая поддержка `X-Trino-User`
Метрики	Prometheus, Grafana, Admin API, Studio	Prometheus (JMX), менее развит
GUI управления	Полноценный веб-интерфейс (Studio)	Отсутствует (только конфигурация API)

Плюсы QueryFlux: гетерогенность (один шлюз на разные виды движков), гибкая маршрутизация, встроенный перевод диалектов, PostgreSQL wire, наличие красивого веб-интерфейса.
Минусы: молодой проект (версия 0.1.2), не поддерживается Extended Query Protocol для PostgreSQL, требует настройки доступа к системным таблицам Trino.

8.2. Другие альтернативы

Trino + многокаталожность – простейшее решение, но требует доработки приложений для переключения на trino диалект.
Apache Linkis – тяжеловесный ETL-ориентированный шлюз, не подходит для лёгкой ad-hoc аналитики.
Nginx + Lua + sqlglot – сложно поддерживать, требует глубокой кастомной разработки.
Коммерческие решения (Starburst, Dremio) – дорогостоящие, но предоставляют готовую маршрутизацию, закрытый код и полноценный SLA. но 100% всего не решает так как это готовые коробки. явно захочется что-то под себя подкрутить.

и еще много с акцентов на gateway: Hoop.dev кстати интересный и GatewayD

GatewayD и ProxySQL: Не заменяют Trino, но отлично решают вашу задачу с логированием. GatewayD работает с PostgreSQL и может проверять запросы через Casbin, а ProxySQL предоставляет детальное логирование запросов (время, строки, IP и т.д.). Логирование — есть (аудит запросов), диалект Postgres — полный, подключение к 90 БД — сложно (нужно настраивать 90 подключений).
Mammoth и JumpWire: Специализированные прокси для PostgreSQL. Первый упрощает аудит, логируя каждую команду, второй позволяет гибко настраивать политики доступа и маскировать данные. Логирование — есть, диалект Postgres — полный, подключение к 90 БД — сложно (на каждый экземпляр нужен свой прокси).
Hoop.dev: Платформа для контролируемого доступа к базам данных с сильным акцентом на аудит и безопасность. Логирует все: от попыток входа до полного текста запросов и даже планов выполнения. Логирование — детальное, диалект Postgres — полный, подключение к 90 БД — сложно (требует развёртывания на каждую базу).
Уже посмотрели QueryFlux: Это решение ближе всего к Trino, но работает как высокоуровневый шлюз. На входе может принимать запросы через “PostgreSQL wire”, а на выходе автоматически транслировать диалект под Trino, Clickhouse и другие системы. Логирование — ограниченное, диалект Postgres — только как входной интерфейс (запросы уходят в Trino), подключение к 90 БД — замена Trino (шлюз к 90 разным источникам).
SQL Gateway (CData): Позволяет представить любые ODBC-источники как виртуальную PostgreSQL или SQL Server базу. Логирование — только общее, диалект Postgres — виртуальный (эмуляция), подключение к 90 БД — сложно (настройка ODBC).
Cloud Service Gateways (Infisical и др.): Специализированные облачные решения. Обещают централизованный доступ и аудит, но их возможности нативных диалектов сильно привязаны к конкретному провайдеру.
Native PostgreSQL Gateways: Как сборник технологий (например, PgCat), из которых можно построить своё решение. Позволяет гибко настраивать подключения и логи, но требует ручной сборки и высокой квалификации.
Интеграция с Keycloak: К сожалению, прямой интеграции с Keycloak для аутентификации SQL-запросов практически нет. Keycloak используется для аутентификации доступа к веб-интерфейсам административных консолей, но не для самих SQL-клиентов. Исключение — GatewayD, который, хотя и не интегрируется с Keycloak, позволяет реализовать схожую логику через Casbin.

Вывод: QueryFlux идеален, если у вас уже есть несколько движков и вы хотите дать единую точку входа для бизнес-пользователей и аналитиков (особенно тех, кто привык к `psql`). Для production, где критична поддержка prepare-statements, стоит использовать Trino JDBC напрямую или использовать дополнительный прокси (например, `trino-pg-gateway`).

9. Итоги и рекомендации

Мы успешно запустили полноценный аналитический стек с Lakekeeper (Iceberg), Trino и StarRocks, а QueryFlux обеспечил единый вход через HTTP и PostgreSQL wire. Ключевые достижения:

✅ QueryFlux принимает Trino HTTP и PostgreSQL wire запросы, направляя их в Trino.
✅ Клиент `psql` выполняет сложные `SELECT`-запросы к Iceberg таблицам (даже TPC-DS) через порт 5434.
✅ Статистика в Studio отображается корректно.
✅ Маршрутизация по протоколу (`protocolBased`) работает как задумано.
✅ Веб-интерфейс Studio даёт полный контроль над кластерами, группами, маршрутами и скриптами.

Рекомендации для production:

Замените `persistence: inMemory` на `persistence: postgres` и настройте репликацию БД конфигурации (чтобы не терять историю и настройки).
Включите аутентификацию OIDC (Keycloak) и авторизацию OpenFGA для разграничения доступа к группам кластеров.
Рассчитайте `maxRunningQueries` по формуле N = R \times T, исходя из планируемой нагрузки и SLA.
Для PostgreSQL-клиентов с GUI (DataGrip/DBeaver) используйте параметр `prepareThreshold=0` (через JDBC) или переключитесь на официальный Trino JDBC драйвер.
Настройте сбор метрик в Prometheus и дашборды Grafana для мониторинга длины очередей и задержек.

Заключение: QueryFlux — очень перспективный и многообещающий инструмент для построения унифицированного доступа к аналитическим движкам. Несмотря на молодость, он уже пригоден для некоторых сценариев, особенно если вы готовы ограничиться simple query protocol при использовании PostgreSQL wire. В связке с Iceberg-каталогами и объектным хранилищем он образует мощную open-source альтернативу дорогим коммерческим решениям.

Ничто не предвещало

Wed, 10 Jun 2026 08:58:22 +0300

Вчера зевнул на улице, съел муху. Блин, надо больше спать 😅