Gestione dello schema

Questo approfondimento spiega come Zerobus Ingest in Lakeflow Connect convalida i record in arrivo in base allo schema della tabella Delta e come progettare lo schema per dati parziali o in evoluzione.

La tabella è il contratto

Lo schema della tabella Delta è il contratto di riferimento per ciò che Zerobus Ingest accetta. Zerobus Ingest verifica ogni record rispetto a quel contratto, ma sei tu a decidere quanto il contratto sia severo o permissivo. Lo stesso servizio può imporre uno schema rigido, accettare un sottoinsieme flessibile di colonne o catturare tutto ciò che non rientra, a seconda di come definisci la tua tabella.

• Zerobus Gestest blocca i dati. Convalida ogni record in base alla tabella di destinazione e respinge tutto ciò che non rientra in essa. Non indovina mai né lascia le colonne in silenzio.
• Definisci tu il contratto. Segnare colonne obbligatorie o nullabili, e aggiungere una colonna di salvataggio, è il modo in cui decidi cosa "si adatta".
• Zerobus Ingest non modifica mai la tua tabella. Non aggiunge colonne, non cambia tipi né evolve lo schema per adattarsi a un record. Evolvi ciò che Zerobus Ingest accetta evolvendo la tabella, non il contrario.

La sezione successiva mostra tre modi per modellare quel contratto, dal più accettante al più severo fino all'universale.

Come i record vengono abbinati alla tabella

Un record deve entrare nella tabella di destinazione: deve contenere, almeno, tutte le colonne non nullabili della tabella. Le colonne che sono nullabili nella tabella possono essere omesse dal record e sono scritte come NULL. L'omissione di una colonna che può contenere valori nulli è considerata una modifica non incompatibile, quindi puoi aggiungere colonne che possono contenere valori nulli a una tabella e continuare ad acquisire record meno recenti che non le includono.

Zerobus Ingest restituisce un errore quando un record non corrisponde alla tabella. Tra queste vi sono anche:

• Manca una colonna che non ammette valori null.
• Un nome di colonna che non esiste nella tabella Delta (a meno che tu non configuri una colonna di salvataggio).
• Una colonna il cui tipo non è compatibile con la tabella Delta. Per i tipi di dati Delta e Protobuf supportati, vedi Tipi di dati supportati.

Tre modi per modellare il contratto

Il modo in cui definisci la tabella determina quanto rigorosa o permissiva sia l'ingestione. I tre scenari seguenti vanno dal più permissivo al più rigoroso, fino a quello onnicomprensivo.

Scenario 1: Tutte le colonne opzionali (accettare un sottoinsieme)

Rendi ogni colonna nullabile. I produttori possono quindi inviare qualsiasi sottoinsieme delle colonne, e le colonne omesse sono scritte come NULL. I record che includono una colonna che la tabella non ha vengono comunque rifiutati.

CREATE TABLE main.default.air_quality (
  device_name STRING,
  temp INT,
  humidity INT);

• {"device_name": "sensor-1", "temp": 22, "humidity": 55}: accettato. Tutte le colonne presenti.
• {"device_name": "sensor-1"}: accettato.temp e humidity sono nullabili, quindi sono scritti come NULL.
• {"device_name": "sensor-1", "temp": 22, "region": "us-west"}: rifiutato.region non esiste nella tabella.

Scenario 2: Colonne obbligatorie (applicare campi specifici)

Segna le NOT NULL colonne per richiederle. Ogni record deve includere quelle colonne, altrimenti viene scartato. Questo è il limite rigoroso dello spettro: usarlo quando un campo deve essere sempre presente.

CREATE TABLE main.default.air_quality (
  device_name STRING NOT NULL,
  temp INT NOT NULL,
  humidity INT);

• {"device_name": "sensor-1", "temp": 22, "humidity": 55}: accettato. Tutte le colonne richieste sono presenti.
• {"device_name": "sensor-1", "temp": 22}: accettato.humidity è nullabile, quindi viene scritto come NULL.
• {"device_name": "sensor-1"}: rifiutato.temp non è nullabile ed è mancante.

Scenario 3: Colonna di soccorso (cattura tutto il resto)

Aggiungi una VARIANT colonna di salvataggio per catturare campi che non corrispondono allo schema, invece di rifiutare il record. I campi che corrispondono alla tabella vengono scritti sulle loro colonne come di consueto. Eventuali campi extra o non conformi sono raggruppati nella colonna di salvataggio come oggetto JSON. Questo è l'estremo più permissivo della gamma: i campi aggiuntivi e le incompatibilità di tipo nelle colonne nullable vengono rilevati invece di essere rifiutati. Un record viene comunque rifiutato se omette una colonna richiesta (non nullabile), perché la colonna di salvataggio non può fornire un valore richiesto dallo schema. La colonna di salvataggio è in Beta e attualmente supporta l'ingestione in formato JSON.

• {"device_name": "sensor-1", "temp": 22, "region": "us-west"}: accettato.region non esiste nella tabella, quindi viene registrato nella colonna di salvataggio invece di essere rifiutato.

Per come configurare una colonna di salvataggio e le regole esatte, vedi la colonna di salvataggio Zerobus.

Evoluzione dello schema

Zerobus Ingest non aggiorna automaticamente la tabella di destinazione. Quando la forma dei tuoi dati cambia, evolve prima la tabella (ad esempio, con ALTER TABLE), poi invia i record contro il nuovo schema.

Aggiungere una colonna nullabile è un cambiamento irrilevante: i produttori esistenti che non inviano la nuova colonna continuano a lavorare, e i loro record ne vengono pagati NULL . Questo ti consente di implementare in modo indipendente le modifiche allo schema e le modifiche ai producer.

Schema Protobuf

Quando si ingerisce con i Protocol Buffer (protobuf), la stessa regola di adattamento si applica alla definizione del messaggio protobuf: deve contenere almeno tutte le colonne non nullabili nella tabella Delta, e può omettere quelle nullabili.

Quanto segue si applica anche allo schema protobuf:

• Zerobus Ingest non supporta proto schemi con più di 2000 colonne.
• Zerobus Ingest supporta solo nomi di tabelle e colonne con lettere, cifre e sottolinee ASCII.
• Zerobus Ingest non supporta l’utilizzo di uno schema Proto diverso per le operazioni di "creazione del flusso" e di "acquisizione dei record".