Post on 24-May-2020
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.