Google Cloud a detaliat pe 15 octombrie integrarea Gemini cu borderless Lakehouse, infrastructura prin care companiile lucrează cu date distribuite între mai multe platforme. Integrarea este în preview și permite configurarea accesului la surse precum Databricks Unity Catalog și Snowflake Horizon direct din Gemini, prin federarea cataloagelor de date.

Funcția privește întrebările și analizele care folosesc informațiile unei organizații. În această arhitectură, agenții identifică datele relevante și trimit interogări către motoarele care le procesează. Conversational Analytics poate lucra cu tabele federate, alături de date BigQuery și alte surse configurate. Accesul la informații este legat de conexiuni și permisiuni definite în infrastructura firmei.

Trei colegi colaborează la laptopuri și consultă documente de lucru
Mikhail Nilov

Conectarea datelor păstrează rolul permisiunilor existente

Documentația conectorului BigQuery pentru Gemini Enterprise descrie două moduri de lucru. Interogarea federată, aflată în preview, trimite cererea către BigQuery folosind identitatea utilizatorului și păstrează regulile IAM, inclusiv accesul la nivel de rând. Ingestia copiază datele unei anumite tabele într-un depozit Gemini Enterprise și necesită reîmprospătare pentru a reflecta modificările sursei.

Aceste instrucțiuni se aplică edițiilor Standard, Plus, Pay-as-you-go și Frontline ale Gemini Enterprise. Ediția Business are documentație separată. În modul federat, utilizatorul poate analiza tabelele și seturile de date pentru care are drepturi, iar rularea interogărilor generează costurile de procesare BigQuery. Activarea unui conector și dreptul de a citi datele sunt condiții distincte.

Lakehouse runtime catalog centralizează metadatele tabelelor într-un serviciu administrat, fără servere gestionate de client. Metadatele descriu structura și localizarea informațiilor, iar fișierele de date rămân în stratul de stocare. Motoare precum BigQuery și Apache Spark pot folosi același catalog, cu interfețe compatibile cu standardele deschise utilizate pentru tabelele Apache Iceberg.

Arhitectura catalogului separă înregistrarea tabelului, metadatele despre structura și versiunile sale și fișierele care conțin datele propriu-zise. În configurațiile cu delegarea accesului la stocare, motoarele primesc acreditări temporare, cu domeniu limitat. Această separare permite administrarea accesului la resurse fără a transforma simpla descoperire a unui tabel într-un drept general asupra întregii stocări.

Agenții primesc contextul tehnic și definițiile de business

Knowledge Catalog adaugă instrumente de căutare a datelor accesibile și de citire a contextului. Acest context poate include scheme de tabele, descrieri de coloane, termeni din glosarul firmei și interogări verificate anterior. Integrarea este numai pentru citire și poate fi activată automat când o aplicație Gemini Enterprise primește un conector Data Cloud în modul federat.

Căutarea în catalog folosește identitatea persoanei autentificate. Înregistrările pentru care utilizatorul nu are drepturi sunt filtrate din rezultatele descoperirii. Pentru metadatele suplimentare și sursele terțe există permisiuni specifice catalogului. Astfel, descrierea unei tabele și accesul la conținutul acesteia sunt controlate în funcție de resursa și identitatea implicate.

Interogarea tabelelor externe presupune și drepturi asupra motorului de execuție. Documentația Lakehouse enumeră roluri pentru citirea datelor BigQuery, rularea lucrărilor și descoperirea metadatelor. După configurarea conexiunii, tabelele federate pot fi analizate prin SQL în BigQuery sau prin Apache Spark. Lakehouse gestionează traducerea metadatelor și accesul la sursa asociată.

Pentru aplicațiile custom cu integrare AI, accesul programatic poate folosi serverul MCP BigQuery. Acesta oferă instrumente pentru interogări, metadate și inventarul resurselor, cu autentificare și autorizare OAuth și IAM. Aplicația care îl utilizează stabilește instrumentele accesibile agentului, în cadrul drepturilor acordate identității sale.

Documentația MCP distinge instrumentul de execuție numai pentru citire de cel care acceptă și operațiuni de modificare. Pentru instrumentele de interogare sunt descrise o limită implicită de trei minute și rezultate de maximum 3.000 de rânduri. Acestea sunt limitele instrumentelor respective; volumul stocat și puterea de procesare a platformei de date sunt niveluri separate ale sistemului.

Interogarea între platforme implică transport și cache regional

Accesul cross-cloud descoperă structura informațiilor din cataloagele externe și citește datele de care are nevoie o interogare. Autentificarea poate utiliza credențiale păstrate în Secret Manager sau federarea identității. Conexiunile acceptate depind de furnizor și de configurația sursei; documentația enumeră, între altele, AWS Glue, Databricks Unity Catalog și Snowflake Horizon Catalog.

Pe măsură ce sunt citite, blocurile de date pot fi păstrate temporar într-un cache Google Cloud pentru reutilizare la interogări ulterioare. Cache-ul se află în regiunea țintă a conexiunii, iar traficul către furnizorul extern depinde de datele care trebuie aduse din sursă. Interogarea fără migrarea întregului set de fișiere include, astfel, transferul și stocarea regională a blocurilor necesare procesării.

Cross-Cloud Interconnect oferă o conexiune dedicată între rețeaua Google și cea a unui furnizor cloud acceptat. Configurația implică resurse și porturi în ambele medii, iar proiectarea pentru disponibilitate include redundanță. Această componentă asigură traseul privat de rețea; catalogul, identitățile și motorul de interogare au în continuare roluri proprii în accesarea datelor.

Disponibilitatea conexiunilor este descrisă prin perechi de regiuni și tipuri de interconectare. De exemplu, pentru regiunea AWS Frankfurt, documentația indică Google Cloud Frankfurt drept regiunea cea mai apropiată și marchează opțiunile corespunzătoare de interconectare. Localizarea infrastructurii și a cache-ului este parte din configurarea tehnică a datelor, separată de limba în care utilizatorul formulează întrebarea.

Importul prin Dataflow este un flux distinct

Google documentează separat importul tabelelor Delta Lake din Cloud Storage în Lakehouse prin Dataflow. Aici, datele sunt copiate în tabela destinație, printr-o lucrare care își adaptează resursele la volum. Pentru tabele existente, schema destinației trebuie să corespundă sursei. Funcția utilizează un flux batch și are condiții diferite de interogarea federată a datelor păstrate la alt furnizor.

După import, migrarea continuă poate utiliza capturarea modificărilor, cu activarea proprietății necesare în Delta Lake și lucrări ulterioare programate. Documentația delimitează acest import la surse Delta Lake valide din Cloud Storage; Amazon S3 nu este acceptat ca sursă pentru operațiunea respectivă. În pachetul Lakehouse, conectarea, interogarea și migrarea rămân mecanisme cu cerințe tehnice proprii.