Архитектура AIDA
AIDA — мультитенантная платформа анализа происхождения данных. On-premise, в вашем контуре. Студия аналитика, граф-хранилище и контрольный центр связаны единым потоком данных.
Эта страница — про устройство: слои, путь запроса, компоненты, стек. Имена модулей здесь не маркетинг, а узлы архитектуры.
Три слоя
- Seidr Studio — то, что видит аналитик: загрузка SQL, граф, impact-анализ, ассистент.
- YGG / FRIGG — где живут данные: граф происхождения и состояние.
- Heimdallr — изоляция тенантов, доступ, метрики, события платформы.
Путь данных
- Аналитик работает в Seidr Studio (холст Loom, инспектор Knot).
- Запросы идут через Chur — шлюз: аутентификация, сессии, проксирование на бэкенд.
- SHUTTLE (GraphQL), Anvil (impact / трассировка происхождения) и Mimir (ассистент) читают граф из YGG.
- Hound разбирает SQL и пишет результат в YGG напрямую, пакетно (REMOTE_BATCH). Dali оркеструет прогоны парсинга (JobRunr) и принимает события OpenLineage.
- Heimdallr собирает события и метрики со всех сервисов.
Компоненты
Граф происхождения (YGG)
Сердце платформы — типизированный граф в Ygg.db. Запросы: Cypher (OpenCypher), SQL, Gremlin, GraphQL. Каждый тенант — в своей изолированной базе.
Схема (v26) включает:
- ≈26 типов вершин — от приложений, баз и схем до таблиц, колонок, процедур, операторов, атомов, курсоров, записей и иерархии ограничений (PK/FK/unique/check).
- свыше 60 типов рёбер, организованных в таксономию: структура (
CONTAINS_*,HAS_COLUMN), поток по таблицам (READS_FROM,WRITES_TO), поток по колонкам (DATA_FLOW,FILTER_FLOW,ATOM_PRODUCES), разрешение ссылок (ATOM_REF_*), вызовы (CALLS).
Колоночная связность строится через атомы — атомарные ссылки в выражениях SQL, которые разрешаются до конкретных колонок-источников. Детали алгоритма — на странице Seidr Studio.
FRIGG — отдельный экземпляр Ygg.db: снепшоты графа (отмотка во времени, append-only / SCD Type 2), пользовательские настройки, состояние сессий и фоновых задач.
Уровни визуализации
Loom показывает граф на четырёх уровнях детализации (L1–L4): обзор баз и схем → исследование схемы → область процедуры с колоночным путём → дерево одного оператора. Переключение в один клик, с хлебными крошками. Подробно — в Seidr Studio.
Ассистент: где работает модель
Mimir работает в двух режимах — честно про оба:
- Локальная или открытая модель — через Ollama, в вашем контуре. Данные о схеме не покидают периметр — режим для закрытого контура и 152-ФЗ.
- Облачная модель — опция для скорости, без локальных требований к железу.
Архитектурно это один и тот же tool-calling агент; меняется только провайдер модели (конфигурация). Внешние облачные LLM в on-prem поставке не задействуются.
Изоляция тенантов
Каждый тенант изолирован на уровне базы данных (hound_<тенант>). На каждом запросе бэкенд проверяет заголовок X-Seer-Tenant-Alias против привязки тенанта в JWT — несовпадение отклоняется (не логируется и продолжается, а именно отклоняется). Общих данных между тенантами нет — только общий контроль через Heimdallr.
Наблюдаемость (Heimdallr)
Heimdallr — собственный слой наблюдаемости платформы, без внешних систем мониторинга.
- Метрики — временны́е ряды прямо в Ygg.db: события платформы (хранение 7 дней), прогоны парсинга (365 дней), приём OpenLineage (90 дней), плюс память/запись парсера.
- Дашборды — графики на Nivo прямо в интерфейсе Heimdallr.
- События — поток в реальном времени по WebSocket с «холодным» воспроизведением последних событий при подключении.
- Доступ — REST
/api/heimdall/metrics/{series,topk,value,heatmap}.
On-premise
- Развёртывание — Docker Compose. Требования и режимы — Развёртывание.
- Доступ, роли, изоляция — Безопасность.
- Функции студии — Seidr Studio.