davorin vukelić
TRANSCRIPT
SVEUČILIŠTE U ZAGREBU
FAKULTET ORGANIZACIJE I INFORMATIKE
V A R A Ž D I N
Davorin Vukelić
Izrada ETL alata za transformaciju
podataka iz polustrukturiranih izvora
DIPLOMSKI RAD
Varaždin, 2014.
SVEUČILIŠTE U ZAGREBU
FAKULTET ORGANIZACIJE I INFORMATIKE
V A R A Ž D I N
Davorin Vukelić
Matični broj: 40574/11-R
Studij: Baze podataka i baze znanja
Izrada ETL alata za transformaciju
podataka iz polustrukturiranih izvora
DIPLOMSKI RAD
Mentor:
Izv. prof. dr. sc. Kornelije Rabuzin
Varaždin, rujan 2014.
I
Sadržaj
1. Uvod ................................................................................................... 1
2. Skladište podataka .............................................................................. 3
2.1. Poslovna inteligencija ....................................................................................... 3
2.2. Definicija skladišta podataka ............................................................................ 4
2.3. Model skladišta podataka ................................................................................. 5
2.4. Korištenje skladišta podataka ........................................................................... 7
2.5. Novi pristup skladištima podataka ................................................................... 7
3. Extract Transform Load ..................................................................... 9
3.1. Potreba .............................................................................................................. 9
3.2. ETL segmenti ................................................................................................. 10
3.2.1. Integracija podataka ................................................................................. 10
3.2.2. Kvaliteta podataka ................................................................................... 10
3.2.3. Repozitorij metapodataka ........................................................................ 11
3.2.4. Nadzor procesa ........................................................................................ 11
3.2.5. Međuspremanje ........................................................................................ 12
3.3. Prilagodba i čišćenje podataka ....................................................................... 14
3.4. Načini obrade .................................................................................................. 16
3.5. Extract Load Transform .................................................................................. 16
3.5.1. ELT princip .............................................................................................. 16
3.5.2. ELT realizacija ......................................................................................... 18
3.5.3. MapReduce programska paradigma ........................................................ 19
4. Big Data ............................................................................................ 23
4.1. Big Data definicija .......................................................................................... 23
II
4.2. Tehnologije. .................................................................................................... 26
4.3. Hadoop ............................................................................................................ 27
4.3.1. HDFS modul ............................................................................................ 29
4.3.2. mapReduce modul ................................................................................... 29
4.3.3. Hive .......................................................................................................... 30
4.3.4. HBase ....................................................................................................... 32
5. Polustrukturirani podaci ................................................................... 34
5.1. Definicja polustrukturiranih podataka ............................................................ 34
5.2. XML ............................................................................................................... 34
5.3. JavaScript Object Notation ............................................................................. 35
5.3.1. JSON elementi ......................................................................................... 36
5.3.1.1. Objekt ................................................................................................ 36
5.3.1.2. Polje .................................................................................................. 36
5.3.1.3. Primitivni tipovi ................................................................................ 36
5.4. JSON Schema ................................................................................................. 38
5.5. JSONiq upitni jezik ........................................................................................ 39
5.6. Usporedba XML i JSON-a ............................................................................. 41
6. Rad sa polustrukturiranim podatcima .............................................. 42
6.1. Izvor polustrukturiranih podataka .................................................................. 42
6.2. Predefinirana funkcija čitanja JSON zapisa u ETL alatu ............................... 44
6.2.1. Problem obrade JSON zapisa .................................................................. 44
6.2.2. Metapodatak ............................................................................................. 44
6.2.3. Izrada tokova ............................................................................................ 45
6.2.4. Dinamička izrada metapodataka .............................................................. 46
6.2.5. Mapiranje ................................................................................................. 47
6.3. Čitanje i obrada JSON zapisa izradom mapReduce modela .......................... 48
III
6.3.1. Problem obrade JSON zapisa .................................................................. 48
6.3.2. Metapodatak ............................................................................................. 48
6.3.3. Izrada tokova ............................................................................................ 48
6.3.4. Mapiranje ................................................................................................. 49
6.4. Prednosti i mane načina obrade ...................................................................... 49
7. ETL sustavi ....................................................................................... 51
7.1. Samostalna izrada sustava .............................................................................. 51
7.2. Izrađeni sustavi ............................................................................................... 54
7.2.1. Informatica Power Centar ........................................................................ 54
7.2.2. Pentaho Kettle .......................................................................................... 57
8. Prototip alata za obradu JSON-a ...................................................... 60
8.1. Karakteristke prototipa ................................................................................... 60
8.2. Korištene tehnologije ...................................................................................... 60
8.3. Izgled nositelja metapodataka JSON objekta ................................................. 61
8.4. Izrada metapodataka JSON objekta ................................................................ 62
8.5. Mapiranje ........................................................................................................ 65
8.6. Procesiranje .................................................................................................... 67
8.7. Primjer rada alata ............................................................................................ 69
8.7.1. Gilt – izvor podataka ................................................................................ 69
8.7.2. Struktura podataka ................................................................................... 69
8.7.3. Mapiranje ................................................................................................. 74
8.7.4. Izvršavanje ............................................................................................... 77
9. Zaključak .......................................................................................... 80
10. Literatura .......................................................................................... 82
IV
Popis slika
Slika 1 Poslovna inteligencija (Michalewicz ,Schmidt,Constantin,, 2007) ................... 3
Slika 2 Metode poslovne inteligencije (Negash, 2004) .................................................. 4
Slika 3 Model zvijezda (Rabuzin) .................................................................................. 6
Slika 4 Primjer jedne činjenične tablice u skladištu podataka (Ralph Kimball, 2004) .. 7
Slika 5 ETL sustav koji integrira heterogene izvore koristeći međuspremanje podataka
(Ralph Kimball, 2004) .................................................................................................. 13
Slika 6 Primjer međuspremanja podataka u ETL procesu (Informatica, 2014) ........... 14
Slika 7 Dijagram toka jednog ETL procesa (Oracle, 2013) ......................................... 15
Slika 8 Jedan od pristupa ELT procesu (Davenport, 2008, str. 9) ................................ 17
Slika 9 MapReduce model za brojanje riječi (MapReduce Introduction , 2012) ......... 20
Slika 10 Implementacija Join funkcije u MapReduce poslu (Holmes, 2012) .............. 21
Slika 11 Left outer join funkcija izvedena mapReduce modelom (Rathbone, 2013) .. 22
Slika 12 Izvori podataka unutar poduzeća (Jaya Singh, Ajay Rana, 2013).................. 23
Slika 13 Prikaz svih tehnologija koje se ubrajaju u Big Data tehnologije
(Turck,2012) ................................................................................................................. 26
Slika 14 Hive arhitektura (White, 2012) ...................................................................... 31
Slika 15 Pregled kako HBase pohranjuje datoteke na HDFS sustav (George, 2011) .. 32
Slika 16 Prikaz zaslona za Zobra live demo ................................................................. 40
Slika 17 Komunikacija klijenta na pretraživaču i pozadinskog sustava na serveru (Li,
2010) ............................................................................................................................. 42
Slika 18 Json čitač ........................................................................................................ 46
Slika 19 Izgled izlaza i ulaza JSON čitača ................................................................... 47
Slika 20 Arhitektura Informatica PowerCentra (Informatica, 2014) ............................ 54
Slika 21 Izgleda sučelja Informatica PowerCenter Workflow Manager-a .................. 55
Slika 22 Izgled Informatica PowerCenter Designer sučelja ........................................ 56
Slika 23 Izrađeno mapiranje u Informatica PowerCentru ............................................ 56
Slika 24 Pentaho Kettle Spoon sučelje i izrađena transformacija ................................ 58
Slika 25 Pentaho Kettle Spoon sučelje i izrađen posao ................................................ 58
Slika 26 JSON Input u Pentaho Kettle alatu ................................................................ 59
Slika 27 Mapiranje objekta izrađeno u prototipu alata za obradu JSON zapisa .......... 66
V
Slika 28 Sučelje za definiranje novog odredišta u objekt izrađeno u prototipu alata za
obradu JSON zapisa ..................................................................................................... 67
Slika 29 Sučelje za definiranje input datoteke, početak treniranja i procesiranje objekta
izrađeno u prototipu alata za obradu JSON zapisa ....................................................... 68
Slika 30 Izgled JSON objekta Product details ............................................................. 74
Slika 31 Povezivanje pojedinog primitivnog objekta i atributa u tablici product ........ 75
Slika 32 Povezivanje pojedinog primitivnog objekta i atributa u tablici content ......... 75
Slika 33 Povezivanje pojedinog primitivnog objekta od objekta Skus i atributa u tablici
Skus ............................................................................................................................... 76
Slika 34 Agregiranje objekta categories ....................................................................... 76
Slika 35 Tablica SKUS u relacijskoj bazi ..................................................................... 77
Slika 36 Tablica product u relacijskoj bazi .................................................................. 77
Slika 37 Tablica content u relacijskoj bazi ................................................................... 77
Slika 38 Tablica sale u relacijskoj bazi ........................................................................ 77
Slika 39 Podaci sadržani u tablici Skus ........................................................................ 78
Slika 40 Podaci u tablici product .................................................................................. 78
Slika 41 Sadržaj tablice sale ......................................................................................... 79
VI
Popis programskog koda
Programski kod 1 Primjer JSONiq upita za Zobra virtualni stroj ................................ 40
Programski kod 2 Maper izrađen u Java programskom jeziku (Alma, 2013) .............. 52
Programski kod 3 Reduktor izrađen u Java programskom jeziku ................................ 53
Programski kod 4 Prikaz ExtractObject modela objekta/metapodatak ........................ 62
Programski kod 5 Početak dijela koda kada funcija goThroughElement dolazi do
složenog objekta ........................................................................................................... 63
Programski kod 6 Dio koda funkcije goThroughElement gdje se izrađuje novi objekt
ExtractObject ili dodaje novi atribut u listu ................................................................. 63
Programski kod 7 Dio koda funkcije goThroughElement koja obrađuje primitivne
JSON objekte ................................................................................................................ 64
Programski kod 8 Dio koda goThroughElement funkcije koji obrađuje JSON polje .. 65
VII
Popis tabela
Tabela 1 Objekti koje sadrži Sale detail objekt ............................................................ 70
Tabela 2 Objekti koje sadrži Product detail objekt ...................................................... 71
Tabela 3 Objekti koje sadrži objekt Product content ................................................... 73
Tabela 4 Objekti koji su sadržanu u objektu SKU objects ........................................... 73
VIII
Popis zapisa
Zapis 1 Primjer jednostavnog XML dokumenta (W3C, 1999) .................................... 35
Zapis 2 Primjer JSON zapisa (ECMA) ....................................................................... 37
Zapis 3 Primjer JSON Scheme (Json Schema, 2013) ................................................... 38
Zapis 4 Ugniježđeni JSON Schema (F. Galiegue , Kris Zyp , Gary Court, 2013) ....... 39
Zapis 5 Primjer Sale detail objekta (GILT GROUPE, 2014) ....................................... 70
Zapis 6 Primjer Product detail objekta ........................................................................ 72
1
1. Uvod
Kako bi poduzeće što kvalitetnije poslovalo potreban je sustav poslovnog odlučivanja.
Sustav poslovnog odlučivanja sastoji se od analize prethodno generiranih podataka tijekom
poslovanja istog. Kako bi se mogle izrađivati što dublje i kvalitetnije analize, potreban je
sustav pohrane generiranih podataka. Takvi sustavi koji pohranjuju podatke generirane
tijekom uobičajenog poslovanja poduzeća nazivaju se bazama podataka. Baze podataka se
modeliraju tako da su u mogućnosti spremiti veliku količinu podataka te da upiti potrebni za
analizu poslovanja daju odgovor u realnom vremenu. Većina podataka koji ulaze u poduzeće
pohranjuje se kako bi se mogli analizirati. Trenutno, ono što se pohranjuje ulazni su i izlazni
podaci poduzeća. Kad se podaci iz postojećih baza sakupe i integriraju, nastaje skladište
podataka. Skladište podataka (engl. data warehouse) skup je podataka organizacije na kojem
se temelji sustav za donošenje poslovnih odluka. Skladište podataka namijenjeno je svima
koji u svom poslu obavljaju različite analitičke zadatke, kao što su poslovi praćenja i
izvještavanja. Ti poslovi obavljaju se postavljanjem usmjerenih upita i analizom dobivenih
rezultata.
Podaci koji nastaju unutar tvrtke mogu biti u raznim oblicima. Podatke najčešće
nalazimo u relacijskim bazama podataka. Za takav oblik pohrane kaže se da je strukturiran jer
postoji jasna i definirana struktura kako se podaci pohranjuju u sustav. Poduzeće poslovanjem
generira veliku količinu nestrukturiranih podataka. U nestrukturirane podatke ubraja se na
primjer e-mail pošta. Vrsta podataka s kojima se bavi ovaj rad su polustrukturirani zapisi
podataka. Ti podaci imaju krnju definiranu strukturu. Struktura postoji, ali se može mijenjati
od zapisa do zapisa. Takva vrsta zapisa također nema toliko bogat fond tipova podataka.
Najpopularniji primjeri polustrukturiranih zapisa podataka su zapisi u XML i JSON formatu.
Takva vrsta podataka najčešće nastaje prilikom međusobne komunikacije između dva
poduzeće B2B (ebg. business-to-business). Takva vrsta komunikacije počela se primjenjivati i
između klijenta i poduzeća B2C (eng. business-to-customer).
Za polustrukturirane podatke obrada nije tako jednostavna. Potrebno je razviti
drugačiji pristup obradi podataka iz polustrukturiranih izvora. XML je zapis koji je već duže
vrijeme najpopularniji zapis te vrste. Razvijeni su efektivni načini njegove obrade. JSON
(eng. JavaScript Object Notation) je noviji način zapisa podataka koji je razvijen kako bi se
2
nadišla ograničenja zapisivanja u XML obliku. Pošto je JSON specifičan po tome što ima
veliku slobodu kombiniranja osnovnih elemenata, potreban je drugačiji pristup nego kod
XML zapisa.
Ovaj rad bavit će se definiranjem pristupa obradi polustrukturiranih izvora podataka i
bazirat će se na pristupu izrade prototipa alata za obradu podataka zapisanih u JSON obliku.
Osvrnut će se na izgled, primjenu, izvore, obradu i integraciju dokumenata u JSON zapisu.
3
2. Skladište podataka
2.1. Poslovna inteligencija
Razvojem nekog poduzeća njegovo poslovanje postaje sve veće i kompleksnije.
Vodstvo poduzeća mora donositi dobre poslovne odluke kako bi poduzeće bilo održivo i
nastavilo rast. Donošenje poslovnih odluka temelji se na poslovnoj inteligenciji. Poslovna
inteligencija je skup metodologija, koncepata i sustava koji podatke poduzeća pretvaraju u
znanje poduzeća. Ona omogućuje prikupljanje, pristup i analiziranje podataka o poslovanju
tvrtke. To je potvrdio i Solomon Negash u svom radu : „Business intelligence systems
combine operational data with analytical tools to present complex and competitive
information to planners and decision makers.“ (Negash, 2004). Vodstvo poduzeća će na
temelju informacija i znanja donositi ispravne i pravovremene poslovne odluke. Slika 1
Poslovna inteligencija (Michalewicz ,Schmidt,Constantin,, 2007) prikazuje proces poslovne
inteligencije.
Slika 1 Poslovna inteligencija (Michalewicz ,Schmidt,Constantin,, 2007)
Poslovna inteligencija sastoji se od više dijelova. Metode poslovne inteligencije su
rudarenje podataka, skladištenje podataka, OLAP (eng. Online Analytical Processing),
priprema podataka, izrada izvještaja. Poslovna inteligencija razvila se od sustava za podršku
odlučivanja. Svaka metoda je zadužena za neki segment poslovne inteligencije. Pripremu
podataka odrađuje ETL (eng. Extract Transform Load) proces. Informacije se pohranjuju u
skladištu podataka. Iz skladišta podataka možemo vrlo brzo izrađivati izvještaje. Također, nad
4
informacijama podataka vrši se rudarenje podataka koje informacije pretvara u znanje. Slika 2
Metode poslovne inteligencije prikazuje odnos metoda poslovne inteligencije.
Slika 2 Metode poslovne inteligencije (Negash, 2004)
2.2. Definicija skladišta podataka
Opis skladišta podataka u svome radu iznijeli su Panos Vassiliadis, Christoph Quix,
Yannis Vassilioui i Matthias Jarke (Data warehouse process management, 2001):
„Data warehouses (DW) integrate data from multiple heterogeneous information
sources and transform them into a multidimensional representation for decision
support applications. A part from a complex architecture, involving data sources, the
data staging area, operational data stores, the global data warehouse, the client data
marts, etc., a data warehouse is also characterized by a complex lifecycle.“
U skladištu podataka nalaze se podaci iz cijeloga sustava poslovanja. Svaki izvor
podataka generira podatke koji se mogu pretvoriti u informaciju. Kombinacijom podataka iz
dva različita izvora možemo dobiti cjelovit izvještaj potreban za donošenje poslovne odluke.
5
Isto tako, kombinacija nekoliko izvora može donijeti neka nova znanja dobivena rudarenjem
podataka.
Sadržaj tako velike količine podataka mora biti brzo dostupan u realnom vremenu.
Zato su podaci u skladištu podataka modelirani tako da su redundantni. Svako poduzeće
izrađuje skladište podataka tako da je primjereno njegovom poslovanju. Redundantnost
podataka nije problem jer se predviđa da će skladište podataka biti velikoga obujma. Brzina
upita veoma je bitna. Podaci se u skladišta podataka ne umeću nego pune. Umetanje se
definira kao zapisivanje redak po redak u tablicu dok je punjenje podataka zapisivanje više
redaka odjednom, tj. unos veće količine odjednom. U svojoj knjizi Ralph Kimball iznosi
ciljeve koje mora zadovoljavati skladište podataka (Ralph Kimball, Margy Ross, 2002):
Skladište podataka mora učiniti informacije poduzeća lako dostupnim
Skladište podataka mora učiniti informacije poduzeća konzistentnim
Skladište podataka mora biti elastično i adaptivno
Skladište podataka mora biti sigurno kako bi zaštitilo informacije poduzeća
Skladište podataka mora biti temelj za unapređenje donošenja poslovnih
odluka
Poslovna zajednica mora prihvatiti skladište podataka kako bi ono bilo
uspješno implementirano
2.3. Model skladišta podataka
Modeli pohrane podataka u skladištima podataka definirani su od strane Ralpha
Kimballa i Billa Inmona. Njih dvojica imaju različite pristupe skladištenju podataka.
Bill Inmon zastupa tezu da podaci moraju biti pohranjeni kao dio poslovanja u trećoj
normalnoj formi. Njegov model za skladišta dobiven je analiziranjem poslovanja poduzeća.
Podaci su pohranjeni u izoliranim dijelovima gdje će se pokretati upiti koji neće ometati
uobičajene transakcije. Ralph Kimbal smatra da se podaci u skladištu podataka moraju
prilagoditi za što lakše iščitavanje.
Ralph Kimbal navodi dva modela koja se koriste kod skladištenja podataka: model
zvijezde ili model snježne pahulje. Model skladišta podataka određuje kako će podaci biti
pohranjeni u cilju da se upiti izvršavaju što brže. Zbog brojnih ograničenja sklopovlja,
6
potreban je dobar model nad kojim će se moći vršiti kompleksni upiti. Kad govorimo o
modelu zvijezde, razlikujemo dvije vrste tablica: dimenzijske tablice i činjenične tablice.
Model zvijezde možemo vidjeti na Slika 3 Model zvijezda (Rabuzin). Model pahulje je takav
da su dimenzijske tablice rastavljene kako ne bi dolazilo do redundancije podataka. Prilikom
normaliziranja modela zvijezde na model pahulje dobiva se na sažimanju obujma, ali se upiti
dulje izvršavaju jer je potrebno izvršiti spajanje tablica.
Dimenzijske tablice sadrže statične informacije vezane uz poduzeće. Punjenje tih
tablica se ne događa često. Dimenzijske tablice su opisi pojedinih segmenata poslovanja.
Dimenzijske tablice nastaju definiranjem poslovnih procesa unutar poduzeća. Mijenjanje
zapisa u dimenzijskim podacima radi se na određene načine tako da ostane pohranjen
povijesni segment. U maloprodajnim lancima je dimenzijska tablica proizvod. Ona sadrži sve
informacije o pojedinom proizvodu. Također, u gotovo svakom skladištu postoji dimenzijska
tablica datuma.
Slika 3 Model zvijezda (Rabuzin)
Činjenične tablice sadrže mjere poduzeća. U svakoj činjeničnoj tablici sadržane su
mjere kombinacija nekoliko dimenzija. Mjere su vrijednosti koje mogu biti izmjerene u
poslovanju poduzeća. U poslovanju maloprodajnih lanaca to mogu biti, na primjer prodane
količine proizvoda, vrijednosti prodane količine proizvoda itd. Činjenične tablice sastoje se od
vanjskih ključeva dimenzijskih tablica i mjera.
7
Slika 4 Primjer jedne činjenične tablice u skladištu podataka (Ralph Kimball, 2004)
Na Slika 4 Primjer jedne činjenične tablice u skladištu podataka (Ralph Kimball,
2004) prikazan je primjer činjenične tablice. Najčešća je primjena hibrida između
Kimballovog pristupa i Inmanovog pristupa. Modeli izgrađeni u skladištu podataka nisu isti
kao i u transakcijskim bazama. Potrebno je odvojiti potrebne podatke od nepotrebnih,
održavati kvalitetu podataka i izračunavati mjere. Zbog toga se uvodi cijeli proces između
transakcijskih baza i skladišta podataka koji omogućava izvršavanje svih navedenih zahtjeva.
2.4. Korištenje skladišta podataka
Skladište podataka jedan je od segmenata poslovne inteligencije. Kada u skladištu
postoje informacije, ono se koristi na razne načine. Postavljaju se upiti koje je nemoguće
postaviti u transakcijskim bazama zato što će zagušiti normalni rad baza podataka. Postavljaju
se upiti koji se ne mogu postaviti jer je dio podataka prije spremanja u skladište podataka bio
u nestrukturiranom ili polustrukturiranom obliku. Izrađuju se agregirani izvještaji po
vremenskoj dimenziji. Vrši se dinamička analiza velike količine podataka (eng. Online
Analytical Processing, OLAP). Izvršava se rudarenje podataka kojim se dobiva znanje.
2.5. Novi pristup skladištima podataka
Skladišta podataka nastala su zbog velikih ograničenja u sklopovlju. Sadašnja
tehnologija sklopovlja uvelike je nadišla ta ograničenja. Sada se pohranjuju samo bitni podaci
u posebno izrađenim modelima. Promijenio se i način poslovanja. Sve više sami korisnici
generiraju sadržaj. Znanje koje se dobiva došlo je do svojeg limita. Sadašnji zahtjevi za
znanjem se u nekim kompanijama svode na predviđanje emocija svojih korisnika. U
sustavima za upravljanje odnosima s kupcem (eng. Customer Relationship Management,
8
CRM) pokušavaju se dobiti nova znanja kako bi se klijentu što više ugodilo. Tako klasična
skladišta podataka koja su definirana od strane Ralpha Kimballa i Billa Inmona sve više ne
zadovoljavaju mogućnosti i kapacitete.
Skladišta podataka razvijaju se u smjeru pohranjivanja što je više moguće podataka i
to iz što više heterogenih izvora. Svi podaci koji se generiraju pokušavaju se zadržati i
pohraniti. Razvijaju se novi načini povezivanja podataka.
9
3. Extract Transform Load
3.1. Potreba
ETL je skraćenica za Extract-Transform-Load što bi u prijevodu značilo ekstrakcija,
transformacija i učitavanje. Extract-Transform-Load (ETL) sustav je temeljnog skladištenja
podataka. Dobro dizajniran ETL sustav dohvaća podatke iz izvorišnih sustava, uvodi
kvalitetne podatke, standarde konzistentnosti, prilagođava podatke tako da se odvojeni izvori
podataka mogu koristiti zajedno, i na kraju dostavlja iste u format spreman za prezentaciju
tako da korisnici mogu graditi aplikaciju i donositi odluke.
Potreba za kvalitetnim ETL sustavom je velika jer bez kvalitetnih podataka izrađeno
skladište podataka neće imati dobre rezultate. ETL nije vidljiv krajnjim korisnicima, ali on
tvori veliki dio projekta izrade skladišta podataka. Kvaliteta podataka u skladištu stvara
dodatnu vrijednost tih podataka. Funkcije ETL-a prema Ralph Kimballu (The Data
Warehouse ETL Toolkint, 2004) su:
Brisanje i ispravak pogrešnih podataka
Pružanje dokumentiranog mjerenje povjerljivosti podatka
Priprema tok transakcije za sigurno spremanje
Usklađuje podatke iz različitih izvora kako bi mogli biti korišteni zajedno
Strukturira podatke kako bi mogli biti korišteni zajedno
Potreban je kvalitetan zaseban sustav koji će omogućavati navedene funkcije. ETL se,
naravno, može izraditi unutar samog sustava za upravljanje relacijskim bazama podataka
(eng. Relational Database Management System). Svaki RDBMS ima mogućnost korištenja
procedura, okidača, pogleda i funkcija čijom se kombinacijom može izraditi ETL postupak.
Takva primjena ETL-a ubrzo dolazi do granice neiskoristivosti jer, iako je logika primjenjiva
za neki drugi izvor, potrebna je ponovna implementacija.
ETL proces zahtjeva svoj vlastiti sustav koji će se brinuti za neometano i nadzorno
odvijanje izrađenih procesa.
ETL se ne koristi samo za pohranu podataka u skladište podataka. On se također
koristi za obradu i čišćenje podataka u bilo koju svrhu. ETL se na primjer može koristiti za
10
pripremu podataka za njihovu analizu. Kod projekta analize podataka najveći dio vremena se
ne utroši na izradu modela analize, nego na obradu podataka potrebnih za analizu.
3.2. ETL segmenti
3.2.1. Integracija podataka
Integracija podataka je postupak ujedinjavanja podataka u jednu cjelinu, što znači i
omogućavanje pristupa u jednoj tehnologiji. Za dobivanje informacija sustav će koristiti samo
jednu tehnologiju jer se u prethodnim koracima oni integriraju. Integracija podataka je
postupak izrade logike za povezivanje izvora podataka i skladišta podataka. Izvor podataka
ima svoj model. Skladište podataka ima svoj model koji je prilagođen za izradu izvještaja.
Veličine koje se mjere mogu biti na primjer KPI-ajevi (eng. Key Performance Indicators) što
je količina izvršenog posla, odrađenih zadataka, itd. KPI-ajevi za pojedinog djelatnika su na
jedan način pohranjeni u transakcijskoj bazi tako da se na primjer nalaze u više tablica. Kada
se ta ista mjera pohranjuje u skladište, potrebna je logika koja će iz više tablica uzeti mjere te
pomoću zadane kalkulacije izračunati i sumirati vrijednost KPI za pojedinog djelatnika kroz
dan.
Ono što u teoriji nije toliko zastupljeno, ali ima učestalu primjenu, su tablice koje
sadrže agregirane podatke.Takve tablicesadrže agregirane podatke koji se nalaze u
činjeničnim tablicama po pojedinim atributima, najčešće po datumskoj dimenziji npr. m
mjesecu. Integracija podataka, to jest izrada logike prijenosa podataka u poslovnom okruženju
naziva se mapiranje.
3.2.2. Kvaliteta podataka
Kvaliteta podataka je veoma bitna. Što su podaci kvalitetniji, to će nam izvještaji i
zaključci koji se temelje na njima biti točniji. Profiliranje podataka je definiranje što uraditi sa
podacima koji nisu točni ili ne postoje. "Everyone starts out blaming IT. However, data is
created by people outside IT, and is used by people outside IT." (Olson, 2003, str. 10) . Jedan
od najvećih problema naveo je Jack E. Olson u svojoj knjizi o kvaliteti podataka. Informatika
je ta koja mora ispravljati ljudsku pogrešku.
11
ETL proces taj dio mora ispravljati u transformaciji. Transformacija se u ETL alatima
događa prilikom postupka mapiranja.
Kada govorimo o polustrukturiranim izvorima podataka u dijelu kvalitete podataka,
možemo napraviti podjelu prema sudionicima komunikacije ovisi je li to B2B komunikacija
ili C2B komunikacija.
U B2B primjerice, može se dogovoriti format poruke kao JSON oblik koji će jedno
poduzeće izrađivati, a drugo ga preuzimati i iščitavati potrebne podatke iz njega. JSON zapis
će se generirati iz sustava. U sustavu imamo kontrolirani upis podataka što znači da su oni
visoke kvalitete. Nad njima nije potrebno vršiti detaljni pregled kvalitete.
U B2C komunikaciji je na primjer provjera kvalitete daleko važnija. JSON poruku
generira web sustav u kojeg čovjek samostalno upisuje podatke. Količina pogrešnih podataka
koji dođu iz takvoga sustava bit će velika zbog namjerne ili nenamjerne ljudske pogreške
tijekom upisa. Možemo predvidjeti moguće greške te ih transformacijama ispraviti. Tu je
potrebna velika ljudska intervencija. To se može izraditi u svakom boljem ETL alatu.
3.2.3. Repozitorij metapodataka
Meta podaci su podaci o podacima. Definicija strukture podataka su metapodaci o
zapisanim podacima. Svaki RDBMS (Relation Database Managment System) ima pohranjene
metapodatke. Kvalitetan ETL sustav ima repozitorij u kojem se nalaze metapodaci za svaki
pojedini izvor podataka. Kada se jednom dohvate metapodaci o pojedinom izvoru, za potrebe
mapiranja oni ostaju u ETL sustavu. ETL sustav tipove podataka automatski prilagođava za
uporabu u izradi logike mapiranja. Neki tipovi podataka dobiveni iz metapodataka se ne
podudaraju sa daljnjim zahtjevima u izradi logike. Takvi podaci se ručno prilagođavaju te i
takve varijacije ostaju pohranjene u repozitoriju. Sljedeći put kad će biti potrebe za ponovnim
korištenjem istoga izvora, veza i metapodaci bit će prilagođeni za korištenje.
3.2.4. Nadzor procesa
ETL se odvija nezavisno za njegov rad koristi se više sustava: Izvorišni sustav iz
kojeg dobivamo podatke, odredišni sustav u kojem pohranjujemo podatke te središnji ETL
sustav koji nam omogućuje da imamo nadzor nad ETL procesom. Ralph Kimbal u svojoj
knjizi The Data Warehouse ELT Toolkit naglašava važnost nadzora ETL procesa. To znači od
12
automatskog izvršavanja procesa prema definiranom rasporedu do mogućnosti oporavka i
ponovnog pokretanja u slučaju da se prilikom procesa dogodi pogreška.
ETL proces mora imati dva načina pokretanja: ručno pokretanje i
automatskopokretanje. Definirati se može više ETL transformacija i mapiranja podataka koji
čine dio ETL procesa. Potrebno je odrediti redoslijed izvođenja procesa.
Kada se ETL izvrši, potrebna je statistika procesa. Potrebna je i potvrda je li proces
uspješno izvršen. Tijekom procesa moguće je da se jedan od redaka ne pohrani ili ako dođe do
pogreške. ETL alat treba imati mogućnost nastavka izvršavanja procesa do kraja iako je u
jednom trenutku došlo do greške nad jednim zapisom. Jedan zapis ne smije utjecati na
izvršavanje ostalih zapisa. Nakon izvedenog procesa, uspješno ili neuspješno, zbog
mogućnosti rješavanja grešaka, u procesu mora biti omogućen pristup zapisanim logovima.
Log mora zapisivati pojedine kritične točke procesa.
Bitan segment kontrole je mogućnost oporavka učitavanja. Ako sustav padne usred
određenog ETL procesa, njegovim ponovnim dizanjem mora biti moguće obrađivanje
podataka na dijelu gdje je obrada završila prije pada sustava. Također, postupak koji se
pokreće ispočetka ne smije duplicirati redove. Redovi koji su umetnuti u skladište podataka
moraju se obrisati kako ne bi došlo do dupliciranja podataka.
3.2.5. Međuspremanje
Međuspremanje je postupak pohrane parcijalno obrađenih podataka u toku ETL
procesa. ETL proces se međuspremanjem dijeli na nekoliko dijelova. Međuspremanje
podataka nije nužno, ali je ponekad neizbježno. Podaci se unutar procesa mogu pohranjivati u
radnu memoriju. Problem nastaje ako radna memorija nije dovoljna za obradu podataka. Slika
5 ETL sustav koji integrira heterogene izvore koristeći međuspremanje podataka (Ralph
Kimball, 2004) prikazuje način i povezanost međupohrane podataka unutar ETL procesa.
Međupohrana može biti izvršena unutar bilo kojeg sustava pohrane kao što je na slici.
Na primjer, može sagledati grupiranje prema određenom atributu, podaci se sumiraju
prilikom grupiranja u radnu memoriju ukoliko se sumira više atributa, ono može zauzimati
mnogo radne memorije. Prilikom pada sustava ili dolaska do greške svi podaci unutar radne
memorije neće ostati pohranjeni.
13
Slika 5 ETL sustav koji integrira heterogene izvore koristeći međuspremanje podataka (Ralph Kimball,
2004)
Slika 6 Primjer međuspremanja podataka u ETL procesu (Informatica, 2014) prikazuje
primjer međuspremanja podataka unutar ETL procesa. Izvor su podaci koji se dobivaju u
online transakciji podataka. U međuspremniku pohranjuju se podaci slični izvorišnima ali
prilagođeni za pohranu u skladište.
14
Slika 6 Primjer međuspremanja podataka u ETL procesu (Informatica, 2014)
3.3. Prilagodba i čišćenje podataka
Prilagodba i čišćenje podataka dio je koji se u nazivu odnosi na transformaciju.
Transformacija podataka je najvažniji dio u ETL procesu. Postupak ekstrakcije i učitavanja
podataka su sami po sebi potrebni. Transformacija podataka je dio gdje se podaci zapravo
mijenjaju. U transformaciji se definiraju pravila obrade podataka. Obrada podataka odnosi se
na prilagodbu podataka za model izrađenog skladišta podataka. Obrada podataka se također
odnosi na čišćenje podataka kako bi zadovoljili segment kvalitete podataka. Prilagodba
podataka znači također i stvaranje novih podataka koji se temelje na postojećim podacima i
zanemarivanje nebitnih postojećih podataka.
Čišćenje podataka odnosi se na kvalitetu podataka. ETL proces u segmentu kvalitete
podataka ima zadatak da bude brz, dokumentiran, da podaci budu potvrđeni i točni, da se
može osloniti na njih i na kraju da bude propustan. Kao što je već napomenuto, što je veća
kvaliteta podataka, to je ETL proces sporiji.
15
Slika 7 Dijagram toka jednog ETL procesa (Oracle, 2013)
Slika 7 Dijagram toka jednog ETL procesa (Oracle, 2013) prikazuje tok ETL procesa.
Točka u kojoj se događaju transformacije je Intra-ETL, odnosno dvije točke u kojima se može
ugraditi transformacija. Unutar samog procesa izrađuju se transformacije koje će potvrđivati
kvalitetu podataka. Obrada podataka ne vrši se samo iz jednoga izvora. U nekim ETL
procesima potrebno je kombinirati izvore podataka kako bih se izvršio proces.
16
3.4. Načini obrade
Postoje dva načina obrade podataka. Prvi način obrade je obrada toka podataka, a
drugi način obrade je obrada gomile podataka.
U toku podataka, podaci putuju iz izvorišta pa sve do odredišta u obliku jednoga retka.
Redci ulaze u proces transformacije jedan za drugim. Za svaku strukturu retka izrađuje
se transformacija koja će obrađivati retke iste strukture. U transformacijama se definira što se
događa sa pojedinim atributom unutar retka. Ukoliko se definira funkcija gdje se pojedini
atributi sumiraju, potreban je drugačiji pristup negoli nad obradom gomile podataka. Kako
redovi dolaze, potrebno je pohranjivati vrijednosti između dvaju redaka. Potrebna je varijabla
koja će biti upisana naknadno. Definiranjem funkcije grupiranja prema nekom atributu
potrebna je pohrana vrijednosti retka koji će biti upisan u odredište tek nakon što se agregiraju
svi redci koji se grupiraju u jedan redak. Za takav pristup pogodna je izrada modela
mapReduce paradigmom. MapReduce paradigma bit će opisana dalje u radu.
Kada se obrađuju podaci koji su u gomili, pristup je sasvim drugačiji. U ETL sustav se
dohvaćaju svi podaci. Nad svim podacima izvršavaju se jedna po jedna funkcija
transformacije. U toku podataka imamo definirane funkcije transformacije koje se izvršavaju
jedna za drugom nad svakim retkom. Zahtjevi u toku podataka su repetativni, ali kratki. U
obradi gomile podataka funkcije transformacije se jednokratne, ali traju duže. Što je funkcija
duža i kompleksnija, to je veća vjerojatnost dolaska do neuspjeha izvršavanja. Neuspjeh
izvršavanja funkcije nad jednim dijelom prolongira se nad čitavim setom podataka. Funkcije
grupiranja izvode se nad čitavim setom pa nije potrebno spremanje.
3.5. Extract Load Transform
3.5.1. ELT princip
Extract Load Transform (ELT) je drugačiji proces zbog toga što mijenja koncept
klasičnog (dosadašnjeg) pogleda na ETL proces. ETL proces je smješten između heterogenih
izvora podataka i centralnog mjesta pohrane, tj. skladišta podataka. Skladište podataka je u
sadašnjoj praksi smješteno uglavnom u relacijske baze podataka. Pojavom Big Data rješenja
skladište podataka se smješta u novonastale tehnologije.
17
Prvi dio procesa odnosi se na povlačenje podataka, njihovu integraciju i učitavanje
podataka dok je drugi dio procesa transformacija podataka. Postoje dva načina izvođenja
transformacija:
Transformiranje podataka prije prezentacije podataka
Transformiranje podataka nakon što se podaci nalaze u skladištu podataka
Slika 8 Jedan od pristupa ELT procesu (Davenport, 2008, str. 9) prikazuje drugi način
gdje se podaci transformiraju nakon što su u skladištu podataka.
Slika 8 Jedan od pristupa ELT procesu (Davenport, 2008, str. 9)
Podaci su u skladištu podataka kada završi postupak punjenja podataka u skladište.
Time se izolira riskantan dio procesa. Transformacija je riskantna jer u sebi sadrži razne
logike i zahtjeve obrade podataka. Obrada podataka može potrajati. Zahtjevi za obradu mogu
biti točka pada procesa jer su nerealni ili neizvedivi nad setom podataka koji se pune u
skladište. Integracija podataka i logika mapiranja podataka odnose se na prvi dio procesa. Tim
postupkom umjesto dvije moguće točke pada jednog procesa, postoji samo jedna točka pada
po svakom procesu (ExtractLoad i Transformation procesa). Identična izolacija problema
transformacije događa se i s pristupom da se proces transformacije odvija nakon upućenog
zahtjeva za prikazom podataka. U drugom pristupu postoji prednost što se transformacija
obavlja na manjem setu podataka, tj. onom koji je zahtijevan, ali transformacija se odvija više
puta na istim podacima ako se oni u više zahtijeva koriste.
Prednosti su umanjenje rizika, fleksibilnost i lakše projektiranje.
18
Slabosti ELT je u tome što se protivi normi izrade skladišta podataka te nedostupnost
alata za njegovu provedbu.
Nedostaci ETL-a su nefleksibilnost, više točaka rizika za neizvršavanje procesa,
oprema. Prednosti su dostupnost alata na tržištu, automatsko reduciranje podataka, prirodan
proces punjenja skladišta podataka, brzina razvoja procesa.
3.5.2. ELT realizacija
ELT je moguće realizirati i sa klasičnim ETL alatima. ETL alat ima mogućnost da
izvor podataka i odredište podataka bude isti baza podataka, tj. baza koja je i skladište
podataka. Unutar toga skladišta podataka podaci se zatim mijenjaju. Takav pristup protivi se,
kako je već navedeno, konceptima skladišta podataka prema definiciji Ralpha Kimbala.
Zaključak Robert J Davenporta u njegovom radu (ETL vs ELT A Subjective View,
2008, str. 11) je :
„As mentioned earlier, the fundamental nature of BI solutions is one of change and
evolution. Employing ETL will undoubtedly limit the ability to embrace this change. At
the very best unnecessary cost will be incurred, and at worse significant risk. With the
availability of tools that implement ELT extremely effectively, and the clear benefits
that can be gained from using ELT over ETL, it’s difficult to see why anyone
embarking upon the development of a BI solution would use any other approach“
Rad je objavljen 2008. godine. Koncept novog pristupa bio je dobar, ali nisu postojale
tehnologije koje to omogućavaju. Kako je naveo kroz tekst, nedostatak tehnologija i alata bila
je velika prepreka za realizaciju ELT-a.
Od tada se razvijaju tehnologije koje omogućuju takvu izvedbu ELT procesa, odnosno
ekstrakcije, pohrane i zatim obrade podataka. Tehnologija koja se razvila, a omogućuje takav
proces je programska paradigma koja ima konkretnu primjenu u Hadoop sustavu kao zasebni
modul. MapReduce moguće je koristiti kao poseban dio, ali se najbolje uklapa u Big Data
koncept čiji je sastavni dio. Napomenuto je u radu da se u skladište podataka pohranjivala
velika količina podataka koja je premještena iz transakcijskih baza radi lakše izrade upita te
integracije samih podataka. Podaci su dobiveni poslovanjem kompanije i razmjenom poruka
između poduzeća. U posljednje vrijeme promijenili su se trendovi poslovanja, izvorišta
19
nastajanja podataka, poslovanja poduzeća itd. Za uspješno donošenje poslovnih odluka sad
nije više samo bitno koristiti podatke koje korisnik generira tijekom poslovanja ili koji se
sami generiraju u poslovanju. Uspješne odluke koje će donijeti uspješnu promjenu strategije
poslovanja prema onom kakvu promjenu korisnici žele, dobivaju se iz podataka koju
generiraju korisnici sami sa svojim kretanjem. Potrebno je pratiti i pohranjivati sve
korisnikove radnje kako bi se što točnije pratili trendovi. Takve podatke teško je pohranjivati
u klasične relacijske baze podataka. Stoga je potrebna prilagodba načina pohrane podataka
kao i njihova obrada. Obrada podataka prilikom upita je moguća u mapReduce programskoj
paradigmi. Realizacija takvog upita mora biti izvršena u realnom vremenu.
3.5.3. MapReduce programska paradigma
MapReduce je najbolje rješenje za ELT proces, ono se ne mora vezati samo na njega.
MapReduce možemo iskoristiti i za ETL.
MapReduce je programska paradigma u kojoj se izrađuju modeli za procesiranje
podataka. U svojoj knjizi Donald Miner i Adam Shook (MapReduce Design Patterns, 2012,
str. 1) navode što je točno mapReduce:
„MapReduce is a computing paradigm for processing data that resides on hundreds of
computers, which has been popularized recently by Google, Hadoop, and many
others.“
MapReduce je dobar, kako je navedeno, za procesiranje velike količine podataka. Ono
nije ultimativno rješenje za procesiranje podataka unutar Hadoop sustava. Zavisno od
problema, ima svoje nedostatke i mane. Popularno je jer je prilagođeno za masovno
procesiranje podataka. Zbog svoje definicije mapReduce paradigma je veoma dobra za obradu
polustrukturiranih podataka kao što su poruke u JSON zapisu. Unutar modela mogu se uvesti
transformacije koje su potrebne da bi se proveo ETL proces.
MapReduce model sastoji se od dijela mapiranja i dijela reduciranja. Uvodi se još
jedan dio razvrstavanja između mapa dijela i redukt dijela koji nam omogućuje distribuiranost
takvoga modela. Način na koji mapReduce obrađuje podatke je redak po redak. Svaki redak
se sastoji od dva dijela. Prvi dio je ključ koji identificira redak. Drugi dio je vrijednost retka.
20
Ključ i vrijednost mogu se sastojati od više elemenata. Svaki element unutar ključa i
vrijednosti nositelj je neke informacije koju je unutar procesa moguće obrađivati.
U mapiranju se izrađuju parovi ključ-vrijednost. Iz izvora učitamo jedan redak koji će
se obrađivati. Redak može biti strukturiran ili polustrukturiran. Izrađuje se više mapera kako
bi proces mapiranja bio što brži. U svakom maperu se radi isti postupak.
Kada su ključ-vrijednost parovi definirani, oni se šalju drugom dijelu, tj. reduktoru.
Svaki reduktor prima jednako obrađene podatke sastavljene u retke koji imaju ključ-vrijednost
izgled. Pošto je sustav distribuiran te imamo više mapera i reduktora, izrađuje se dodatna
logika kako će rasporediti retke iz mapera u reduktor. To se definira ako se želi postići
jedinstvenost podataka. U dva različita mapera moguća je izrada dvaju redaka s istim ključem.
U reduktoru ta dva ista retka će se grupirati po ključu, a njihove vrijednosti će se agregirati.
Reduciranje neće biti pravilno izvedeno ako se u dva različita reduktora nađu redci s istim
ključem. Najčešće srednji sloj sortira retke po vrijednosti ključa. Tako sortiranom nizu
moguće je pronaći vrlo brzo podnizove koji imaju iste ključeve. Nizovi s istim ključevima se
definiraju kako bi išli u isti reduktor. Slika 9 MapReduce model za brojanje riječi
(MapReduce Introduction , 2012) prikazuje srednji sloj pod nazivom Shuffling.
Slika 9 MapReduce model za brojanje riječi (MapReduce Introduction , 2012)
U reduktoru će se izvršiti grupiranje svih redaka po ključu. Od nekoliko redaka dobit
će se jedan redak koji sadrži vrijednosti svih agregiranih redaka. Unutar reduktora definira se
kako će se vrijednosti agregirati. Vrijednosti mogu biti jednostavne ili složene. Svaka
21
vrijednost može imati nekoliko atributa po kojima će se ona agregirati zadanom funkcijom.
Na Slika 10 Implementacija Join funkcije u MapReduce poslu (Holmes, 2012) vidljive su i
dodatne funkcije koje se mogu uključiti u mapReduce posao kao što je spajanje dvaju izvora
podataka.
Slika 10 Implementacija Join funkcije u MapReduce poslu (Holmes, 2012)
Na Slika 11 Left outer join funkcija izvedena mapReduce modelom (Rathbone, 2013)
prikazan je način kako se spajaju redovi iz dvaju različitih izvora po nekom elementu pomoću
mapReduce paradigme. Povlačenjem paralele između mapReduce načina i relacijskog načina
element spajanja je u odnosima kao primarni ključ i vanjski ključ, svaki u svojoj tablici.
Svaki od redaka se mapira tako da se element spajanja postavi kao ključ retka. U
vrijednost retka stavljaju se ostale vrijednosti iz redaka. Reduktor ima sada podnizove u
kojima je isti ključ, a u vrijednostima se nalaze ne samo različite vrijednosti nego i različiti
atributi. Izlaz je napravljen tako da se redci s istim ključem međusobno kombiniraju
povezujući različite vrijednosti iz različitih atributa, svaki sa svakim.
22
Slika 11 Left outer join funkcija izvedena mapReduce modelom (Rathbone, 2013)
23
4. Big Data
4.1. Big Data definicija
U svojem istraživanju Jaya Singh i Ajay Rana (Exploring the Big Data Spectrum,
2013, str. 73) naveli su definiciju:
„Big Data is the data pouring globally from transactional systems like SCM, CRM,
ERP and non-transactional sources such as sensors, mobile communications, RFID,
Social Media, satellites, web logs, clickstreams and emails and is structured, semi-
structured or unstructured in schema.“
Kako je navedeno u definiciji, iza Big Data pojma kriju se svi podaci koje jedno
poduzeće ili ustanova posjeduje. Na Slika 12 Izvori podataka unutar poduzeća (Jaya Singh,
Ajay Rana, 2013) vidljivo je da je osim dosadašnjih izvora podataka pridodan i Big Data
izvor. Podaci koje pojedino poduzeće posjeduje tvore vrijednost poduzeća. Vrijednost tih
podataka je veća ako su oni iskoristivi. Podaci će biti iskoristivi s upotrebom pravilnih
tehnologija. Kompanije koje se temelje na servisima, kao na primjer Facebook skup podataka
koje generiraju njegovi korisnici, čine kompaniju još vrijednijom. Korisnikovo kretanje i
njegovi sadržaji se pohranjuju te se vrši analiza za omogućavanje pružanja što kvalitetnije i
personaliziranije usluge.
Slika 12 Izvori podataka unutar poduzeća (Jaya Singh, Ajay Rana, 2013)
24
Big Data pojam odnosi na veliku količinu podataka koja se generira korištenjem
proizvoda, usluga i aplikacija. Velike količine podataka se generiraju nesvjesno od strane
korisnika. Kako bi mogli upotrijebiti te podatke, potrebno ih je pohraniti i moći analizirati u
nekom realnom vremenu. Big Data analitika je jedan od glavnih imperativa u industrijama
orijentiranim prema kupcu kao što su telekomunikacijske kompanije, banke, osiguravajuća
društva, maloprodajni lanci. Big Data ima četiri karakteristike: velika količina podataka,
podaci dolaze velikom brzinom, podaci dolaze iz raznih izvora te podaci najčešće nisu
strukturirani.
Red veličina Big Data podataka opisao je Dr. Thomas Hill u svojem radu (The Big
Data Revolution And How to Extract Value from Big Data, 2012, str. 4):
Large data sets: 1,000 megabytes = 1 gigabyte to hundreds of gigabytes
Huge data sets: 1,000 gigabytes = 1 terabyte to multiple terabytes
Big Data: Multiple terabytes to hundreds of terabytes
Extremely Big Data: 1,000 to 10,000 terabytes = 1 to 10 petabytes
Big Data se smatra samo set podataka od nekoliko terabajta i više. Takav red veličine mogu
proizvoditi korisnici i korisnički uređaji. Za primjer može se uzeti očitavanje ADSL
(Asymmetric Digital Subscriber Line) modema u nekom sustavu. Neka se modem u sustavu
prijavi svakih 5 minuta i zabilježi svoje stanje u koje su uključeni mjerljivi atributi. Adsl
modema okvirno u Hrvatskoj može biti i do 3 milijuna. Dnevno se tako pohrani 864 000 000
zapisa. Svaki zapis neka sadrži 0,5 KB podataka što je 411 GB podataka dnevno. Kroz godinu
dana je to 144 TB podataka. U ovom primjeru se predstavio slučaj gdje se generirani podaci
mogu lako, brzo i jednostavno pohraniti. Nakon godine dana sa tim podacima može se
provesti analiza rada telekomunikacijskog sustava čitave Hrvatske s kojim se zatim može
poboljšati usluga i infrastruktura.
Big Data se temelji na pet dimenzija:
Volumen (eng. Volume) – red veličine je naveden iznad u radu.
Brzini (eng. Velocity) – brzina se odnosi na obradu velikih data setova. Obrada
mora biti ostvarena u realnom vremenu.
25
Raznolikost (eng. Variety) – podaci koji se pohranjuju i obrađuju moraju biti iz
različitih izvora: tradicionalnih relacijskih baza ili polustrukturiranih izvora kao što
je JSON oblik zapisa.
Vjerodostojnosti (eng. Veracity) - podaci moraju biti pouzdani kako bi se nad
njima mogle donijeti strateške odluke.
Kompleksnost (eng. Complexity) – cijeli sustav pohrane je kompleksan kako bi
bio efikasan.
26
4.2. Tehnologije.
Slika 13 Prikaz svih tehnologija koje se ubrajaju u Big Data tehnologije (Turck, 2012)
Pod pojmom Big Data tehnologije podrazumijevanju se svi alati koji služe obradi i
pohrani velikih količina podataka. Što se smatra velikom količinom podataka navedeno je
ranije u radu. Na Slika 13 Prikaz svih tehnologija koje se ubrajaju u Big Data tehnologije
(Turck, 2012) prikazane su sve tehnologije koje barem jednim svojim dijelom zadovoljavaju
standarde BigData. Kategorija infrastrukture sadrži sve tehnologije koje imaju mogućnost
pohrane velike količine podataka i dohvat tih istih podataka. Kategorija Analytics kategorija
sadrži tehnologije s kojima je moguće vršiti analizu velikih količina podataka. Application
27
kategorija sadrži aplikacije koje su stvorene kako bi krajnji korisnik mogao upravljati sa svim
Big Data procesima. Procesom može upravljati stručnjak koji je upoznat sa svakom
kategorijom tehnologija. Upravljanje postaje problem krajnjem korisniku kojem se želi
približiti mogućnost uporabe velikih podataka. Posebne kategorije tehnologije izdvojene su
tehnologije otvorenog koda. Izdvojene su jer su one najviše zaslužne za razvoj Big Data
rješenja. Te tehnologije su besplatne, ali njihova implementacija zahtijeva stručnjaka.
Kategorija Cross Infrastructure podrazumijeva one tehnologije koje se mogu iskoristiti za Big
Data rješenje, ali se po prirodi ne razvijaju u tom pravcu. Zadnja kategorija ima nabrojane
trenutne izvore velike količine podataka.
Potrebno je istražiti svaku potkategoriju kategorija navedenih na Slika 13 Prikaz svih
tehnologija koje se ubrajaju u Big Data tehnologije (Turck, 2012). Iz svake kategorije
potrebno je izdvojiti jednu tehnologiju koja će se koristiti u Big Data cjelovitom rješenju
kakva se nalaze u kategoriji Applications.
4.3. Hadoop
Hadoop je okruženje (eng. framework) otvorenog koda za distribuirano procesiranje i
pohranu velike količine podataka koristeći jednostavan programski model mapReduce o
kojem je bilo govora ranije. Hadoop se sastoji od više modula:
Hadoop Common – sadrži biblioteke potrebne za pristup Hadoop modulima
Hadoop Distributed File System (HDFS) – distribuirani datotečni sustav za
pohranu podataka. Ima veliku agregiranu propusnost kroz klastere.
Hadoop MapReduce – pokreće izrađeni model za procesiranje velike količine
podataka.
Hadoop sustav sastoji se od više čvorova. Hadoop sustav je izrađen kao distribuiran
sustav što znači da se nalazi na više servera. Čvorovi su serveri. Može se koristiti u lokalnom
načinu rada sa samo jednim serverom. Prilikom instalacije određuje se koji je glavni (eng.
master) server, tj. master čvor i uslužni (eng. slave) server, tj. slave čvor. Master čvorovi služe
za nadgledanje i kao kazalo dok slave čvorovi služe za obradu i pohranu podataka.
U svakom modulu čvorovi imaju drugačiju namjenu. U HDFS-u master čvorovi su
imenski (eng. name) čvorovi. Imenski čvorovi sadrže informacije gdje se nalaze pohranjeni
28
podaci. Zato možemo imati brz pristup pohranjenim podacima jer postoji katalog podataka,
ali taj server postaje usko grlo. Postoje metode kako se server nadograđuje i nadopunjuje sa
zamjenskim serverom kako ne bi bio točka padanja. Postoje i čvorovi koji prate izvršavanje
poslova kojima je također moguće pristupati iz Cloudera web sučelja ukoliko se koristi
Cloudera distribucija Hadoopa, a koji logiraju i prate pojedine aktivnosti koje se odvijaju na
Hadoop-u. Čvorevi koji prate izvršavanje zadataka ostvaruju rad unutar klastera. Svaki
pratitelj zadataka vrti se na nekom pomoćnom čvoru. Pratitelj poslova dijeli što će koji
pratitelj zadataka raditi i nad kojim podacima. Čvorevi koji prate posao prate gdje se nalaze
podaci s kojim čvor za izradu zadataka rade te ga tamo dodjeljuje za izvršavanje tako da bi on
mogao raditi direktno s podacima. U Hadoopu se podaci repliciraju. Blok podataka koji se
nalazi na jednom čvoru ima svoju repliku i na drugom čvoru.
Postoji niz alata koji su se razvili oko Hadoopa te koji koriste Hadoop za procesiranje
ili pohranu podataka. Za te alate kažemo da tvore Hadoop eko sutav. Svi ti alati ili koriste
HDFS modul za pohranu podataka ili koriste mapReduce modul za procesiranje pomoću
mepReduc paradigme.
Kada bismo sve te alate samostalno instalirali, došli bismo do problema
kompatibilnosti verzija pojedinih alata. Zato postoje distribucije Hadoop sustava koje u sebi
imaju povezane sve servise iz Hadoop eko sustava. Najpoznatije distribucije su Cloudera i
Hortonworks. Svi alati izrađeni oko Hadoopa su otvorenog koda kao i sam Hadoop. Cloudera
distribucija ima Cloudera upravitelj s web sučeljem koje omogućuje nadzor i konfiguraciju
Hadoopa.
Zookeper je servis za koordinaciju distribuiranih aplikacija. Omogućuje da se uvijek
vidi isto bez obzira kojem se serveru pristupa. Odgovoran je za sprječavanje pada sustava.
Ako se neki posao ne može izvršiti na nekom serveru, taj se posao prosljeđuje na drugi server.
Koordinira serverima koji su na njega spojeni kao klijenti. Zookeeper ima čvorove kojima
mogu pristupati svi servisi na kojima se nalaze podaci.
Hue je korisničko sučelje od Cloudera Hadoop sustava preko kojeg se može pristupati
raznim pokrenutim servisima na Hadoop-u, od Pig-a pa do mapReduce-a.
Poslovi koji su pokrenuti na Hadoop serveru mogu se pratiti preko Clouderinog web
sučelja ili preko Hue servisa. Hue servis se također pokreće na Hadoop serveru i služi za
29
pisanje Pig skripti, pretraživanje direktorija, nadzor poslova itd. Cloudera web sučelje sadrži
sve servise koji su pokrenuti na Hadoop serveru. S njime možemo izvršiti nadzor poslova
preko servisa pratitelja poslova. Pratitelj poslova prikazuje sve podatke vezane uz pokrenuti
proces, npr. koliko je bilo ulaznih redaka, izlaznih redaka, ulaznih i izlaznih bytova, duljina
obrade. Pratitelji poslova također zapisuje log zapise. Agregaciju procesira mapReduc modul.
Hadoop se instalira na operativnom sustavu Linux. Clauderina distribucija ima
preporuku instalacije sustava na CentOS distribuciji Linux operativnog sustava.
4.3.1. HDFS modul
U HDFS-u se jedna datoteka koja se pohranjuje lomi na više manjih blokova/datoteka
fiksne veličine. 64 MB je veličina jednoga bloka. Veličina bloka se može konfigurirati.
Blokovi podataka se stavljaju na različite čvorove, ali tako da se replike podataka nikad ne
nalaze na istome čvoru.
HDFS modul je izrađen tako da ima programski riješenu arhitekturu datoteka. HDFS
ima propusnost za veliku količinu podataka. S operativnog sustava mogu se stavljati i
povlačiti datoteke na Hadoop okruženje.
4.3.2. mapReduce modul
MapReduce modul služi za procesiranje velike količine podataka. MapReduce modul
prihvaća modele programirane u skriptama u raznim jezicima. MapReduce je programska
paradigma koja se može programirati u programskim jezicima Python, Ruby, C++, Java itd.
Preporuka je pisati ih u programskom jeziku Java jer je cijeli sustav izrađen u njemu.
MepReduce je model kojim se može procesirati velika količina podataka.
MapReduc posao se sastoji od dva dijela: mapiranja i reduciranja podataka. U
mapiranju se izrađuje ključ s kojim će kasnije biti pohranjen redak u, na primjer HBase bazu
podataka. U dijelu vrijednosti imamo jednu ili više varijabli prema kojima će se podaci
sumirati. U redukt dijelu radimo reduciranje podataka tako što grupiramo retke koji imaju isti
ključ, a vrijednosti tih redaka sumiramo ili radimo neku drugu agregacijsku funkciju.
MapReduce poslovi se na Hadoopu izvršavaju paralelno tako da je moguće zadati koliko će
biti potrebno paralelnih instanci za obradu, posebno za dio mapiranja i posebno za dio
reduciranja. Količinu paralela koja se definira potrebno je testirati - ako se stavi previše
30
paralela, moguće je da će se posao duže izvršavati. Potrebno je pronaći pravu mjeru koja ovisi
o količini podataka, atributa u retku, brzini procesora i količini RAM-a. Može se odrediti
koliko RAM-a će koristiti izrađeni mapReduc posao. Maping poslovi se izvršavaju lokalno te
se potom izrađeni redci spajaju u reduktorima. Svaki programirani maper i reduktor postavlja
se na određeni pratitelj zadataka koji zatim odrađuje zadani posao. Mehanizam koji povezuje
mapere i reduktore napravljen je sa funkcijom preslagivanja (eng. shuffle) tako da svi isti
ključevi završe na istom reduktoru. Također se povezni mehanizam može programirati tako
da koristi opciju sortiranja.
4.3.3. Hive
Hive je programsko okruženje (eng. framework) razvijen za skladištenje podataka koji
se temelji na Hadoop-u. Hive ima deklarativan jezik sličan SQL jeziku, HiveQL koji
organizira podatke u tablice. Hive pohranjuje podatke na HDFS sustav kao datoteke. Datoteke
su logički raspoređene. Logički model pohrane se izrađuje postupkom mapiranja podataka.
Budući da Hive ima jezik sličan SQL-u, naredbe za mapiranje podataka su slične kao za
izradu tablice u SQL jeziku. Kreiranjem tablice definira se datoteka koja će biti distribuirana
po čvorovima u definiranim blokovima. Datoteka će biti zapisana s atributima na način koji je
definiran mapiranjem. Mapiranje se odnosi na CREATE TABLE izjavu u kojoj se definiraju
tipovi podataka. Metapodaci za pojedinu tablicu se posebno pohranjuju. Tipovi podataka u
Hive tablicama su:
TINYINT (od -128 do 127)
SMALLINT (od -32,768 do 32,767)
INT (od -2,147,483,648 do 2,147,483,647)
BIGINT (od -9,223,372,036,854,775,808 do 9,223,372,036,854,775,807)
FLOAT (4-byte preciznost)
DOUBLE (8-byte preciznost)
DECIMAL
TIMESTAMP
DATE
STRING
VARCHAR
31
CHAR
BOOLEAN
BINARY
arrays: ARRAY<data_type>
maps: MAP<primitive_type, data_type>
structs: STRUCT<col_name : data_type ...>
union: UNIONTYPE<data_type, data_type, ...>
Za dohvat podataka izrađuju se HIVEQL upiti. HIVEQL upiti koji se upute prema
Hive-u zapravo izrađuju mapReduce poslove koji će se izvršiti na zahtijevanim podacima.
Izrada mapReduce poslova unutar Hive-a nije jednostavan zadatak. Izrada zadatka
može potrajati, ali zato kada realizacija mapReduc zadatka krene, ona traje dosta kratko. Zbog
izrade mapReduce posla cijeli upit je spor. Sporost je velika nad malim setom podataka. Što je
veći set podataka nad kojima se radi upit, to su performanse bolje. Zbog toga ograničenja
razvijen je servis Impala koji služi dohvatu podataka, pohranjenih kroz Hive sustav, koji ne
izrađuje mapReduce poslove. Imapala služi za brz dohvat podataka iz manje seta podataka.
Imapala koristi metapodatke tablica od Hive-a.
Slika 14 Hive arhitektura (White, 2012)
32
Na Slika 14 Hive arhitektura (White, 2012) prikazana je Hive arhitektura koja se
sastoji od dva dijela. Prvi dio su Hive klijenti koji se spajaju na Hive servis. Hive servis
pohranjuje na HDFS podatke dok u posebnoj bazi čuva metapodatke za izrađena mapiranja.
Podaci u Hive ne umeću se jedan po jedan. Uvijek se koristi učitavanje većeg seta
podataka kako bi se pojedini blok datoteke/tablice mogao distribuirati na sve nodove u
definiranoj veličini bloka.
4.3.4. HBase
HBase je nerelacijska (NoSQL) distribuirana baza podataka otvorenog koda napisana
u Java programskom jeziku. Ona se koristi kad je potrebno brzo nasumično pisanje i čitanje
velikih količina podataka. Ona ima veliku skalabilnost. Nastala je na razvoju Googlove
BigTable baze podataka. Također se koristi jer je iz skupa programa koji su u Hadoop obitelji
proizvoda. Kako bi baza bila što brža, koristi Hadoop sustav.
U HBase-u se definiraju tablice sa kolumnama. Red u tablici sadrži kolone (atribute)
koje su smještene u pojedine kolumne tzv. Column Family. Svaki atribut retka pripada
pojedinom ColumnFamily. Svaki red ima jedinstven ključ preko kojeg se pristupa tom retku.
Ključ ne pripada niti u jedan Column Family. Svaki Column Family nema definirane atribute.
Kako se umeću redci, tako se može pojaviti novi atribut koji se definira u određeni Column
Family, tako se dodaje novi atribut u tablicu.
33
Slika 15 Pregled kako HBase pohranjuje datoteke na HDFS sustav (George, 2011)
Slika 15 Pregled kako HBase pohranjuje datoteke na HDFS sustav (George, 2011)
prikazuje načina na koji HBase pohranjuje podatke. HBase je zasnovan na
HRegionServerima.
Pristup izradi ključa također je specifičan. Ključ retka se ne radi inkrementalno nego
on sadrži informacije preko kojih se može pojedinom retku brzo pristupati. Ključ mora biti
jedinstven u tablici jer se u protivnom redak prepiše s novim vrijednostima. Prilikom izrade
pojedinih tablica unutar baze, moguće je zadati broj vremenskih verzija retka koje može imati
pojedini Column Family. To daje i treću dimenziju svakoj tablici, onu povijesnu. Ključ se
sastoji od vrijednosti po kojima će se pretraživati taj redak. Ključ može imati više
komponenata koje se odvajaju samostalno definiranim separatorom. Primjerice komponenta
ključa može biti vrijeme izrade retka, atribut korisnika, atribut tip usluge, itd. Redci jedne
tablice sortiraju se prilikom umetanja u nj tako da su svi redovi pohranjeni i sortirani prema
ključu.
Čitanje i spremanje koje se vrši po ključu je jako brzo. Pretraživanje po ključu (tj. po
pojedinom segmentu ključa) isto tako je veoma brzo. Čitanja i pretraživanja koje se vrše po
filtraciji atributa su sporija.
34
HBase-u se pristupa sa Java API-jem ili preko HBase Managera (iako je pristup
moguć s bilo kojim programskim jezikom). HBase je namijenjen za čitanje odjednom velike
količine podataka te je napravljen tako da ima veliku brzinu čitanja. HBase koristi HDFS
sustav za pohranu zapisa što automatski znači da su podaci replicirani u sustavu.
35
5. Polustrukturirani podaci
5.1. Definicja polustrukturiranih podataka
Kada je riječ o komunikaciji između dvije kompanije, B2B se u cijelosti prebacuje na
komunikaciju internetom. Komunikacija pisanim putem odvija se samo još između kompanija
koje su male i nisu se dovoljno razvile kako bi ima bilo isplativo uvođenje kvalitetnog
informacijskog sustava. Komunikacija između kompanije i klijenta, B2C također ide u smjeru
komuniciranja internetom. B2C komunikacija je već dobrim dijelom prebačena na internet.
Strukturirani podaci su npr. oni koji se nalaze u bazama podataka. U bazama podataka
prvo se definira kako će se podaci rasporediti, što se definira tablicama i atributima te kakvi
će ti podaci u rasporedu biti, tj. tip podataka. Kod strukturiranih podataka prvo se zadaje
shema kako će oni biti zapisani pa se potom zapisuju. Definiraju se meta podaci, podaci o
podacima. Potrebno je strukturirati poruke i dokumente koji se razmjenjuju između dvije
kompanije, dva servisa, kompanije i klijenta, itd. Razvio se jezik koji označava dijelove
poruka tako da su te poruke postale definirane, tj. dobile su neku svoju strukturu. Struktura u
tim porukama ne mora biti definirana prije zapisivanja nego se ono određuje tijekom
zapisivanja. Takve poruke nazivaju se polustrukturiranima porukama, te one tvore
polustrukturirane podatke.
Razvijaju se jezici za obilježavanje dijelova teksta kako bih se olakšala komunikacija.
Jezik ima definirane dijelove. Svako obilježje na jedinstveni način definira dio teksta. Kada se
poruka prenosi od jednog subjekta do drugoga, u njoj već imamo sadržano više informacija:
meta podatke, podatke. Razvili su se i jezici kojima definiramo što sve mora jedna poruka
sadržavati. Postoje jezici koji obilježavaju dijelove poruka i jezici koji definiraju sadržaj
poruke.
5.2. XML
XML (eng. eXtensible Markup Language) je jezik za definiranje podataka. Lako ga
mogu iščitavati i ljudi i strojevi. „Each XML document has both a logical and a physical
structure.“ (Tim Bray, Jean Paoli,C. M. Sperberg-McQueen,Eve Male,François Yergeau,
2006). Svaki XML dokument, kako su naveli autori W3C preporuke, mora biti dobro
36
strukturiran. Postoji dosta ključnih riječi i elemenata XML s kojima se dijelovi XML
dokumenta mogu označiti. Zbog toga je XML postao popularan jer pruža dobru potporu za
strukturiranje. Međutim, ta prednost s vremenom postaje mana jer dokumenti zbog toga
postaju glomazni i veliki. XML je definiran prema standardu za Standard Generalized Markup
Language (SGML) .
XML dokument se sastoji od elemenata, te se izrađuje se kao stablo. Svaki element se
sastoji od oznake (eng. tag) i vrijednosti. Postoji početna i završna oznaka. Tag se piše unutar
< i >, vrijednost se piše između početnog i završnog taga. Završni tag sadrži znak /.
Kako bi mogli koristit XML dokumente potrebno je izraditi XML procesore koji će
moći iščitavati XML dokumente.
Zapis 1 Primjer jednostavnog XML dokumenta (W3C, 1999)
XML je već dugo prisutan i postao je "de facto" standard. Novi trendovi teže k
automatizaciji te dolazi do vidnih ograničenja XML-a, npr. potrebno je izraditi zasebni servis
koji će XML poruke iščitavati. Za razliku od njega JSON je vrlo lako deserijalizirati u objekt
unutar objektno orijentiranog programskog jezika.
5.3. JavaScript Object Notation
JavaScript Object Notation, skraćenica JSON, neovisan je tekstualni format zapisa.
„JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data
interchange format. It was derived from the ECMAScript Programming Language Standard.“
(T. Bray, 2013, str. 1) To je definicija prema službenom dokumentu Internet Engineering
Task Force-u. JSON-ova velika prednost je u tome što ima jako malo pravila za izradu.
Postoje dvije vrste elemenata s kojima se podaci opisuju u JSON obliku. Izvučen je iz
standarda za programske jezike što omogućuje jako lagano parsiranje poruka prilikom
<?xml version="1.0" encoding="UTF-8"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
37
programiranja. Najveća je prednost u tome što je JSON-om u porukama moguće prebacivati
serijalizirane izrađene objekte, instancirane prilikom izvršavanja programa. JSON objekti su
posebno pogodni za korištenje u objektno orijentiranim programskim jezicima.
5.3.1. JSON elementi
Dva tipa JSON elemenata su strukturirani i primitivni elementi. Strukturirani oblici su
objekti i polja. Primitivni elementi su tekst (String), broj (number), null vrijednost i Boolean
vrijednosti (istina i laž).
5.3.1.1. Objekt
Definicija JSON objekta preuzeta je iz Javascript notacije. JSON objekt je skup ključ-
vrijednost parova. Primitivni objekt je, kako je napomenuto, par gdje je ključ naziv
primitivnog objekta, a vrijednost je prezentacija vrijednosti toga objekta. U jednom JSON
objektu moguće je imati koliko god primitivnih elemenata ili kompleksnih JSON objekata.
Takvim načinom mogu se izrađivati složene strukture, ali se također može zadržati na
jednostavnim objektima. Objekt u objektu omogućuje izradu stabla strukture. Stablasta
struktura postoji i u XML, ali s jednim velikom ograničenjem. XML dokument uvijek počinje
od jednog korijenskog elemenata. JSON-ova prednost je što ima polje kao strukturni element.
Polje kao korijen zaobilazi tu potrebu da ima samo jedan korijenski objekt u strukturi. U
Zapis 2 Primjer JSON zapisa izrađen je strukturirani objekt "glossary" koji se sastoji od
primitivnih tipova objekata i kompleksnijih tipova objekta. Unutar vitičastih zagrada potrebno
je navesti ime objekta pod navodnicima. Zatim se stavlja dvotočka te se definira vrijednost
koja može biti jednostavna kao "title" ili kompleksna kao "GlossDiv".
5.3.1.2. Polje
Polje je strukturni element koji u sebi može sadržavati vrijednosti, kompleksne objekte
i primitivne objekte. Polje u sebi može imati i polja. Elementi unutar jednoga polja ne moraju
biti istoga tipa. Vrijednosti unutar polja mogu biti tekst (string), broj (number), null i
booleanove vrijednosti (istina i laž). U Zapis 2 Primjer JSON zapisa je objekt
"GlossSeeAlso": čija je vrijednost polje primitivnih tipova tekst (eng. String).
5.3.1.3. Primitivni tipovi
38
Primitivni tipovi su tekst ili niz znakova (eng. String), brojevi (eng. Number), null, ili
Boolean vrijednosti. Niz znakova stavlja se pod dvostruke navodnike.
Zapis 2 Primjer JSON zapisa (ECMA)
.Primjer je prikazan na Zapis 2 Primjer JSON zapisa objekta "title". Brojevi se upisuju bez
navodnika. Primjer za primitivni tip je: "Visina":170. Null vrijednost može se zapisati.
Ukoliko objekt nije izrađen, a definiran je, deserijalizacijom poprima null vrijednost.
Booleanove vrijednosti su true (istina) i false (laž). Primjer je objekt "Check":false.
{
"glossary": {
"title": "example glossary",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Acronym": "SGML",
"Abbrev": "ISO 8879:1986",
"GlossDef": {
"para": "A meta-markup language, used to create markup
languages such as DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markup"
}
}
}
}
}
39
5.4. JSON Schema
JSON Schema opisuje JSON format podataka. JSON Shema opisuje kako treba
izgledati struktura izrađenog dokumenta u JSON zapisu. Izradom JSON sheme dokument u
JSON zapisu postaje strukturiran i izlazi iz sfere polustrukturiranih podataka. JSON Scheme
služi kao validator JSON dokumenta.
Zapis 3 Primjer JSON Scheme (Json Schema, 2013)
Na Zapis 3 Primjer JSON Scheme (Json Schema, 2013) prikazana je jednostavna
JSON shema. Shema ukazuje na to da dokument JSON objekt, koji će biti validan prema njoj,
mora u sebi sadržavati jedan objekt, "Example Schema", koji sadrži obavezno dva primitivna
objekta te opcionalno jedan primitivan objekt. Obavezni primitivni objekti definiranih naziva
"firstName" i "lastName" su tipa string. Opcionalni primitivni objekt naziva "age“ je npr. broj
koji je još unutar sheme definiran kao integer. Objekt ''age'' ima ograničenje koje mu ne
dopušta da bude negativan. Ovaj primjer ukazuje da čovjek i računalo mogu čitati isti
dokument veoma razumljivo. JSON shema ima definirane ključne riječi. JSON shema
zapisana je u JSON formatu te koristi strukturirane objekte i primitivne objekte. Ona ima
definirane ključne riječi za opis i strukturalizaciju određenog dokumenta izrađenog u JSON
zapisu. Ključne riječi su na primjer ''type'' koju je potrebno navesti u svakom objektu tako da
{
"title": "Example Schema",
"type": "object",
"properties": {
"firstName": {
"type": "string"
},
"lastName": {
"type": "string"
},
"age": {
"description": "Age in years",
"type": "integer",
"minimum": 0
}
},
"required": ["firstName", "lastName"]
}
40
se zna tip podataka za primitivni ili strukturni element. JSON zapis objekta može biti
ugniježđen. Na Zapis 4 Ugniježđeni JSON Schema (F. Galiegue , Kris Zyp , Gary Court,
2013) vidimo kako će se definirati ugniježđeni JSON zapis.
Zapis 4 Ugniježđeni JSON Schema (F. Galiegue , Kris Zyp , Gary Court, 2013)
JSON shemom se polustrukturirani podatak strukturira. Strukturiran je onoliko
koliko je detaljno razrađena JSON shema. Kada u JSON shemi nabrojimo elemente, JSON
zapisi koji su validni prema toj shemi imaju definiranu strukturu.
Poruke u JSON zapisu koje će ETL alat obrađivati u ETL postupku najčešće nisu
definirane, a to je u većini slučajeva kada se uvodi ETL u nekom poduzeću. Poduzeće ima
različite izvore podataka koji nisu definirani u potpunosti.
5.5. JSONiq upitni jezik
JSONiq je upitni jezik izrađen za postavljenje upita nad podacima zapisanim u JSON
formatu. JSONiq je napisan po uzoru na XQuery. XQuery je jezik za postavljanje upita nad
podacima zapisanim u XML formatu. JSONiq izrađen je tako da radi na sekvenci podataka.
On ne radi nad jednim objektom, nego istu radnju izvršava nad setom objekata. On je
funkcionalan jezik. Izraz ima glavno značenje prilikom obrade. Također je i deklarativan jezik
te se definira kakav izlaz mora biti.
Za pokretanje upita izrađenih u JSONiq jeziku koristi se Zobra NoSQL processor.
Zobru je razvio Oracle, 28msc i FLWOR fundacija. Sintaksa jezika je takva da se navode
nazivi objekata koji će zatim kao rezultat dati vrijednost tog objekta ili više vrijednosti
ukoliko ih pronađe. Definiranje vrijednosti nije nužno, ali je moguće.
{
"title": "root",
"otherSchema": {
"title": "nested",
"anotherSchema": {
"title": "alsoNested"
}
}
}
41
({ "foo" : "bar" }, { "foo" : "bar2" } ).foo je primjer upita u JSONiq jeziku. Unutar ''('' i
'')'' nalaze se dva JSON objekta. Nakon ''.'' slijedi naziv objekta koji se traži. Rezultat ovoga
upita je: "bar" i "bar2". Na Programski kod 1 Primjer JSONiq upita za Zobra virtualni stroj
prikazano je spajanje dviju kolekcija ''faqs'' i ''answers''. Kolekcije su sekvence Jsona
Objekata. JsonIq najčešće radi sa kolekcijama.
Programski kod 1 Primjer JSONiq upita za Zobra virtualni stroj
Zobra je virtualni stroj za procesiranje JSONiq upita. Otvorenog je koda pisan u C++
jeziku. Osim JSONiq upitnog jezika, implementiran je i XQuery upitni jezik jer su istoga tipa
obrade. Može se kombinirati procesiranje XML i JSON-a.
Slika 16 Prikaz zaslona za Zobra live demo
Slika 16 Prikaz zaslona za Zobra live demo prikazuje primjer koda koji je moguće
obraditi u Zobra virtualnom stroju.
for $question in collection("faqs"),
$answer in collection("answers")
[ $$.question_id eq $question.question_id ]
return { "question" : $question.title,
"answer score" : $answer.score }
42
5.6. Usporedba XML i JSON-a
Poruka koja sadrži JSON zapis može prenijeti vrijednosti koje su potrebne. Takve
poruke mogu poslužiti u istu svrhu kao i XML poruke. Glavna razlika je u tome što poruke u
XML zapisu imaju veću količinu potrebnih oznaka. Druga bitna razlika je što se u poruci s
JSON zapisom može prenositi serijalizirani objekt. U jednom sustavu se objekt izradi, te se
potom serijalizira. U drugom sustavu, koji komunicira s prvim sustavom, taj objekt u poruci
može se deserijalizirati i nastaviti s daljnjim korištenjem. Upravo ta druga razlika je JSON
učinila popularnim gdje su se prebrodila ograničenja XML-a.
Prednost kod XML je u tome što se on dugo razvijao te je postao standard za razmjenu
poruka između dvaju sustava u različitim poduzećima, u B2B komunikaciji. Za svaku granu
industrije postoji nekoliko razvijenih XML shema koje moraju sadržavati sve atribute XML
poruka kako bi se pokrile sve važne i krucijalne informacije za komunikaciju dvaju poduzeća
u pojedinoj grani poslovanja.
Odnos XML-a i JSON formata zapisa dobro opisuju Nolan i Lang u knjizi XML and
Web Technologies for Data Sciences with R (2014, str. 15):
„Many people claim JSONcontent is easier to read and more compact than XML. This
depends on how it is formatted, but is often the case. However, JSON is much less
general than XML and there are times when we want the power and versatility of
XML.“
43
6. Rad sa polustrukturiranim podatcima
6.1. Izvor polustrukturiranih podataka
Izvori polustrukturiranih podataka mogu biti svi segmenti poslovanja nekoga
poduzeća. B2B komunikacija, kako je navedeno, stvara polustrukturirane poruke. One su
najčešće zapisane u XML formatu. Većina njih ima definiranu XML shemu kako mora
izgledati jedna takva poruka, zavisno u kojem segmentu poslovanja se ona koristi. Takve
poruke, kako je već navedeno, imaju svoju strukturu zbog same primjene. Obrada
polustrukturiranih izvora u XML formatu već je dovoljno istražena. Načini i metode obrade
poruka u XML zapisu već su dobro definirani i u teoriji i u praksi. U svakom alatu postoji
nekoliko predefiniranih funkcija koje pomažu njihovoj obradi. Razvijene tehnologije vezane
uz XML omogućuju nam njegovu detaljnu obradu.
U B2B komunikaciji poruke u JSON zapisu nisu učestale. Takav način komunikacije
koriste kompanije koje su se razvile u zadnjih desetak godina kada se JSON format zapisa
počeo primjenjivati. IT kompanije su većinom počele koristiti JSON zapis za svoje servise.
Sve razvijenije kompanije također počinju sa primjenom JSON zapisa u svojoj komunikaciji.
Na Slika 17 Komunikacija klijenta na pretraživaču i pozadinskog sustava na serveru (Li,
2010) vidimo način komunikacije sučelja i pozadine neke web aplikacije.
Slika 17 Komunikacija klijenta na pretraživaču i pozadinskog sustava na serveru (Li, 2010)
Komunikacija između sučelja aplikacije i pozadinskog dijela aplikacije odvija se
putem JSON poruka. Sadašnji sustavi poruke deserijaliziraju te ih potom pohranjuju u
44
transakcijsku bazu nakon što ih se u potpunosti strukturira. Potom iz transakcijskih baza ETL
sustav prebacuje te podatke u skladište podataka.
Klasične mobitele zamjenjuju pametni telefoni. Za pametne telefone razvijaju se
mobilne aplikacije. Većina aplikacija instalirana kod korisnika je klijent u nekom klijent
server sustavu. Aplikacija koja ne komunicira sa serverom nema velike mogućnosti.
Klijentske aplikacije instalirane na pametnim telefonima porukama komuniciraju sa web
serverima. Poruke su u većini slučajeva zapisane u JSON formatu. Razlozi toga su lakoća
serijalizacije i deserijalizacije i manja veličina poruke. Poruke su namijenjene za prijenos
preko GSM, 3G, 4G mreže i slično. Neke od tih mreža su sporije te ne mogu prenositi veliku
količinu podataka u realnom vremenu. Zbog toga poruke moraju biti što manje kako bi se
mogle što brže prenositi.
Prema Twitterovoj službenoj stranici (dev.twitter.com) najbolji primjer komunikacije
je komunikacija s Twitter-om. Twitter koristi REST (Representational state transfer) server.
REST server je aritektura sustava sastavljena od komponenata , konektora i podatkovnih
elemenata.Odgovor na upite prema Twitterovom REST serveru su u JSON zapisu. Funkcije
Twittera, kao na primjer objavljivanje statusa, moguće je osim preko njihovog web servisa i
mobilne aplikacije uraditi i preko vlastoručno izrađene aplikacije. Vlastita aplikacija mora
imati ugrađen mehanizam koji izrađuje poruku u JSON zapisu. Takva poruka se šalje Twitter
REST serveru. Odgovor od REST servera je također poruka u JSON zapisu. Osim objave
statusa, moguće je dobivati sve objavljene statuse koji se trenutno objavljuju. Statusi se
dobivaju također kao odgovor u JSON zapisu.
45
6.2. Predefinirana funkcija čitanja JSON zapisa u ETL alatu
6.2.1. Problem obrade JSON zapisa
Obrada JSON zapisa nije još toliko razvijena u ETL alatima koji prevladavaju na
tržištu. Svaki od vodećih alata razvio je svoje rješenje obrade JSON zapisa. Problem obrade
JSON zapisa nisu funkcije transformacije i čišćenja podataka, već je problem kako pristupiti
čitanju JSON zapisa te kako JSON zapis iščitati i prilagoditi ga kako bi se mogao obraditi s
predefiniranim funkcijama koje već postoje unutar ETL alata.
ETL alati za obradu, kako je napomenuto, izrađuju se tako da imaju tok podataka. U
toku podataka nalaze se redci. Svaki redak se sastoji od atributa. Svaka funkcija se veže na
jedan ili nekoliko atributa. U jednu funkciju obrade dolazi cijeli redak. U funkciji se definira
što će se sa svakim atributom retka raditi te sedefinira hoće li se atribut samo proslijediti ili će
nad njime biti izvršena neka kalkulacija koja se definira unutar funkcije.
Transformacije koje posjeduje bilo koji alat moguće je iskoristiti i za obradu JSON
zapisa. JSON zapis se mora prilagoditi takvoj vrsti obrade. Potrebno je riješiti problem kako
jednu JSON objekt efikasno iščitati i pretvoriti u klasičan redak s atributima. Što će se dalje
uraditi s retkom, odredit koja integrira podataka.
Pristupanje tom problemu riješeno je u nekim alatima na različite načine. Svaki ETL
alat ima funkciju u kojoj se definira iščitavanje podataka iz pojedinog tipa izvora. Posebna je
funkcija izrađena za definiranje čitanja datoteka, a posebna funkcija za čitanja baza podataka,
itd. Pristup različitim sustavima (Oracle, MySQL) nije isti.
6.2.2. Metapodatak
Kada ETL alati rade s izvorima podataka, oni preuzimaju pohranjene metapodatke o
njihovoj strukturi. Spajanjem na baze podataka postojeći meta podaci se nalaze unutar
kataloga RDBMS-a. ETL alat preuzima meta podatke o pojedinoj tablici. Spajanjem na
datoteke zapisane u Excel ili csv (comma separated values) formatu, prvi redak najčešće
sadrži informaciju o nazivu sadržanih atributa. U jednom i u drugom slučaju jednostavno je
doći do informacija o nazivima atributa jer u relacijskim bazama podataka postoje
metapodaci, dok su u excel i csv datotekama podaci pohranjeni u retcima tako da su atributi
46
sami po sebi definirani. Iako nema naziva atributa, jednostavno ih je samostalno definirati.
Funkcija iščitavanja definira kakav će redak i sa kojim atributima izlaziti iz nje. Funkcije
međusobno komuniciraju na način da se definirani atributi na izlazu jedne funkcije postave
kao atributi ulaza druge funkcije.
Čitanje JSON-a moguće je izvršiti sa JSONiq upitnim jezikom, koji je već opisan u
radu. Takav način moguće je primijeniti ako je struktura JSON zapisa poznata i definirana.
Poznatu strukturu je zatim lako pretraživati i postavljati upite. Poruke u JSON zapisu u većini
slučajeva nisu definirane. Također, iz jednoga izvora možemo imati više različitih varijacija
iste poruke. Potrebno je izraditi funkciju koja će biti dinamična. Funkcija mora sama prikazati
cjelokupni izgled JSON zapisa. Osoba koja razvija će samostalno odrediti kako će se taj
JSON zapis potom obrađivati iz toga cjelokupnoga izgleda.
6.2.3. Izrada tokova
Glavni element koji je potrebno promatrati u JSON zapisu je objekt. Uz objekt postoji
i kompleksni element polje. Polje je element koji omogućuje napredno oblikovanje JSON
zapisa. Svaki JSON zapis posjeduje objekte u kojem su sadržane informacije koje je potrebno
obraditi. JSON objekt se sastoji od jednog ili više objekata složenog ili primitivnog tipa.
Jedan složeni JSON objekt tvori jedan redak. Unutar toga retka atributi će biti primitivni
objekti i agregirana polja koja se sastoje od primitivnih objekata. Unutar složenog objekta
može se nalaziti drugi složeni objekt. Njega nije moguće pretvoriti u atribut. Taj složeni
objekt koji je sadržan unutar složenog objekta tvori novi tok. Atributi za retke unutar novog
toka se ponovno definiraju od njegovih primitivnih elemenata. Funkcija koja će iščitavati
JSON zapis imat će onoliko tokova koliko će sadržavati ugniježđenih složenih objekata. To je
prikazano na Slika 18 Json čitač.
47
Slika 18 Json čitač
JSON polja su elementi koji također utječu na obradu podataka. Polje koje sadrži
primitivne elemente mora se na neki način sažeti ukoliko se ne radi o JSON zapisu koji je
oblikovan kao set podataka. Agregacije mogu biti primjerice, kalkulacija koja sumira sve
vrijednosti ako su one brojčanog tipa ili spajanje ako su one tekstualnog tipa. Može se na
način da se definira koji će se element unutar polja uzimati. JSON polja u kojima se nalaze
složeni objekti promatramo na drugačiji način. Takva polja su na neki način čvorovi. JSON
objekt u tim poljima sadrži složene objekte istoga ili sličnoga sadržaja. Svi složeni objekti
unutar jednoga polja su jedna vrsta retka koji izlazi iz funkcije. Svi ti redci imaju iste atribute
koji se tvore od istih primitivnih objekata sadržanih u tim ponavljajućim (repetitivnim)
složenim objektima.
6.2.4. Dinamička izrada metapodataka
U funkciji koja će iščitavati određeni JSON zapis potrebno je pronaći cjelokupni
izgled svakog JSON objekta koji će se pretvarati u redak. U dva objekta koji će ići u isti tok,
dakle dva repetitivna objekta, mogu se nalaziti različiti atributi. To se može dogoditi ako klase
objekata implementiraju isto sučelje. Objekti su istoga tipa, ali su različiti. Postupak stvaranja
informacija o izgledu svakog objekta je stvaranje metapodataka za određeni JSON zapis. U
metapodatku potrebno je definirati koje sve elemente pojedini repetitivni objekt sadrži.
Također je potrebno definirati koji su to repetitivni objekti od objekata koji služe za stvaranje
hijerarhije (ugnježđivanja).
Učenje izgleda objekta ne može se provoditi nad cjelokupnim setom podataka ili samo
nad prvim objektom. Potrebno je izraditi sustav koji će prolaziti kroz prvih nekoliko redaka te
48
tako izraditi model objekta, tj. metapodatak o objektu. Potrebno je omogućiti osobi koja
razvija da sam odredi koliko u kojoj razini JSON objekta će se provjeravati istovjetnost
modela nekog objekta.
Slika 19 Izgled izlaza i ulaza JSON čitača
Na Slika 19 Izgled izlaza i ulaza JSON čitača vidimo primjer gdje svaki objekt stvara
svoj tok podataka sa redcima koji imaju definirane atribute prema ulaznom JSON zapisu.
Svaki sljedeći objekt „widget“ dolaskom na obradu rasporedit će se po tokovima na identičan
način. Funkcija koja prolazi kroz JSON zapis i izgrađuje model mora biti rekurzivna kako bi
se mogla kretati kroz zapis.
6.2.5. Mapiranje
Funkcija iščitavanja i pretvaranja JSON zapisa u retke treba ponuditi sve mogućnosti.
Ona treba naučiti kako pojedini JSON objekt u zapisu izgleda. Kada imamo izgled JSON
objekta, osoba koja razvija integraciju podataka unosi logiku kako će se koji objekt pretvoriti
u redak. Taj postupak naziva se mapiranje. U samoj funkciji imamo jedan ulaz s više složenih
objekata koji, logikom koju određuje soboa koja razvija, pretvaraju se u retke. Takva funkcija
može se poistovjetiti s terminologijom računalnih mreža. Može se povući poveznica prema
uređaju ruter.
49
Postavlja se pitanje kako će redci putovati. Svaki redak ide u svoju granu. Svaka grana
bude opskrbljena sa svojim retkom nakon što se opskrbe redci iz prethodnog toka za taj
objekt.
Način obrade opisan u ovom dijelu razvijen je kako bi omogućio osobi koja razvija
integraciju podataka što jednostavnije i brže razvijanje ETL postupka. Postupak se može
primjenjivati u bilo kojem ETL alatu. Ovaj način zadržava klasičan pristup integraciji
podataka.
6.3. Čitanje i obrada JSON zapisa izradom mapReduce modela
6.3.1. Problem obrade JSON zapisa
Model za obradu podataka također se može izraditi u mapReduce modelu. U tom
slučaju osoba koja razvija integraciju podataka mora biti i programer. Ovaj način je
kompleksniji i sporije se izrađuje ETL proces. Stoga, kada je jednom razvijen ETL proces za
određeni izvor polustrukturiranih podataka, on je veoma brz i učinkovit. Brz će biti stoga što
će moći biti distribuiran. Još jedan segment brzine će biti taj što će se koristiti direktna
serijalizacija i deserijalizacija objekta.
S obzirom da se ETL razvija programski, JSON objekti se mogu deserijalizirati i
nastaviti obrađivati kao objekti.
6.3.2. Metapodatak
U ovom načinu metapodaci su potrebni unaprijed. Prilkom razvoja ETL procesa mora
se znati definicija objekata kako bi se mogla izvesti deserijalizacija objekata iz JSON zapisa.
Nema potrebe za dinamičkim metapodacima.
6.3.3. Izrada tokova
Rješavanju problema se pristupa jednako kao u prethodno opisanoj metodi, samo što
je sada puno lakše izvesti takav način. Svaki objekt će imati svoj tok za obradu. Lakše je
utoliko, što svakom toku samo proslijedimo deserijalizirani objekt. Unutar tog objekta može
se nalaziti i drugi objekt za kojeg nema potrebe da se odvaja u poseban tok. Svaki tok imat će
svoj maper i svoj reduktor. Svaki objekt će se morati obraditi na poseban način. Dakako,
50
programeru razvija integracija podataka dozvoljena je upotreba istih mapera i reducera za
različite podatke. U ovom načinu nema puno ograničenja. Onaj tko stvara model za obradu
podataka ima slobodu stvaranja. Sloboda stvaranja mora biti u okviru opisane mapReduce
paradigme. Izrada tokova odvija se samom deserijalizacijom objekata. Izrađuje se funkcija
koja prolazi kroz čitav model i koja deserijalizira objekte. S obzirom da programer mora znati
shemu dolazećeg JSON objekta, to neće biti problem te funkcija ne mora biti rekurzivna.
6.3.4. Mapiranje
U ovom načinu cijeli razvoj je prepušten programeru. Programer osim znanja
programiranja mora bit upućen u ETL proces. Programer mora znati nadolazeći izgled
podataka i odredišni izvor podataka. Svaki objekt će se rastaviti na atribute i tako upisati u
bazu podataka.
Drugo rješenje za pohranu je jednostavno zapisivanje u NoSql bazu, primjerice HBase ili
u Hive tabicu.
6.4. Prednosti i mane načina obrade
U prvom načinu potrebno je izraditi funkciju čitanja u JSON zapisu, a za to je
potreban programer. Kada se funkcija jednom izradi te imamo i njezinu vizualnu prezentaciju,
ona će se koristiti učestalo. Razvoj takve funkcije će biti dug, ali će njezinim razvojem svaki
novi razvoj mapiranja biti brz. U prvom načinu možemo znanje razdvojiti na dvije osobe,
odnosno na dva zaposlenika. Jedan zaposlenik može biti programer, dok je druga osoba ona
koja razvija integraciju podataka u grafičkom alatu (eng. Data integration developer). Također
možemo odvojiti ta dva procesa. Velika je prednost što svaki od osoba može biti veliki
stručnjak u svojem području. Svaki u svojem području može izraditi vrhunski zadatak.
Za izradu drugoga načina potrebna je samo jedna osoba, odnosno osoba koja izrađuje
mora imati znanje i iz programiranja i iz integracija podataka. Postavlja se pitanje je li
dovoljno stručna u oba područja. Osoba koja ima visoko znanje iz oba područja povlači i
financijsku komponentu. Cijeli postupak je potrebno programirati što proces izrade svakog
pojedinog integriranja čini dužim. Jednom kada se taj postupak kvalitetno izradi, on će biti
puno brži nego sa predefiniranim funkcijama.
51
Oba načina su dobra, zavisno koja im je namjena i kako se koriste. Prvi način sa
izradom predefinirane funkcije je najbolje koristiti kada trebamo:
proces izraditi za jednokratnu uporabu
proces izraditi brzo
kada nam brzina obrade procesa nije bitna
kada izrađeni proces obrađuje optimalnu količinu podataka
Drugi način s programiranjem mapReduce modela za obradu se koristi kada trebamo:
obraditi veliku količinu podataka u realnom vremenu
izrađeni proces obrade koristiti konstantno
izraditi proces koji ima veliku brzinu izvršavanja
52
7. ETL sustavi
7.1. Samostalna izrada sustava
ETL sustav je moguće izraditi u programskom kodu. Takav postupak duže traje te se
koristi kada želimo procesirati veliku količinu podataka. Također, napisani kod za obradu
podataka može biti optimiziran i distribuiran. Optimiziran je zato što se odbacuju nepotrebne
predefinirane radnje, a distribuiran jer se može sa raznim načinima distribuirati u cilju
izvršavanja na više odvojenih čvorova. Čvor je, kako je navedeno, jedan server.
Distribuiranost možemo dobiti s korištenjem mapReduce modula u Hadoop sustavu.
MapReduce model može se izraditi za obradu podataka prije pohrane u skladište
podataka ili nakon pohrane u skladište podataka. Također, mapReduce poslovi mogu se
izvoditi prilikom izrade izvještaja.
Kako bi se mapReduce poslovi mogli izvoditi, potrebno je dodati Java API Hadoop-
core. U njemu se nalaze sučelja mapera i reduktora. Maperi i reduktori se izrađuju tako da se
ručno izrade funkcije unutar klasa koje implementiraju ta sučelja.
MapReduce paradigma je najviše iskorištena kada se koristi pri masivnom
procesiranju. U skladište podataka mogu se pohranjivati agregirane vrijednosti. Unutar
mapReduce dodaju se razne transformacije i obrade podataka.
53
Programski kod 2 Maper izrađen u Java programskom jeziku (Alma, 2013)
Programski kod 2 Maper izrađen u Java programskom jeziku (Alma, 2013) prikazuje
jednostavni maper. Za izradu mapera proširena je klasa Mapper<Text,Text,Text,Text> iz Java
Api-a hadoop-core.
Programski kod 3 Reduktor izrađen u Java programskom jeziku prikazuje proširenje
klase Reducer<Text, Text, Text, Text> iz Java Api-a hadoop-core.
package net.pascalalma.hadoop;
import org.apache.hadoop.io.Text; import org.apache.hadoop.mapreduce.Mapper; import java.io.IOException; import java.util.StringTokenizer; /** * Created with IntelliJ IDEA. * User: pascal * Date: 16-07-13 * Time: 12:07 */ public class WordMapper extends Mapper<Text,Text,Text,Text> { private Text word = new Text(); public void map(Text key, Text value, Context context) throws IOException, InterruptedException { StringTokenizer itr = new StringTokenizer(value.toString(),","); while (itr.hasMoreTokens()) { word.set(itr.nextToken()); context.write(key, word); } } }
54
Programski kod 3 Reduktor izrađen u Java programskom jeziku
Potrebno je Objekte maper i reduktor definirati unutar određenog posla (eng. job), npr.
Job job = new Job (conf, "dictionary");. U kodu je potrebno koristiti funkcije
setMapperClass(Mapper mapper) i setReducerClass(Reducer reducer) kako bi se u pojedini
posao postavile novoizrađene klase.
Jedno od rješenja koje se nameće način je pohrane JSON zapisa i izrade upita nad
njima. JSON je moguće pohranjivati u Hive tablice u tip podataka struct. Tip podatka struct se
definira prilikom izrade tablice i može biti replika sheme JSON zapisa. Struct definira
kompleksni objekt. Parsiramo JSON zapis i spremamo zapise u definiranu shemu. Svakom od
elemenata struct podataka moguće je pristupati. Izradom upita u HiveQL jeziku definira se
mapReduce posao koji koristi sve zapisane elemente.
package net.pascalalma.hadoop;
import org.apache.hadoop.io.Text; import org.apache.hadoop.mapreduce.Reducer; import java.io.IOException; /** * Created with IntelliJ IDEA. * User: pascal * Date: 17-07-13 * Time: 19:50 */ public class AllTranslationsReducer extends Reducer<Text, Text, Text, Text> { private Text result = new Text(); @Override protected void reduce(Text key, Iterable<Text> values, Context context) throws IOException, InterruptedException { String translations = ""; for (Text val : values) { translations += "|" + val.toString(); } result.set(translations); context.write(key, result); } }
55
7.2. Izrađeni sustavi
7.2.1. Informatica Power Centar
Informatica je jedna od vodećih kompanija u svijetu koja se bavi ETL-om. Imaju razvijen svoj
ETL alat Informatica PowerCenter koji je vodeći svjetski ETL alat. Uz navedeni alat razvija
se i Informatica Developer. Informatica Developer je alat koji će postupno zamijeniti
Informatica PowerCentar jer se razvija u smjeru obrade velike količine podataka.
Slika 20 Arhitektura Informatica PowerCentra (Informatica, 2014) prikazuje arhitekturu
PowerCentar sustava sastoji se od nekoliko dijelova. PowerCentar servisi se instaliraju na
server koji će služiti samo za obradu podataka. PowerCentar integracijski servis i servis
repozitorija su srž sustava. Integracijski servis izvršava proces prema načinu koji je pohranjen
u repozitorijskom servisu. Repozitorij servis pohranjuje u posebnu relacijsku bazu načine
obrade pojedinih izvora.
Slika 20 Arhitektura Informatica PowerCentra (Informatica, 2014)
Obrada nije samo izvršavanje prema definiranom mapiranju. Obrada se sastoji od
povezanog toka izvršavanja zadataka, među kojima se nalaze i mapiranja. Tok izvršavanja
zadataka izrađuje se klijentskom aplikacijom Workflow Manager. Slika 21 Izgleda sučelja
56
Informatica PowerCenter Workflow Manager-a prikazuje njegov izgled. Na toj slici se
također nalazi primjer jednostavnog toka izvršavanja.
Slika 21 Izgleda sučelja Informatica PowerCenter Workflow Manager-a
Mapiranja se izrađuju u klijentskoj aplikaciji Designer. Slika 22 Izgled Informatica
PowerCenter Designer sučelja prikazuje njegov izgled. Također, na slici je prikazan primjer
mapiranja s nekoliko transakcija. Slika sadrži nekoliko čvorova. Svaki čvor ima definirane
portove (ulazne i izlazne varijable). One su osnova svakoga čvora. Posebnost Informatica
PowerCenter-a prilikom dizajniranja koja uvelike olakšava posao je rad s vlastitim tipovima
podataka. Svaki tip podataka iz različitih baza pretvara u svoj vlastiti oblik te u cijelom
mapiranju radi s vlastitim tipom. Na kraju, vlastiti tip podatka pretvara u onaj tip kakav je
primjeren za odredišnu bazu podataka.
57
Slika 22 Izgled Informatica PowerCenter Designer sučelja
Repository Manager je klijentska aplikacija u kojoj se nalaze svi metapodaci od
definiranih izvora za pojedinog korisnika. U Repository Manager također se nalaze definirana
mapiranja.
Slika 23 Izrađeno mapiranje u Informatica PowerCentru
58
Na Slika 23 Izrađeno mapiranje u Informatica PowerCentru prikazano je mapiranje.
Svaka funkcija, kako je vidljivo, je otvorena tako da se mogu vidjeti portovi. Portovi su
ulazne i izlazne varijable. Portovi mogu biti ulazni, izlazni ili ulazno/izlazni.
Nadzor izvršavanja napravljenog posla se može nadzirati isto kao i pokrenute poslove.
7.2.2. Pentaho Kettle
Pentaho Kettle je ETL alat otvorenog kod. Njime se vrši transformacija podataka tako
što učitava retke iz izvorne tablice i obrađuje atribute svakog retka sa predefiniranim
funkcijama. Alat obrađuje podatke redak po redak. Pentaho Kettle je napisan u java
programskom jeziku. Pentaho Kettle za izradu transformaciju i poslova koristi skriptu Spoon
koja ima grafičko sučelje. Transformacija se izrađuje tako da se metodom „dovuci i ispusti“
(eng. drag and drop) zadaju predefinirane funkcije. Postoji više vrsta funkcija podijeljene u
kategorije: input, output, transform, flow itd. Funkcije su predefinirane, ali postoje one koje se
mogu dodatno modificirati s programskim jezikom Java i JavaScript.
U Kettlu postoje dvije razine: transformacije i poslovi. Poslovi mogu sadržavati više
transformacija. Transformacije i poslovi se mogu izvršavati iz Spoon-a ili se mogu pokretati
sa skriptama Kitchen za poslove i Pan za transformacije. Preko tih skripta moguće je
prosljeđivati varijable u skriptu. Kettle pohranjuje transformacije u datoteku sa ekstenzijom
.ktr, a poslove s ekstenzijom .kjb. Pentaho Kettle može se koristiti za izradu mapReduc
poslova. Izrađuje se transformacija kojoj se dodjeljuju posebni ulazi i izlazi kako bi ona
mogla biti map ili reduce funkcija. Te se funkcije definiraju u posebnom mapReduc poslu na
višoj razini. MapReduc posao šalje zatim izrađene transformacije na Hadoop sustav gdje će se
one izvršavati. On generira Java programski kod iz workflowa koji će biti upotrijebljen na
Hadoopovom mapReduce modulu.
59
Slika 24 Pentaho Kettle Spoon sučelje i izrađena transformacija
Na Slika 24 Pentaho Kettle Spoon sučelje i izrađena transformacija prikazan je izgled
jedne izrađene transformacije. U ovom slučaju, tu se radi o reduce transformaciji. Na lijevoj
strani vidimo izbornik kategorija transformacija. Desno je ploča na kojoj povezujemo funkcije
transformacije. Svaka reduce ili maper transformacija ima istu ulaznu i izlaznu funkciju.
Ulazna i izlazna funkcija definira se unutar posla koji spaja jednu map i jednu reduc
transformaciju i tvore mapReduce posao.
Na Slika 25 Pentaho Kettle Spoon sučelje i izrađen posao vidljivo je kako se izrađuje
posao koji je na razini višoj od transformacije. Pokretanjem ovog posla, poslat ćemo izrađeni
mapReduce model na definirani Hadoop sustav. Hadoop sustav će primiti mapReduce model
u obliku programskog koda koji je generirao Pentaho Kettle te će ga izvršavati kod sebe.
Slika 25 Pentaho Kettle Spoon sučelje i izrađen posao
60
Naveden je primjer gdje se transformacija obavlja na drugom sustavu. Klasične
transformacije izvršavaju se lokalno na sustavu gdje je Pentaho Kettle instaliran. Pentaho
Kettle kao sustav uzima redak po redak te ga obrađuje. Svaki redak prolazi kroz definirane
funkcije te se obrađuje na isti način. Nakon neprolaska jednoga retka, sustav nastavlja sa
daljnjom obradom. Zapisuju se samo problematični redovi modela.
Slika 26 JSON Input u Pentaho Kettle alatu
Slika 26 JSON Input u Pentaho Kettle alatu prikazuje JSON čitač u Pentaho Kettle
alatu. Na slici se nalazi i prikazan JSON objekt koji je pokušao biti učitan s JSON čitačem.
Pokušaj nije uspio jer čitač nije prepoznao JSON zapis unutar datoteke. JSON zapis u datoteci
pravilno je zapisan. Potrebno je koristiti regularni izraz kako bi se opisale varijable. Pisanje
regularnih izraza uvelike otežava i ograničava izradu mapiranja.
61
8. Prototip alata za obradu JSON-a
8.1. Karakteristke prototipa
U sklopu rada izrađen je prototip alata za iščitavanje JSON zapisa. Prototip alata
izrađuje tokove podataka na način da se svaki tok pohranjuje u definiranu tablicu pojedine
baze podataka. U izradi prototipa aplikacije prikazuje se implementacija rješenja iščitavanja
JSON zapisa. Aplikacija preuzima dokumente koji sadrže JSON objekt ili polje JSON
objekata. Izlaz aplikacije su, kako je navedeno, tablice. Time se željelo simulirati način izrade
tokova. Aplikacija ima jedan ulaz i više izlaza. Prototip aplikacije ima grafičko sučelje.
Aplikacija ima mogućnost izrade mapiranja ulaznog JSON objekata u pojedine tablice. Izrada
mapiranja je glavni razlog što aplikacija ima grafičko sučelje. Prototip aplikacije je alat s
kojim može raditi osoba koja razvija integraciju podataka. Dvije glavne funkcije prototipa
aplikacije su:
definiranje potpunog izgleda pojedinog objekta
definiranje odredišta
izrada mapiranja JSON objekta u odredišta
procesiranje podataka prema definiranim pravilima mapiranja.
8.2. Korištene tehnologije
Program je izrađen u Java programskom jeziku. Java programski jezik je objektno
orijentiran. Grafičko sučelje izrađeno je u Swingu. Swing je primarni alat za izradu grafičkog
sučelja u Java programskom jeziku. Za učitavanje i manipuliranje JSON objektima iskorišten
je GSON Java API.
Java API je kolekcija predefiniranih klasa, paketa i sučelja (eng. interface). Java API
su stvoreni kako bi se izrađeni kod mogao koristiti više puta na različite načine. API je
skraćenica za aplikacijsko programsko sučelje (eng. Application Programming Interface).
GSON je Java API u kojem su sadržane funkcije koje čitaju datoteku s podacima u
JSON zapisu. Izrađene su funkcije koje zapis pretvaraju u JSON objekte i JSON polja kojima
je moguće manipulirati. Kroz JSON polje moguće je prolaziti sa for petljom kao s običnim
poljem (eng. array) u Java programskom jeziku. Isto tako, može se prolaziti i kroz JSON
62
objekt. On je definiran kao i mapa u Java programskom jeziku (eng. map) i trerira se kroz
skup objekata.
Dakle, nije bilo potrebno parsiranje zapisa u JSON Objekte i JSON polje. To je
izrađeno pomoću GSON API-a.
8.3. Izgled nositelja metapodataka JSON objekta
Definiranje izgleda objekta je izrada metapodatka za pojedini JSON objekt. Potrebno
je izraditi klasu koja će definirati objekte, te klase koje sadrže informaciju o izgledu pojedinog
JSON objekta. Klasa mora biti primjenjiva za izradu izgleda svakog složenog JSON objekta.
Objekti takve klase će se definirati dinamički. Ta klasa će biti metapodatak o JSON objektu.
Ona će biti korištena za definiranje mapiranja te će kao takva biti temelj za procesiranje.
Ugniježđeni JSON objekti će biti definirani unutar objekta. Ugniježđeni JSON objekti
su čvorovi koji služe za izradu hijerarhije. JSON polja bit će prikazana na dva načina. JSON
polje koje se sastoji od složenih JSON objekata bit će prikazano kao repetitivni JSON objekt.
Repetitivni JSON objekti su kandidati za izradu toka. Izraditi se tok može i od nerepetitivnih
JSON objekata iako oni većinom služe za gradnju arhitekture zapisa. JSON polje koje se
sastoji od primitivnih elemenata mora se agregirati kako bi se omogućilo njegovo postavljanje
u jedan redak definiranog toka.
Programski kod 4 Prikaz ExtractObject modela objekta/metapodatak prikazuje izgled
klase ExtractObject klase. ExtractObject definira objekte koji će biti nositelji informacija o
pojedinom JSON objektu. Unutar objekta postavljeni su atributi npr. liste koji sadrže sve
objekte koji se nalaze unutar JSON objekta, prema kojem se izrađuje klasa ExtractObject. Za
svaki primitivni objekt postoji posebna lista i za svaki složeni objekt postoji posebna lista.
63
Programski kod 4 Prikaz ExtractObject modela objekta/metapodatak
8.4. Izrada metapodataka JSON objekta
Nositelj metapodatak se izrađuje složenom rekurzivnom funkcijom:
public Object goThroughElement(Object object, ExtractObject extractObject).
Funkcija poziva samu sebe što znači da je rekurzivna. Ona prolazi kroz svaki element
unutar JSON objekta. Funkcija izrađuje novi ExtractObject ako je potrebno. Izrađene nove
ExtractObject funkcija dodaje unutar roditeljskog JSON objekta.Funkcija prolazi kroz sve
primitivne objekte i dodaje nazive primitivnih objekata u listu kojoj pripadaju po tipu.
Primitivni objekti dodaju se u listu strings ako su tekstualnoga tipa itd. Programski kod 5
Početak dijela koda kada funcija goThroughElement dolazi do složenog objekta prikazuje
iterator koji prolazi kroz elemente objekta.
public class ExtractObject {
public String name;
public ArrayList<String> integers;
public ArrayList<String> strings;
public ArrayList<String> decimals;
public ArrayList<String> booleans;
public ArrayList<ExtractObject> objects;
public ArrayList<ExtractObject> ObjectList;
public ArrayList<String> integerList;
public ArrayList<String> stringList;
public ArrayList<String> decimList;
public ArrayList<String> booleanList;
public ArrayList<CalculateValues> cratedValuesCalculate;
public ArrayList<ConcatStrings> cratedValuesConcate;
public Map<Filter,String> filters = new HashMap<>();
public boolean repeatable;
public Target target;
}
64
Programski kod 5 Početak dijela koda kada funcija goThroughElement dolazi do složenog objekta
Kada funkcija dolazi do složenog JSON objekta ona poziva samu sebe s objektom koji
treba proći i sa ExtractObjectom koji se definira. Prilikom prvoga prolaza bit će potrebno
izrađivati sve objekte. U funkciji je definirano dodavanje segmenata i izrada novih
ExtractObject objekata. Nakon što se prođe kroz prvi objekt, definiraju se arhitektura zapisa i
pojedini objekti. Programski kod 6 Dio koda funkcije goThroughElement gdje se izrađuje
novi objekt ExtractObject ili dodaje novi atribut u listu prikazuje izradu modela. Poziva se
funkcija koja provjeri postoji li taj objekt. Na temelju vraćenog odgovora određuje se da je
potrebno dodati novi objekt.
Programski kod 6 Dio koda funkcije goThroughElement gdje se izrađuje novi objekt ExtractObject ili dodaje
novi atribut u listu
Funkcija će prolaziti kroz objekte onoliko puta koliko je korisnik alata zadao. Funkcija
prolazi kroz idući JSON objekt kako bi dodala segment ili izradila novi ExtractObject objekt
ukoliko on ne postoji u dosadašnjem modelu. Funkcija prolazi kroz JSON objekte te
} else if (object instanceof JsonObject) {
Iterator entries = JsonObject.class.cast(object).entrySet().iterator();
while (entries.hasNext()) {
Entry thisEntry = (Entry) entries.next();
Object searchResponse = extractObject.search(thisEntry.getKey().toString());
} else if (String.class.cast(searchResponse).equals(extractObject.NOTEXIST)) {
ExtractObject newExtractObject = new
ExtractObject(thisEntry.getKey().toString());
returnObj = newExtractObject;
Object returned = goThroughElement(thisEntry.getValue(), newExtractObject);
if (returned instanceof String) {
if (String.class.cast(returned).equals(eObject.STRING)) {
extractObject.strings.add(thisEntry.getKey().toString());
} else if (String.class.cast(returned).equals(eObject.DECIMAL)) {
extractObject.decimals.add(thisEntry.getKey().toString());
}
65
provjerava sadržava li trenutni složeni ili primitivni JSON objekt; ukoliko nije sadržan,
funkcija dodaje taj objekt u izrađeni model.
Programski kod 7 Dio koda funkcije goThroughElement koja obrađuje primitivne JSON objekte
U Programski kod 7 Dio koda funkcije goThroughElement koja obrađuje primitivne
JSON objekte prikazano je kako nakon što se provjeri kakav je objekt, vraća se obavijest o
vrsti objekta funkciji koja je pozvala provjeru toga objekta. Na kraju imamo izrađen
metapodatak koji sadrži model svakog JSON Objekta unutar nekog zapisa u JSON formatu.
Zapis ako nije velik može u cijelosti poslužiti za treniranje modela. Za veliku količinu zapisa
potrebno je na nekoliko bitnih varijacija istrenirati model. Programski kod 8 Dio koda
goThroughElement funkcije koji obrađuje JSON polje prikazuje način na koji se definira
JSON polje s primitivnim objektima.
} else if (object instanceof JsonPrimitive) {
if (JsonPrimitive.class.cast(object).isNumber()) {
returnObj = eObject.DECIMAL;
} else if (JsonPrimitive.class.cast(object).isString()) {
returnObj = eObject.STRING;
} else if (JsonPrimitive.class.cast(object).isBoolean()) {
returnObj = eObject.BOOLEAN;
} else if (JsonPrimitive.class.cast(object).isJsonArray()) {
66
Programski kod 8 Dio koda goThroughElement funkcije koji obrađuje JSON polje
8.5. Mapiranje
Slika 27 Mapiranje objekta izrađeno u prototipu alata za obradu JSON zapisa
prikazuje kako izgleda sučelje kroz koje će korisnik alata izrađivati mapiranje. Mapiranje je
proces u kojem osoba koja razvija definira u koje odredište ide pojedini JSON objekt iz
cjelokupnog JSON objekta. Potrebno je odrediti tablicu iz Tables padajućeg izbornika u koje
će se mapirati izabrani objekt. U Tables padajućem izborniku nalaze se tablice iz svih
definiranih odredišta, tj. baza. U prozoru Table prikazuju se svi atributi odabrane tablice.
if (object instanceof JsonArray) {
int counter = 0;
for (Object o : JsonArray.class.cast(object)) {
returnObj = goThroughElement(o, extractObject);
if (counter++ > stopTraining) break;
if (returnObj instanceof String) {
if (String.class.cast(returnObj).equals(eObject.STRING)) {
returnObj = eObject.ARRAYSTRING;
} else if (String.class.cast(returnObj).equals(eObject.DECIMAL)) {
returnObj = eObject.ARRAYDECIMAL;
} else if (String.class.cast(returnObj).equals(eObject.BOOLEAN)) {
returnObj = eObject.ARRAYBOOLEAN;
} else if (String.class.cast(returnObj).equals(eObject.NOTEXIST)) {
} else if (String.class.cast(returnObj).equals(eObject.ALREADYXIST)) {
returnObj = eObject.ALREADYXIST;
} else {
}
} else if (returnObj instanceof ExtractObject) {
extractObject.repeatable = true;
returnObj = extractObject;
} else {
}
}
67
Nakon određivanja tablice, klikom miša označi se objekt iz prozora Object. Pritiskom
na gumb Create target pojavljuje se i izrađuje povezivanje. U prozoru Target pojavljuje se
par objekt – tablica izrađenog povezivanja. To povezivanje unutar prototipa aplikacije naziva
se target.
Slijedi definiranje koji će se primitivni JSON objekt određenog objekta pohranjivati u
koji atribut u tablici. Klikom miša označi se primitivni JSON objekt unutar prozora Object i
atribut tablice unutar prozora Table. Pritiskom na gumb > definira se par primitivni JSON
objekt- atribut. Taj definirani par pojavljuje se u prozoru Target.
Slika 27 Mapiranje objekta izrađeno u prototipu alata za obradu JSON zapisa
Odredišne baze podataka definiraju se u sučelju prikazanom na Slika 28 Sučelje za
definiranje novog odredišta u objekt izrađeno u prototipu alata za obradu JSON zapisa. Tu se
nalaze polja za upis podataka potrebnih za spajanje na neko odredište.
U slučaju da JSON Objekt nije moguće smjestiti niti u jednu tablicu, upotrebljava se
opcija kreiranje tablice. Unutar grupacije Create New Table iz padajućeg izbornika odabire se
odredišna baza podataka. Klikom miša odabiremo JSON objekt. Pritiskom na gumb Create
68
Table izrađuje se tablica unutar odabrane baze podataka na temelju odabranog JSON Objekta
te se automatski izrađuje mapiranje.
Slika 28 Sučelje za definiranje novog odredišta u objekt izrađeno u prototipu alata za obradu JSON zapisa
8.6. Procesiranje
Slika 29 Sučelje za definiranje input datoteke, početak treniranja i procesiranje objekta
izrađeno u prototipu alata za obradu JSON zapisa prikazuje sučelje koje se sastoji od nekoliko
dijelova. U prototip aplikacije se učitava cjelokupna datoteka. Datoteka mora sadržavati
JSON objekt ili JSON polje. JSON polje se sastoji od JSON objekata. Nakon učitavanja
datoteke moguće je pokrenuti treniranje s parametrima količine objekata za trening. Nakon
izvršenog treniranja pojavljuje se izgled modela JSON objekta unutar taba Mapping u prozoru
Objects.
69
Slika 29 Sučelje za definiranje input datoteke, početak treniranja i procesiranje objekta izrađeno u
prototipu alata za obradu JSON zapisa
Nakon mapiranja može se pokrenuti ETL proces. Prvo se učitaju svi JSON Objekti iz
datoteke s gumbom Read : START. Nakon toga se pokreće proces s gumbom Write: START.
Iz učitanoga skupa uzima se JSON objekt jedan po jedan, te se upisuje u definirano
odredište na način koji je izrađen mapiranjem. Učitava se na način da se u svakom JSON
repetitivnom objektu koji sadrži repetitivni JSON objekt najprije pohrane dijete objekt, a
potom roditelj objekt.
70
8.7. Primjer rada alata
8.7.1. Gilt – izvor podataka
Gilt je kompanija za internet kupovinu odjeće. Gilt se bavi prodajom markirane odjeće
preko interneta. Narudžbu je moguće izraditi na njihovoj stranici
http://www.gilt.com/sale/men?globalnav_refe rrer=women. Potrebno je otvoriti korisnički
račun s kojim je moguće zatim izrađivati narudžbe. Gilt kompanija je razvila REST servis koji
omogućuje da se izrađuju narudžbe u nekoj drugoj aplikaciji. Također, u nekoj drugoj
aplikaciji mogu se pregledavati proizvodi sa stranice. Aplikacija i Gilt REST servis
komuniciraju tako što se na poslani http zahtjev vraća određena poruka u JSON zapisu. Da bi
se mogla ostvariti takva komunikacije, potrebno je na postojeći otvoreni račun na Gilt web
stranici izraditi profil aplikacije. Svaka aplikacija dobiva jedinstveni ključ s kojim će se
potvrđivati o kojem korisniku se radi prilikom komunikacije aplikacije i GILT web servisa.
8.7.2. Struktura podataka
Ima nekoliko mogućih JSON zapisa koje će Gilt servis vratiti ovisno o poslanom
zahtjevu. Dvije vrste zahtjeva će se slati kako bi se prikupilo nekoliko odgovora u JSON
zapisu. Odgovorene poruke u JSON zapisu će se iskoristiti kao izvor u ETL procesu.
Zahtjevi:
Sale detail – Sale detail object odgovor, koji sadrži osnovne podatke o
rasprodaji i listu proizvoda na rasprodaji
Product details - Product detail object, koji sadrži osnovne podatke o proizvodu
i listu slika koje opisuju proizvod te dodatne kompleksnije atribute.
U Tabela 1 Objekti koje sadrži Sale detail objekt nalazi se opis atributa jednog objekta Sale
detail.
Naziv Tip Opis
Name String Prodajno ime
Sale String URL koji ukazuje na tu rasprodaju
sale_key String Jedinstveni ključ za rasprodaju
71
Store String Ključ pod kojim je pohranjena rasprodaja
Description String Opis rasprodaje brenda ili teme
sale_url String Link za posjet stranici rasprodaje
Begins String ISO8601 – vremenski format početka rasprodaje
Ends String ISO-8601 – vremenski format kraja raspordaje
image_urls Object
objekti koji sadrže objekte slike. Objekti slike se sastoje
od tri atributa:
o url
o width
o height
URL atribut sadrži sliku vezanu za rasprodaju.
Dok width i height opisuju tu sliku.
Products String[] Lista koja sadrži objekte product detail. To su proizvodi
koji se nalaze na raspordaji.
Tabela 1 Objekti koje sadrži Sale detail objekt
Zapis 5 Primjer Sale detail objekta (GILT GROUPE, 2014) sadrži primjer objekta Sale detail.
Sale detail u sebi sadrži listu u atributu products koja sadrži veze svih proizvoda na akciji.
Slanjem zahtjeva na te veze dolaze nam odgovori u JSON zapisu koji sadrže Product details
objekte.
{ "name": "Winter Weather", "sale":"https://api.gilt.com/v1/sales/men/winter-weather48/detail.json", "sale_key": "winter-weather-48", "store": "men", "description": "Get out of the cold and into these great blah blahblah", "sale_url": "http://www.gilt.com/sale/men/winter-weather-48", "begins": "2012-02-04T17:00:00Z", "ends": "2012-02-07T17:00:00Z", "image_urls": { "91x121": [{ "url": "...", "width": 91, "height": 121 }] }, "products":["https://api.gilt.com/v1/products/124344157/detail.json",
"https://api.gilt.com/v1/products/121737201/detail.json"] }
72
Zapis 5 Primjer Sale detail objekta (GILT GROUPE, 2014)
Zapis 6 Primjer Product detail objekta sadrži primjer izgleda poruke u JSON zapisu
koja sadrži Product detail objekt. Struktura Product detail objekta je definirana u Tabela 2
Objekti koje sadrži Product detail objekt.
Naziv Tip Opis
Name String Naziv proizvoda
Product String URL proizvoda
Id String Jedinstveni identifikator proizvoda
Brand String Naziv brenda
url String URL do stranice gdje je moguće kupiti proizvod
Brand String Naziv brenda
image_urls Object Objekti koji sadrže objekte slike. Objekti slike se sastoje od tri
atributa:
o url
o width
o height
URL atribut sadrži sliku vezanu za rasprodaju. Dok width i
height opisuju tu sliku.
Skus Object Skus objekt
Categories String[] Lista kategorija kojem proizvod pripada
Content Object Objekt u kojem se nalazi sadržaj proizvoda
Tabela 2 Objekti koje sadrži Product detail objekt
73
U Zapis 6 Primjer Product detail objekta unutar objekta se osim primitivnih objekata
nalaze i kompleksni ugniježđeni objekti: Product content i SKU. Tabela 3 Objekti koje sadrži
objekt Product content i opisuju atribute tih dvaju objekata.
Zapis 6 Primjer Product detail objekta
{
"name": "Fake Product",
"product": "https://api.gilt.com/v1/products/1268792864/detail.json",
"brand": "Fake Corp",
"content": {
"description": "...",
"material": "Stainless steel and plastic",
"origin": "China"
},
"image_urls": {
"91x121": [{
"url": "...",
"width": 91,
"height": 121
}, {
"url": "...",
"width": 91,
"height": 121
}]
},
"skus": [{
"id": 1445982,
"inventory_status": "sold out",
"msrp_price": "449.00",
"sale_price": "340.00",
"attributes": [{
"name": "color",
"value": "choc brown"
}]
}]
}
74
Naziv Tip Opis
Description String Opis proizvoda
fit_notes String Informacija o veličini
Material String Materijal izrade
care_instructions String Dodatne informacije o konstrukciji
Origin String Mjesto proizvodnje
Tabela 3 Objekti koje sadrži objekt Product content
Odredišta će biti izrađena u bazi podataka u MySQL sustavu. Baza podataka Gilt sadrži
tablice:
SKU
Sale
Product content
Product
Images
Field Type Description
id Integer SKU jedinstveni identifikator
inventory_status String Opisuje dostupnost proizvoda vrijednosti:
prodan, dostupan, rezerviran.
msrp_price String Preporučena cijena proizvoda
sale_price String Prodajna cijena proizvoda
shipping_surcharge String Cijena sufinanciranja troškova dostave
Attributes Object Objekt koji sadrži atribute proizvoda:
veličina, boja itd.
Tabela 4 Objekti koji su sadržanu u objektu SKU objects
75
8.7.3. Mapiranje
U prototipu alata izvršit će se izrada mapiranja dolazećih JSON objekata. Product
details objekti dolaze iz jedne vrste izvora, dok Sale details dolazi iz druge vrste izvora. Tako
će biti potrebno izraditi dvije vrste mapiranja. Mapiranje Sale details u tablicu Sale će biti
jednostavno jer se atribut sastoji od primitivnih objekata. Drugo mapiranje je iz objekta
Product detail u tablice Product, Images, Contetn i SKU. To će mapiranje prikazati
funkcionalnost prototipa alata.
Izradit će se datoteka koja sadrži listu objekata koji su dobiveni prilikom upita na Gilt
REST servis.
Slika 30 Izgled JSON objekta Product details
Prototipu aplikacije zadano je da nauči kako izgleda cjelokupni izgled JSON objekta
Product details. Alat je prepoznao da se objekt Product details sastoji od nekolicine
primitivnih objekata i tri kompleksna objekta. Također, alat je prepoznao pojedine primitivne
76
objekte u kompleksnim objektima. Parametri su postavljeni tako da alat uči iz prvih 5
objekata. Slika 30 Izgled JSON objekta Product je prikaz strukture objekta u prototipu alata.
Slika 31 Povezivanje pojedinog primitivnog objekta i atributa u tablici product
Slika 31 Povezivanje pojedinog primitivnog objekta i atributa u tablici product prikazuje
povezivanje primitivnih objekata objekta Product i atributa u tablici product.
Slika 32 Povezivanje pojedinog primitivnog objekta i atributa u tablici content prikazuje
povezivanje primitivnih objekata objekta content i atributa relacijske tablice contant.
Slika 32 Povezivanje pojedinog primitivnog objekta i atributa u tablici content
Slika 33 Povezivanje pojedinog primitivnog objekta od objekta Skus i atributa u tablici
Skus prikazuje mapiranje objekta Skus.
77
Slika 33 Povezivanje pojedinog primitivnog objekta od objekta Skus i atributa u tablici Skus
Slika 34 Agregiranje objekta categories
Slika 34 Agregiranje objekta categories prikazuje grafičko sučelje koje omogućuje
razvijatelju da definira način sumiranja polja s primitivnim objektima.
78
8.7.4. Izvršavanje
Nakon uspješnog izvršavanja možemo vidjeti popunjene tablice u bazi input. Izrada
mapiranja nije dugo trajala. Slika 35 Tablica SKUS u relacijskoj bazi Slika 36 Tablica product
u relacijskoj bazi Slika 37 Tablica content u relacijskoj bazi prikazuju izrađene tablice u
relacijskoj bazi sustavu MySQL.
Slika 35 Tablica SKUS u relacijskoj bazi
Slika 36 Tablica product u relacijskoj bazi
Slika 37 Tablica content u relacijskoj bazi
Slika 38 Tablica sale u relacijskoj bazi
79
Potrebana je bila samo osoba koji definira koji primitivni objekti iz izvora prelaze u
atribute u odredište, tj. pojedine tablice.
Slika 39 Podaci sadržani u tablici Skus
Slika 39 Podaci sadržani u tablici Skus prikazuju ispis sadržaja tablice Skus nakon pokretanja
procesa u prototipu alata.
Slika 40 Podaci u tablici product
80
Slika 40 Podaci u tablici product prikazuje sadržaj tablice product nakon izvršenog
procesa u prototipa alata.
Slika 41 Sadržaj tablice sale
Slika 41 Sadržaj tablice sale prikazuje sve što se nalazi u tablici sale nakon što je
proveden izrađeni proces.
Ovim primjerom mapiranja i izvršavanja izrađenih mapiranja prikazane su
funkcionalnosti prototipa ETL alata za obradu polustrukturiranih izvora podataka.
Polustrukturirani izvor podataka koji prototip ETL alata obrađuje mora biti zapisan u JSON
formatu.
81
9. Zaključak
Sve je više izvora gdje se generiraju podaci u JSON zapisu. Najviše se podataka u
JSON zapisu generira prilikom povezivanja raznih servisa.. Također, komunikacija između
klijentskih aplikacija i servisa provodi se sa podacima zapisanim u JSON formatu. Kako bi se
moglo izvući više znanja iz podataka, potrebno je pohranjivati sve podatke koji se generiraju.
Tijekom istraživanja uočene su dva moguća rješenja obrade i pohrane podatka u JSON
zapisu: obrađivanje zapisa nakon pohranivanja u Hadoop sustav i tradicionalan način za
iščitavanje JSON zapisa.
Pohranjivanje JSON zapisa nakon korištenja, odnosno nakon pohrane i obrađivanja
zapisa. Također, podaci mogu ostati zapisani u izvornom obliku i obrađivati se netom prije
korištenja. Za pohranu neobrađenih JSON zapisa pogodan je Hadoop sustav. Hadoop sustav
može zapisivati bilo kakav tip podatka. Tipovi podataka mogu biti kompleksni ili primitivni.
Hadoop sustav je sa svojim mapReduce modulom pogodan i za brzu obradu podataka
prilikom samoga upita. Iako je postupak izrade dugotrajniji, on je brži prilikom procesiranja.
Model izrađen u mapReduce paradigmi je savršen za obradu JSON zapisa.
Drugo pronađeno rješenje je tradicionalan način obrade podataka. Kod tradicionalnog
načina rješavanja bio je potreban način kako efikasno iščitavati JSON zapis te procesirati tako
da se daljnja obrada može izvršiti u razvijenim ETL alatima. Testiranjem i istraživanjem
mogućnosti tehnologija pronađen je idealan koncept rješenja. Koncept rješenja sastoji se u
tome da se pronađe struktura JSON zapisa tako se prolazi kroz više istovjetnih objekata. To je
potreban korak kako bi se dobio cjeloviti sadržaj pojedinog objekta. Neki objekti se mogu i ne
moraju pojavljivati u pojedinom JSON objektu. Rješenje je prilagođeno tako da postupak
mapiranja objekta u pojedine tokove izvršava osoba koja razvija integraciju podataka ETL-a
preko grafičkog sučelja. Na taj način odvojio se posao na dva stručnjaka, programera i osobe
koja razvija integraciju podataka u grafičkom alatu.
Trenutačno je više zastupljen tradicionalan način obrade podataka, stoga je u sklopu
rada izrađen prototip aplikacije koja simulira ETL sustav. Trenutno stanje zahtijeva ovakvu
vrstu aplikacije. Trend je takav da će se u narednih nekoliko godina sve više početi prelaziti
na Big Data rješenja. Svaka veća kompanija u IT-u (Twitter, Facebook, Google, Amazon)
82
pridonosi razvoju Big Data konceptima zbog ograničenja na koja su naišli u korištenju
relacijskih baza podataka i načina obrade podataka.
83
10. Literatura
[1] Alma, P. (16. 8 2013). THE PRAGMATIC INTEGRATOR. Preuzeto 22. 8 2014 iz
Writing a Hadoop MapReduce task in Java:
http://pragmaticintegrator.wordpress.com/2013/08/16/writing-a-hadoop-mapreduce-
task-in-java/
[2] Davenport, R. J. (6 2008). ETL vs ELT A Subjective View. Commercial Aspects of
BI.
[3] Deborah Nolan, Duncan Temple Lang. (2014). XML and Web Technologies for Data
Sciences with R. New York: Springer.
[4] dev.twitter.com. (n.d.). Preuzeto 23. 08 2014 iz Twitter Developers:
https://dev.twitter.com/
[5] Donald Miner, Adam Shook. (2012). MapReduce Design Patterns. Sebastopol:
O’Reilly Media.
[6] ECMA. (n.d.). Introducing JSON. Preuzeto 17. 08 2014 iz http://json.org/example
[7] F. Galiegue , Kris Zyp , Gary Court. (2013). JSON Schema: core definitions and
terminology. Palo Alto: Internet Engineering Task Force.
[8] Fourny, G. (2014). JSONiq The SQL of NoSQL.
[9] George, L. (2011). HBase The Definitive Guide. O'Reilly Media.
[10] GILT GROUPE, I. (2014). DevGilt . Preuzeto 25. 08 2014 iz Data Structures:
https://dev.gilt.com/documentation/data_structures.html#image_url_objects
[11] Hill, D. T. (6. 27 2012). The Big Data Revolution And How to Extract Value from Big
Data. str. 16.
[12] Holmes, A. (2012). Hadoop in Practice. New York: Manning Publications Co.
[13] Informatica. (2014). Module 1: PowerCenter Overvie. San Francisco: Informatica.
84
[14] Inmon, W. H. (2005). Building the Data Warehouse, Fourth Edition. Indianapolis:
Wiley Publishing, Inc.
[15] Jaya Singh, Ajay Rana. (2013). Exploring the Big Data Spectrum. International
Journal of Emerging Technology and Advanced Engineering, 73.
[16] Json Schema. (2013). Preuzeto 20. 08 2014 iz http://json-schema.org/: http://json-
schema.org/examples.html
[17] Li, D. S. (24. 5 2010). Working on JSON objects in jQuery and MVC. Preuzeto 20. 8
2014 iz Code Project: http://www.codeproject.com/Articles/124541/Working-on-
JSON-objects-in-jQuery-and-MVC
[18] MapReduce Introduction . (2012). Preuzeto 20. 08 2014 iz http://www.cs.uml.edu/:
http://www.cs.uml.edu/~jlu1/doc/source/report/MapReduce.html
[19] Michalewicz ,Schmidt,Constantin,. (2007). Adaptive Business Intelligence. Berlin:
Springer.
[20] Negash, S. (2004). BUSINESS INTELLIGENCE. Communications of the Association
for Information Systems, 177.
[21] Olson, J. E. (2003). Data Quality The Accuracy Dimension. San Francisco: Morgan
Kaufmann Publishers.
[22] Oracle. (2013). Oracle Retail Data Model Implementation and Operations Guide.
Preuzeto 21. 8 2014 iz ETL Implementation and Customization:
http://docs.oracle.com/cd/E11882_01/doc.112/e20363/etlmap.htm#RBIOG228
[23] Panos Vassiliadis, Christoph Quix, Yannis Vassiliou, Matthias Jarke. (2001). Data
warehouse process management. Information Systems, 236.
[24] Rabuzin, K. (13. 5 2013). Data Warehouses and Business Intelligence Used for Exam
Analysis. Research Notes in Information Science (RNIS), 13, 5.
[25] Ralph Kimball, J. C. (2004). The Data Warehouse ETL Toolkint. Indianapolis: Wiley
Publishing, Inc.
[26] Ralph Kimball, Margy Ross. (2002). The Data Warehouse Toolkit Second Edition:
The Complete Guide to Dimensional Modeling. Toronto: Wiley Computer Publishing.
85
[27] Rathbone, M. (9. 2 2013). http://blog.matthewrathbone.com/. Preuzeto 20. 08 2014 iz
Real World Hadoop - Implementing a Left Outer Join in Map Reduce:
http://blog.matthewrathbone.com/2013/02/09/real-world-hadoop-implementing-a-left-
outer-join-in-hadoop-map-reduce.html
[28] T. Bray, E. (2013). The JavaScript Object Notation (JSON) Data Interchange Format.
Preuzeto 17. 08 2014 iz IETF Tools: http://tools.ietf.org/html/rfc7159
[29] Tim Bray, Jean Paoli,C. M. Sperberg-McQueen,Eve Male,François Yergeau. (16. 8
2006). W3C. Preuzeto 18. 8 2014 iz w3pdf:
http://www.w3pdf.com/W3cSpec/XML/2/REC-xml11-20060816.pdf
[30] Turck, M. (23. 10 2012). On Grid Ventures. Preuzeto 10. 7 2014 iz
http://www.ongridventures.com/: http://www.ongridventures.com/wp-
content/uploads/2012/10/Big-Data-Landscape1.jpg
[31] W3C. (1999). w3schools. Preuzeto 18. 8 2014 iz W3Schools.com:
http://www.w3schools.com/xml/xml_validator.asp
[32] White, T. (2012). Hadoop : the definitive guide. Beijing,
Cambridge,Farnham,Koln,Sebastopol,Tokyo: O'Reilly.