Jämförelser av MySQL och Apache Spark: För aggregering av smartmätardata i Big Data format för en webbapplikation

JÄMFÖRELSER AV MYSQL OCH APACHE SPARK

För aggregering av smartmätardata i Big Data format för en

webbapplikation

COMPARISONS BETWEEN MYSQL AND APACHE SPARK

For aggregation of smartmeter data in Big Data format for a web

application

Examensarbete inom huvudområdet Informationsteknologi

Grundnivå 30 Högskolepoäng Vårtermin 2020

Robin Danielsson

Sammanfattning

Smarta elmätare är ett område som genererar data i storleken Big Data. Dessa datamängder medför svårigheter att hanteras med traditionella databaslösningar som MySQL. Ett ramverk som uppstått för att lösa dessa svårigheter är Apache Spark som implementerar MapReduce-modellen för klustrade nätverk av datorer. En frågeställning för arbetet är om Apache Spark har fördelar över MySQL på en enskild dator för att hantera stora mängder data i formatet JSON för aggregering mot webbapplikationer.

Resultaten i detta arbete visar på att Apache Spark har lägre aggregeringstid än MySQL mot en webbapplikation vid minst ~6.7 GB data i formatet JSON vid mer komplexa aggregeringsfrågor på enskild dator. Resultatet visar även att MySQL lämpar sig bättre än Apache Spark vid enklare aggregeringsfrågor för samtliga datamängder i experimentet.

Nyckelord: Big Data, Apache Spark, MySQL, JSON, Webbapplikationer

Innehållsförteckning

1 Introduktion . . . . 1

2 Bakgrund . . . . 2

2.1 Webbapplikationer . . . . ²

2.2 PHP . . . . ²

2.3 Relationsdatabaser . . . . ³

2.3.1 MySQL . . . . ³

2.4 JSON . . . . ⁴

2.5 Big Data . . . . ⁵

2.6 MapReduce . . . . ⁵

2.7 Apache Spark . . . . ⁶

2.7.1 Scala . . . . ⁷

3 Problemformulering och hypotes . . . . 8

3.1 Problemformulering . . . . ⁸

3.2 Hypotes . . . . ⁹

4 Metodbeskrivning . . . . 10

4.1 Metod . . . . ¹⁰

4.1.1 Datagenerering . . . . ¹⁰

4.2 Alternativa metoder . . . . ¹¹

4.3 Forskningsetik . . . . ¹¹

5 Genomf ¨ orande. . . . 13

5.1 Litteraturstudie . . . . ¹³

5.2 Konfiguration . . . . ¹³

5.3 Progression . . . . ¹⁴

5.3.1 Datageneration . . . . ¹⁴

5.3.2 MySQL . . . . ¹⁵

5.3.3 Apache Spark . . . . ¹⁸

5.3.4 Webbapplikation . . . . ¹⁸

5.3.5 M ¨atningsskript . . . . ¹⁸

5.4 Pilotstudie . . . . ¹⁹

5.4.1 Genomf ¨orande av pilotstudie . . . . ¹⁹

5.4.2 Resultat av pilotstudie . . . . ²⁰

5.4.3 Diskussion av pilotstudie . . . . ²³

6 Till ¨ampade ¨andringar . . . . 24

6.1 Modifiering av komplex s ¨okfr ˚aga . . . . ²⁴

6.2 Byte av lokal testmilj ¨o . . . . ²⁵

6.2.1 Slutgiltig h ˚ardvaruspecifikation . . . . ²⁵

6.2.2 Slutgiltig mjukvaruspecifikation . . . . ²⁵

6.3 Ytterligare ¨andringar . . . . ²⁶

7 Utv ¨ardering . . . . 27

. . . .

7.2.1 Testfall T1: 400 simpla aggregeringar (˜1.4GB) . . . . ²⁸

7.2.2 Testfall T2: 400 komplexa aggregeringar (˜1.4GB) . . . . ³⁰

7.2.3 Testfall T3: 200 simpla aggregeringar (˜6.7GB) . . . . ³¹

7.2.4 Testfall T4: 200 komplexa aggregeringar (˜6.7GB) . . . . ³³

7.2.5 Testfall T5: 100 simpla aggregeringar (˜13.5GB) . . . . ³⁴

7.2.6 Testfall T6: 100 komplexa aggregeringar (˜13.5GB) . . . . ³⁶

7.3 Analys . . . . ³⁷

7.4 Slutsatser . . . . ³⁹

8 Avslutande diskussion . . . . 40

8.1 Sammanfattning . . . . ⁴⁰

8.2 Diskussion . . . . ⁴⁰

8.3 Etik och samh ¨alle . . . . ⁴¹

8.4 Framtida arbete . . . . ⁴¹

Referenslista . . . . 43

1 Introduktion

Allt eftersom behovet av att analysera allt större mängder data växer så krävs nya lösningar för att kunna möta de ökade analyseringskraven för stora datamängder (Lu et al. 2014). Datamängder som har en hög storleksgrad kallas även Big Data (Sagiroglu och Sinanc 2013). Big Data är ett begrepp som har olika definitioner. En definition av Big Data enligt Chen, Mao och Liu (2014) är att det är data som har en massiv storlek, höga krav på hastighet för datainsamling och analys samt data med hög varians. Inom webbutveckling har relationsdatabaser en hög användningsgrad, exempelvis MySQL (Auer et al. 2009). Ett problem som finns med dessa databaser är att deras prestanda i form av hastighet minskar vid hantering av stora datamängder (Ongo och Kusuma 2018).

Ett huvudproblem inom Big Data är hastigheten som data hanteras på, speciellt vid datalösningar som måste exekveras i hastigheter som är nära realtid (Kaisler et al. 2013).

En problemdomän som använder Big Data teknologier, exempelvis ramverk för att analysera och hantera stora datamängder är data som genereras av så kallade smarta mätare (smartmeters) i stadsmiljöer (Yang et al. 2017). Ett generellt beräkningsramverk som fått stor användning på senare tid för att beräkna Big Data på klustrade datorsystem är Apache Spark (Lu et al. 2014).

Tidigare forskning som genomförts av (Pérez-Chacón et al. 2018) visar att Apache Spark är lämpligt för att analysera Big Data från smarta mätare för att hitta mönster i energiförbrukning för smarta elmätare. Målet med arbetet är att jämföra Apache Spark med den mer traditionella relationsdatabasen MySQL för att avgöra vilken av dessa teknologier som har snabbast aggregeringstid för dataaggregering mot en webbapplika- tion.

Metoden som används i arbetet är av typen teknologiskt orienterat experiment som mäter aggregeringstider av JSONdata bestående av genererad elförbrukningsdata mot en lokal webbapplikation. Den beroende variabeln som mäts i experimentet är aggregeringstider mätt i millisekunder för en webbapplikation.

Studien som genomförs i arbetet består av flera testfall med varierande datamängd där

aggregeringstider mot en webbapplikation mäts för MySQL samt Apache Spark för

en enkel samt mer komplex aggregeringsfråga. Mätning av dessa aggregeringstider för

MySQL samt Apache Spark förväntas ge en inblick i lämpligheten för användningen av

respektive teknologi för användning på webben.

2 Bakgrund

Detta kapitel kommer att behandla bakgrunden inför problemformuleringen. Kapitlet kommer att ta upp den relevanta kunskapen kring olika områden för att kunna genomföra studien.

2.1 Webbapplikationer

Webbläsare som plattform blir allt mer ett populärt område för utveckling av mjukvara och förväntas att bli den standardiserade plattformen för stora delar av nyutvecklad mjuk- vara (Taivalsaari, Mikkonen, Ingalls och Palacz 2008). Innan webbapplikationer anropades diverse informationsdokument från internet via HTTP-protokollet från en webbläsare (Jazayeri 2007). Enligt Jazayeri (2007) har denna statiska struktur blivit utbytt mot en dynamisk struktur i form av webbapplikationer. Webbapplikationer har möjligheten att leverera mjukvara till en webbläsare genom scriptspråk från en server, ett av dessa scriptspråk är PHP (Jazayeri 2007).

2.2 PHP

Det mest populära scriptspråket för webben som används på serversidan för utveckling av webbapplikationer är PHP (Dahse och Holz 2014). Enligt Dahse och Holz (2014) är anledningen till den enorma populariteten hos PHP är delvis att det är enkelt för nybörjare att lära sig.

En aspekt av PHP är att det är ett dynamiskt scriptspråk vilket innebär att variabler allokeras under exekveringstid för koden. Variabler i PHP har även möjligheten att byta datatyp under exekveringstid (Dahse och Holz 2014). En annan aspekt av PHP är att det är möjligt att kombinera PHP-kod tillsammans med HTML-kod. (Dahse och Holz 2014).

Nedan i figuren Fig. 1 följer ett exempel för "Hello World" i PHP inuti HTML.

<!DOCTYPE html>

<html>

<?php

$greeting = "Hello world!";

echo "<h1> { $greeting } </h1>";

?>

<html>

Fig. 1: Exempelkod för "Hello World" i PHP.

PHP används ofta i Linuxmiljöer tillsammans med Apache som webbserver samt MySQL

som relationsdatabas (Jazayeri 2007). Denna kombination kallas för en LAMParkitektur

och är vanlig för webbservrar (Jazayeri 2007). Då PHP används som scriptspråk för att

implementera relationsdatabaser i webbapplikationer (Auer et al. 2009) gör detta PHP

till ett lämpligt språk att använda med MySQL. För att få åtkomst till relationsdatabaser

i PHP används biblioteken MySQLi eller PDO (Anderson och Hills 2017).

2.3 Relationsdatabaser

Databaser av olika slag spelar en viktig roll i moderna webbapplikationer. Den populära typen av databas som används när webbapplikationer utvecklas i dagsläget kallas för relationsdatabaser (Ongo och Kusuma 2018). Dessa databaser benämns ofta med förko- rtningen RDBMS som står för Relational Database Management System och är diverse mjukvarupaket som möjliggör slutanvändare att hantera data inom en databas (Ongo och Kusuma 2018). Relationsdatabaser använder ett frågespråk som kallas SQL (Structured Query Language) för att ställa frågor mot en databas i syfte att hantera och manipulera data (Jamison 2003). En relationsdatabas har en struktur för hur datan i tabellerna är organiserad i databasen, även kallat ett schema (Kaur och Rani 2013). Varje tabell består av ett visst antal rader med definierade värden för varje rad (Kaur och Rani 2013). Nedan följer ett exempel på hur ett schema kan representeras:

Fig. 2: Exempel på ett enkelt schema för orderhantering

En relationsdatabas består av tabeller och relationer mellan dessa tabeller för att beskriva dess relationer.

Dessa relationer hanteras primärt med två typer av nycklar i tabellerna, primärnycklar samt främmande nycklar. Primärnyckeln är ett eller flera fält i en tabell som enskilt eller tillsammans identifierar en rad i en relationsdatabas (Groff och Weinberg 2002). En främ- mande nyckel är en relation från en tabell som matchar en annan tabells primärnyckel för att beskriva en relation (Groff och Weinberg 2002). I figuren Fig. 2 markeras primärny- cklar med PK (Primary Key) och främmande nycklar med FK (Foreign Key). En viktig aspekt av relationsdatabaser är aggregering av data. När ett relationsdatabassystem pro- cessat en fråga och returnerat ett svar beroende på den givna frågan har en så kallad aggregering skett (Hellerstein, Haas och Wang 1997).

2.3.1 MySQL

Den version av relationsdatabas som har störst användning inom området webbapplika-

tioner är MySQL (Auer et al. 2009). Enligt Ongo och Kusuma (2018) är anledningen till

MySQL stora popularitet på webben snabb datainläsning samt att MySQL databaser är

DROP DATABASE IF EXISTS exjobb;

CREATE DATABASE exjobb;

USE exjobb;

CREATE TABLE IF NOT EXISTS Kund ( ID INT AUTO_INCREMENT NOT NULL , Personnummer VARCHAR(11) NOT NULL, Namn VARCHAR(64) NOT NULL ,

Leveransadress VARCHAR(255) NOT NULL , PRIMARY KEY(ID)

) ENGINE=InnoDB;

Fig. 3: Exempel på hur kundtabellen från föregående schema i Fig. 2 kan implementeras i MySQL

Datan som lagras i en MySQL relationsdatabas har möjligheten att lagras på flera ställen, detta kallas för klustring och kan möjliggöras via MySQL cluster (Fuad, Erwin och Ipung 2014). Forskningsresultat av Fuad et al. (2014) visar dock att MySQL cluster har liknande problem med stora datamängder som beskrivs av Ongo och Kusuma (2018) för självstående MySQL databaser där databasen blir långsammare ju mer data som la- gras. Enligt Fuad et al. (2014) beror denna prestandaförlust på att kolumnerna lagras i arbetsminnet på servern innan den processas.

2.4 JSON

Ett av de mest använda formaten som används på webben för att hantera data är JSON, vilket är en förkortning för Javascript Object Notation (Bourhis, Reutter, Suárez och Vrgoč 2017). Enligt Bourhis et al. (2017) består ett JSON-dokument enkelt beskrivet av data i form av nyckelvärdespar.

De datatyper som stöds i JSON-formatet enligt Chasseur, Li och Patel (2013) är primi- tiva datatyper som strängar, nummer, booleans samt nullvärden. JSON har även stöd för objekt samt arrayer (Chasseur et al. 2013). Ett område på webben som specifikt använder sig av JSONformatet är olika gränssnitt för att skicka data mellan klienter och webbapp- likationer. Dessa gränssnitt kallas även för APIer (Application Programming Interfaces) (Bourhis et al. 2017).

Figuren Fig. 4 beskriver en fiktiv person i JSONformatet.

{

"name" :"Steve",

"occupation" :"Student",

"birthyear":2000,

"favorite" : {

"food" :"asian",

"hobby":"woodcrafting",

"game" :"chess",

"season" :"summer"

} }

Fig. 4: Exempel på en person i JSONformat.

2.5 Big Data

Allt eftersom data som används för webbapplikationer och i dess databaser växer i storlek blir dessa data svårare att kontrollera med traditionella databasverktyg som exempelvis MySQL på ett effektivt sätt (Kaisler et al. 2013). För att lösa problem som finns med traditionella databaser och stora datamängder har ett nytt begrepp som kallas Big Data (Kaisler et al. 2013). Begreppet Big Data har flera definitioner (Chen et al. 2014). En- ligt Chen et al. (2014) är en definition av begreppet Big Data sådan typ av data som inte kan hanteras effektivt inom en skälig tidsperiod (Chen et al. 2014). Det finns fler- talet utmaningar med att arbeta med Big Data. Ett ytterligare begrepp för att definiera innehållet av Big Data som även enkapsulerar dessa utmaningar kallas för de 3V’en, Vol- ume, Velocity, Variety (Kaisler et al. 2013).

På Svenska kan dessa översättas till Volym, Hastighet, Variation. Dessa definieras enligt följande:

• Volym

Eftersom Big Data har en enorm volym finns det utmaningar med att hantera den (Chen et al. 2014).

• Hastighet

Hastighet i denna definition menas enligt Kaisler et al. (2013) "hastigheten för att skapa data, streaming av data samt aggregering av data" (Kaisler et al. 2013).

• Variation

Variation innebär den stora variationen av datan som hanteras. Data finns i flera former, strukturerad data, ostrukturerad data eller delvis strukturerad data. (Chen et al. 2014). En utmaning med dessa olika strukturvariationer enligt Sagiroglu och Sinanc (2013) är att datan blir mycket större.

2.6 MapReduce

(Condie et al. 2010). Då MapReduce-modellen enligt Dean och Ghemawat (2008) samt Condie et al. (2010) tillåter parallell bearbetning av data på stora datorkluster bör det inte finnas en teoretisk gräns för hur mycket data som kan processas inom en specifik tidsram. MapReduce som modell kan beskrivas genom två funktioner som hanterar och analyserar datan och som även måste programmeras av dess användare för att exekveras.

Dessa funktioner kallas för en Mapfunktion samt en Reducefunktion. (Chen et al. 2014).

Nedan följer en modell över hur MapReduce-modellen fungerar i praktiken samt förk- laringar för de båda stegen enligt Dean och Ghemawat (2008).

Fig. 5: Förenkling av MapReduce.

Mapreduce fungerar kortfattat genom att datan från ett datalager eller databas delas upp i så kallade datasplits i mindre datastorlekar (Dean och Ghemawat 2008). Dessa skickas sedan från ett huvudprogram även kallat Masterprogrammet till arbetsprogram som utför uppgiften Map eller Reduce. Genom Mapfunktionen skrivs nyckelvärdespar för datan som ska hanteras till en klustrad dators lokala disk för att sedan användas av arbetsprogram- men som exekverar Reduce med dessa nyckelvärdespar (Dean och Ghemawat 2008). Sedan sorteras datan på dess nyckelvärdespar i ett stadie som kallas för shufflestadiet (Condie et al. 2010) för att slutligen skrivas till någon typ av utfil (Dean och Ghemawat 2008).

2.7 Apache Spark

Ett relativt nytt ramverk som har vunnit stor framgång inom området Big Data är Apache Spark. Spark är en typ av beräkningsramverk som på senare tid fått stor fokus och som har möjlighet att använda en modell som liknar MapReduce för beräkning av stora dataset mellan enheter på ett klustrat datorsystem. (Lu et al. 2014). Tidigare forskning av Yang et al. (2017) och Pérez-Chacón et al. (2018) föreslår Apache Sparks användbarhet för analysering av stora datamängder.

Arkitekturen för ett system skrivet i Apache Spark har huvudsakligen två delar och har likheter med hur MapReduce-modellen fungerar. Dessa två delar är ett huvudsak- ligt "mainprogram" där skriven programkod körs samt "arbetare" som utför arbetet enligt

"mainprogrammet"s instruktioner. Dessa hanteras via en hanterare för att hantera ar-

betet på de olika klusternoderna i systemet (Chambers och Zahari 2018). Apache Spark

har möjlighet att använda sig av flertalet APIer för att integrera flertalet programspråk,

exempelvis Python eller R. Apache Spark har även stöd för SQL. Det generella språket som används för Apache Spark är dock Scala (Chambers och Zahari 2018).

Fig. 6: Förenkling över Apache Spark.

2.7.1 Scala

Ett programmeringsspråk som kan användas för att skapa program i Apache Spark är Scala (Lu et al. 2014). Scala är ett programmeringsspråk som har likheter med Java. En aspekt av Scala är att det är funktionellt med Java. Det innebär att det finns möjlighet att blanda Java och Scala i samma projekt (Odersky et al. 2004). En ytterligare likhet som finns mellan Java och Scala och som är anledningen till den höga graden av utbytbarhet mellan dessa är att båda språken exekveras på JVM (Odersky et al. 2004). JVM är en förkortning för Java Virtual Machine som är en miljö för att exekvera konverterad bytecode (Hardin 2001).

Koden i Fig. 7 illustrerar ett kodexempel för ett enklare program i Scala som anropar en funktion för en hälsning och skriver ut den i konsollen.

object exempel {

def main(args: Array[String]) = { sayHello("Robin")

}

def sayHello(name:String) = { printf("Hello %s!\n", name) } }

Fig. 7: Enkelt programexempel i Scala.

3 Problemformulering och hypotes

3.1 Problemformulering

Ett huvudproblem inom Big Data är svårigheterna med att hantera datan (Kaisler et al. 2013). Apache Spark är en generell plattform som är kapabel till att processa stora datamängder som räknas som Big Data (Meng et al. 2016). En datadomän som Apache Spark har ett lämpligt användningsområde inom är energiförbrukningsdata. Enligt Honarvar och Sami (2016) kräver processering av energiförbrukningsdata från smarta elmätare i städer denna typ av teknologier som Apache Spark då den datan räknas som Big Data, både i volym samt datahastighet enligt de 3Ven beskrivet av Kaisler et al.

(2013). Tidigare forskningsresultat av Pérez-Chacón et al. (2018) visar på att Apache Spark kan processa stora datamängder under kort tid då data för ~65000 hushåll med en storlek på ~45GB processerades på ~6 minuter för att hitta energiförbrukningsmönster för dessa hushåll genom maskinlärningsmetoder i Apache Spark.

Eftersom storleken på data som klassas som Big Data ofta är enorm finns det ut- maningar med att processa denna typ av data på ett hanterbart sätt (Kaisler et al. 2013).

Ett problem med relationsdatabaser i kontexten Big Data är att de blir långsammare för att hantera samt processa data ju mer data som lagras (Ongo och Kusuma 2018).

Då hastigheten för åtkomst av lagrad data är en viktig aspekt av Big Data eftersom stora mängder data måste processas med en hög hastighet (Sagiroglu och Sinanc 2013) är troligtvis traditionella relationsdatabaser som exempelvis MySQL långsamma när det gäller aggregering av denna typ av data. Apache Spark är en potentiell lösning för aggregering av stora datamängder till en webbapplikation om man ser till forskningsre- sultaten av Pérez-Chacón et al. (2018) samt (Yang et al. 2017).

Pérez-Chacón et al. (2018) och Yang et al. (2017) använder Apache Spark med klustrade samt kraftfulla datorer på data som är i Big Data storlek. En mer relevant jämförelse mellan Apache Spark och MySQL för arbetet i Big Data kontext är att jämföra Apache Spark för en klusternod på en dator kallat Standalone Mode (Chambers och Zahari 2018) med MySQL som traditionellt endast använder en dator, för att aggregera en datamängd som är nära Big Data storleksmässigt för en webbapplikation.

Denna jämförelse är relevant inom arbetet för att ta reda på om Apache Spark är beroende av ett klustrat datorsystem med flera datorer eller inte för att dra nytta av MapReduce-modellen för aggregering av data.

Huvudfrågeställningen som arbetet förväntas ge svar på är om MapReduce-modellen inom

Apache Spark i Standalone Mode på begränsad hårdvara är snabbare än MySQL för att

aggregera data på en lokal server till en webbapplikation. En sekundär frågeställning som

är relevant för arbetet är vid vilken datamängd Apache Spark potentiellt blir snabbare

än MySQL för aggregering av data på en klusternod. Dessa jämförelser är relevanta inom

området webbutveckling då MySQL enligt Auer et al. (2009) är den relationsdatabas som

har störst användning på webben. Genom att jämföra aggregeringstider mellan MySQL

och Apache Spark i millisekunder för energiförbrukningsdata i JSON-format kan man få

en insikt i vilken av dessa teknologier som är lämpligast att använda för att aggregera

smartmätardata till en webbapplikation med begränsad hårdvara.

3.2 Hypotes

• Apache Spark har en lägre aggregeringstid mätt i millisekunder än MySQL vid

aggregering av en stor mängd energiförbrukningsdata i JSON-format till en web-

bapplikation.

4 Metodbeskrivning

Detta kapitel kommer att behandla den metod som kommer att användas för genomföran- det av arbetet. Kapitlet kommer även att genomgå forskningsetiska aspekter av arbetet.

4.1 Metod

Enligt Wohlin et al. (2012) finns det flera empiriska strategier för att genomföra forskning inom kontexten för software engineering. De olika strategierna är enkätstudier, fallstudier, quasi-experiment samt experiment (Wohlin et al. 2012).

Genom att använda experiment är det möjligt att statistiskt dra slutsatser från den insamlade datan utifrån utförandefasen från experimentet som Wohlin et al.

(2012) kallar för Operation som även innefattar andra aktiviteter som planering samt datavalidering. Att kunna testa den utformade hypotesen genom att analysera insamlad data med en hög validitet är en av styrkorna med att använda sig av experiment (Wohlin et al. 2012). En annan fördel med att använda experiment är den höga nivån av kontroll då experiment genomförts genom att manipulera variabler i en kontrollerad miljö (Wohlin et al. 2012).

Nackdelen som finns med att använda sig av experiment som empirisk strategi är att det finns en risk att simulerad data inte blir representativ för experimentet och därmed felaktig (Wohlin et al. 2012). Ytterligare en nackdel med att använda experiment i en kontrollerad miljö är att endast en person kommer att delta i experimentet mot webbapplikationen. En fallstudie skulle kunna vara mer lämplig i verklighetsbaserade miljöer (Wohlin et al. 2012) och därmed bidra till en verklig kontext (Wohlin et al. 2012).

I forskningsartikeln skriven av Fuad et al. (2014) används experiment som em- pirisk metod för att mäta processering mellan Apache Hive, Apache Pig samt MySQL på klustrade system. Denna metod kommer även att användas för denna studie då det enligt Wohlin et al. (2012) är ett tekniskt experiment som ska utföras eftersom resultatet av variabelmanipuleringen är det som mäts. De oberoende variablerna som kommer att förändras under experimentet är valet av teknologi för att aggregera ett genererat dataset från en verklighetsbaserad struktur av ett dataset från (Öppna data och PSI 2020-02-21) i JSONformat. Wohlin et al. (2012) beskriver den beroende variabeln som mäts från manipuleringen av de oberoende variablerna. I denna studie kommer den beroende variabeln vara aggregeringstiden av en stor datamängd till en webbapplikation mätt i sekunder. För att få en högre validitet i studien kommer datapunkter som avviker till stor del från mätningar att tas bort (Wohlin et al. 2012).

Den kontrollerade miljön experimentet kommer att genomföras inom kommer att endast bestå av lokalt installerad teknologi. Anledningen till detta är på grund av att det skapar en högre validitet då faktorer som exempelvis nätverkshastighet ej kommer att påverka studien. Alla delar av experimentet kommer att genomföras på samma enhet för att undvika orsaksfaktorer (Wohlin et al. 2012).

4.1.1 Datagenerering

Att kunna skapa testdata för att uppfylla mål en utvecklare testar för är viktigt inom

mjukvaruutveckling, framförallt är möjligheten att kunna skapa testdata viktigt för att

minska utvecklingskostnader för mjukvara (Pargas, Harrold och Peck 1999). Generation

av testdata som att kunna generera testdata är även viktigt för att kunna skapa en mer exakt replikering för kommande studier då det är ännu en aspekt av kontroll. (Wohlin et al. 2012). I figuren Fig. 8 nedan illustreras ett JSONobjekt från ett öppet dataset från (Öppna data och PSI 2020-02-21).

{ "nyckelkod" : "123307", "period" : "201907", "tidpunkt" :

"2019-07-06T00:00:00+00:00", "detaljniva" : "Dag", "enhet" : "kWh",

"forbrukningstyp": "EL", "varde": 82763.784511}

,→

,→

Fig. 8: Strukturmall för genererat JSONobjekt.

4.2 Alternativa metoder

En metod som alternativt skulle kunna användas är en fallstudie för att få ett perspek- tiv hur den utvecklade mjukvaran skulle kunna fungera i en verklig miljö (Moher och Schneider 1981). Det finns dock svårigheter med att använda fallstudier för arbetet då det ej finns möjlighet eller resurser att utföra en sådan studie då en verklig miljö inom Big Data saknas. Enligt Wohlin et al. (2012) är fallstudier även svåra att återskapa.

Enkätstudier är en alternativ metod som ej är lämplig att använda för arbetets hypotes.

Anledningen till den bristande lämpligheten för enkätstudier för arbetet är att de endast har möjligheten att samla in människors åsikter och tankar utan kontroll över studien (Wohlin et al. 2012). Eftersom studien främst ämnar att mäta kvantitativ data i form av aggregeringstider för energiförbrukningsdata är enkätstudier av låg relevans för arbetet då enkätstudier enligt Wohlin et al. (2012) främst involverar data från människor.

4.3 Forskningsetik

Att genomföra experiment av olika slag har möjligheten till att medföra forskningsetiska problem. Dessa problem är i synnerhet mycket viktiga om experiment innefattar män- niskor som i sin tur måste ge ett informerat samtycke för deltagandet i experimentet (Wohlin et al. 2012). Även mycket små risker med att använda människor i experiment måste kunna styrkas med en vetenskaplig nytta av någon form (Wohlin et al. 2012).

Inom området big data finns det unika forskningsetiska problem som är viktiga att ta upp. Det problemet som är mest relevant för detta arbete är identifikation av användare från den data de genererar. Genom att analysera anonymiserad data från människor kan organisationer få reda på stora delar information från utvalda grupper av människor (Zwitter 2014). Genom att generera energiförbrukningsdata med struktur från en anonymiserad, öppen datakälla minskar risken för att känslig information kring människor läcks ut då datan är genererad. Något som även bidrar till en minskad risk för att data läcks ut är att experimentet genomförs i en lokal miljö.

Att kunna repetera ett experiment är en viktig del av empiriska studier för att

kunna styrka korrektheten av en studie. Att ha möjligheten att kunna återskapa en

studie är även viktigt för kommande forskning (Wohlin et al. 2012).

datan som används i experimenten ska finnas tillgängligt. Detta kommer att inkluderas

på Github och i tillhörande Appendix.

5 Genomförande

5.1 Litteraturstudie

En litteraturstudie är en nödvändig studie som måste genomföras innan progressionen samt pilotstudien kan genomföras. Litteraturstudien har som syfte att samla in informa- tion som anses nödvändig för att genomföra studien.

Manualen för PHP används för att få insikt över hur PHP fungerar för att koda och avkoda JSON-objekt. PHP är ett lämpligt språk att använda för att arbeta med JSON-formatet då det är inbyggt i PHP 5 och PHP 7 (JavaScript Object Notation 2020- 03-20). En aspekt som är relevant för att motivera lämpligheten för användningen av PHP är språkets hastighet då större datamängder ska genereras. Genom en sökning på sökorden "php language speed" på Google.com finner man en tråd på Stackoverflow på första resultatsidan. I tråden på Stackoverflow.com skriver användaren cletus att även fast PHP är långsammare än exempelvis C++ så spelar hastighetsskillnaden mindre roll, vilket är något som användaren Matthew påpekar i samma tråd som beskriver att effektiviteten för ett givet programmeringsspråk även handlar om att välja ett lämpligt språk för uppgiften (Curren 2010). Då PHP har inbyggt stöd för JSON i språket kommer det att användas både för att generera lämpliga dataset samt för att användas som serverspråk för webbapplikationen som ska byggas. Boken "Webbutveckling med PHP och MySQL" skriven av Montathar Faraon kommer att användas för att utveckla webbapplikationen i PHP som ska kommunicera med MySQL samt Apache Spark då den går igenom PHP och MySQL på ett detaljerat sätt (Faraon 2011).

Boken "Spark: The Definite Guide" skriven av Matei Zaharia har fullständig infor- mation om hur man kommer igång med att använda Apache Spark samt skriva arbetsprogram i Scala (Chambers och Zahari 2018). Det som gör boken relevant är att den är skriven av skaparen av Apache Spark. På webbplatsen för Apache Spark finns även dokumentation som kommer att användas under framtagningen av artefakten för arbetet (Spark Overview 2020-04-10).

5.2 Konfiguration

För att möjliggöra genomförandet av studien har Apache Spark (version 2.4.5 med Hadoop 2.7) samt MySQL (version 8.0.19) installerats i den lokala testmiljön med oförändrade standardinställningar. Ett separat administratörskonto med fulla rättigheter har även skapats för MySQL-installationen för att undvika att känsliga uppgifter som exempelvis lösenord läcks i samband med källkoden. För att enkelt kunna bygga program i Scala med Apache Spark så har även sbt laddats ned vilket är ett verktyg för att enklare bygga applikationer i Scala då den tar hand om alla beroenden som Apache Spark och Scala har.

PHP (version 7.2.24) med standardinställningar har även installerats i den lokala

testmiljön för att möjliggöra att applikationen som implementerar Apache Spark och

MySQL ska fungera. Ingen mjukvara för webbservrar har installerats då PHP har

möjligheten att tillhandahålla en lokal webbserver genom att starta den i mappen där

index.php finns tillgänglig. För att underlätta strukturen för PHP-applikationen har

en routerklass implementerats i index.php som returnerar korrekt PHP-fil beroende på

<?php

class Router {

protected $routes = [

"" => "controllers/index.controller.php",

"query" => "controllers/query.controller.php"

];

public function route($uri) { switch($uri) {

case "":

return $this->routes[""];

break;

case "query":

return $this->routes["query"];

break;

default :

return "controllers/404.controller.php";

break;

} } }

?>

Fig. 9: Kod för Router.php.

På GitHub har en förvaringsplats för all kod som behövs för att kunna replikera experimentet skapats. Genom att använda Git kan därför all kod laddas ned enkelt genom att klona förvaringsplatsen för arbetet till en lokal testmiljö.

De delar som utgör helheten av arbetet består av filer för datageneration, en en- klare webbapplikation som skickar förfrågan till antingen MySQL eller Apache Spark och renderar ut tabeller beroende på val. Ett arbetsprogram för Apache Spark skrivet i Scala har även utvecklats. För mätning av svarstider i webbläsaren Firefox har två stycken Javaskript för insticksmodulen Greasemonkey tagits fram, ett för att skicka en förfrågan, och ett för att mäta svarstider i millisekunder till en CSV-fil.

5.3 Progression

Följande kapitel kommer att behandla progressionen i arbetet. All kod som används i progressionen kommer att finnas på Github med en fotnot på varje sida för den kod som tas upp under varje delmoment.

5.3.1 Datageneration

Det första som skapades under arbetets gång var script för att generera datafiler enligt önskad storlek ¹ . Koden för detta skrevs i PHP. Det slutgiltiga programmet för fram-

1

https://github.com/a17robda/Examensarbete/commit/7a6a333

tagning av data skrevs vid ett senare skede när problem med att arbeta med enstaka, stora filer i JSON-format framkom. Det slutgiltiga datagenerationsprogrammet stöder därför uppdelning av JSON-filerna i mindre delar ² . Detta ändrades senare till en mindre filstorlek om 14MB/fil ³ . Koden som genereras har liknande struktur som energiförbrukn- ingsdatan från Umeå Energi på Öppna data och PSI (2020-02-21) med några repetitiva kolumner borttagna. Dessa kolumner är period, detaljnivå samt förbrukningstyp som finns i Fig. 8. Förbrukningsvärden för den genererade datamängden genererades slumpmässigt genom att seeda srand i PHP med värdet 1024 för att få samma slumpmässiga sekvens i datagenerationen vid varje exekvering ⁴ .

{"tkeycode":157705,"tstamp":"1985-10-31T11:30:00+00:00","tunit":"kwh",

"tvalue" :22675}

Fig. 10: Exempel för ett genererat JSON-objekt.

I liknande experiment använder Honarvar och Sami (2016) en tidsintervall på 30 minuter för varje datapunkt, denna tidsintervall kommer att användas i detta experiment. Värdena för det minimala samt maximala energiförbrukningsvärdet per halvtimme i Kilowatt tas fram genom att avläsa dessa värden från redan existerande JSON-data från Öppna data och PSI (2020-02-21) för Umeå centrum genom ett framtaget PHP-script ⁵ . För att få bättre spridning på den genererade datan har det sammanlagda medelvärdet för alla minimala samt maximala värden från fyra JSON-dataset över Umeå centrum dividerats med 48 för att få ut möjliga lägsta samt högsta värde för varje halvtimme att generera slumptal mellan. Ett exempel på ett genererat dataobjekt illustreras i figuren Fig. 10 ovan.

5.3.2 MySQL

I MySQL har SQL-kod för skapandet av tre olika databaser skapats, en separat databas för varje datamängd i JSON-format. Varje databas består av en tabell som har ett fält för ID samt ett JSON-fält för varje JSON-objekt som skapas genom en separat SQL-fil ⁶ . I figuren Fig. 11 visas SQL-koden för skapandet av dessa databaser.

2

https://github.com/a17robda/Examensarbete/commit/5774a5f

3

https://github.com/a17robda/Examensarbete/commit/8d12d27

4

https://github.com/a17robda/Examensarbete/commit/5774a5f

5

https://github.com/a17robda/Examensarbete/commit/10e72a7

6

https://github.com/a17robda/Examensarbete/commit/3fc606f

DROP DATABASE IF EXISTS exjobb_1;

CREATE DATABASE exjobb_1;

USE exjobb_1;

CREATE TABLE jsontable(

id int AUTO_INCREMENT, jsonrow JSON,

PRIMARY KEY(id) ); ...

Fig. 11: Kod för skapandet av en databas samt tabell i SQL.

Eftersom MySQL inte har stöd för att på ett automatiskt sätt kunna ladda in JSON-data från filer genom exempelvis funktionerna LOAD DATA eller LOAD DATA INFILE så skapades PHP-kod för att ladda varje JSON-fil och föra in dessa i respektive databas samt dess tabeller på ett dynamiskt sätt ⁷ . Nedan i figuren Fig. 12 följer den del av skriptet för dynamisk JSON-införing till MySQL.

7

https://github.com/a17robda/Examensarbete/commit/0133a78

<?php ...

foreach ($files as $f) {

$qmarks = "";

$valArr = array ();

$js = file_get_contents($folderPath."/".$f);

$decoded = json_decode($js, true);

$lastArr = end($decoded);

foreach ($decoded as $arr) { foreach($arr as $k => $v) {

if ($k == "tkeycode") {

$insert.= '{"'.$k.'"'.':'.$v.",";

}

if ($k == "tstamp") {

$insert.= '"'.$k.'"'.':'.'"'.$v.'"'.",";

}

if ($k == "tunit") {

$insert.= '"'.$k.'"'.':'.'"'.$v.'"'.",";

}

if ($k == "tvalue") {

$insert.= '"'.$k.'"'.':'.$v."}";

} }

echo $insert." \n ";

array_push($valArr, $insert);

if ($arr["tkeycode"] != $lastArr["tkeycode"]) {

$qmarks.= "(?),";

} else {

$qmarks.= "(?)";

} $insert = "";

} $sql = "INSERT INTO jsontable (jsonrow) VALUES { $qmarks } ";

$stmt = $conn->prepare($sql);

$stmt->execute($valArr);

... }

Fig. 12: Kod för inmatning av JSONdata till MySQL.

5.3.3 Apache Spark

För att möjliggöra användandet av Apache Spark för sökning av data i JSON-format så skrevs inledningsvis det arbetsprogram som söker igenom JSON-filer i en specifik mapp.

Programmet skrevs i Scala och byggdes genom Sbt ⁸ . För att implementera olika typer av sökfrågor mot JSON-filerna samt seed för konsistent slumpgeneration av maximalvärden för sökfrågorna implementerades inmatningsparametrar i Scala-programmet som hanteras genom en funktion för slumptalsgeneration. En funktion för val av sökfråga implementer- ades även ⁹ .

5.3.4 Webbapplikation

En enklare webbapplikation skapades i PHP för att sammankoppla MySQL-databasen samt implementationen i Apache Spark mot en webbapplikation ¹⁰ . Webbapplikationen består av kod som antingen skickar en sökfråga till MySQL-databasen eller startar en instans av det skapade arbetsprogrammet i Apache Spark som nämndes i tidigare kapi- tel beroende på input i webbapplikationen genom en POST-förfrågan. De parametrar som förändras genom webbapplikationen är typ av sökfråga, iterationsnummer, val av aggregering, samt datastorlek. Nedan i figuren Fig. 13 följer en övergripande bild över webbapplikationens flöde.

Fig. 13: Flöde över webbapplikationen från klient till Apache Spark/MySQL.

5.3.5 Mätningsskript

Utförandet av mätningarna i experimentet för arbetet implementerades genom att skapa två stycken skript för insticksmodulen Greasemonkey i Firefox ¹¹ . Det första skriptet som skapades fyller i webbapplikationens formulär med de parametrar som ska sökas på och trycker på knappen för att genomföra en sökning. Det andra skriptet lägger till den totala tiden i millisekunder som sökfrågan tog att utföra till en CSV-fil och dirigerar om webbläsaren till det föregående formuläret. Tiden som skrivs i CSV-filen mellan varje sökning fås genom Date.now() funktionen i Javascript.

8

https://github.com/a17robda/Examensarbete/commit/8d12d27

9

https://github.com/a17robda/Examensarbete/commit/e432881

10

https://github.com/a17robda/Examensarbete/commit/3fc606f

11

https://github.com/a17robda/Examensarbete/commit/2d00e53

5.4 Pilotstudie

En pilotstudie är en mindre studie som genomförs för att kunna avgöra om det valda tillvägagångssättet i relation till hypotesen är relevant för att kunna utföra experimentet på ett lämpligt sätt. Genom pilotstudien kan man upptäcka brister över olika aspekter i arbetet som kan utgöra stora hinder. Detta kapitel kommer att genomgå pilotstudien som genomförts i sin helhet och presentera resultaten för denna. Kapitlet avslutas av en diskussionsdel som behandlar problem som uppkom i samband med pilotstudien och potentiella lösningar för dessa.

5.4.1 Genomförande av pilotstudie

Pilotstudien i som tas upp i detta kapitel genomfördes och mättes i en lokal testmiljö på en dator med följande specifikationer nedan.

Operativsystem: Ubuntu 18.04.4 LTS x86_64

Processor: Intel i5-7200U @ 3.100GHz

Grafik: NVIDIA GeForce 940MX

RAM: 15916MB

Lagring: KINGSTON A400 240GB SSD

För att mäta och samla in data användes Javascript för insticksmodulen Greasemonkey i webbläsaren Firefox. Både MySQL samt Apache spark mättes genom två typer av sök- fråga, en enkel sökfråga samt en mer komplex sökfråga. Den enkla sökfrågan returnerar en enda rad där nyckelkoden är ett slumpmässigt seedat heltal som har ett värde som ej över- skrider det totala antalet JSON-objekt. Den mer komplexa frågan använder funktioner för interna operationer som troligtvis ökar arbetsmängden hos MySQL samt Apache Spark.

Data samlades in för alla testfall i MySQL samt Apache Spark under 150 iterationer per testfall. Datan som mätningarna utfördes på var JSON-data i storleken 1.4GB, for- matet för datan som mättes i MySQL var JSONdata i JSONformat i en tabell medans mätningarna i Apache Spark utfördes genom laddning av 1.4GB JSONfiler i storlekarna

~14MB per fil. Nedan i figurerna Fig. 14 samt Fig. 15 följer koden som implementerades

för sökfrågorna som användes för MySQL och Apache Spark.

<?php ...

switch ($complexity) { case "simple":

return 'SELECT * FROM jsontable WHERE jsonrow->>"$.tkeycode" = '.$maxrand;

,→

break;

case "complex":

return 'SELECT MAX(CAST(jsonrow->>"$.tvalue" AS UNSIGNED)) AS maximum,

,→

MIN(CAST(jsonrow->>"$.tvalue" AS UNSIGNED)) AS minimum, AVG(CAST(jsonrow->>"$.tvalue" AS UNSIGNED)) AS average, STD(CAST(jsonrow->>"$.tvalue" AS UNSIGNED)) AS std_dev, VARIANCE(CAST(jsonrow->>"$.tvalue" AS UNSIGNED)) AS variance FROM jsontable WHERE jsonrow->>"$.tkeycode" < '.$maxrand;

break;

...

Fig. 14: Sökfrågor till MySQL via PHP

choice match { case "0" =>

return "SELECT * FROM values WHERE tkeycode = " + maxRand case "1" =>

return "SELECT MAX(tvalue) AS maximum, MIN(tvalue) AS minimum, AVG(tvalue) AS average, STD(tvalue) AS std_dev,

VARIANCE(tvalue) AS variance FROM values WHERE tkeycode < "

+ maxRand

,→

,→

,→

}

Fig. 15: Sökfrågor till Apache Spark i Scala.

5.4.2 Resultat av pilotstudie

Resultatet som tas fram genom utförandet av pilotstudien är diverse datapunkter i CSV- format. Dessa datapunkter representerar aggregeringstider för enkla, samt komplexa sök- frågor i MySQL samt Apache Spark för JSON-data i mängden 1.4GB för 150 sökningar.

Resultaten av pilotstudien visualiseras nedan i figurerna Fig. 16 samt Fig. 17 genom

grafer som beskriver aggregeringstiden för varje iteration. Resultaten kommer även att

visualiseras genom stapeldiagram som beskriver medelvärdet samt standardavvikelsen för

MySQL samt Apache Spark. Dessa diagram visas nedan i figurerna Fig. 18 och Fig. 19.

Fig. 16: Aggregeringstider för enkla frågor.

Fig. 17: Aggregeringstider för mer komplexa frågor.

Fig. 18: Medelvärden samt standardavvikelser för enkla frågor.

Fig. 19: Medelvärden samt standardavvikelser för mer komplexa frågor.

5.4.3 Diskussion av pilotstudie

Genom att analysera resultaten av den genomförda pilotstudien kan experimentets relevans och grad av genomförbarhet tolkas. Pilotstudien var i stort sett lyckad men visade även på brister i den framtagna artefakten.

En av dessa brister som kommer att åtgärdas inför det slutgiltiga experimentet för att försöka få ner aggregeringstiderna något då de förväntas bli längre vid större datamängder är att byta hårdvara för den lokala testmiljön som experimentet kommer att genomföras i. Genom att använda mer kraftfull hårdvara för arbetet kan troligtvis aggregeringstiderna för energiförbrukningsdatan minskas något.

Då mätningarna för pilotstudien genomfördes på en bärbar dator med internetup-

pkoppling via WI-FI finns det en risk att mätningarna för pilotstudien har påverkats av

detta genom exempelvis diverse störningar från nätverksuppkopplingen. Detta är dock

antagligen en mindre trolig anledning till de till synes höga aggregeringstiderna men som

kommer att ändras inför det slutgiltiga experimentet som ej kommer att ha tillgång till

internet eller andra nätverk.

6 Tillämpade ändringar

Denna delsektion kommer att genomgå de ändringar som tillämpats för arbetets experi- ment. Syftet med denna del är att presentera de ändringar som tillämpats samt diskutera och motivera dessa ändringar för att få en djupare förståelse kring varför dessa ändringar tillämpats.

6.1 Modifiering av komplex sökfråga

För att få en mer verklighetsbaserad förankring i de olika typerna av sökfrågor kommer vissa förändringar göras för sökfrågorna. I en forskningsartikel av Loghin et al. (2015) genomförs en undersökning på Big Data på datorkluster med litet antal noder. Efter- som denna forskningsartikel behandlar ett område som har likheter med studien som ska genomföras för detta arbete modifieras den komplexa sökfrågan för att inkludera ett spann av datum likt frågan i arbetet av Loghin et al. (2015) ¹² . Nedan i figur Fig. 20 följer den modifierade, mer komplexa sökfrågan från pilotstudien med datumspann likt den som användes i studien av Loghin et al. (2015) som implementeras i PHP samt Apache Spark.

<?php ...

case "complex":

return 'SELECT AVG(CAST(jsonrow->>"$.tvalue" AS UNSIGNED)) AS average,

,→

SUM(CAST(jsonrow->>"$.tvalue" AS UNSIGNED)) AS sum_energy, MAX(CAST(jsonrow->>"$.tvalue" AS UNSIGNED)) AS maximum, MIN(CAST(jsonrow->>"$.tvalue" AS UNSIGNED)) AS minimum, STD(CAST(jsonrow->>"$.tvalue" AS UNSIGNED)) AS std_dev, VARIANCE(CAST(jsonrow->>"$.tvalue" AS UNSIGNED)) AS variance FROM jsontable_1 where jsonrow->>"$.tstamp" BETWEEN

"1976-12-31%"

,→

AND '.'"'.randomizeDate($maxrand).'%"';

break ; ...

Fig. 20: Den modifierade, mer komplexa sökfrågan i PHP.

Genom att implementera ett datumspan för den komplexa sökfrågan likt den som imple- menterats för Loghin et al. (2015) är målet att delvis få en högre grad av verklighets- förankring genom att använda en typ av aggregering som använts tidigare, men även för att undersöka hur MySQL samt Apache Spark hanterar aggregeringsfrågor av mer komplex grad där sökningarna genomförs på ett varierande datumspann.

12

https://github.com/a17robda/Examensarbete/commit/f399d5d

6.2 Byte av lokal testmiljö

För att kunna minska längden av aggregeringstiderna som påvisades i pilotstudien kom- mer hårdvaran för den lokala testmijön att ändras till mer kraftfull sådan. En annan anledning till förändring av hårdvaran är på grund av att minska faktorerna som kan påverka resultatet för de olika testfallen i experimentet i arbetet. Genom att använda en dedikerad dator med ett nyinstallerat operativsystem minskas troligen riskerna att annan mjukvara stör mätningarna för experimentet. En ytterligare ändring som implementerats i samband med byte av hårdvara är att inaktivera tillgången till samtliga nätverk.

6.2.1 Slutgiltig hårdvaruspecifikation

Den slutgiltiga hårdvaruspecifikationen i den lokala testmiljön för experimentet kommer att beskrivas i denna del. Nedan i figur Fig. 21 följer den slutgiltiga hårdvaruspecifika- tionen som används för arbetet.

Hårdvaruspecifikation

Operativsystem: Ubuntu 19.10 x86_64

Processor: Intel i5-6600K @ 3.900GHz

Grafik: NVIDIA GeForce GTX 960

RAM: 15956MB

Lagring: Western Digital WD Green 120GB SSD

Nätverksuppkoppling: Ingen

Fig. 21: Slutgiltig hårdvaruspecifikation för experimentet

De förändringar av hårdvaran som troligtvis har störst påverkan på arbetets experiment är användandet av en snabbare fyrkärnig processor för experimentet än den tvåkärniga pro- cessorn som användes för pilotstudien. Resterande förändringar av hårdvaran har troligtvis ingen, eller en väldigt liten påverkan av slutresultatet i jämförelse med pilotstudien.

6.2.2 Slutgiltig mjukvaruspecifikation

Den slutgiltiga mjukvaruspecifikationen för experimentet har ändrats något sedan pilot- studien, Exempelvis används en nyare version av PHP inför de slutgiltiga mätningarna.

Nedan i figur Fig. 22 följer den slutgiltiga mjukvaruspecifikationen som artefakten im- plementerats för.

Mjukvaruspecifikation

Webbläsare: Firefox 76.0.1_64

PHP: 7.3.11-0ubuntu0.19.10.4

Mysql: 8.0.20-0ubuntu0.19.10.1

Scala: 2.11.12 (OpenJDK 64-Bit Server VM, Java 1.8.0_252)

Apache Spark: version 2.4.5

6.3 Ytterligare ändringar

Ytterligare ändringar som tillämpas för arbetet är att ta bort alla externa SQL-filer för MySQL för att skapa databaser. Då dessa SQL-filer var små så skapades databaserna manuellt för varje testfall. Däremot skapas MySQL-tabellen i skriptet jsonMysql.php vid införingen av data till MySQL ¹³ .

13

https://github.com/a17robda/Examensarbete/commit/f399d5d

7 Utvärdering

7.1 Presentation av testfall

Från resultatet av pilotstudien samt efter att ändringar genomförts för arbetet så kan testfall för huvudexperimentet tas fram. Totalt kommer sex stycken testfall att presenteras i detta delkapitel samt framtagningen av dessa. De testfall som tagits fram kommer att listas nedan i figur Fig. 23 för att sedan diskuteras kring.

Specifikation av testfall

Testfall T1: 400 simpla aggregeringar mot JSON-data motvarande cirka 1.4GB för båda aggregeringsteknologierna.

Testfall T2: 400 komplexa aggregeringar mot JSON-data motvarande cirka 1.4GB för båda aggregeringsteknologierna.

Testfall T3: 200 simpla aggregeringar mot JSON-data motvarande cirka 6.7GB för båda aggregeringsteknologierna.

Testfall T4: 200 komplexa aggregeringar mot JSON-data motvarande cirka 6.7GB för båda aggregeringsteknologierna.

Testfall T5: 100 simpla aggregeringar mot JSON-data motvarande cirka 13.5GB för båda aggregeringsteknologierna.

Testfall T6: 100 komplexa aggregeringar mot JSON-data motvarande cirka 13.5GB för båda aggregeringsteknologierna.

Fig. 23: Specifikation av de olika testfallen.

Samtliga testfall i tabellen ovan genomförs för både MySQL samt Apache Spark per testfall. För båda aggregeringsteknologierna genomförs sökfrågorna för samtliga aggregeringar genom en enkel samt en mer komplicerad sökfråga. Den enklare sökfrågan är samma fökfråga som pilotstudien som visas i caset "simple" i figurerna Fig. 14 samt Fig. 15 . Den mer komplicerade sökfrågan är den som visas i figuren Fig. 20. Samma aggregeringsfråga av mer komplex grad används även för Apache Spark i Scala.

De datamängder som MySQL samt Apache Spark aggregerar mot är data som genererats med skriptet generate.php i målstorlekarna 1000MB, 5000MB samt 10000MB. Då skriptet generate.php ej räknar med vissa karaktärer som JSON-objekt består av, exempelvis klamrar och kommatecken så blir den faktiska datan som genereras större än datamålet som specifieras i skriptet. Detta är dock inget signifikant problem för experimentet då datan som genereras via skriptet har samma datastorlek och värden varje gång vid samma datamål.

Allt eftersom datamängden ökar kommer även aggregeringstiden troligtvis även att öka. Då pilotstudien visade på en något hög aggregeringstid i millisekunder för ~1.4GB JSON-data kommer antalet aggregeringar att minska allt eftersom datamängden ökar.

Detta genomförs för att kunna utvinna samma antal datapunkter för både MySQL och

Apache Spark inom en resonabel tidsperiod för det testfall som mätningarna utförs på.

7.1.1 Dataspecifikation för testfall

För att kunna få en mer detaljerad inblick i experimentets testfall är det nödvändigt att ytterligare beskriva datan på en mer detaljerad nivå. Denna delsektion syftar till att delvis beskriva datan mer ingående, men syftar även till att motivera den minskade mängden av aggregeringar som genomförs för varje ökad datamängd. Nedan i figur Fig. 24 följer en tabell som beskriver antalet JSON-objekt för varje datamängd för samtliga testfall.

Dataspecifikation per testfall

Testfall Antal JSON Objekt Total datamängd T1 & T2: 15307048 JSON-objekt ~1.4GB T3 & T4: 75862409 JSON-objekt ~6.7GB T5 & T6: 150787803 JSON-objekt ~13.5GB

Fig. 24: Dataspecifikation för samtliga testfall

Datan som tagits fram för experimentet har samma struktur som i den tidigare pilotstudien och som genereras via skriptet generate.php i form av genererad energiför- brukningsdata i JSON-objekt. Ett exempel på ett sådant objekt illustreras i tidigare figur Fig. 10.

Varje datamängd för samtliga testfall som aggregeringar ska utföras på i MySQL samt Apache Spark innehåller ett stort antal JSON-objekt. Då pilotstudien för ~1.4GB data hade en relativt hög aggregeringstid i Apache Spark måste troligtvis kompromisser göras för insamling av data för större datamängder för att kunna fullfölja mätningarna.

Den kompromiss som valdes för detta arbete är att minska antalet datapunkter som samlas in för att fortfarande kunna genomföra aggregeringar för större datamängder.

7.2 Resultat

I detta delkapitel presenteras resultaten för samtliga testfall för arbetet. Samtliga mät- ningar för varje testfall genomförs på data som specificerats i föregående delsektion. Dessa resultat presenteras som grafer med data i form av aggregeringstider mätt i millisekunder.

Resultaten kommer även att presenteras som stapeldiagram för medelvärden för samtliga testfall med standardavvikelser.

7.2.1 Testfall T1: 400 simpla aggregeringar (~1.4GB)

Testfall T1 mäter 400 aggregeringar mot en lokal webbapplikation av enkel typ enligt den

enkla aggregeringsfrågan som specificerats i föregående del. 400 aggregeringar genomfördes

för både MySQL samt Apache Spark på en datamängd bestående av ~1.4GB. Resultaten

av dessa mätningar visas i figurerna Fig. 25 samt Fig. 26 som visar medelvärden och

standardavvikelserna för dessa.

Fig. 25: Aggregeringstider för 400 aggregeringar av enkel typ för cirka 1.4GB data.

Fig. 26: Medelvärden och standardavvikelser för 400 aggregeringar av enkel typ för cirka

1.4GB data.

Spark för en aggregeringsfråga av simpel typ på en datammängd bestående av ~1.4GB genererad energiförbrukningsdata i form av JSON-objekt.

7.2.2 Testfall T2: 400 komplexa aggregeringar (~1.4GB)

I testfall T2 mäts 400 aggregeringar mot en lokal webbapplikation likt föregående testfall med skillnaden att frågan är av mer komplex typ. Resultatet för detta testfall presenteras nedan i figurerna Fig. 27 samt Fig. 28.

Fig. 27: Aggregeringstider för 400 aggregeringar av mer komplex typ för cirka 1.4GB

data.

Fig. 28: Medelvärden och standardavvikelser för 400 aggregeringar av mer komplex typ för cirka 1.4GB data.

För testfall T2 har MySQL fortfarande en lägre aggregeringstid. Det är dock en signifikant skillnad mellan standardavvikelserna mellan MySQL och Apache Spark. Stapeldiagram- met för medelvärden och standardavvikelse visar på att Apache Spark har mer stabila aggregeringstider för testfallet än MySQL när det kommer till en högre kompexitet av aggregeringsfråga.

7.2.3 Testfall T3: 200 simpla aggregeringar (~6.7GB)

I testfall T3 genomfördes 200 aggregeringar av simpel typ för MySQL samt Apache Spark

för genererad energiförbrukningsdata i JSONformat på en datamängd av ~6.7GB. Resul-

tatet för detta testfall presenteras nedan i figurerna Fig. 29 samt Fig. 30.

Fig. 29: Aggregeringstider för 200 aggregeringar av enkel typ för cirka 6.7GB data.

Fig. 30: Medelvärden samt standardavvikelser för 200 aggregeringar av enkel typ för cirka 6.7GB data.

Resultatet av detta testfall har flera likheter med Testfall T1 där MySQL visar på en

signifikant lägre aggregeringstid än Apache Spark för 200 aggregeringsfrågor av enkel typ.

Grafen för MySQL visar dock på en spik i början av mätningen. Denna spik bedöms dock ej vara en mätningsanomali då det förekommer flertalet mätpunkter i början med högre aggregeringstid i början av mätningen.

7.2.4 Testfall T4: 200 komplexa aggregeringar (~6.7GB)

Testfallet T4 är testfallet där mätningar gjordes på 200 aggregeringar med en enkel ag- gregeringsfråga på en datamängd av ~6.7GB data i JSON-format. Resultaten för detta testfall visas i diagrammen Fig. 31 samt Fig. 32 nedan.

Fig. 31: Aggregeringstider för 200 aggregeringar av komplex typ för cirka 6.7GB data.

Fig. 32: Medelvärden och standardavvikelser för 200 aggregeringar av komplex typ för cirka 6.7GB data.

Figurerna Fig. 31 samt Fig. 32 visar på en signifikant skillnad mellan MySQL och Apache Spark för mer komplexa aggregeringar vid en datamängd av ~6.7GB data. Stan- dardavvikelsen för MySQL visar på en mindre grad av stabilitet för aggregeringstiderna än Apache Spark som har mer stabila aggregeringstider under testfallet. Stapeldiagrammet för medelvärdena föreslår även att denna datamängd är den mängd av data där Apache Spark har en lägre aggregeringstid än MySQL.

7.2.5 Testfall T5: 100 simpla aggregeringar (~13.5GB)

För testfallet T5 genomfördes 100 aggregeringar av simpel typ mot energiförbrukningsdata

i JSONformat på en total datamängd i storleken ~13.5GB. Resultatet för dessa mätningar

visas i diagrammen Fig. 33 samt Fig. 34 nedan.

Fig. 33: Aggregeringstider för 100 aggregeringar av enkel typ för en datamängd av cirka

13.5GB.

Likt tidigare testfall för aggregeringsfrågor av simpel typ har MySQL lägre ag- gregeringstider är Apache Spark. Dock verkar skillnaderna mindre mellan de två olika teknologierna för denna datamängd även för aggregeringsfrågor av enkel typ.

7.2.6 Testfall T6: 100 komplexa aggregeringar (~13.5GB)

Det slutgiltiga testfallet för arbetet är testfall T6 där data samlades in för 100 ag- gregeringar av mer komplex typ mot en datamängd av ~13.5GB data. Resultatet för detta testfall visas i diagrammen Fig. 35 samt Fig. 36 nedan.

Fig. 35: Aggregeringstider för 100 aggregeringar av komplex typ för cirka 13.5GB data.

Fig. 36: Medelvärden och standardavvikelser för 100 aggregeringar av komplex typ för cirka 13.5GB data.

Resultatet för testfall T6 visar på en signifikant skillnad mellan MySQL och Apache Spark där Apache Spark tydligt har lägre aggregeringstider än MySQL trots att ag- gregeringstiderna överlag är flera minuter långa. Likt tidigare testfall för mer komplexa aggregeringar har Apache Spark en högre stabilitet gällande aggregeringstiderna då grafen för MySQL för detta testfall är väldigt "spikig".

7.3 Analys

Om man analyserar resultaten från mätningarna av aggregeringarna av den genererade

energiförbrukningsdatan i JSON-format kan man urskilja mönster och dra generella slut-

satser trots det minskade antalet mätningar vid större datamängder. Diagrammen för

medelvärden samt standardavvikelser används för att bekräfta slutsatserna samt ge en

större insikt i mätresultaten. Nedan i figurerna Fig. 37 samt Fig. 38 presenteras resul-

taten för samtliga testfall i kombinerade diagram för resultatet och medelvärden samt

standardavvikelser.

Fig. 37: Aggregeringstider för samtliga testfall.

Fig. 38: Stapeldiagram med medelvärden samt standardavvikelser för samtliga testfall.

En initial analys som går att göra från mätresultaten i graferna är att aggregeringstiden för de olika testfallen ökar signifikant allt eftersom datamängden ökar. Denna signifikanta ökning av aggregeringstid är troligtvis ett resultat av den begränsade hårdvaran som användes för testfallen. Denna ökning av aggregeringstiderna har dock likheter med resultatet i forskningsartikeln av Pérez-Chacón et al. (2018) då även där ökades beräkn- ingstiderna signifikant när datamängden ökades till flertalet gigabyte trots användandet av en klustrad datormiljö i Apache Spark. En annan trolig anledning till de överlag höga aggregeringstiderna för samtliga testfall kan vara sättet MySQL samt Apache Spark gör sökningar på JSONdatan då all JSONdata låg i samma tabellkolumn för alla testfall.

Möjligen måste MySQL och Apache Spark läsa in all data i samtliga JSONkolumner vilket är en möjlig anledning till de överlag höga aggregeringstiderna. Detta är ett problem som Ongo och Kusuma (2018) beskriver med relationsdatabaser som MySQL då prestandan minskar i samband med att mängden data som lagras ökas. Detta verkar även vara ett problem i Apache Spark när endast en beräkningsnod används på begränsad hårdvara.

En ytterligare analys som går att göra enligt mätresultaten är att MySQL har lä-

gre aggregeringstider än Apache Spark för att aggregera enklare sökfrågor likt den

som används i arbetet för den simpla aggregeringsfrågan då Apache Spark presterade

betydligt sämre i denna kontext i samtliga testfall. Däremot föreslår mätresultaten att Apache Spark är snabbare än MySQL för att aggregera data i JSON-format genom mer komplexa sökfrågor när mängden data som ska aggregeras är större vilket kan ses i Fig.

35 . För sökfrågor där mängden data som ska sökas igenom har en hög varians exempelvis för den komplexa sökfrågan i arbetet där datumspannet kan variera stort verkar Apache Spark vara mer stabilt än MySQL då denna typ av sökfråga skapade färre spikar i grafen för Apache Spark än i MySQL.

7.4 Slutsatser

Den hypotes som togs fram i problemformuleringen som lyder "Apache Spark har en snabbare aggregeringstid mätt i millisekunder än MySQL vid aggregering av en stor mängd energiförbrukningsdata i JSON-format till en webbapplikation." är arbetets enda hypotes. Från denna hypotes i kontrast till mätresultaten för de olika testfallen kan man dra slutsatsen att Apache Spark kan ha en snabbare aggregeringstid än MySQL för aggregering av en stor mängd energiförbrukningsdata i JSON-format beroende på definitionen av stora mängder data samt komplexiteten på sökfrågan som ställs mot Apache Spark eller MySQL för att aggregera data. Därför kan inte arbetet ge ett definitivt svar för att antingen bekräfta eller falsifiera hypotesen. För aggregeringsfrågor av enklare grad presterade aldrig Apache Spark bättre än MySQL i samtliga testfall trots att skillnaderna mellan dessa aggregeringsteknologier till synes minskade något vid enkla aggregeringsfrågor mot en datamängd på ~13.5GB data som kan ses i figuren Fig. 33.

Däremot började Apache Spark i genomsnitt att ha lägre aggregeringstider än MySQL för större datamängder vid mer komplexa sökfrågor för aggregeringar där mängden data som aggregeras har hög variation vilket kan ses från stapeldiagrammen Fig. 32 samt Fig. 36. Denna slutsats kan delvis ge svar på den sekundära frågeställningen för arbetet som frågade vid vilken mängd data Apache Spark är snabbare än MySQL för att aggregera data. Om aggregeringen är av komplex typ verkar denna brytpunkt ligga vid en datamängd av ~6.7GB JSONdata och uppåt för detta arbete.

Ytterligare slutsatser som kan dras från arbetet är att det troligtvis ej är lämpligt att göra sökningar på data i JSONformat då aggregeringstiderna för MySQL samt Apache Spark var långa samt att aggregeringstiderna för de de båda aggregeringsme- toderna ökade med en väldigt signifikant grad när datamängden ökades från ~1.4GB JSON-data till de större datamängderna i samtliga testfall.

En annan slutsats som kan dras från resultatet av arbetet är att beräkningsramverk likt

Apache Spark som använder sig av MapReduce-modellen ej är lämpliga att använda

för att aggregera JSONdata på en enskild klusternod om aggregeringstiderna för dessa

operationer måste vara låga.