Fonctionnalités de Zerobus Ingest
Cette page présente une vue d'ensemble de ce que propose Zerobus Ingest dans Lakeflow Connect. Chaque fonctionnalité renvoie à sa documentation complète.
- Endpoint toujours actif: serverless, activé par default, monte en charge automatiquement.
- Méthodes d’authentification: comment les clients s’authentifient, notamment le service principal OAuth et la fédération des fournisseurs d’identité externes.
- Blocage de messages: méthodes d’ingestion et comment confirmer la durabilité.
- Callbacks d'acquittement: réagissent aux acquittements et aux erreurs de manière asynchrone.
- Fonctionnalités des tables Delta: partitionnement, clustering fluide et données
VARIANT. - Colonne de sauvetage: capturez les champs qui ne correspondent pas au schéma de table au lieu de les rejeter.
- Emplacement de fallback durable: où les données aboutissent si elles ne peuvent pas être publiées.
- monitoring de votre utilisation: tables système pour l’utilisation et les dépenses.
Endpoint toujours actif
Zerobus Ingest est un Endpoint Serverless activé par default pour les Workspace dans les régions prises en charge. Il n'y a rien à start, à provisionnement ou à Monter en charge. Une fois que vous avez une table cible et une identité autorisée, vous pouvez commencer à pousser les données, et la capacité est automatiquement mise à l'échelle. Pour commencer, consultez Utiliser Zerobus Ingest.
Méthodes d’authentification
Chaque client Zerobus s'authentifie avec un jeton OAuth Databricks à courte durée de vie. Lorsque vous utilisez un SDK, il obtient et refresh le jeton pour vous. Sur les autres interfaces, comme l'API REST, vous obtenez le jeton vous-même et vous l'incluez dans vos requêtes. Pour connaître les étapes de configuration et obtenir le code, consultez Configurer l’authentification.
OAuth avec un Service Principal (default)
Authentifiez-vous avec un ID client et un secret de Service Principal Databricks. Il s’agit de la méthode par default. Il convient aux workloads qui peuvent contenir un secret géré par Databricks.
Fédération de fournisseurs d’identité externes
Authentifiez-vous avec un jeton provenant de votre propre fournisseur d'identité, tel que Microsoft Entra ID, au lieu d'un secret Databricks. Le jeton du fournisseur d'identité est échangé contre un jeton Databricks de portée Zerobus à l'aide de l'échange de jetons RFC 8693, aucun secret Databricks de longue durée n'est donc stocké sur le client.
La fédération prend en charge deux modèles d'identité :
- Fédération au niveau du compte : il n’y a pas de service principal Databricks. Votre identité issue du fournisseur d’identité est synchronisée dans le compte Databricks via la gestion automatique des identités, et votre client s’authentifie en tant que cette identité. Cela nécessite une politique de fédération de compte qui enregistre votre fournisseur comme émetteur approuvé.
- Fédération d’identités de Workload : utilisez un Service Principal Databricks ayant un ID client et aucun secret, auquel une politique de fédération est attachée.
Microsoft Entra ID est l'exemple utilisé sur ces pages, mais le même flux fédéré fonctionne avec d'autres fournisseurs d'identité compatibles avec OpenID Connect (OIDC).
Comparer les méthodes d’authentification
Méthode | Service principal Databricks | Secret client Databricks | Quand utiliser |
|---|---|---|---|
Service principal OAuth | Oui | Oui | Votre client peut contenir un secret géré par Databricks. |
Fédération au niveau du compte | Non | Non | Votre identité est régie uniquement par votre fournisseur, sans aucun service principal ou secret Databricks. |
Fédération d'identité de Workload | Oui, sans secret | Non | Vous souhaitez obtenir une identité de Service Principal Databricks sans stocker de secret. |
L'échange automatique de jetons dans le SDK est disponible dans le SDK Python 1.10.0 et ultérieur et dans le SDK Rust 2.11.0 et ultérieur. Pour les étapes de configuration et le code, consultez Configurer l’authentification.
Fonctionnalités de table Delta
Zerobus Ingest écrit dans des tables Delta standard gérées par Unity Catalog, de sorte que vos données ingérées fonctionnent avec les fonctionnalités des tables Delta. Pour connaître les exigences auxquelles une table cible doit répondre, consultez Table requirements.
- Tables partitionnées : prises en charge, sous réserve d'une limite de partition-fan-out. Databricks recommande le clustering fluide pour les clés à cardinalité élevée. Voir Tables partitionnées.
- Liquid clustered tables : la layout recommandée, qui organise les données pour optimiser les performances de query sans la limite de partition-fan-out. Consultez Use liquid clustering for tables.
- Données Variant : importez des données semi-structurées dans des colonnes
VARIANT. Voir Types de données pris en charge.
Emplacement de fallback durable
Si une modification de table incompatible survient après que Zerobus Ingest a rendu vos données durables mais avant qu'il ne puisse les publier dans la table, Zerobus Ingest écrit ces données sous forme de fichiers Parquet dans un répertoire de fallback au sein de l'emplacement de stockage de votre table, plutôt que de les supprimer. Pour trouver et retraiter ces données après avoir corrigé le schéma, consultez Récupération des données depuis l'emplacement de fallback durable.
monitoring de votre utilisation
Surveillez votre utilisation et vos dépenses Zerobus Ingest via les tables système. Consultez Zerobus Ingest system table reference et, pour les dépenses, la table système de facturation sous Cost.