Sander Borny

tools en algoritmen met TenguEenvoudig opzetten van gedistribueerde stream analyse

Academiejaar 2015-2016Faculteit Ingenieurswetenschappen en ArchitectuurVoorzitter: prof. dr. ir. Daniël De ZutterVakgroep Informatietechnologie

Master of Science in de industriële wetenschappen: informaticaMasterproef ingediend tot het behalen van de academische graad van

Begeleiders: ing. Merlijn Sebrechts, ir. Thomas VanhovePromotor: prof. dr. ir. Filip De Turck

Sander Borny

tools en algoritmen met TenguEenvoudig opzetten van gedistribueerde stream analyse

Academiejaar 2015-2016Faculteit Ingenieurswetenschappen en ArchitectuurVoorzitter: prof. dr. ir. Daniël De ZutterVakgroep Informatietechnologie

Master of Science in de industriële wetenschappen: informaticaMasterproef ingediend tot het behalen van de academische graad van

Begeleiders: ing. Merlijn Sebrechts, ir. Thomas VanhovePromotor: prof. dr. ir. Filip De Turck

iv

Voorwoord

Met dit dankwoord wil ik me richten naar allen die geholpen hebben bij het tot stand komen

van deze masterproef.

Vooreerst dank ik mijn begeleiders Merlijn Sebrechts en Thomas Vanhove. Voor hun raadge-

vingen en adviezen doorheen de masterproef, alsook de aanzet gegeven voor het thema.

Graag wil ik ook Femke Ongenae, Pieter Bonte en Femke De Backere bedanken voor hun

begeleiding voor het eerste deel van de masterproef.

Ook dank aan iedereen die de masterproef nagelezen heeft en de steun van familie en vrienden.

Sander Borny, 5 juni 2016

v

Toelating tot bruikleen

”De auteur(s) geeft (geven) de toelating deze masterproef voor consultatie beschikbaar te stel-

len en delen van de masterproef te kopieren voor persoonlijk gebruik. Elk ander gebruik valt

onder de bepalingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting

de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.”

”The author(s) gives (give) permission to make this master dissertation available for consulta-

tion and to copy parts of this master dissertation for personal use. In the case of any other

use, the copyright terms have to be respected, in particular with regard to the obligation to

state expressly the source when quoting results from this master dissertation.”

Sander Borny, 5 juni 2016

vi

Abstract

Het opzetten van stream analyse tools en het gebruik hiervan kan een grote instapdrempel

zijn voor onderzoekers. In deze masterproef wordt onderzocht of het gebruik van Apache

Storm, een stream processing tool, kan vereenvoudigd worden. Dit met betrekking tot het

hergebruik van bestaande algoritmen en topologieen, net als het ontplooien en het aanpassen

ervan te vereenvoudigen. Door dit te implementeren op het Tengu platform die als backend

gebruik maakt van het cloud management framework Juju, kunnen Apache Storm topologieen

gemodelleerd worden die op een gebruiksvriendelijke manier in de cloud worden gedeployed.

Kernwoorden: Stream Processing, Tengu, Juju, Apache Storm

Simple configuration of distributed stream analysistools and algorithms with Tengu

Sander Borny

Supervisor(s): Merlijn Sebrechts, Thomas Vanhove

Abstract— This article tries to take the first steps to simplify the use ofApache Storm and the algorithms that can be implemented with it. This bysimplifying the reuse of existing algortihms and providing a smoother expe-rience to modify topologies. By using the Tengu platform Storm topologiescan be modeled and visually modified in a GUI, allowing users a high levelview of the topology while still having control over the structure.

Keywords—Stream Processing, Tengu, JuJu, Apache Storm

I. INTRODUCTION

Setting up stream analysis tools and using them can be a bigbarrier. In this work Apache Storm[1] is being researched tosee if the use of this stream processor can be simplified. Thisby simplifying the reuse of existing algortihms and modifyingtopologies. By implementing this on the Tengu[3] platformwhich uses as back-end JuJu[2], a cloud management frame-work, Apache Storm topologies may be modeled and deployedin a user-friendly way.

This article introduces new ways to deploy, configure andsetup topologies by only using a graphical user interface(GUI).This will be evaluated by working out different situations atopology can be in and timing the downtime while it is beingmodified.

The structure of this article is as follows: Section II gives anoverview over the Tengu platform and how the deployment andconfiguration of premade topologies can be simplified. SectionIII discusses how topologies can be modelled in a JuJu environ-ment to allow modifications to the topology. An evaluation isgiven in Section IV and Section V concludes with a final con-clusion.

II. SIMPLIFYING DEPLOYMENT

A. Tengu

Tengu offers users a platform to quickly set up, configure andmanage big data environments without needing a deep under-standing of these services. The architecture of Tengu is based onJuJu, a service orchestration framework, which allows servicesto be deployed by using JuJu charms. These charms tell JuJuhow to manage a service and how they can interact with othersby defining relations. Relations allow communication betweentwo charms. Either charm can ask information that the othercharm made available.

B. Deploying existing topologies

A first step to simplify the use of Apache Storm is allow-ing users to deploy existing topologies without having to setupconfiguration or using the command line. Therefore an exist-ing charm[4] has been updated and extended, which deployed

topologies where the source code is available in public reposi-tories on Github. The charm now also allows deployment fromprivate repositories and downloadable jars.

This stormdeployer charm is connected to a Storm charmwhich represents the Nimbus server. All topologies who need tobe deployed are downloaded from their repositories and storedlocally. They are then compiled and started on the Nimbus.

C. Automating configuration

Deploying full topologies with stormdeployer is one possibil-ity to deploy topologies. However topologies which use externalservices such as Apache Kafka[5] and MongoDB[6] need addi-tional configuration. Usually topologies who use these servicesare deployed with the IP-addresses and ports as configuration.Because we are inside a JuJu environment all this information isavailable for the charms which have a relation with each other.

A MongoDB-Kafka charm is introduced for topologies whichuse these two services. This charm requires relations to the Nim-bus, MongoDB and Kafka. For every relation the IP-address andport is retrieved and saves on the Nimbus. As soon as all of theseservices are up and running the topology is started. As soon asone or more services stop, the topology will be stopped as well.

Another advantage is that modification to the IP-addressesand ports of Kafka and MongoDB can be detected and allowsthe topology to readjust to the new situation.

III. MODELLING TOPOLOGIES

A. Apache Storm topologies

Apache Storm topologies can be seen as a directed graph withtwo types of nodes. These nodes can either be spouts or bolts.Spouts are responsible to deliver data to the topology and boltsare the nodes which process the data. In order to allow usersto modify topologies to their needs in a GUI, new charms areneeded which represent either spouts or bolts.

The model seen in Figure 1 is the general structure of a Stormtopology in a JuJu environment. A Storm-Topology charm isintroduced to represent a topology. It is responsible to hold thestate of the topology (for instance which bolt charms are part ofthis topology and what class they represent). Sub indicates thatthese charms need a subordinate relation with this charm. Thisindicates that they have to be deployed in the same container asthe Nimbus.

Deploying a storm-topology charm triggers the creation of aApache Maven[7] project which functions as a skeleton projectwhere classes are added or removed by editing charm configu-rations. For each spout and bolt charm there is a configurationsetting to declare the class which it represents. Every time a new

class is loaded into one of these charms, the class is added to theproject.

Building a storm topology requires a main function whichspecifies the structure of the topology. Generating this mainfunction can however become very unstructured so the ApacheStorm Flux framework[8] is used to tackle this problem. Fluxreplaces the main function by an easy to read and configure filein yaml format. An additional feature is that the project does nothave to be recompiled every time a bolt or spout is added to thetopology. Only if a new class is introduced, a recompilation isrequired.

Fig. 1. A Storm topology in a JuJu environment.

Topologies which use external services such as Kafka andMongoDB are handled differently than other charms. Using aKafka spout is pre built in Storm and uses extra configurationsuch as the topic of which messages are pulled, the Zookeepercluster, etc. To offer users this functionality an additional charmis developed called the Kafka-Spout charm. This charm has onlyone purpose, the representation of a Kafka spout and requires ayaml formatted file with configuration options. Zookeeper con-figuration can be omitted and adding a relation from a Kafka-Spout to the Zookeeper cluster will automatically configure thespout.

MongoDB is often used to store json formatted data whichhas been processed by the topology. By adding a relation be-tween a bolt and MongoDB charm, the bolt is transformed intoa MongoDB-Bolt which sole purpose is to store incoming datainto the MongoDB instance.

B. Redeploying topologies

In order to provide a good user experience it is important thatthe running topology accurately represents the situation in theGUI. Therefore whenever a change is made to a spout or boltcharm, an example could be a relation which is added, will trig-ger a redeployment.

Because the topology is a directed graph by nature, we canrebuilt the structure of the topology by using breadth-first searchusing all spouts as starting points. This will generate a new yamlfile with the new topology structure. Additional checks are inplace to minimize the amount of downtime and to verify whether

or not the topology is valid. If the change in the GUI has noimpact on the running topology there is no need to redeploy.

IV. EVALUATION

To evaluate these charms we use the amount of downtimeneeded to restore a topology to the state pictured in the GUI.We can distinguish five different situations that can occur whenchanging a topology and cause downtime:1. Starting a topology without compilation and without unde-ploying the previous topology. This situation occurs when a re-lation between two charms is added and they form a valid topol-ogy.2. A change in the GUI creates an invalid topology and the run-ning topology has to be stopped.3. Starting a topology with compilation without undeploying.This can occur after a new class is added and the topology be-comes valid.4. Starting without compilation with undeploying. Adding abolt with the same class as another can cause this situation.5. Starting with compilation and undeploying. This can occurafter a new class is added in a valid topology.The results can be seen in figure 2. Situation 3 and 5 are worstcase scenarios because they require recompilation and/or unde-ploying a running topology.

Fig. 2. Evaluation of 5 situations in seconds.

V. CONCLUSION

The new charms provide a user friendly way to managetopologies. We tried to support existing topologies by allowingthem to be deployed via URL and automatically configure theirexternal services such as MongoDB and Kafka. To simplify themodification process of topologies we modelled a Storm topolo-gies in different charms and allowed them to be configured viathe GUI.

REFERENCES

[1] Apache Storm, http://storm.apache.org/[2] JuJu, https://jujucharms.com/[3] Tengu, http://tengu.intec.ugent.be/vnew/[4] Stormdeployer, https://jujucharms.com/u/maarten-ectors/stormdeployer/[5] Apache Kafka, http://kafka.apache.org/[6] MongoDB, https://www.mongodb.com/[7] Apache Maven, https://maven.apache.org/[8] Apache Storm Flux, http://storm.apache.org/releases/0.10.0/flux.html

Inhoudsopgave

Lijst van figuren 1

1 Inleiding 1

I Stream Reasoning 3

2 Probleemstelling en doelstelling 4

2.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Literatuurstudie 6

3.1 Stream processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Stream reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3 Linked Stream Data Processors . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.4 CQELS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.5 CQELS Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Conclusie 13

II Stream Processing Tools 14

5 Probleemstelling en doelstelling 15

6 Technologiestudie 17

6.1 Apache Storm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.1.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.1.2 Onderdelen van een lopende topologie . . . . . . . . . . . . . . . . . . 18

6.2 Cloud Modellering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.2.1 Juju . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.2.2 Tengu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7 Stormdeployer 27

7.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

ix

Inhoudsopgave x

7.2 Aanpassingen en uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . . . 28

8 Mongo-Kafka Charm 30

8.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8.2 Opbouw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

9 Modelleren van Storm topologieen 33

9.1 Storm-Topology Charm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

9.2 Bolt Charm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

9.3 Spout Charm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

9.4 Topologie status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

9.5 Opbouwen topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

9.6 Heropbouwen van topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

10 Evaluatie 49

11 Conclusies 55

11.1 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

11.2 Toekomst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Bibliografie 57

Lijst van figuren

3.1 Whitebox architectuur. Bron:[9] . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 CQELS architectuur. Bron:[8] . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 CQELS Cloud architectuur. Bron: [14] . . . . . . . . . . . . . . . . . . . . . 11

6.1 Storm cluster. Bron:[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.2 Apache Storm bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.3 Charm Lifecycle Bron:[2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.4 Relatie tussen Storm en Zookeeper services. Bron:[11] . . . . . . . . . . . . . 22

6.5 Verschillende hooks tussen Storm en Zookeeper services. Bron:[11] . . . . . . 22

6.6 Status environment. Bron:[11] . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.7 Configuratie aanpassen. Bron:[11] . . . . . . . . . . . . . . . . . . . . . . . . 24

6.8 Tengu deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.9 Hauchiwa status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

9.1 Samenhang Storm-Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9.2 Sequentiediagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

9.3 Gerichte graaf met terugverbinding . . . . . . . . . . . . . . . . . . . . . . . . 43

9.4 Gerichte graaf zonder terugverbinding . . . . . . . . . . . . . . . . . . . . . . 43

9.5 Situaties om te herdeployen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

10.1 Juju omgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

10.2 Vereenvoudigde topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

10.3 Topologie met geschaalde Averagebolt . . . . . . . . . . . . . . . . . . . . . . 50

10.4 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Afkortingen

HDFS Hadoop Distributed File System

RDF Resource Description Framework

VPN Virtual Private Network

LXC Linux Containers

DRPC Distributed Remote Procedure Call

JVM Java Virtual Machine

GUI grafische gebruikersomgeving

CQELS Continuous Query Evaluation over Linked Stream

URL Uniform Resource Locator

Hoofdstuk 1

Inleiding

Deze masterproef is een tweeledig onderzoek waarbij beide delen draaien rond het Tengu1

platform. In het eerste deel wordt onderzocht hoe een stream reasoner binnen Tengu kan

worden geıntegreerd. In het tweede deel wordt een onderzoek gevoerd om het gebruik van

stream analyse tools en de algoritmes die erop kunnen worden geımplementeerd te vereen-

voudigen. Dit wordt gedaan met behulp van Tengu waarvan de architectuur toelaat om dit

op een gebruiksvriendelijke manier op te lossen.

Deel 1 maakt duidelijk dat de gekozen stream reasoner, CQELS Cloud, een interessante

toepassing is binnen een cloud omgeving maar niet gebruiksvriendelijk genoeg is om verder

te implementeren. Het verplichte gebruik van verouderde libraries en technologieen brengen

deze masterproef te ver van zijn oorspronkelijke doel. Hiermee wordt de overgang genomen

naar deel 2, stream processing.

Stream analyse tools worden steeds gebruikt in de analyse van big data. Een van de meer

populaire tools hiervan is Apache Storm2. Dit is een open source gedistribueerde realtime

computatie systeem, waarvan het gebruik heel wat voorkennis eist. In dit onderzoek wordt

geprobeerd het hergebruik van bestaande algoritmen en topologieen te vereenvoudigen, net

als het ontplooien en aanpassen ervan. Het vereenvoudigen van het gebruiksproces kan een

grote winst zijn voor onderzoekers die uit een ander veld komen dan big data.

Een eerste stap naar het vereenvoudigen wordt gezet door het toelaten van Storm oplossingen

via Github repositories. Een ontwikkelaar die gebruik wil maken van een algoritme, ontwik-

keld voor het Storm framework, hoeft enkel een Uniform Resource Locator (URL) mee te

geven naar de repository of jar en de Storm oplossing zal automatisch opgezet worden.

De tweede stap is het automatisch configureren van services, dewelke nodig zijn binnen een

Storm oplossing. Dit werd uitgewerkt voor Storm oplossingen die gebruik maken van Apache

1http://tengu.intec.ugent.be/2http://storm.apache.org/

1

Hoofdstuk 1. Inleiding 2

Kafka3 en MongoDB4. Storm oplossingen worden automatisch gestart of gestopt naargelang

deze aanwezig zijn.

Een laatste stap is het modelleren van Storm oplossingen. Deze bestaan uit specifieke ele-

menten zoals spouts en bolts. Deze zijn verantwoordelijk respectievelijk voor het ophalen

en verwerken van data. Alle spouts en bolts worden geplaatst in een geheel, genaamd een

topologie. Het is deze topologie die op een zo laag mogelijk niveau moet kunnen aangepast

worden. Met dit onderzoek is het mogelijk topologieen op te bouwen en aan te passen via een

grafische gebruikersomgeving (GUI) die gebruiksvriendelijk is.

Het resultaat is een geheel van services die in een cloud omgeving de status van Storm op-

lossingen kunnen beheren en aanpassen naargelang de noden van de gebruiker. Met behulp

van de situatie geschetst in de GUI dient de Storm oplossing immers zo snel mogelijk te

worden aangepast. Omdat deze services aanspreekbaar zijn vanuit een GUI is dit niet enkel

gebruiksvriendelijker dan een commandolijn maar heeft dit ook voordelen ten opzichte van

het beveiligingsaspect. Indien deze services aangeboden worden kan het wenselijk zijn dat

toegang tot de machine, waar de Storm cluster uitgevoerd wordt, beperkt is tot administrators

of gebruikers met voldoende toegangsrechten.

De indeling van de masterproef zit als volgt in elkaar. Hoofdstuk 2 geeft de originele pro-

bleemstelling en doelstelling die de aanzet gegeven heeft tot de uiteindelijke doel van de

thesis. Een literatuurstudie wordt gegeven in Hoofdstuk 3, die stream reasoning omlijnt en

het CQELS Cloud framework bespreekt. De conclusie van Deel 1 wordt gegeven in Hoofd-

stuk 4 en bespreekt de reden waarom de focus van de masterproef verlegd is naar stream

processing tools zoals Apache Storm. Hoofdstuk 5 beschrijft de nieuwe probleemstelling en

doelstelling. Een technologiestudie wordt gegeven in Hoofdstuk 6, welke de nodige componen-

ten toelicht die gebruikt worden in Deel 2. Hoofdstuk 7, 8 en 9 beschrijven de implementatie

van de verscheidene stappen die ondernomen zijn om Apache Storm te vereenvoudigen in

gebruik. De beschreven oplossingen kunnen teruggevonden worden op de Github repository:

https://github.ugent.be/sborny/charms. Een evaluatie van deze implementatie wordt gege-

ven in Hoofdstuk 10. Hoofdstuk 11 sluit de masterproef af met een conclusie en een overzicht

van de mogelijkheden in de toekomst.

3http://kafka.apache.org/4https://www.mongodb.com/

Deel I

Stream Reasoning

3

Hoofdstuk 2

Probleemstelling en doelstelling

2.1 Probleemstelling

Binnen het eHealth domein wordt er steeds meer gebruik gemaakt van workflow en proces

management. Een goede workflow zorgt ervoor dat informatie op een geautomatiseerde manier

bij de juiste instanties terechtkomt. Medewerkers vanuit verschillende instanties kunnen zo

samenwerken met de meest up-to-date informatie en zo de gepaste beslissingen nemen.

Een voorbeeld hiervan zijn chronisch zieke patienten die meer en meer korte ziekenhuisop-

names krijgen en die daarnaast ook thuis worden opgevolgd door verpleegkundigen of een

thuiszorgorganisatie. Door het gebruik van verscheidene discrete sensoren kunnen de hande-

lingen van de patient geanalyseerd worden om zo een beter inzicht te krijgen in diens toestand.

Indien afwijkend gedrag gedetecteerd wordt, kan automatisch een workflow opgestart worden

om zo de nodige personen te informeren. Gezien deze analyse persoonsgebonden is, dient

het systeem eenvoudig te kunnen geconfigureerd worden. Verder dient het in staat te zijn

achtergrondkennis, zoals profielinformatie en het ziektedossier, in rekening te brengen om

persoonsgebonden conclusies te nemen.

Er is dus nood aan een reactief systeem dat grote hoeveelheden sensordata kan combineren

met achtergrondkennis om zo tijdig de nodige conclusies te kunnen trekken.

Een use case die gebruikt kan worden, is deze van een patient die chemotherapie nodig heeft

[3]. Bij chemotherapie kunnen veel complicaties voorkomen. Enkele complicaties die in deze

use case als voorbeeld gebruikt worden zijn:

1. Vermoeidheid of verminderde energie: is een vaak voorkomende bijwerking. Langdurige

vermoeidheid wordt bestreden door gerichte medicamenteuze behandelingen (behan-

delingen met medicatie zoals pijnstillers en slaapmedicatie). Regelmatig bewegen is

aangeraden.

4

Hoofdstuk 2. Probleemstelling en doelstelling 5

2. Koorts: bij het optreden van rillingen en/of koorts is het belangrijk om regelmatig de

lichaamstemperatuur op te meten.

De patient kan worden uitgerust met verschillende sensoren om de situatie op te volgen. Zoals

een stappenteller om bij te houden hoeveel beweging de patient heeft en een temperatuursen-

sor om regelmatig zijn temperatuur te meten.

Er zijn verschillende actoren die informatie over de patient kunnen gebruiken. De huisarts,

thuisverpleging en oncoloog zijn enkele voorbeelden. Het verwerken van de binnenkomende

data stroom en de opgeslagen statische informatie kan de progressie van de ziekte in kaart

brengen.

Een drastische verandering in patient kan aantonen dat deze te vermoeid is of in te veel pijn

lijdt. Een workflow kan opgestart worden als een zekere limiet gebroken wordt. Deze workflow

kan de huisdokter of thuisverpleging verwittigen zodat ze de patient beter kunnen opvolgen.

Een verhoogde lichaamstemperatuur wordt best onmiddellijk gemeld aan de huisdokter en/of

de oncoloog.

Het systeem moet dus patient gebonden zijn. Eenzelfde chemo behandeling heeft voor ver-

schillende patienten verschillende combinaties van bijwerkingen. Sommige complicaties zoals

verhoogde lichaamstemperatuur moeten onmiddellijk opgevolgd worden door de arts.

2.2 Doelstelling

Het doel van deze masterproef is het ontwikkelen van een workflow management platform.

Er wordt hierbij gebruik gemaakt van stream reasoning. Streams van informatie komen

steeds meer voor, deze komen van verschillende bronnen zoals sensor data, financiele data

en dergelijke. Deze streams kunnen gecombineerd worden, waarna er reasoners op losgelaten

kunnen worden die hieruit realtime beslissingen kunnen nemen.

Om het workflow systeem op een eenvoudige manier te deployen, wordt er gebruik gemaakt

van het Tengu platform. Tengu laat toe om automatisch big data analysis frameworks,

datastores en andere cloud technologieen te deployen.

Voor het verwerken van de stream data wordt gebruik gemaakt van het Continuous Query

Evaluation over Linked Stream (CQELS) Cloud principe. Deze methode zorgt ervoor dat

stream reasoning op een schaalbare manier kan gebeuren. Huidige oplossingen om linked

stream data te verwerken bestaan, maar ze ondersteunen geen multiprocessing in de cloud.

CQELS Cloud biedt hiervoor een oplossing. Het workflow platform zou hiervan gebruik

kunnen maken door het CQELS Cloud systeem te mappen binnen het Tengu platform.

Hoofdstuk 3

Literatuurstudie

Het worflow management systeem moet een grote hoeveelheid binnenkomende sensor data

kunnen verwerken, en proberen conclusies te trekken door deze te verwerken samen met ach-

tergrondinformatie van de patient. Een methode die hiervoor geschikt is, is stream reasoning

(stroom redenering) die samen geevalueerd is met stream processing (stroom verwerking).

3.1 Stream processing

Stream processing is geevolueerd uit de opkomst van big data. Big data steunt op vier

aspecten, de vier V’s, namelijk: volume, velocity (snelheid), veracity (waarheidsgetrouwheid)

en variety (verscheidenheid). Het volume aspect laat toe om aan batch verwerking te doen.

Een voorbeeld hiervan is Hadoop MapReduce1. Om deze bewerkingen ook op stromen van

data toe te passen is stream processing hieruit geevolueerd. Stream processing kan ingedeeld

worden als deels velocity en deels variety. Batch processing aan de andere kant, heeft meer

voordeel aan het volume aspect van big data.

Een definitie voor stream processing gegeven door Kai Wahner [16];

Stream processing is designed to analyze and act on realtime streaming data,

using continuous queries (i.e. SQL-type queries that operate over time and buffer

windows). Essential to stream processing is Streaming Analytics, or the ability to

continuously calculate mathematical or statistical analytics on the fly within the

stream. Stream processing solutions are designed to handle high volume in real

time with a scalable, highly available and fault tolerant architecture. This enables

analysis of data in motion.

1http://hadoop.apache.org

6

Hoofdstuk 3. Literatuurstudie 7

Vertaling:

Stream processing is ontworpen om realtime data te analyseren, gebruik makend

van continue queries (d.w.z SQL-achtige queries die werken over tijd-en buffer

intervallen). Essentieel voor stream processing is streaming analytics, of de moge-

lijkheid om continue mathematische bewerkingen of statistische analyses op gelijk

welk moment uit te voeren binnen de data stroom. Stream processing oplossin-

gen zijn ontworpen om een groot aantal data te verwerken in realtime met een

schaalbare en fouttolerante architectuur. Dit laat toe om data in beweging te

analyseren.

Enkele voorbeelden van stream processors zijn Apache Storm, Streaming Apache Spark2 en

Samza3.

3.2 Stream reasoning

Stream reasoning is ontstaan om een brug te maken tussen reasoners (systemen die logische

conclusies kunnen nemen uit voorgelegde data) en stream processing. Reasoners werken op

een grote hoeveelheid statische data. Stream reasoning heeft als doel volledige reasoning

mogelijkheden aan te bieden aan streaming systemen. Om logische verbanden te leggen

tussen semantische data4 afkomstig uit streams is het nodig om deze te verwerken samen met

achtergrondinformatie die ook rijk is aan informatie. Voor veel stream reasoners is het echter

niet evident om de performantie aan realtime verwachtingen te laten voldoen.

Volgens Della Valle [7] heeft het semantisch modelleren van data stromen verschillende moei-

lijkheden:

1. Windows: Een stream wordt bekeken door een window, deze duidt aan welke data rele-

vant is om tot een beslissing te komen. Time-based windows werken met een tijdsspanne

in dewelke de binnenkomende data geldig is. Count-based / buffer windows houden dan

weer geen rekening met de tijd, maar zetten een limiet op het aantal data gegevens. Als

gevolg hiervan kan een window niet alle gegevens bevatten of juist zeer veel in een korte

tijd.

2. Tijd: Data stromen kunnen enkel onderzocht worden op het moment dat de sensoren

data uitzenden. Als informatie niet opgevangen en verwerkt wordt dan is de reconstruc-

tie van informatie misschien onmogelijk.

3. Statische data: Door gebruik te maken van statische en stream data kunnen betere

conclusies genomen worden. Enige zorg is wel nodig indien men deze resultaten wil

2http://spark.apache.org3http://samza.apache.org/4 Data die zo georganiseerd is zodat die geınterpreteerd kan worden zonder menselijke hulp.

Hoofdstuk 3. Literatuurstudie 8

bewaren om later opnieuw te gebruiken. In tegenstelling tot dynamische streaming data

heeft statische data meestal geen timestamp om aan te duiden hoe lang deze geldig is.

4. Schaal: De grote throughput van data en de nood om data te linken aan statische

datasets kan heel wat overhead met zich meedragen. Dit heeft een grote impact op de

performantie van de stream reasoner.

5. Geheugen: Door de enorme hoeveelheid van data die verwerkt moet worden, kan deze

niet allemaal opgeslagen worden.

3.3 Linked Stream Data Processors

De term linked data (gekoppelde data) word gedefinieerd door Tom Heath[5] als:

The term Linked Data refers to a set of best practices for publishing and connec-

ting structured data on the Web.

Vertaling:

De term Linked Data is een reeks best practices voor het publiceren en connecteren

van gestructureerde data op het Web.

Het behandelen van linked stream data [15] is reeds op verschillende manieren uitgewerkt.

Hieronder worden verschillende systemen vergeleken. Deze systemen kunnen opgedeeld wor-

den in twee groepen [9] naargelang hun architectuur. Deze twee groepen volgen enerzijds een

blackbox en anderzijds een whitebox architectuur.

De whitebox architectuur (zie Figuur 3.1(Le Phuoc) ) moet zelf de fysische operatoren, zoals

sliding windows en joins, implementeren. De optimizer werkt een logical query plan uit om

een optimale execution plan te vinden. De continuous query wordt steeds uitgevoerd en de

optimizer probeert steeds het optimale plan te vinden. Deze kan veranderen door een wijziging

in data. Processing engines die deze architectuur bevatten zijn Streaming SPARQL[6] en

CQELS.

Een blackbox architectuur wordt gekozen wanneer men deze componenten niet zelf wil imple-

menteren. Deze architectuur gebruikt bestaande systemen als sub-componenten. Het bouwen

van een blackbox systeem vraagt minder moeite, maar deze systemen hebben geen volledige

controle over de sub-componenten. Blackbox architecturen zijn dan ook een stuk minder

performant dan whitebox architecturen [9].

Hoofdstuk 3. Literatuurstudie 9

Figuur 3.1: Whitebox architectuur. Bron:[9]

3.4 CQELS

CQELS realiseert de whitebox architectuur zoals te zien in Figuur 3.2. De query executor

kan beslissen over verschillende fysische query plannen tijdens de levenstijd van de query.

Deze methode laat een zeer flexibel systeem toe, die zich na elke executie kan optimaliseren

naargelang de omgeving verandert. De CQELS engine krijgt als input Resource Description

Framework (RDF) triples en behandelt deze als eerste klas data elementen. Hiervoor zijn er

efficiente datastructuren voor sliding windows en triple storages ontworpen.

De CQELS engine maakt gebruik van een uitbreiding op SPARQL 1.1 voor continuous query’s.

CQELS ondersteunt disk-based processing wanneer de hoeveelheid stroom data te groot wordt

en niet meer in het geheugen past. Hierdoor is de hoeveelheid te verwerken data niet beperkt

tot de capaciteit van het geheugen.

Hoofdstuk 3. Literatuurstudie 10

Figuur 3.2: CQELS architectuur. Bron:[8]

3.5 CQELS Cloud

Linked stream data processing engines zoals CQELS en C-SPARQL proberen zo efficient

mogelijk stream data te integreren met statische linked data. Deze engines hebben echter een

probleem met hun schaalbaarheid. Er kunnen verbeteringen aangebracht worden rondom het

aantal concurrent query’s, stream update frequenties en de hoeveelheid te verwerken data. Le

Phuoc et al. [14] stelt hier een oplossing voor door het ondersteunen van parallel processing

in de cloud.

De elasticiteit die een cloud omgeving aanbiedt, kan grote gevolgen hebben voor linked stream

data processing engines. De engine die op dergelijke cluster loopt, kan automatisch het aantal

processing nodes aanpassen. Stream data is van nature onvoorspelbaar en het aantal parallel

query’s kan at run-time drastisch veranderen. Het gevolg hiervan is een moeilijk te voorspellen

computing load en resource vereisten. CQELS Cloud maakt gebruik van deze elasticiteit met

behulp van algoritmes en data access die parallelization ondersteunen.

Distributed computing (gedistribueerd rekenen) geeft een oplossing voor de schaalbaarheid,

maar zorgt ook voor performantie problemen wanneer veel data van node naar node verplaatst

wordt. Bandbreedte en latency zijn problemen die altijd zullen bestaan in een netwerk. De

CQELS Cloud engine gebruikt hiervoor enkele methoden om deze kosten te beperken. RDF

Hoofdstuk 3. Literatuurstudie 11

streams worden eerst gecomprimeerd aan de hand van de dictionary methode van de CQELS

engine. Dit zorgt ervoor dat triples worden weergegeven als integers. Een tweede methode

om de kost te drukken is het groeperen van verschillende operatoren op dezelfde machine die

dezelfde input nodig hebben. Data die toch verstuurd moet worden over het netwerk, wordt

in grotere units verzameld en in een keer verstuurd om overhead te vermijden.

CQELS Cloud werd reeds gedeployed en geevalueerd op Amazon EC2 [14]. Er werd gebruik

gemaakt van ZooKeeper, Storm en Hbase5 om het model en algoritmes uit te werken. De

architectuur van het systeem is terug te vinden in Figuur 3.3. Deze bestaat uit twee grote

onderdelen, een execution coordinator en operator containers.

Figuur 3.3: CQELS Cloud architectuur. Bron: [14]

De execution coordinator coordineert de cluster die bestaat uit verschillende operator con-

tainers via de services die beschikbaar gesteld zijn door Storm en HBase. Er wordt een

ZooKeeper cluster gebruikt voor zowel Storm als HBase. De global scheduler overziet de

operator containers voor failures en is verantwoordelijk om deze te deployen.

Een query wordt gemapt naar de verschillende operator containers. Elke operator container is

verantwoordelijk voor een set operatoren die de input streams verwerken en terug doorsturen

naar de volgende operator. Een operator container heeft een Storm Supervisor lopen die

luistert naar taken die doorgestuurd worden via Nimbus. De containers beschikken ook over

een HBase client waarvan operators, die data toegang nodig hebben, deze kunnen bereiken

over de hele cluster. De nodes die de rol van operator container hebben zijn ook host voor de

Hadoop Distributed File System (HDFS) DataNodes van de HBase cluster.

5https://hbase.apache.org/

Hoofdstuk 3. Literatuurstudie 12

In CQELS Cloud worden Storm spouts6 gebruikt om data te streamen van de sensoren. De

bolts krijgen een of meerdere input streams van upstream processen. Deze upstream processen

verwerken de tuples en zenden deze verder in de topologie. Deze topologie wordt gegenereerd

uit de logical query plan, gebruik makend van de parallellisatie algoritmes waar de bolts de

verschillende query operators voorstellen. Storm heeft verschillende stream groupings (shuffle

grouping, all grouping en fields grouping) die gebruikt worden om data te routeren naar

verschillende bolts. De shuffle grouping wordt gebruikt bij stateless operatoren (zoals filter)

waar data even verspreid wordt. Fields grouping stuurt de data met een zekere sleutel naar

bolts die een aggregator implementeren voor deze sleutel.

Door Storm’s concept dat elk bericht met zekerheid verwerkt wordt via zijn acknowledgment

principe, laat dit CQELS Cloud toe om aan state recovery te doen met de toevoeging van

timestamps aan elk bericht.

6Zie subsectie Apache Storm

Hoofdstuk 4

Conclusie

CQELS Cloud is een interessant platform dat veel mogelijkheden biedt aan stream reasoning

use cases. Onderzoek naar het mappen van CQELS Cloud binnen Tengu heeft echter enkele

problemen aan het licht gebracht.

Het CQELS Cloud project1 werd origineel ontworpen voor een Amazon EC2 omgeving. Hier-

door gebruikt het project specifieke libraries, zoals Nimbus2 om nodes te initialiseren. Nimbus

is nog niet ondersteund voor Tengu. De publiek beschikbare versie van CQELS Cloud wordt

niet meer ondersteund door de auteur, de source code is ook niet meer beschikbaar en enkel een

jar kan nog gebruikt worden. Deze jar vereist dat de verschillende te gebruiken technologien,

zoals Apache Storm en Hbase, een specifieke versie moeten gebruiken en de configuratie hard

gecodeerd is. De nodige Storm versie is 0.8.2 dewelke niet meer beschikbaar is via Apache

Storm en daardoor niet kan gedeployed worden op Tengu.

Na contact opgenomen te hebben met de auteur van CQELS Cloud werd duidelijk dat deze

versie van CQELS Cloud niet nuttig is om te implementeren binnen Tengu. Een nieuwe versie

van CQELS Cloud wordt momenteel ontwikkeld. Deze zal kunnen werken met recentere

versies van Apache Storm.

Het implementeren van een stream reasoner op het Tengu platform zal hierbij niet verder

uitgewerkt worden.

1https://code.google.com/archive/p/cqels/2http://www.nimbusproject.org/

13

Deel II

Stream Processing Tools

14

Hoofdstuk 5

Probleemstelling en doelstelling

Uit het onderzoek naar CQELS Cloud is gebleken dat binnen het reasoning domein er veel

interesse is om gebruik te maken van stream analyse tools. De instapdrempel om van deze

tools gebruik te maken kan echter groot zijn.

In CQELS Cloud wordt er gebruik gemaakt van Apache Storm om hun algoritmes uit te

voeren. Het opzetten van deze tools en het gebruik ervan vraagt echter heel wat expertise in

het gebruik van Storm. Apache Storm is een veelgebruikte realtime stream processor met een

grote community en werd daardoor uitgekozen om te vereenvoudigen. De architectuur van

Storm laat toe om deze verder te modelleren in kleine afzonderlijke delen.

Een voorbeeld is een onderzoeker die de luchtkwaliteit wil monitoren uit verschillende steden.

Indien er een Storm topologie bestaat die gebruikt kan worden in deze situatie, namelijk het

verzamelen van sensor data, berekeningen hierop uitvoeren en deze doorsturen naar een web-

site waar de resultaten gevisualiseerd worden. De onderzoeker wil deze resultaten misschien

niet op een website plaatsen maar opslaan in een databank of de topologie ervan aanpassen

zodat die het beste werkt in zijn use case.

Het verlagen van de drempel kan twee richtingen uitgaan:

1. Hergebruik van bestaande algoritmen en topologieen vereenvoudigen.

2. Ontplooien en aanpassen van algoritmen en topologieen vereenvoudigen.

Deze richtingen worden behandeld door gebruikers zo weinig mogelijk te confronteren met

de achterliggende configuratie. Voor het deployen van bestaande topologieen wordt de mo-

gelijkheid gegeven om bestaande topologieen te starten door een URL mee te geven naar de

source code of jar. De configuratie van veelgebruikte services in een Storm topologie zoals da-

tabanken en messaging systemen, wordt geautomatiseerd. Als laatste wordt de mogelijkheid

aangeboden om een topologie op een laag niveau te beheren. Hiermee kunnen afzonderlijke

delen in een topologie ingesteld worden.

15

Hoofdstuk 5. Probleemstelling en doelstelling 16

Iedere bolt en spout moet op zijn eigen kunnen beheerd worden en in de topologie zijn plaats

krijgen, dit moet mogelijk zijn door enkel gebruik te maken van een GUI. Dit is handig als

er in de toekomst stores komen waar men spouts en bolts kan kopen gelijkaardig aan huidige

app-stores. Een voorbeeld hiervan is Algorithmia1, waar developers hun algoritmes te koop

kunnen stellen. Een spout of bolt kan dan aangekocht worden en in de topologie geplaatst

worden zonder dat er code aan te pas moet komen.

Een ander systeem dat dit probleem probeert aan te pakken is het open source project Stream-

Flow2, ontwikkeld door Lockheed Martin. Dit systeem probeert zoveel mogelijk instellingen

in een GUI te gieten en de code erachter te verbergen. Het opzetten en aanmaken van nieuwe

Storm oplossingen vergt echter nog heel wat achtergrondkennis en verwacht dat de gebruiker

de nodige elementen in een Storm oplossing zelf kan aanpassen. In deze masterproef proberen

we dit proces zoveel mogelijk te automatiseren.

1https://algorithmia.com/2https://github.com/lmco/streamflow

Hoofdstuk 6

Technologiestudie

6.1 Apache Storm

6.1.1 Algemeen

Apache Storm is een open source realtime distributed computation systeem die een onge-

limiteerde toestroom van data kan behandelen. Het is een framework die data in realtime

probeert te verwerken zoals Hadoop doet voor batch processing. Storm[10] heeft verschil-

lende use cases: stream processing, continue berekeningen en Distributed Remote Procedure

Call (DRPC). Bij DRPC neemt de Storm topologie als input een methode en zijn argumenten

en zal deze resultaten terugsturen naar de gebruiker.

Een Storm cluster[12] (zie Figuur 6.1) bestaat uit een Nimbus die verbonden is aan een

Zookeeper cluster en uit verscheidene worker nodes die elk een supervisor hebben. De Nimbus

is verantwoordelijk voor de verdeling van taken onder de worker nodes, het monitoren van

failures in de cluster en het distribueren van code. Elke worker node heeft een supervisor

proces lopende. Deze luistert naar werk die toegekend is door de Nimbus op de node waar

deze loopt. Zookeeper wordt gebruikt om de nimbus en supervisors te coordineren.

De logica achter een realtime Storm applicatie wordt ontworpen in een topologie. Een topo-

logie is een gerichte graaf. Nodes kunnen opgedeeld worden in twee categorien:

1. Spouts: hebben slechts een doel, het ophalen of aanmaken van data, de individuele data

pakketten worden tuples genoemd. Meestal lezen spouts input data van externe streams

en sturen ze deze verder in de topologie.

2. Bolts: deze nodes zijn verantwoordelijk voor het verwerken van binnenkomende data.

Bolts aanvaarden een input stream en doen een stream transformatie zoals filteren,

aggregeren en joins. Complexe transformaties kunnen uitgevoerd worden door verschil-

lende bolts aan elkaar te koppelen.

17

Hoofdstuk 6. Technologiestudie 18

Figuur 6.1: Storm cluster. Bron:[1]

Verbindingen tussen nodes worden uitgedrukt in stream groupings. Bij het definieren van een

topologie moet voor elke bolt gespecifieerd worden voor welke input streams deze verantwoor-

delijk is. Stream groupings leggen dus de regels op over hoe data uitgewisseld wordt binnen

een topologie.

6.1.2 Onderdelen van een lopende topologie

Storm maakt een onderscheid tussen drie verschillende entiteiten[13] die nodig zijn om een

topologie te runnen op een Storm cluster:

1. Worker proces: deze voert een deel van topologie uit en loopt in zijn eigen Java Virtual

Machine (JVM). Een worker voert een of meerdere executors uit.

2. Executors: zijn threads die binnen een worker proces lopen. Een executor voert een of

meerdere tasks uit. Taken worden serieel uitgevoerd. Een executor gebruikt een thread

voor alle taken die moeten uitgevoerd worden.

3. Tasks: zorgen voor de eigenlijke data verwerking. Elke spout en bolt wordt uitgevoerd

binnen tasks in de cluster. Storm zal, tenzij anders ingesteld, een task per thread

runnen.

Twee topologieen met dezelfde naam kunnen niet op hetzelfde moment actief zijn. De Nimbus

zal de tweede niet aanvaarden. Er is dan ook geen andere manier om een topologie bij te

werken dan deze eerst te stoppen en daarna te herstarten.

Hoofdstuk 6. Technologiestudie 19

6.2 Cloud Modellering

6.2.1 Juju

Inleiding

Juju1 is een open source cloud modelleertaal en management framework. Het laat toe om

snel cloud services te deployen, beheren, schalen en configureren op publieke clouds en in

containers.

Het service model van Juju laat toe om verschillende services automatisch samen te laten

werken aan de hand van relaties. Een voorbeeld hiervan is het opzetten van een Apache

Storm cluster. Het model levert de middelen om deze services samen te laten werken en

uit te schalen. Alle applicatie specifieke operationele kennis, zoals dependencies, scale-out

best practices en integratie mogelijkheden met andere services, zijn samengebundeld in Juju

Charms. Een charm beschrijft dan een bepaalde service zodat andere gebruikers deze service

kunnen deployen zonder veel operationele kennis nodig te hebben. De charm bevat dan ook

de operationele code voor alle mogelijke acties die iemand wil ondernemen met deze service.

Het linken van een Zookeeper node aan een Apache Storm node zal automatisch een event

triggeren dewelke de nodige configuraties zal uitvoeren. Juju is dan ook event-based. Events

worden gepushed naar de state server en juju agents pollen deze en voeren ze een voor een

uit.

Een connectie tussen twee charms noemt men een relationship. Het opzetten van indivi-

duele services kan eenvoudig gebeuren maar het connecteren met andere services is meestal

een lastig en foutgevoelig proces. Elke charm bevat hiervoor een set hooks dewelke deze

relaties automatisch kan opzetten. Het definieren van een relationship kan met het volgend

commando:

juju add-relation zookeeper stormmaster

De Storm charm weet dat deze een Zookeeper node nodig heeft en kan communiceren met de

Zookeeper charm om aan te duiden welke configuraties toegepast moeten worden.

Een bundle is een collectie van charms en hun relationships. Ze geven users de mogelijkheid

om een voorgeconfigureerde cluster van charms te deployen. Het opzetten van een Apache

Storm omgeving kan eenvoudig met:

juju quickstart u/bigdata-charmers/realtime-analytics-with-storm/10

Deze start een ZooKeeper cluster, een Storm-Worker en een Nimbus-Server. Via de juju-gui

charm kan de juju environment visueel bekeken worden. Een Apache Storm bundle geeft een

visuele weergave zoals in Figuur 6.2.

1https://jujucharms.com/

Hoofdstuk 6. Technologiestudie 20

Figuur 6.2: Apache Storm bundle

Structuur van een charm

Charm

hooks

config-changed

install

relation-name-relation-broken

relation-name-relation-changed

relation-name-relation-departed

relation-name-relation-joined

start

stop

upgrade-charm

config.yaml

icon.svg

metadata.yaml

README.md

Een charm is opgebouwd uit metadata, configuratie en extra support bestanden. Om aanzien

te worden als een geldige charm is er maar een verplicht bestand nodig, de metadata.yaml,

dewelke de charm beschrijft. De naam van de charm, de auteur, omschrijving wat deze charm

Hoofdstuk 6. Technologiestudie 21

precies doet en tags (labels) om de charms te kunnen indelen in categorıen zijn enkele van

de mogelijkheden die kunnen voorkomen. De metadata.yaml is ook verantwoordelijk om de

relations van de charm te definieren. Deze bestaan uit provides (aanbieden), requires (nodig

hebben), peers (gelijken) en subordinate (ondergeschikten).

1. Provides: geeft aan welke interfaces de charm aanbiedt.

2. Requires: geeft aan welke interfaces de charm kan consumeren.

3. Peers: deze relations zijn vooral handig voor charms die gebruik maken van clustering.

Twee charms die een peer relationship hebben kunnen onderling corresponderen.

4. Subordinate: Services bestaan uit een of meerdere service units. Deze runnen de service

software en zijn de kleinste entiteit die gemanaged kan worden binnen Juju. Service

units lopen in geısoleerde containers binnen een machine. Dit zorgt ervoor dat de

verschillende services volledig van elkaar gescheiden zijn. Subordinate services laten toe

om verschillende units binnen eenzelfde container te laten lopen en hierdoor kunnen ze

met elkaar communiceren.

De hooks directory bevat bestanden die uitgevoerd worden tijdens de lifecycle van de service.

De lifecycle wordt beınvloed door het uitvoeren van commando’s zoals juju deploy of door

events zoals een relation die toegevoegd wordt met juju relation-add. De lifecycle van een

charm is te zien in Figuur 6.3. De namen komen overeen met de files in de hooks directory.

Figuur 6.3: Charm Lifecycle Bron:[2]

Deze bestaan uit vijf hooks dewelke geımplementeerd kunnen worden door elke charm. De

hooks zijn: install, config-changed, start, stop en upgrade-charm. Voor elke relatie die een

charm kan bezitten, kunnen er vier extra hooks gedefinieerd worden. Bij het toevoegen van

een relatie wordt de relation-joined hook gestart. Deze wordt slechts een keer uitgevoerd en

wordt gebruikt om lokale unit settings in te stellen. Relation-changed wordt minstens eenmaal

uitgevoerd, na de relation-joined hook. Telkens er een setting aangepast wordt aan een van de

charms, die verbonden zijn met elkaar, wordt deze opgeroepen. Relation-departed en relation-

broken worden gebruikt wanneer de relation gebroken wordt. Hooks moeten niet verplicht

Hoofdstuk 6. Technologiestudie 22

aanwezig zijn binnen een charm. Indien er geen acties ondernomen moeten worden tijdens

het verbreken van een relatie kan de relation-departed en relation-broken hooks weggelaten

worden. Een belangrijk idee achter hooks is dat ze idempotent zijn. Dit betekent dat er

geen verschil of probleem mag voorkomen indien de hook slechts een keer of meerdere keren

uitgevoerd worden.

Een uitgewerkt voorbeeld hiervan is een relatie tussen een Storm en Zookeeper service. Storm

heeft een zookeeper node nodig en maakt dit duidelijk in zijn metadata.yaml door de zookeeper

interface te specifieren. De Zookeeper service biedt dan weer deze interface aan (zie Figuur

6.4). Na het uitvoeren van de juju relation-add zal juju de service-units van de Storm

Figuur 6.4: Relatie tussen Storm en Zookeeper services. Bron:[11]

en Zookeeper services informeren zodat er communicatie kan gebeuren tussen de twee. Deze

event zal de nodige hooks oproepen in beide units zodat ze zich juist kunnen configureren

(zie Figuur 6.5).

Figuur 6.5: Verschillende hooks tussen Storm en Zookeeper services. Bron:[11]

Hoofdstuk 6. Technologiestudie 23

Juju environment

Alle charms die gemanaged worden door juju zijn gedeployed binnen een juju environment.

Deze kunnen opgezet worden op verschillende cloud providers (AWS, Microsoft Azure, OpenStack,

...) en zelfs lokaal via LXC op een Ubuntu machine. Het aanmaken van een environment kan

met:

juju bootstrap

Dit zal een machine opzetten voor de geconfigureerde infrastructure provider en de machine

klaarmaken voor de juju state server welke de omgeving zal managen. De state server is

verantwoordelijk om de environment in de staat te brengen die de administrator ingeeft. Het

opzetten van een Storm en Zookeeper instantie kan door:

juju deploy storm

juju deploy zookeeper

juju add-relation storm zookeeper

Deze commando’s communiceren naar de state server, wat de gewenste staat is van de en-

vironment. Juju zal dan twee machines opstarten met de Storm en Zookeeper services zoals

te zien in Figuur 6.6 Het aanmaken van relaties en aanpassen van configuratie gegevens voor

Figuur 6.6: Status environment. Bron:[11]

services gaat ook via de state server. Deze zal de nieuwe configuratie doorsturen naar de

juiste service en de juiste hook oproepen. Een voorbeeld hiervan is de uiport van de storm

interface instellen. Deze situatie is te zien in Figuur 6.7.

Hoofdstuk 6. Technologiestudie 24

Figuur 6.7: Configuratie aanpassen. Bron:[11]

6.2.2 Tengu

Het Tengu platform biedt de mogelijkheid om snel big data omgevingen op te zetten en te

beheren, zonder diepgaande kennis nodig te hebben over deze systemen. Het uittesten van

NoSQL en gedistribueerde services, zoals Apache Storm, kan gemakkelijk en snel opgezet

worden binnen een Tengu omgeving. Tengu kan gedeployed worden op publieke, alsook op

private cloud infrastructuren. Deze is onder andere gedeployed op de Virtuall Wall, een

grootschalig Emulab testbed van iMinds.

Deze componenten, die kunnen opgezet worden met Tengu, kunnen vergeleken worden met

Lego blokken. Net zoals men bij Lego een plan kan gebruikt worden, is dit ook terug te

vinden op Tengu in de vorm van bundles. Bundles zijn componenten die voorgeconfigureerd

opgezet worden zoals een speed en batch processing layer. Naast deze bundles is er ook de

mogelijkheid om zelf alles op te bouwen.

Componenten zijn afzonderlijke tools die automatisch met elkaar kunnen geconfigureerd wor-

den. Dit is mogelijk omdat Tengu gebaseerd is op Juju. Juju verdeelt verschillende tools

onder in Juju charms, die aanzien kunnen worden als afzonderlijke lego blokken. Charms

kunnen verbonden worden aan andere charms om een geheel te vormen.

Een clean Tengu omgeving is in eerste instantie een Juju omgeving die gemodificeerd is (zie

Figuur 6.8). Deze omgeving bestaat uit een aantal machines waar Linux Containers (LXC) op

kunnen draaien. Er is een privaat intern netwerk aanwezig met een gateway, Virtual Private

Network (VPN) en een juju-GUI die kan gebruikt worden om de juju environment visueel voor

te stellen in de browser. Het gebruik van LXC containers maakt het mogelijk om meerdere

services onafhankelijk van elkaar te laten lopen op een machine. Ze weten niet van elkaars

bestaan af en zijn volledig gescheiden. Dit is ook een voordeel ten opzichte van de beveiliging.

De toegang tot de Tengu en Juju management tools gebeurt via de hauchiwa. Het ssh-en

naar de hauchiwa geeft niet enkel toegang tot de server, maar ook tot de verschillende LXC

Hoofdstuk 6. Technologiestudie 25

Figuur 6.8: Tengu deployment

containers waar de Juju charms gedeployed zijn. De toegang tot de afzonderlijke containers is

mogelijk met behulp van juju ssh #container. Figuur 6.9 is een voorbeeld van een status

opvraag vanop een hauchiwa. De opstelling bestaat uit drie machines die een container,

namelijk de juju-gui, lopende hebben.

Figuur 6.9: Hauchiwa status

Het deployen van nieuwe services kan met behulp van het Juju framework. Het opzetten van

een nieuwe service kan met het volgend commando:

juju deploy charm-name name [--to]

De charm-name is de unieke naam van de charm, die aanduidt welke service geınstalleerd

moet worden. De name kan zelf gekozen worden en wordt gebruikt om later configuraties

mee uit te voeren of naar te ssh-en. Met de optionele parameter [--to] wordt aangegeven

Hoofdstuk 6. Technologiestudie 26

waar de service gedeployed wordt. Het deployen van een nieuwe service op Tengu zal telkens

op een lxc container gebeuren. Het deployen van een Apache Storm node op de omgeving

van 6.9 is mogelijk met:

juju deploy storm storm-master --to lxc:0

--to lxc:0 duidt aan dat de storm-master node zal gedeployed worden op een lxc container

op machine 0.

Hoofdstuk 7

Stormdeployer

Een eerste stap om het gebruik van Apache Storm te vereenvoudigen, is het eenvoudig de-

ployen van reeds volledige topologien waaraan geen aanpassingen meer moeten gebeuren.

Zonder hulp van tools moet een gebruiker zelf de Storm cluster opzetten en het project met

de juiste dependencies in een jar verwerken. Het automatisch opzetten van een Storm cluster

is reeds een mogelijkheid met de Storm charm1 stormdeployer. Het deployen van volledige

topologieen kan nog verder uitgebreid worden.

7.1 Algemeen

Stormdeployer2 is een reeds ontwikkelde Juju charm met als doel het eenvoudig deployen van

Apache Storm topologien. Het manueel deployen via de commandolijn kan moeilijkheden

of verwarring met zich meebrengen. De stormdeployer biedt hiervoor een oplossing. Deze

charm werd ontwikkeld voor Ubuntu Precise Pangolin (Ubuntu 12.04) en kan hierdoor niet

gebruikt worden met charms die ontwikkeld zijn voor Ubuntu Trusty Tahr (Ubuntu 14.04).

Het updaten en uitbreiden van deze charm biedt voordelen voor het eenvoudig deployen van

Storm topologien die gebruikt kunnen worden op het Tengu platform.

De stormdeployer charm heeft twee configuratie parameters, de ene specificeert welke topo-

logien moeten gedeployed worden, en de andere welke geundeployed worden. Deployen maakt

gebruik van een yaml file om de deployment configuratie mee te geven. Deze file heeft als

extensie .storm en ziet eruit als volgt:

topology:

- name: naam van de topologie

jar: jar van de topologie

topologyclass: volledige domeinnaam van de klasse van de topologie

1https://jujucharms.com/u/merlijn-sebrechts/storm/trusty/12https://jujucharms.com/u/maarten-ectors/stormdeployer/

27

Hoofdstuk 7. Stormdeployer 28

packaging: packaging formaat (mvn package is enige optie)

repository: git url waar de topologie source code kan gevonden worden

scriptbeforepackaging: optionele script die uitgevoerd wordt voor packaging

scriptbeforedeploying: optionele script die uitgevoerd wordt voor deployment

datasources:

- parameters:

- {name: name1, value: value1}

- {name: name2, value: value2}

type: mysql/mongo/postgres/redis/kafka/etc.

script: extra script voor configuratie

- name: volgende topologie

Deze yaml file wordt ingelezen en gebruikt om de repository te downloaden van github naar

de machine waar de Storm Nimbus gedeployed is. De source code wordt verwerkt tot een jar

met behulp van Apache Maven3. Eventueel worden er nog scripts uitgevoerd voor packaging

of deployment.

7.2 Aanpassingen en uitbreidingen

Sinds subordinate charms geen relation kunnen krijgen met charms van een andere Ubuntu

versie, zijn er enkele aanpassingen nodig om deze charm te laten werken met charms die

ontwikkeld zijn voor trusty. Dit kan verholpen worden door de repository van de charm aan

te passen. De URL van een charm heeft volgend formaat:

cs:~maarten-ectors/precise/stormdeployer-1

De directory /precise/ geeft de Ubuntu versie aan. Door de charm in een lokale repository

te plaatsen en lokaal te deployen wordt dit probleem omzeild, de charm werkt op Ubuntu

Trusty:

juju deploy --repository="/path/to/charms" local:trusty/stormdeployer

De charm laat enkel deployment via source code toe, waar de repository gehost wordt op

Github. Deze methode vereist dat de source code eerst nog gepackaged moet worden op de

Storm node voordat deze gedeployed kan worden. Door niet enkel URLs naar source code

repositorys, maar ook naar jar files zelf toe te laten, kan dit vermeden worden. Deze uitbrei-

ding gebruikt dezelfde yaml configuratie file om deze te deployen. Hieronder een voorbeeld

van een te deployen topologie:

topology:

- name: WordCountTopology

3https://maven.apache.org/

Hoofdstuk 7. Stormdeployer 29

jar: WordCountExample-1.0-SNAPSHOT.jar

topologyclass: com.sborny.wordcountexample.WordCountTopology

packaging: jar

release: https://github.com/.../releases/download/1.0/WordCount.jar

Enkele configuratie opties krijgen een extra betekenis. Packaging laat nu niet enkel mvn

package toe maar ook jar. Deze duidt aan dat de gespecificeerde file een jar is. De extra

optie release geeft een url die aanduidt waar deze kan gedownload worden.

Deze uitbreiding focust zoch voornamelijk op projecten die gehost worden op Github. Door

de toevoeging van een downloadable URL kan dit ook van andere bronnen komen. De locatie

van de jar kan dus door de auteur van de topologie bepaald worden. Binnen Github zijn er

twee mogelijkheden om een jar te publiceren:

1. De jar kan als file geupload worden binnen de repository. Deze methode zal dezelfde

werkwijze gebruiken als die van de source code. Github laat niet toe om een specifieke

file aan te duiden als downloadbaar binnen een repository. Hierdoor wordt de volledige

repository elke keer gedownload. Het bewaren van binaire files binnen de repository

wordt door Github afgeraden. Deze methode wordt dus ook niet toegepast binnen de

uitbreiding.

2. Een tweede optie is gebruik maken van het Github release systeem. Deze laat toe om

bepaalde versies van het project te releasen met toegevoegde files. Een auteur van

een Storm topologie kan dus verschillende versies van zijn topologie publiceren met

bijgevoegde jar files. Deze methode zorgt ervoor dat er slechts een file gedownload moet

worden en dat er ondersteuning is voor verschillende gereleasde versies.

Het deployen via het downloaden van een jar is enkel mogelijk als de URL publiek beschikbaar

is. Het releasen van een private repository via Github is hierdoor niet toegankelijk. De

mogelijkheden van het deployen van private repositories blijft beperkt tot het downloaden

van de source code, en die op de node compilen naar een jar. Om dit mogelijk te maken is er

een extra configuratie parameter beschikbaar gesteld:

juju set stormdeployer "credentials=username:password"

Wanneer deze parameter gezet wordt, zullen deze username en paswoord gebruikt worden om

de private repository te clonen.

Hoofdstuk 8

Mongo-Kafka Charm

Nu een volledige Storm topologie eenvoudig kan opgezet worden via source code of jar, is het

interessant om het aantal configuratie parameters tot een minimum te herleiden.

8.1 Algemeen

Het deployen van een topologie die gebruik maakt van Apache Kafka1 en MongoDB2 heeft

parameters nodig voor de IP-adressen en poorten. Het is handig indien deze parameters

automatisch gedetecteerd worden en als deze gewijzigd worden, ook door de topologie worden

overgenomen.

De charm krijgt een topologie mee als jar en wacht om te deployen tot wanneer alle nodige

componenten actief en beschikbaar zijn. Indien een of meerdere componenten niet meer actief

zijn, wordt de topologie weer gestopt. Bij de implementatie is er een relatie nodig naar een

MongoDB, Zookeeper, Kafka en Storm charm.

8.2 Opbouw

De charm is een subordinate service die gebruik maakt van de volgende interfaces dewelke

gedefinieerd staan in metadata.yaml:

name: mongo-kafka-storm-deployer

summary: mongo-kafka-storm-deployer

maintainer: Sander Borny <sander.borny@ugent.be>

description: |

mongo-kafka-storm-deployer

categories: [app-servers]

1http://kafka.apache.org/2https://www.mongodb.org/

30

Hoofdstuk 8. Mongo-Kafka Charm 31

subordinate: true

requires:

master:

interface: storm

scope: container

database:

interface: mongodb

zookeeper:

interface: zookeeper

kafka:

interface: kafka

De metadata.yaml geeft aan welke relations nodig zijn voor deze charm. De charm heeft

toegang nodig tot de Storm Nimbus container en is hierdoor subordinate voor de stormmaster.

De drie andere interfaces die nodig zijn, zijn de mongodb, zookeeper en kafka interfaces. De

relation naar Zookeeper is nodig, omdat het ip adres van Zookeeper meegegeven wordt bij het

starten van de topologie. Kafka gebruikt deze onder andere om de broker topics bij te houden.

Het opstarten van een storm topologie die van MongoDB en Kafka wil gebruik maken, heeft

het IP adres van MongoDB en Zookeeper nodig. Het IP-adres van kafka is niet nodig om

de topologie te starten. Om te controleren of deze wel degelijk werkende is, wordt deze wel

bijgehouden.

Naast de vijf standaard hooks (start, config-changed, etc.) heeft deze charm nog enkele hooks

met de nodige services. Deze worden uitgevoerd wanneer een relatie aangemaakt of aangepast

wordt met MongoDB, Kafka en Zookeeper. Deze hooks roepen een algemene script storm-

deployer.sh op die de nodige handelingen afwerkt. Iedere keer dat de status van Mongodb,

Zookeeper of Kafka verandert, wordt het IP-adres en poort gecontroleerd en opgeslagen in

een file. Wanneer alle drie de IP-adressen en poorten aanwezig zijn probeert de charm de

topologie te deployen. Bij het verdwijnen van een of meerdere adressen of poorten, wordt de

topologie gestopt. Het testen hiervan wordt verwezenlijkt door de volgende code:

testDeployment()

{

files=( "mongo" "zookeeper" "kafka" )

waitingFor=""

for i in "${files[@]}"

do

if [[ ! -e "/tmp/deployer/${i}_config" ]]; then

waitingFor="$waitingFor $i relation;"

else

regex="^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\:[0-9]+$"

Hoofdstuk 8. Mongo-Kafka Charm 32

[[ ‘cat /tmp/deployer/${i}_config‘ =~ $regex ]] &&

juju-log "$i regex matches" || waitingFor="$waitingFor $i relation;"

fi

done

if [ -z "$waitingFor" ]; then

juju-log "All relations up and running, deploying storm topology"

status-set active

deploy

else

juju-log "Not all relations up, undeploying storm topology"

status-set blocked "Waiting for: $waitingFor"

undeploy

fi

}

Deze methode controleert het bestaan van de drie files waarin de IP adressen en poorten

opgeslagen worden, en zal bovendien nagaan of ze een geldig formaat hebben. Indien er een

relatie niet geldig is, wordt de charm in een blocked status gezet met een gepaste boodschap.

Charms die een interface providen zullen meestal ook settings beschikbaar maken voor charms

die deze interface nodig hebben. Het zetten en opvragen van het IP-adres van een charm kan

op de volgende manier:

relation-set private-adress=192.168.3.20

relation-get private-adress

Het opvragen van statusgegevens wordt het best opgevangen in een relation-changed hook.

In de mongo-kafka charm is het opvragen van een IP-adres geen probleem als dit in de joined-

hook gebeurt. Het opvragen van het poortnummer kan echter even duren, een tweede relation

changed event kan opgeroepen worden waarin het poortnummer wel gedefinieerd is.

Hoofdstuk 9

Modelleren van Storm topologieen

De stormdeployer en mongo-kafka charm gaan ervan uit dat men een volledige topologie

bezit en deze niet meer hoeft aan te passen. Indien men op een lager niveau de topologie wil

beheren, is er nood aan een oplossing die draait rond het modelleren van een Storm topologie.

Om een topologie voor te stellen in de Juju GUI wordt er gebruik gemaakt van drie nieuwe

charms:

1. Storm-Topology charm: voorstelling van een topologie.

2. Spout charm: voorstelling van een Storm spout.

3. Bolt charm: voorstelling van een Storm bolt.

Deze charms zijn subordinate charms die op dezelfde container werken als de Storm Nimbus.

Dit is noodzakelijk omdat het deployen en undeployen van topologieen toegang vereist tot de

Nimbus. De algemene samenhang van deze charms is te zien in Figuur 9.1. Spout en bolt

charms zijn genoodzaakt om niet enkel te verbinden met de storm-topology, maar ook met

Nimbus. Indien er geen relatie gemaakt wordt met een niet-subordinate charm, weet Juju

niet tot welke container deze behoort en deze charm dus niet opgestart worden.

9.1 Storm-Topology Charm

Per topologie is er een storm-topology charm nodig. Deze is verantwoordelijk voor het aanma-

ken van alle bestanden die nodig zijn om de status van de topologie bij te houden. Alle spouts

en bolts binnen een topologie moeten verbonden zijn met de overeenkomstige storm-topology.

Tijdens de installatie van de charm wordt een leeg Storm project van Github gehaald. Dit

is een maven project waaraan nog geen klassen aan toegevoegd zijn. Er wordt geen gebruik

gemaakt van een default Storm project dat bestaat uit een main functie om de topolgie

te definieren. Het genereren van een main functie kan snel onoverzichtelijk en moeilijk te

33

Hoofdstuk 9. Modelleren van Storm topologieen 34

Figuur 9.1: Samenhang Storm-Topology

onderhouden worden. Niet alleen moet deze bij iedere aanpassing in de GUI aangemaakt

worden, maar ook het gebruiken van externe services, zoals Kafka spouts, brengen heel wat

extra configuratie met zich mee.

Om het main klasse probleem op te vangen wordt er gebruik gemaakt van Apache Storm

Flux1. Dit zorgt ervoor dat de main klasse kan vervangen worden door een configuratie file in

yaml formaat. Hierin wordt de topologie beschreven en kan extra functionaliteit opgeroepen

worden. Een voorbeeld van een wordcount topologie , die zinnen genereert en de verschillende

woorden telt, is:

name: "yaml-topology"

config:

topology.workers: 1

spouts:

- id: "spout-1"

className: "backtype.storm.testing.TestWordSpout"

parallelism: 1

bolts:

1http://storm.apache.org/releases/2.0.0-SNAPSHOT/flux.html

Hoofdstuk 9. Modelleren van Storm topologieen 35

- id: "bolt-1"

className: "backtype.storm.testing.TestWordCounter"

parallelism: 1

streams:

- name: "spout-1 --> bolt-1"

from: "spout-1"

to: "bolt-1"

grouping:

type: FIELDS

args: ["word"]

De naam van de topologie kan worden ingesteld met behulp van de charm configuratie para-

meters:

juju set topologyCharm "name=yaml-topology"

Flux maakt gebruik van Maven zodat het toevoegen van dependencies op een eenvoudige

manier kan gebeuren. Indien bolts of spouts toegevoegd worden aan de topologie die extra

dependencies nodig heeft, kunnen deze meegegeven worden aan de storm-topology charm.

Dit gebeurt via de configuratie instelling dependencies, dewelke een URL vraagt naar een

bestand die verschillende <dependency> objecten beschrijft.

In een standaard Storm project waarbij met een main klasse gewerkt wordt, moet bij iedere

aanpassing een nieuwe jar aangemaakt worden. Dankzij Flux kan dit gedrag in sommige ge-

vallen vermeden worden. Enkel wanneer er een nieuwe klasse toegevoegd of aangepast wordt,

moet het project opnieuw gecompileerd worden. Een topologie kan dus sneller gedeployed

worden, indien men aanpassingen doet zoals het verwijderen en schalen van bolts of spouts.

Het deployen via Flux gebeurt door de jar mee te geven en de Flux klasse als main op te

roepen. De topologie configuratie wordt als laatste parameter meegegeven.

storm jar storm.jar org.apache.storm.flux.Flux --remote topologie.yaml

De storm-topology charm ondergaat de volgende stappen:

1. Deploy charm in Juju environment.

2. Toevoegen relation met Storm Nimbus.

3. Wachten op eventuele dependencies.

Hoofdstuk 9. Modelleren van Storm topologieen 36

9.2 Bolt Charm

De bolt charm vertegenwoordigt een generieke bolt klasse in de Storm topologie. Deze kan

gelijk welke klasse voorstellen en kan verbonden worden met andere bolts of spouts. Deze

charm kan hergebruikt worden door een andere klasse in te laden. Het inladen van een klasse

kan door de class configuratie parameter in te stellen met een URL naar de klasse.

Twee bolts kunnen niet met elkaar verbonden worden via dezelfde relatie interface. Het

declareren van een relatie gebeurt volgens onderstaand commando. De volgorde van de bolts

maakt niet uit. Commando’s (1), (2) en (3) zijn equivalent.

(1) juju add-relation bolt1:stormelement bolt2:coworker

(2) juju add-relation bolt2:stormelement bolt1:coworker

(3) juju add-relation bolt1:coworker bolt2:stormelement

Het verbinden van een bolt naar een andere bolt of spout wordt opgeslagen in een topology/graph

bestand. Het formaat van dit bestand is:

bolt1 bolt2 SHUFFLE

bolt1 spout SHUFFLE

...

De eerste twee velden slaan op de twee charms die betrokken zijn in de relatie. Het derde veld

is de stream grouping. Default wordt deze ingesteld op SHUFFLE. Andere stream groupings

zoals ALL, FIELDS, GLOBAL, etc. kunnen ingesteld worden via de configuratie parameter

groupings die wordt ingesteld op een van de twee bolts:

juju set bolt1 "groupings=bolt2(FIELDS word)"

Soms is het noodzakelijk om extra parameters mee te geven aan een bolt. Bijvoorbeeld om

aan te duiden uit welk formaat de binnenkomende tuples bestaan. Op die manier kan de

bolt de binnenkomende tuples verwerken of kan er een IP-adres meegegeven worden aan een

databank. Dit kan via het toevoegen van een methode aan de klasse. Deze methode wordt

opgeroepen voor de klasse actief wordt. Met de prepare-methods configuratie parameter kan

deze methoden worden meegeven. Onderstaand voorbeeld roept twee methoden op en hoe

dit vertaald wordt naar het configuratiebestand van de topologie.

juju set bolt1 "prepare-methods=prepareFormat(json);prepareDb(192.168.20.30,2701)"

bolts:

- id: "bolt1"

className: "tengu.storm.PrepareBolt"

parallelism: 1

Hoofdstuk 9. Modelleren van Storm topologieen 37

configMethods:

- name: "prepareFormat"

args:

- "json"

- name: "prepareDb"

args:

- "192.168.20.30"

- "2701"

Het meegeven van ip-adressen en poorten zoals hierboven aangegeven is een mogelijkheid,

maar is niet gebruiksvriendelijk. Het is handiger dat de bolt charm dit automatisch kan con-

figureren en dat de topologie zichzelf opnieuw deployed indien er een verandering gedetecteerd

wordt.

Door een relatie te leggen tussen een bolt en mongodb charm, wordt de bolt charm automa-

tisch omgevormd naar een MongoBolt. Deze schrijft de binnenkomende json data weg naar

de gespecificeerde databank. Indien er gebruik gemaakt wordt van de mongobolt, wordt de

klasse vanuit de files directory van de charm gekopieerd naar het maven project. De nodige

dependencies bevinden zich ook in de files directory en worden toegevoegd aan de pom.xml

van het maven project indien ze nog niet aanwezig zijn.

Het instellen van het ip-adres en poort van mongodb wordt opgehaald met behulp van het

config-get commando. Wanneer de bolt een geldig ip-adres en poort detecteert, wordt deze

toegevoegd of aangepast aan een database-config bestand. Deze houdt per topologie bij

welke bolts een databank relatie hebben, welk ip-adres en poort ze gebruiken en de naam van

de gebruikte databank.

De gebruiker kan een bolt charm in verscheidene stappen gebruiken:

1. Deploy charm in Juju environment.

2. Toevoegen relatie met Storm Nimbus.

3. Toevoegen relatie met Storm-Topology.

4. Wachten op class of MongoDB relatie.

5. Indien een MongoDB relatie aanwezig is, kan de database naam gezet worden, of de

default test databank gebruikt worden.

9.3 Spout Charm

De spout charm heeft grotendeels hetzelfde concept als de bolt charm. Na het deployen van de

charm wacht deze tot een klasse ingeladen wordt. Het grootste verschil is dat in tegenstelling

Hoofdstuk 9. Modelleren van Storm topologieen 38

tot een bolt charm, de spout slechts een configuratie parameter heeft, namelijk class. Confi-

guratieopties, zoals prepare-methods en database, kunnen extra uitbreidingsmogelijkheden

bieden. De groupings parameter is overbodig sinds een spout steeds met een bolt verbonden

is.

Ondanks de gelijkaardige functionaliteit tussen de spout en bolt charms is er gekozen om deze

niet in een charm te combineren. Twee verschillende charms geven een duidelijker overzicht

in de GUI en zijn dus gebruiksvriendelijker. Dit vermijdt dat een gebruiker twee spouts met

elkaar verbindt. De metadata.yaml van de spout laat geen relaties toe met andere spouts.

Bolts laten dit wel toe. Een laatste voordeel is dat de staat van de topologie eenvoudiger kan

bijgehouden worden achter de schermen. Dit is een belangrijk voordeel in het opbouwen van

de topologie.

Apache Storm en Apache Kafka werken van nature goed met elkaar. Kafka levert de data

aan de spout en Storm verwerkt deze data. Het aanbieden van een gebruiksvriendelijke

Kafka spout is dus een interessante toevoeging. Een Kafka spout heeft, in tegenstelling tot

andere spouts, heel wat extra configuratie variabelen nodig. Hierdoor werd een extra charm

ontwikkeld die het opzetten van een kafka spout tot doel heeft. Deze Kafka-spout charm

biedt geen mogelijkheid om een eigen klasse in te laden en heeft slechts twee configuratie

parameters. De config parameter vraagt een configuratie file in yaml formaat waarin alle

kafka spout configuraties in behoren. Per topologie met een of meerdere kafka spouts is er

nood aan een config bestand. De tweede configuratie parameter is spoutconfigname. Deze

duidt aan welke configuraties in de config file bij welke spout behoren. Hieronder volgt een

voorbeeld van een configuratie voor twee kafka spouts, die via config kan worden meegegeven.

components:

- id: "KafkaBoltKeyValueScheme"

className: "tengu.storm.KafkaBoltKeyValueScheme"

constructorArgs:

- "message"

- id: "MultiScheme"

className: "backtype.storm.spout.SchemeAsMultiScheme"

constructorArgs:

- ref: "KafkaBoltKeyValueScheme"

- id: "zkHosts"

className: "storm.kafka.ZkHosts"

constructorArgs:

- "localhost:2181"

Hoofdstuk 9. Modelleren van Storm topologieen 39

- id: "spoutConfig"

className: "storm.kafka.SpoutConfig"

constructorArgs:

- ref: "zkHosts"

- "test_topic"

- "/kafkaStorm"

- "user_id"

properties:

- name: "scheme"

ref: "MultiScheme"

- id: "spoutConfig2"

className: "storm.kafka.SpoutConfig"

constructorArgs:

- ref: "zkHosts"

- "demo_topic"

- "/kafkaDemo"

- "user_id_demo"

properties:

- name: "scheme"

ref: "MultiScheme"

Het Flux framework laat toe om components (componenten) te definieren. Deze components

stellen Java objecten voor die kunnen gebruikt worden als configuratie opties voor spouts en

bolts. De structuur van een component staat vast en begint altijd met een unieke id. Deze

id kan later gebruikt worden in andere components met behulp van het ref sleutelwoord.

De kafka spout die bruikbaar is in de implementatie, kan telkens gebruikmaken van de

tengu.storm.KafkaBoltKeyValueScheme klasse. Deze heeft als functie het output formaat

van de tuple te beschrijven. In het voorbeeld hierboven krijgt het object de string "message"

mee als parameter en zal Storm tuples uitsturen in het key-value formaat message: value.

Kafka maakt gebruik van Zookeeper om zijn staat bij te houden. De Zookeeper node wordt

hier meegegeven als component met de id zkHosts. De gebruiker kan kiezen om het ip-adres

en de poort van de Zookeeper host hard gecodeerd mee te geven, of gebruik te maken van Juju

zodat dit dynamisch afgehandeld kan worden. Wanneer een relatie gelegd wordt tussen de

kafka-spout charm en een Zookeeper charm, wordt deze informatie automatisch aangevuld.

Wanneer het ip-adres en/of de poort aangepast wordt, zal deze ook mee veranderen in de

configuratie van de kafka spout.

Hoofdstuk 9. Modelleren van Storm topologieen 40

De laatste twee componenten brengen alle vorige samen. De id’s van deze componenten moe-

ten meegegeven worden in de configuratie parameter spoutconfigname van de charm. Deze

moet uniek zijn binnen eenzelfde topologie. De component is een storm.kafka.SpoutConfig

klasse en vraagt dus de volgende constructor argumenten: een zkHost instantie, de naam van

de topic waarvan berichten zullen gehaald worden, een pad op de Zookeeper node waarin de

offset voor kafka topics zal bijgehouden worden en een unique id. De properties beslissen hoe

de kafka spout zich zal gedragen. Het schema die aantoont, hoe de spout zijn output zal

uitzenden, wordt hier meegegeven. Er kunnen hier ook opties meegegeven worden zodat de

spout telkens vanaf het begin van de topic berichten kan afhalen en dit van zodra de topologie

herstart wordt.

Een gebruiker kan de volgende stappen nemen met de Kafka spout:

1. Deploy charm in Juju environment.

2. Toevoegen relatie met Storm Nimbus.

3. Toevoegen relatie met Storm-Topology.

4. Wachten op config bestand.

5. Wachten op spoutconfigname.

6. Indien nodig toevoegen relatie met Zookeeper (moet na het toevoegen van config).

Het sequentiediagram van deze stappen is te vinden in Figuur 9.2.

Figuur 9.2: Sequentiediagram

Hoofdstuk 9. Modelleren van Storm topologieen 41

9.4 Topologie status

De GUI zorgt ervoor dat het opzetten van een topologie op een eenvoudige manier kan opge-

zet worden. De eigenlijke staat van de topologie moet echter achter de schermen bijgehouden

worden. Deze methode moet rekening houden met het feit dat er meerdere topologieen aan-

wezig kunnen zijn in de Juju omgeving, en dat sommige spouts en bolts nog niet verbonden

zijn aan een topologie.

De algemene structuur om de verschillende topologieen bij te houden in een omgeving wordt

in /tmp/storm-topology opgeslagen:

storm-topology

spout-list

bolt-list

buildGraph

runningTopologies

topologyName

spouts

bolts

graph

rebuild

deploy

bolt-preparation

topology.yaml

kafka-config

kafka-spout-config

database-config

Storm-Flux-Skeleton

pom.xml

src/.../tengu/storm

MongoBolt.java

...

Hoofdstuk 9. Modelleren van Storm topologieen 42

De bestanden spout-list, bolt-list en buildGraph worden door elke topologie gebruikt.

spout-list en bolt-list houden bij welke charm bij welke topologie hoort. Alle bestanden

die status bijhouden volgen een formaat zoals key value. Hierbij is de key de naam van de

charm (dewelke uniek is binnen een Juju omgeving). buildGraph wordt gebruikt om topolo-

gieen te herdeployen wanneer een verandering wordt waargenomen. Alle actieve topologieen

worden bijgehouden in runningTopologies.

Voor elke storm-topology charm wordt een directory aangemaakt met de naam van de charm.

De spouts en bolts bestanden houden bij, welke klasse bij welke spout of bolt hoort. Voor een

kafka spout komt een lijn in spouts overeen met kafka-spout storm.kafka.KafkaSpout.

Het inladen van een klasse in een spout of bolt gebeurt dan ook in de volgende volgorde:

1. De URL naar de nieuwe klasse wordt gezet met behulp van juju set spout "class="

2. De topologie waarvan de spout charm deel uitmaakt, wordt opgezocht in spout-list.

3. Er wordt gekeken of de spout reeds deze klasse ingesteld heeft.

4. Indien deze klasse, een klasse is die nog niet eerder gebruikt is, wordt deze opnieuw

gedownload. Als de klasse wel al gebruikt werd, wordt enkel het bestand spouts aan-

gepast.

Het rebuild bestand houdt met een 0 of 1 bij of de topologie opnieuw gecompileerd moet

worden. Het downloaden van een nieuwe klasse zal dus de inhoud van rebuild op 1 zetten.

Bij het herdeployen in buildGraph wordt rebuild ingelezen en terug op 0 gezet.

bolt-preparation houdt per bolt bij welke methodes moeten uitgevoerd worden om de bolt

voor te configureren. Per methode wordt er een lijn toegevoegd die volgend formaat heeft:

boltName methode param1 param2.

De verschillende stream groupings of relaties tussen de bolt en spout charms worden bijgehou-

den in graph. Per Juju relatie is er een lijn in dit bestand aanwezig. Een verbinding tussen

een spout en een bolt kan worden weergegeven als: spout bolt SHUFFLE of bolt spout

SHUFFLE. De volgorde van bolt of spout heeft geen invloed op het bouwen van de topologie

en hangt af van welke hook eerst opgeroepen wordt.

Indien er kafka spouts aanwezig zijn in de topologie worden twee extra bestanden toegevoegd,

namelijk kafka-config en kafka-spout-config. Deze staan respectievelijk in voor het

opslaan van de algemene kafka configuratie en voor het bijhouden van welke configuratie

component bij welke charm hoort.

Per bolt die omgevormd is naar een MongoBolt, worden de databank gegevens opgeslagen

in database-config. De structuur van het bestand is de volgende: charmNaam ip-adres

poort databankNaam. Een charm kan maar een keer voorkomen.

Hoofdstuk 9. Modelleren van Storm topologieen 43

Het maven project dat gecompileerd en deployed wordt, bevindt zich in Storm-Flux-Skeleton.

Bij het deployen van een storm-topology charm wordt een lege instantie van Github gehaald.

Alle toegevoegde dependencies en alle gedownloade klassen worden opgeslaan in de pom.xml.

Bij het deployen naar de Nimbus wordt de jar uit Storm-Flux-Skeleton/target/ gehaald,

en topology.yaml als parameter meegegeven. Deze dient als vervanger van de main klasse,

dewelke de topologie beschrijft.

9.5 Opbouwen topologie

Zoals hierboven beschreven is buildGraph verantwoordelijk voor het bouwen van de topologie,

en dus het opbouwen van topology.yaml. Het script vraagt een inputparameter, namelijk

de topologie naam die deployed moet worden.

Om een topologie correct te deployen, net zoals de gebruiker heeft ingesteld in de GUI,

moet er door de verschillende spout en bolt charms gelopen worden om de juiste structuur

te herkennen. Dit is mogelijk door de topologie te aanzien als een gerichte graaf die geen

terugverbindingen heeft. Een voorbeeld hiervan is scenario 1 (Figuur 9.3). Na een type 2 bolt

wil men een verbinding terugleggen naar een type 1 bolt. Dit is meestal slecht gedrag voor

een topologie en dus te vermijden.

Figuur 9.3: Gerichte graaf met terugverbinding

Door de verbinding tussen twee bolts slechts een maal toe te voegen aan graph, is men

verplicht om een derde bolt bij te plaatsten. Deze derde bolt gebruikt dezelfde klasse als type

1 bolt. Dit is te zien in scenario 2 (Figuur 9.4)

Figuur 9.4: Gerichte graaf zonder terugverbinding

Hoofdstuk 9. Modelleren van Storm topologieen 44

Door met breedte-eerst-zoeken de graaf te doorlopen kunnen alle charms gevonden worden die

deel uitmaken van de topologie, en die logisch verbonden zijn zodat de topologie kan deployen.

De volgorde waarmee de charms ontdekt worden in de graaf duidt aan in welke richting de

stream grouping ingesteld moet worden. Dit is noodzakelijk sinds de stream groupings in het

graph bestand in beide volgordes toegevoegd kunnen worden.

Bij het starten van het buildGraph script wordt de inhoud van topology.yaml gewist en van

nul terug opgebouwd. Eerst worden alle spouts opgezocht via het spouts bestand en wordt

er nagegaan of er kafka spouts aanwezig zijn in de topologie. Indien ja wordt de kafka config,

die opgeslagen is in kafka-config, toegevoegd aan topology.yaml.

Nadat alle spouts toegevoegd zijn, komen de bolts aan de beurt. Ook hier wordt elke bolt in

bolts toegevoegd. Het maakt niet uit of deze bolt geen relatie heeft met een andere spout

of bolt. Flux deployed enkel de bolts die in de stream groupings vermeld worden. Per bolt

wordt ook gekeken of er extra configuratie methoden moeten worden opgeroepen.

Na de spouts en bolts moeten de stream groupings nog ingesteld worden. Hier komt breedte-

eerst-zoeken aan te pas. Alle spouts worden aanzien als start nodes in de graaf en worden in

een wachtrij opgeslagen. Per element worden al zijn kind nodes overlopen en toegevoegd aan

de wachtrij. Bij ieder kind node wordt de stream grouping gegenereerd. Dit herhaalt zich tot

de wachtrij leeg is.

Nadat de stream groupings gedefinieerd zijn, is de topology.yaml volledig en klaar om te

deployen. Apache Storm laat echter niet toe dat twee topologieen met dezelfde naam gelijk-

tijdig worden uitgevoerd. Er moet eerst gecontroleerd worden of er reeds een topologie met

dezelfde naam gedeployed is. Indien dit het geval is, moet deze gestopt worden.

Controleren welke topologieen actief zijn kan op twee manieren. Een eerste methode kan alle

topologieen opsommen met behulp van ingebouwde storm commando’s:

/opt/storm/apache-storm-0.10.0/bin/storm list

De tijd die het commando nodig heeft om dit uit te voeren is evenwel een nadeel. Om zo snel

mogelijk een topologie aan te passen aan de GUI situatie, moet de uitvoertijd van buildGraph

zo laag mogelijk gehouden worden. Met de uitvoertijd als belangrijkste factor werd er gekozen

om de namen van alle lopende topologieen in een apart bestand bij te houden. Controleren

of een topologie reeds actief is, kan met een zoekoperatie bepaald worden.

Het controleren of een topologie actief is, is niet de enige reden om een topologie te stoppen.

In sommige situaties worden enkel nieuwe elementen aan de topologie toegevoegd die geen

invloed hebben op de lopende instantie2.

2Zie 9.6

Hoofdstuk 9. Modelleren van Storm topologieen 45

Nadat gecontroleerd wordt of een topologie gestopt moet worden, wordt er gekeken of het

nut heeft om de nieuwe topologie te deployen. Dit is enkel het geval indien er geen stream

groupings aanwezig zijn. In deze situatie bestaat de GUI enkel uit spout en bolt charms die

geen enkele relatie hebben met elkaar.

De laatste controle gaat na of de jar geupdate moet worden. Indien de waarde in rebuild

een is, wordt het project opnieuw gecompileerd. De topologie kan dan gedeployed worden

met behulp van het aangemaakte topology.yaml bestand.

De pseudocode voor buildGraph:

for elke spout in spouts; do

voeg spout component toe aan topology.yaml

if spout is kafka-spout; do voeg kafka argumenten toe; fi

done

for elke bolt in bolts; do

voeg bolt component toe aan topology.yaml

voeg eventuele configuratie methoden toe

done

maak wachtrij met alle spouts

while wachtrij.size != 0; do

element is wachtrij.pop

while element heeft stream groupings; do

voeg stream grouping toe

voeg kind node toe aan wachtrij als nog niet ontdekt

done

done

if topologie al loopt; do

stop topologie

fi

if topologie.yaml geldig is; do

if kafka-spout in topologie;do

voeg kafka configuratie toe

fi

Hoofdstuk 9. Modelleren van Storm topologieen 46

if jar outdated; do

hercompileren

fi

deploy topologie

fi

9.6 Heropbouwen van topologie

Het heropbouwen van de topologie, of het oproepen van het buildGraph script, kan tijdens

de lifecycle van de spout of de bolt charm op verschillende momenten opgeroepen worden.

Er is een onderscheid tussen de verschillende charms. De topologie wordt afhankelijk van de

charm op verschillende momenten heropgebouwd.

De spout charm heeft de eenvoudigste condities. Wanneer er een klasse in de charm ingeladen

wordt, wordt gekeken of er reeds een klasse aanwezig is, en of deze verschilt van de nieuwe

klasse. Indien er nog geen klasse ingeladen is, wordt er ook buildGraph opgeropen.

Kafka spouts hebben geen configuratie optie om de klasse in te stellen. Hierdoor wordt de

topologie slechts op een wijze opnieuw heropgebouwd. Dit gebeurt door het veranderen van

de stormelement relaties.

De bolt charm heeft, net zoals een spout, de configuratie optie om een klasse in te stellen. Het

veranderen van de hooks stormelement-relation-changed en stormelement-relation-

departed zetten aan tot het oproepen van buildGraph. Het verschil tussen een bolt en een

spout charm ligt in de mogelijkheid om stream groupings te definieren. Na elke aanpassing

aan de groupings configuratie wordt de topologie herstart.

Het leggen van een relatie naar een MongoDB charm, en dus een bolt omvormen naar een

MongoBolt, is ook een reden om de topologie te herstarten. Een MongoBolt aanmaken is het

aanpassen van klasse en vereist hercompilatie.

Het toevoegen of aanpassen van een Juju relatie tussen spouts en bolts is altijd een reden om

de topologie te heropbouwen. Er moet echter opgelet worden dat buildGraph niet meerdere

keren opgeroepen wordt. Bij het aanmaken of verwijderen van een relatie wordt aan beide

charms de nodige hooks uitgevoerd. Een relatie verwijderen tussen een spout en een bolt heeft

als gevolg dat ze beiden de hook storm-element-departed uitvoeren. Hierdoor ontstaat er

een raceconditie tussen de twee charms waardoor de nieuwe topolgie twee keer geredeployed

wordt.

Hoofdstuk 9. Modelleren van Storm topologieen 47

Deze raceconditie kan op twee manieren aangepakt worden:

1. Er kan een extra parameter bijgehouden worden die aangeeft dat de topologie reeds

gedeployed is, en dus dat de hook geen acties meer moet uitvoeren. Dit kan door een 0

of 1 bij te houden in een extra statusbestand binnen de topologie directory. Voordat een

hook buildGraph kan oproepen, wordt er eerst gecontroleerd wat de inhoud is binnen

het statusbestand.

2. Sinds spouts geen relatie kunnen leggen met andere spouts, kan alle logica in de handen

gelegd worden van de bolt charm. Het enige wat een spout moet doen bij het uitvoeren

van de storm-element-relation-changed hook, is het zetten van de charm naam.

De bolt kan deze dan opvragen, zodat hij weet met wie er een relatie gevormd wordt,

waarna hij ook de nodige statusbestanden kan updaten.

De relatie tussen twee bolts is anders dan de relatie tussen een spout en een bolt. Omdat

een van de bolts als coworker, en de ander als stormelement gedefinieerd wordt, is

enkel de hook van de stormelement bolt verantwoordelijk voor het heropbouwen van

de topologie.

In de implementatie wordt gebruik gemaakt van de tweede methode. Zo wordt vermeden dat

een charm onnodig veel werk verricht, en moet er minder status worden bijgehouden over de

topologie. Hooks worden in willekeurige volgorde uitgevoerd. Door de tweede methode te

gebruiken is er zekerheid over wat uitgevoerd wordt en door welke charm.

Het heropbouwen van de topologie garandeert niet dat de topologie opnieuw deployed zal

worden naar de Nimbus. Het redeployen gebeurt enkel als er veranderingen opgemerkt worden

die een impact hebben op de lopende topologie. Als voorbeeld zie onderstaande Figuur 9.5.

Figuur 9.5: Situaties om te herdeployen

Hoofdstuk 9. Modelleren van Storm topologieen 48

In de beginsituatie (a) zijn er vier bolts aanwezig in de topologie, en zijn hun klassen reeds

ingeladen. Spout en bolt 1 zijn verbonden, terwijl bolt 2 en 3 los staan van alle andere. De

lopende topologie heeft dan enkel de spout en bolt 1 actief.

Situatie (b) ontstaat wanneer een relatie gelegd wordt tussen bolt 2 en 3. De hook stormelement

-relation-changed wordt uitgevoerd, dewelke het script buildGraph oproept. Deze zal de

topologie heropbouwen en zal beslissen of de lopende topologie gekilled, en opnieuw gede-

ployed, moet worden. Sinds er geen relaties liggen tussen de lopende topologie en bolt 2 of

bolt 3, is er ook geen stream grouping tussen deze elementen. graphBuilder vergelijkt de

vorige situatie met de nieuwe, en indien deze merkt dat er een uitbreiding mogelijk is zal er

geredeployed worden. Een tweede keer door de graaf lopen zal duidelijk maken dat er geen

extra verbindingen mogelijk zijn en zal dus de lopende topologie niet onderbreken.

In situatie (c) is bolt 1 verbonden met bolt 2 en ontstaat er een stream grouping tussen

beide. Het breedte-eerst-zoeken door de graaf zal nu wel extra paden ontdekken, en de

topologie wordt onderbroken en terug gedeployed met de nieuwe configuratie.

Stel dat in situatie (a) de klasse van bolt 3 ingeladen wordt. Na elke klasse aanpassing van

een spout of bolt moet de topologie gecontroleerd worden of die redeployed moet worden.

Zoals hierboven beschreven zal buildGraph opnieuw door de graaf lopen en geen nieuwe

nodes ontdekken. Dit is ook het geval als de klasse van de spout of bolt 1 aangepast wordt.

Om dit gedrag te vermijden wordt er ook gecontroleerd of er een klasse is aangepast van een

node die ook voorkomt in de stream groupings.

Hoofdstuk 10

Evaluatie

De beschreven charms worden geevalueerd aan de hand van de use case die besproken is in

de probleemstelling. De use case betreft de situatie van een onderzoeker die de luchtkwaliteit

wil monitoren in verschillende steden. Het evaluatiecriterium is de tijd die nodig is om een

aanpassing te maken aan de topologie. Dit wil zeggen vanaf het moment dat de aanpassing

doorgegeven wordt via de Juju GUI, tot de topologie (indien mogelijk) gedeployed is op de

Nimbus.

De opstelling van de Juju omgeving wordt gegeven in Figuur 10.1. Deze bestaat uit een Kafka

charm die de berichten zal toeleveren aan de topologie. Een Zookeeper instantie houdt de

staat bij voor de Kafka topics en Storm cluster. De Nimbus en worker node zorgen voor een

Storm deployment, en een MongoDB charm geeft de mogelijkheid om verwerkte data op te

slaan. De stippellijnen duiden aan dat elke spout en bolt charm een subordinate relatie nodig

hebben naar de Nimbus.

Figuur 10.1: Juju omgeving

49

Hoofdstuk 10. Evaluatie 50

De lopende topologie bestaat uit vijf onderdelen. De Kafka spout is verantwoordelijk voor

het afhalen van berichten van de Kafka topic. Dit zijn json berichten die het volgend formaat

hebben:

{ "collectionId": "1", "message": { "location": "Brugge", "concentration": "0.002" }}

De collectionId duidt aan naar welke collection in MongoDB de json moet worden wegge-

schreven. message houdt de eigenlijke informatie van de sensoren. In het voorbeeld wordt

enkel de locatie en concentratie van de luchtvervuiling meegegeven. Deze json wordt ver-

zonden naar de preparebolt, dewelke instaat om de gegevens uit de json te halen en in een

verwerkbaar formaat door te sturen.

AverageBolt zal per unieke locatie de concentratiegegevens bufferen. Nadat de buffer vol zit,

wordt een gemiddelde berekend en vervolgens doorgestuurd naar jsonbolt. Deze vormt de

gekregen tuples om naar json formaat. De MongoBolt zal de tuples dan uiteindelijk opslaan

in de MongoDB databank.

De stream groupings zijn te zien in Figuur 10.2. De fields grouping gebruikt men om te

bepalen waar de data verwerkt moet worden. Dit verzekert dat alle data die bij een locatie

horen, door dezelfde node verwerkt worden. In dit geval zal een shuffle grouping volstaan

sinds er slechts een node aanwezig is.

Figuur 10.2: Vereenvoudigde topologie

Indien de averagebolt een knelpunt vormt in de topologie kan er een extra bolt bijgeplaatst

worden zoals in Figuur 10.3.

Figuur 10.3: Topologie met geschaalde Averagebolt

Hoofdstuk 10. Evaluatie 51

Vijf situaties zijn uitgekozen om op te meten. Deze zijn individuele acties die ondernomen

worden om bijvoorbeeld Figuur 10.2 aan te passen aan 10.3. In deze situatie wordt een nieuwe

AverageBolt klasse ingeladen, die eerst nog niet verbonden is aan andere topologie elementen.

Dan wordt een eerste verbinding gelegd met preparebolt, jsonbolt en uiteindelijk wordt de

stream grouping aangepast naar een fields grouping die tuples verdeelt op basis van locatie.

De vijf situaties zijn:

1. Opstarten van een topologie zonder compilatie en zonder een topologie te moeten un-

deployen. Deze situatie komt voor indien een relatie tussen twee charms in de topologie

wordt toegevoegd, die voor de eerste keer een geldige topologie vormt. Dit kan voorko-

men indien de verschillende bolts in Figuur 10.2 eerst met elkaar verbonden worden, en

de verbinding tussen de Kafka spout en de prepare bolt als laatste toegevoegd wordt.

2. Een verandering in de GUi zorgt ervoor dat de topologie niet meer geldig is, en dus

geundeployed moet worden. Stel dat er een aanpassing gemaakt wordt aan een topolo-

gie, zoals 10.2 veranderen naar 10.3, kan eerst de relatie tussen Kafka spout en prebolt

verwijderd worden. Hierdoor zal de topologie niet meer lopen, en kunnen geen berichten

meer van de Kafka topic gehaald worden.

3. Opstarten met compilatie zonder een topologie te moeten undeployen. In deze situatie

moet de jar opnieuw gebouwd worden omdat er een nieuwe klasse toegevoegd is. Dit

kan voorkomen wanneer de topologie voor de eerste keer gedeployed wordt, of na een

situatie twee waar een klasse aangepast wordt.

4. Opstarten zonder compilatie, maar met undeployen. Het toevoegen van een bolt zoals

in Figuur 10.3, die dezelfde klasse gebruikt als een van de reeds gedeployde bolts, is de

oorzaak voor deze situatie.

5. Opstarten met compilatie en undeployen. Deze situatie komt voor bij het aanpassen

van een klasse bij een lopende spout of bolt.

Onderstaande grafiek 10.4 toont de gemiddelde duur per situatie. Elke waarde vertegenwoor-

digd het gemiddelde van een situatie die twintig keer werd uitgevoerd.

Tussen het bevestigen van aanpassingen in de GUI en het oproepen van de bijpassende hook

verloopt er in alle situaties gemiddeld zeven seconden. Het rebuilden van de jar in situaties

drie en vijf duurt gemiddeld twaalf seconden. Breedte-eerst-zoeken, alsook de nodige controles

die uitgevoerd worden in buildGraph, gebeuren onder een seconde.

Situatie een heeft een gemiddelde tijd van zestien seconden. De twee componenten die verant-

woordelijk zijn voor deze tijd, zijn het wachten tot de hook opgeroepen wordt en het opstarten

van de topologie met storm jar.

Hoofdstuk 10. Evaluatie 52

Figuur 10.4: Evaluatie

In situatie twee wordt enkel de topologie gestopt. Deze duurt gemiddeld dertien seconden.

Door alle lopende topologien in een apart bestand bij te houden kan met een grep operatie

gecontroleerd worden of de topologie reeds loopt. De grootste tijdsbestedingen zijn dan weer

het wachten op de hook, en de uitvoer van het storm kill commando. Standaard zal deze

de topologie in een killed (gestopt) status zetten voor 30 seconden. Door de optie -w te

specificeren wordt dit gedrag onderdrukt en wordt de topologie ogenblikkelijk gestopt.

storm kill topologie -w 1

Situatie drie en vijf nemen de meeste tijd in beslag met respectievelijk 30 en 34 seconden.

Het hercompileren van het Storm project is verantwoordelijk voor een grote toename. Deze

situaties zijn de slechtste gevallen, sinds ze zo goed als elke configuratie opnieuw moeten

uitvoeren.

Het aanpassen van de topologie beschreven in Figuur 10.2 naar 10.3 kan op twee verschillende

manieren:

1. De nieuwe bolt toevoegen aan de prebolt en de jsonbolt. Daarna de stream grouping

aanpassen.

2. Eerst de relatie tussen de Kafka spout en de prebolt verwijderen, dan de relaties leggen

tussen de bolts en hun stream groupings definieren. Als laatste de relatie tussen Kafka

spout en prebolt opnieuw toevoegen.

Hoofdstuk 10. Evaluatie 53

Als de beginsituatie een geldige topologie is, zoals in Figuur 10.2, dan is deze reeds gedeployed.

Elke actie die ondernomen wordt om de topologie aan te passen, moet volledig uitgevoerd

worden voor de volgende actie. Om een tweede averagebolt toe te voegen moeten er twee

extra relaties gelegd worden. De tweede relatie kan pas starten als de eerste afgelopen is.

Methode 1 bestaat dan uit de volgende stappen dewelke herleid worden naar de vijf situaties

die hierboven beschreven staan:

1. De nieuwe bolt toevoegen aan de prebolt is een situatie vier. De nieuwe bolt is een

tweede instantie van de averageBolt klasse, en dus is hercompileren niet nodig.

2. Na de relatie met de prebolt wordt een relatie gelegd met de jsonbolt. Dit is opnieuw

een situatie vier.

3. Aanpassen van de stream groupings naar een fields grouping. Hercompileren is niet

nodig en de lopende topologie moet eerst gestopt worden. Dit is een situatie vier.

De totale uitvoertijd van methode 1 is dus drie keer situatie vier, wat een tijd oplevert van

54 seconden. Deze methode is het meest vanzelfsprekend, maar kan een ongewenst resultaat

opleveren voor de gebruiker. Door het toevoegen van de nieuwe bolt aan de prebolt wordt de

topologie aangepast en blijft deze geldig. De default stream grouping is ingesteld op shuffle

en zal dus berichten doorsturen wanneer de topologie weer actief is. De data die verwerkt

wordt zal dus tijdelijk incompleet zijn.

Het toevoegen van de tweede relatie naar de jsonbolt heeft opnieuw een geldige topologie als

gevolg, maar dankzij de shuffle grouping zal data van verschillende locaties op verschillende

nodes verwerkt worden. Dit kan opnieuw leiden naar tijdelijke incomplete data.

Methode 2 gaat als volgt te werk:

1. Het verwijderen van de relatie tussen de Kafka spout en prebolt maakt de topologie

ongeldig. Er is slechts een spout, en deze heeft geen bestaande stream groupings meer.

De topologie wordt gestopt en niet meer gedeployed. Dit is een situatie twee.

2. Alle volgende aanpassingen die betrekking hebben op de nieuwe bolt, hebben geen

invloed op de geldigheid van de topologie. Beginnend bij de kafka spout zal buildGraph

een keer met breedte-eerst-zoeken naar bolts en geen relaties vinden . Er moeten dus

geen topologieen gestart of gestopt worden.

3. De laatste stap is het opnieuw toevoegen van de relatie tussen de Kafka spout en prebolt.

Er zijn geen nieuwe klassen toegevoegd dus hercompileren is niet noodzakelijk. Er is

ook geen lopende topologie. Dit is een situatie een.

De totale uitvoeringstijd van methode 2 is een situatie twee die dertien seconden duurt en

drie aanpassingen waar de uitvoeringstijd bepaald wordt door de tijd die nodig is om de hook

Hoofdstuk 10. Evaluatie 54

op te roepen. Gemiddeld is dit zeven seconden per verandering. Als laatste het opstarten

van de topologie in situatie een welke gemiddeld zestien seconden duurt. Dit komt uit op een

totale uitvoeringstijd van 50 seconden.

Methode 2 vraagt in vergelijking met methode 1, een extra bewerking maar heeft nog steeds

een snellere uitvoeringstijd. Tijdens de veranderingen in de topologie worden er ook geen

berichten van de Kafka topic gehaald en verwerkt. Er zullen geen incomplete resultaten

verwerkt worden.

De performantie is dus grotendeels afhankelijk door het aantal storm jar en storm kill

commando’s. De gemiddelde tijd om de hook te starten is ook een vaste kost die in elke

operatie aanwezig is. Afhankelijk van use case tot use case kan de topologie misschien wel

sneller opgebouwd worden door de volgorde van de gebruikeracties aan te passen of extra

acties toe te voegen.

Het gebruik van het Apache Storm Flux framework heeft wel de kosten gedrukt in de situaties

een en vier. Door niet rechtstreeks een main klasse te moeten schrijven of aanpassen, maar

te werken met een configuratiebestand die deze simuleert is het niet nodig om steeds te

hercompileren.

Buiten het tijdsaspect is er ook een voordeel wat betreft beveiliging. Het deployen van

topologieen kan enkel gebeuren via de commandolijn op de machine waar de Nimbus actief

is. Door gebruik te maken van Juju charms en Juju GUI, kan deze restrictie omzeild worden.

Het starten en stoppen wordt achter de schermen uitgevoerd en laat geen toegang toe tot de

commandolijn.

Hoofdstuk 11

Conclusies

11.1 Conclusie

Dit onderzoek probeert de instapdrempel voor het gebruik van de stream processing tool

Apache Storm te verlagen. Dit enerzijds met een nadruk op het hergebruik van bestaande

algoritmen en topologieen en anderzijds door het ontplooien en aanpassen van topologieen te

vereenvoudigen.

Dit werd geımplementeerd op het Tengu platform die als back-end gebruik maakt van Juju,

een cloud management framework, dewelke de nodige modulariteit kan leveren om topologieen

te vereenvoudigen.

Als eerste stap werd een Juju charm uitgebreid om het mogelijk te maken volledige Storm

topologieen te deployen door URL’s mee te geven naar de Github repositories of jar. Deze

zal de topologieen automatisch starten.

Een tweede charm werd ontwikkeld die een topologie beheert die gebruik maakt van Apache

Kafka en MongoDB en de status bijhoudt van deze services. Wanneer de charm detecteert

dat alle nodige services aanwezig zijn, zal hij de topologie starten. Indien er een of meerdere

wegvallen, wordt de topologie weer gestopt.

Als laatste werd de structuur van een topologie zelf verwerkt in verschillende charms. Zo

ontstaat er een storm-topology charm die een topologie voorstelt. De verschillende onderdelen

van een topologie worden voorgesteld als spout en bolt charms. Topologieen die werken met

Kafka of MongoDB hebben de mogelijkheid om deze op een eenvoudige manier te gebruiken

en in te stellen.

Een use case werd uitgewerkt en geevalueerd welke vijf situaties omlijnt die kunnen voorkomen

bij het aantpassen van topologieen. Hieruit werd er afgeleid dat de oorzaak van de langste

downtime een gevolg is van het uitvoeren van storm jar en storm kill commando’s.

55

Hoofdstuk 11. Conclusies 56

11.2 Toekomst

Het starten en stoppen van topologieen op de Nimbus zijn twee grote boosdoeners die invloed

hebben op de performantie. Apache Storm is echter van plan[4] om in een latere versie een

functie toe te voegen die bij actieve topologieen niet enkel toelaat het aantal workers per node

aan te passen, maar ook de structuur.

Dit storm swap commando verzekert minimale downtime (wachttijd) tussen het opzetten van

de nieuwe topologie. De oude en nieuwe topologie zullen ook geen kans hebben om tuples op

hetzelfde moment te verwerken.

Het aanpassen van stream groupings gebeurt momenteel via de configuratie parameters van

een Juju charm. Dit zorgt ervoor dat het aanpassen van stream groupings een langzaam

proces kan zijn. Iedere aanpassing in een actieve topologie kan ervoor zorgen dat de topologie

moet herstart worden. Als Juju in de toekomst toelaat om parameters mee te geven bij het

definieren van relaties zal dit op een elegante manier kunnen worden opgevangen.

Door de werking van subordinate charms is het noodzakelijk om extra relaties te leggen tussen

enerzijds de spout en bolt charms, en anderzijds de Nimbus. Dit is te zien in figuur 10.1.

De stippellijnen duiden deze relaties aan. Op het eerste zicht is het niet duidelijk voor een

gebruiker waarom dit nodig is. Hierdoor is deze werkwijze niet gebruiksvriendelijk. De GUI

kan bovendien onoverzichtelijk voorkomen wanneer de topologie voldoende groot is of waneer

meerdere topologieen in een Juju omgeving aanwezig zijn.

De huidige implementatie laat enkel klassen toe die geschreven zijn in Java. Met de nadruk

op het hergebruik van algoritmes, die geschreven kunnen zijn door andere onderzoekers, is

het ideaal moesten bolts of spouts kunnen geıntegreerd worden die geschreven zijn in een

andere programmeertaal. Enkele voorbeelden van andere talen die gebruikt worden voor het

ontwikkelen van storm topologieen zijn Python en JavaScript.

Dankzij het gebruik van Flux is deze functionaliteit een uitbreiding die mogelijk is. Binnen

het configuratiebestand kunnen extra parameters meegegeven worden die de taal aanduiden

per spout of bolt. Deze modulariteit past in het Juju formaat waar per charm beslist kan

worden welke taal gebruikt wordt. Ontwikkelaars die hun algoritmes publiek willen maken,

hoeven deze dan ook niet in meerdere talen te herschrijven en bereiken op die manier een zo

wijd mogelijk publiek.

Bibliografie

[1] (2013). Storm (0.9.3-1411). http://doc.mapr.com/pages/viewpage.action?pageId=28213843.

Geraadpleegd op 2/06/2016.

[2] (2014). Explain about how the juju charms hooks files working (life cy-

cle). http://stackoverflow.com/questions/25157039/explain-about-how-the-juju-charms-

hooks-files-working-life-cycle. Geraadpleegd op 2/04/2016.

[3] (2016). Bijwerkingen van chemotherapie. https://www.kanker.nl/bibliotheek/chemotherapie/bijwerkingen/225-

bijwerkingen-van-chemotherapie. Geraadpleegd op 15/02/2016.

[4] (2016). Running topologies on a production cluster.

http://storm.apache.org/releases/2.0.0-SNAPSHOT/Running-topologies-on-a-

production-cluster.html. Geraadpleegd op 29/05/2016.

[5] C. Bizer, T. Heath & T. Berners-Lee (2009). Linked data - the story so far. International

Journal on Semantic Web and Information Systems, 5(3):1–22.

[6] A. Bolles, M. Grawunder & J. Jacobi (2008). Streaming sparql - extending sparql to

process data streams. The Semantic Web: Research and Applications, pp. 448–462.

[7] E. Della Valle, S. Ceri, F. van Harmelen & D. Fensel (2009). It’s a streaming world!

reasoning upon rapidly changing information. IEEE Intelligent Systems, 24:83–89.

[8] T. Eiter & T. Krennwallner (2012). Reasoning Web - Semantic Technologies for Advanced

Query Answering. Springer Berlin Heidelberg.

[9] D. Le Phuoc (2013). A Native and Adaptive Approach for Linked Stream Data Processing.

Doctoraatsthesis, NUI Galway.

[10] N. Marz (2012). Storm-distributed and fault-tolerant realtime computation. Open Source

Conference (OSCON).

[11] G. Niemeyer (2013). The heart of juju. http://blog.labix.org/2013/06/25/the-heart-of-

juju. Geraadpleegd op 26/03/2016.

57

Bibliografie 58

[12] M. Noll (2012). Running a multi-node storm cluster. http://www.michael-

noll.com/tutorials/running-multi-node-storm-cluster/. Geraadpleegd op 2/04/2016.

[13] M. Noll (2012). Running a multi-node storm cluster. http://www.michael-

noll.com/blog/2012/10/16/understanding-the-parallelism-of-a-storm-topology/. Ge-

raadpleegd op 2/04/2016.

[14] D. L. Phuoc, H. N. M. Quoc, C. L. Van & M. Hauswirth (2013). Elastic and scala-

ble processing of linked stream data in the cloud. ISWC ’13 Proceedings of the 12th

International Semantic Web Conference - Part I, pp. 280–297.

[15] J. Sequeda, O. Corcho & A. Gomez-Perez (2009). Linked stream data: a short paper.

CEUR Workshop Proceedings.

[16] K. Wahner (2014). Real-time stream processing as game changer in a big data world with

hadoop and data warehouse. http://www.infoq.com/articles/stream-processing-hadoop.

Geraadpleegd op 2/04/2016.