Concetti di acquisizione di Zerobus

Questa pagina descrive i concetti fondamentali di Zerobus Ingest in Lakeflow Connect: come funziona il servizio, i suoi stream, server e client, e i tipi di dati che supporta.

Passa a un concetto:

• Come funziona Zerobus Ingest: il flusso end-to-end, dal produttore alla tabella interrogabile.
• Server: di cosa è responsabile il servizio Zerobus Ingest.
• Cliente: di cosa è responsabile il tuo produttore.
• Stream: la connessione che il tuo client apre per ingerire dati.
• Come scala Zerobus Ingest: perché scala senza pianificazione della capacità.
• Requisiti del tavolo: cosa devono soddisfare il tavolo di destinazione e lo spazio di lavoro.
• Limitazioni: tipi di tabelle non supportati, operazioni di tabella e ordinamento cross-stream.
• Tipi di dati supportati: la mappatura di tipo Delta-a-Protobuf.

Come funziona Zerobus Ingest

Un produttore di dati si collega innanzitutto a un'API Zerobus Ingest e specifica una tabella Delta di destinazione, costruisce un messaggio conforme al relativo schema e quindi invia il messaggio. Il servizio rende i dati durevoli e, per interfacce che forniscono confermi di durabilità, riconosce il messaggio del cliente. Successivamente materializza i dati nella tabella Delta, in modo ottimizzato, come passaggio separato. Un riconoscimento della durabilità conferma la durabilità, non la questionabilità. Vedi Comunicazione asincrona per capire come funziona e cosa significa per il tuo cliente.

Zerobus Ingest è un servizio serverless che scala elasticamente con il tuo carico di lavoro. Per informazioni su come viene scalato, vedi Come viene scalato Zerobus Ingest qui sotto.

Questa sezione copre anche i modi in cui ti connetti a Zerobus Ingest e le forme che i tuoi dati possono assumere:

• Protocolli API: I protocolli API, gRPC con SDK, REST, OpenTelemetry, MQTT e API compatibili con Kafka, e quando utilizzare ciascuno.
• Tipi di messaggio: i formati di registro, JSON, Protocol Buffer (protobuf) e Apache Arrow, e quando utilizzare ciascuno.

Server

Il servizio Inserimento Zerobus non crea o modifica automaticamente le tabelle. Gli utenti devono creare autonomamente la tabella. Le tabelle e i relativi schemi sono le origini autorevoli per le aspettative dei dati in ingresso.

Il server Zerobus Ingest accetta i dati inviati dai client e verifica che corrispondano allo schema della tabella di destinazione. Se il record corrisponde, il server lo rende resistente e, quando l'interfaccia fornisce un riconoscimento di durabilità, lo riconosce al client. Materializzare il record nella tabella Delta, in modo che diventi interrogabile, avviene come passaggio separato poco dopo.

Le responsabilità del servizio includono:

• Validazione dello schema del messaggio rispetto alla tabella.
• Rendere il disco duraturo e, quando l'interfaccia fornisce un riconoscimento di durata, riconoscerlo al cliente. Il riconoscimento conferma la durata, anche se il record non è ancora consultabile.
• Materializzare i dati nella tabella di destinazione in modo tempestivo, momento in cui la tabella può essere interrogata. Per i dati di latenza, vedi Latenza.

Client

Un client si collega a Zerobus Ingest, invia record e, quando l'interfaccia lo supporta, conferma che siano durevoli. Quando usi un SDK Zerobus Ingest, l'SDK gestisce la maggior parte di questo per te, quindi aiuta a separare automaticamente ciò che configuri da ciò che fa l'SDK.

Configuri o implementi:

• Selezionare una tabella di destinazione.
• Apertura di un flusso verso il servizio Zerobus Ingest.
• Costruire un messaggio compatibile con lo schema e inviarlo.

L'SDK gestisce automaticamente:

• Conferme di ricezione dei messaggi L'SDK esegue il ciclo di conferma per te e mostra le conferme di durabilità tramite offset o un callback di conferma. Blocchi solo un record specifico quando la tua applicazione ne ha bisogno. Vedi Comunicazione asincrona.
• Ripristino. Di default, l'SDK si riconnette e riproduce i record non riconosciuti in caso di guasti transitori.
  • Puoi disattivare il recupero integrato e implementare il tuo meccanismo di recupero invece. Per informazioni su cosa attiva il ripristino, sulle opzioni di configurazione e sui modelli di ripristino personalizzati, vedere Modelli di ripristino e nuovo tentativo.

Non è necessario scrivere a mano conferma o logica di recupero quando usi un SDK. Per integrazioni personalizzate che non utilizzano un SDK, il repository Zerobus SDK è un riferimento per la struttura di integrazione e la gestione del recovery.

Flussi

Un flusso è una connessione diretta tra il tuo client e il server Zerobus Ingest, stabilita tramite una connessione gRPC persistente e bidirezionale. Gli SDK usano flussi per facilitare connessioni a velocità effettiva elevata e di lunga durata.

• I flussi vengono usati solo nell'API gRPC con gli SDK.
• Un flusso inserisce i dati in una singola tabella di destinazione.
• Apri flussi aggiuntivi per scrivere su tabelle diverse, o per scalare la velocità di un singolo client fino al limite del carico di lavoro richiesto.

I flussi sono anche l'unità di ordinamento (vedi Garanzie di ordinamento) e l'unità in base a cui Zerobus Ingest viene scalato (vedi Come viene scalato Zerobus Ingest).

Garanzie di ordine

L'ordine è garantito per ogni stream. I record vengono scritti nella tabella di destinazione nell'ordine in cui vengono accodati su un singolo flusso. Non esiste un ordine globale tra i flussi d'acqua. Da questo derivano diversi punti di progettazione:

• Se distribuisci i record su più flussi (ad esempio, round-robin), non c'è alcuna garanzia di ordinamento tra tali flussi.
• Se il tuo caso d'uso richiede un unico ordinamento totale tra molti producer o stream, imponi tale ordinamento nella tua applicazione (ad esempio, con un timestamp o un numero di sequenza su cui eseguire query) invece di affidarti all'ordine di ingestione.

Perché utilizzare lo streaming gRPC

Poiché la connessione gRPC di uno stream rimane aperta, il client evita il costo di configurazione per richiesta di un protocollo stateless e può spingere un flusso continuo e ad alto volume di record lungo un singolo canale. Questo è ciò che rende gli SDK il modo più efficiente, in termini di throughput, per acquisire i dati. Per le altre interfacce (REST, OpenTelemetry, MQTT e API compatibili con Kafka) e per sapere quando scegliere ciascuna, consulta Protocolli API.

Come scala l'ingestione di Zerobus

Zerobus Ingest è progettato per un'alta scalabilità e raggiunge quella scala senza doverti dover pianificare la capacità. Due scelte progettuali rendono possibile questo risultato:

• È serverless. Il servizio aggiunge e rimuove capacità automaticamente man mano che il carico cambia, quindi non si dimensionano i broker o non si provvedono partizioni. Puoi aprire tanti flussi concorrenti e scrivere su quante tabelle il tuo carico di lavoro richiede.
• I flussi sono unità di partizionamento dinamico. Anziché un insieme fisso di partizioni che devono essere ripartizionate e ribilanciate per aumentare la capacità, i flussi possono essere aperti, chiusi e fatti ruotare. Ruotare i flussi permette al servizio di ribilanciare capacità e risorse man mano che la domanda cambia, così scali aprendo più flussi e gestendo più produttori mentre il servizio assorbe il resto.

Il risultato pratico è che un client "hello world" e un carico di lavoro su scala petabyte eseguono essenzialmente lo stesso codice. La differenza sta nel numero di produttori e stream che gestisci. Questo design ha sostenuto l'ingestione di oltre 1 trilione di record in una singola tabella Delta. Per il contesto tecnico, vedi il post sul blog Ingerire la Via Lattea: Petabyte-Scale con Zerobus Gestest .

Requisiti della tabella

Zerobus Ingest scrive su una tabella Delta che crei e possiedi. Il tavolo e lo spazio di lavoro target devono soddisfare questi requisiti:

• La tabella target deve essere una tabella Delta gestita o una tabella streaming.
• I nomi delle tabelle devono utilizzare solo lettere ASCII, cifre e caratteri di sottolineatura.
• Lo spazio di lavoro e la tabella target devono essere entrambi in una delle regioni supportate.

Per come i record vengono convalidati rispetto allo schema della tabella, vedi Gestione dello schema. Per le caratteristiche delle tabelle come partizionamento e clustering liquido, vedi caratteristiche della tabella Delta. Per tipi di tabelle e operazioni non supportate, vedi Limitazioni.

Limitazioni

Zerobus Ingest presenta le seguenti limitazioni:

• Zerobus Ingest non scrive su tabelle o viste esterne.
• Zerobus Ingest non scrive in uno storage protetto tramite un endpoint privato.
• Zerobus Ingest non crea tabelle target né cambia il loro schema. Crei la tabella ed evolvi il suo schema. Vedi Evoluzione dello schema.
• Zerobus Ingest non supporta la ricreazione di una tabella target.
• Zerobus Ingest non supporta la ridenominazione o la sostituzione di una tabella target mentre l'ingestione è attiva. Vedi Rinomina o sostituisci una tabella target.
• Zerobus Ingest non supporta nomi di tabella che contengano caratteri diversi da lettere ASCII, cifre e trattini bassi.
• Zerobus Ingest non garantisce l'ordine tra i flussi. L'ordine è garantito solo all'interno di un singolo stream. Vedi garanzie di ordinamento.

Per limiti numerici come throughput, dimensione del record e fan-out delle partizioni, vedi Zerobus Ingest quotas.

Rinomina o sostituisci una tabella target

Non rinominare, rimuovere e ricreare, o sostituire una tabella target con un altro oggetto, come una vista, mentre i flussi scrivono su di essa. Zerobus Ingest non può scrivere i dati bufferizzati in una tabella che è stata rinominata o sostituita, quindi i flussi interessati cessano di avanzare e i record non ancora riconosciuti non possono essere scritti nella tabella. I dati che rimangono non svuotati vengono cancellati dopo il periodo di conservazione dei dati in buffer .

Le modifiche allo schema, come l'aggiunta di una colonna con ALTER TABLE, sono supportate. Vedi Evoluzione dello schema.

Per rinominare o migrare una tabella target in sicurezza:

1. Ferma i tuoi produttori, poi svuota e chiudi ogni stream che scrive sulla tabella. Vedi svuotamento e chiusura corretta.
2. Conferma che i registri più recenti compaiano nella tabella.
3. Rinomina o migra la tabella.
4. Concedi al service principal che acquisisce i dati USE CATALOG, USE SCHEMA, SELECT e MODIFY i permessi sulla nuova tabella. Vedi Crea un principio di servizio e concede permessi.
5. Aggiorna i tuoi produttori per usare il nuovo nome della tabella, poi apri nuovi stream. Se i tuoi produttori richiedono token OAuth con scope su una tabella, chiedili per la nuova tabella.

Tipi di dati supportati

La tabella seguente illustra i tipi Delta supportati e i tipi Protobuf corrispondenti per l'inserimento.

Avro types

Quando si ingeriscono record in formato Avro, Zerobus Ingest decodifica ogni record rispetto allo schema writer Avro che fornisci e lo converte nei tipi della tabella Delta di destinazione. La tabella seguente mostra come i tipi Avro si mappano ai tipi Delta.

Questa mappatura segue le convenzioni delle sorgenti dati Spark Avro. Per il sistema di tipi Avro stesso, vedi la specifica Apache Avro.

TIMESTAMP le colonne sono scritte come istanti UTC. Avro non ha un tipo intero a 8 o 16 bit, quindi le colonne TINYINT e SMALLINT non possono essere usate come destinazione in Avro. Avro inoltre non può scrivere sulle colonne VARIANT, VOID, INTERVAL, GEOMETRY o GEOGRAPHY. Uno schema che fa riferimento a uno di questi viene rifiutato quando viene creato il flusso.

Gli schemi writer Avro devono anche dichiarare ogni tipo in linea; i riferimenti a tipi nominati non sono supportati. Vedi Avro.