Відповіді з сховища даних

Підключіть Computer до Snowflake або Databricks, зберігаючи існуючі ролі, дозволи та засоби безпеки.
Створіть карту даних, яка фіксує бізнес-визначення, зв'язки між таблицями та шаблони запитів для більш надійного аналізу.
Створюйте звіти, інформаційні панелі та робочі процеси регулярного моніторингу, використовуючи дані сховища разом з іншими затвердженими корпоративними джерелами.

Приклади запитів

Поширені запитання

Підключення Computer до сховищ даних

Як команди даних працюють з Computer?

Computer може надати бізнес-командам інтерфейс природною мовою для керованих даних сховища та поєднати їх із контекстом з інших затверджених систем. Клієнти зменшили кількість повторюваних запитів даних і дозволили команді даних витрачати більше часу на моделювання, керування та стратегічний аналіз. Це не замінює сховище, семантичний шар чи заходи з контролю якості даних.

Який найкращий спосіб розпочати?

Почніть з однієї добре зрозумілої бізнес-доменни та невеликої групи користувачів. Налаштуйте User OAuth, обмежте доступ до затверджених схем та інструментів, задокументуйте канонічні метрики, згенеруйте та перегляньте карту даних, а також протестуйте типові запитання на основі довірених звітів. Розширюйтеся лише після того, як команда даних буде задоволена якістю SQL, дозволами, витратами та поведінкою користувачів.

Чи може Computer проактивно моніторити метрики та конвеєри даних?

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

Архітектура та керування

Що таке карта даних і хто має нею керувати?

Карта даних — це шар контексту на рівні організації, який фіксує важливі таблиці, стовпці, зв'язки, шаблони запитів і бізнес-контекст. Вона допомагає Computer перекладати бізнес-запитання в запити з джерелом у сховищі. Власник платформи даних, аналітичної інженерії або керування даними повинен підтримувати її, визначати авторитетні метрики, переглядати запропоновані зміни та додавати постійний додатковий контекст.

Чи залишається сховище системою записів?

Так. Карта даних зберігає контекст про те, як орієнтуватися в даних. Поточні метрики все ще вимагають активного підключення, а SQL виконується в середовищі Snowflake або Databricks клієнта. Сховище залишається авторитетним джерелом даних, обчислень, дозволів, історії запитів та політики доступу.

Як забезпечується дотримання ідентифікації та дозволів?

Computer використовує User OAuth зі своїми конекторами. Кожна особа входить за допомогою свого індивідуального облікового запису, а запити виконуються в контексті налаштованої ролі цього облікового запису. Нативні гранти сховища, фільтри рядків, політики стовпців та конфігурація ролей залишаються авторитетними елементами керування. Спільний службовий обліковий запис для певних конекторів також підтримується, але він застосовує модель доступу службового облікового запису, а не індивідуальні дозволи кожного користувача.

Чи може Computer узгоджувати дані в сховищах, додатках SaaS, файлах і в Інтернеті?

Computer може поєднувати інформацію з увімкнених джерел в одному робочому процесі. Це не скасовує потреби в надійному розв'язанні сутностей. Для матеріальної звітності підтримуйте канонічні ідентифікатори клієнтів, продуктів і облікових записів на вищому рівні, задокументуйте затверджені перехресні посилання та визначте джерело істини для кожної метрики.

Точність і можливість перевірки

Як команді даних слід перевіряти згенерований SQL і відповіді?

Computer генерує SQL, який можна перевірити. Команди даних повинні перевірити SQL, порівняти матеріальні результати з довіреними звітами, протестувати граничні випадки та виправити відсутній бізнес-контекст у карті даних.

Коли системи не погоджуються, як вибирається авторитетна метрика?

Команда даних має зробити рішення остаточним. Адміністратори можуть редагувати карту даних, щоб затверджене визначення стало актуальною базовою істиною, а постійні бізнес-визначення можна розмістити в додатковому контексті. Конфліктні виправлення користувачів спрямовуються на перевірку людиною, а не вирішуються автоматично. Для кожної матеріальної метрики задокументуйте канонічне джерело, зернистість, обов'язкові фільтри, власника та відомі альтернативи.

Який слід аудиту доступний?

Журнали аудиту Perplexity фіксують події щодо введення користувачем, дій агента, завершення, помилок і адміністративних змін. Сховища даних, такі як Snowflake і Databricks, зберігають авторитетні записи запитів та ідентифікації на стороні сховища.

Чи можна точно відтворити кожну відповідь для аудитора?

Точне детермінистичне відтворення публічно не задокументовано та не гарантовано. Журнали аудиту, тред, SQL, що підлягає перевірці, історія версій карти даних і записи сховища можуть допомогти реконструювати виконання, але жоден задокументований ідентифікатор не зв'язує кожну відповідь із незмінними зпнімками даних, дозволів, карти даних і виконання моделі. Організації зі суворими вимогами щодо відтворюваності повинні зберігати власний маніфест версій доказів.

Безпека та відповідність нормативним вимогам

Де зберігаються дані та чи використовуються вони для навчання моделі?

Корпоративні дані не використовуються для навчання або донавчання моделей Perplexity. Завдання Computer виконуються в ізольованих пісочницях, а облікові дані знищуються разом із пісочницею. Артефакти сеансу та історія запитів сховища керуються окремо. Прикріплені файли сеансу видаляються через сім днів. Для корпоративних організацій доступні додаткові налаштовувані параметри зберігання.