Antwoorden>Meer informatie over blockchain-datastreaming>Wat is blockchain-datastreaming?
Wat is blockchain-datastreaming?
// Tags
streaming van blockchain-gegevensrealtime blockchain-gegevens
TL;DR: Blockchain-datastreaming is een push-gebaseerde methode voor het opvragen van blockchain-gegevens, waarbij nieuwe blokken, transacties en gebeurtenissen automatisch naar je applicatie of database worden verzonden zodra ze op de blockchain worden gegenereerd. In plaats van dat je applicatie herhaaldelijk aan het knooppunt vraagt „is er al iets nieuws?“ (polling), stuurt een streamingdienst je de gegevens zodra deze beschikbaar zijn. Streaming vermindert de latentie, voorkomt dat gebeurtenissen worden gemist, vereenvoudigt uw backend-architectuur en schaalt veel efficiënter dan traditionele request-response-patronen.
De eenvoudige uitleg
Er zijn twee fundamentele manieren om gegevens uit een systeem op te halen: je kunt erom vragen (pull), of ze worden naar je verzonden (push). Gedurende het grootste deel van de geschiedenis van blockchain hebben ontwikkelaars het pull-model gebruikt. Je applicatie stuurt een RPC-verzoek naar een node, de node stuurt een antwoord terug en je applicatie beslist wanneer er opnieuw een verzoek wordt gedaan. Dit is het polling-patroon. Het is eenvoudig te implementeren, maar inefficiënt, vooral wanneer je applicatie gesynchroniseerd moet blijven met de meest recente status van de blockchain.
Streaming draait dit model om. In plaats van dat je applicatie duizenden keren per dag vraagt „wat is er in het laatste blok gebeurd?”, stel je één keer een datapijplijn in en levert de streamingdienst de gegevens van elk nieuw blok aan je applicatie of database zodra deze worden geproduceerd. Je applicatie wordt zo een afnemer van een continue gegevensstroom in plaats van een aanvrager van afzonderlijke gegevensmomentopnames.
De vergelijking is hetzelfde als het verschil tussen het elke vijf minuten verversen van een nieuwswebsite en het abonneren op een pushmelding die je op de hoogte brengt zodra er nieuws binnenkomt. Uiteindelijk krijg je in beide gevallen dezelfde informatie, maar het pushmodel is sneller, efficiënter en betrouwbaarder.
Hoe blockchain-datastreaming werkt
Een streamingdienst fungeert als tussenlaag tussen blockchain-knooppunten en uw applicatie of gegevensinfrastructuur. Aan de invoerzijde maakt de dienst verbinding met knooppunten binnen de ondersteunde netwerken en verwerkt elk nieuw blok zodra dit is vastgelegd. De dienst haalt de ruwe blokgegevens eruit, waaronder headers, transacties, transactiebewijzen (met gebeurtenislogboeken) en, optioneel, uitvoeringstraces. Deze ruwe gegevens vormen het volledige verslag van alles wat er in dat blok is gebeurd.
Wat de verwerking betreft, past de streamingdienst alle filters of transformaties toe die je hebt geconfigureerd. Misschien ben je alleen geïnteresseerd in ERC-20-overdrachtsgebeurtenissen uit een specifieke reeks contracten. Een filter, geschreven in JavaScript of een andere ondersteunde taal, wordt toegepast op de gegevens van elk blok en laat alleen de records door die aan je criteria voldoen. Deze filtering aan de serverzijde is cruciaal voor de efficiëntie, omdat dit betekent dat je bestemming alleen de gegevens ontvangt en opslaat die je daadwerkelijk nodig hebt, en niet het volledige blok.
Wat de aflevering betreft, worden de gefilterde gegevens naar de door u geconfigureerde bestemming verzonden. Dit kan een webhook-URL zijn waarop uw applicatie luistert, een PostgreSQL-database, een Snowflake-datawarehouse, een Amazon S3-bucket, Azure Blob Storage of een ander ondersteund eindpunt. De streamingdienst zorgt voor de afleveringsgaranties, waaronder herhalingspogingen bij mislukking, ontdubbeling en de juiste volgorde, zodat uw bestemming een naadloze, opeenvolgende stroom van blockchain-gegevens ontvangt.
Streaming versus traditionele ETL-benaderingen
Bij traditionele blockchain-ETL-pijplijnen (Extract, Transform, Load) moeten ontwikkelaars een omvangrijke infrastructuur opzetten en onderhouden. Een typische aangepaste ETL-opstelling bestaat uit een polling-worker die volgens een schema RPC-eindpunten aanroept om nieuwe blokken op te halen, een verwerkingslaag die de ruwe gegevens decodeert en transformeert, een database-writer die records invoegt, een foutverwerker die herpogingen en storingen beheert, een reorg-detector die gegevens van verlaten forks identificeert en terugdraait, en monitoring die waarschuwt wanneer een van deze componenten uitvalt. Elk onderdeel voegt complexiteit toe en elk onderdeel is een potentieel storingspunt.
Streamingdiensten bundelen dit alles in één beheerde pijplijn. Het extraheren, filteren, transformeren, leveren, de herhalingslogica, het ordenen en het omgaan met reorganisaties vinden allemaal plaats op de infrastructuur van de aanbieder. Uw verantwoordelijkheid beperkt zich tot het instellen van welke gegevens u wilt, waar u ze naartoe wilt sturen en hoe u ze wilt vormgeven. Dit vermindert de technische inspanning die nodig is voor het opzetten en onderhouden van een blockchain-gegevensinfrastructuur aanzienlijk.
Het prestatieverschil is eveneens aanzienlijk. Een op polling gebaseerde pijplijn heeft inherent een latentie die gelijk is aan het polling-interval. Als je worker elke 5 seconden controleert op nieuwe blokken, kun je tot wel 5 seconden achterlopen op de chain tip, zelfs als alles perfect werkt. Gemiste polls (als gevolg van fouten, rate limits of het opnieuw opstarten van de worker) vergroten deze achterstand. Streaming elimineert de polling-latentie omdat gegevens worden gepusht zodra ze beschikbaar zijn. Op ketens met een hoge doorvoercapaciteit, waar om de paar honderd milliseconden blokken worden geproduceerd, is dit verschil van belang voor toepassingen die gevoelig zijn voor latentie.
Belangrijkste kenmerken van productiestreaming
Er zijn verschillende kenmerken die streaming op productieniveau onderscheiden van een eenvoudige WebSocket-abonnement. Dankzij gegarandeerde levering komen de gegevens van elk blok precies één keer op de bestemming aan, zelfs als de verbinding tijdelijk wegvalt of de bestemming kortstondig niet bereikbaar is. De streamingdienst slaat de gegevens op in de buffer en blijft het verzenden herhalen totdat de levering is bevestigd, zodat er nooit hiaten in je gegevens ontstaan.
Levering in definitieve volgorde houdt in dat gegevens binnenkomen in de volgorde die de blockchain als canoniek beschouwt. Op blockchains met variabele definitieve bevestigingstijden wacht de streamingdienst tot een blok voldoende is bevestigd voordat het wordt geleverd. Zo wordt voorkomen dat je applicatie gegevens verwerkt die later door een reorganisatie ongeldig zouden kunnen worden verklaard. Wanneer er toch een reorganisatie plaatsvindt, detecteert de dienst de splitsing, stelt vast welke blokken niet langer canoniek zijn en verstuurt corrigerende gegevenspakketten, zodat je bestemming de gegevens dienovereenkomstig kan bijwerken.
Met historische backfilling kunt u dezelfde streamingpijplijn gebruiken voor historische gegevens, en niet alleen voor nieuwe blokken. In plaats van een apart ETL-proces op te zetten voor historische gegevens en een ander voor realtime gegevens, configureert u één enkele stream met een startblok in het verleden en laat u deze de geschiedenis afwerken, waarna er naadloos wordt overgeschakeld naar realtime zodra de stream de tip van de keten heeft ingehaald. Deze geïntegreerde pijplijn vereenvoudigt uw architectuur en waarborgt de consistentie tussen historische en realtime gegevens.
Door filtering en transformatie aan de serverzijde wordt de hoeveelheid gegevens die uw bestemming bereikt verminderd, waardoor de kosten voor bandbreedte, opslag en verwerking worden verlaagd. Filters kunnen worden toegepast op adressen, gebeurtenissignaturen, functieselectors, transactiewaarden of elke andere eigenschap van de blokgegevens. Transformaties kunnen payloads hervormen, ABI-gecodeerde gegevens decoderen, afgeleide waarden berekenen en records uitvoeren in een schema dat overeenkomt met uw databasetabellen.
Hoe Quicknode Streams blockchain-datastreaming mogelijk maakt
Quicknode Streams is een speciaal ontwikkelde blockchain-dienst voor datastreaming en ETL die realtime en historische gegevens uit meer dan 80 blockchains levert, met ingebouwde filter- en transformatiefuncties en gegarandeerde levering. Streams ondersteunt verschillende soorten datasets (blokken, transacties, ontvangstbewijzen, gebeurtenislogboeken, traces) en diverse bestemmingen (webhooks, PostgreSQL, Snowflake, Amazon S3, Azure Storage en meer).
Streams verwerkt gegevens in volgorde van definitieve vastlegging met een ‘exactly-once’-leveringsgarantie, gaat automatisch om met reorganisaties van de blockchain door correctie-payloads te verzenden, en ondersteunt configureerbare batchverwerking en compressie voor een optimale doorvoer tijdens het aanvullen van historische gegevens. JavaScript-filters draaien op de infrastructuur van Quicknode, waardoor u gebeurtenissen kunt decoderen, patronen kunt matchen, externe sleutel-waarde-opslagplaatsen kunt raadplegen en output-payloads kunt vormgeven voordat de gegevens hun bestemming bereiken. Backfill-sjablonen met één muisklik bieden vooraf geconfigureerde pijplijnen voor veelvoorkomende datasets in meer dan 20 blockchains, waarbij transparante schattingen van de kosten en de voltooiingstijd worden weergegeven voordat u begint.
Voor nog geavanceerdere workflows kan Streams worden geïntegreerd met Quicknode Functions, waardoor serverloze automatisering op basis van streaminggegevens mogelijk wordt. Functions kan records verrijken met aanvullende on-chain gegevens, externe API’s aanroepen, meldingen activeren of willekeurige bedrijfslogica uitvoeren als reactie op streaminggebeurtenissen. Samen vormen Streams en Functions een compleet blockchain-gegevensplatform dat maatwerk-ETL-infrastructuur vervangt door een beheerde, schaalbare oplossing.
Wat is het verschil tussen streaming en polling?
Polling en streaming zijn de twee manieren waarop een applicatie op de hoogte blijft van de activiteit op de blockchain, en ze bevinden zich aan tegenovergestelde uiteinden van een spectrum. Polling is pull-gebaseerd: je applicatie vraagt herhaaldelijk aan een node of er nieuwe gegevens beschikbaar zijn. Streaming is push-gebaseerd: een dienst levert nieuwe gegevens aan je zodra deze beschikbaar zijn. In de onderstaande tabel worden beide methoden vergeleken op basis van de aspecten die het belangrijkst zijn bij het kiezen van een aanpak.
Afmeting
Enquête
Streaming
Gegevensstroom
De applicatie haalt gegevens op volgens een schema
De service voert gegevens door zodra deze worden gegenereerd
Vertraging
Begrensd door het peilinginterval
Bijna in realtime, zonder vertraging
Risico van ontbrekende gegevens
Leemtes als een peiling mislukt of wordt overgeslagen
Gegarandeerde levering zonder onderbrekingen
Afhandeling van reorganisaties
Je bouwt het zelf
Ingebouwd via correctie-payloads
Operationele belasting
Je beheert en schaal de workers
Beheerd door de aanbieder
Voor een uitgebreidere vergelijking van de twee leveringsmodellen en wanneer elk model de voorkeur verdient, zie ‘polling versus streaming’.
Wat zijn veelvoorkomende toepassingen van blockchain-datastreaming?
Streaming is geschikt voor elke workload die snel moet reageren op activiteiten op de blockchain of een database continu gesynchroniseerd moet houden. Bekende voorbeelden zijn onder meer het in realtime bijhouden van wallets en portefeuilles, DeFi-dashboards, handels- en liquidatiebots, het monitoren van het slaan en verkopen van NFT’s, waarschuwingen voor fraude en naleving, en analyse-warehouses die elk blok verwerken. Al deze toepassingen profiteren van een lage latentie en een naadloze gegevenslevering in plaats van periodieke momentopnames. Zie de use cases voor blockchain-streaming voor een uitgebreider overzicht van patronen.
Hoe gaat streaming om met realtime- en historische gegevens?
Een krachtige streamingpijplijn behandelt realtime- en historische gegevens als één doorlopende tijdlijn, in plaats van als twee afzonderlijke systemen. U kunt een stream starten vanaf een blok ver in het verleden, deze achteraf door de geschiedenis laten aanvullen en vervolgens naadloos overgaan naar live-blokken zodra deze de tip van de keten heeft ingehaald. Dit voorkomt dat er twee pijplijnen met twee verschillende codepaden moeten worden onderhouden. Om de afwegingen tussen recente en gearchiveerde gegevens te begrijpen, zie realtime versus historische blockchaingegevens, en voor strategieën voor het achteraf aanvullen, zie hoe u toegang krijgt tot historische blockchaingegevens.
Hoe gaat streaming om met ketenreorganisaties?
Reorganisaties vormen het moeilijkste aspect van het verwerken van live blockchain-gegevens, omdat een blok dat je applicatie al heeft verwerkt, kan worden vervangen door een concurrerend blok. Streamingdiensten in de productieomgeving lossen dit op door gegevens in definitieve volgorde te leveren en, wanneer er een reorganisatie plaatsvindt, correctiepakketten te versturen die je bestemming laten weten welke blokken niet langer canoniek zijn, zodat de betreffende records kunnen worden teruggedraaid. Hiermee wordt een van de meest foutgevoelige onderdelen van aangepaste pijplijnen weggenomen. Lees meer in het artikel ‘Wat is een blockchain-reorganisatie?’.
Waarin verschilt streaming van indexering?
Streaming en indexering lossen verwante, maar toch verschillende problemen op. Bij streaming draait het om de levering: het in realtime naar de bestemming sturen van on-chain gegevens. Bij indexering draait het om organisatie: het structureren van die gegevens in een doorzoekbare database, zodat je snel historische en geaggregeerde zoekopdrachten kunt uitvoeren. Veel teams gebruiken streaming om een index te vullen en voeren vervolgens zoekopdrachten uit op de index voor analytische doeleinden. Lees de artikelen ‘Wat is blockchain-indexering? ’ en ‘Zoeken in blockchain-gegevens’ om te zien hoe de verschillende onderdelen in elkaar passen.
Veelgestelde vragen
Is het streamen van blockchain-gegevens hetzelfde als een WebSocket-abonnement?
Niet helemaal. Een WebSocket-abonnement is een verbinding op laag niveau die gebeurtenissen pusht zolang de socket open blijft, maar het biedt geen leveringsgaranties en stopt als de verbinding wordt verbroken. Productiestreaming voegt bovenop dat basis-pushmodel „exactly-once“-levering, finaliteitsvolgorde, reorg-correcties, filtering aan de serverzijde en het aanvullen van historische gegevens toe.
Garandeert streaming dat ik geen enkel blok mis?
Ja, met een productiedienst. Gegarandeerde levering houdt in dat de aanbieder de gegevens in de buffer opslaat en het verzendproces herhaalt totdat de gegevens van elk blok op je bestemming zijn bevestigd, zodat je een onderbrekingsvrije feed krijgt, zelfs als je eindpunt even buiten gebruik is. Op push gebaseerde gebeurtenisdiensten zoals Quicknode Webhooks passen dezelfde betrouwbaarheidsprincipes toe op gebeurtenismeldingen.
Kan ik streaminggegevens filteren voordat ze hun bestemming bereiken?
Ja. Met filtering aan de serverzijde kunt u zoeken op adressen, gebeurtenissignaturen, functieselectors, waarden of andere eigenschappen van het blok, zodat alleen de records worden geleverd die voor u van belang zijn. Dit verlaagt de kosten voor bandbreedte, opslag en verwerking, omdat u nooit gegevens ontvangt die u niet nodig hebt.
Kan streaming een op maat gemaakte ETL-pijplijn vervangen?
Voor de meeste teams is dat inderdaad het geval. Een beheerde streamingdienst bundelt het extraheren, filteren, transformeren, leveren, herhalen, sorteren en omzetten in één pijplijn, waardoor de vele losse onderdelen van een zelfgebouwde ETL-stack komen te vervallen. Je stelt in welke gegevens je wilt en waar ze naartoe moeten, en de aanbieder regelt de rest.
Naar welke bestemmingen kunnen streaminggegevens worden verzonden?
Veelgebruikte bestemmingen zijn onder andere webhook-URL’s, PostgreSQL, Snowflake, Amazon S3 en Azure Blob Storage. Hierdoor kun je streaminggegevens rechtstreeks naar de backend van je applicatie, je datawarehouse of je objectopslag sturen, zonder dat je daarvoor voor elk daarvan een eigen connector hoeft te bouwen.
