Door Chris Latimer, vice-president, productbeheer, DataStax
Er wordt momenteel veel gesproken over het belang van het streamen van gegevens en gebeurtenisgestuurde architecturen. Je hebt er misschien wel eens van gehoord, maar weet je echt waarom het zo belangrijk is voor veel ondernemingen? Streamingtechnologieën ontsluiten de mogelijkheid om inzichten vast te leggen en direct actie te ondernemen op gegevens die uw organisatie binnenstromen; ze zijn een cruciale bouwsteen voor het ontwikkelen van applicaties die in realtime kunnen reageren op gebruikersacties, beveiligingsbedreigingen of andere gebeurtenissen. Met andere woorden, ze zijn een belangrijk onderdeel van het bouwen van geweldige klantervaringen en het genereren van inkomsten.
Hier volgt een kort overzicht van wat streamingtechnologieën doen en waarom ze zo belangrijk zijn voor ondernemingen.
Gegevens in beweging
Organisaties zijn behoorlijk goed geworden in het creëren van een relatief compleet beeld van zogenaamde “data in rust” – het soort informatie dat vaak wordt vastgelegd in databases, datawarehouses en zelfs datameren om onmiddellijk (in “realtime”) of om later brandstoftoepassingen en analyse te gebruiken.
Steeds meer gegevens die worden aangestuurd door activiteiten, acties en gebeurtenissen die in realtime in een organisatie plaatsvinden, komen binnen vanaf mobiele apparaten, winkelsystemen, sensornetwerken en routeringssystemen voor telecommunicatiegesprekken.
Hoewel deze ‘gegevens in beweging’ uiteindelijk kunnen worden vastgelegd in een database of een andere winkel, is het uiterst waardevol terwijl het nog in beweging is. Voor een bank kunnen gegevens in beweging het mogelijk maken om fraude in realtime te detecteren en er onmiddellijk op te reageren. Winkeliers kunnen productaanbevelingen doen op basis van de zoek- of aankoopgeschiedenis van een consument, zodra iemand een webpagina bezoekt of op een bepaald artikel klikt.
Denk aan Overstock, een Amerikaanse online retailer. Het moet consequent boeiende klantervaringen bieden en inkomsten halen uit actuele mogelijkheden om inkomsten te genereren. Met andere woorden, Overstock zocht de mogelijkheid om razendsnelle beslissingen te nemen op basis van gegevens die in realtime binnenkwamen (over het algemeen hebben merken 20 seconden om contact te leggen met klanten voordat ze naar een andere website gaan).
“Het is als een zelfrijdende auto”, zegt Thor Sigurjonsson, hoofd data-engineering bij Overstock. “Als je wacht op feedback, ga je van de weg af.”
De gebeurtenisgestuurde architectuur
Om de waarde van hun gegevens te maximaliseren zoals ze zijn gemaakt – in plaats van uren, dagen of zelfs langer te wachten om ze te analyseren als ze eenmaal in rust zijn – had Overstock een streaming- en berichtenplatform nodig, waarmee ze realtime besluitvorming konden gebruiken om te leveren gepersonaliseerde ervaringen en het aanbevelen van producten die waarschijnlijk goed zullen worden ontvangen door klanten op het perfecte moment (heel snel, met andere woorden).
Gegevensberichten en -streaming zijn een belangrijk onderdeel van een gebeurtenisgestuurde architectuur, een software-architectuur of programmeerbenadering die is gebouwd rond het vastleggen, communiceren, verwerken en vasthouden van gebeurtenissen – muisklikken, sensoruitgangen en dergelijke.
Het verwerken van gegevensstromen houdt in dat er acties worden ondernomen op een reeks gegevens die afkomstig zijn van een systeem dat continu ‘events’ creëert. De mogelijkheid om deze non-stop stream te doorzoeken en afwijkingen te vinden, te herkennen dat er iets belangrijks is gebeurd en er snel en op een zinvolle manier op te reageren, is wat streamingtechnologie mogelijk maakt.
Dit in tegenstelling tot batchverwerking, waarbij een applicatie gegevens opslaat nadat ze deze hebben ingevoerd, verwerkt en vervolgens het verwerkte resultaat opslaat of doorstuurt naar een andere applicatie of tool. De verwerking begint mogelijk pas nadat, laten we zeggen, 1000 gegevenspunten zijn verzameld. Dat is te traag voor het soort toepassingen dat nodig is reactieve betrokkenheid op het punt van interactie.
Het is de moeite waard om even stil te staan bij dat idee:
- De punt van interactie kan een systeem zijn dat een API-aanroep doet, of een mobiele app.
- Verloving wordt gedefinieerd als het toevoegen van waarde aan de interactie. Het kan gaan om het geven van een trackingnummer aan een klant nadat deze een bestelling heeft geplaatst, een productaanbeveling op basis van de browsegeschiedenis van een gebruiker, of een factureringsautorisatie of service-upgrade.
- reactief betekent dat de betrokkenheidsactie in realtime of bijna realtime plaatsvindt; dit vertaalt zich in honderden milliseconden voor menselijke interacties, terwijl machine-naar-machine-interacties die plaatsvinden in het sensornetwerk van een energiebedrijf, bijvoorbeeld, zo’n bijna realtime reactie mogelijk niet vereisen.
Wanneer berichtenwachtrij niet genoeg is
Sommige ondernemingen hebben ingezien dat ze waarde moeten halen uit hun data-in-motion en hebben hun eigen gebeurtenisgestuurde architecturen samengesteld uit een verscheidenheid aan technologieën, waaronder berichtgeoriënteerde middlewaresystemen zoals Java-berichtenservice (JMS) of berichtenwachtrij (MQ ) platformen.
Maar deze platforms waren gebouwd op een fundamenteel uitgangspunt dat de gegevens die ze verwerkten van voorbijgaande aard waren en onmiddellijk moesten worden weggegooid zodra elk bericht was afgeleverd. Hiermee wordt in wezen een zeer waardevol bezit weggegooid: gegevens waarvan kan worden vastgesteld dat ze aankomen bij een bepaald moment in de tijd. Tijdreeksinformatie is van cruciaal belang voor toepassingen die asynchrone analyse omvatten, zoals machine learning. Zonder dit kunnen datawetenschappers geen modellen voor machine learning bouwen. Een modern streamingsysteem moet niet alleen evenementen doorgeven van de ene service naar de andere, maar ze ook opslaan op een manier die hun waarde of gebruik later behoudt.
Het systeem moet ook schaalbaar zijn om terabytes aan gegevens en miljoenen berichten per seconde te beheren. De oude MQ-systemen zijn voor geen van beide ontworpen.
Pulsar en Kafka: de oude garde en de verenigde uitdager van de volgende generatie
Zoals ik hierboven heb aangegeven, zijn er veel keuzes beschikbaar als het gaat om berichten- en streamingtechnologie.
Ze omvatten verschillende open-sourceprojecten zoals RabbitMQ, ActiveMQ en NATS, samen met eigen oplossingen zoals IBM MQ of Red Hat AMQ. Dan zijn er de twee bekende, verenigde platforms voor het verwerken van realtime gegevens: Apache Kafka, een zeer populaire technologie die bijna synoniem is geworden met streaming; en Apache Pulsar, een nieuwer platform voor streaming en berichtenwachtrijen.
Beide technologieën zijn ontworpen om de hoge doorvoer en schaalbaarheid aan te kunnen die veel gegevensgestuurde toepassingen vereisen.
Kafka is door LinkedIn ontwikkeld om datacommunicatie tussen verschillende diensten bij het jobnetwerkbedrijf te vergemakkelijken en werd in 2011 een open source-project. In de loop der jaren is het een standaard geworden voor veel ondernemingen die op zoek zijn naar manieren om waarde te halen uit realtime gegevens.
Pulsar is ontwikkeld door Yahoo! om berichten- en gegevensproblemen op te lossen waarmee toepassingen zoals Yahoo! Mail; het werd in 2018 een open source-project op het hoogste niveau. Hoewel het Kafka nog steeds in populariteit inhaalt, heeft het meer functies en functionaliteit. En er is een heel belangrijk onderscheid: MQ-oplossingen zijn uitsluitend berichtenplatforms en Kafka behandelt alleen de streamingbehoeften van een organisatie – Pulsar behandelt beide behoeften van een organisatie, waardoor het het enige beschikbare uniforme platform is.
Pulsar kan realtime, high-rate use-cases zoals Kafka aan, maar het is ook een completere, duurzamere en betrouwbaardere oplossing in vergelijking met het oudere platform. Om bijvoorbeeld streaming en wachtrijen te hebben (een asynchroon communicatieprotocol waarmee applicaties met elkaar kunnen praten), zou een Kafka-gebruiker iets als RabbitMQ of andere oplossingen moeten gebruiken. Pulsar daarentegen kan veel van de use-cases van een traditioneel wachtrijsysteem aan zonder add-ons.
Pulsar heeft andere voordelen ten opzichte van Kafka, waaronder een hogere doorvoer, betere schaalbaarheid en geo-replicatie, wat vooral belangrijk is wanneer een datacenter of cloudregio uitvalt. Geo-replicatie stelt een applicatie in staat om gebeurtenissen zonder onderbreking naar een ander datacenter te publiceren, zodat de app niet uitvalt en eindgebruikers niet worden getroffen door een storing. (Hier is een meer technische vergelijking van Kafka en Pulsar).
Afsluiten
In het geval van Overstock werd Pulsar gekozen als streamingplatform van de retailer. Hiermee bouwde het bedrijf wat zijn hoofd engineering Sigurjonsson beschrijft als een “geïntegreerde laag van gegevens en verbonden processen die worden bestuurd door een metagegevenslaag die de implementatie en het gebruik van geïntegreerde herbruikbare gegevens in alle omgevingen ondersteunt.”
Met andere woorden, Overstock heeft nu een manier om realtime gegevens in de hele organisatie te begrijpen en erop te reageren, waardoor het bedrijf indruk kan maken op zijn klanten met magisch snelle, relevante aanbiedingen en gepersonaliseerde ervaringen.
Als gevolg hiervan kunnen teams gegevens tijdens de vlucht betrouwbaar transformeren op een manier die gebruiksvriendelijk is en minder data-engineering vereist. Dit maakt het veel gemakkelijker om hun klanten tevreden te stellen en uiteindelijk meer inkomsten te genereren.
Bezoek ons voor meer informatie over DataStax hier.
Over Chris Latimer
Chris Latimer is een technologiemanager wiens carrière meer dan twintig jaar omvat in verschillende functies, waaronder enterprise-architectuur, technische presales en productbeheer. Hij is momenteel Vice President Product Management bij DataStax, waar hij zich richt op het bouwen van de productstrategie van het bedrijf rond cloud messaging en het streamen van evenementen. Voordat hij bij DataStax kwam, was Chris senior productmanager bij Google, waar hij zich richtte op API’s en API-beheer in Google Cloud. Chris is gevestigd in de buurt van Boulder, Colorado, en als hij niet aan het werk is, is hij een fervent skiër en muzikant en geniet hij van de oneindige verscheidenheid aan buitenactiviteiten die Colorado te bieden heeft met zijn gezin.
