Limitations du connecteur Zerobus Ingest
Cette page répertorie les limitations lors de l'utilisation du connecteur Zerobus Ingest dans Lakeflow Connect.
Disponibilité
Le connecteur Zerobus Ingest est disponible uniquement dans certaines régions. Pour obtenir la 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 la durabilité et le temps nécessaire pour matérialiser les enregistrements dans la table Delta cible. Les durées réelles varient en fonction de l'alignement régional et des caractéristiques de la charge de travail.
-
Délai de durabilité
- P50 ≤ 150 ms
-
Temps de la table
- P50 ≤ 5 s
Limites de throughput default
Les limites default suivantes s'appliquent au connecteur Zerobus Ingest.
- 100 Mo/seconde par Stream (mesuré avec des messages de 1 Ko)
- 10 Go/seconde par table cible
Pour atteindre un throughput maximal, une application cliente et un Endpoint doivent se trouver dans la même région géographique. Si vous avez besoin d'un throughput plus élevé, contactez votre représentant de compte Databricks.
Garanties de livraison
Le connecteur Zerobus Ingest offre des garanties d'au moins une livraison.
Rétention des données tamponnées
Si le service Zerobus Ingest ne peut pas vider les données mises en mémoire tampon dans 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 purgées pendant 31 jours, le service supprime les données mises en mémoire tampon et émet un événement d'abandon par Stream, enregistrant le nombre d'enregistrements et d'octets supprimés. Vous ne pouvez pas récupérer les données après la suppression.
Quotas
Vous trouverez ci-dessous les quotas default pour le connecteur Zerobus Ingest. Si vous avez besoin de performances plus élevées, veuillez contacter votre représentant de compte Databricks.
gRPC
- 100 Mo par seconde de throughput par Stream
- 10 Go par seconde de throughput par table cible
REST
- 10 000 requêtes par seconde
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 dans chaque intervalle de 5 secondes.
Databricks recommande d'utiliser des tables en cluster liquides avec Zerobus Ingest au lieu du partitionnement.
Commits de catalogue
Zerobus Ingest ne prend pas en charge les commits de catalogue. N'utilisez pas Zerobus Ingest pour les tables Delta avec les commits de catalogue activés.
Workspace et table cible
Les conditions suivantes de workspace et de table cible sont requises pour l'ingestion.
- Le connecteur ne prend en charge l'écriture que sur des tables Delta gérées. L'écriture dans le stockage default n'est pas prise en charge.
- Le connecteur ne prend pas en charge l'écriture dans le stockage sécurisé via un endpoint privé.
- Le connecteur ne prend pas en charge la recréation d'une table cible.
- Le connecteur ne prend en charge que les noms de table contenant des lettres ASCII, des chiffres et des traits de soulignement.
- Le workspace et la table cible doivent se trouver dans l'une des régions disponibles, et tous deux dans la même région.
Tables en clustering liquide
Aperçu
L'écriture dans des tables en clusters liquides à l'aide du connecteur Zerobus Ingest est en Beta.
Lorsque vous utilisez le connecteur Zerobus Ingest avec des tables à clustering liquide, il est recommandé de maintenir l'optimisation prédictive activée pour la table cible. Le connecteur écrit les données dans la table, mais la mise en cluster optimale des données est appliquée 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.
évolution des schémas
Zerobus Ingest ne fera jamais évoluer automatiquement votre table cible.
Zerobus Ingest prend en charge l'ingestion continue lorsque des colonnes Delta pouvant être nulles sont ajoutées à la table cible. Les colonnes manquantes sont remplies avec les valeurs NULL, ce qui vous permet d'envoyer des enregistrements avec des champs manquants.
schéma Protobuf
La définition du schéma Protobuf doit correspondre à 1:1 avec le schéma de la table Delta (à l’exclusion des colonnes delta nullables supplémentaires, qui sont considérées comme un changement de schéma non cassant). 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 (nullables et non nullables)
-
Le connecteur ne prend pas en charge les schémas proto avec plus de 2 000 colonnes.
-
Le connecteur ne prend en charge que les noms de tables et de colonnes avec 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 "création de Stream" et d'"ingestion d'enregistrements".
Taille d'enregistrement
Chaque message est limité à 10 Mo. La taille maximale de l’enregistrement est de 10 485 760 octets. Les en-têtes requis pour la communication occupent 19 octets.
Prise en charge des types
Le tableau suivant présente les types Delta pris en charge et leurs types Protobuf correspondants pour l'ingestion.
Types Delta | Types Protobuf |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Doit être converti en |
|
Doit être converti en |
|
|
|
|
Le sucre syntaxique |
|
|
La variante doit être ingérée comme une chaîne encodée en JSON avec des clés de type Les formats pris en charge incluent :
|
|