Quotas du connecteur Zerobus Ingest
Cette page décrit les quotas default du connecteur Zerobus Ingest dans Lakeflow Connect, ainsi que son fonctionnement avec vos tables Delta, votre schéma et vos types de données.
Disponibilité
Le connecteur Zerobus Ingest n’est disponible que dans certaines régions. Pour obtenir une liste des régions prises en charge, consultez Disponibilité de l’ingestion.
Latence
La latence reflète à la fois l’accusé de réception de durabilité et le temps nécessaire pour matérialiser les enregistrements dans la table Delta cible. Les délais réels varient en fonction de l’alignement régional et des caractéristiques de la charge de travail.
-
Délai de durabilité
- P50 ≤ 150 ms
-
Délai de table
- P50 ≤ 5 s
Quotas
Le tableau suivant répertorie les quotas default pour le connecteur Zerobus Ingest.
Élément | Quota default | Besoin de plus ? |
|---|---|---|
Throughput par stream (gRPC) | 100 Mo/seconde (évalué avec des messages de 1 Ko) | Réglable |
Throughput par table cible (gRPC) | 10 Go/seconde | Réglable |
Enregistrements par seconde et par stream | 100 000 (benchmarqué avec des messages de 1 Ko) | Réglable |
Requêtes REST par seconde | 10 000 | Réglable |
Il s'agit des throughput default avec lesquels le connecteur est provisionné, et ils montent en charge pour répondre à des workloads plus élevés. [[ ## completed ##]] Pour en soulever un, contactez votre représentant de compte Databricks. Pour un throughput maximal, conservez votre application cliente et l'endpoint dans la même région géographique.
Garanties de livraison
Le connecteur Zerobus Ingest fournit des garanties « au moins une fois ».
Conservation des données mises en mémoire tampon
Si le service Zerobus Ingest ne peut pas vider les données mises en tampon vers votre table Delta, il conserve les données dans un stockage durable géré par le service et émet occasionnellement des événements d'avertissement par stream.
Si les données restent non vidées pendant 28 jours, le service supprime les données mises en mémoire tampon et émet un événement de rejet par stream enregistrant le nombre d'enregistrements et d'octets supprimés. Vous ne pouvez pas récupérer les données après leur suppression.
Comportement de la table
Comment Zerobus Ingest fonctionne avec vos tables Delta.
Tables partitionnées
Lors de l'écriture dans des tables partitionnées, Zerobus Ingest ne prend pas en charge l'écriture dans plus de 100 partitions sur un intervalle de 5 secondes. Pour un throughput optimal, minimisez le nombre de partitions sur chaque intervalle de 5 secondes.
Databricks recommande d'utiliser des tables en cluster liquide avec Zerobus Ingest plutôt que le partitionnement.
Workspace et table cible
L’ingestion fonctionne avec la configuration de workspace et de table cible suivante.
- Le connecteur prend en charge l'écriture dans des tables Delta gérées.
- Le connecteur ne prend pas en charge la recréation d'une table cible.
- Le connecteur prend uniquement en charge les noms de table contenant des lettres ASCII, des chiffres et des traits de soulignement.
- Le workspace et la table cible doivent tous deux se trouver dans l’une des régions disponibles.
Tables avec clustering liquide
Lors de l'utilisation du connecteur Zerobus Ingest avec des tables en clustering liquide, il est recommandé de maintenir l'option d'optimisation prédictive activée pour la table cible. Le connecteur écrit les données dans la table, mais le clustering optimal des données est appliqué de manière asynchrone par le service d'optimisation prédictive. La désactivation de l'optimisation prédictive peut entraîner des performances de query sous-optimales sur les données ingérées.
Schéma et types de données
Les sections suivantes expliquent comment définir votre schéma et les types de données pris en charge par Zerobus Ingest.
évolution des schémas
Zerobus Ingest n’effectuera jamais d’évolution automatique de votre table cible.
Zerobus Ingest prend en charge l’ingestion continue lorsque des colonnes Delta nullables sont ajoutées à la table cible. Les colonnes manquantes sont remplies avec des valeurs NULL, ce qui vous permet d’envoyer des enregistrements avec des champs manquants.
Schéma Protobuf
La définition de schéma protobuf doit correspondre 1:1 au schéma de table Delta (à l'exclusion des colonnes delta nullable supplémentaires, qui sont considérées comme un changement de schéma non bloquant). Si le schéma ne correspond pas, l'API renvoie une erreur. Sont concernés :
-
Nombre de colonnes différent
-
Noms de colonne différents
-
Différentes options de colonne (pouvant être nulle ou non nulle)
-
Le connecteur ne prend pas en charge les schémas proto comportant plus de 2 000 colonnes.
-
Le connecteur prend uniquement en charge les noms de table et de colonne contenant des lettres ASCII, des chiffres et des traits de soulignement.
-
Le connecteur ne prend pas en charge l’utilisation d’un schéma proto différent pour les opérations de « stream creation » et d’« ingest record ».
Taille de l’enregistrement
Chaque message a une taille maximale de 10 Mo. La taille maximale d'un enregistrement est de 10 485 760 octets. Les en-têtes requis pour la communication occupent 19 octets.
Prise en charge du type
Le tableau suivant présente les types Delta pris en charge et leurs types Protobuf correspondants pour l’ingestion.
Types Delta | Types Protobuf |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Texte décimal, p. ex. « 123,45 », « 1e2 », etc. |
|
|
|
|
|
|
|
Doit être converti en |
|
Doit être converti en |
|
Doit être converti en |
|
|
|
|
Le sucre syntaxique Protobuf |
|
|
La variante doit être ingérée sous forme de chaîne encodée en JSON avec des clés de type Les formats pris en charge sont les suivants :
|
|