Protocoles d'API
Zerobus Ingest expose un endpoint doté de plusieurs protocoles d'API : gRPC (via les SDK), REST, OpenTelemetry (OTLP), MQTT et des API compatibles avec Kafka. Tous écrivent directement dans des tables Delta Unity Catalog, vous choisissez donc le protocol qui s'adapte le mieux à chaque producteur.
Le diagramme suivant montre comment les enregistrements provenant des flux de Stream et des APIs transitent par la mise à l'échelle automatique et l'équilibrage de charge vers un pool horizontalement évolutif de nœuds Zerobus sans état. Chaque nœud dispose d'un journal des transactions (write-ahead log) et d'un rédacteur lakehouse qui valide par lots (batch-commits) des enregistrements dans une table Delta gérée par Unity Catalog. Les étiquettes de source dans le diagramme sont représentatives. MQTT suit le même chemin à travers l'équilibrage de charge, le stockage durable et la matérialisation des tables.
Quel protocole devez-vous utiliser ?
Protocole | Idéal pour | Pourquoi |
|---|---|---|
gRPC (SDK) | Producteurs de streaming à haut volume : change data capture, flux de clics, et redirecteurs de logs et d'événements. | Les connexions persistantes offrent le throughput soutenu le plus élevé et préservent l'ordre par Stream. Disponible en Python, Java, Rust, Go, TypeScript et (en version bêta) en C++ et C# / .NET. Voir Écrire un client. |
REST | Grands parcs de clients légers ou « bavards », tels que les appareils de périphérie et IoT qui envoient des rapports peu fréquemment. | Sans état : chaque requête est indépendante, les clients ne maintiennent donc pas de connexion ouverte. Plus simple pour les appareils qui envoient des données occasionnellement. Voir l'exemple REST. |
OpenTelemetry (OTLP) | Pipelines d'observabilité émettant déjà des traces, des logs et des métriques. | Pointez vos SDK ou collecteurs OpenTelemetry existants vers l'endpoint sans intégration personnalisée. Consultez Ingérer des données OpenTelemetry avec Zerobus Ingest. |
MQTT | Applications IoT, edge et de télémétrie publiant déjà des messages MQTT v5. | Réutilisez un client MQTT v5 pour publier des enregistrements JSON dans un sujet nommé d'après la table cible. Voir Utiliser MQTT avec Zerobus Ingest. |
APIs compatibles avec Kafka | Producteurs utilisant déjà le protocole Kafka, ou outils émettant vers Kafka, lorsque vous souhaitez intégrer ces données dans Delta avec un minimum de modifications de code. | Réutilisez un producteur Kafka existant sans SDK Databricks. Pointez-le vers l’Endpoint et produisez vers un sujet nommé d’après votre table cible. Consultez Use Kafka-compatible APIs with Zerobus Ingest. |
gRPC avec les SDK
Les SDK Zerobus encapsulent une connexion gRPC bidirectionnelle persistante appelée stream. Comme la connexion reste ouverte, gRPC atteint le throughput soutenu le plus élevé et constitue la méthode recommandée pour une ingestion continue à haut volume. Chaque stream ouvert est une connexion longue durée ; ainsi, le throughput d'un client évolue en fonction du nombre de streams qu'il ouvre.
Les SDK gèrent pour vous la gestion des connexions, le suivi des offsets et la récupération, et sont disponibles en Python, Java, Rust, Go, TypeScript et (en version bêta) en C++ et C# / .NET. Ils offrent un comportement équivalent dans tous les langages ; choisissez donc celui qui convient à votre application. Via gRPC, les SDK prennent en charge les formats d'enregistrement JSON, protobuf et Apache Arrow. Voir Types de messages.
Pour écrire un client avec les SDK, y compris un exemple par langage pour chacun, consultez Écrire un client.
REST
L'interface REST est sans état : chaque requête s'exécute de manière autonome sans maintenir de connexion ouverte. Cela en fait une solution parfaitement adaptée aux larges flottes de producteurs légers ou intermittents, par exemple les appareils de périphérie et les appareils IoT qui signalent leur état peu fréquemment, pour lesquels le maintien d'une connexion persistante par appareil serait peu pratique.
L'ingestion REST est régie par un quota de taux de requêtes (voir les quotas de Zerobus Ingest). Pour un producteur à haut volume, les SDK via gRPC maintiendront un throughput plus élevé que l'émission de nombreuses requêtes REST individuelles. Réservez REST aux producteurs qui envoient des données peu fréquemment ou qui ne peuvent pas maintenir une connexion persistante.
OpenTelemetry (OTLP)
Zerobus Ingest inclut un endpoint natif pour le protocole OpenTelemetry. Si vos systèmes produisent déjà des traces, des logs et des métriques OpenTelemetry, vous pouvez pointer vos exportateurs ou collecteurs OTLP existants vers Zerobus Ingest et stocker ces données de télémétrie directement dans les tables Delta que vous possédez, généralement avec un simple changement de configuration. Consultez Ingérer des données OpenTelemetry avec Zerobus Ingest.
MQTT
Bêta
Cette fonctionnalité est en version bêta. Les administrateurs du Workspace peuvent contrôler l'accès à cette fonctionnalité à partir de la page Previews . Consultez Gérer les aperçus Databricks.
L'interface MQTT accepte les connexions MQTT v5 sur TLS via le port 8883. Une connexion cible une table et chaque message contient un objet JSON UTF-8. Utilisez le niveau 1 de qualité de service (QoS) lorsque le producteur nécessite un accusé de réception durable. Pour la configuration, l'authentification, les limitations et un exemple en Python, consultez Utiliser MQTT avec Zerobus Ingest.
APIs compatibles avec Kafka
Bêta
Les API compatibles avec Kafka sont en version bêta.
Zerobus Ingest propose des APIs de producteur compatibles avec Kafka, vous permettant ainsi d'ingérer des données avec n'importe quel client producteur Apache Kafka sans SDK Databricks. Vous pointez un producteur Kafka existant vers l'endpoint et produisez vers un sujet nommé d'après votre table cible, et les enregistrements sont stockés dans une table Delta Unity Catalog. C'est la solution idéale si vous utilisez déjà un producteur Kafka, ou un collecteur ou agent émettant vers Kafka, et que vous souhaitez acheminer ces données vers Delta avec un minimum de modifications de code.
Les APIs compatibles Kafka implémentent le sous-ensemble côté producteur du protocole Kafka et sont en écriture seule : les APIs de consommateur, d'administration et transactionnelles ne sont pas disponibles. Ils acceptent uniquement les enregistrements JSON. Le throughput est régi par un quota de taux de requêtes par workspace plutôt que par des connexions individuelles. Pour le quota spécifique, voir les quotas de Zerobus Ingest. Pour obtenir le throughput le plus élevé, des accusés de réception par enregistrement et une récupération automatique, utilisez plutôt un SDK Zerobus via gRPC.
Pour la configuration, l’authentification et un exemple de producteur, consultez Utiliser des APIs compatibles Kafka avec Zerobus Ingest.
Connexes
- Types de messages: les formats d'enregistrement disponibles via ces protocoles.
- Utiliser Zerobus Ingest: écrivez un client en utilisant les SDK ou l'API REST.
- Ingérer des données OpenTelemetry avec Zerobus Ingest: ingérez des données OpenTelemetry.
- Utiliser MQTT avec Zerobus Ingest: utiliser MQTT v5 pour publier des enregistrements JSON.
- Phases de publication de Zerobus Ingest: phases de publication pour chaque interface et format d'enregistrement.
- Utiliser des APIs compatibles Kafka avec Zerobus Ingest: utilisez des APIs de producteur compatibles Kafka.