Databricks veut simplifier le streaming de données avec Zerobus Ingest

Ingestion de données et performances : Databricks mise sur Rust, gRPC et Protobuf

L’éditeur vante la simplicité de son offre managée synchrone ou asynchrone qui, elle, s’appuie sur architecture client-serveur « single sink » et une approche WAL (Write Ahead Log) pour la persistance en cas d’erreur. Le point d’entrée n’est autre qu’un SDK (Java, Rust, Go, TypeScript) ou des API gRPC et REST (en bêta) en mode push.

Les déclinaisons des SDK sont des wrappers autour d’un client écrit en Rust. Un choix qui s’explique aisément, au vu de la performance de certains langages de programmation. « Le SDK Python utilise les liaisons PyO3 avec le SDK Rust haute performance. Il offre ainsi un débit jusqu’à 40 fois supérieur à celui du Python pur et une entrée/sortie réseau efficace grâce au runtime asynchrone de Rust », affirme Databricks dans sa documentation. L’éditeur avait déjà utilisé gRPC, le protocole de sérialisation Protobuf et Rust pour développer Spark Connect.

Ce client permet de sélectionner la table cible, d’établir et maintenir la connexion avec le serveur Zerobus Ingest en gRPC, de construire un schéma compatible avec la table cible, d’envoyer le message à haute vitesse en sérialisant les données. Il gère les reconnexions, l’identification OAuth 2.0 avec le serveur. Optionnellement, il détecte les coupures réseau, remet en file d’attente les données perdues et relance automatiquement les pipelines.

Le serveur Zerobus Ingest, lui, reçoit les données, valide le schéma, optimise les buffers Protobuf (avec gRPC) ou les fichiers JSON (avec l’API REST) et les lots, puis écrit dans la table Delta cible connectée au catalogue de données Unity Catalog. Ces « serveurs » sont en fait des pods déployés sur Kubernetes et ont accès des baies de stockage SSD NVMe.

Databricks recommande l’usage des SDK et de l’API gRPC relié, pour les performances associées et les connexions persistantes, mais prévient que « chaque flux ouvert est pris en compte dans vos quotas de concurrence ». L’API REST, elle, est plus adaptée aux cas d’usage où les messages sont envoyés sporadiquement. Toutefois, puisqu’elle est stateless, « elle exige une procédure de connexion complète pour chaque mise à jour ».

« Appuyez-vous sur gRPC pour les flux à haut volume et sur REST pour les flottes d’appareils massives à faible fréquence ou les langages [de programmation] non pris en charge », résument les ingénieurs de Databricks. La documentation précise que l’API REST est fournie avec une limitation de 10 000 requêtes par seconde.

Zerobus Ingest est une alternative partielle à Kafka. Sa nature « single sink », contrairement à Kafka qui est multisink, implique que la solution ne serve qu’à alimenter le « lakehouse » de Databricks.

Pas un véritable remplaçant à Apache Kafka

En clair, Zerobus Ingest ne remplace pas les systèmes Kafka quand ils sont utilisés dans le cadre d’architecture de microservices event-driven, de plateformes complexes de notifications et d’alertes avec plusieurs producteurs et plusieurs consommateurs.

« Si un utilisateur a besoin d’acheminer simultanément des événements vers des dizaines de systèmes en aval, Zerobus Ingest n’est pas conçu pour cela », prévient William McKnight, fondateur du cabinet d’analyste éponyme. Il s’exprime auprès de SearchDataManagement, une publication sœur du MagIT. « Il ne convient pas à tous les besoins d’une entreprise. […] Zerobus Ingest sacrifie le routage multidestinations, la relecture des événements et la livraison unique en échange d’une architecture simplifiée. C’est un excellent outil pour l’ingestion vers un lac de données à destination unique plutôt qu’un hub de messages universel ».

Les plus gros utilisateurs de Kafka, les institutions financières, ne risquent pas de débrancher dans l’immédiat leur flux de streaming vers leur plateforme analytique.

« Pour les transactions financières, le traitement des commandes ou d’autres flux de travail où un traitement en double pourrait entraîner de graves problèmes, les garanties de livraison en une seule fois offertes par Kafka sont essentielles », reconnaît Yashodhan Kale, architecte solutions spécialisé chez Databricks. « Bien que la feuille de route de Zerobus Ingest inclue cette fonctionnalité, les organisations qui en ont besoin dès aujourd’hui doivent encore s’appuyer sur Kafka », précisait-il dans un billet de blog à la toute fin du mois de décembre.

C’est toujours le cas au lancement (Zerobus Ingest fournit uniquement des garanties « au moins une fois », lit-on dans la documentation), mais la solution dispose d’un autre atout. En définissant un schéma strict « Zerobus valide les enregistrements entrants en fonction de la définition de la table ». Dans le cas contraire, il génère une erreur. Avec le type VARIANT, Databricks dit pouvoir s’adapter à une approche « Schema on Read », quand le schéma des données sources n’est pas maîtrisable (un service tiers) ou que les métadonnées changent beaucoup. Les deux approches peuvent être combinées quand la table cible concatène différentes sources de données. Cela veut aussi dire que la gestion des schémas et des tables reste la responsabilité des clients. Et qu’il faut potentiellement opérer des transformations après l’ingestion.

De surcroît, Zerobus Ingest n’est pas disponible dans un mode multirégion, ce qui empêche son usage dans les contextes les plus critiques. « Cela devrait changer prochainement », dixit Yashodan Khale. Un point officiellement confirmé dans la documentation de l’éditeur. Tout comme la prise en charge des tables Apache Iceberg (les données sont stockées au format Parquet).

Supervision IT, cyber et IoT : les cas d’usage privilégiés de Zerobus Ingest

Alors, à qui s’adresse Zerobus Ingest ? Databricks précise ces marchés de prédilection : l’industrie manufacturière, l’IoT, la cybersécurité, la supervision IT et le suivi des interactions clients en temps réel (pour de l’A/B testing ou de la recommandation personnalisée).

Un connecteur OpenTelemetry est par ailleurs disponible en bêta. L’éditeur a aussi noué un partenariat avec le fournisseur IoT japonais Soracom. Les équipements transitent des capteurs connectés vers la gateway cloud Soracom Beam, qui elle-même est connectée au client Zerobus Ingest.

Le client de cette intégration n’est autre que Toyota. Le constructeur automobile aurait ainsi baissé le temps de la détection de surchauffe de certains équipements « de quelques heures à quelques minutes ». La notion de quasi-temps réel est importante. Joby Aviation, un fabricant d’avions-taxis dit pousser des gigaoctets de données de télémétrie par minute issue de ses appareils vers Databricks.

Malgré cette portée plus limitée que le laissent entendre la communication de Databricks et l’éventuel enfermement propriétaire que cela implique, l’éditeur compte encore bousculer des acteurs comme IBM (propriétaire de DataStax) et sa future filiale Confluent, ainsi qu’AWS, GCP ou Microsoft. Il mise sur une tarification agressive, basée sur un volume de SKU consommé.

Certaines entreprises ont déjà décommissionné leurs infrastructures Kafka en migrant vers des services managés. Malgré tout, il reste la gestion des messages et des coûts. « Les factures Amazon Managed Streaming for Apache Kafka (Amazon MSK) peuvent rapidement atteindre des montants astronomiques en raison d’un surprovisionnement des brokers, d’un excès de partitions, de facteurs de réplication élevés et de longues périodes de conservation », illustre, Yashodhan Kale. « AWS gère l’infrastructure, mais pas votre discipline en matière de dépenses, qui reste votre problème ».

Les acteurs de l’observabilité, dont Cisco Splunk, Datadog, Dynatrace et les fournisseurs de SIEM sont également en ligne de mire, comprend LeMagIT, tout comme InfluxData, porteur d’InfluxDB, utilisés dans l’IoT et pour le monitoring.

Le prix de Zerobus Ingest bénéficie d’un rabais de 50 % au cours des six premiers mois du lancement, jusqu’au 1^er septembre prochain. Hors promotion, Zerobus Ingest est facturé à partir de 0,05 dollar du Go en incluant les coûts de calcul associé (à partir de 50 dollars par téra-octet, et plutôt 56 dollars en Europe). Il faut compter en revanche sur une tarification au-delà des 0,06 dollar par giga-octet sur Microsoft Azure. Pour tous les clouds, le prix varie selon les régions. Amazon MSK Serverless combine la facturation à l’heure des clusters et des partitions et un prix aux volumes de données, entrants, sortants et stockés.

 De son côté, Snowflake a lancé Snowpipe Streaming qui permet de nourrir des tables de son Data Warehouse Cloud à partir de flux Kafka existants ou de volumes de stockage objet. OpenFlow (Apache NiFi) permet de faire la même chose. Avant son rachat par IBM, Confluent a développé la jonction de l’ingestion Kafka et des traitements à l’aide d’Apache Flink.