Protocoles d'API
Zerobus Ingest expose un endpoint avec plusieurs protocoles d'API : gRPC (via les SDK), REST, OpenTelemetry (OTLP) et des API compatibles avec Kafka. Tous écrivent directement dans des tables Delta du Unity Catalog ; vous choisissez donc le protocole le mieux adapté à chaque producteur.
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. |
APIs compatibles Kafka (Bêta) | 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.
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.
- 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.