Come funziona Lakehouse senza confini

L'architettura tecnica di Lakehouse senza confini supporta l'interoperabilità tra i motori centralizzando la gestione dei metadati e gestendo le query tramite percorsi specifici.

Architettura

La creazione di Lakehouse di Google Cloud è costituita dai seguenti componenti tecnici:

  • Archiviazione: Cloud Storage e l'archiviazione BigQuery fungono da livello di archiviazione, con Apache Iceberg come formato di tabella aperta consigliato per l'archiviazione interoperabile e ad alte prestazioni in Cloud Storage. Con Lakehouse senza confini, i dati non devono risiedere in Google Cloud. Configurando connessioni cross-cloud (anteprima) ai cataloghi remoti supportati, puoi conservare i dati in altri sistemi di spazio di archiviazione sul cloud, come Amazon S3, ed eseguire query senza eseguire la migrazione dei file o creare pipeline ETL.

  • Catalogo: il catalogo di runtime Lakehouse fornisce una "single source of truth" per la gestione dei metadati. Centralizza il rilevamento dei metadati su più motori utilizzando varie opzioni di compatibilità, come l'endpoint del catalogo REST Apache Iceberg. Le registrazioni delle tabelle nel catalogo registrano automaticamente le voci nel Knowledge Catalog dei metadati aziendali.

  • Motore di query: BigQuery e i motori open source, tra cui Apache Spark, Apache Flink e Trino, interagiscono senza problemi connettendosi al catalogo di runtime Lakehouse. I motori di calcolo come Managed Service for Apache Spark utilizzano Apache Spark open source con ottimizzazioni di esecuzione per garantire la portabilità dei workload ed evitare il lock-in del fornitore.

  • Governance: Knowledge Catalog fornisce criteri di sicurezza, derivazione e governance centralizzati in tutta la lakehouse.

  • Strumenti di scrittura e acquisizione dei dati e analisi: i motori e gli strumenti integrati forniscono più percorsi per l'acquisizione e l'analisi dei dati, contribuendo a garantire un accesso coerente ai dati sia per i data scientist sia per gli analisti.

Gerarchia delle risorse

Lakehouse di Google Cloud organizza i dati utilizzando una gerarchia in linea con gli standard Apache Iceberg e i concetti di database standard. Questa struttura consente al catalogo runtime Lakehouse di mappare le identità logiche ai percorsi di archiviazione fisica. Per interagire con questa gerarchia di risorse e connettere i motori di query al catalogo, utilizza endpoint specifici, come descritto nell'elenco seguente.

  1. Catalogo di runtime Lakehouse: la risorsa di servizio regionale di primo livello in Google Cloud cui sono ospitati i metadati. Per connettere i motori di query a questo servizio e gestire i cataloghi sottostanti, configura le applicazioni client utilizzando un endpoint del catalogo specifico, ad esempio l'endpoint del catalogo REST Apache Iceberg.
  2. Catalogo: un contenitore logico all'interno del servizio di catalogo di runtime. Nella struttura di denominazione Project/Catalog/Namespace/Table (P.C.N.T), questa rappresenta l'istanza del catalogo specifica su cui stai eseguendo la query.
  3. Spazio dei nomi: un raggruppamento logico di tabelle all'interno di un catalogo. Per gli utenti che conoscono BigQuery, uno spazio dei nomi è funzionalmente simile a un set di dati.
  4. Tabella: l'entità specifica che punta ai dati in Cloud Storage. I metadati della tabella contengono lo schema, le informazioni di partizionamento e un puntatore allo stato attuale della tabella tramite un file metadata.json di Apache Iceberg.

Endpoint supportati

Il catalogo di runtime Lakehouse fornisce diversi endpoint per connettere i dati in Cloud Storage e BigQuery.

  • Endpoint del catalogo REST Apache Iceberg: fornisce un'interfaccia REST standard per un'ampia compatibilità con i motori open source come Apache Spark, Apache Flink, e Trino. Questa è l'interfaccia consigliata per i nuovi workload e offre interoperabilità completa di lettura e scrittura.

  • Endpoint del catalogo Apache Iceberg personalizzato per BigQuery: consente ai motori di interagire direttamente con il catalogo BigQuery. Questa interfaccia viene utilizzata principalmente per le tabelle Apache Iceberg gestite da BigQuery e per i workload esistenti che eseguono la transizione all'architettura Lakehouse.

  • Endpoint del catalogo Apache Hive: fornisce la compatibilità per i workload open source che dipendono dall'interfaccia del metastore Apache Hive (HMS). In questo modo puoi eseguire i workload Apache Hive o Spark su un servizio di metastore completamente gestito su Google Cloud.

Catalogo di runtime Lakehouse

All'interno della gerarchia delle risorse, il catalogo runtime Lakehouse funge da servizio di metadati regionale di primo livello in Google Cloud. Funge da container radice che ospita le singole istanze del catalogo, centralizzando il rilevamento dei metadati su motori di query diversi.

Implementa l' API del catalogo REST Apache Iceberg open source per gestire spazi dei nomi e tabelle e fornisce estensioni specifiche per la gestione dei cataloghi.

Per un approfondimento sul servizio di metastore, incluse le funzionalità chiave, motori supportati, configurazione degli endpoint e limitazioni, consulta Informazioni sul catalogo runtime Lakehouse.

Catalogo

Un catalogo è un container di metastore logico supportato dalle località del data warehouse di Cloud Storage. Nella struttura di denominazione Project.Catalog.Namespace.Table (P.C.N.T), il catalogo rappresenta l'istanza del metastore univoca che connette i metadati della tabella aperta ai motori di query.

Le caratteristiche principali dei cataloghi includono le seguenti:

  • Associazione di archiviazione: la relazione tra un catalogo e l'archiviazione sottostante dipende dal tipo di catalogo configurato.
  • Replica regionale: la regione di un catalogo corrisponde automaticamente alla regione del bucket sottostante.
  • Delega dell'accesso: gli amministratori possono abilitare la distribuzione delle credenziali nel catalogo per delegare l'accesso, consentendo la generazione automatica di credenziali di breve durata con ambito ridotto anziché concedere agli utenti le autorizzazioni dirette per il bucket.

Spazio dei nomi

Uno spazio dei nomi è un gruppo logico di tabelle all'interno di un catalogo, che funziona in modo simile a un database, uno schema o un set di dati BigQuery. Fornisce una struttura per organizzare e gestire i controlli di accesso per le tabelle.

Le caratteristiche principali degli spazi dei nomi includono le seguenti:

  • Regionalità: quando crei uno spazio dei nomi, questo utilizza automaticamente la stessa regione del catalogo principale.
  • Flessibilità della località: le opzioni per specificare le località personalizzate dello spazio dei nomi sono determinate dal tipo di data warehouse del catalogo.
  • Limitazioni di nidificazione: gli spazi dei nomi nidificati (sottospazi dei nomi) non sono supportati.
  • Limiti di sicurezza: puoi concedere ruoli IAM a livello di spazio dei nomi per gestire l'accesso a tutte le tabelle contenute al suo interno.

Tabelle

Quando crei con Lakehouse di Google Cloud, puoi scegliere tra i seguenti tipi di tabelle:

Supportati dal catalogo di runtime Lakehouse

Consigliati

  • Tabelle Apache Iceberg: tabelle Apache Iceberg create da motori open source e archiviate in Cloud Storage. Questi offrono compatibilità e gestione aperte tramite l'endpoint REST del catalogo di runtime Lakehouse. Per garantire che non esistano due tabelle nella stessa località, i percorsi delle tabelle personalizzate devono essere nidificati nel percorso dello spazio dei nomi principale e le località delle tabelle risultanti ricevono automaticamente un suffisso di stringa casuale per evitare conflitti.

    Formati di tabella supportati

    Sono supportate le tabelle Apache Iceberg V2 (GA) e V3 (anteprima). Le tabelle Iceberg V1 non sono supportate. Prima di utilizzare le tabelle V1 esistenti con Lakehouse, devi eseguire l'upgrade a una versione supportata. Per ulteriori informazioni, vedi Eseguire l'upgrade delle tabelle Iceberg V1 a V2.

Supportati da BigQuery

  • Tabelle Apache Iceberg: tabelle Apache Iceberg create e gestite da BigQuery. I metadati di queste tabelle vengono archiviati nel catalogo BigQuery, mentre i dati delle tabelle e i metadati fisici vengono archiviati in Cloud Storage.
  • Tabelle native: tabelle completamente gestite da BigQuery che possono essere connesse al catalogo di runtime Lakehouse per consentirti di interagire con i motori open source.
  • Tabelle esterne: tabelle esterne al catalogo di runtime Lakehouse in cui i dati e i metadati sono autogestiti. Questi supportano l'accesso delegato tramite connessioni per i dati archiviati in Cloud Storage, Amazon S3 o Azure Blob Storage.

Per un confronto dettagliato di queste opzioni, vedi Informazioni sui tipi e sulle funzionalità delle tabelle.

Sequenza di elaborazione delle query

Quando invii una query a una tabella Apache Iceberg gestita da Lakehouse, la richiesta segue un percorso specifico per applicare i criteri e recuperare i metadati prima dell'elaborazione dei dati.

  1. Invio: invii una query SQL a un motore compatibile come Apache Spark, Trino o BigQuery.
  2. Richiesta di metadati: il motore richiede i metadati della tabella dal catalogo di runtime Lakehouse per identificare la tabella e la relativa posizione dei metadati.
  3. Autorizzazione: se supportato dall'endpoint che stai utilizzando, il catalogo convalida la richiesta in base a Identity and Access Management (IAM) e ai criteri di sicurezza granulari.
  4. Risposta dei metadati: il catalogo restituisce i metadati. Se la distribuzione delle credenziali è abilitata, fornisce anche un token di breve durata per facilitare l'accesso sicuro all'archiviazione.
  5. Recupero dei dati: il motore utilizza i metadati e il token facoltativo per leggere i file di dati direttamente da Cloud Storage.
  6. Esecuzione: il motore elabora i dati e restituisce i risultati.

Best practice

Quando progetti e gestisci un data lakehouse su Google Cloud, tieni presente le seguenti best practice:

  • Adotta un'architettura medallion: struttura il data warehouse in livelli logici progressivi (bronzo per l'importazione non elaborata, argento per i dati puliti e conformi e oro per le aggregazioni curate a livello aziendale). Utilizza BigQuery per il livello di consumo oro per massimizzare le prestazioni e la concorrenza delle query.
  • Utilizza i modelli di sessione per i workload interattivi: per l'analisi esplorativa e la creazione di notebook, utilizza i modelli di sessione per standardizzare le configurazioni dell'ambiente tra i team di sviluppo e ridurre la configurazione ripetitiva.
  • Assegna identificatori batch personalizzati: quando invii workload batch Apache Spark serverless non interattivi, assegna nomi di batch e job personalizzati. In questo modo migliora l'osservabilità, che ti aiuta a filtrare e monitorare le esecuzioni dei job in Cloud Logging e nella Google Cloud console.
  • Abilita la registrazione di diagnostica: per le pipeline di data engineering complesse, abilita i bundle di diagnostica e contribuisci a garantire che i log dei driver e degli executor vengano conservati per facilitare la risoluzione dei problemi e la gestibilità.

Passaggi successivi