Waarom stream processing een ingrediënt van echte waarde is.

Stream processing, het verwerken en analyseren van data terwijl deze nog stroomt tussen verschillende systemen. Waarom zou je dit binnen je landschap willen toepassen? Lees in deze blog er van alles over en lees hoe Leo onder andere de verschillen tussen message queues en stream processing uitlegd.

In deze blog

In deze blog wil ik even stilstaan bij een waardevol onderdeel binnen het integratie patroon event streaming, namelijk stream processing.  Stream processing is het verwerken en analyseren van data terwijl deze nog stroomt tussen verschillende systemen. In deze blog bespreken we wat het concept inhoudt en waarom je het binnen je landschap zou willen toepassen. We leggen uit wat voor type architectuur goed bij stream processing past en beargumenteren waarom het misschien wel hét patroon is voor IoT omgevingen. Lees alles over stream processing in deze blog. Wil je eerst wat meer weten over het integratiepatroon event streaming? Lees dan alles over event streaming via deze link.

Stream processing is het verwerken van een stroom van data. Als methode is het sterk gerelateerd aan IoT, maar ook erg nuttig in big data projecten gezien de mogelijkheid om grote hoeveelheden  data snel en continue te verwerken. Het wordt gebruikt om direct events (veranderingen in omstandigheden) te ontdekken en te verwerken gedurende de periode dat die gegevens van A naar B stromen.

In deze korte periode kan door middel van verwerkingen en analyse direct waardevolle nieuwe informatie ontleent worden aan je datastromen. Bijvoorbeeld een notificatie die verzonden wordt wanneer een bepaalde grenswaarde van je warehouse overschreden wordt, waarbij de gegevensstromen afkomstig zijn van sensoren en systemen die vervolgens door middel van stream processing verwerkt worden om een waarschuwing af te geven wanneer de grenswaarde is bereikt. Ten opzichte van traditionele processing is de event stream, inclusief de data, nu zelf actief en kan deze continue bevraagd worden voor nieuwe inzichten.

Figuur 2. Verschil tussen traditionele database en event stream processing.

Zoals al aangegeven, wordt tegenwoordig (vaak) de waarde van data vastgesteld door informatie die afgeleid is van het verwerken van verschillende data. Het moment van het afleiden van de informatie kan cruciaal zijn voor het maken van beslissingen. Vertraging tussen het moment van datageneratie en de analyse van deze data resulteert vaak in een mindere, of zelfs geen, waarde van de informatie.

Door stream processing binnen je organisatie in te zetten verbeter je de omstandigheden om ‘real time besluitvorming’ scenario’s te ondersteunen. Stream processing maakt het mogelijk om sneller inzichten te leveren, vaak nog binnen milliseconden nadat een actie en/of event het systeem heeft getriggerd.

Er zijn allerlei methodes beschikbaar voor het verwerken van data. Ongeacht je usecase zijn er verschillende integratiepatronen die ingezet kunnen worden om tot het gewenste resultaat te komen.  Er zijn tegenwoordig echter duidelijke usecases waar men zou kiezen voor een stream processing integratiepatroon in plaats van een batch-verwerkingspatroon. Bijvoorbeeld bij het verwerken van een continue stroom met een eindeloos aantal gebeurtenissen. In deze stroom moeten real-time patronen worden herkent en de resultaten gegroepeerd, geanalyseerd en direct verwerkt. Dit moet voor meerdere datastromen tegelijkertijd worden gedaan.

Event driven architecture

Stream processing kan tevens beschreven worden als een type event-driven architectuur die steeds vaker wordt ingezet om de groeiende vraag naar informatie door de steeds groter wordende ‘data gedreven maatschappij’ op te lossen. Wat is een ‘event’ gedreven architectuur?

In de event-driven architectuur is er een component die iets uitvoert wat van belang is voor andere componenten. Het ene component (producer) produceert een gebeurtenis, een verslag van de gebeurtenis wordt opgeslagen, en het andere component (consumer) consumeert deze gebeurtenis zodat het haar eigen taken kan uitvoeren als resultaat van (of beïnvloed door) deze gebeurtenis.

Het uit elkaar halen van consumers en producers geeft een event-driven architectuur de volgende voordelen:

  • Asynchroon verkeer
  • Afzonderlijke componenten
  • Makkelijk schaalbaar
  • Geen additioneel development voor one-to-many integraties

Het verschil tussen stream processing en de message-queue

Er zijn twee varianten van event-driven architectuur namelijk message queues en
stream processing. Laten we even kort de verschillen tussen de twee bekijken.

Binnen ‘traditionele’ event driven architecturen plaatst de producent een bericht in een queue dat gericht is naar een specifieke consument. Dat bericht wordt in de wachtrij gehouden (meestal op een first-in, first-out volgorde) totdat de consument het ophaalt, waarna het bericht wordt verwijderd.

Met stream processing zijn berichten niet gericht op een bepaalde ontvanger, maar worden ze gepubliceerd op een specifiek onderwerp en beschikbaar gesteld voor alle consumenten. Alle ontvangers kunnen zich op dat onderwerp abonneren en het bericht lezen. Omdat het bericht voor alle consumenten beschikbaar moet zijn, wordt het bericht niet verwijderd wanneer het uit de stream wordt gelezen.

Stream processing, een waardevolle tool voor IoT

Stream processing is de ideale architectuur om grote volumes event driven data berichten effectief te verwerken en te analyseren. Dit is van toepassing op IoT usecases dankzij het gebruik van time series data. Time series data kunnen we omschrijven als een verzameling van observaties verkregen door het continue uitvoeren van metingen. Als men deze gegevens zou plotten in een grafiek zou er altijd één as de tijd bevatten. Deze type data is vaak het resultaat van het gebruik maken van sensoren in variërende operaties zoals verkeer, industrie en gezondheidszorg. Het kan ook het resultaat zijn van log data, bijvoorbeeld: transactielogs, activiteitenlogs en allerlei andere vormen van logs

Hoe veelbelovend stream processing ook mag zijn, organisaties moeten er wel op letten dat stream processing als patroon of architectuur niet altijd het wondermiddel is. Er zijn genoeg situaties en usecases te benoemen waarin andere integratiepatronen effectiever en/of efficiënter zullen zijn. Een voorbeeld waar stream processing niet de juiste architectuur is, is wanneer de gehele dataset meerdere keren moet worden verwerkt of wanneer het verwerken gebeurt op basis van willekeurige toegang. Bovendien is het analyseren in de ‘edge’ van de infrastructuur, zoals bijvoorbeeld bij ‘edge machine learning’, een architectuur die niet goed past bij stream processing.

Figuur 3. Retail voorbeeld van twee datastromen, één van verkoop en één van inkomende goederen. Deze data stromen worden continu verwerkt en geanalyseerd, waardoor real-time informatie over de actuele voorraad beschikbaar is.

Stream processing is de favoriete keuze geworden voor veel, door gebeurtenissen gestuurde, systemen of patronen. Het biedt verschillende voordelen:

  • Real-time beslissingen faciliteren
  • Het verrijken van ‘traditionele’ BI met ‘predictive’ BI
  • De mogelijkheid om grote volumes ‘ruwe’ data te verwerken en analyseren zonder deze eerst te hoeven opslaan in bijvoorbeeld een datawarehouse of datalake.

Over het algemeen vergroot het de flexibiliteit van je data-integratie landschap enorm. En daarmee is het een ingrediënt van echte waarde voor dat landschap.

Door Leo Bekhuis, Software Engineer @ eMagiz

Twitter
LinkedIn
WhatsApp
Email
nl_NL_formal