Protocoles d’API

Zerobus Ingest expose un point d’extrémité avec plusieurs protocoles API : gRPC (via les SDK), REST, OpenTelemetry (OTLP) et des API compatibles Kafka. Toutes écrivent directement dans les tables Delta du catalogue Unity, vous choisissez donc le protocole qui convient le mieux à chaque producteur.

Architecture de montée en charge de Zerobus Ingest : les sources transmettent des enregistrements Protocol Buffers (protobuf), JSON et Arrow via les API gRPC, REST, OpenTelemetry et compatibles avec Kafka, puis transitent, grâce à la mise à l’échelle automatique et à l’équilibrage de charge, vers un pool de nœuds Zerobus sans état extensible horizontalement, chacun doté d’un journal de préécriture et d’un module d’écriture Lakehouse qui valide par lot les enregistrements dans une table Delta gérée par Unity Catalog

Quel protocole devriez-vous utiliser ?

Protocole Idéal pour Pourquoi
gRPC (SDK) Producteurs de diffusion en continu à fort volume : modification de la capture de données, parcours de visite, journaux et redirecteurs d’événements. Les connexions persistantes offrent le débit soutenu le plus élevé et préservent la commande par flux. Disponible en Python, Java, Rust, Go, TypeScript, et (en version Bêta) C++ et C# / .NET. Voir Écrire un client.
REST De grandes flottes de clients légers ou « bavards », comme des appareils en périphérie et des appareils IoT qui communiquent rarement. Sans État : chaque requête est autonome, donc les clients n’ont pas de connexion ouverte. Plus simple pour les appareils qui envoient des données de temps en temps. Voir l’exemple REST.
OpenTelemetry (OTLP) Les pipelines d’observabilité émettent déjà des traces, des journaux et des métriques. Dirigez vos SDK ou collecteurs OpenTelemetry existants vers le point de terminaison, sans aucune intégration personnalisée. Voir Ingérer les données OpenTelemetry avec Zerobus Gest.
API compatibles avec Kafka (Beta) Des producteurs qui parlent déjà le protocole Kafka, ou des outils qui envoient des données vers Kafka, si vous souhaitez retrouver ces données dans Delta avec un minimum de modifications du code. Réutiliser un producteur Kafka existant sans un SDK Azure Databricks. Pointez-le vers le point de terminaison et publiez dans un topic portant le nom de votre table cible. Voir Utiliser des API compatibles Kafka avec Zerobus Ingest.

gRPC avec les SDK

Les SDK Zerobus enroulent une connexion gRPC bidirectionnelle persistante appelée un flux. Parce que la connexion reste ouverte, le gRPC atteint le débit soutenu le plus élevé et constitue la voie recommandée pour une ingestion continue et à haut volume. Chaque flux ouvert est une connexion durable, donc le débit d’un client évolue avec le nombre de flux ouverts.

Les SDK gèrent la gestion des connexions, le suivi des décalages et la récupération pour vous, et sont disponibles en Python, Java, Rust, Go, TypeScript et (en version Bêta) C++ et C# / .NET. Ils offrent un comportement équivalent entre les langues, alors choisissez celui qui convient à votre application. Sur 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, voir Écrire un client.

REST

L’interface REST est sans état : chaque requête se complète d’elle-même sans tenir une connexion ouverte. Cela le rend particulièrement bien adapté aux grandes flottes de sources légères ou intermittentes, par exemple des dispositifs en périphérie et des appareils IoT qui transmettent rarement leur état, pour lesquels maintenir une connexion persistante pour chaque appareil serait peu pratique.

L’ingestion REST est régie par un quota de taux de demande (voir quotas d’ingestion Zerobus). Pour un producteur à fort volume, les SDK sur gRPC maintiennent un débit plus élevé que l’émission de nombreuses requêtes REST individuelles. Réservez REST aux producteurs qui envoient rarement ou qui ne peuvent pas maintenir une connexion permanente.

OpenTelemetry (OTLP)

Zerobus Ingest inclut un point de terminaison natif OpenTelemetry Protocol. Si vos systèmes produisent déjà des traces, journaux et métriques OpenTelemetry, vous pouvez orienter vos exportateurs ou collecteurs OTLP existants vers Zerobus Ingest et obtenir cette télémétrie directement dans les tables Delta que vous possédez, généralement avec un simple changement de configuration. Voir Importer des données OpenTelemetry avec Zerobus Ingest.

API compatibles avec Kafka

Important

Les API compatibles Kafka sont en version Bêta.

Zerobus Ingest propose des API producteur compatibles Kafka, ce qui vous permet d’ingérer avec n’importe quel client producteur Apache Kafka sans SDK Azure Databricks. Vous pointez un producteur Kafka existant vers le point de terminaison et produisez vers un sujet nommé d’après votre table cible. Les enregistrements se retrouvent alors dans une table Delta du catalogue Unity. C’est la meilleure option quand vous utilisez déjà un producteur Kafka, ou un collecteur ou un agent qui émet vers Kafka, et que vous souhaitez acheminer ces données vers Delta avec un minimum de changement de code.

Les API compatibles Kafka implémentent le sous-ensemble côté producteur du protocole Kafka et sont en écriture seule : les API consommateur, administrateur et transactionnelle ne sont pas disponibles. Ils n’acceptent que les enregistrements JSON. Le débit est régi par un quota de taux de demande par espace de travail plutôt que par des connexions individuelles. Pour le quota spécifique, voir quotas d’ingestion Zerobus. Pour un débit maximal, des accusés de réception pour chaque enregistrement et une récupération automatique, utilisez plutôt le SDK Zerobus via gRPC.

Pour la configuration, l’authentification et un exemple de producteur, voir Utiliser des API compatibles Kafka avec Zerobus Ingest.

  • Last updated on