Réponses>En savoir plus sur le streaming de données blockchain>Qu'est-ce que le streaming de données blockchain ?
Qu'est-ce que la diffusion de données via la blockchain ?
// Tags
diffusion de données blockchaindonnées de la blockchain en temps réel
En bref : le streaming de données blockchain est une approche de type « push » permettant d’accéder aux données de la blockchain, dans laquelle les nouveaux blocs, transactions et événements sont transmis automatiquement à votre application ou à votre base de données dès leur création sur la chaîne. Au lieu que votre application interroge sans cesse le nœud pour savoir s’il y a du nouveau (polling), un service de streaming vous envoie les données dès qu’elles sont disponibles. Le streaming réduit la latence, élimine les événements manqués, simplifie votre architecture backend et s'adapte bien plus efficacement que les modèles traditionnels de requête-réponse.
L'explication simple
Il existe deux méthodes fondamentales pour récupérer des données depuis n'importe quel système : vous pouvez les demander (modèle « pull ») ou elles peuvent vous être envoyées (modèle « push »). Pendant la majeure partie de l’histoire de la blockchain, les développeurs ont utilisé le modèle « pull ». Votre application envoie une requête RPC à un nœud, le nœud renvoie une réponse, puis votre application décide quand envoyer une nouvelle requête. C’est ce qu’on appelle le modèle de sondage. Il est simple à mettre en œuvre mais inefficace, en particulier lorsque votre application doit rester synchronisée avec l’état le plus récent de la blockchain.
Le streaming renverse ce modèle. Au lieu que votre application demande « Que s'est-il passé dans le dernier bloc ? » des milliers de fois par jour, vous mettez en place un pipeline de données une seule fois et le service de streaming transmet les données de chaque nouveau bloc à votre application ou à votre base de données au fur et à mesure de leur production. Votre application devient ainsi un consommateur d'un flux de données continu plutôt qu'un demandeur d'instantanés de données discrets.
Cette analogie illustre la différence entre actualiser un site d'actualités toutes les cinq minutes et s'abonner à une notification push qui vous alerte dès qu'une information est publiée. Les deux méthodes vous permettent finalement d'obtenir les mêmes informations, mais le modèle des notifications push est plus rapide, moins fastidieux et plus fiable.
Comment fonctionne la diffusion de données via la blockchain ?
Un service de streaming s'intercale entre les nœuds de la blockchain et votre application ou votre infrastructure de données. Du côté de l'ingestion, le service se connecte aux nœuds des réseaux pris en charge et traite chaque nouveau bloc dès qu'il est finalisé. Il extrait les données brutes du bloc, notamment les en-têtes, les transactions, les reçus de transaction (avec les journaux d'événements) et, éventuellement, les traces d'exécution. Ces données brutes constituent l'historique complet de tout ce qui s'est passé dans ce bloc.
Du côté du traitement, le service de streaming applique tous les filtres ou transformations que vous avez configurés. Peut-être ne vous intéressent-ils que les événements de transfert ERC-20 provenant d’un ensemble spécifique de contrats. Un filtre écrit en JavaScript ou dans un autre langage pris en charge analyse les données de chaque bloc et ne laisse passer que les enregistrements qui correspondent à vos critères. Ce filtrage côté serveur est essentiel pour l’efficacité, car il permet à votre destination de ne recevoir et de ne stocker que les données dont vous avez réellement besoin, et non le bloc dans son intégralité.
Du côté de la diffusion, les données filtrées sont envoyées vers la destination que vous avez configurée. Il peut s’agir d’une URL de webhook sur laquelle votre application est à l’écoute, d’une base de données PostgreSQL, d’un entrepôt de données Snowflake, d’un compartiment Amazon S3, d’Azure Blob Storage ou de tout autre point de terminaison pris en charge. Le service de streaming assure les garanties de diffusion, notamment les tentatives de réenvoi en cas d’échec, la déduplication et le classement correct des données, afin que votre destination reçoive un flux séquentiel et sans interruption de données de blockchain.
Approches de streaming vs approches ETL traditionnelles
Les pipelines ETL (Extract, Transform, Load) traditionnels basés sur la blockchain obligent les développeurs à mettre en place et à maintenir une infrastructure importante. Une configuration ETL personnalisée typique comprend un processus de sondage qui appelle des points de terminaison RPC selon un calendrier défini pour récupérer les nouveaux blocs, une couche de traitement qui décode et transforme les données brutes, un module d'écriture dans la base de données qui insère les enregistrements, un gestionnaire d'erreurs qui gère les nouvelles tentatives et les échecs, un détecteur de réorganisation qui identifie et annule les données issues de fourches abandonnées, ainsi qu'un système de surveillance qui alerte en cas de défaillance de l'un de ces composants. Chaque élément ajoute à la complexité et constitue un point de défaillance potentiel.
Les services de streaming regroupent toutes ces étapes au sein d'un pipeline unique et géré. L'extraction, le filtrage, la transformation, la diffusion, la logique de réessai, le classement et la gestion des réorganisations s'effectuent tous sur l'infrastructure du fournisseur. Votre rôle se limite à configurer les données souhaitées, leur destination et la manière dont vous souhaitez qu'elles soient traitées. Cela réduit considérablement l'effort d'ingénierie nécessaire à la mise en place et à la maintenance d'une infrastructure de données blockchain.
La différence de performances est également considérable. Un pipeline basé sur l’interrogation présente intrinsèquement une latence égale à l’intervalle d’interrogation. Si votre worker vérifie la présence de nouveaux blocs toutes les 5 secondes, vous pourriez accuser un retard pouvant aller jusqu’à 5 secondes par rapport à la pointe de la chaîne, même lorsque tout fonctionne parfaitement. Les interrogations manquées (dues à des erreurs, à des limitations de débit ou à des redémarrages du worker) accentuent cet écart. Le streaming élimine la latence liée à l’interrogation, car les données sont transmises dès qu’elles sont disponibles. Sur les chaînes à haut débit où les blocs sont produits toutes les quelques centaines de millisecondes, cette différence est significative pour les applications sensibles à la latence.
Principales fonctionnalités de la diffusion en continu en production
Plusieurs caractéristiques distinguent le streaming de niveau production d'un simple abonnement WebSocket. La livraison garantie assure que les données de chaque bloc parviennent à leur destination exactement une fois, même en cas de coupure temporaire de la connexion ou de brève interruption de service au niveau de la destination. Le service de streaming met les données en mémoire tampon et effectue des tentatives répétées jusqu'à ce que la livraison soit confirmée, ce qui vous évite toute perte de données.
La livraison dans l'ordre de finalité signifie que les données arrivent dans l'ordre que la blockchain considère comme canonique. Sur les chaînes dont les délais de finalité sont variables, le service de streaming attend qu'un bloc soit suffisamment confirmé avant de le transmettre, ce qui empêche votre application de traiter des données qui pourraient être invalidées ultérieurement par une réorganisation. Lorsqu'une réorganisation se produit, le service détecte la bifurcation, identifie les blocs qui ne sont plus canoniques et envoie des charges utiles de correction afin que votre destination puisse se mettre à jour en conséquence.
Le « backfilling » historique vous permet d’utiliser le même pipeline de streaming pour les données passées, et pas seulement pour les nouveaux blocs. Au lieu de mettre en place un processus ETL distinct pour les données historiques et un autre pour les données en temps réel, vous configurez un flux unique dont le bloc de départ se situe dans le passé, puis vous le laissez traiter les données en remontant dans le temps, avant de passer de manière transparente au traitement en temps réel dès qu’il a rattrapé la pointe de la chaîne. Ce pipeline unifié simplifie votre architecture et garantit la cohérence entre les données historiques et celles en temps réel.
Le filtrage et la transformation côté serveur réduisent le volume de données qui parvient à votre destination, ce qui permet de diminuer les coûts de bande passante, les coûts de stockage et la charge de traitement. Les filtres peuvent s’appliquer en fonction d’adresses, de signatures d’événements, de sélecteurs de fonctions, de valeurs de transaction ou de toute autre propriété des données de bloc. Les transformations permettent de remodeler les charges utiles, de décoder les données encodées en ABI, de calculer des valeurs dérivées et de générer des enregistrements dans un schéma compatible avec les tables de votre base de données.
Comment Quicknode Streams assure la diffusion en continu de données blockchain
Quicknode Streams est un service dédié au streaming de données blockchain et à la transformation, au chargement et à la mise en forme (ETL) qui fournit des données en temps réel et historiques sur plus de 80 chaînes, avec des fonctionnalités intégrées de filtrage, de transformation et de livraison garantie. Streams prend en charge plusieurs types de jeux de données (blocs, transactions, reçus, journaux d'événements, traces) et plusieurs destinations (webhooks, PostgreSQL, Snowflake, Amazon S3, Azure Storage, etc.).
Streams traite les données dans l'ordre de finalité avec des garanties de livraison « exactly-once », gère automatiquement les réorganisations de chaîne en envoyant des charges utiles de correction, et prend en charge le traitement par lots et la compression configurables pour un débit optimal lors des remplissages historiques. Les filtres JavaScript s'exécutent sur l'infrastructure de Quicknode, ce qui vous permet de décoder des événements, de faire correspondre des modèles, de référencer des bases de données clés-valeurs externes et de modeler les charges utiles de sortie avant que les données n'atteignent leur destination. Des modèles de réintégration en un clic fournissent des pipelines préconfigurés pour des ensembles de données courants sur plus de 20 chaînes, avec des estimations transparentes des coûts et des délais d’exécution affichées avant le lancement.
Pour des flux de travail encore plus sophistiqués, Streams s'intègre à Quicknode Functions afin de permettre une automatisation « serverless » sur les données en flux continu. Les fonctions peuvent enrichir les enregistrements avec des données supplémentaires sur la blockchain, appeler des API externes, déclencher des notifications ou exécuter une logique métier arbitraire en réponse à des événements en flux continu. Ensemble, Streams et Functions constituent une plateforme complète de données blockchain qui remplace l'infrastructure ETL personnalisée par une solution gérée et évolutive.
Quelle est la différence entre le streaming et le polling ?
Le polling et le streaming sont les deux méthodes permettant à une application de se tenir informée de l'activité sur la blockchain ; elles se situent aux deux extrémités d'un spectre. Le polling fonctionne selon un principe « pull » : votre application interroge de manière répétée un nœud pour savoir s'il existe de nouvelles données. Le streaming fonctionne selon un principe « push » : un service vous transmet les nouvelles données dès qu'elles sont disponibles. Le tableau ci-dessous les compare selon les critères les plus importants à prendre en compte lors du choix d'une approche.
Dimension
Sondage
Streaming
Flux de données
L'application s'exécute selon un calendrier
Le service envoie des notifications à mesure que les données sont générées
Latence
Limité par l'intervalle de sondage
En temps quasi réel, sans délai d'intervalle
Risque lié aux données manquantes
Lacunes en cas d'échec ou d'omission d'un sondage
Livraison garantie et sans interruption
Gestion des réorganisations
C'est vous qui le construisez vous-même
Intégré via des charges utiles de correction
Charge opérationnelle
C'est vous qui gérez et adaptez le nombre de workers
Géré par le prestataire
Pour une comparaison plus approfondie des deux modèles de diffusion et pour savoir dans quels cas chacun est le plus adapté, consultez la rubrique « Diffusion par sondage ou en continu ».
Quels sont les cas d'utilisation courants du streaming de données sur la blockchain ?
Le streaming convient à toute charge de travail devant réagir rapidement à l’activité sur la blockchain ou maintenir une base de données synchronisée en permanence. Parmi les exemples courants, on peut citer le suivi en temps réel des portefeuilles et des placements, les tableaux de bord DeFi, les bots de trading et de liquidation, la surveillance de la frappe et de la vente de NFT, les alertes de fraude et de conformité, ainsi que les entrepôts d’analyse qui ingèrent chaque bloc. Chacun de ces cas tire parti d’une faible latence et d’une diffusion sans interruption, plutôt que d’instantanés périodiques. Pour un répertoire plus complet des cas d’utilisation, consultez les cas d’utilisation du streaming blockchain.
Comment le streaming gère-t-il les données en temps réel par rapport aux données historiques ?
Un pipeline de streaming performant traite les données en temps réel et les données historiques comme une seule chronologie continue, plutôt que comme deux systèmes distincts. Vous pouvez démarrer un flux à partir d’un bloc situé loin dans le passé, le laisser remonter l’historique, puis passer de manière transparente aux blocs en direct une fois qu’il a rattrapé la pointe de la chaîne. Cela évite de devoir gérer deux pipelines avec deux chemins de code différents. Pour comprendre les compromis entre les données récentes et archivées, consultez la section « Données blockchain en temps réel vs données historiques », et pour les stratégies de remontée de l’historique, consultez la section « Comment accéder aux données historiques de la blockchain ».
Comment le streaming gère-t-il les réorganisations de la chaîne ?
Les réorganisations constituent la partie la plus délicate de l'exploitation des données blockchain en temps réel, car un bloc déjà traité par votre application peut être remplacé par un bloc concurrent. Les services de streaming en production gèrent ce problème en transmettant les données dans l'ordre de finalité et, lorsqu'une réorganisation se produit, en envoyant des charges utiles de correction qui indiquent à votre destination quels blocs ne sont plus canoniques, afin qu'elle puisse annuler les enregistrements concernés. Cela élimine l'un des éléments les plus sujets aux erreurs dans les pipelines personnalisés. Pour en savoir plus, consultez l'article « Qu'est-ce qu'une réorganisation de blockchain ? ».
En quoi le streaming diffère-t-il de l'indexation ?
Le streaming et l'indexation répondent à des problèmes connexes mais distincts. Le streaming concerne la diffusion : acheminer les données de la blockchain vers leur destination au fur et à mesure de leur génération. L'indexation concerne l'organisation : structurer ces données dans une base de données interrogeable afin de pouvoir effectuer rapidement des requêtes historiques et agrégées. De nombreuses équipes utilisent le streaming pour alimenter un index, puis interrogent cet index à des fins d'analyse. Consultez les articles « Qu'est-ce que l'indexation de la blockchain ? » et « Interroger les données de la blockchain » pour comprendre comment ces éléments s'articulent entre eux.
Foire aux questions
Le streaming de données via la blockchain revient-il à un abonnement WebSocket ?
Pas tout à fait. Un abonnement WebSocket est une connexion de bas niveau qui diffuse des événements tant que la connexion reste ouverte, mais il n'offre aucune garantie de livraison et s'interrompt en cas de perte de connexion. Le streaming en production ajoute à ce modèle de diffusion de base la livraison « exactly-once », l'ordre de finalité, les corrections de réorganisation, le filtrage côté serveur et le remplissage historique.
Le streaming me garantit-il de ne manquer aucun bloc ?
Oui, avec un service de production. La livraison garantie signifie que le fournisseur met les données en mémoire tampon et effectue des tentatives répétées jusqu’à ce que les données de chaque bloc soient confirmées à destination ; vous bénéficiez ainsi d’un flux ininterrompu, même en cas de brève interruption de service de votre terminal. Les services d’événements de type « push », tels que Quicknode Webhooks, appliquent les mêmes principes de fiabilité aux notifications d’événements.
Puis-je filtrer les données en flux continu avant qu'elles n'atteignent leur destination ?
Oui. Le filtrage côté serveur vous permet d'effectuer des filtrages en fonction d'adresses, de signatures d'événements, de sélecteurs de fonctions, de valeurs ou de toute autre propriété du bloc, de sorte que seuls les enregistrements qui vous intéressent vous soient transmis. Cela permet de réduire les coûts liés à la bande passante, au stockage et au traitement, car vous ne recevez jamais les données dont vous n'avez pas besoin.
Le streaming peut-il remplacer un pipeline ETL sur mesure ?
Pour la plupart des équipes, oui. Un service de streaming géré regroupe l'extraction, le filtrage, la transformation, la diffusion, les tentatives de reprise, le classement et la gestion des réorganisations au sein d'un seul pipeline, éliminant ainsi les nombreux éléments mobiles d'une pile ETL développée en interne. Vous configurez les données souhaitées et leur destination, et le fournisseur se charge du reste.
Vers quelles destinations les données de streaming peuvent-elles être transmises ?
Parmi les destinations courantes, on peut citer notamment les URL de webhooks, PostgreSQL, Snowflake, Amazon S3 et Azure Blob Storage. Cela vous permet d'acheminer les données en continu directement vers le backend de votre application, votre entrepôt de données ou votre stockage d'objets, sans avoir à développer de connecteurs personnalisés pour chacun d'entre eux.
