Когда вы подключаете Snowflake или Databricks к Perplexity, Computer создаёт карта данных вашего хранилища данных или lakehouse. карта данных содержит ключевую информацию о вашей модели данных — важные таблицы и столбцы, распространённые шаблоны запросов и связи между объектами — чтобы Computer мог преобразовывать вопросы на естественном языке в точные запросы.
Представьте это как карту вашей среды данных, которая помогает Computer понимать, что где находится и как обычно используется. После создания карта данных продолжает со временем улучшаться: она учится на отзывах пользователей, её могут напрямую редактировать администраторы, а также она версионируется, чтобы изменения всегда можно было проверить и откатить.
После запуска создания карта данных Computer исследует вашу модель данных, используя разрешения подключённой учётной записи. Этот процесс анализирует ваши схемы, таблицы, представления и исторические шаблоны использования, чтобы сформировать всестороннее понимание ваших данных.
карта данных надёжно хранится в версионируемом репозитории, отдельном для каждой организации, и доступен только участникам вашей организации. Каждое изменение — будь то повторное создание, правки администратора или обновления по результатам самообучения — фиксируется, чтобы его можно было проверить и откатить.
Существует одна карта данных на организацию, общий для всех участников этой организации. Когда администратор запускает создание, это делается от имени всей организации, а не отдельного пользователя.
Создание карта данных для Snowflake запускается администратором организации из настроек подключения Snowflake. Perplexity предоставляет два подключения Snowflake, и администраторы создают карта данных из того подключения, которое настроила их организация:
Snowflake (ключевая пара или PAT) — запросы выполняются от имени настроенной сервисной учётной записи.
Snowflake (User OAuth) — запросы выполняются под учётной записью Snowflake администратора, который запускает создание.
Используемая учётная запись должна иметь возможность читать представления Snowflake account-usage (см. Требования ниже). Если эти права отсутствуют, создание сразу завершится с понятной ошибкой разрешений, а не приведёт к формированию неполного карта данных.
Для Databricks создание запускается из настроек подключения с использованием OAuth-идентичности Databricks инициатора. Computer перечисляет каталоги, схемы и таблицы, которые этот пользователь может видеть в Unity Catalog, и читает системные таблицы Databricks для получения сигнала об использовании. То, что инициатор может видеть в Unity Catalog, и определяет, что попадёт в карта данных.
Вы можете добавить Дополнительный контекст — загрузить файлы или добавить заметки с описанием ваших данных (например, что представляют ключевые таблицы, бизнес-определения, распространённые шаблоны запросов), чтобы помочь Computer точнее интерпретировать ваши данные. Дополнительный контекст используется в каждом запуске создания и не затрагивается при повторном созданиитак что вы можете со временем продолжать дополнять его, не беспокоясь о том, что потеряете его.
После завершения генерации Сгенерировать карту данных кнопка в модальном окне коннектора становится Просмотреть знания. Нажатие Просмотреть знания открывает Редактор карты данныхгде администраторы могут просматривать, редактировать и управлять всем, что Computer узнал о ваших данных. Перегенерировать карту данных также доступно в модальном окне коннектора, если уже существует первоначальная карта данных — см. Повторное создание карта данных чтобы узнать, что она делает и что сохраняется.
Генерация карты данных может занять до 90 минутв зависимости от размера и сложности вашего хранилища данных или lakehouse. Не нужно держать страницу открытой — процесс выполняется в фоновом режиме, и Просмотреть знания кнопка появится в модальном окне коннектора после его завершения.
Редактор карты данных — это предназначенное для администраторов представление вашей карты данных, доступное из административных инструментов организации. В нем знания по Snowflake и Databricks разделены на отдельные разделы, а базовый бизнес-контекст, кластеры таблиц и шаблоны запросов организованы как файлы, которые можно читать и редактировать напрямую.
Из редактора администраторы могут:
Просматривать полную карту данных — бизнес-контекст, кластеры таблиц, распространенные шаблоны запросов.
Редактировать файлы напрямую. Сохраненные изменения сразу применяются к действующей карте данных и становятся новой истиной; им не нужно проходить через конвейер проверки.
Проверять и применять изменения, предложенные ИИ из конвейера самообучения. Администраторы могут одобрить предложение (изменения будут применены к карте данных) или отклонить его (предложение будет отброшено). Изменять предложение на месте до одобрения сейчас нельзя — если администратору нужен другой результат, он может отклонить предложение, а затем внести изменение самостоятельно.
Просматривать историю версий любого файла и при необходимости откатываться назад.
Прямые правки в редакторе сохраняются для обычного использования, но они существуют вместе с автоматически сгенерированным содержимым и не сохраняются, если вы перегенерируете карту данных для этого хранилища — см. Повторное создание карта данных ниже.
Карта данных становится лучше по мере того, как ваша команда ею пользуется. Когда пользователь исправляет агента данных в сессии — например, «используй fct\_queries вместо query\_events для количества запросов» или «исключи type = 'internal' из метрик объема запросов» — Computer фиксирует эту обратную связь и использует ее, чтобы улучшать карту данных для всех.
Конвейер спроектирован так, чтобы быть безопасным, подлежащим проверке, а также доступным для всей организации:
Когда пользователь оставляет обратную связь в сессии Data Scientist, Computer записывает структурированное исправление — файл, на который оно должно повлиять, раздел, предлагаемое изменение и контекст сессии, в котором оно было создано. Сама карта данных никогда не редактируется напрямую из пользовательской сессии; обратная связь сначала всегда попадает именно в этот журнал.
Раз в день Computer просматривает исправления, зафиксированные за предыдущие 24 часа для каждой организации, и формирует единое консолидированное предлагаемое обновление для карта данных:
Несколько исправлений в одной и той же области объединяются в одно изменение.
Противоречащие друг другу исправления (например, одно говорит «всегда включать cron jobs», другое — «всегда исключать cron jobs») откладываются для проверки человеком а не разрешаются автоматически.
Каждое исправление направляется в нужный warehouse — исправление, специфичное для Snowflake, не попадет в карта данных для Databricks, и наоборот.
Исправления, которые нельзя уверенно объединить или направить, помечаются для просмотра администратором вместо того, чтобы применяться незаметно.
Результат отображается в редакторе карты данных как единое предложение, которое администраторы могут проверить.
Администраторы одобрить предложение (изменения применяются к карта данных) или отклонить его (предложение отклоняется). Одобрение — это то, что «развертывает» изменения: следующий вопрос к данным, который задаст ваша команда, будет использовать обновленную карту данных. Отдельного шага публикации нет.
Такой подход с участием человека намеренно выбран: он позволяет Computer непрерывно учиться на реальном использовании, сохраняя за администраторами контроль над тем, что считается достоверным источником истины.
Кто что может?
Любой пользователь в сессии Data Scientist может оставлять обратную связь, которая попадет в предлагаемое обновление следующего дня.
Администраторы организации могут просматривать и редактировать файлы карты данных напрямую, а также утверждать или отклонять ежедневные предлагаемые обновления в редакторе карты данных.
Существует одна карта данных на организацию — все участники организации выполняют запросы к одному общему карта данных. Отдельного карта данных для каждого пользователя нет.
Администраторы могут запускать Повторно создать карту данных в любое время из модального окна коннектора. На сегодня регенерация — это пересборка с нуля для хранилища, который вы регенерируете:
карта данных для этого хранилища полностью заменяется новым результатом. Ручные правки администратора в карта данных этого хранилища не сохраняются.
карта данных другого хранилища не затрагивается — регенерация Snowflake не влияет на Databricks и наоборот.
Дополнительный контекст сохраняется и повторно применяется к новому запуску.
Ожидающая обратная связь (исправления, зафиксированные в этот день, но еще не свернутые в предлагаемое обновление) сохраняется. Обратная связь, которая уже была одобрена и применена к карта данных, входит в число того, что будет заменено.
Полная история версий сохраняется, поэтому предыдущие версии карта данных по-прежнему можно просматривать.
Поскольку регенерация заменяет карта данных для хранилища и любые ручные правки администратора, ее следует запускать осознанно. Более безопасная регенерация, сохраняющая правки администратора, — а также отдельный явный «полный сброс» — уже в дорожной карте, но пока недоступны в продукте.
Идентификатор, используемый для генерации карта данных, — служебная учетная запись для аутентификации по ключевой паре / PAT, либо пользователь Snowflake инициирующего администратора для аутентификации через OAuth — должен иметь возможность читать оба этих представления в SNOWFLAKE.ACCOUNT\_USAGE схеме:
SNOWFLAKE.ACCOUNT\_USAGE.QUERY\_HISTORY
SNOWFLAKE.ACCOUNT\_USAGE.ACCESS\_HISTORY (Snowflake Enterprise Edition или выше)
Важно: ACCOUNT\_USAGE по умолчанию доступно только администраторам. Самая частая причина сбоя генерации — роль, которая может читать обычные базы данных, но не имеет доступа к ACCOUNT\_USAGE. Исправление — предоставить IMPORTED PRIVILEGES для SNOWFLAKE базы данных.
Если вы еще не предоставили этот доступ во время первоначальной настройки, выполните следующее от имени ACCOUNTADMIN: