Come funziona Lakehouse

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

Architettura

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

  • Archiviazione:l'archiviazione Cloud Storage e BigQuery funge da livello di archiviazione, con Apache Iceberg come formato di tabella aperto consigliato per l'archiviazione interoperabile e ad alte prestazioni in Cloud Storage.

  • Catalogo: il catalogo runtime Lakehouse fornisce un'unica fonte di riferimento per la gestione dei metadati. Centralizza il rilevamento dei metadati in più motori utilizzando varie opzioni di compatibilità, ad esempio l'endpoint del catalogo REST di Apache Iceberg. Le registrazioni delle tabelle nel catalogo registrano automaticamente le voci nel catalogo delle conoscenze dei metadati aziendali.

  • Motore di query:BigQuery e i motori open source, tra cui Apache Spark, Apache Flink e Trino, interagiscono perfettamente connettendosi al catalogo runtime lakehouse. I motori di calcolo come Managed Service for Apache Spark sfruttano Apache Spark open source con ottimizzazioni dell'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 analisi dei dati:motori e strumenti integrati forniscono più percorsi per l'importazione e l'analisi dei dati, garantendo 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 delle risorse e connettere i motori di query al catalogo, utilizza endpoint specifici, come descritto di seguito.

  1. Catalogo runtime Lakehouse: la risorsa di servizio regionale di primo livello in Google Cloud che ospita i tuoi 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 di Apache Iceberg.
  2. Catalogo: un contenitore logico all'interno del servizio di catalogo runtime. Nella struttura di denominazione Progetto/Catalogo/Spazio dei nomi/Tabella (P.C.N.T), questo rappresenta l'istanza del catalogo specifica che stai interrogando.
  3. Spazio dei nomi: un raggruppamento logico di tabelle all'interno di un catalogo. Per gli utenti che hanno familiarità con 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 Apache Iceberg.

Endpoint supportati

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

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

  • Catalogo Apache Iceberg personalizzato per l'endpoint BigQuery:consente ai motori di interoperare 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 compatibilità per i workload open source che dipendono dall'interfaccia del metastore Apache Hive (HMS). In questo modo puoi eseguire 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 contenitore radice che ospita le singole istanze del catalogo, centralizzando l'individuazione dei metadati in motori di query diversi.

Per un'analisi più approfondita del servizio metastore, incluse le funzionalità chiave, i motori supportati, la configurazione degli endpoint e le limitazioni, vedi Informazioni sul catalogo del runtime Lakehouse.

Catalogo

Un catalogo è un contenitore metastore logico supportato da un singolo bucket warehouse Cloud Storage. Nella struttura di denominazione Project.Catalog.Namespace.Table (P.C.N.T), il catalogo rappresenta l'istanza metastore univoca che collega i metadati della tabella aperta ai motori di query.

Le caratteristiche principali dei cataloghi includono:

  • Associazione di spazio di archiviazione:puoi associare un solo catalogo a un singolo bucket Cloud Storage.
  • Replica regionale:la regione di un catalogo corrisponde automaticamente a quella del bucket Cloud Storage sottostante.
  • Delega dell'accesso:gli amministratori possono attivare la distribuzione delle credenziali nel catalogo per delegare l'accesso, consentendo la generazione automatica di credenziali di breve durata e con ambito ridotto anziché concedere agli utenti autorizzazioni dirette per i 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 dell'accesso per le tabelle.

Le caratteristiche principali degli spazi dei nomi includono:

  • Regionalità: quando crei uno spazio dei nomi, questo utilizza automaticamente la stessa regione del catalogo principale.
  • Limitazioni di nidificazione: gli spazi dei nomi nidificati (spazi dei nomi secondari) non sono supportati.
  • Confini 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 la 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. Questi offrono compatibilità e gestione aperte tramite l'endpoint REST del catalogo runtime Lakehouse.

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 consentire l'interoperabilità con motori open source.
  • Tabelle esterne: tabelle al di fuori del catalogo di runtime di Lakehouse in cui dati e 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 Panoramica della tabella.

Sequenza di elaborazione delle query

Quando invii una query alla tabella Lakehouse di Google Cloud, la richiesta segue un percorso specifico per applicare i criteri e recuperare i metadati prima che i dati vengano elaborati.

  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 posizione dei relativi metadati.
  3. Autorizzazione:se supportata 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 è attivata, fornisce anche un token di breve durata per facilitare l'accesso sicuro all'archivio.
  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, considera le seguenti best practice:

  • Adotta un'architettura medallion:struttura il data warehouse in livelli logici progressivi (bronze per l'importazione non elaborata, silver per i dati puliti e conformi e gold per gli aggregati a livello aziendale curati). Utilizza BigQuery per il livello di consumo gold 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 nei vari 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. Ciò migliora l'osservabilità, semplificando il filtraggio e il monitoraggio delle esecuzioni dei job in Cloud Logging e nella console Google Cloud .
  • Attiva il logging diagnostico:per le pipeline di data engineering complesse, attiva i bundle diagnostici e assicurati che i log di driver ed executor vengano conservati per semplificare la risoluzione dei problemi e la compatibilità.

Passaggi successivi