Comprendere la terminologia di base di Lakehouse senza confini ti aiuta a valutare le architetture di lakehouse e a configurare cataloghi, tabelle, motori di query e governance su Google Cloud. Ogni voce definisce un concetto chiave utilizzato nella documentazione di Lakehouse e rimanda a guide dettagliate. Per una visualizzazione end-to-end di come questi componenti si integrano, consulta Come funziona Lakehouse senza confini.
Nozioni di base su Lakehouse
I seguenti concetti costituiscono la base dell'architettura Lakehouse di Google Cloud.
Data lakehouse
Una data lakehouse combina i risparmi sui costi e la flessibilità di un data lake con la gestione dei dati e le prestazioni di un data warehouse. Ti consente di archiviare i dati in formati aperti su Cloud Storage e di utilizzare le funzionalità di BigQuery, come controlli di sicurezza precisi e query rapide.
Architettura medallion
Un pattern di progettazione comune in una data lakehouse è l'architettura medallion, che organizza logicamente i dati in livelli progressivi di struttura e qualità:
- Livello Bronze (non elaborato): importa e archivia i dati non elaborati in formati aperti come Apache Iceberg su Cloud Storage.
- Livello silver (pulito): pulisce, filtra e arricchisce i dati non elaborati in tabelle standardizzate.
- Livello gold (curato): fornisce tabelle a livello aziendale completamente curate e aggregate. BigQuery viene spesso utilizzato per fornire il livello gold per l'utilizzo, la generazione di report e l'analisi ad alte prestazioni.
Interoperabilità aperta
L'interoperabilità aperta è la capacità di più sistemi analitici e transazionali, come BigQuery, Apache Spark, Apache Flink e Trino, di operare su una singola copia di dati in formati aperti come Apache Iceberg. In questo modo non è necessario duplicare i dati e si ottiene una visualizzazione coerente dei dati tra gli strumenti.
Catalogo di runtime Lakehouse
Il catalogo di runtime Lakehouse è un servizio di metadati centralizzato e serverless che funge da Single Source Of Truth per il Lakehouse di Google Cloud. Consente a più motori, come Apache Spark, Apache Flink, Trino e BigQuery, di rilevare ed eseguire query sulle stesse tabelle contemporaneamente. I motori si connettono tramite gli endpoint del catalogo. Per saperne di più, consulta Informazioni sul catalogo di runtime Lakehouse.
Gerarchia delle risorse
Il catalogo di runtime Lakehouse organizza i metadati in una gerarchia che si allinea agli standard Apache Iceberg e mappa le identità logiche ai percorsi di archiviazione fisica.
Catalogo
Un catalogo è il container logico di primo livello nel catalogo di runtime Lakehouse. Definisce dove possono essere archiviati i dati della tabella e quale regione gestisce i relativi metadati. Per saperne di più, consulta Crea un catalogo.
Tipi di catalogo
Quando crei un catalogo, scegli tra due modelli di archiviazione:
- Catalogo con più bucket (consigliato): consente di assegnare un nome al catalogo in modo indipendente e di configurare una posizione di archiviazione predefinita (
default_location) e fino a 128 bucket Cloud Storage o sottopercorsi aggiuntivi inrestricted_locations. Quando configuri i motori di query client (come Spark o Trino), imposta il percorso del warehouse subl://projects/PROJECT_ID/catalogs/CATALOG_ID. - Catalogo con un singolo bucket: una configurazione legacy in cui il catalogo è bloccato su un singolo bucket Cloud Storage ed eredita il nome del bucket.
Quando configuri i motori di query client, imposta il percorso del warehouse su
gs://CLOUD_STORAGE_BUCKET_NAME.
Per saperne di più, consulta Cataloghi e località di archiviazione.
Spazio dei nomi
Uno 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. Gli spazi dei nomi ereditano la regione del catalogo padre e non supportano l'nidificazione.
Tabella
Una tabella è l'entità che punta ai dati in Cloud Storage. Per le tabelle Apache Iceberg, i metadati della tabella contengono lo schema, le informazioni di partizionamento e un puntatore allo stato attuale della tabella tramite un file metadata.json. Per i tipi di tabelle supportati da Lakehouse, consulta Tipi di tabelle.
Convenzione di denominazione P.C.N.T
La convenzione di denominazione P.C.N.T è la convenzione in quattro parti utilizzata per identificare ed eseguire query in modo univoco sulle tabelle nel catalogo di runtime di Lakehouse da BigQuery. Sta per Project.Catalog.Namespace.Table:
- Progetto: l'ID progetto Google Cloud .
- Catalogo: il nome del catalogo nel catalogo di runtime Lakehouse.
- Spazio dei nomi: il raggruppamento logico delle tabelle (simile a un set di dati).
- Tabella: il nome della tabella di dati.
Endpoint del catalogo
Un endpoint del catalogo è un'interfaccia di protocollo utilizzata dai motori di query per connettersi al catalogo di runtime Lakehouse. L'endpoint che utilizzi determina i formati di tabella e i motori con cui puoi lavorare.
Endpoint del catalogo REST Apache Iceberg
L'endpoint del catalogo REST Apache Iceberg implementa l'API Iceberg REST Catalog open standard. È l'endpoint consigliato per i nuovi workload e fornisce l'interoperabilità di lettura e scrittura tra i motori open source e BigQuery. Supporta cataloghi con più bucket, distribuzione delle credenziali e replica tra regioni (anteprima). Per saperne di più, consulta la panoramica degli endpoint del catalogo REST Apache Iceberg.
Endpoint del catalogo Apache Hive
L'endpoint del catalogo Apache Hive offre compatibilità per i workload open source che dipendono dall'interfaccia del metastore Apache Hive (HMS). Poiché il catalogo di runtime Lakehouse gestisce questo endpoint, puoi eseguire workload Apache Hive o Spark senza gestire un metastore Hive in hosting autonomo. L'endpoint gestisce tabelle Hive e Spark standard anziché tabelle Apache Iceberg e supporta le chiavi di crittografia gestite dal cliente (CMEK) per i dati in Cloud Storage. Per saperne di più, consulta Informazioni sull'endpoint del catalogo Hive.
Catalogo Apache Iceberg personalizzato per BigQuery
Il catalogo Apache Iceberg personalizzato per BigQuery è un'integrazione precedente che utilizza un plug-in del catalogo (BigQueryMetastoreCatalog) per consentire ai motori open source di archiviare le definizioni delle tabelle Apache Iceberg in BigQuery. Gli spazi dei nomi vengono mappati ai set di dati BigQuery, quindi puoi eseguire query su queste tabelle con la sintassi standard dei set di dati BigQuery. Per i nuovi workload, utilizza l'endpoint del catalogo REST Apache Iceberg. Per saperne di più, consulta Catalogo Apache Iceberg personalizzato per BigQuery.
Tipi di tabella
Il lakehouse di Google Cloud supporta diversi tipi di tabelle, a seconda del motore utilizzato per gestire i dati e dell'endpoint del catalogo che utilizzi. Per un confronto dettagliato, consulta Confronta i tipi di tabelle.
Tabelle Apache Iceberg nel catalogo di runtime Lakehouse
Si tratta di tabelle Apache Iceberg gestite e fornite dal catalogo di runtime Lakehouse tramite l'endpoint del catalogo REST Apache Iceberg, con i dati archiviati in Cloud Storage. I motori open source hanno accesso in lettura e scrittura a queste tabelle. BigQuery ha accesso in lettura e in scrittura (anteprima) quando attivi BigQuery DML. Questa è l'opzione consigliata per la maggior parte dei workload di lakehouse aperti. Per saperne di più, consulta Gestisci le tabelle Apache Iceberg.
Tabelle Apache Hive
Si tratta di tabelle Apache Hive e Spark standard, in formati come Parquet, ORC, Avro e Delta Lake, gestite dal catalogo di runtime Lakehouse tramite l'endpoint del catalogo Apache Hive. I motori open source hanno accesso in lettura e scrittura, mentre BigQuery ha accesso di sola lettura. Per utilizzare le tabelle Delta Lake, devi crearle con un motore compatibile con Delta, come Apache Spark, e registrarle nel metastore. Per ulteriori informazioni, consulta Formati e tipi di archiviazione supportati.
Tabelle BigQuery
Queste tabelle sono gestite con BigQuery.
Tabelle gestite Apache Iceberg
Si tratta di tabelle Apache Iceberg che crei da BigQuery e archivi in Cloud Storage. BigQuery gestisce tutto il layout e l'ottimizzazione dei dati. Sebbene più motori possano leggere queste tabelle, BigQuery è l'unico motore che può scrivere direttamente al loro interno. Queste tabelle sono distinte dalle tabelle Apache Iceberg nel catalogo di runtime Lakehouse. Per saperne di più, consulta Tabelle gestite di Apache Iceberg.
Tabelle native
Queste tabelle sono gestite da BigQuery e archiviano i dati nello spazio di archiviazione di BigQuery. Puoi collegare queste tabelle al catalogo di runtime Lakehouse.
Tabelle esterne
Le tabelle esterne si trovano al di fuori del catalogo di runtime Lakehouse. I dati e i metadati sono autogestiti in uno spazio di archiviazione come Cloud Storage, Amazon S3 o Azure Blob Storage e BigQuery vi accede tramite connessioni. BigQuery può solo leggere da queste tabelle.
Funzionalità e opzioni della tabella
Le seguenti funzionalità si applicano alle tabelle Apache Iceberg nel catalogo di runtime Lakehouse, se non diversamente specificato.
Versioni delle tabelle Apache Iceberg
Il catalogo di runtime Lakehouse supporta le tabelle Apache Iceberg V2 e V3 (anteprima). Le tabelle V3 supportano i vettori di eliminazione binari, che consentono di eliminare righe specifiche senza riscrivere interi file di dati. Le tabelle Iceberg V1 non sono supportate; devi prima eseguire l'upgrade alla versione V2. Per ulteriori informazioni, consulta Utilizza i vettori di eliminazione binari nelle tabelle Iceberg V3.
Evoluzione della tabella
L'evoluzione della tabella ti consente di modificare lo schema o la specifica di partizione di una tabella nel tempo senza riscrivere i dati della tabella o ricrearla. Le tabelle Apache Iceberg nel catalogo di runtime Lakehouse supportano anche i nomi di colonna flessibili per impostazione predefinita, pertanto i nomi di colonna possono contenere caratteri come spazi e caratteri internazionali.
Viaggio nel tempo
La funzionalità di viaggio nel tempo ti consente di eseguire query sui dati di una tabella così come esistevano in un momento specifico o in un ID snapshot. Questo è utile per l'audit, la riproduzione di esperimenti o il ripristino dei dati dopo un'eliminazione accidentale. I motori open source possono eseguire il viaggio nel tempo entro il periodo di conservazione configurato nelle proprietà della tabella, mentre il viaggio nel tempo di BigQuery è limitato a sette giorni.
Opzioni tabella
Le opzioni della tabella sono proprietà della tabella che attivano le funzionalità gestite da Google per le singole tabelle Apache Iceberg. Per saperne di più, consulta Configura le opzioni della tabella.
DML di BigQuery
BigQuery DML è in
anteprima. Quando imposti la proprietà della tabella gcp.biglake.bigquery-dml.enabled, BigQuery può creare, alterare e modificare la tabella utilizzando le istruzioni DDL e DML di GoogleSQL (INSERT, UPDATE, DELETE e MERGE), mentre i motori open source continuano a leggere e scrivere la stessa tabella.
Gestione dei tavoli
La gestione delle tabelle (anteprima) automatizza la manutenzione dello spazio di archiviazione per le tabelle Apache Iceberg. Quando imposti la proprietà della tabella gcp.biglake.table-management.enabled, Lakehouse esegue la compattazione in background (coalesce), la scadenza degli snapshot e la garbage collection per mantenere le prestazioni delle query e l'efficienza dello spazio di archiviazione. La gestione delle tabelle richiede che il catalogo utilizzi la distribuzione delle credenziali. Per saperne di più, consulta Attiva la gestione dei tavoli.
Cronologia delle modifiche
La cronologia delle modifiche consente di utilizzare la funzione con valori di tabella APPENDS di GoogleSQL per monitorare le righe aggiunte alle tabelle gestite di Apache Iceberg in un intervallo di tempo specificato. Puoi utilizzarlo per gestire in modo incrementale le repliche, controllare le aggiunte di dati o attivare pipeline downstream senza scansioni complete delle tabelle. Per saperne di più, consulta Utilizza la cronologia delle modifiche.
Memorizzazione nella cache dei metadati
La memorizzazione nella cache dei metadati accelera le prestazioni delle query per le tabelle esterne di BigQuery. Archivia una copia dei metadati della tabella nello spazio di archiviazione di BigQuery, riducendo la necessità di leggere i file di metadati da Cloud Storage durante l'esecuzione delle query.
Importazione e migrazione dei dati
Lakehouse offre diversi percorsi per caricare i dati nelle tabelle Apache Iceberg e spostare i metadati dai metastore esistenti.
Importazioni di tabelle in batch
I modelli di Dataflow Job Builder ti consentono di importare tabelle Apache Iceberg, Delta Lake e file Parquet esistenti in tabelle Apache Iceberg gestite da Lakehouse senza scrivere codice.
Acquisizione di flussi di dati
Puoi trasmettere dati in flussi alle tabelle Apache Iceberg utilizzando motori open source (come Spark o Kafka), Dataflow o l'API BigQuery Storage Write (gRPC), che fornisce scritture transazionali exactly-once. Puoi anche scrivere l'output delle query continue di BigQuery direttamente nelle tabelle gestite di Apache Iceberg.
Change Data Capture (CDC)
L'importazione CDC mantiene le tabelle Apache Iceberg sincronizzate con i sistemi di origine applicando inserimenti, aggiornamenti ed eliminazioni anziché ricaricare le tabelle complete. Le tabelle gestite di Apache Iceberg supportano l'importazione CDC di BigQuery (anteprima) e puoi utilizzare Dataflow per eseguire la migrazione dei log CDC dalle tabelle Apache Iceberg e Delta Lake (anteprima).
Migrazione del metastore
La migrazione del metastore sposta i metadati delle tabelle dai metastore esistenti al catalogo di runtime Lakehouse senza copiare i file di dati. Puoi eseguire una migrazione o un dry run una tantum da Dataproc Metastore all'endpoint del catalogo REST Apache Iceberg o all'endpoint del catalogo Apache Hive oppure eseguire la migrazione da metastore esterni come il metastore Hive (anteprima).
Accesso ai dati cross-cloud
L'accesso ai dati cross-cloud ti consente di eseguire query sui dati archiviati in altri cloud e piattaforme SaaS direttamente da Google Cloud, senza migrare i file o creare pipeline ETL. Per saperne di più, consulta Informazioni sull'accesso ai dati cross-cloud.
Catalogo federato
Un catalogo federato è un catalogo nel catalogo di runtime Lakehouse che si connette a un provider di cataloghi remoto ed espone le sue tabelle tramite l'endpoint del catalogo REST Apache Iceberg. Puoi quindi eseguire query su queste tabelle con BigQuery, Managed Service for Apache Spark o Apache Spark. I provider di cataloghi remoti supportati includono Databricks Unity Catalog, AWS Glue Data Catalog, Snowflake Horizon Catalog, Workday Data Lake e SAP Business Data Cloud (SAP BDC). Per saperne di più, consulta Esegui query sui dati remoti.
Aggiornamento dei metadati in background
L'aggiornamento dei metadati in background è il processo mediante il quale un catalogo federato sincronizza periodicamente i metadati dello spazio dei nomi e della tabella dal catalogo remoto, in base a un intervallo di aggiornamento. Lakehouse si autentica nel catalogo remoto utilizzando la federazione dei token OIDC o le credenziali archiviate in Secret Manager.
Trasporto cross-cloud
L'accesso ai dati cross-cloud separa l'aggiornamento dei metadati in background dal trasporto dei dati delle query. Puoi instradare uno o entrambi i tipi di traffico tramite internet pubblico o privatamente tramite Cross-Cloud Interconnect per soddisfare i requisiti di sicurezza e di costo. Per limitare l'esfiltrazione di dati, puoi anche proteggere gli endpoint del catalogo federato con i Controlli di servizio VPC.
Memorizzazione nella cache cross-cloud
La memorizzazione nella cache cross-cloud archivia i blocchi di file letti dallo spazio di archiviazione di oggetti remoto localmente nella regione Google Cloud in cui vengono eseguite le query, in modo che le query ripetute vengano lette dalla cache anziché dal cloud remoto. La memorizzazione nella cache aiuta a ridurre i costi di traffico in uscita tra cloud ed è disabilitata per impostazione predefinita. Puoi attivarla su un catalogo federato o su una connessione cross-cloud BigQuery. Per saperne di più, consulta Memorizzazione nella cache intelligente.
Modalità di identità
La modalità di identità determina quale identità esegue le query su un catalogo remoto:
- Identità del servizio (predefinita): l'aggiornamento dei metadati in background e le query vengono eseguiti come account di servizio del catalogo.
- Federazione delle identità utente: le query vengono eseguite con l'identità dell'utente finale, il che consente al catalogo remoto di applicare le proprie autorizzazioni e attribuire gli audit log ai singoli utenti. Questa modalità è supportata per Databricks Unity Catalog.
Integrazione SAP BDC
L'integrazione di SAP BDC funziona in due direzioni. La federazione sincronizza le condivisioni SAP BDC in Lakehouse utilizzando il protocollo Delta Sharing in modo da poter eseguire query da BigQuery. La pubblicazione condivide le tabelle Apache Iceberg o i prodotti di dati di Knowledge Catalog con SAP BDC senza eseguire la migrazione dei dati. Per saperne di più, consulta Informazioni sull'integrazione di SAP BDC.
Set di dati pubblici
Borderless Lakehouse ospita set di dati pubblici forniti tramite l'endpoint del catalogo REST Apache Iceberg, fornendo l'accesso di sola lettura per l'esplorazione e il test senza gestire l'infrastruttura. Google paga per lo spazio di archiviazione e tu paghi solo per le query che esegui. Per saperne di più, consulta Set di dati pubblici.
Sicurezza e governance
Lakehouse combina Identity and Access Management (IAM), delega dell'accesso allo spazio di archiviazione e controlli di rete per proteggere il tuo lakehouse.
Controllo dell'accesso a livello di risorsa
Le policy IAM su cataloghi, spazi dei nomi e tabelle controllano chi può visualizzare e modificare le risorse Lakehouse. Per saperne di più, consulta Gestisci gli ACL di cataloghi, spazi dei nomi e tabelle e Ruoli e autorizzazioni.
Distribuzione delle credenziali
La distribuzione delle credenziali è un meccanismo di sicurezza che rafforza il controllo dell'accesso quando utilizzi il catalogo di runtime Lakehouse. Anziché concedere agli utenti autorizzazioni dirette per i bucket, l'endpoint del catalogo REST di Apache Iceberg vende credenziali di archiviazione con ambito ridotto e di breve durata con accesso limitato ai percorsi delle tabelle specifici richiesti da una query. La distribuzione delle credenziali è necessaria anche per la gestione delle tabelle. Per saperne di più, consulta Distribuzione delle credenziali.
Connessioni
Una connessione è una risorsa BigQuery che archivia le credenziali per accedere ai dati esterni. In Lakehouse di Google Cloud, le connessioni delegano l'accesso a Cloud Storage consentendo al service account della connessione di accedere al bucket di archiviazione per tuo conto.
Controlli di servizio VPC
I perimetri di servizio dei Controlli di servizio VPC aiutano a prevenire l'esfiltrazione di dati limitando l'accesso all'API Lakehouse (biglake.googleapis.com) e ai bucket Cloud Storage che archiviano i dati delle tabelle. Per saperne di più, consulta Utilizza i Controlli di servizio VPC con la distribuzione delle credenziali.
Endpoint regionali
Gli endpoint regionali limitano le richieste in modo che vengano elaborate solo se la risorsa del catalogo di destinazione esiste nella località specificata dall'endpoint, il che ti aiuta a soddisfare i requisiti di residenza dei dati. Per saperne di più, consulta Endpoint regionali.
Audit logging
Cloud Audit Logs registra le attività di amministrazione e di accesso ai dati sulle risorse Lakehouse. Per saperne di più, consulta Visualizza gli audit log.
Governance unificata
La governance unificata ti consente di definire e applicare centralmente le policy di sicurezza e gestione dei dati tramite l'integrazione con Knowledge Catalog. Quando registri le tabelle nel catalogo di runtime Lakehouse, il sistema registra automaticamente le voci corrispondenti in Knowledge Catalog, consentendo la ricerca e la scoperta, la derivazione dei dati, la profilazione dei dati e gli insight sui dati generati dall'AI (anteprima) tra i motori senza spostare o copiare i file.
Motori e strumenti di query
Il lakehouse di Google Cloud disaccoppia lo spazio di archiviazione dal computing, in modo che vari motori di analisi possano lavorare con le stesse tabelle aperte.
Motori open source
I motori open source si connettono al catalogo di runtime Lakehouse tramite l'endpoint del catalogo REST Apache Iceberg utilizzando la configurazione client standard di Apache Iceberg. Per la configurazione specifica del motore, consulta Apache Spark, Apache Flink e Trino. Puoi anche gestire le risorse Lakehouse con Terraform.
Managed Service for Apache Spark
Managed Service for Apache Spark (in precedenza Dataproc Serverless) fornisce un runtime completamente gestito per l'elaborazione di formati di tabelle aperte come Apache Iceberg. Supporta due modalità di esecuzione principali:
- Batch serverless: progettati per pipeline di trattamento dati automatizzate e non interattive e workload ETL. Questo modello di pagamento per esecuzione elimina la gestione dei cluster, rimuove la contesa delle risorse tra i job e automatizza la manutenzione dell'infrastruttura.
- Sessioni interattive serverless: progettate per l'analisi esplorativa dei dati, il data engineering e la sperimentazione di data science. Le sessioni interattive alimentano i notebook Apache Spark utilizzando Spark Connect o kernel Spark remoti, fornendo un ambiente di scalabilità automatica senza configurazione dell'infrastruttura.
Livelli di servizio
Quando esegui i workload Apache Spark su Managed Service for Apache Spark, puoi scegliere tra i livelli di servizio:
- Livello Standard: il livello di esecuzione predefinito adatto ai workload di elaborazione batch standard.
- Livello Premium: offre funzionalità avanzate, tra cui il supporto per sessioni di notebook interattivi serverless e funzionalità di accelerazione delle prestazioni come Lightning Engine.
Modelli di sessione
I template di sessione semplificano la configurazione delle sessioni interattive serverless.
Consentono agli amministratori di definire e rendere persistenti le impostazioni comuni dell'ambiente (come le proprietà del catalogo, le configurazioni di rete e le versioni di runtime), il che promuove la coerenza e riduce al minimo la configurazione ripetuta. Puoi creare e gestire i template di sessione utilizzando la console Google Cloud , l'interfaccia a riga di comando gcloud, l'API REST o Terraform.
analisi conversazionale
L'analisi conversazionale (anteprima) ti consente di eseguire query sulle tabelle nel catalogo di runtime di Lakehouse, incluse le origini cross-cloud, utilizzando prompt in linguaggio naturale in BigQuery.
Affidabilità
Il catalogo di runtime Lakehouse fornisce il ripristino di emergenza gestito per i cataloghi che utilizzano l'endpoint del catalogo REST Apache Iceberg (anteprima). Per saperne di più, consulta Informazioni sulla replica tra regioni e sul disaster recovery.
Replica tra regioni
La replica tra regioni copia i metadati del catalogo da una regione principale a una regione secondaria quando il catalogo utilizza un bucket Cloud Storage a due regioni o multiregionale, che mantiene il catalogo disponibile durante le interruzioni a livello di regione. Cloud Storage replica i dati della tabella sottostante.
Failover
Il failover cambia le regioni principale e secondaria di un catalogo e di tutti i suoi spazi dei nomi e tabelle. Un failover soft attende la sincronizzazione di tutti i dati prima che il nuovo database principale accetti le scritture, il che impedisce la perdita di dati ed è adatto ai test pianificati. Un failover forzato dà la priorità alla disponibilità e consente al nuovo database principale di subentrare anche se quello precedente non è raggiungibile.