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: l'archiviazione di Cloud Storage e BigQuery funge da livello di archiviazione, con Apache Iceberg come formato di tabella aperta consigliato per l'archiviazione interoperabile e ad alte prestazioni in Cloud Storage.

  • Catalogo: il catalogo 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 catalogo di conoscenza 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 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 politiche di sicurezza, tracciabilità e governance centralizzate in tutta la lakehouse.

  • Strumenti di scrittura e analisi dei dati: i motori e gli strumenti integrati forniscono più percorsi per l'importazione 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 fisici. 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 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 container logico all'interno del servizio di catalogo runtime. Nella struttura di denominazione Progetto/Catalogo/Spazio dei nomi/Tabella (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 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 (anteprima): fornisce 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 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 disparati.

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, vedi Informazioni sul catalogo runtime Lakehouse.

Catalogo

Un catalogo è un container di metastore logico supportato dalle posizioni del 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 autorizzazioni dirette per il bucket.

Spazio dei nomi

Uno spazio dei nomi è un raggruppamento 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à degli spazi dei nomi personalizzati sono determinate dal tipo di 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:

Supportato dal catalogo runtime Lakehouse

Consigliati

  • Tabelle Apache Iceberg: tabelle Apache Iceberg create da motori open source e archiviate in Cloud Storage. Queste offrono compatibilità e gestione open tramite l'endpoint REST del catalogo runtime Lakehouse. Per garantire che due tabelle non occupino la stessa posizione, i percorsi delle tabelle personalizzate devono essere nidificati nel percorso dello spazio dei nomi principale e le posizioni 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.

Supportato da BigQuery

  • Tabelle Apache Iceberg: tabelle Apache Iceberg create e gestite da BigQuery. I metadati di queste tabelle sono archiviati nel catalogo BigQuery, mentre i dati delle tabelle e i metadati fisici sono archiviati in Cloud Storage.
  • Tabelle native: tabelle completamente gestite da BigQuery che possono essere connesse al catalogo runtime Lakehouse per consentirti di interagire con i motori open source.
  • Tabelle esterne: tabelle esterne al catalogo 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 le policy 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 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 alle policy 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 a livello aziendale curate). 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 diagnostica: per le pipeline di data engineering complesse, abilita i bundle di diagnostica e assicurati che i log dei driver e degli executor vengano conservati per facilitare la risoluzione dei problemi e la gestibilità.

Passaggi successivi