Perplexity Computer підключається до Snowflake та Databricks

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

Концепція знайома: дозволити нетехнічним користувачам ставити запитання звичайною мовою, дозволити агенту писати SQL і повертати числа, прив'язані до реальних таблиць сховища. Цікаво не у концепції. Цікаво — у механізмі управління, що лежить під нею.

Ключові деталі

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

Сценарії використання охоплюють нудні, але дорогі робочі процеси: аналіз пайплайну, огляд використання продукту, сегментацію клієнтів, підсумки трендів виручки та повторювані аналітичні завдання. Функція постачається через конектори Perplexity для Snowflake і Databricks і доступна лише користувачам Pro, Max, Enterprise Pro та Enterprise Max. Адміністратори контролюють розгортання на рівні організації.

На боці Snowflake підтримуються бази даних, схеми, таблиці, вʼюери, матеріалізовані вʼюери та структуровані формати даних, як-от CSV, JSON і таблиці на основі Parquet. Документацію Snowflake варто перечитати всім, хто підключає це до матеріалізованих вʼюерів зокрема, бо поведінка витрат там швидко стає неочевидною. На боці Databricks інтеграція охоплює таблиці та вʼюери Unity Catalog, таблиці Delta Lake, схеми, каталоги, зовнішні таблиці, зареєстровані в Unity Catalog, і структуровані дані. Неструктуровані активи — зображення, аудіо, відео, файли у специфічному для сховища сховищі — наразі не підтримуються.

Технічним центром є інструмент під назвою Data Map. Perplexity описує його як спільний організаційний семантичний шар, побудований зі структури сховища, зв'язків між таблицями, історичних патернів запитів і бізнес-контексту, наданого адміністраторами. Адміни можуть переглядати й редагувати карту, оновлювати її та затверджувати запропоновані зміни на основі відгуків користувачів. Цей останній пункт важливіший, ніж натякає маркетинг.

Щодо автентифікації: Snowflake підтримує користувацький OAuth, сервісні облікові записи з key-pair аутентифікацією або програмні токени доступу. Databricks використовує індивідуальну OAuth-ідентичність. Запити виконуються під наявними правами платформи, тому доступ забезпечується Snowflake RBAC або Databricks Unity Catalog, а не UI Perplexity. Адміни можуть вимикати конектори, керувати доступом і застосовувати read-only поведінку на рівні дата-платформи.

Чому це важливо для дата-команд

Відкинувши маркетинг, для керівника платформи є два реальних питання: хто відповідає за семантику і хто платить за запити.

Щодо семантики, Data Map — це правильна форма відповіді. Команди, з якими я працював, всі наштовхувались на одну і ту ж стіну з text-to-SQL: модель технічно здатна, але вона не знає, що rev_net_v3 — це таблиця, якій фінанси справді довіряють, а rev_net_v2 — та, що тихо подвоює повернення. Семантичний шар з адмін-рев'ю, оновленням і процесом затвердження — ось як зупинити агента від впевненого генерування неправильних чисел. Це той самий патерн, який команди вже будують у dbt, тільки замість BI-інструменту його споживає LLM.

Моя думка: цінність цього релізу цілком залежить від того, наскільки дисципліновано адміни ведуть Data Map. Пропустите цю роботу — і ви запустили дуже дорогий спосіб генерувати правдоподібно виглядаючу нісенітницю.

Щодо витрат, інтеграція — це тонкий клієнт поверх сховища, яке виставляє рахунок за кожен запит. Кожне «швидке питання» від менеджера з продажів стає скануванням у Snowflake або Databricks. Я бачив виробничі інциденти, де один неправильно налаштований BI-дашборд запускав повне сканування таблиці з п'ятьма мільярдами рядків кожні п'ятнадцять хвилин, і місячний рахунок падав як удар. А тепер уявіть те саме, але тригером є сотні нетехнічних користувачів, які друкують цікаві запитання у вікно чату.

Засоби захисту існують. Запити виконуються під правами платформи. Адміни можуть застосовувати read-only на рівні сховища. Матеріалізовані вʼюери та попередньо агреговані таблиці залишаються вашими друзями. Але розмова про бюджет буде гучною в будь-якій організації, що вмикає це без governance запитів. Плануйте це до того, як procurement підпише SOW, а не після.

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

Вплив на індустрію

Для iGaming і fintech платформ розрахунок специфічний. Ці вертикалі вже запускають важкі аналітичні навантаження проти сховищ для скорингу ризиків, сегментації гравців, сигналів шахрайства та регуляторної звітності. Обіцянка дозволити керівнику відділу боротьби з шахрайством запитати «покажи мені аномалії депозитів за останні 48 годин по регіонах» без залучення аналітика — справді корисна. Ризик у тому, що той самий запит, виконаний ad hoc проти сирих таблиць подій, коштує в десять разів більше, ніж еквівалентний тайл дашборду проти правильно змодельованого марту.

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

Для корпоративних інфра-команд головним є питання автентифікації. Сервісні облікові записи з key-pair auth, OAuth, програмні токени у Snowflake; OAuth-ідентичність у Databricks; права, що застосовуються через RBAC і Unity Catalog. Це правильна відповідь. Це означає, що перевірка безпеки може схвалити це без необхідності команди вигадувати нову модель дозволів. Це також означає, що радіус ураження від скомпрометованого облікового запису Perplexity обмежений тим, що цей користувач вже міг робити у сховищі, — що саме так і має бути.

Більш широкий сигнал: семантичні шари стають спірною територією в аналітиці. У dbt є один. У Looker є один. У Cube є один. Тепер у Perplexity є один. Хто б не володів надійним визначенням «щомісячного регулярного доходу» у вашій компанії — той контролює аналітичний робочий процес. Це серйозне місце для встромлення прапора.

За чим стежити

Три речі варто відстежувати протягом наступних двох кварталів.

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

По-друге, дрейф Data Map. Семантичні шари, схвалені адміністраторами, як правило, розпадаються в момент, коли людина, яка їх побудувала, змінює роль. Слідкуйте за тим, чи додасть Perplexity версіонування, метадані власності та сигнали застарілості до записів Data Map. Без цього шар перетвориться на полицевий пил через 18 місяців.

По-третє, питання неструктурованих даних. Зараз воно поза охопленням. Якщо Perplexity розширить це до логів запитів, транскриптів підтримки або медіаметаданих, що зберігаються поруч із сховищем, продукт стане суттєво цікавішим — і проблема governance стане суттєво складнішою. Для OLAP-орієнтованих компаній, які вже оцінюють рушії на зразок ClickHouse для аналітики логів, стежте, чи почнуть агентні інтерфейси сягати і в ці сховища теж.

Ключові висновки

• Governance справді якісний: запити успадковують права Snowflake RBAC і Databricks Unity Catalog, тому існуючий контроль доступу залишається в силі.
• Data Map — це справжній продукт: семантичний шар з адмін-рев'ю — ось що відрізняє це від звичайного text-to-SQL інструменту. Ведіть його або відмовтесь від впровадження.
• Закладіть бюджет на витрати сховища: кожен запит у чаті — це платне сканування. Позначайте, моніторте та попередньо агрегуйте, перш ніж відкривати для широкої аудиторії.
• Неструктуровані дані поза охопленням: зображення, аудіо, відео та файли поруч із сховищем наразі не підтримуються. Плануйте відповідно.
• Рівні доступу мають значення: доступ отримують лише користувачі Pro, Max, Enterprise Pro та Enterprise Max з адмін-контролем на рівні організації. Procurement і IT мають бути узгоджені до пілоту.