SVEUČILIŠTE U ZAGREBU FAKULTET ORGANIZACIJE I INFORMATIKE VARAŽDIN 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 VARAŽDIN 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. 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 I 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 II 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 III 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 IV 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 V 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 VI 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 VII 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 VIII 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 1 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. 2 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 3 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. 4 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, 5 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. 6 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, 7 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. 8 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 9 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. 10 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 11 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. 12 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. 13 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. 14 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. 15 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. 16 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. 17 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 18 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. 19 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 20 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. 21 Slika 11 Left outer join funkcija izvedena mapReduce modelom (Rathbone, 2013) 22 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, semistructured 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) 23 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. 24 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. 25 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 26 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 27 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 28 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 29 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 30 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) 31 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. 32 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. 33 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. 34 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 35 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. <?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> 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 36 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 "GlossSeeAlso": je objekt čija je vrijednost polje primitivnih tipova tekst (eng. String). 5.3.1.3. Primitivni tipovi 37 Primitivni tipovi su tekst ili niz znakova (eng. String), brojevi (eng. Number), null, ili Boolean vrijednosti. Niz znakova stavlja se pod dvostruke navodnike. { "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" } } } } } 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. 38 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. { "title": "Example Schema", "type": "object", "properties": { "firstName": { "type": "string" }, "lastName": { "type": "string" }, "age": { "description": "Age in years", "type": "integer", "minimum": 0 } }, "required": ["firstName", "lastName"] } 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 39 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. { "title": "root", "otherSchema": { "title": "nested", "anotherSchema": { "title": "alsoNested" } } } 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. 40 ({ "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. for $question in collection("faqs"), $answer in collection("answers") [ $$.question_id eq $question.question_id ] return { "question" : $question.title, "answer score" : $answer.score } 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. 41 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.“ 42 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 43 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. 44 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 45 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č. 46 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 47 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. 48 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, 49 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. 50 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 51 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 Hadoopcore. 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. 52 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); } } } 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. 53 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); } } 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. 54 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 55 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. 56 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 57 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. 58 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 59 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. 60 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 61 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. 62 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; } 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. 63 } 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()); 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. } 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()); } 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 64 provjerava sadržava li trenutni složeni ili primitivni JSON objekt; ukoliko nije sadržan, funkcija dodaje taj objekt u izrađeni model. } 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()) { 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. 65 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 { } } 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. 66 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 67 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. 68 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. 69 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 70 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"] } 71 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 72 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. { "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" }] }] } Zapis 6 Primjer Product detail objekta 73 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 74 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 75 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. 76 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. 77 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 78 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 79 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. 80 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) 81 pridonosi razvoju Big Data konceptima zbog ograničenja na koja su naišli u korištenju relacijskih baza podataka i načina obrade podataka. 82 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-mapreducetask-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. 83 [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://jsonschema.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-onJSON-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. 84 [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-leftouter-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/wpcontent/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. 85
© Copyright 2024 Paperzz