implementacija geojson izvorišta podataka i tablica u ... · sveuČiliŠte u zagrebu fakultet...
TRANSCRIPT
SVEUČILIŠTE U ZAGREBUFAKULTET ELEKTROTEHNIKE I RAČUNARSTVA
DIPLOMSKI RAD br. 1360
Implementacija GeoJSON izvorištapodataka i tablica u distribuiranom
sustavu za procesiranje tokovapodatakaTomislav Gracin
Zagreb, lipanj 2017.
Zahvaljujem mentoru doc. dr. sc. Zdravku Galiću, te bivšoj mentoriciprof. dr. sc. Mirti Baranović na svoj pomoći kroz ove silne godine studija; mamina srpljivosti, tati na pozivima u sedam ujutro, Pavici na svim sitnicama kojesu mi omogućile bezbrižne odmore, stricu na uvijek hladnoj glavi, teti na svimručkovima, seki na najboljem djetinjstvu. Zahvaljujem Tihani na motivaciji dastudij (ponovo) započnem, te Teni na motivaciji da ga završim. Zahvaljujem isvim svojim prijateljima koji su imali neiscrpan izvor pošalica na moj broj godinastudiranja na zajedničkom smijehu, život bi mi bio prazan bez vas. Zahvaljujemljudima koji vjeruju u mene kad to i sam ne činim. Naposlijetku, zahvaljujemsvima onima koji me inspiriraju, jer je to ono što me čini boljim i sretnim.
iii
Sadržaj
1. Uvod 1
2. Distribuirani sustavi za obradu tokova podataka 22.1. Metode obrade ulaznih podataka . . . . . . . . . . . . . . . . . . 2
2.1.1. Serijska obrada . . . . . . . . . . . . . . . . . . . . . . . . 22.1.2. Obrada tokova . . . . . . . . . . . . . . . . . . . . . . . . 22.1.3. MapReduce . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Big Data 43.1. Apache Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Moduli Hadoopa . . . . . . . . . . . . . . . . . . . . . . . 63.1.2. HDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.3. YARN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.4. Generalni princip rada u Hadoopu . . . . . . . . . . . . . . 8
3.2. Apache Spark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.1. Motivacija za razvoj . . . . . . . . . . . . . . . . . . . . . 93.2.2. Moduli Sparka . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2.1. Spark Core . . . . . . . . . . . . . . . . . . . . . 103.2.2.2. Resilient Distributed Dataset . . . . . . . . . . . 103.2.2.3. Spark SQL . . . . . . . . . . . . . . . . . . . . . 113.2.2.4. Spark Streaming . . . . . . . . . . . . . . . . . . 113.2.2.5. Spark MLlib . . . . . . . . . . . . . . . . . . . . 113.2.2.6. Spark GraphX . . . . . . . . . . . . . . . . . . . 123.2.2.7. SparkR . . . . . . . . . . . . . . . . . . . . . . . 12
4. Apache Flink 134.1. Osnovne značajke . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2. Organizacija Flink platforme . . . . . . . . . . . . . . . . . . . . . 15
iv
4.2.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.2. Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.3. Kernel (Runtime) . . . . . . . . . . . . . . . . . . . . . . . 164.2.4. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Flinkove odlike . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.4. Programiranje u Flink okruženju . . . . . . . . . . . . . . . . . . 19
4.4.1. DataSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.4.2. Transformacije na DataSetu . . . . . . . . . . . . . . . . . 204.4.3. Table API . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.4.4. Operacije na Tablicama . . . . . . . . . . . . . . . . . . . 22
5. Scala 23
6. GeoJSON 246.1. JavaScript Object Notation (JSON) . . . . . . . . . . . . . . . . . 24
6.1.1. Tipovi podataka . . . . . . . . . . . . . . . . . . . . . . . 246.1.2. Primjer JSON reprezentacije objekta . . . . . . . . . . . . 25
6.2. Povijest GeoJSONa . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2.1. Tipovi podataka . . . . . . . . . . . . . . . . . . . . . . . 266.2.2. Primjer GeoJSON strukture . . . . . . . . . . . . . . . . . 27
7. GeoTools 28
8. OpenStreetMaps 298.1. Značajke OpenStreetMap objekata . . . . . . . . . . . . . . . . . 30
8.1.1. Tipovi objekata . . . . . . . . . . . . . . . . . . . . . . . . 308.1.2. Ostala svojstva . . . . . . . . . . . . . . . . . . . . . . . . 32
9. Implementacija GeoJSON izvorišta podataka 339.1. Ideja rješenja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359.2. Rasčlanjivanje GeoJSON formata . . . . . . . . . . . . . . . . . . 359.3. Konverzija objekata . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.3.1. Mapa svojstava . . . . . . . . . . . . . . . . . . . . . . . . 409.3.2. Popunjavanje jednostavnog razreda . . . . . . . . . . . . . 42
9.4. UML Dijagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459.5. Primjeri korištenja . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.5.1. Podaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459.5.2. Programi . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
v
9.6. Rezultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489.7. Moguća buduća poboljšanja rješenja . . . . . . . . . . . . . . . . 51
10.Zaključak 52
Literatura 54
vi
1. Uvod
U okviru diplomskog rada trebalo je implementirati GeoJSON izvorište podataka(DataSource) i GeoJSON izvorište tablica (TableSource) u Apache Flink distri-buiranom sustavu za procesiranje tokova podataka. Za implementaciju trebaloje koristiti programski jezik Scala, GIS knjižnicu GeoTools, te OpenStreetMappodatke za područje Hrvatske. Prostorno izvorište podataka nužno je potrebanza kvalitetan rad sa prostornim podacima, a GeoJSON je jedan od standardau industriji. Sustav Apache Flink ne posjeduje potporu za izvorišta prostornihpodataka, te bi ova implementacija trebala biti od pomoći svima koji planirajuraditi na geoprostornim podacima u sustavu Apache Flink.
1
2. Distribuirani sustavi za obradutokova podataka
Obrada tokova podataka je računalna paradigma koja omogućava aplikacijamakorištenje ograničenog oblika paralelnog programiranja uz naglasak na brzo pri-manje i distribuiranje podataka. Podrazumijeva kontinuiranu obradu, agregacijui analizu (barem teoretski) nelimitirane količine podataka. Najpoznatija takvaparadigma je MapReduce.
2.1. Metode obrade ulaznih podataka
2.1.1. Serijska obrada
Podaci koji dolaze na ulaz sustava se skupljaju u spremnike, te se serijski obra-đuju, dio po dio (u komadima, engl. chunks), kako su sustav stiže. Može sereći da sustav smatra da u trenu obrade ima "pristup svim podacima". Takvajedna obrada se zove "prozor", koji je najčešće nekoliko minuta. Obrade su čestokompliciranije. Ne garantira se da će podatak koji je stigao na ulaz sustava utom trenu biti obrađen. U stručnoj terminologiji se to naziva batch processing.
2.1.2. Obrada tokova
Podaci kontinuirano dolaze na ulaz sustava i odmah se obrađuju, ne pretpostavljase da je neki podatak "zadnji u nizu". Obrade su generalno jednostavne, najčešćetransformacija ulaznih podataka, te se smatra da su obrađene u stvarnom vre-menu - vremenu dolaska podatka. Način rada se smatra asinkronim, jer se neobvezuje onome tko je podatak dostavio istovremeno dati i nekakav smisleni od-govor (osim eventualno da je podatak primljen). U stručnoj terminologiji se tonaziva stream processing.
2
2.1.3. MapReduce
MapReduce [10] je programski model (ujedno i implementacija koju je popularizi-rao Google) za obradu i stvaranje velike količine podataka u BigData paradigmi.Svodi se na dvije operacije - Map() koja vrši filtriranje i sortiranje (primjerice,sortiranje gradova po županijama i stvara red za svaku županiju) te Reduce()koja agregira rezultate (primjerice, broji gradove sa više od 50000 stanovnika).
Karakteristike takvog modela su maršaliranje, pokretanje zadataka na uda-ljenim računalima u paralelnom načinu rada, kontroliranje komunikacije izmeđusvih aktivnih u modelu, te redundancija koja omogućava otpornost na pogreške ikvarove. Maršaliranje je tehnika kojom se objekti iz memorije pretvaraju u oblikpogodan za prijenos - najčešće niz znakova ili bajtova, slično serijalizaciji.
3
3. Big Data
Big data je otvoreni problem današnjice s kojim se susreću sve veće kompanijekoje imaju potrebu za skladištenjem odnosno analizom veće količine podataka.Rapidnim rastom tehnologije i količine podataka koja je dostupna odnosno po-trebna, standardne strukture za skladištenje odnosno obradu podataka su postalenedovoljno brze.
Big data je pojam koji obuhvaća kolekciju skupova podataka toliko veliku ikompleksnu da ju je izrazito teško, ili čak nemoguće, obraditi standardnim pris-tupima za obradu podataka odnosno bazama podataka. Zahtjevi su višestruki:dohvat podataka, filtriranje (pročišćavanje), spremanje, pretraživanje, dijeljenje,prijenos, analiza, vizualizacija. Količina podataka koju obraćujemo raste stalnimrazvojem tehnologije i količinom podataka koju je moguće prikupiti, ali i samomanalizom podataka koje posjedujemo, jer i analizirane podatke treba nekako spre-miti odnosno koristiti na bilokoji način.
Prvi spomen pojma "big data" datira iz 1997. na IEEE konferenciji o vizu-alizaciji, referencirajući se na količinu podataka potrebnu za vizualizaciju kojaizlazi izvan ograničenja memorije i čvrstog diska računala, a rješava se poveća-njem resursa. 1997. Michael Lesk objavljuje tekst o količini podataka na svijetu,procjenjujući tu količinu na nekoliko tisuća petabajta, te konstatira da će kroznekoliko godina (do 2000.) tehnologija omogućiti pohranu svih podataka.
– Veljača 2001 – Doug Laney, analitičar Meta Groupa (današnji Gartner),objavljuje istraživanje nazvano "3D Data Management: Controlling DataVolume, Velocity, and Variety.". Desetljeće kasnije, sintagma "3Vs" postaječesto korištena za opisivanje rasta dimenzija big data, iako Doug Laney nekoristi sam pojam u svom istraživanju.
– Kasnije je, 2012, Gartner preoblikovao definiciju u "big data je velika ko-ličina, velika brzina i/ili velika varijabilnost informacijskih imovina kojezahtijevaju nove oblike procesiranje da bi se omogucilo kreiranje poboljša-nih odluka, otkrića i optimizacije procesa". Novi "V" (veracity) se također
4
veže uz big data.
– Veljača 2007 – Istraživači u IDC objavljuju rad o rastu količine digitalnihpodataka. Procijenili su da je 2006. na svijetu stvoreno 161 extrabajtpodataka, te da će do 2010. ta količina se ušestostručiti (odnosno, po-duplati svakih 18 mjeseci). Kasnije je istim istraživanjem otkriveno da jeprognoza bila pesimistična, do 2010. se količina podataka udesetostručila,a do 2012. udvadesetostručila.
– Veljača 2010 – Kenneth Cukier objavljuje u časopisu "The Economist"reportažu nazvanu "Data, data everywhere.", u kojem opisuje rapidan rastkoličine podataka koji se stvara i prikuplja, te ustanovljuje izraz "big data"za tu problematiku.
5
3.1. Apache Hadoop
Apache Hadoop [11] je jedan od najpoznatijih sustava za rješavanje Big Dataproblematike, razvijen od strane Apache Software Foundationa [1]. Hadoop jeopen-source, te ga stoga koriste mnoge poznate kompanije, od kojih je vjero-jatno najpoznatiji Facebook [4]; što mu je izvanredna preporuka. Hadoop koristiMapReduce tehniku, te je jedan od najpoznatijih predstavnike te vrste serijskeobrade podataka. Autori su mu Doug Cutting i Mike Cafarella.
Kratka povijest Hadoopa:
– 2003. Google je izdao članak o Google File Systemu
– 2004. Google je izdao članak o MapReduce tehnici
– 2006. U siječnju je krenuo razvoj Hadoopa
– 2006. U travnju je napravljena prva verzija (0.1.0)
– 2012. Prva finalna verzija Hadoopa (1.0)
3.1.1. Moduli Hadoopa
Sastoji se od 4 glavna modula:
– Hadoop Common – sadrži apstrakciju file systema i operativnog sustava("wrappere"), te osnovne elemente nužne za pokretanje Hadoopa
– Hadoop Distributed File System – Hadoopov portabilni, skalabilni i dis-tribuirani datotečni sustav
– Hadoop YARN – modul razvijen u 2.0 verziji Hadoopa koji vrši menadž-ment resursa grozda, što je u 1.0 radio MapReduce
– Hadoop MapReduce – modul za procesiranje velikog opsega podataka.
Svi principi rada Hadoopa podrazumijevaju kvarljivosti komponenti, te jeoporavak od greške (kvara) jedan od osnovnih preduvjeta svih operacija.
Mali grozd se sastoji od master grozda i nekoliko slave /worker grozdova.Master grozd se sastoji od JobTrackera, TaskTrackera, NameNode i DataNode.Slave grozd se sastoji samo od DataNode i TaskTrackera, iako je moguće čak ito razdjeliti pa imati slave grozdove koji su specifično designirani za DataNodeodnosno TaskTracker.
Veliki grozd ima dva NameNode servera – primarni i sekundarni. Također,odvojen je i JobTracker dio u zasebni server.
6
3.1.2. HDFS
Iako Hadoop podržava i druge datotečne sustave, primarno se oslanja na HDFS,budući da je specifično rađen za ovaj problem, te su neke funkcionalnosti poputsekundarnog NameNode servera onemogućene ukoliko se ne koristi baš HDFS.
HDFS je pisan u Javi, te koristi TCP/IP za međusobnu komunikaciju nakoji je nadograđen protokol specifičan za HDFS. Klijenti koriste RPC (engl. re-mote procedure call) kako bi međusobno komunicirali. Nije dio POSIX standarda(IEEE standad za portabilna sučelja operativnih sustava) jer mu cilj nije isti, ai zbog toga omogućuje neke dodatne mogućnosti poput appendanja podataka.HDFS distribuira podatke na nekoliko poslužitelja kako bi bili dostupniji, i kakobi operacije bile brže (zadaci se odvijaju na zasebnim poslužiteljima i onda senjihov rezultat spaja). Tipično, podaci se repliciraju u tri kopije – dvije u istojmreži i jedna na udaljenoj. Ideja je da su replicirane u istoj mreži radi ubrzanja,a na udaljenoj za slučaj da "glavna" mreža padne. Secondary NameNode nijedirektna zamjena Primary NameNodeu ukoliko on postane nedostupan (iako jeod verzije 2.0 i to moguće), nego on radi snapshot memorije dotičnog kako bi uslučaju greške/nedostupnosti mogao vratiti memoriju (i eventualno kroz analizulogova dovesti ju u zadnje stanje).
Velika prednost HDFSa je veza između JobTrackera i TaskTrackera, zbogkoje je moguće raspodijeliti pod-zadatke na grozdove koji drže različite dijelovepodataka koji se obrađuju i na taj način značajno ubrzati proces.
HDFS se može direktno mountati na nekim Unix sistemima, te kao virtualnidatotečni sustav u Linuxu, a može mu se pristupati i preko raznih drugih API-ja,komandnolinijskog sučelja, HTTPa i slično.
3.1.3. YARN
Kako se sustav razvijao, a primarno – primjenjivao, uviđeno je da osnovna podjelana MapReduce i HDFS nije dostatna, te da korisnicima treba omogućiti laganoproširenje sustava bez da troše velike količine vremena na modifikaciju sustava. Iztog razloga u Hadoop verziji 2.0 je MapReduce dio razdvojen u YARN modul kakobi se lako moglo nadograditi. Osim toga, YARN dio sada kontrolira i rasporedresursa na grozdu.
7
3.1.4. Generalni princip rada u Hadoopu
Klijentska aplikacija pošalje zahtjev kojeg prihvaća JobTracker. JobTracker tajzadatak šalje slobodnim TaskTrackerima u grozdu, uz tendenciju da zadatakbude fizički što bliži čvoru koji sadrži podatke koji se trebaju obraditi (ili baremmreži u kojoj se nalazi), a to saznanje mu omogućuje baš HDFS. TaskTrackerstvara proces u Java Virtualnom Stroju kako ne bi bilo posljedica u slučaju dase izvršavanje zadatka prekine u neočekivanom trenutku ili isti baci pogrešku.Ujedno si JobTracker i TaskTracker svakih par minuta šalju status report kakobi znali da je zadatak još uvijek u obradi i bitan. U novijim verzijama Hadoopa,moguće je čak i nastaviti zadatke koji su bili na pola dovršeni u trenu kada jesustav pao, što omogućuje neka vrsta checkpointa (spremanju međurezultata) uizvršavanju zadataka. Budući da se zadaci izvršavaju distribuirano, moguće jeda se na neki pod-rezultat čeka dugo čime se sav proces značajno uspori. Postojinačin rada u kojem se isti zadatak pokreće na više slave čvora, kako bi se smanjilamogućnost takve situacije. Naravno, to dodatno opterećuje sustav i svrhovito jesamo kada opterećenost nije problem.
Osnovni Hadoop sustav obrađuje zadatke FIFO principom – redosljed dola-ska zadataka dirigira i redoslijed izvršavanja, stariji zadaci se izvršavaju prvi. Unovijim verzijama Hadoopa scheduler je refactoran ("izvađen") kao zasebna kom-ponenta koju se može i zamijeniti ovisno o korisničkim željama, pa su tako nastalii alternativni scheduleri.
8
3.2. Apache Spark
Apache Spark [18] je programsko okruženje (framework) sa javno dostupnim ko-dom (open source) čija je glavna zadaća procesiranje tokova podataka. Razvijenje od strane Apache Software Foundationa [1], a iako naizgled sličan Hadoopu,njegov princip rada je nešto drukčiji i smatra ga se "trećom generacijom (3G)platformi za procesiranje tokova podataka.
Nazivna komparativna prednost u odnos na Hadoop jest tvrdnja da je 100puta brži u obradi podataka i 10 puta brži od dohvata podataka sa standardnog(rotacionog) diska.
Apache Spark pisan je u programskom jeziku Scala, a ima sučelja za progra-miranje u R, Javi, Scali i Pythonu.
Kratka povijest Apache Sparka:
– 2009. nastao je godine u UC Berkley R&D Lab (kasnije AMPLab)
– 2010. je promoviran u BSD licencu i kod je postao javan (open source)
– 2013. doniran u Apache Software Foundation gdje je odmah postao topprojekt
– 2014. izbačena prva verzija
3.2.1. Motivacija za razvoj
Nakon pojave Hadoopa, pokazalo se da obrada podataka u serijskom načinurada nije dovoljna, te je Spark taj koji je napravio iskorak i omogućio obradu(pseudo) tokova podataka. Naime, u trenu kada se razvijao Spark, bilo je nekolikoplatformi sa različitim mogućnostima odnosno ulogama:
– Apache Hadoop - obrada serije podataka
– Apache Storm / S4 - obrada tokova podataka
– Apache Impala / Apache Tez - interaktivna obrada podataka
– Neo4j / Apache Giraph - obrada grafova
Cilj Sparka je bio to ujediniti - pokazala se potreba za mašinerijom koja možeobrađivati podatke i serijski i kao tok podataka, da odgovara na upite u vremenuispod sekunde i radi obradu u memoriji (za razliku od npr. Hadoopa koji rezultatedostavlja na disk).
9
3.2.2. Moduli Sparka
3.2.2.1. Spark Core
Jezgra Apache Sparka, koji omogućava pokretanje svih Spark aplikacija. Toje generalizirana platforma koja omogućuje razvoj i izvršavanje velikog spektraaplikacija. Sadrži svojstva poput:
– Distribuirano raspačavanje (distribuciju) zadataka
– Zakazivanje (scheduling) zadataka kako bi bili pravovremeno izvršeni uzminimalno zagušenje resursa
– Osnovne I/O (input/output) funkcionalnosti poput čitanja sa diska ili pi-sanja na ekran.
– Nudi aplikacijsko sučelje u obliku RDD (Resilient Distributed Dataset)apstrakcije.
3.2.2.2. Resilient Distributed Dataset
Resilient Distributed Dataset odnosno RDD je osnovna čestica podatka u ApacheSparku koju se distribuira unutar sustava te se na njoj vrše transformacije. RDDje po definiciji nepromjenjiv (engl. immutable), što ima svojih prednosti i mana.Prednost je što je pozivaocu metoda jasnije što ta metoda može i smije raditi,jednostavnija je distribucija podataka u mreži grozdova, a i lakši je oporavak odgreške odnosno nastavak izračuna u slučaju greške; a mana je što su algoritmiza obradu takvih podataka ponekad kompliciraniji (i memorijski manje efikasni)kako bi se akomodiralo to nužno svojstvo. Budući da se RDD-ovi ne mogu mi-jenjati, alternativa je da se stvaraju novi u slučaju transformacije i agregacije.RDD može nastati na tri načina:
1. Paralelizirana korelacija - kreiraju se paralelne kolekcije pozivajući metodeu programu koji vrši transformaciju
2. Vanjski DataSetovi - npr. čitanje redaka iz tekstualne datoteke
3. Transformacija postojećih RDD-ova.
Na RDD su moguće dvije vrste operacija:
1. Transformacija - iz jednog RDD nastaje novi
2. Akcija - iz RDD se izvlači rezultat koji postaje rezultat programa, najčešćese isti zapiše u datoteku ili bazu podataka.
10
3.2.2.3. Spark SQL
Spark SQL je komponenta bazirana na Spark Core koja uvodi apstrakicju zvanuDataFrames (podatkovni okviri), čija je uloga podrška za strukturirane i polu-strukturirane podatke. Spark SQL predviđa DSL (domain-specific language) zamanipulaciju DataFrameovima u Scali, Javi i Pythonu. Kako samo ime nagovje-štava, Spark SQl omogućuje i podršku za SQL programski jezik i pristup takvimbazama podataka, iako, kako to vidimo, mu to nije isključiva uloga. Također,omogućava vezu prema Apache Hive platformi čime se dobiva već prije spomenutoubrzanje i do 100 puta na već postojećim rješenjima.
3.2.2.4. Spark Streaming
Spark Streaming je komponenta koja koristi mogućnosti brze raspodjele zadatakaiz Spark Corea kako bi omogućila analizu "tokova" podataka. Kombinira podatkeu male pakete na kojima radi RDD transformacije. Taj princip rada omogućujeda se koriste isti algoritmi koji su pisani za serijsku obradu podataka, pa je dizajnrješenja problema uvelike olakšan. Naravno, to dolazi uz cijenu - latencija kre-iranja malih paketa ponekad nije zanemariva, te to nije stvarni realno-vremenskipristup rješavanju tokova podataka. Spark Streaming kao ulazni tok može konzu-mirati razne platforme poput Apache Kftke, Flume, Twittera, ZeroMQ, Kinesisa,te i generičku TCP/IP priključnu točku (socket).
3.2.2.5. Spark MLlib
Spark MLlib odnosno "Spark Machine Learning Library" je distribuirana plat-forma napravljena na osnovici Spark Corea čija je uloga strojno učenje. ZbogSparkove distribuirane memorijske strukture, rezultati pokazuju da je i do 10puta brža od Apache Mahouta čija je implementacija zasnovana na pisanju podisku. Spark MLlib ima mnogo već implementiranih algoritama, poput:
– statistika sažetaka, testiranje hipoteza, korelacije, generiranje slučajnihbrojeva odnosno podataka
– klasifikacija i regresija
– kolaborativno filtriranje poput ALS (Alternating least squares)
– analiza na grozdu poput k-means (vrsta klasificiranja) i LDS (Latent Di-richlet Allocation)
– tehnike redukcije dimenzija
11
– ekstrahiranje značajki
– optimizacijski algoritmi poput stohastičkog spuštanja gradijenta
3.2.2.6. Spark GraphX
Spark GraphX je distribuirana platforma izgrađena na osnovi Spark Corea zaobradu grafova, te je bazirana na RDD. Zbog te odluke, grafovi su nepromjenjivi(engl. immutable), te je GraphX neprikladan za grafove koji se mijenjaju odnosnoažuriraju (primjerice, mreža prometnica sa podacima o gustoći prometa). Štoviše,iz tog razloga, GraphX je u potpunosti neprikladan kao izbor za bazu podatakakoja reprezentira graf. Spark GraphX ima dvije vrste priključnih metoda (engl.API - application programming interface):
– Pregel apstrakcija
– MapReduce
3.2.2.7. SparkR
SparkR je jednostavni front-end pristup Sparku iz programskog jezika R. Njeganajčešće koriste matematičari odnosno statističari koji vrše analizu podataka(data analysts), kako bi na distribuiranoj platformi vršili kompleksne izračune.
12
4. Apache Flink
Apache Flink [6] je programsko okruženje (framework) sa javno dostupnim ko-dom (open source) čija je glavna zadaća procesiranje tokova podataka. Razvijenje od strane Apache Software Foundationa [1], a iako naizgled sličan Hadoopu,njegov princip rada je nešto drukčiji. Naime, on ne koristi MapReduce, negovlastiti sustav raspodjele i izvršavanja zadataka. Svojevrstan je nasljednik Hado-opa i smatra ga se novom - četvrtom - generacijom rješenja za BigData. Glavnarazlika u odnosu na Hadoop i Spark je što mu je pristup ulaznom toku podatakadrukčiji - on predviđa obradu tokova za razliku od serijske obrade podataka čiji supredstavnici Hadoop i Spark (koji "tokove" rješava zapravo "kratkim serijama").Naravno, može raditi i u serijskom načinu rada.
Koliko mu je aktivan razvoj dovoljno govori činjenica da je zadnja verzijau trenutku početka pisanja ovog rada bila 1.2, a u završavanja je verzija 1.3proglašena stabilnom dok je 1.4 već u poodmakloj fazi i koristi se u produkcijiiako je još podložan ažuriranju.
Naravno, budući da su autori isti, pri izradi je posebna pozornost pridodanakompatibilnosti "unazad", pa je tako Apache Flink kompatibilan sa HDFS dato-tečnim sustavom kako bi mogao pisati i čitati podatke s njega, a ima i pristupYARN-u (Hadoopovom menadžeru resursa) za upravljanje resursima na grozdu.
4.1. Osnovne značajke
Apache Flink je najnovija generacija platformi za obradu BigData problematike.Glavna odlika mu je stvarna podrška za tokove podataka (ne stvara male na-kupine koje potom rješava kao da je riječ o serijskom modelu). Jezgra mu jeprotočna rutina koja omogućava distribuiranu obradu, otpornost na kvarove, ho-rizontalnu skalabilnost, te se odlikuje iznimnom brzinom, velikom propusnosti imalom latencijom koristeći podatkovno-paralelne modele i cjevovode transforma-cija. Podržava i serijsku obradu podataka, te ima i nativnu podršku za iterativne
13
algoritme.Jezici iz kojih se može nativno koristiti Apache Flink su Java, Scala, Python
i SQL, te se kod iz tih jezika automatski kompajlira i optimizira. Flink ne pružasvoj sustav za spremanje podataka (data storage, ekvivalent npr. HDFS u ApacheHadoopu), a omogućuje priključne točke (kako za ulaz, tako i za izlaz odnosnorezultate) za mnoge druge platforme - primjerice Amazon Kinesis, Apache Kafka,HDFS, Apache Cassandru, ElasticSearch.
Dakle, ukratko, glavne značajke su:
– Serijska obrada
– Stvarna realno-vremenska obrada tokova
– Interaktivna obrada
– Obrada grafova
– Iterativna obrada
– Obrada direktno u memoriji
Apache Flink je započet na tehničkom sveučilištu u Berlinu, 2009. godine, aslično kao i Spark, od 2014. pripada korporaciji Apache Software Foundation. Uprosincu iste godine postao je najbitnijim projektom i njegov razvoj je ubrzan.Ime mu dolazi od njemačkoga flink što znači spretan odnosno okretan. Počevšisa 2015, svake godine se održava Flink konferencija pod imenom Flink Forward[9].
14
4.2. Organizacija Flink platforme
Strukturu Apache Flinka možemo podijeliti u četiri sloja:
1. Storage - spremanje podataka
2. Deploy - okolina odnosno arhitektura u kojoj je rješenje postavljeno
3. Kernel / Runtime - jezgra sustava koja sve to pogoni
4. API / Library - najviša programska razina za razvoj aplikacija
Slika 4.1: Organizacija Flink platforme sa svim njenim dijelovima
15
4.2.1. Storage
Storage odnosno pohrana je sloj pod kojim se smatra raznovrsnot Flinka u po-gledu tehnologija iz kojih može "čitati" i "pisati" podatke. Jednakovrijedni sudatotečni sustavi, baze podataka i platforme za distribuiranje i konzumiranjetokova podataka. Neke od mogućnosti su:
– HDFS – Hadoop Distributed File System
– Local-FS – Local File System
– S3 – Simple Storage Service (autor: Amazon)
– HBase – NoSQL Database (Hadoop)
– MongoDB – NoSQL Database
– RBDBMs – Bilokoja relacijska baza
– Apache Kafka – Sustav za distribuiranu raspodjelu repova poruka
– RabbitMQ – Sustav za distribuiranu raspodjelu repova poruka
– Flume – Sustav za prikupljanje i agregiranje podataka
4.2.2. Deploy
Apache Flink moze biti raspoređen na više načina:
– lokalni Java Virtualni Stroj
– grozd strojeva, koje pak mogu biti raznih raspodjela resursa:
Samostalna instalacija (to je osnovna verzija)
YARN - dio instalacije Hadoopa
Apache Mesos
– Cloud - Apache ili Google Cloud servera.
4.2.3. Kernel (Runtime)
Jezgra sustava, koja se brine za distribuiranu obradu, oporavak i toleranciju gre-šaka i iznimki, pouzdanost, nativnu podršku za iterativnu obradu podataka islično.
16
4.2.4. API
Pristupna aplikacijska sučelja za Flink mogu biti tokovi podataka, tablice, Data-Set, Gelly i FlinkML.
– DataSet API - uglavnom se koristi za distribuirano procesiranje. Omogu-ćava korisniku da implementira operacije poput map, filter, join, group naDataSetu podataka. Zapravo, to je specijalan slučaj tokova podataka ukojem tok ipak ima konačan broj elemenata, tj. finalan je.
– DataStream API - API za tokove podataka. Obrađuje kontinuirani tokpodataka i omogućuje mapiranje, filtriranje, promjenu stanja, prozore,agregiranje, sumirane i slično. Može "konzumirati" podatke iz raznih "iz-vora" i rezultate pisati u razne ponoore engl. sinkove. Podržava i Javu iScalu.
– Tablice - Omogućuje korisniku da radi ad-hoc analizu na podacima koris-tivši jezik sličan SQL na konačnom setu podataka u obliku tablice. Možebiti korišten i u DataSet i DataStream APIju, te korisniku pojednostavljujekorištenje Flinka.
– Gelly - Platforma obrade grafova te omogućuje korisniku skup operacijai transformacija, a i već unaprijed implementiranih algoritama nad grafo-vima. Podrazumijeva već spomenutu nativnu podršku iterativne obradekoja je pogodna za ovakav tip podataka. Također postoji podrška i u Javii u Scali.
– FlinkML - Flinkova platforma za strojno učenje (engl. Machine Learning- ML). Pisana je u Scali. Kako i priliči, svesrdno iskorištava nativnu ite-rativnost obrade iz jezgre sustava, budući da su algorigmi stojnog učenjapo svojoj prirodi - iterativni.
4.3. Flinkove odlike
– Tokovi podataka - prirodna podrška za obradu tokova
– Visoke performanse i velika propusnost podataka uz minimalni overhead(dodatnu količinu podataka koja se šalje skupa sa pravim podacima kakobi se oni verificirali, otklonile podrške i slično)
– Niska latencija - izrazito brza koordinacija svih uključenih
17
– Podrška za obradu zakašnjelih podataka i podataka izvan redoslijeda uzprilagodljiv "prozor" tolerance
– Izrazita brzina obrade podataka - zato ga se i naziva 4G (četvrtom gene-racijom) platforme za obradu podataka
– Toleranca odnosno otpornost na pogreške i kvarove (hardvera, čvorova,softvera ili procesa) - kvarovi ne utječu na ostatak grozda.
– Kontrola nad memorijom, dijeljenje memorije i rad sa podacima direktnou memoriji što je izraziti skok u performansama nad sustavima koji to nerade
– Široka integracija - podržava velik broj tehnologija s kojima se može "spo-jiti" što ga čini prigodnim izborom za mnoge zadatke, a i za kombiniranjetehnologija u produkciji
– Optimizator - Flink dolazi sa optimizatorom koda koji pokuša povećatiperformanse već na prvom koraku - u implementaciji
– Skalabilan - glavni preduvjet za svaki moderni distribuirani sustav
– Bogat set operatora - velika količina unaprijed predviđenih operacija itransformacija nad podacima čini implementaciju bržom i mogućnost po-greške manjom, a nerjetko i sprečava suboptimalna rješenja u naizgledjednostavnim zadacima.
– Exactly-once semantika – takozvani "sveti gral" analitike nad tokovimapodataka. Podrazumijeva da se svaki događaj nađe točno jednom u obradi- izostanak ili duplikacija bi mogli biti pogubni za rad (npr. duplo plaćanjeračuna u financijskim arhitekturama).
– Fleksibilni prozori za obradu tokova - veličina prozora može biti dinamičkipromjenjiva ovisno o trenutnim rezultatima, gustoći toka i slično.
– Jednaka sintaksa i model za obradu tokova i serije podataka, te se bezdodatnih modifikacija može po volji mijenjati pristup radu.
– Jednostavan za korištenje i koristi minimalan set resursa za rad
18
4.4. Programiranje u Flink okruženju
Osnovni "građevni blok" u flinku su tokovi i transformacije. Svaki program sesastoji od 3 dijela:
1. Izvora (source) na koji dolaze ulazni podaci
2. Transformacija
3. Slivnika (sink) gdje se ispisuju ili spremaju podaci.
Slika 4.2: programski tok
19
Naravno, taj koncept je moguć i u paralelnom načinu rada, gdje se podaciparticioniraju ukoliko je to moguće na više računala (ili procesora, jezgara) itransformacije se obavljaju paralelno.
Slika 4.3: paralelni programski tok
4.4.1. DataSet
DataSet je osnovna jedinka u Flink programima koji vrše transformacije na skupupodataka. DataSet je kontejner koji čuva same podatke i informacije o njihovojparticiji, redosljedu i slično, te se na njemu mogu raditi transformacije. Interno,to je također tok (stream).
4.4.2. Transformacije na DataSetu
– Map - Mapiranje je operacija koja radi transformaciju svakog elementau kolekciji (jedan-na-jedan) u neki drugi element. Npr, pretvara svakielement u njegovu String reprezentaciju ili ga množi skalarom.
– FlatMap - metoda slična Map, samo što rezultat mapiranja jednog ele-menta može biti bilokoji broj elemenata (nije nužan uvjet jedan-na-jedan.Npr, razdvajanje niza znakova u riječi.
20
– MapPartition - transformira paralelnu particiju u samo jednom pozivu
– Filter - filtiranjra odnosno odbacivanje dijela kolekcije ovisno o nekomuvjetu
– Reduce - reduciranje je tehnika kojom se kolekcija reducira u samo jedanelement. tipično, to je suma elemenata, spojeni niz znakova ili rječnik(engl. dictionary, map) elemenata.
– GroupBy - grupiranje elemenata po nekom ključu
– ReduceGroup - redukcija na grupi (umjesto na jednom elementu i pret-hodnom rezultati redukcije)
– Aggregate - agregiranje - podržava sumiranje, traženje maksimalnog iliminimalnog elementa.
– Distinct - odbacivanje duplikata
– Join - spaja dva DataSeta u jedan po nekom zajedničkom ključu
– Cross - vrši kartezijev produkt dva DataSeta, tako da na svaki par eleme-nata (iz svakog DataSeta po jedan) izvrši transformaciju.
– CoGroup - grupira dva DataSeta i na zajedničkim elementima vrši tran-sformaciju
– Union - unija dva DataSeta koji moraju biti istog tipa
– Rebalance - rebalansira particije na jednolike djelove
– Hash-Partition - radi hash-particije od DataSeta
– Range-Partition - radi particije veličine nekih raspona
– Sort Partition - radi sortirane particije
– First-n - vraća prvih (ne nužno kronološki) N elemenata DataSeta
4.4.3. Table API
Osim tog, poznatog načina rada, popularan je i takozvani tablični pristup (TableSource). Kako je već spomenuto, Flink pokušava pokriti širok spektar primjena,pa se podaci mogu transformirati u oblik koji je sličan klasičnim bazama po-dataka - u tablice; te se na njemu rade upiti slični SQL-u. Također, postoje itransformacije koje pretvaraju DataStream i DataSet objekte u tablice i obrnuto.
21
4.4.4. Operacije na Tablicama
Osnovne operacije:
– Scan - evivalent ključnoj riječi "FROM" u SQL; vrši skeniranje registriranetablice
– Select - ekvivalent ključnoj riječi "SELECT" u SQL.
– As - (pre)imenovanje polja odnosno izračuna za daljnje korištenje
– Where/Filter - slično "WHERE" klauzuli u SQL; filtrira retke
Agregacije:
– GroupBy - grupira retke
– GroupBy Window - grupira retke u "prozore" određene veličine, pogodneza kasnije izračune
– Over - slično "OVER" u SQL; definira particioniranje i redosljed prije negose SELECT ili particioniranje dogode
– Distinct - odbacuje duplikate, kao i u SQL
Osim toga, naravno, postoje i sve verzije JOIN semantike (Inner, Outer, Left,Right, Full), a osim toga moguće je napraviti JOIN i sa funkcijom čiji je rezultattablica.
Operacije nad skupovima:
– Union - unija skupova, miče duplikate ako postoje
– UnionAll - ekvivalent "UNION ALL" u SQL; radi uniju ali ne miče dupli-kate
– Intersect - presjek skupova, svaki rezultat jednom
– IntersectAll - vraća presjek, svaki rezultat onoliko puta koliko se pojavljujeu operandima
– Minus - ekvivalent "EXCEPT" u SQL; vraća razliku skupova, izbacujeduplikate
– MinusAll - ekvivalent "EXCEPT ALL" u SQL; vraća razliku skupova, neizbacuje duplikate
Dodatno, postoje i operatori OrderBy koji sortira rezultantne retke, te Limitkoji odbacuje sve osim prvih N redaka (ekvivalent "LIMIT" odnosno "TOP" uSQL).
22
5. Scala
Scala (naziv je nastao spajanjem scalable i language) je funkcijski programski jezikzasnovan na Javi. Za razliku od većine funkcijskih jezika koji su interpreterskogtipa, on je strong static type (strong znači da su strukture strogo definirane i neimplicira se kojeg je tipa neka varijabla, nego je to znano, a static znači da je tipvarijable odnosno objekta poznat u prilikom kompajliranja a ne da se odgonetavaza vrijeme pokretanja) i kompajlira se u bytecode koji se onda izvršava na Javavirtualnom stroju.
Glavne odlike Scale su njena jednostavnost (to je jedna od glavnih zamjerkiJavi - količina koda za jednostavne operacije je povelika) te mogućnost da sekoristi Java kod unutar Scala koda. Na taj način je omogućeno korištenje svihkomponenti koje su napisane za Javu u jeziku koji je jednostavniji za korištenjei fleksibilniji.
Također, postoji i Scala interpreter koji omogućuje direktno pisanje komandiu konzolu, čime se Scala može koristiti i za kratke skripte, izračune i testiranja.
Kratka povijest Scale:
– 2001. - započeo je dizajn Scale u Lausanni, a autor je Martin Odersky.
– 2003. - prva interna verzija
– 2004. - prva javna verzija
Posebitosti Scala jezika koje nisu očite ili su specifične za jezik biti će opisaneu samoj implementaciji rješenja.
23
6. GeoJSON
GeoJSON je otvoreni format za kodiranje raznih jednostavnih tipova podataka oprostornim strukturama. Temelji se na JavaScript Object Notationu (JSON) štoje tekstualna reprezentacija objekata u jeziku JavaScript.
6.1. JavaScript Object Notation (JSON)
JavaScript Object Notation [12] je otvoreni standard za enkriptiranje objekata utekstualni oblik koji je čitljiv čovjeku (engl. human-readable). Definiran je u RPCStandadu 7159[7]. Prednost mu je, dakako, to što se podaci mogu pročitati i razu-mjeti, a nije ključna njihova kompresija niti optimalan prijenos između računala,niti spremanje. Izrazito je popularan te ga danas koristi gotovo svaka tehnolo-gija u računalnom svijetu, a njegova ekstenzija JSONP (JSON with Padding) jestandard za dohvaćanje podataka između različitih domena. Iako je potjekao izJavaScripta, nije vezan samo za taj jezik, nego je postao općeniti standard.
6.1.1. Tipovi podataka
JSON standard podržava šest tipova podataka, a kompleksni objekti nastajukombinacijom istih.
– Broj - može biti cjelobrojan, decimalan ili koristiti E-notaciju
– String - niz znakova
– Boolean - istina ili laž
– Array - niz vrijednosti koje mogu biti bilokojeg podržanog tipa (mogućerekurzivno ugnježđivanje)
– Object (Dictionary/Map) - kolekcija parova ključ/vrijednost bez definira-nog redosljeda. Ključ mora biti String, a vrijednost može biti bilo kojegpodržavanoga tipa (moguće rekurzivno ugnježđivanje)
24
– null - prazna vrijednost
6.1.2. Primjer JSON reprezentacije objekta
Ovaj zapis reprezentira objekt koji predstavlja neku osobu:
{
" firstName ": "John",
" lastName ": "Smith",
" isAlive ": true ,
"age": 25 ,
" address ": {
" streetAddress ": "21 2nd Street",
"city": "New York",
"state": "NY",
" postalCode ": "10021 -3100"
},
" phoneNumbers ": [
{
"type": "home",
"number": "212 555 -1234"
},
{
"type": "office",
"number": "646 555 -4567"
},
{
"type": "mobile",
"number": "123 456 -7890"
}
],
" children ": [],
"spouse": null
}
25
6.2. Povijest GeoJSONa
GeoJSON je krenuo s razvojem 2007, a 2008 je finalizirana specifikacija formata.Internet Engineering Task Force (IETF) je 2015. je u suradnji sa izvornim auto-rima standarda napravio Geographics JSON working group koja je u kolovozu2016. izdala GeoJSON kao standard RFC 7946[8], te je on pravi nasljednik ver-zije iz 2008. godine koja je do tad bila standard.
6.2.1. Tipovi podataka
GeoJSON pretpostavlja slijedeće vrste geometrije:– Point - Točka u prostoru
– LineString - Izlomljena linija u prostoru, reprezentirana nizom točaka kojeslijede jedna za drugom
– Polygon - Poligon u prostoru, reprezentiran nizom točaka takvima da jezadnja točka identična prvoj
Te njihove agregacije (varijacije gdje je jedan objekt reprezentiran sa više istihgeometrijskih struktura):
– MultiPoint - Niz točaka
– MultiLineString - Niz izlomljenih linija
– MultiPolygon - Niz poligonaNaposlijetku, kombinacija svega navedenoga se naziva GeometryCollection.Svaki prostorni objekt naziva se Feature, a kolekcija istih FeatureCollection.
Svaki Feature ima tri bitna svojstva:– type - tip objekta, gotovo uvijek Feature
– geometry - geometrija objekta
– properties - dodatna svojstva objekta, poput naziva, verzije, datuma kadaje objekt geokodiran, ime korisnika koji je unio objekt u bazu podataka,tipa objekta (npr. tip ceste), dodatnih napomena...
Geometrija objekta ima dva svojstva:– type - tip geometrije, iz već navedenog popisa
– coordinates - koordinate geometrije, kako je već opisano.Osim ovih svojstava, dodatna svojstva se definiraju upotrebom odnosno ba-
zom podataka koja sadrži GeoJSON objekte, a najčešće su to barem naziv i adresau slučaju fizičkih lokacija, odnosno tipovi puteva u slučaju ruta ili cesta.
26
6.2.2. Primjer GeoJSON strukture
Tipični primjer podataka iz OpenStreetMap baze podataka su lokacije dviju ka-mera za nadzor brzine u Hrvatskoj.
{
"type": " FeatureCollection ",
" features ": [
{
"type": " Feature ",
"id": "node/ 60051329 ",
" properties ": {
" timestamp ": "2015 -12 -12T11:58:11Z",
"user": "idelac",
" highway ": " speed_camera ",
},
" geometry ": {
"type": "Point",
" coordinates ": [16.5313391 , 43.5450405 ]
}
},
{
"type": " Feature ",
"id": "node/ 103684718 ",
" properties ": {
" timestamp ": "2017 -05 -25T19:22:38Z",
"user": " hbogner ",
" highway ": " speed_camera ",
" maxspeed ": "50",
},
" geometry ": {
"type": "Point",
" coordinates ": [17.2033565 , 43.4392981 ]
}
}
]
}
27
7. GeoTools
Geotools [13] je besplatni alat za razvoj rješenja koja se uklapaju u standarderazvijene od strane Open Geospatial Consortiuma (OGC) [3], i to paralelno srazvojem istih; što je nepobitna velika prednost u odnosu na ostale alate ovevrste. Pisan je u Javi, te su mu glavne značajke:
– sučelje za prostorne koncepte i podatkovne strukture
– Java Topology Suite topologija i geometrija
– atributi, prostorni i vremenski filteri po OGC specifikacijama
– tehnologije za dekodiranje prostornih i vremenskih objekata iz mnogihformata - npr. GML, GeoJSON
Budući da je GeoTools pisan u Javi, prirodno ga je bilo koristiti za ovaj rad,budući da je i Flink pisan u Javi odnosno Scali.
Kratka povijest GeoToolsa: GeoTools 1 je nastao 1996. na sveučilištu u Le-edsu (Engleska) kao projekt na završnim godinama studija. Ideja mu je bilarazviti alate za stvaranje klijenata koji bi mogli vizualizirati geografiju, te je ra-zvijen u Javi 1.1. Kako je to bio sveučilišni projekt, rađen je ad-hoc, bez podlogeu nekim standardima.
GeoTools 2 je nastao 2002, te je njegov razvoj krenuo ispočetka i pisala ga jedruga grupa stručnjaka. Naučivši na greškama, pisane su specifikacije i rađen jena temelju OCG specifikacija i standarda. U potpunosti je zamijenio GeoTools1, u toj mjeri da je s vremenom odbačen broj 2, i ovaj projekt - koji je i danasaktivan - se naziva GeoTools.
28
8. OpenStreetMaps
OpenStreetMaps (OSM) [14] je javna, besplatna i pristupačna baza geografskihpodataka o planeti Zemlji. To je kolaborativni projekt na kojem može sudjelovati(odnosno volontirati) bilo tko. Motivacija za nastanak je nepostojanje besplatnihmapi svijeta, a sami autori navode da je većina istih nastala iz državnih fondova(koje plaća narod), koje su se kasnije pak tim istom narodu naplaćivale. Također,već kupljena karta vrlo brzo postaje zastarjela, pa treba kupiti novu. Kupljenakarta se ne može promijeniti, ne smije se legalno kopirati, ne smije se koristitiu komercijalne svrhe... Postojanjem besplatne mape koju svi smiju koristiti,mijenjati i distribuirati se taj problem riješio sam od sebe.
Kratka povijest OpenStreetMapa:
– 2004. je Steve Coast započeo projekt kartiranjem Ujedinjenog Kraljevstva
– 2006. etabliran je OpenStreetMap Foundation koji podupire razvoj OpenS-treetMapa
– 2006.-2007. Yahoo, Google i Automotive Navigation Data potpomažurazvoj donirajući podatke, slike i sponzoriravši prvu konferenciju.
– 2012. Ironično, Google je pretvorivši Google Maps u komercijalni produktlansirao OpenStreetMaps kao vrlo primamljivu alternativu, te ju sad, iz-među ostalih, koriste Foursquare, Craigslist i Apple koji je zbog toga iprekinuo ugovor s Googleom i napravio svoju platformu za kartu (kombi-nacija OpenStreetMapa i TomToma).
29
8.1. Značajke OpenStreetMap objekata
Budući da će demonstracija rada biti u podacima dobivenima iz OpenStreetMapbaze podataka, valja navesti i najčešća polja u toj bazi. Naravno, jako je bitnoprimjetiti da su u bazi moguće (i prisutne) greške - budući da gotovo sav sadržajunose volonteri i korisnici, postoje inkonzistencije - osim logičkih, i u nazivlju,duplikaciji; te greške - od tiplelera do jednostavno posve neistinitih podataka.OpenStreetMap se potrudio napraviti detaljnu klasifikaciju i upute za izmjene nakarti, ali podataka ima puno previše da bi se sve moglo verificirati.
Svaki Feature se klasificira u jednu od ovih skupina:
8.1.1. Tipovi objekata
1. aerialway - prijevoz ljudi ili dobara zrakom, npr. uspinjača
2. aeroway - zračne luke i slično
3. amenity - javna mjesta za posjetitelje, npr. javni zahod, kafić ili škola
4. barrier - kontrolni objekti na cestama, npr. stupići ili rampa
5. boundary - granice, npr. grada ili nacionalnog parka
6. building - zgrade
7. craft - zgrade u kojima se stvaraju dobra, npr. pekara ili postolarska radnja
8. emergency - razne hitne ustanove, npr. ambulanta
9. geological - služe geološkom opisu lokacije
10. highway - ceste, svih tipova (ne samo brze ceste kako bi se moglo pomislitiiz naziva)
11. historic - povijesne lokacije
12. landuse - način na koji je zemlja iskorištena, npr. šuma ili industrijskopodručje
13. leisure - lokacije za sport i slobodno vrijeme, npr. parkovi ili stadioni
14. man_made - umjetne strukture koje je napravio čovjek, npr. obelisk
30
15. military - vojne lokacije
16. natural - fizičke karakteristike prirode
17. office - uredi
18. place - opis naselja, regija, država
19. power - lokacije generiranja i distribuiranja energije, npr. elektrane
20. public_transport - javni prijevoz
21. railway - željeznički promet
22. route - rute raznih namjena, npr. biciklističke
23. shop - trgovine
24. sport - opis sportova koji se igraju na lokacijama
25. tourism - turističke lokacije
26. waterway - vodeni putovi
31
8.1.2. Ostala svojstva
Uz to, svaki Feature sadrži podatke o njegovom nastanku:
– id - unikatni identifikator u OpenStreetMap bazi
– user - ime korisnika koji je unio podatak
– uid - unikatni identifikator korisnika koji je unio podatak
– changeset - unikatni identifikator promjene baze kada je unešen ovaj po-datak
– version - verzija unosa
– timestamp - vrijeme zadnje promjene
Osim ovih osnovnih oblika, svaka lokacija obogaćena je brojnim svojstvimapoput:
– ime
– cestovna adresa
– napomena
alternativno ime
ime bez dijakritika
ime koje treba koristiti prilikom sortiranja
– restrikcije
maksimalna brzina
zabrana prometa
zabrana smjera
Za opis Featurea se koristi izniman broj opisnih riječi, a cjelokupni popis možese naći na stranici OpenStreetMap [15].
32
9. Implementacija GeoJSONizvorišta podataka
Za implementaciju rješenja koristio se Flink 1.2, odnosno njegov službeni izvornikod za tu verziju. Flink je pisan u kombinaciji Jave i Scale, a zadatak je bioimplementirati rješenje u Scali. Flink koristi Apache Maven [2] kao rješenje zadistribuciju paketa odnosno knjižnica. Maven koristi XML datoteke za opis po-trebnih knjižnica, paketa i repozitorija na kojima se dotične nalaze. Kao prvikorak rješenja, bilo je potrebno dodati reference na GeoTools u datoteku pom.xmlu kojoj se nalaze sve te informacije.
Prvo je u poglavlje predviđeno za repozitorije (repositories) trebalo dodatirepozitorij koji sadrži GeoTools pakete:
<r e p o s i t o r i e s>. . .<r epo s i t o r y>
<id>osgeo</ id><name>Open Source Geospat ia l Foundation Repos i tory</name><ur l>ht tp : //download . osgeo . org /webdav/ g eo t oo l s /</ u r l>
</ r epo s i t o r y>. . .
</ r e p o s i t o r i e s>
Nadalje, jako je korisno postaviti i encoding za tekst u UTF-8 koji je danasjedini suvisao standard za tekst, te postaviti svojstvo geotools.version koji će svipaketi u pom.xml referencirati, kako bi svi GeoTools paketi bili iste verzije.
<prop e r t i e s><pro j e c t . bu i ld . sourceEncoding>UTF−8</ p ro j e c t . bu i ld .
↪→ sourceEncoding><geo t oo l s . version>15.1</ geo t oo l s . version>
</ p r op e r t i e s>
33
Potom je u poglavlje koje opisuje ovisnosti o paketima potrebno dodati Ge-oTools pakete. Usput, uputno je dodati i junit paket koji služi testiranju koda.
<dependenc ies>. . .<dependency>
<groupId>jun i t</groupId><a r t i f a c t I d>jun i t</ a r t i f a c t I d><version>4.11</version><scope>t e s t</ scope>
</dependency><dependency>
<groupId>org . g e o t oo l s</groupId><a r t i f a c t I d>gt−s h a p e f i l e</ a r t i f a c t I d><version>${ geo t oo l s . version}</version>
</dependency><dependency>
<groupId>org . g e o t oo l s</groupId><a r t i f a c t I d>gt−swing</ a r t i f a c t I d><version>${ geo t oo l s . version}</version>
</dependency><dependency>
<groupId>org . g e o t oo l s</groupId><a r t i f a c t I d>gt−main</ a r t i f a c t I d><version>${ geo t oo l s . version}</version>
</dependency><dependency>
<groupId>org . g e o t oo l s</groupId><a r t i f a c t I d>gt−geo j son</ a r t i f a c t I d><version>${ geo t oo l s . version}</version>
</dependency>
. . .</ dependenc ies>
34
9.1. Ideja rješenja
Kako je zadatak bio implementacija rješenja u Scali, nije bilo moguće zaći "dublje"odnosno "niže" u sam izvorni kod Flinka, budući da je jezgra istog pisana u Javi.Također, bitna je odluka radi li se izmjena u samom kodu Flinka ili se radidodatna funkcionalnost koja se može koristiti uz postojeću instalaciju Flinka.U ovom radu odlučeno je za ovu drugu varijantu, iz dva razloga. Prvi je samodabir jezika, odnosno zadatka, a drugi zato što ovako napisano rješenje, kojemožda neće biti optimalnih performansi, vrijedi kao samostalno rješenje, te ga semože do na eventualne sitne preinake koristiti u svim verzijama Flinka i na većkompajliranim varijantama sustava, neovisno o izvornom kodu. Drugim riječima,može ga se koristiti na bilokojoj postojećoj instalaciji Flinka, a ne samo u slučajuda se ponovo iskompajlira cijeli Flinkov kod.
9.2. Rasčlanjivanje GeoJSON formata
Slijedivši principe objektno orijentiranog programiranja kojeg promovira Java,kao rješenje se nameće da treba implementirati razred koji rasčlanjuje (engl.parse, kolokvijalno parsira) GeoJSON objekte i pretvara ih u objekte koji suiskoristivi za obradu i transformacije. GeoTools pruža dva razreda koji rade par-siranje - GeometryJSON i FeatureJSON, te tekstualni zapis pretvara u objekte poOGS standardu; koji se zovu jednako kao i njihovi GeoJSON ekvivalenti - Feature,FeatureCollection i slično. GeometryJSON radi transformaciju na općenitoj ge-ometriji, a FeatureJSON na kolekcijama Featurea, odnosno realnim geografskimobjektima. Prirodni je izbor odabrati FeatureJSON za ovaj zadatak. Parsiranjese radi tako da se stvori inačica objekta, te pozove metoda readFeatureCollection
var f j = new FeatureJSON ( )f j . r eadFeatu r eCo l l e c t i on ( data )
35
Takav poziv vraća objekt tipa FeatureCollection. No, iako se GeoJSON zapisne nalazi nužno sa shemom (engl. schemom) podataka unutar nje, to je vrlosmislen zahtjev. Naime, kako je GeoJSON zapis vrlo "slobodan", može se pojavitineko svojstvo koje se nije nalazilo u objektima prije. Primjerice, zapis poput
{
"type": " FeatureCollection ",
" features ": [
{
"type": " Feature ",
" properties ": { },
" geometry ": {
"type": "Point",
" coordinates ": [16.5313391 , 43.5450405 ]
}
},
{
"type": " Feature ",
"id": "node/ 103684718 ",
" properties ": { },
" geometry ": {
"type": "Point",
" coordinates ": [17.2033565 , 43.4392981 ]
}
}
]
}
može baciti grešku jer je parser iz prvog objekta etablirao svojstva, a novosvojstvo "id" se pojavilo u kasnijim objektima. Od toga se možemo braniti takoda parser prvo jednom prođe po zapisima i etablira sva svojstva, kako bi kasnijemogao parsirati sve elemente. To radimo metodom readFeatureCollectionSchema,a onda tu shemu postavimo parseru kao zadanu kako bi mogao bez grešaka parsi-rati sve objekte. Naravno, to dodatno usporava rad parsera, jer se kroz podatkeprolazi dvaput, te to treba koristiti isključivo kada imamo bojazni da bi se takvegreške mogle događati. Kao dizajn odluka jest je li to svojstvo opcionalno, te akonije, koja je predviđena zadana (engl. default) vrijednost. Autor ovog rada je
36
mišljenja kako bi programiranje trebalo osigurati točno rješenje, a omogućiti op-timizacije, te je postavio default takav da se uvijek ispita shema. Kod koji vršiparsiranje, dakle, izgleda ovako:
i f ( sa feReading )f j . setFeatureType ( f j . readFeatureCol lect ionSchema ( f i l eData ,
↪→ fa l se ) )f j . r eadFeatu r eCo l l e c t i on ( f i l eDa t a )
Pri čemu je safeReading postavljen na false.Iduća pogreška koja se može pojaviti u parsiranju jest nevaljani podatak. Pri-
mjerice, u OpenStreetMap podacima postoje linije koje su proglašene poligonima.Možemo se zabaviti razmišljanjem jesu li dvije točke degenerirani poligon ili nisu(u matematičkom kontekstu), ali u standardu to nije tako, te poligon mora imatibarem tri točke (odnosno četiri koordinate u notaciji budući da su prva i zadnjajednake). Također, odluka pada između odabira da se takva pogreška ignoriraili da se napravi iznimka koja će potencijalno zaustaviti program Odluka autorajest da se takva pogreška ispiše na ekran, ali i to je postavljena kao opcija kojuse može promijeniti.
37
Budući da se ispostavilo kako za rad u Flinku nije pogodan FeatureCollectionbudući da on nije POJO odnosno jednostavni Java objekt i ne mogu se serija-lizirati svi njegovi članovi, te u konačnoj inačici ova metoda ne vraća isti negoniz Featurea koji se kasnije obrađuju. Tu konverziju je mogao napraviti i krajnjikonzument, ali kako je ova metoda privatna u razredu koji vrši parsiranje, takonverzija je napravljena odmah. Kompletan kod metode koja radi parsiranjeizgleda ovako:
def parseFeatures ( ) : Array [ SimpleFeatureImpl ] = {f i l e L i s t . f latMap ( f i l ePa t h => {
val f i l eDa t a = s c a l a . i o . Source . f romFi l e ( f i l ePa t h ) . mkStringtry {
i f ( sa feReading )f j . setFeatureType ( f j . readFeatureCol lect ionSchema (
↪→ f i l eData , fa l se ) )f j . r eadFeatu r eCo l l e c t i on ( f i l eDa t a ) . toArray (Array [
↪→ SimpleFeatureImpl ] ( ) )}catch {
case e : Exception => {p r i n t l n ( " Error ␣ read ing ␣ f i l e : ␣%s " . format ( f i l ePa t h ) )i f ( i g n o r e I n v a l i dF i l e s )
Array [ SimpleFeatureImpl ] ( )else
throw e}
}})
}
U implementaciji se vidi primjena flatMap metode (pretvaranje niza ulaznihdatoteka u niz Featurea). Za svaku takvu datoteku, pročita se sadržaj datoteke,te ga se pokuša parsirati. U slučaju pogreške, ako je tako definirano varijablomignoreInvalidFiles, vraća se prazan niz Featurea, inače se ta pogreška proslijedi upozivajuću metodu.
Metoda vraća niz Featurea, u Scali je nepromjenjiv takav nazvan Array.Zgodno je primjetiti da Scala ne koristi ključnu riječ return, nego metoda im-plicitno uvijek vraća zadnji redak u metodi, koji god to bio.
Iako to nije nužno, kao pomoćna metoda razredu se može dodati i metoda koja
38
omogućuje da je ulazni parametar putanja ili do datoteke ili do mape (direktorija)sa GeoJSON datotekama. One tipično imaju ekstenziju .geojson.
private [ this ] val f i l e L i s t : Array [ F i l e ] = {val fp = new java . i o . F i l e ( path )i f ( fp . i sD i r e c t o r y )
fp . l i s t F i l e s . f i l t e r ( x => x . i s F i l e&& x . getName . toLowerCase . endsWith ( " . geo j son " ) )
elseArray [ F i l e ] ( fp )
}
Također, primjenom idiomatskog Scala principa, rješenje problema vraća nizdatoteka (koji je niz koji sadrži samo ulaznu datoteku, ako je to bila datoteka,odnosno sve datoteke u mapi ako je takav bio ulaz). Filtriranjem se postiže dase vrate samo GeoJSON datoteke.
Sada razred koji rješava problem parsiranja može imati definiciju:
class GeoJsonFeatureParser ( val path : Str ing ,val sa feReading : Boolean = true ,val i g n o r e I n v a l i dF i l e s : Boolean = true ) {
. . .}
Zgodno je primjetiti da je gorenavedeni fileList zapravo privatna članska vari-jabla ovog razreda, a njenu vrijednost smo mogli definirati programskim odsječ-kom, što je jedno zgodno svojstvo Scale. Ekvivalent tome bi bio konstruktor uJavi, ali tada bi taj konstruktor morali naslijediti svi ostali konstruktori. Alter-nativno, mogli bismo pisati incijalizacijsku metodu kojom pak kršimo principedvokoračne inicijalizacije (konstruktor i incijalizacijska funkcija). Kako je u pa-rametru razreda već naveden put do datoteke (odnosno datoteka), metoda zaparsiranje ne treba taj parametar. Valja primjetiti i pretpostavljene vrijednostiza safeReading i ignoreInvalidFiles.
9.3. Konverzija objekata
U prošlom poglavlju je već opisano zašto nije pogodno koristiti Feature i Featu-reCollection za rad sa DataSetom, te je trebalo napraviti jednostavnije objektekoji to mogu.
39
Za taj problem postoji mnogo pristupa, a u ovom rješenju implementirana sudva.
9.3.1. Mapa svojstava
Prvi pristup je stvoriti mapu (dictionary ili općenito podatkovnu strukturu saključevima i vrijednostima) sa svim odlikama iz Feature objekta. U tu svrhunapravljena je pomoćna metoda getPropertiesMap koja stvara mapu čiji su klju-čevi imena svojstava, a vrijednosti njihova vrijednost. Kako su sve vrijednosti uGeoJSON formatu zapisane kao niz znakova (string), tada i vrijednosti u mapimogu biti stringovi, štogod oni zapravo reprezentirali. Budući da su svojstvaionako jasna samo konzumentu, odnosno, samo konzument GeoJSON datotekazna koja je reprezentacija podataka, što svojstva stvarno znače i slično, ovo jeizrazito sigurna metoda.
Svojstva su u Feature objektu smještena u kolekciju kojoj se pristupa metodomgetValue, te po njoj možemo iterirati (prolaziti element po element) tako dapreuzmemo iterator te kolekcije i na njemu pozivamo metodu next. Svaku takvuvrijednost čitamo, dohvaćamo joj ime i vrijednost te to spremamo u mapu. UScali se kolekcije dijele na mutable (promjenjive) i immutable (nepromjenjive).Prirodno je stvoriti promjenjivu mapu te ju popunjavati dobivenim vrijednostima.Alternativno, može se i napraviti lista parova<ključ, vrijednost>, te se nju kasnijepretvoriti u mapu.
Iznimno, znamo da je svojstvo koje se zove "geometry" specijalnog tipa - onopredstavlja geometriju. To je jedino svojstvo kojem unaprijed znamo ime! Njuvalja specijalno tretirati, i nećemo ju spremati u ovu mapu. Zanimljivo je napo-menuti, da ako bismo geometriju spremali u ovu mapu tako da pozovemo toStringmetodu nad njom, dobili bismo takozvanu WKT (Well-Known text) reprezenta-ciju istog, koja je potpuno reverzibilna, te bismo mogli takve stringove kasnijeponovo konvertirati u geometriju. I taj pristup je validan, dakako. No, u našemslučaju, to nije potrebno; već je samo gubljenje performansi.
40
Slijedi kod koji rješava ovaj problem:
def getPropert iesMap ( f e a t u r e : SimpleFeatureImpl ) : Map[ Str ing ,↪→ St r ing ] = {
val r e t = c o l l e c t i o n . mutable .Map[ Str ing , S t r ing ] ( )val prop_it = f e a t u r e . getValue . i t e r a t o rwhile ( prop_it . hasNext ) {
val value = prop_it . nextval k = value . getNameval v = value . getValuei f ( k != null && v != null && k . toS t r i ng != " geometry " )
r e t += ( k . t oS t r i ng −> v . toS t r i ng )}r e t . toMap
}
Za lakše korištenje, imavši u vidu potrebe i općenito motivaciju ovog rada,napravljen je i jednostavan razred koji koristi baš ovaj pristup, imena Geome-tryWithProperties. Njega će se koristiti u finalnoj implementaciji metode za par-siranje.
class GeometryWithProperties ( val geometry : Geometry , val↪→ propMap : Map[ Str ing , S t r ing ] ) {
def this ( ) {this (null , s c a l a . c o l l e c t i o n . mutable .Map[ Str ing , S t r ing ] ( ) .
↪→ toMap)}def this ( f e a tu r e : SimpleFeatureImpl ) {
this ( FeatureHelpers . getGeometry ( f e a tu r e ) , FeatureHelpers .↪→ getPropert iesMap ( f e a t u r e ) )
}}
Razred ima dva konstruktora - prazni, te onaj u kojem se od Featurea popu-njavaju oba njegova člana - geometrija i mapa svojstava.
41
9.3.2. Popunjavanje jednostavnog razreda
Drugi pristup je popunjavanje jednostavnog razreda. Ideja je da konzument rje-šenja napravi razred po svom izboru, a parser automatski popuni njegova poljavrijednostima.
Tome također možemo pristupiti na nekoliko načina - koristivši shemu cilja-noga objekta, ili koristiti takozvani reflection. Reflection je tehnika kojom se urun-timeu (životnom djelu programa) ekstrahiraju svojstva objekata, imena poljai metoda. Kao rješenje, korištena je potonja metoda, primarno iz jednostavnostikorištenja, jer bi kreiranje sheme objekta konzumentu bio dodatni posao, beznekog benefita. Ovako je kod elegantniji.
Objekti u Scali za svako svoje polje imaju metode postavljanja i dohvaćanja(popularno: setter i getter). Pozivanjem metode iz paketa import scala.reflect.ClassTagpod nazivom getMethods na tipu objekta (tj. njegovom razredu) dobivamo svenjegove metode. Ukoliko se među njima nalazi metoda čiji je sufiks _$eq, to jemetoda za postavljanje vrijednosti. Sada je posao jasniji - za sva svojstva Featu-rea ćemo provjeriti postoji li metoda za postavljanje vrijednosti s istim imenomi istim tipom vrijednosti, te ukoliko postoji, postaviti ćemo tu vrijednost napročitanu iz svojstva Featurea.
val prop_it = f e a t u r e . getValue . i t e r a t o rval retMethods = r e t . g e tC la s s . getMethodswhile ( prop_it . hasNext ) {
val prop = prop_it . nextval key = prop . getNameval m = retMethods . f i nd (_. getName == key + "_$eq " )i f (m. nonEmpty) {
val value = prop . getValuei f (m. get . getParameterTypes . head . i s I n s t a n c e ( va lue ) )m. get . invoke ( ret , va lue )
}}
Tek ukoliko je nađena metoda s odgovarajućim imenom, evaluira se vrijed-nost val, a nakon toga se provjerava još i odgovara li tip parametra settera tipuvrijednosti - metodom isInstance. Kako je metoda getParameterTypes općenitai radi za sve metode, a ne samo za naš setter, ona može vratiti proizvoljan brojrezultata, odnosno tipova vrijednosti. Dakle, vraća kolekciju. Mi znamo da namtreba samo jedna, odnosno prva, te metodom head dohvaćamo prvu vrijednost
42
iz kolekcije. Možda je zgodno primjetiti da u programskom jeziku Scala postojiskraćeni način pisanja poziva funkcije - ukoliko funkcija ne prima argument, možese izostaviti pisanje zagrada. Tako da su, primjerice, ove dvije linije identične:
. . .i f (m. get ( ) . getParameterTypes ( ) . head ( ) . i s I n s t a n c e ( va lue ) ). . .
To je stil djelomično preuzet iz drugih jezika u pretvorbi Jave u Scalu (npr.C# - tamo se tako ponašaju Property) i treba ga biti svjestan.
Ovaj pristup je izvrstan, do na jednu zavrzlamu - svojstva se u GeoJSONobjektu smiju zvati raznorodno (npr. počinjati brojem, imati u nazivu crticu...),dok imena polja odnosno varijabli u razredima nije tako. Primjerice, "alt-name"koji se koristi u OpenStreetMap ne može biti valjano ime polja, ali "altName"može. U tu svrhu, pogodno je ovoj metodi proslijediti konverzijsku funkciju zaimena, ili alternativno mapu alternativnih imena. Slijedi implementacija potonjevarijacije, što je ujedno i finalna implementacija ove tehnike.
private [ this ] def f i l l G e n e r i cC l a s s [T] ( f e a tu r e :↪→ SimpleFeatureImpl , a l ternat iveNames : Map[ Str ing , S t r ing↪→ ] , r e t : T) {
val prop_it = f e a t u r e . getValue . i t e r a t o rval retMethods = r e t . g e tC la s s . getMethodswhile ( prop_it . hasNext ) {
val prop = prop_it . nextvar key = prop . getName . t oS t r i ngi f ( a l ternat iveNames != null )
key = al ternat iveNames . getOrElse ( key , key )val m = retMethods . f i nd (_. getName == key + "_$eq " )i f (m. nonEmpty) {
val value = prop . getValuei f (m. get . getParameterTypes . head . i s I n s t a n c e ( va lue ) )m. get . invoke ( ret , va lue )
}}
}
Povrh toga, dodan je i alternativni poziv ove metode, koji ne popunjava većstvoreni objekt, nego kreira novi i popuni ga. Kako bi to mogao, također sereflectionom kako bi kreirao novu instancu zadanog razreda čiji objekt treba
43
vratiti, te pozove gorenavedenu metodu nad novonastalom instancom.
private [ this ] def f i l l G e n e r i cC l a s s [T] ( f e a tu r e :↪→ SimpleFeatureImpl , a l ternat iveNames : Map[ Str ing , S t r ing↪→ ] ) ( implicit m: s c a l a . r e f l e c t . Mani fest [T] ) : T = {
val r e t = m. runt imeClass . newInstance . as InstanceOf [T]f i l l G e n e r i cC l a s s ( f ea ture , a lternat iveNames , r e t )r e t
}
Konačno, sve do sad navedene metode su bile privatne, a korisniku se prikazujusamo javne metode, koje dekoriraju navedeni pristup:
def parseAs [T : ClassTag ] ( a l ternat iveNames : Map[ Str ing ,↪→ St r ing ] = null ) ( implicit m: s c a l a . r e f l e c t . Mani fest [T] ) :↪→ Array [T] = {
parseFeatures ( ) .map( f i l l G e n e r i cC l a s s [T] (_, a l ternat iveNames )↪→ )
}
def parseGeometryWithProperies ( ) : Array [ GeometryWithProperties↪→ ] = {
parseFeatures ( ) .map(new GeometryWithProperties (_) )}
Napravljene su još i neke pomoćne metode, poput dumpGeometries koja udatoteku ispisuje kolekciju geometrijskih objekata kako bi se rezultate moglo ivizualizirati - primjerice MapBox alatom kojeg koristi i GitHub.
44
9.4. UML Dijagram
Ovaj model je izrazito jednostavan po pitanju nasljeđivanja razreda, jer je cijelafunkcionalnost sažeta u svega nekoliko razreda koji se mogu i neovisno koristiti.Ipak, slijedi UML dijagram.
Slika 9.1: UML dijagram rješenja
9.5. Primjeri korištenja
9.5.1. Podaci
Podatke na kojima bi se radilo testiranje rješenja trebalo je nabaviti primarnoiz OpenStreetMap izvora. Podatke iz OpenStreetMap moguće je pribaviti nanekoliko načina - primjerice, gledanjem na mapu i spremanjem zanimljivih dje-lova, ili preuzimanjem već kompletiranih podataka. Primjerice, moguće je (izarhive) preuzeti kartu cijele neke države ili regije. U ovom radu koristila se kartaHrvatske te karta Zagreba. Karte se tipično nalaze u .osm.pbf obliku koji je -naravno - OpenStreetMap specifikacija. Tu u pomoć priskaču aplikacije poputosmtogeojson [17], osmosis [16] te geojsplit [19].
– osmosis ekstrahira podatke iz kompresiranih .pbf datoteka u čitljive .osmdatoteke. Prilikom konverzije može se podesiti da konvertira samo nekedjelove mape, feature koji sadrže samo neka svojstva ili tako nešto. Unašem slučaju, budući da je konverzija mape Hrvatske par gigabajta, ko-nvertirali smo samo ceste.
– osmtogeojson pretvara datoteku iz .osm formata u GeoJSON format.
– geojsplit razdjeljuje GeoJSON datoteku u više manjih - što je pogodno zatestiranje aplikacija budući da učitavanje, primjerice, gigabajt podatakaiz GeoJSON datoteke može potrajati. Druga zanimljiva primjena je raz-dvajanje ulaznih podataka na više datoteka kako bi se one mogle učitavatiu više procesa, na više računala ili simulirati rad s paralelnim tokovimapodataka.
45
Osim tih podataka, korištena je i jednostavna mapa hrvatske pribavljena sastranice Matematičkog fakulteta Univerziteta iz Beograda [5].
9.5.2. Programi
Kao što je vidljivo iz poglavlja o Apache Flinku, tipični Flink program instanciraokruženje (Environment), stvara DataSet, na njemu vrši transformacije i potomsprema rezultat. Npr.:
val env = ExecutionEnvironment . getExecutionEnvironmentval parserHrvReg = new GeoJsonFeatureParser ( " in / hrv_reg iona l .
↪→ geo j son " )env . f r omCo l l e c t i on ( parserHrvReg . parseAs [ SimpleGeometry ] ( ) )
.map(x => ( x . geometry . getArea , x . name) )
. s o r tPa r t i t i o n (0 , Order .DESCENDING)
. p r i n t ( )
Konkretno, dotični parsira datoteku in/hrv_regional.geojson, te okruženju uobliku kolekcije predaje parsirane jednostavne objekte. Nad njima je napravljenatransformacija kojom se iz geometrije izračuna površina te se u daljnji procesobjekti mapiraju u Tupleove (razrede koji čuvaju n-torku potencijalno različitihtipova) - površina i ime. Idućom transformacijom se ti objekti sortiraju po pr-vom članu Tuplea (površini) i to silazno. Rezultat je autora ovog rada krajnjeiznenadio:
(0 .6840451223148776 , Zadarska )(0 .5818128168304382 , Sisacko−Moslavacka )(0 .46747903669161456 , Sp l i t sko−Dalmatinska )(0 .4272912855872551 , Licko−Senjska ). . .
Nakon kratkog razmišljanja se podsjetio da je raspored županija u Hrvat-skoj bio nešto drukčiji pred dvadesetak godina. Tada je, naime, Knin spadao uZadarsku županiju.
46
Sličan princip je kod upravljanja tablicama:
class SimplerGeometry (var g : Str ing , var ve r s i on : S t r ing ) {def this ( ) = {
this ( " " , " " )}
}
val p = new GeoJsonFeatureParser ( " in /ZagrebPartsSmal l / " )val env = ExecutionEnvironment . getExecutionEnvironmentval tEnv = TableEnvironment . getTableEnvironment ( env )
val hanzo = env . f r omCo l l e c t i on (p . parseAs [ SimpleGeometry ] ( ).map(x => new SimplerGeometry (x . geometry . toStr ing , x . v e r s i on
↪→ ) ) ). toTable ( tEnv )
hanzo. groupBy ( ’ v e r s i on ) . s e l e c t ( ’ v e r s i on . count ). toDataSet [ Long ]. p r i n t ( )
}
Objekti se parsiraju iz direktorija in/ZagrebPartsSmall/ kao SimpleGeometry,ali budući da tablice mogu raditi samo sa vrlo jednostavnim tipovima, geome-triju je ipak trebalo pretvoriti u string. Budući da je ovo samo demonstracija,napravljena je i pomoćna klasa koja čuva takav tip podataka pod nazivom Sim-plerGeometry.
Transformacija grupira retke tablice prema verziji, uzima njihove količine, teto vraća kao retke sa cjelobrojnim vrijednostima.
47
9.6. Rezultati
U samom kodu rješenja priloženi su primjeri korištenja, te evo njihovih rezul-tata. Biti će prikazan samo isječak koji vrši transformacije, te eventualno izvorpodataka.
Broj različitih geometrijskih oblika u ulaznim podacima za Zagreb:
env . f r omCo l l e c t i on ( parserZagreb . parseAs [ SimpleGeometry ] ( ) ). f i l t e r (_. geometry != null ).map(x => ( x . geometry . getGeometryType ( ) , 1) ). groupBy (0). sum(1). p r i n t ( )
Kao rezultat daje
( L ineStr ing ,45652)( Mult iL ineStr ing , 101 )( Polygon ,92516)( Point , 42016)
Iz čega je vidljivo da poligona ima otprilike koliko linija i točaka zajedno.Proučavanjem atributa iz OpenStreetMap baze, lako je pronaći one koji nas
zanimaju; pa tako možemo jednostavnim upitom saznati koliko ima reciklažnihpostaja za recikliranje papira:
val r e cyc l ingPaper = env . f r omCo l l e c t i on ( parserZagreb .↪→ parseGeometryWithProperies ( ) ). f i l t e r (_. propMap . getOrElse ( " r e c y c l i n g : paper " , null ) == " yes
↪→ " ).map(_. geometry ). c o l l e c t ( )
FeatureHelpers . dumpGeometries ( recyc l ingPaper , " out/↪→ r ecyc l ePaper . geo j son " )
48
Rezultat je vidljivo tužan:
Slika 9.2: Postaje za recikliranje papira u Zagrebu
Kad smo na istom tragu, može nas zanimati ne samo koliko, nego i kakvihlokacija za parkiranje bicikala ima u Zagrebu:
val bicyc leParkingKey = " b i cyc l e_park ing "env . f r omCo l l e c t i on ( parserZagreb . parseGeometryWithProperies ( ) )
. f i l t e r (_. propMap . i sDef inedAt ( bicyc leParkingKey ) )
.map(x => ( x . propMap . getOrElse ( bicycleParkingKey , " " ) , 1) )
. groupBy (0) . sum(1)
. p r i n t ( )
Prvo smo filtrirali sve objekte koji definiraju parkiranje za bicikl, te njih gru-pirali po vrijednosti baš tog atributa. To smo mapirali u Tuple kojem smo dali idodatnu vrijednost - 1. Grupirajući ih po toj vrijednosti i sumirajući drugi člandobivamo upravo traženi upit.
( bo l l a rd , 2 )( wall_hoops , 2 )( wal l_loops , 2 4 )( wal l_loops , _stands , 1 )( stands , 3 0 )
Iz čega vidimo da ih nažalost nema mnogo, a gotovo pola ih je nesigurnih(wall_loops omogućuju vezanje samo za kotač).
Prirodno se u tom smjeru nameće pitanje kakvih rekreacijskih objekata imamou Zagrebu.
49
val l e i su r eKey = " l e i s u r e "val l = env . f r omCo l l e c t i on ( parserZagreb .
↪→ parseGeometryWithProperies ( ) ). f i l t e r (_. propMap . i sDef inedAt ( l e i su r eKey ) ).map(x => ( x . propMap . getOrElse ( l e i sureKey , " " ) , x . geometry .
↪→ getArea , 1) ). groupBy (0) . aggregate (SUM, 1) . and (SUM, 2). c o l l e c t ( )
p r i n t l n ( "By␣ S i z e : " )l . sortBy(−_._2) . f o r each ( p r i n t l n )
p r i n t l n ( "By␣Count : " )l . sortBy(−_._3) . f o r each ( p r i n t l n )
To nas zanima sortirano i po broju takvih objekata, i po ukupnoj površiniistih, pa ćemo rezultate pokupiti (collect) i dvaput ispisati.
( pitch ,1 .675558361849767E−4 ,724)( playground ,2 .600044934498434E−5 ,372)( park ,3 .6727505953492655E−4 ,345)( garden ,2 .507934277249774E−4 ,287)( sports_centre ,1 .0190744260508547E−4 ,79). . .
Odnosno
( nature_reserve ,0 .014746860660154876 ,2)( park ,3 .6727505953492655E−4 ,345)( garden ,2 .507934277249774E−4 ,287)( pitch ,1 .675558361849767E−4 ,724)( sports_centre ,1 .0190744260508547E−4 ,79). . .
Vidimo da travnjaka, parkova, igrališta, vrtova i sportskih centara ima naj-više; a ujedno zauzimaju i najveću površinu, osim dva objekta koji su tipa na-ture_reserve. Jednostavnim upitom saznajemo koja su to dva:
val n_r = env . f r omCo l l e c t i on ( parserZagreb .↪→ parseGeometryWithProperties ). f i l t e r (_. propMap . getOrElse ( " l e i s u r e " , " " ) == "
↪→ nature_reserve " ).map(_. propMap . getOrElse ( "name" , " " ) ). p r i n t ( )
50
Te saznajemo da su to Jezera Savica i Park Prirode Medvednica.Kad smo već kod parkova, možda bismo željeli vidjeti na mapi gdje su sve
parkovi u Zagrebu:
val r e cyc l ingPaper = env . f r omCo l l e c t i on ( parserZagreb .↪→ parseGeometryWithProperies ( ) ). f i l t e r (_. propMap . getOrElse ( " l e i s u r e " , null ) == " park " ).map(_. geometry ). c o l l e c t ( )
FeatureHelpers . dumpGeometries ( recyc l ingPaper , " out/ parks .↪→ geo j son " )
Slika 9.3: Parkovi u Zagrebu
9.7. Moguća buduća poboljšanja rješenja
Kao što je već spomenuto u ideji rješenja, ovo rješenje nije optimalnih perfor-mansi. Kako bi se to postiglo, novija implementacija bi trebala biti u Java pro-gramskom jeziku, te bi cilj bio napraviti novi InputFormat koji implementira svemetode tog sučelja i u tom se slučaju može na "lijen" (engl. lazy) način pozi-vati kada DataStream zatraži više podataka. Također, takav InputFormat bi kaoargument sigurno trebao primati potencijalnu shemu GeoJSON formata kako birad bio brži. Takav parser bi bio izrazito pogodan za tokove podataka.
51
10. Zaključak
U ovom radu implementirana je podrška za geoprostorna izvorišta podataka usustavu Apache Flink. Kao izvorišta podataka koristio se GeoJSON oblik, aimplementacija je napravljena u programskom jeziku Scala. Sa strane korisnikaovog rješenja, izvorište podataka se može koristiti na nekoliko načina, dobivanjerezultata kao mapu svojstava, ili se pak može korisnikova tip podataka opleme-niti atributima prostornih objekata. Rezultati su demonstrirani u oba tipičnaprimjera primjene izvorišta u sustavu Apache Flink - kao standardno izvorištepodataka (DataSource), ali i kao izvorište tablica TableSource.
Također, rješenje je lako prilagoditi drugim upotrebama ili iskoristiti u nekomnovom projektu, budući da nije vezano za izvorni kod Apache Flinka, niti za nekuposebnu verziju istog. Drugim riječima, rješenje je samostalno.
Apache Flink je izrazito moćna platforma koja korisniku omogućuje vrlo jed-nostavan pristup alatima za distribuiranu, paralelnu obradu podataka, rad s to-kovima i serijama podataka. Nadogradnja mogućnošću da se kao podaci koristegeoprostorni objekti u GeoJSON obliku samo je jedan mali kotačić u ovom ve-likom stroju, ali GIS zajednici može biti od izuzetne koristi. Ova implementa-cija demonstrira mogućnost Scale kao programskog jezika, te koristivši moderneobjektno-orijentirane principe daje te mogućnosti. Prilikom implementacije po-sebna pažnja je posvećena prema konciznosti koda, minimalnosti i optimalnostiistog (minimalan broj konverzije podataka, minimalan broj kopiranja objekatapo memoriji i mijenjanja tipova - što su sve bitne stavke u performansama).
52
Lista Skraćenica
API Application Programming Interface, stranica 7
FIFO First In - First Out, stranica 8
HDFS Hadoop Distributed File System, stranica 7
IEEE Institute of Electrical and Electronics Engineers, stranica 4
JSON JavaScript Object Notation, stranica 24
POJO Plain Old Java Object, stranica 38
RDD Resilient Distributed Dataset, stranica 10
SQL Structured Query Language, stranica 11
YARN Yet Another Resource Negotiator, stranica 7
53
Literatura
[1] Apache. Apache Software Foundation, . URL https://www.apache.org/.
[2] Apache. Apache maven, . URL http://maven.apache.org.
[3] Open Geospatial Consortium. Open geospatial consortium. URL http:
//www.opengeospatial.org/.
[4] Facebook. Facebook. URL http://www.facebook.com.
[5] Matematički fakultet Univerziteta u Beogradu. URL http://www.matf.bg.
ac.rs/.
[6] Apache Flink. Apache Flink. URL https://flink.apache.org/.
[7] Internet Engineering Task Force. Json rfc standard, 3 2014. URL https:
//tools.ietf.org/html/rfc7159.
[8] Internet Engineering Task Force. Geojson rfc standard, 8 2016. URL https:
//tools.ietf.org/html/rfc7946.
[9] Flink Forward. Flink forward. URL http://flink-forward.org.
[10] Google. MapReduce. URL https://research.google.com/archive/
mapreduce.html.
[11] Apache Hadoop. Apache Hadoop. URL https://hadoop.apache.org/.
[12] JSON. Json. URL http://json.org/.
[13] OpenGeo; GeoSolutions; Refractions Research; LISAsoft. Geotools. URLhttp://www.geotools.org/.
[14] Open Street Map. Open street map, . URL https://www.openstreetmap.
org.
54
[15] Open Street Map. Open street map features, . URL http://wiki.
openstreetmap.org/wiki/Map_Features.
[16] OpenStreetMaps. osmosis. URL http://wiki.openstreetmap.org/wiki/
Osmosis.
[17] Martin Raifer. Osm to geojson. URL https://github.com/tyrasd/
osmtogeojson.
[18] Apache Spark. Apache Spark. URL https://spark.apache.org/.
[19] Brandon Wood. geojsplit. URL https://github.com/woodb/geojsplit.
55
Implementacija GeoJSON izvorišta podataka i tablica udistribuiranom sustavu za procesiranje tokova podataka
Sažetak
Oblikovana je i implementirana podrška za GeoJSON izvorište podataka usustavu Apache Flink. Temelji se na GeoTools programskom paketu, te je pisanau programkom jeziku Scala. Demonstrirana je podrška i za DataSource i Table-Source primjene, te je omogućena primjena za razne pristupe dohvata podataka,pritom izrazitu pozornost pridavši performansama rješenja.
Ključne riječi: Scala, Apache, Flink, GeoJSON
Implementation of GeoJSON Data and Table Sources in aDistributed Data Stream Processing System
Abstract
A solution for implementing GeoJSON format has been made for ApacheFlink. It is based on GeoTools packages and was made in Scala programminglanguage. It is followed by short demonstration of usage for both Data and TableSources, and provides interface for several result object types. Special attentionwas given to code simplicity and performance.
Keywords: Scala, Apache, Flink, GeoJSON