Data architect¶

Data architect объединяет инструменты для понимания структуры данных, контроля зависимостей и подготовки витрин. Раздел находится в Glarus BI по адресу /data-architect/. Он доступен только пользователям из групп Администраторы и Аналитики данных.

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

Конструктор схемы (ERD)¶

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

Связь FK можно создать перетаскиванием между полями разных таблиц, а созданную пользователем связь — удалить с холста. Перед сохранением проверьте итоговое направление связи в окне подтверждения. Такие действия меняют только метаданные Glarus BI; реальная схема базы данных и её DDL не изменяются. Связи, существующие в самой базе данных, не удаляются через этот инструмент.

Предложения связей с помощью ИИ¶

Кнопка генерации связей с помощью ИИ предлагает кандидаты для отсутствующих FK. Перед применением изучите связь, уровень уверенности и объяснение, снимите отметки с неподходящих вариантов и только затем нажмите «Применить выбранные». Ни одна связь не создаётся автоматически.

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

Lineage: поток данных¶

Lineage отвечает на вопрос «откуда пришли данные и куда они идут». Выберите таблицу или, когда это возможно, отдельную колонку, чтобы проследить upstream-источники и downstream-потребителей через таблицы, модели, вопросы и ETL-задания. Это помогает понять происхождение показателя до изменения модели или источника.

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

Зависимости, влияние и диагностика¶

Инструмент «Зависимости» строит карту того, что использует выбранную таблицу, модель, вопрос, дашборд или ETL-задание. Перед удалением, переименованием или изменением источника загрузите downstream-граф: это и есть анализ влияния — список объектов, которые могут потребовать проверки.

На вкладке диагностики ищите битые зависимости и неиспользуемые модели или вопросы, затем переходите к проблемному элементу. Если источник требуется заменить, выберите старый и новый источник, сопоставьте поля и внимательно проверьте предварительный список затронутых объектов. Применяйте замену только после ревью: нативные запросы могут быть пропущены, а операция не должна заменять ручную проверку бизнес-логики.

ETL-задания: построение витрин¶

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

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

Ограничение инкрементального обновления

Инкрементальная загрузка добавляет новые и изменённые строки, если курсор обновляется, но не отражает удаления из источника: удалённой строки уже нет в выборке. Для полной синхронизации после удалений выполните полный refresh или используйте отдельный процесс CDC.

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

Конвейеры: граф выполнения ETL¶

Конвейер — это отдельный объект Data Architect, который объединяет ETL-задания и вычислительные шаги в направленный ациклический граф (DAG). ETL-задание остаётся самостоятельным объектом: удаление узла из конвейера не удаляет исходное задание и его историю.

На странице /data-architect/pipelines отображается список конвейеров. Из строки доступны запуск, история, редактирование и безопасное удаление или архивирование. Список поддерживает поиск, сортировку и постраничную навигацию; статус запуска обновляется без перезагрузки страницы.

Редактор и связи¶

Откройте конвейер отдельно, чтобы перейти в редактор DAG. Перетащите ETL-задание или compute-шаг из палитры на холст, настройте свойства справа и соедините узлы от порта к порту. Положение узлов сохраняется; доступны масштабирование, панорамирование, автоматическая раскладка и «Уместить на экране». Для добавления и удаления узлов и связей есть доступные клавиатурные действия.

Ручная зависимость и допустимые целочисленные branch-коды на ребре задают маршрутизацию. Автоматически найденные SQL-зависимости отмечаются отдельно. Циклы, несовместимые связи, пустые обязательные параметры и неверный branch показываются до сохранения и не допускаются сервером.

Параметры, compute и запуск¶

Параметры имеют тип и значение по умолчанию; в compute-шаге можно выбрать соединение и SQL с плейсхолдерами {param} и {ctx.field}. Один запуск проходит узлы в порядке зависимостей, а для fan-in ожидает все непропущенные входы. Статусы Успешно, Ошибка, Пропущено, Выполняется и Ожидает отображаются в редакторе и истории.

Расписание и история¶

Для конвейера можно задать расписание cron и часовой пояс. Расписание восстанавливается после перезапуска приложения; один тик запускает конвейер не более одного раза. Политика перекрывающихся запусков видна в истории. История содержит trigger, параметры и контекст, длительность, шаги, branch-коды, причины ошибок и ссылки на связанные ETL-запуски. Ошибка создаёт одно уведомление, а Пропущено само по себе аварийным уведомлением не является.

Перед удалением проверьте downstream-зависимости. Удаление конвейера сохраняет аудит и историю запусков через архивный механизм; права create/read/update/delete/run/history проверяются одинаково.