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.
• Tipi di dati supportati: la mappatura di tipo Delta-a-Protobuf.

Come funziona Zerobus Ingest

Un produttore di dati apre prima uno stream verso l'API di Zerobus Ingest e specifica una tabella Delta target, costruisce un messaggio che corrisponde al suo schema e poi invia il messaggio attraverso il flusso aperto. Il servizio rende i dati durevoli e riconosce il messaggio del cliente. Successivamente materializza i dati nella tabella Delta, in modo ottimizzato, come passaggio separato. Il riconoscimento conferma la durabilità, non l'interrogabilità. 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 e OpenTelemetry, 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 duraturo e 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 record persistente e confermarlo al client. 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 i record e conferma che sono 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 e OpenTelemetry) e quando scegliere ciascuna, vedi 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:

• Zerobus Ingest scrive solo su tabelle Delta gestite. La scrittura nella risorsa di archiviazione predefinita non è supportata.
• Zerobus Ingest non scrive in uno storage protetto tramite un endpoint privato.
• Zerobus Ingest non supporta la ricreazione di una tabella target.
• I nomi delle tabelle supportano solo lettere, cifre e sottolinee ASCII.
• 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.

Tipi di dati supportati

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