Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questa pagina offre una panoramica di ciò che Zerobus Ingest a Lakeflow Connect offre. Ogni funzionalità è collegata alla documentazione completa.
- Endpoint sempre attivo: serverless, attivo di default, scala automaticamente.
- Metodi di autenticazione: come i client si autenticano, inclusi service principal OAuth e la federazione dei fornitori di identità esterni.
- Blocco dei messaggi: metodi di acquisizione e come confermarne la durabilità.
- Callback di conferma: gestiscono conferme ed errori in modo asincrono.
-
Caratteristiche della tabella Delta: partizionamento, clustering liquido e
VARIANTdati. - Colonna di salvataggio: cattura campi che non si adattano allo schema della tabella invece di rifiutarli.
- Posizione di riserva duratura: dove i dati arrivano se non possono essere pubblicati.
- Monitoraggio del tuo utilizzo: tabelle di sistema per uso e spesa.
Endpoint sempre attivo
Zerobus Ingest è un endpoint serverless attivato di default per gli spazi di lavoro nelle regioni supportate. Non c'è nulla da cui iniziare, né provvistare, né scalare. Dopo aver creato una tabella target e un'identità autorizzata, puoi iniziare a inviare dati e la capacità scala automaticamente. Per iniziare, vedi Usa Zerobus Ingest.
Metodi di autenticazione
Ogni client Zerobus si autentica con un token Azure Databricks OAuth di breve durata. Quando usi un SDK, l'SDK ottiene e aggiorna il token per te. Sulle altre interfacce, come l'API REST, ottieni tu stesso il token e lo fornisci con le tue richieste. Per i passaggi di configurazione e il codice, vedi Configurare autenticazione.
OAuth con un service principal (predefinito)
Autentica con un client ID e un segreto di un'entità servizio di Azure Databricks. Questo è il metodo predefinito. È adatto a carichi di lavoro che possono contenere un segreto di Azure Databricks.
Federazione con provider di identità esterno
Autentica con un token del tuo stesso fornitore di identità, come Microsoft Entra ID, invece di un segreto di Azure Databricks. Il token del provider di identità viene scambiato con un token Azure Databricks con scopo Zerobus utilizzando lo scambio token RFC 8693, quindi nessun segreto Azure Databricks di lunga durata viene memorizzato sul client.
La federazione supporta due modelli di identità:
- Federazione a livello di account: Non esiste alcuna entità servizio di Azure Databricks. La tua identità dal fornitore di identità viene sincronizzata nell'account Azure Databricks tramite la gestione automatica dell'identità e il client si autentica con quell'identità. Questo richiede una politica di federazione degli account che registri il tuo fornitore come emittente affidabile.
- Federazione delle identità dei carichi di lavoro: Usa un principale di servizio Azure Databricks che abbia un ID client e nessun segreto, con una policy di federazione allegata.
Microsoft Entra ID è l'esempio in queste pagine, ma lo stesso flusso federato funziona con altri provider di identità compatibili OpenID Connect (OIDC).
Confronta i metodi di autenticazione
| Metodo | Azure Databricks service principal | Azure Databricks client secret | Quando utilizzare |
|---|---|---|---|
| entità servizio OAuth | Yes | Yes | Il tuo client può custodire un segreto gestito da Azure Databricks. |
| Federazione a livello di account | No | No | La tua identità è gestita esclusivamente dal tuo provider, senza alcun service principal o segreto di Azure Databricks. |
| Federazione delle identità dei carichi di lavoro | Sì, senza credenziali | No | Vuoi un'identità di Azure Databricks service principal senza memorizzare un segreto. |
Annotazioni
Lo scambio automatico di token nell'SDK è disponibile nell'SDK Python 1.10.0 e successivi e nel Rust SDK 2.11.0 e superiori. Per i passaggi di configurazione e il codice, vedi Configurare autenticazione.
Caratteristiche della tabella Delta
Zerobus Ingest scrive nelle tabelle Delta gestite da Unity Catalog standard, quindi i dati ingeriti funzionano con le capacità delle tabelle Delta. Per i requisiti che una tabella target deve soddisfare, vedi requisiti della tabella.
- Tabelle partizionate: supportate, soggette a un limite di dispersione della partizione. Azure Databricks raccomanda il cluster liquido per chiavi ad alta cardinalità. Vedi Tabelle partizionate.
- Tabelle cluster liquide: la disposizione consigliata, organizzare i dati per le prestazioni delle query senza il limite di diffusione delle partizioni. Vedere Usare clustering liquido per le tabelle.
-
Dati varianti: ingerire dati semi-strutturati in
VARIANTcolonne. Vedere Tipi di dati supportati.
Posizione di riserva resistente
Se una modifica interrotta nella tabella arriva dopo che Zerobus Ingest rende i tuoi dati durevoli ma prima che possa pubblicarli sulla tabella, Zerobus Ingest scrive quei dati come file Parquet in una cartella di riserva all'interno della posizione di archiviazione della tabella, invece di eliminarla. Per trovare e rielaborare questi dati dopo aver sistemato lo schema, vedi Recupero dei dati dalla posizione di fallback durevole.
Monitoraggio dell'utilizzo
Monitora l'utilizzo e i costi di Zerobus Ingest attraverso le tabelle di sistema. Vedi riferimento alla tabella di sistema Zerobus Ingest e, per la spesa, la tabella del sistema di fatturazione sotto Costo.