Продолжение ответов на вопросы, которые не успели охватить в рамках эфира 1 июля:
13. Инструмент полезный. Есть опасения не попасть на костыли или ограничения на какой-либо стадии жизни продукта. Какие есть риски использования инструмента?
Особенности реализуемой продуктом функциональности и текущее состояние продукта требуют учитывать следующие моменты:
🟣Ограничения логики: Не вся логика (например, сложные неаддитивные расчеты) может быть реализована на уровне хранилища данных (хоть через DataForge, хоть через любую другую систему), и часть может остаться на уровне BI
🟣Зависимость от DWH: Продукт требует наличия качественного Gold-слоя, он не решает проблемы «грязных» или неструктурированных данных на нижних уровнях
🟣Отсутствие статистического анализа: DataForge не предназначен для статистического моделирования (A/B-тесты, проверка распределений и т.д.) и для обеспечения качественного наполнения создаваемых витрин требует реализации подобных проверок на других уровнях
🟣Ограничения управления представлениями витрин: DataForge не является инструментом для оркестрации баз данных и поэтому требует наличия отдельных механизмов, которые будут обеспечивать актуальность данных в представлениях, созданных на основе сгенерированных в продукте SQL-скриптов
14. Кто ответственный тогда будет за данные? Если дата-инженер настроил пайплайн, бизнес-пользователи поправили формулы, и в итоге получили ошибки в дашборде. Как тут выстроить процесс? Есть ли ролевая модель?
Да, существует многоуровневая ролевая модель, которая разграничивает ответственность:
🟣Глобальные роли: Наблюдатель, Аналитик, Разработчик, Проджект-менеджер, Администратор
🟣Проектный уровень доступа: Права на конкретный проект могут настраиваться индивидуально (Наблюдатель, Аналитик, Разработчик, Владелец). Уровень доступа не может превышать глобальную роль
Ответственность выстраивается так:
1. Дата-инженер/Разработчик подключает источники (Gold-слой) и настраивает маппинг
2. Бизнес-пользователи/Аналитики (с правами не выше Аналитика или Разработчика) могут создавать и изменять формулы на основе существующих сущностей
3. Процесс изменений контролируется через роли и будущую функцию верификации, где изменения требуют апрува перед применением
15. Непонятно про тесты. Как обеспечить качество данных? Что делать, если данные кривые или пустые - алерты.
В DataForge есть функционал для валидации результатов. Пользователи могут создавать сценарии проверок (бизнес-проверки), где задают эталонные значения для показателей при определенных условиях. Система вычисляет показатели по фактическим данным и сравнивает с эталоном. Это позволяет на уровне бизнес-данных (выручка, возвраты) убедиться в корректности расчетов и выявить проблемы с данными на финальной стадии.
16. Кто ключевой клиент: инженеры или бизнес? Инженерам нужен code, бизнес-пользователям – нет.
Ключевые клиенты — и инженеры, и бизнес-пользователи, но на разных этапах:
🟣Дата-инженеры и архитекторы на этапе внедрения: подключают хранилище, настраивают модели, выполняют маппинг
🟣Бизнес-пользователи и аналитики на этапе эксплуатации: используют уже настроенный семантический слой для создания и поддержки отчетов, корректировки формул и управления логикой без написания SQL-кода
17. Не хватает подхода «аналитика как код». Хочется уже сразу разговаривать с AI-агентом, чтобы он там все строил и кверил. Руками уже лениво работать и кликать)
DataForge уже движется в этом направлении:
🟣Есть работающий MCP-сервер и ИИ-ассистент, которые могут генерировать корректные SQL-запросы и строить отчеты по текстовым запросам, используя семантический слой в качестве контекста
🟣Разрабатывается механизм для автоматического заполнения РПИ через ИИ-агента, который анализирует структуру существующего хранилища
18. Было бы здорово все это дело положить в гит репо и уже там с помощью YAML или SQL описывать трансформации.
Сейчас в DataForge есть внутреннее версионирование проектов (создание версий, сравнение). Интеграция с Git (возможность полной выгрузки проекта в Git) находится в планах разработки. Текущий подход — управление через веб-интерфейс, а не через код в репозитории, хотя API для программного доступа к метаданным уже есть.
19. Было еще хорошо показать демо, как вот прям с 0 построить что-то. Допустим открыли новый проект и там просто и показать шаги и рассказать.
Стандартная последовательность действий при начале работы с продуктом описана в документации продукта и включает шаги:
1. Создать новый проект
2. Описать показатели, измерения и факты в РПИ
3. Объединить их в таблицы фактов и справочники
4. Настроить подключение к хранилищу данных
5. Выполнить маппинг логической модели на физическую
6. Настроить витрины с необходимыми показателями и измерениями
7. Создать представления для витрин в хранилище (автогенерация SQL)
8. Подключиться в BI-системе к созданным представлениям и строить отчеты
Эти шаги и были в целом продемонстрированы на вебинаре через интерфейс. Дополнительно можно посмотреть следующие короткие видеоинструкции по работе с продуктом:
🟣Как в DataForge создать семантический слой для BI и AI: показатели, измерения и происхождение данных - https://rutube.ru/video/private/434df249e05dc979e833b18dde33e2ab/
🟣Модель данных без хаоса: факты, PK/FK и проверка показателей в DataForge - https://rutube.ru/video/private/d445b512f715ff2f8a861fc0a6bf4a62/
🟣Как в DataForge собрать аналитическую витрину данных и выгрузить её в Excel или БД - https://rutube.ru/video/private/025c95fdbd86e321dadd0496b3b4709e/
Также есть возможность запросить персональное демо продукта, чтобы уточнить все детали реализации проекта “с нуля” на нём.
➡️ Запросить демодоступ и протестировать DataForge
DataForge | Подпишитесь и следите за обновлениями продукта 🔗
#DataForge #DataForge_вебинар