UPORABNA INFORMATIKA 26 2023 - πtevilka 1 - letnik XXXI Pregled in analiza tehnoloških skladov za implementacijo sodobnih IT -arhitektur velepodatkov Martina Šestak, Muhamed T urkanović Fakulteta za elektrotehniko, računalništvo in informatiko, Univerza v Mariboru martina.sestak@um.si, muhamed.turkanovic@um.si Izvleček Dandanes se pri implementaciji sodobnih IT -arhitektur velepodatkov podjetja odločajo za uporabo različnih tehnoloških skladov , ki so bodisi odprtokodni bodisi takšni, ki jih na trgu ponujajo oblačni ponudniki, kot so Google, Microsoft, Amazon idr . Na izbiro določene- ga sklada vpliva nekaj različnih dejavnikov , pogosto pa se najpomembnejši izkažejo človeški viri in strošek uporabe posameznega sklada. Kot alternativa se za zmanjšanje stroškov lahko uporabijo odprtokodne tehnologije, kot je sklad Apache, vendar tudi to pri- naša določene implikacije in kompromise. Sodobne arhitekture velepodatkov pa včasih vključujejo ločeni ravni za shrambo in analitiko, pri čemer se na vsaki ravni uporablja različna tehnološka rešitev (tudi znotraj posamezne ravni), a vse z namenom shranjevanja različno strukturiranih oz. nestrukturiranih podatkov in učinkovite analize le-teh. V članku predstavljamo primer dvostopenjske IT- -arhitekture, optimizirane za hrambo in analizo velepodatkov . Prav tako prikazujemo orodja in rešitve znotraj izbranih treh tehnoloških skladov (Google, Amazon, Apache), s katerimi se lahko implementira omenjena arhitektura. Analiziramo lastnosti posameznih skla- dov ter podajamo povzetek prednosti in izzivov pri uporabi določenega sklada. Ključne besede: IT -arhitektura, velepodatki, masovni podatki, podatkovno skladišče, podatkovne baze, širokostolpčne hrambe, tehno- loški sklad ST A TE-OF-THE-ART ANAL YSIS OF TECHNOLOGY ST ACKS FOR THE IMPLEMENT A TION OF MODERN BIG DA T A ARCHITECTURES Abstract Every individual and company perceives the dimensions of big data a bit differently . Big data is not measured as 5 hard drives nor as 5 data barrels, neither is flow of data measured in litres. Big data is a mindset that forms the foundation for data-driven busi- ness. For mass data to be truly introduced to and used in business, one must first understand it. Only then can we expect business and technology to co-exist and deliver added value. In this article, I present all dimensions of big data (i.e., 5 V’ s) and shed light on its use in practical examples. I also present the broader ecosystem of big data and the foundations for building an environment for big data. Keywords: IT architecture, big data, data warehouse, database, wide-column databases, technology stack 1 UVOD Pojem velepodatkov ali masovnih podatkov, ki se že nekaj časa uporablja kot ena ključnih besed v domeni podatkovnih tehnologij, je v zadnjem desetletju po- spešil razvoj novih tehnoloških rešitev za učinkovi- to upravljanje naraščajočih količin podatkov, ki na- slavljajo izzive, kot so razširljivost, količina, hitrost, različnost in drugo. Po trenutnih statistikah se vsak dan proizvede približno 2,5 kvintiljona (1018) bajtov podatkov, sama industrija velepodatkov pa zadnjih nekaj let vedno bolj narašča in je trenutno vredna re- kordnih 274 milijard ameriških dolarjev [10]. Slednje STROKOVNI PRISPEVKI UPORABNA INFORMATIKA 27 2023 - πtevilka 1 - letnik XXXI številke potrjujejo, da morajo podjetja neprekinjeno vlagati v sodobne tehnološke rešitve, ki jim lahko olajšajo spopadanje z izzivi v obdobju velepodatkov. Obenem pa se podjetja, ki v vsakdanjem poslo- vanju obravnavajo veliko količino podatkov, pogosto srečajo s potrebo po prilagoditvi obstoječih informa- cijskih sistemov in integracijo novih rešitev z le-temi. Pri tem se večina finančnih sredstev uporablja za na- men transformacije obstoječih informacijskih rešitev ob upoštevanju sodobnih pristopov v načrtovanju IT-arhitektur IKT-sistemov. Sodobne zahteve namreč določajo, da podatke generirajo različni elementi IKT-rešitve oz. sistema, kar pomeni, da v takšnih sis- temih hitro nastopi beleženje velikih količin podat- kov, da se ti generirajo z veliko hitrostjo in s strani različnih virov ter da so podatki vedno bolj nestruk- turirane oblike. Slednje so obstajale tudi prej, vendar v manjših količinah, a jih nismo znali obdelati oz. po njih poizvedovati, kar pa se korenito spreminja z ve- dno večjim prodorom tehnik umetne inteligence. Kot največji izziv pri vpeljavi sodobnih tehno- loških rešitev za upravljanje velepodatkov podjetja izpostavljajo dodeljena finančna sredstva za takšne projekte ter tehnične izzive pri integraciji z obstoje- čo infrastrukturo podjetja [10]. Ne moremo pa tudi zanemariti kompleksnosti vedno bolj pomembnega področja podatkovnega inženirstva (angl. data en- gineering), ki je tesno povezano s področjem podat- kovne znanosti (angl. data science). S tema podro- čjema so povezani tudi trije profili strokovnjakov, in sicer podatkovni inženir ter podatkovni znanstvenik in podatkovni analitik. Slednja izvajata aktivnosti, ki so neposredno povezane z metodami umetne inteli- gence, strojnega učenja, podatkovnega rudarjenja oz. s področjem poročanja in vizualizacije. V primerjavi s tem pa je naloga podatkovnega inženirja gradnja in vzdrževanje logičnih in fizičnih podatkovnih mo- delov ter s tem povezanih podatkovnih cevovodov. Osredotočajo se na celovito IT-arhitekturo za upra- vljanje velepodatkov, kakor tudi s tem povezano pre- oblikovanje, migriranje in združevanje podatkov ter zagotavljanje kakovosti podatkov. Za zagotavljanje ustreznega in učinkovitega upra- vljanja velepodatkov je treba oblikovati celotni podat- kovni cevovod (en ali več) ter opredeliti posamezne rešitve kot elemente le-tega. Ta korak predstavlja vča- sih izziv celo za strokovnjake, saj je težko izbrati reši- tve, ki bodo med seboj ujemajoče in bodo v celoti za- jemale zahteve uporabnikov. Dodaten izziv je izbira ene rešitve med številnimi možnostmi, ki so na voljo na trgu za določen namen (npr. za zajem podatkov). Večja tehnološka podjetja so razvijala rešitve, s kate- rimi so želela rešiti specifične izzive velepodatkov, s katerimi se srečujejo. Takšen pristop je predstavljal veliko različnih tehnologij in orodij na trgu, pri čemer so razlike med njimi v najmanjši meri oz. jih ni možno ločiti brez podrobne analize rešitev. Posledično izbira tehnološkega sklada pri projektu implementacije ar- hitekture za upravljanje velepodatkov ni odvisna le od stroškov implementacije, temveč tudi od drugih dejavnikov, kot so potreba po realnočasovni obdela- vi, enostavnost integracije z obstoječimi IKT-rešitva- mi v podjetju, način interakcije s sistemom, časovna zahtevnost vzpostavitve cevovoda itn. V nadaljevanju bomo predstavili osnovne izzive sistemov za upravljanje velepodatkov ter način na- slavljanja teh izzivov sodobne arhitekture. Poglobili se bomo v lastnosti rešitev znotraj tehnoloških skla- dov, ki jih v sklopu svojih oblačnih storitev ponujajo podjetja Google in Amazon ter odprtokodne alterna- tivne rešitve znotraj sklada Apache. Podrobna anali- za zmogljivosti izbranih tehnoloških skladov lahko pomaga pri izbiri določenega tehnološkega sklada za implementacijo na praktičnih primerih. 2 ZAHTEVE IN IZZIVI SISTEMOV ZA UPRA VLJANJE VELEPODA TKOV Sodobni sistemi za upravljanje velepodatkov se sre- čajo s številnimi izzivi pri zagotavljanju funkcional- nosti, ki jih zahteva določena domena uporabe. Ena izmed od funkcionalnosti je zagotavljanje sledljivosti vsakega podatkovnega toka [9], in sicer beleženje vsake spremembe nad posameznim podatkovnim zapisom v toku (tj. pogosto v dnevniške datoteke). S tem se pridobi večji nadzor nad podatki, ki teče- jo v sistemu in omogoči transparentnost celotnega cevovoda. Kot največji izziv v obdobju velepodatkov se ve- dno omenjata varnost in kakovost podatkov [3, 28], za kateri je pomembno vzpostaviti ustrezne meha- nizme za upravljanje podatkov v sistemu (angl. data governance), kar npr. vključuje nadzor nad uporabo podatkov (tj. kdo, kaj, kdaj, kje in za kateri namen uporablja določeni podatkovni zapis). Varnost in za- sebnost podatkov sta kot izziv izpostavljeni tudi v [1], kjer so avtorji predstavili pregled najbolj pogosto omenjenih izzivov v literaturi. Med drugim je var- nost podatkov kot večji izziv omenjena v 78 % štu- Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 28 2023 - πtevilka 1 - letnik XXXI dij. Pri tem se s stališča kakovosti podatkov pogosto pojavljajo težave z nekonsistentnostjo podatkov med različnimi komponentami sistema. S stališča IT-arhi- tekture pa predstavlja večji izziv pravočasnost (angl. timeliness) oz. pravočasno dostopni podatki v dolo- čenem koraku cevovoda, ko so ti pričakovani in nuj- ni. Slednje pomeni, da morajo sistemi zagotoviti zelo majhne zakasnitve v vsakem koraku podatkovnega cevovoda, sploh v primeru visokotveganih sistemov (npr. vgrajeni sistemi v avtomobilih). Naslednji večji izziv v kontekstu sodobnih siste- mov velepodatkov je deljenje podatkov, sploh med različnimi oddelki znotraj podjetja. V današnjem okolju več oddelkov znotraj podjetja želi dostopati do iste množice podatkov, ki pa so shranjeni zunaj njihovih IKT-rešitev. V takšnem primeru nastajajo t. i. podatkovni silosi (angl. data silos), kjer ima vsak oddelek svoj interni sistem, ki beleži podatke le ’lo- kalno’, pri čemer se postopek, da se dostop do teh podatkov omogoči tudi zunanjim IKT-rešitvam, lah- ko močno zaplete. Zaradi tega so zaželene bolj de- centralizirane arhitekture, kot je t. i. arhitektura data mesh. V vsakem primeru je treba vzpostaviti učinko- vite varnostne mehanizme za nadzor nad deljenjem podatkov, ki jih določajo različne politike, opredelje- ne kot del upravljanja podatkov. Za učinkovito deljenje podatkov je treba imeti v mislih tudi optimalno načrtovanje IT-arhitekture glede na potencialna težišča podatkov (angl. data centers of gravity). Težišča podatkov so točke v siste- mu, kjer pričakujemo shranjevanje velikih količin po- datkov, ki se pozneje premestijo v drugi del sistema (npr. v rešitev za podatkovno analitiko), pri čemer postopek migracije lahko močno vpliva na učinko- vitost sistema. Da bi se temu izognili, morajo podat- kovni arhitekti pri načrtovanju IT-arhitekture imeti v mislih takšne potencialne točke in oblikovati IT-ar- hitekturo na način, da je takšnih točk v sistemu čim manj ter da je učinek težnosti podatkov (angl. data gravity) čim manjši. V zvezi s tem se težave pojavlja- jo tudi zaradi porazdeljenosti okolja oz. podatkov v sistemu [32]. V določenem trenutku je namreč pod- množica podatkov, ki je nujna za izvedbo določene analize, lahko na enem vozlišču v gruči, medtem ko je drugi podnabor na drugem vozlišču. Težava pa nastane, ko je treba v koraku analize uporabiti oba nabora, ki sta logično in velikokrat tudi fizično shra- njena na različnih lokacijah v gruči oz. sistemu, in je treba izvesti migracijo potencialno velikih količin po- datkov, ne da bi se občutno zmanjšala učinkovitost drugih komponent sistema. Pri razvoju sistemov za upravljanje velepodatkov se IT-arhitekti in inženirji srečajo s številnimi prak- tičnimi izzivi, ki nastajajo zaradi lastnosti velepodat- kov in hitrega razvoja področja [11]. Eden od izzivov je seveda skaliranje IT-arhitekture, kjer se predvsem usmerimo v horizontalno razširljivost (angl. scale- -out). Tukaj nastane izziv, kako določiti optimalno razmerje med kakovostjo podatkov in učinkovitostjo oz. dostopnostjo sistema. Takšna zahteva izhaja tudi iz izbire dveh od treh možnih lastnosti porazdeljenih sistemov, ki ju po teoremu CAP 1 lahko naenkrat za- gotovimo. Izbira boljše kakovosti podatkov v siste- mu ali učinkovitosti sistema je stvar kompromisa in je zelo odvisna od domenskih zahtev. Naloga IT-ar- hitektov je načrtovati sistem na način, da poskusijo zagotoviti čim manjše zamude in večjo prepustnost sistema, hkrati pa v določeni meri obdržati konsi- stentnost podatkov, kolikor je to le možno. Novost področja in nenehno uvajanje novih konceptov, ar- hitektur in tehnoloških rešitev vpliva na strmo nara- ščajočo krivuljo učenja pri strokovnjakih, saj je vedno zahtevnejše slediti novostim in najboljšim praksam na področju, tehnološke rešitve pa so vedno bolj za- pletene za učenje in implementacijo. Sodobni sistemi morajo biti zmožni zajemati po- datke iz več različnih virov. V tem procesu za inte- gracijo podatkov težave lahko povzroča manjkajoča ustrezna infrastruktura, kar je posebej pomembno v okoljih z različnimi viri podatkov. Slaba implemen- tacija na ravni zajema podatkov predstavlja napačne rezultate analize teh podatkov oz. napačne poslovne odločitve. Hkrati je treba poudariti izziv, da se pri sodobnih IKT-rešitvah, ki so označene kot sistemi velepodatkov, srečujemo tudi z različnimi vrstami podatkov oz. z vedno več pol in nestrukturiranimi podatki (npr. dnevniški zapisi, slike, avdio-video za- pisi, prost govor itn.). Nedavno smo se na področju IKT osredotočali zgolj na strukturirane podatke in načine, kako te učinkovito hraniti z uporabo relacij- skih modelov ter kako te uporabiti za namen podat- kovne analitike, pri čemer smo se kot na orodje za 1 Teorem CAP (angl. Consistency, Availability, Partition tolerance) pravi, da lahko vsak porazdeljen sistem istočasno zagotavlja le dve od treh možnih lastnosti: celovitost oz. konsistentnost podatkov, razpoložljivost oz. dostopnost sistema ter odpornost sistema na particioniranje. Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 29 2023 - πtevilka 1 - letnik XXXI izvedbo analitike osredotočali na poizvedovalne jezi- ke, kot so SQL, ki so idealni za strukturirane podat- ke. Nestrukturirane podatke smo rahlo zanemarjali, saj jih nismo znali primerno in učinkovito uporabiti za odkrivanje novih spoznanj. Danes imamo željo in potrebo po tem, da hranimo tudi nestrukturirane po- datke, nad katerimi izvajamo podatkovno analitiko, in sicer s pomočjo tehnik podatkovnega rudarjenja, strojnega in globokega učenja itn. Hkrati smo te po- datke in to vrsto podatkovne analitike, ki še zmeraj spada pod t. i. OLAP , izvajali zgolj ad-hoc, danes pa so težnje, da se ti podatki in ta vrsta analitike vključi v produkcijske sisteme, ki so povezani s t. i. transak- cijsko obdelavo (tj. OLTP). To področje se danes hitro razvija in spada tudi pod t. i. inženiring UI (angl. AI engineering). IT-arhitekti so tako pred kompleksnim izzivom podatkovnega inženirstva, ki je zagotavljati učinkovito podatkovno raven za produkcijske sis- teme, večinoma strukturirane podatke in OLTP , ki zahtevajo visoko razširljivost, ter hkrati učinkovito podatkovno raven za analitične procese, nestrukturi- rane podatke in OLAP , kjer pa se velikokrat srečuje- mo z masovnimi podatki. Povrh vsega pa se pojavlja težnja za IT-arhitekturo, ki bo omogočala hkratno in učinkovito obdelavo OLTP ter OLAP nad enotno po- datkovno ravnjo. Med trenutnimi izzivi podatkovnega inženirstva so tudi zahteve sodobnih IKT-rešitev in storitev, ki se navezujejo na realnočasovno obdelavo podatkov. Za doseganje ciljev takšnih zahtev se pojavljajo temu primerne podatkovne platforme, kot so platforme sporočilnih sistemov in pretakanja podatkov (npr. Apache Kafka). S tem povezano se tudi pojavljajo vnaprej definirani arhitekturni vzorci, kot sta Lamb- da in Kappa, ki se osredotočata zgolj na učinkovito obdelavo podatkovnih tokov in pretakanje podatkov [29]. Ker je to precej specifično področje, ki velja zgolj za poslovne primere, kjer je dejanska potreba po re- alnočasovnem odzivanju na dogodke, se v tem član- ku na to področje (vele-)podatkovnega inženirstva ne osredotočamo. Ne nazadnje se sodobni sistemi kot IKT-rešitve srečujejo tudi z nezanemarljivimi stroški vzpostavi- tve infrastrukture s stališča strojne in programske opreme ter stroški vzdrževanja in človeških virov, saj znajo biti ti zelo visoki ne glede na uporabo oblačne ali lastne infrastrukture (angl. on premise). Takšne sisteme je težko ustrezno nadzorovati, saj je veliko različnih aktivnih komponent v sistemu, nad kateri- mi je treba v vsakem trenutku imeti popoln nadzor zaradi hitrega odkrivanja okvar v sistemu [11]. 3 SODOBNE ARHITEKTURE ZA UPRA VLJANJE VELEPODA TKOV Celovito upravljanje velepodatkov dosežemo z IT- -arhitekturo sistema, ki opredeli rešitve in postopke na ravneh zajemanja, shranjevanja, obdelave, vizua- lizacije in analize velikih količin (potencialno) kom- pleksnih podatkov [27]. Največja izziva predstavljata zagotavljanje učinkovitega shranjevanja in obdelave velepodatkov, saj zaradi slabega načrtovanja IT-arhi- tektur nastanejo nemalokrat ozka grla, ki nato vpli- vajo na celotno učinkovitost sistema. Strokovnjaki si pri načrtovanju podatkovnih cevovodov lahko po- magajo z določenimi smernicami posameznih IT-ar- hitektur, ki so predstavljene v nadaljevanju. Za shranjevanje podatkov se uporabljajo različne tehnologije, ki so se razvijale več let in za različne namene. Tako se za shranjevanje transakcijskih po- datkov, razen tradicionalnih relacijskih podatkov- nih baz, danes pogosto kot zamenjava ali dodatna podpora uporabljajo nerelacijske podatkovne baze (NoSQL), kot sta podatkovna baza ključ-vrednost (npr. Redis) ali dokumentna podatkovna baza (npr. MongoDB), ki rešujejo izzive razširljivosti in prila- godljivosti podatkovne sheme, s katerima se v dana- šnjem okolju srečujejo razvijalci IKT-rešitev. Zahteva večine IKT-rešitev je predvsem podpora za obdelavo OLTP 2 , pri čemer je v večini primerov cilj zagotoviti čim večjo konsistentnost podatkov. Danes imajo večja podjetja več transakcijskih po- datkovnih baz oz. podatkovnih zbirk različnih tipov, ki jih je po določenem obdobju treba združiti zaradi izvedbe statističnih analiz in napredne podatkovne analitike, ki so lahko ustrezna podlaga za prihodnje poslovne odločitve, in se podpirajo s pomočjo podro- čja poslovnega obveščanja (angl. business intelligen- ce, BI). Za ta namen je treba ustrezno shraniti zdru- žene podatke na eni lokaciji, tj. podatkovno skladišče (angl. data warehouse). Osnova podatkovnih skla- 1 Teorem CAP (angl. Consistency, Availability, Partition tolerance) pravi, da lahko vsak porazdeljen sistem istočasno zagotavlja le dve od treh možnih lastnosti: celovitost oz. konsistentnost podatkov, razpoložljivost oz. dostopnost sistema ter odpornost sistema na particioniranje. 2 OLTP (angl. Online Transactional Processing) − način obdelave podatkov kot transakcij, pri čemer se le-te v sistemu shranjujejo in uporabljajo pri obdelavi v realnem času. Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 30 2023 - πtevilka 1 - letnik XXXI dišč so dimenzijski modeli, ki so v nasprotju z rela- cijskimi modeli namenski in usmerjeni neposredno v zahteve analitike oz. poslovnega obveščanja. Pri- mer takšne arhitekture je prikazan na sliki 1. Podatki prihajajo iz več podatkovnih virov v cevovod ETL 3 , kjer se izvajajo določene transformacije in čiščenje teh v skladu s podatkovno (dimenzijsko) shemo cilj- nega podatkovnega skladišča. Prečiščeni podatki se nato shranjujejo v podatkovno skladišče, na podlagi katerega se oblikujejo t. i. kocke OLAP 4 namenjene določenim analizam nad podatki v agregirani obliki. Kocke OLAP vsebujejo podmnožico podatkov, shra- njenih v podatkovnem skladišču, in predstavljajo vir podatkov za orodja za poslovno obveščanje ali poro- čanje. Kot največja izziva pri takšni IT-arhitekturi se poudarjata implementacija učinkovitega procesa ETL in vzpostavljanje mehanizmov za upravljanje kock OLAP v skladu s spremembami pri virih podatkov. Uporabnikom je potem omogočen dostop le do agre- giranih podatkov za namene analitike, ne pa tudi iz- virnih transakcijskih podatkov. Zaradi vpliva velepodatkov vlogo podatkovnih skladišč danes prevzemajo širokostolpčne shrambe (angl. wide-column stores), kot sta HBase ali Cassan- dra, pri katerih so implementirane določene izboljša- ve za izvajanje analitike (tj. OLAP), ki pozitivno vpli- vajo na hitrost sistemov in omogočajo shranjevanje transakcijskih ter agregiranih podatkov. V zadnjem desetletju so se za shranjevanje vele- podatkov začela uporabljati tudi podatkovna jezera (angl. data lake) (slika 2), ki omogočajo shranjeva- nje masovne količine izvirnih (angl. raw) in različno strukturiranih podatkov brez vnaprej določene po- datkovne sheme. Kot osrednji repozitoriji izvirnih podatkov so podatkovna jezera primerna za izvedbo zapletenejših analiz z uporabo strojnega učenja. Po- sledično se najbolj pogosto uporabljajo za podatkov- ne znanosti, vendar podjetja kot njihovo glavno sla- bost vidijo odsotnost mehanizmov za zagotavljanje konsistentnosti podatkov, tj. podatkovna jezera ne podpirajo modela ACID kot podatkovna skladišča ali baze 5 . Pri podatkovnih jezerih je cilj čim prej shraniti podatke s pomočjo vzpostavljenega cevovoda ELT 6 cevovoda. Ob branju shranjenih podatkov se podatki transformirajo iz surove oblike (npr. objekti) v obliko, ustrezno za namen uporabe (podatkovne analitike ali strojnega učenja). Čez leta praktične uporabe se je izkazalo, da da- našnja podjetja nimajo eksplicitno ločene uporabe transakcijskih od agregiranih podatkov, zaradi česar uporaba le ene predhodno omenjenih tehnologij ne zadostuje, da bi podjetja na optimalen način hkrati za- dovoljila potrebe OLTP in OLAP pri upravljanju po- datkov. Hkrati je zaradi zahtev po visoki razširljivosti sistema edini primeren način razširjanje navzven (tj. horizontalno), kjer pa so seveda izzivi povezani s teo- remom CAP in omejitve relacijskih podatkovnih baz, ki ne podpirajo visoke razširljivosti in hkrati dosto- pnosti oz. omejitve nerelacijskih podatkovnih baz, ki ne podpirajo visoke razširljivosti in hkrati konsisten- Slika 1: Primer arhitekture z uporabo podatkovnega skladišča. 3 ETL (angl. Extract-Transform-Load) − proces zajema podatkov iz izvirnega sistema, čiščenja in transformacije prevzetih podatkov glede na ciljni (dimenzijski) podatkovni model ter uvoz pripravljenih podatkov v ciljno shrambo. 4 Kocka OLAP (angl. Online Analytical Processing cube) − podatkovna struktura, ki omogoča večdimenzijski vpogled v podatke in hitro analizo le-teh. 5 Model ACID (angl. Atomicity, Consistency, Isolation, Durability) − transakcijski model, s katerim npr. relacijske podatkovne baze zagotavljajo celovitost, konsistentnost, hkratnost in trajnost podatkov v podatkovni bazi. 6 ELT (angl. Extract-Load-Transform) − proces zbiranja in shranjevanja podatkov v podatkovno jezero, pri čemer se transformacija podatkov izvaja šele ob branju podatkov. Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 31 2023 - πtevilka 1 - letnik XXXI tnosti. Posledično se danes pogosto uporablja dvosto- penjska (angl. 2-tier) arhitektura, prikazana na sliki 3, ki vključuje podatkovno jezero in skladišče, s čimer podjetja združijo prednosti obeh tehnologij. V tem primeru se vsi vhodni (transakcijski) podatki shra- njujejo v podatkovnem jezeru, del teh pa se agregira in shrani v podatkovno skladišče za potrebe OLAP , od koder se uporabljajo za potrebe poslovnega ob- veščanja. Vmes pa so vsi podatki shranjeni v izvirni obliki v podatkovnem jezeru in jih lahko podatkovni znanstveniki kadar koli uporabijo za izvedbo zaplete- nejših algoritmov. Trenutno je dvostopenjska arhitektura priljubljena izbira podatkovnih arhitektov, saj podjetju omogoča shranjevanje različno strukturiranih podatkov v po- datkovnem jezeru, ki so uporabni v sedanjosti in pri- hodnosti. Dodatni sloj podatkovnega skladišča prina- ša podporo za obdelavo podatkov OLAP oz. omogoča izvedbo učinkovitih analiz nad agregiranimi podatki. Podatkovno skladišče se, kot že prej omenjeno, lahko zamenja tudi s širokostolpčno podatkovno bazo. Kot pogosti vzorec se pojavlja tudi vključevanje transak- cijske podatkovne baze nad jezerom, s katerimi pod- jetja lahko izboljšajo učinkovitost obstoječih podat- kovnih baz na ravni upravljanja velepodatkov in tudi pohitrijo postopek transformacije surovih podatkov iz jezera za namen podatkovne analitike. V tem primeru je podatkovna baza odložišče podatkov iz jezera, ki so vnaprej transformirani in pripravljeni za analitiko. Uporabljajo se pa tudi IT-arhitekture, kjer pa se tran- sakcijski podatki primarno shranjujejo v relacijsko po- datkovno bazo in hkrati tudi v podatkovno jezero. Čeprav so zajete zahteve z dvostopenjsko arhitek- turo, se podjetja srečujejo z določenimi slabostmi ta- kšne implementacije. Največji izziv je zapleteno upra- vljanje rešitev na obeh stopnjah, kar pomeni, da je tre- ba zagotoviti vire oz. strokovnjake, ki bodo skrbeli, da podatkovno jezero in skladišče oz. tako OLTP kot OLAP delujeta nemoteno. Največ časa pri takšni IT- -arhitekturi je treba vložiti v implementacijo zaplete- nih poslov ETL in ELT, s katerimi se morajo podatki iz podatkovnega jezera transformirati v ustrezni podat- kovni model podatkovnega skladišča [2]. Dve ravni shranjevanja pomenita, da se čas izvedbe povpraše- vanj na strani uporabnikov lahko močno podaljša, saj podatkovna jezera, kakor tudi podatkovna skladišča, imajo določeno mejo, do katere je možno izboljšati učinkovitost izvedbe povpraševanj. Da bi se izognili potencialno zapletenemu vzdr- ževanju dvostopenjske arhitekture, so se v novejšem času začela uporabljati t. i. podatkovne hiše ob jezeru ali kolišča 7 (angl. data lakehouses), katerih arhitek- tura je prikazana na sliki 4. V podatkovnih koliščih so prednosti podatkovnih jezer in skladišč združene znotraj formata oz. modela za shrambo, vendar je dodan sloj metapodatkov, ki vsebuje podrobne opise izvirnih podatkovnih zapisov v obliki objektov, shra- njenih v podatkovnem jezeru. Na ta način se znotraj sloja metapodatkov lahko zagotovijo lastnosti ACID- -a in dodatni indeksi za izboljšanje konsistentnosti podatkov in učinkovitosti sistema. V tem primeru uporabniki dostopajo do podatkov neposredno iz podatkovnega kolišča, pri čemer se zahtevani podat- ki najprej poiščejo z uporabo metapodatkov v po- Slika 2: Primer arhitekture z uporabo podatkovnega jezera. 7 Podatkovna hiša ob jezeru še nima ustaljenega ali uveljavljenega prevoda v slovenščino, zato uporablja predlog iz islovar.org, tj. kolišče. Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 32 2023 - πtevilka 1 - letnik XXXI datkovnem jezeru, se transformirajo in/ali agregira- jo glede na pravila, shranjena v sloju metapodatkov, se ponovno shranijo na drugo lokacijo v podatkov- nem jezeru ter hkrati vrnejo kot rezultat poizvedbe uporabniku. Kot tehnologija so podatkovna kolišča precej nov koncept na trgu, tehnološke rešitve pa se (predvsem za sloj metapodatkov) še vedno razvijajo z vzorci načrtovanja za najboljšo implementacijo arhi- tekture. Trenutno najbolj uveljavljen primer platfor- me podatkovnega kolišča je Delta Lake. Izbira najbolj primerne arhitekture za upravljanje velepodatkov je predvsem odvisna od stopnje struk - turiranosti izvirnih podatkov, potreb po prilagodlji- vosti sheme, konsistentnosti podatkov in razširlji- vosti ter namenu uporabe shranjenih podatkov oz. ustreznem podatkovnem modelu za določeni namen uporabe (npr. dimenzijski model za analitiko, izvir- ni podatki za podatkovno znanost, model ključ-vre- dnost za hitro iskanje ipd.). Izbiro vedno bolj zaplete- jo novi vzorci načrtovanja in IT-arhitekture, ki želijo združiti prednosti obstoječih rešitev. V nadaljevanju se osredotočimo na analizo tehnoloških rešitev za im- plementacijo različic dvostopenjske arhitekture, ki je trenutno najbolj priljubljena. 4 ANALIZA IZBRANIH TEHNOLOŠKIH SKLADOV 4.1 T ehnološki sklad Google Podjetje Google kot eno vodilnih ponudnikov oblač- nih storitev v kontekstu upravljanja velepodatkov, ponuja v sklopu Google Cloud Platform precej širok nabor tehnoloških rešitev za implementacijo pred- hodno predstavljenih arhitektur. Temu v korist je tudi dejstvo, da je za implementacijo dvostopenjske arhitekture pri Googlu možno oblikovati nekaj razli- čic tehnološkega sklada, glede na zahteve strank in željeno stopnjo odvisnosti od ponudnika oblačnih storitev. Ob analizi ponudbe tehnološkega sklada Slika 3: Prikaz dvostopenjske arhitekture za upravljanje velepodatkov . Slika 4: Prikaz arhitekture z uporabo podatkovnega kolišča. Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 33 2023 - πtevilka 1 - letnik XXXI Google, smo prišli do pregleda osnovnih rešitev za implementacijo dvostopenjske arhitekture, s kate- rimi lahko oblikujemo nekaj različic tehnološkega sklada, ki jih predstavljamo v nadaljevanju. Na ravni podatkovnega jezera se različice tehnolo- škega sklada ne razlikujejo, saj se za ta namen pripo- roča uporaba oblačne rešitve za shranjevanje objektov Google Cloud Storage [26]. Cloud Storage je primeren za shranjevanje tudi nestrukturiranih podatkov oz. predstavlja začetno točko shranjevanja izvirnih po- datkov. Kot tehnologija temelji na HDFS-u (angl. Ha- doop Distributed File System), datotečnem sistemu platforme in ekosistema Hadoop, ki omogoča poraz- deljeno shranjevanje velikih količin podatkov v dato- teke. Cloud Storage omogoča neomejeno shranjevanje datotek velikosti do pet terabajtov v obliki objektov ter integracijo z različnimi rešitvami za zajem in obde- lavo le-teh, pri čemer je optimiziran za prilagodljivo izvedbo povpraševanj in nizke stroške hrambe. Na sliki 5 sta prikazani dve arhitekturi podatkov- nega cevovoda, pri čemer se tehnološki sklad v ozad- ju razlikuje v izbiri rešitev za podatkovno analitiko Slika 5: Prikaz tehnološkega sklada Google z uporabo oblačne relacijske podatkovne baze in različnimi rešitvami za podatkovno analitiko in strojno učenje. Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 34 2023 - πtevilka 1 - letnik XXXI in strojno učenje. Predstavljena arhitektura cevovoda omogoča podjetjem, da razširijo zmogljivost obsto- ječih relacijskih podatkovnih baz z vključevanjem podatkovnega skladišča, s čimer implementirajo IT- -arhitekturo, ki je zmožna izpolniti analitične potre- be (OLAP) in potrebo po hitri izvedbi neposrednih povpraševanj po relacijski podatkovni bazi (OLTP). Treba je poudariti, da se kot osnova za podatkovno skladišče in analitično obdelavo (OLAP) uporablja ši- rokostolpčna podatkovna baza BigQuery. V takšni arhitekturi vlogo relacijske podatkovne baze prevzame Google Cloud SQL [25], ki je oblačna storitev za popolno upravljanje relacijske baze (tre- nutno so podprte MySQL, PostgreSQL in SQL Ser- ver). Storitev se lahko integrira v obstoječe IS-okolje podjetja s pomočjo storitev za orkestracijo, kot so App Engine, Google Kubernetes ipd., ter obstoječimi aplikacijami in storitvami, kot je Google BigQuery. Integracija z rešitvijo BigQuery omogoča vpeljavo analitičnih možnosti bodisi neposredno nad kompo- nento BigQuery Storage bodisi nad podatkovno bazo Cloud SQL, kar lahko močno izboljša učinkovitost dostopa do podatkov. Če podjetje želi svoj transakcijski del (OLTP) učin- koviteje skalirati, se lahko uporabi rešitev Google Cloud Spanner za upravljanje relacijskih podatkov- nih baz [24]. To je podatkovna baza, ki zagotavlja lastnosti ACID-a, a omogoča podprto horizontalno razširljivost, samodejno replikacijo podatkov, črepi- njenje (angl. sharding) in obdelavo transakcij. Privzeto je nastavljen Cloud Spanner, ki odvisno od količine podatkov in obremenitve sistema samo- dejno izvaja črepinjenje podatkov s ciljem izboljšanja učinkovitosti, vendar ni namenjen za uporabo v pri- merih, kjer je treba zadovoljiti osnovne potrebe SQL oz. OLTP (npr. osnovna analitika nad manjšo količino podatkov). Kot rešitev je Cloud Spanner uporabnejši v primerih, ko se pričakujeta masovna količina po- datkov s pogostim pisanjem v podatkovno bazo (npr. tisoče operacij pisanja v sekundi) in visoka razširlji- vost sistema OLTP . Po drugi strani se v kontekstu implementacije po- datkovnega skladišča oz. sistema OLAP v tehnolo- škem skladu Google najbolj pogosto omenja Google BigQuery [20] − rešitev, ki je že od začetka predsta- vljala kritično točko prehoda v ekosistem velepo- datkov in predstavlja navdih številnim sodobnim rešitvam za upravljanje velepodatkov. BigQuery je implementacija podatkovnega skladišča v več obla- kih (angl. multicloud), kar omogoča analizo podat- kov, shranjenih v več oblačnih storitvah. V osnovi to ni tipično podatkovno skladišče, ampak stolpčna shramba s strojem za izvedbo povpraševanj (angl. query engine), optimiziranim za analitične potrebe oz. hitre operacije branja. Predstavlja ustrezno reši- tev poizvedbam, ki zahtevajo skeniranja celih tabel in izvedbo operacij grupiranja podatkov (npr. iskanje povprečja). Uporabnikom je rešitev BigQuery prija- zna, saj tam lahko shranijo podatke, ki imajo struktu- ro relacijske tabele, dodatno pa vključuje nabor orodij za podatkovno analitiko, s katerim se že lahko nepo- sredno ustvarijo nadzorne plošče (angl. dashboards) in generirajo poročila. Za namen analize podatkov BigQuery vključuje naslednji nabor orodij:  BigQuery ML (angl. Machine Learning) − nabor orodij namenjen podatkovnim znanstvenikom in analitikom za izgradnjo in vzpostavitev modelov za strojno učenje z uporabo sintakse SQL (angl. Structured Query Language) na velikih količinah različno strukturiranih podatkov, shranjenih ne- posredno v BigQuery-u;  BigQuery BI Engine (angl. Business Intelligence) − servis za podatkovno analitiko v pomnilniku (angl. in-memory), vgrajen v BigQuery, ki omo- goča interaktivno analizo velikih in kompleksnih naborov podatkov, pri čemer se ohranjajo učinko- vitost in hitrost izvedbe povpraševanj ter visoka konkurenčnost. Google BigQuery je popularna rešitev s širokim naborom možnosti uporabe samo za shrambo in/ali obdelavo podatkov. Posledično je tudi model plače- vanja storitve ločen na plačevanje rešitve izključno za namen učinkovitega shranjevanja podatkov in plače- vanje za namen uporabe orodij za analitiko. BigQue- ry je priljubljen tudi zaradi podpore za združevanje zmogljivosti podatkovnega skladišča in podatkovne- ga jezera brez potrebe po uporabi tretje rešitve. Na ravni analize podatkov pa se pri uporabi rešitve Bi- gQuery tehnološki sklad Google lahko oblikuje na različne načine. Kot primer sta na sliki 5 prikazani dve arhitekturi. Pri arhitekturi na sliki 5a se za podat- kovno analitiko in strojno učenje uporabljajo orodja vgrajena v ekosistem Google (BigQuery), pri čemer uporabniki plačajo stroške shranjevanja in obdelave v rešitvi BigQuery. Kot alternativa za znižanje stroškov uporabe Google Cloud Platforme (BigQuery) se lah- ko vzpostavi tudi arhitektura, prikazana na sliki 5b, kjer se za analizo podatkov uporabljajo odprtokodne Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 35 2023 - πtevilka 1 - letnik XXXI rešitve, kot so Apache Spark, Presto, Hive, Pig. Na ta način uporabniki poravnajo le strošek shranjevanja podatkov v BigQueryju, za obdelavo podatkov pa se lahko v BigQuery integrirajo zgornje rešitve zno- traj ekosistema Apache. Slednja integracija je možna z uporabo orodja Google DataProc [22], s katero te rešitve lahko pišejo ali berejo podatke neposredno v/ iz baze BigQuery s pomočjo BigQuery Storage API-ja. Če podjetje želi zamenjati obstoječo relacijsko bazo zaradi morebitnih izzivov in pomanjkljivosti, kot sta razširljivost in neprilagodljivost sheme, se podjetje lahko odloči tudi za uporabo nerelacijske baze za del OLTP , pri čemer nastane različica arhitekture, prika- zana na sliki 6. V tehnološkem skladu Google se za ta namen upo- rablja Google BigTable [21], ki je razširljiva storitev NoSQL za uspešno upravljanje in izvedbo velikih ana- litičnih in operativnih delovnih obremenitev (angl. workload). Podpira model sčasome konsistentnosti (angl. eventual consistency), kar pomeni, da se podat- ki v bazo shranijo enkrat in se samodejno replicirajo na vozlišča po potrebi. Kot baza BigTable podpira vi- soko prepustnost za operacije pisanja in branja z niz- ko zakasnitvijo in predstavlja idealen vir podatkov za posle MapReduce, saj je zaledni stroj za hrambo (angl. storage engine) načrtovan v smeri, ki je primeren za lažje strojno učenje in napredno analitiko. Podatkovni model baze Google BigTable je kombi- nacija shranjevanja podatkov v obliki ključ-vrednost in delno širokostolpčne shrambe. Podatki se namreč shranjujejo v visoko razširljivih tabelah, vsaka tabela pa se predstavlja kot razvrščena mapa ključev in vre- dnosti. Zaradi slednjega je oblika shrambe BigTable primerna tudi za izvedbo nalog OLAP , saj omogoča hitro iteracijo po ključih. Po drugi strani se lahko pri oblikovanju uporabljajo tudi družine stolpcev (angl. column families), s čimer imajo uporabniki dostop do določenih prednosti širokostolpčnih shramb. Koncept družine stolpcev je pozneje razširjen v izjemno razšir- jenih široko stolpčnih bazah, kot sta Apache HBase ali Cassandra, ki so nastale na podlagi BigTabla. Pri izvedbi povpraševanj BigTable ne podpira poi- zvedovalnega jezika SQL, vendar se lahko integrira z rešitvijo Google BigQuery, pri čemer nastane različica arhitekture, prikazana na sliki 7. Integracija BigTable in rešitev BigQuery predstavljata rešitev, ki lahko prevzame vlogo podatkovnega skladišča, saj zmo- re obvladati naloge OLTP in OLAP . V tem primeru nerelacijska baza, kot je BigTable, shranjuje transak- cijske podatke v obliki, ki je vnaprej optimizirana za izvedbo povpraševanj, medtem ko močna rešitev, kot je BigQuery, lahko bere podatke in izvaja osnovne in napredne analize in agregacije. Včasih se lahko zgodi, da uporaba relacijske po- datkovne baze kot sistema OLTP ne zadostuje potre- bam podjetja, saj imajo relacijske baze določene znane Slika 6: Prikaz tehnološkega sklada Google z uporabo oblačne nerela cijske podatkovne baze. Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 36 2023 - πtevilka 1 - letnik XXXI pomanjkljivosti v kontekstu velepodatkov (npr. raz- širljivost, prilagodljivost sheme). Ne glede na izbrano različico arhitektur, ki so predhodno predstavljene, se lahko zgodi, da podjetje ni zadovoljno z učinkovito- stjo, ki jo v osnovi ponuja relacijska baza (tudi z ukre- pi za optimizacije in izboljšave) ali pa je obremenitev sistema OLTP preprosto previsoka. V takšnem prime- ru se priporoča uporaba določene rešitve, ki temelji na dostopu do podatkov znotraj delovnega pomnil- nika, saj se na ta način močno zmanjša število dosto- pov do diska, kar je posledica hitrejših poizvedb. Za ta namen Google ponuja uporabo storitve v delovnem pomnilniku Cloud Memorystore (slika 8). Rešitev je popolnoma kompatibilna z odprtokodnimi rešitvami, kot sta Redis in Memcached, ki se tudi uporabljajo za izboljšanje učinkovitosti sistema OLTP [23]. 4.2 T ehnološki sklad Amazon Tehnološki sklad Amazon vključuje ožji nabor rešitev, ki se sicer lahko uporabijo za več različic pri imple- mentaciji dvostopenjske arhitekture. Kot je prikazano na sliki 9, vlogo podatkovnega jezera pri skladu Ama- zon prevzame Amazon S3 [15], dobro znana rešitev, ki se pogosto uporablja kot osnovna rešitev za shra- njevanje podatkov v obliki datotek (angl. file server). S3 je največja in ena najbolj učinkovitih storitev za shranjevanje objektov za strukturirane in nestruktu- rirane podatke, vendar v novejšem času postaja tudi priljubljena rešitev za vzpostavitev podatkovnega je- zera. Eden od razlogov za to je, da storitev samodejno ustvarja in shranjuje kopije vseh vnesenih objektov S3 v več porazdeljenih vozliščih. Kot razlog za upora- bo rešitve S3 se poudarja tudi močna razširljivost na ravni petabajtov, ki omogoča navidezno neomejeno shranjevanje podatkov v kakršni koli obliki. Osnov- ni princip v ozadju je porazdelitev med hrambo in obdelavo podatkov, kar prinaša več prednosti pred- vsem pri vzdrževanju in uporabi virov. Glede na po- gostost uporabe in dostopanja do različnih naborov podatkov, se uporabniki lahko odločijo za nakup raz- ličic storitev S3 Standard ali S3 One Zone Infrequent Access [18]. Prva je splošna različica za shranjeva- nje podatkov, ki jo pogosto uporabljamo pogosto za različne namene, medtem ko je različica Infrequent Access ustrezna izbira za shranjevanje dolgotrajnih podatkov, do katerih dostopamo redko. Pri uporabi rešitve S3 kot podatkovnega jezera je treba vzpostaviti različna območja (angl. zones) [30, 12] oz. sloje za shranjevanje podatkov kot objektov glede na različne stopnje obdelave in korak v podat- kovnem cevovodu. Tako imenovano območje landing predstavlja izhodiščno točko shranjevanja prispelih podatkov iz virov podatkov v izvirni obliki v cevovo- du (npr. JSON, XML, CSV), preden se začnejo obde- Slika 7: Prikaz tehnološkega sklada Google z uporabo različice podatkovnega skladišča OL TP/OLAP . Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 37 2023 - πtevilka 1 - letnik XXXI Slika 8: Prikaz tehnološkega sklada Google z uporabo predpomnilnika. lovati na višjih ravneh. Podatki iz območja landing se validirajo in ustrezno reorganizirajo ter shranijo v t. i. območju raw, ki še vedno vsebuje podatke v izvirni obliki, vendar je struktura oz. organizacija objektov izboljšana glede na potrebe, podatki pa se shranijo v formatu, ki zagotavlja boljšo učinkovitost nadaljnjih analiz (npr. Parquet). Izvirni podatki se nato transformirajo v skladu z določeno podatkovno shemo in hranijo v t. i. območju trusted. Do območja trusted lahko dostopa kateri koli sistem OLTP oz. podatkovna baza, saj so podatki kon- sistentni, prečiščeni in usklajeni z določeno shemo. Na najvišji ravni se podatki v območju trusted zdru- žujejo glede na potrebe analiz in se združeni hranijo v t. i. območju curated. Ta je tako glavni vir podatkov za podatkovno skladišče, kjer se podatki agregirajo za potrebe analitike in prikaza uporabniku. Zaradi zahtevnejše organizacije podatkov znotraj shrambe S3 se priporoča vzpostavitev mehanizma za samodejni zajem podatkov iz virov, ustvarjanje in vzdrževanje kataloga metapodatkov ter zagotavljanje točnosti podatkovnih tokov od različnih območij. Za ta namen se priporoča uporaba rešitve AWS Glue [14], ki je popolnoma upravljana storitev za ETL, ki lahko olajša procese razvrščanja, čiščenja, transformacije in prenosa podatkov med različnimi lokacijami. AWS Glue Data Catalogue [17] je orodje znotraj rešitve AWS Glue, ki zagotavlja enotni repozitorij metapo- datkov za izvedbo operacij za namen analitike nad več različnimi viri podatkov, kot so Amazon EMR, Athena, Redshift (Spectrum) ali katere koli aplikacije kompatibilne s hrambo Hive za metapodatke (angl. Hive metastore). Data Catalogue je predvsem podat- kovna baza, v katero se shranjujejo metapodatki in ta- bele podatkovnih shem, lokacija podatkov v sistemu in različne metrike za delovanje rešitve oz. sistema. Ker je kompatibilen s hrambo Hive za metapodatke, pa se Data Catalogue lahko uporablja kot osrednji re- pozitorij za shranjevanje strukturiranih in nestruktu- riranih metapodatkov. Ko so podatki shranjeni v S3 se v naslednjem kora- ku cevovoda transformirajo skozi procese ETL, ki po- stavijo le tiste v ustrezno obliko za potrebe analitike ali vizualizacije. Pri transformaciji podatkov se lahko uporabijo trije pristopi [14]:  Ustvarjanje gruče Amazon EMR z nameščeno re- šitvijo Hive − surovi podatki, shranjeni v S3, se transformirajo v tabele Hive in se shranijo v S3 v formatu Parquet.  Uporabljanje rešitve Spark na Amazon EMR.  Uporabljanje rešitve AWS Glue, ki samodejno naj- de surove podatke, shranjene v S3, identificira nji- hov format shrambe ter predlaga ciljno shemo in transformacije. Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 38 2023 - πtevilka 1 - letnik XXXI V tehnološkem skladu Amazon se kot sistem OLTP oz. transakcijska podatkovna baza uporablja Amazon Aurora [13], storitev za implementacijo rela- cijske baze, ki združuje hitrost in dostopnost komer- cialnih podatkovnih baz s preprostostjo in stroškov- no učinkovitostjo odprtokodnih podatkovnih baz. Aurora je popolnoma kompatibilna s sistemi za upra- vljanje podatkovnih baz MySQL in PostgreSQL, kar bistveno olajša integracijo z obstoječimi aplikacijami, ne da bi bile nujne velike spremembe. Prilagodljiva je vsem potrebam po razširljivosti, saj se viri shrambo po potrebi samodejno razširijo. Poslovni model vzpo- stavitve rešitve Aurora vključuje plačilo storitve po uri uporabe posamezne instance Aurore. Na drugi strani sklada se kot glavna rešitev za OLAP uporablja Amazon RedShift [16] − hitro podat- kovno skladišče na ravni petabajtov, s katerim lahko uporabniki analizirajo svoje podatke, shranjene na več različnih lokacijah. Na ravni implementacije je RedShift širokostolpčna podatkovna baza, ki jo je z uporabo širokega nabora vtičnikov možno povezati z različnimi odjemalci oz. bazami, kot je PostgreSQL. Rešitev je preprosto razširljiva, saj je po potrebi mo- žno dodati nova vozlišča v oblačno storitev s pomočjo spletne konzole ali zasebnega API-ja. Vozlišča lahko dosežejo kapaciteto med 160 gigabajtov in 16 tera- bajtov. Uporabniki poravnajo dejansko porabo virov. RedShift predstavlja izjemno močno rešitev znotraj sklada Amazon, s katero lahko podjetja zadovoljijo analitične potrebe, dodatna prednost pa je tudi mo- žnost povezovanja RedShifta z relacijsko podatkovno bazo ali rešitvijo za poslovno obveščanje zunaj eko- sistema Amazon. Za delo z RedShiftom se uporablja robusten API, ki omogoča izvedbo poizvedb nad po- datki shranjeni v bazi. Za dodatno optimizacijo upo- rabe virov ob izvedbi povpraševanj RedShift upo- rablja algoritme strojnega učenja za napovedovanje in analizo povpraševanj. RedShift podpira različne formate podatkov v obliki datotek, kot so Parquet ali ORC (angl. Optimized Row Columnar), ki lahko vplivajo na učinkovitost sistema. Kot omejitev upora- be RedShifta se omenjata OLAP , omejitve, povezane z učinkovitostjo operacij vnašanja, posodabljanja in brisanja ter izostanek mehanizma za upravljanje in- deksov znotraj platforme AWS. Znotraj rešitve RedShift obstaja tudi orodje, ki omogoča hitro izvedbo kompleksnih analiz nad objekti, shranjenih v določenih oblačnih rešitev skla- da Amazon (S3, RedShift itn.). Amazon RedShift Spectrum [19] je orodje, ki se pogosto uporablja z RedShiftom, saj omogoča samodejno skaliranje in op- timalno izvedbo povpraševanj (na ravni eksabajtov podatkov) nad gručo RedShift. Uporaba orodja se poravna tudi po porabi, nujno pa potrebuje vzposta- vljeno RedShift gručo in povezanega odjemalca SQL. Z uporabo znane sintakse jezika SQL znotraj orodja Spectrum lahko uporabniki hitro dostopajo do ve- likih količin podatkov porazdeljenih med več gruč RedShift (ali vozlišč) in izvajajo kompleksna povpra- ševanja nad podatki. Rezultati povpraševanj se lahko Slika 9: Prikaz tehnološkega sklada Amazon. Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 39 2023 - πtevilka 1 - letnik XXXI nato uporabijo za namen podatkovne analitike, ki jo znotraj sklada Amazon izvajamo z orodjem Amazon QuickSight, ali strojnega učenja, za katero potrebuje- mo rešitev Amazon SageMaker. 4.3 Odprtokodni tehnološki sklad Apache Kot alternativa plačljivim storitvam in rešitvam, ki jih ponujajo vodeči ponudniki na trgu, kot so Goo- gle (Google Cloud Platform − GCP), Amazon (AWS) in Microsoft (Azure), se podjetja lahko obrnejo tudi proti odprtokodnim tehnologijam, kar je tudi pred- nostna smer implementacije pri večini podjetij z omejenim proračunom za implementacijo sistema. Pri tem se kot sopomenka za odprtokodne rešitve na področju velepodatkov večinoma uporablja Apache, saj predstavlja nabor programske opreme, ki je na voljo vsem uporabnikom. Rešitve, ki jih ponuja sklad Apache, so dovolj hitre in zanesljive za uporabo ter se lahko prilagodijo posameznim potrebam podjetja, kar je največja dodana vrednost za podjetja, ki imajo specifične poslovne procese ali zahteve in želijo imeti večji nadzor nad implementacijo. Čeprav implemen- tacija sklada Apache zahteva več časa in znanja, brez- plačna uporaba rešitev za upravljanje velepodatkov, ki niso t. i. ‘črna škatla’ (angl. black box), podjetju predstavlja upravičen strošek za uporabo prav tiste- ga sklada namesto plačevanja oblačnih storitev pri predhodno omenjenih ponudnikih. Čeprav je nabor možnih rešitev za posamezo kom- ponento dvostopenjske arhitekture pri skladu Apa- che precej širši kot pri skladih Google in Amazon, je v nadaljevanju na sliki 10 predstavljen osnovni predlog sklada z rešitvami, ki predstavljajo jedro tehnoloških skladov za upravljanje velepodatkov. Za funkcionalnosti podatkovnega jezera pri skla- du Apache poskrbi rešitev HDFS (angl. Hadoop Dis- tributed File System) [8], porazdeljeni datotečni sis- tem, ki predstavlja osnovno lokacijo za shranjevanje podatkov v obliki datotek znotraj platforme in ekosi- stema Hadoop. Podatki se znotraj HDFSa shranujejo kot bloki, pri čemer se vsak blok za namen replikacije razdeli trikrat na različna HDFS podatkovna vozli- šča. HDFS predstavlja hrbtenico ekosistema Hadoop in podobnih datotečnih sistemov drugih ponudni- kov na trgu, kot so Microsoft HDInsight, Cloudera CDH, IBM Open Platform itn. Kot alternativa upora- bi HDFS-a kot podatkovnega jezera so dandanes na trgu dostopne tudi rešitve zunaj sklada Apache, in sicer se lahko uporabi npr. MinIO kot oblačna rešitev visoke zmogljivosti, ki je hkrati kompatibilna z reši- tvijo Amazon S3. HDFS deluje po principu, da vsaka naprava v gruči Hadoop hrani podmnožico podatkov, Slika 10: Prikaz tehnološkega sklada Apache. Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 40 2023 - πtevilka 1 - letnik XXXI ki tvorijo datotečni sistem. Ob potrebi po shranjeva- nju več podatkov se lahko v gručo doda več naprav z več diski in se celotni datotečni sistem preprosto raz- širi. Podatki, shranjeni v HDFSu, se nato posredujejo v nabor poslov ETL, ki jih lahko opravimo z Apache Sparkom ali katerim koli orodjem, ki omogoča uvoz in izvoz podatkov v/iz HDFSa. Primer takšnega orod- ja je Apache Sqoop [5], ki omogoča prenos paketnih podatkov med gručo Hadoop in strukturiranimi viri podatkov, kot so relacijske baze ali skladišča. Z uporabo Sqoopa se podatki iz HDFSa lahko transformirajo in shranijo v relacijsko bazo, kot je PostgreSQL, ki nato prevzame vlogo sistema OLTP v celotni arhitekturi. Za izboljšano učinkovitost in razširljivost klasične baze PostgreSQL se uporablja odprtokodna razširitev Citus [4], ki vpeljuje možnost porazdeljenega shranjevanja in obdelave podatkov v bazi PostgreSQL in učinkovito razširi zmogljivost ob- stoječe podatkovne baze PostgreSQL. Z vpeljavo reši- tve Citus lahko podjetja razširijo obstoječo podatkov- no bazo PostgreSQL na gručo vozlišč PostgreSQL, ki so zmožna učinkovito hraniti več podatkov. Nastane gruča Citus, v kateri eno vozlišče predstavlja koordi- natorja Citus, ki posreduje povpraševanja, napisana v jeziku SQL, na ustrezno vozlišče PostgreSQL in vodi evidenco o lokaciji, kjer je določeni podatek v gruči. Vlogo podatkovnega skladišča v skladu Apache lahko prevzame rešitev Apache Doris [6], podatkov- no skladišče OLAP , ki omogoča uporabo poizvedo- valnega jezika SQL in temelji na principu masovne vzporedne obdelave (angl. massively parallel pro- cessing). To je relativno nova rešitev, razvita v inku- batorju Apache, ki je nastala kot rezultat integracije rešitev Apache Impala (porazdeljeni stroj SQL za povpraševanja nad gručo Hadoop) in Google Mesa (visoko razširljivo podatkovno skladišče, razvito s strani Googla). Doris omogoča preprosti načrt IT- -arhitekture, ki hkrati zagotavlja visoko zanesljivost, dostopnost, razširljivost ter toleranco na napake. V ozadju rešitve Doris je širokostolpčna podatkovna baza, vendar je le-tista nadgrajena s tehnologijo vek- torizacije (angl. vectorization technology) zaradi opti- mizacije pri izvedbi povpraševanj. Tradicionalni stro- ji SQL za povpraševanja (angl. SQL query engines) analizirajo podatke v tabelah po principu vrstic (angl. row- based), kar prinaša dodatni strošek pri upora- bi procesorskih enot CPU. Pri Doris želi tehnologija vektorizacije izboljšati pristop na način, da se podatki obdelajo po principu stolpcev, kar zmanjšuje uporabo virov CPU in v celoti eliminira odvečno število ope- racij branja nad podatki. Doris podpira tudi visoko konkurenčnost dostopa med več uporabniki ter ho- rizontalno razširljivost. Uporabniki lahko dostopajo do podatkov, shranjenih v skladišču, z različnimi od- jemalci in orodji za poslovno obveščanje. Kot največjo prednost rešitve poudarjajo možnost realnočasovnih nadzornih plošč, ad hoc poizvedbe in celovito rešitev za razširljivo podatkovno skladišče, ki lahko zagoto- vi funkcionalnosti, ki bi jih sicer mogli nadomeščati z več rešitvami (Spark, Hive in HBase). Kot alternativa Apache Doris je vsekakor tudi Apache HBase, ki je ena pravih odprtokodnih rešitev širokostolpčne po- datkovne baze. Kot pomembna komponenta sklada Apache se lah- ko kljub temu uporablja Hive [7] − podprt sistem SQL za analiziranje podatkov, shranjenih v HDFSu. Zaradi preprostega jezika za pisanje poizvedb (Hive Query Language, HQL) je Hive ustrezna rešitev za obdelavo podatkov in izvedbo procesa ETL, zaradi neposredne- ga dostopa do podatkov v HDFSu pa se lahko upora- blja tudi kot alternativa za podatkovno skladišče. V primerjavi z drugimi rešitvami sklada Apache (npr. Impala ali Doris) je bolj namenjen podatkovnim inže- nirjem in ne podatkovnim znanstvenikom. V tistem primeru se podatki, shranjeni v podatkovnem jezeru oz. HDFSu, indeksirajo v komponenti Hive MetaSto- re, ki deluje kot katalog metapodatkov, v katerem se struktura datotek HDFS mapira v obliko razpredelni- ce. Hive je zgrajen nad Hadoopom, kar pomeni, da je že v načrtu ustrezna rešitev za potrebe upravljanja ve- likih datotek na ravni petabajtov. Kot rešitev omogoča sloj abstrakcije nad HDFSom, na katerem so podatki predstavljeni kot tabele z vrsticami, stolpci in podat- kovnimi tipi, katere uporabniki lahko analizirajo po vmesniku HiveQL. Kot dodatna prednost je podpo- ra za transakcije ACID, kar pomaga pri zagotavljanju konsistentnosti podatkov. Hive sledi pristopu sheme ob branju (angl. schema-on- read), kar pomeni, da se podatki hitro shranjujejo v skladišče Hive brez valida- cije ali dodatnih preverjanj, končno obliko pa pridobi- jo iz Hive MetaStora ob izvedbi povpraševanj. Glede integracije z drugimi rešitvami, kot je Amazon S3, je Hive dovolj odprta rešitev. Razen shranjevanja zdru- ženih podatkov v skladišču se Hive lahko uporablja tudi na ravni podatkovne analitike v primeru osnov - nih analiz. Za naprednejšo analitiko in strojno učenje se priporoča uporaba rešitve Apache Spark, ki pred- stavlja danes najbolj razširjeno rešitev za obdelavo ve- Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 41 2023 - πtevilka 1 - letnik XXXI lepodatkov [31] zgrajeno nad porazdeljenim strojem SQL za izvedbo povpraševanj nad velepodatki. 5 DISKUSIJA IT-arhitekti sodobnih podatkovnih cevovodov imajo izziv izbrati tehnološki sklad za implementacijo dvo- stopenjske arhitekture, ki je v skladu z dostopnimi viri ter omejitvami in zahtevami vodstva podjetja. Čeprav ponudniki, kot sta Google ali Amazon, te- žijo k plačljivemu načinu uporabe njihovih rešitev, je možno določene rešitve znotraj njihovega sklada integrirati z odprtokodnimi rešitvami znotraj skla- da Apache ali drugega sklada, s katerima si podje- tja lahko znižajo stroške implementacije. V Tabeli 1 so predstavljeni izsledki analize rešitev tehnoloških skladov Google, Amazon in Apache, ki so arhitektom na voljo za implementacijo posameznih komponent dvostopenjske arhitekture, in sicer možne rešitve za podatkovno jezero, podatkovno skladišče (OLAP), podatkovno bazo (OLTP) ter rešitve za podatkovno analitiko in strojno učenje. Poudariti pa je treba, da IT-arhitekti niso zgolj omejeni z uporabo odprtoko- dnih rešitev za podatkovno analitiko, kot prikazuje slika 5b, temveč lahko posamezne komponente (npr. podatkovno jezero, podatkovno skladišče, podat- kovna baza) izbirajo s strani različnih ponudnikov in te med seboj združujejo. Primer tega bi bila uporaba Amazon S3 za podatkovno jezero, relacijsko podat- kovno bazo PostgreSQL na lastni infrastrukturi za namen OLTP , Google BigQuery kot osnova za podat- kovno skladišče oz. OLAP ter odprtokodna orodja za podatkovno analitiko, kot so Apache Spark, Hive, Pig itn. Kombinacij je toliko, koliko je orodij in ponu- jenih storitev na trgu, pri čemer načeloma omejitev ni, temveč so zgolj morebitni zadržki zaradi zaple- tenosti upravljanja takšne IT-arhitekture. Prednosti takšnih morebitnih kombinacij so vsekakor manjši stroški ter nezavezanost enemu ponudniku storitev. Prav tako pa bi lahko IT-arhitekti uporabili določene ponudnike oblačnih storitev zgolj za infrastrukturo kot storitev (IaaS), med tem ko bi sami nameščali in upravljali odprtokodne rešitve za del podatkovnega inženirstva ali za podatkovno analitiko. Eden večjih izzivov pri načrtovanju arhitektu- re sodobnega cevovoda je predvsem izbira najbolj ustrezne rešitve za hitro in učinkovito shranjevanje podatkov ter rešitve za preprosto in morebitno kom- pleksno obdelavo in analizo le-teh. Zaradi tega se podjetja pogosto odločajo za izbiro oblačne storitve, ki predstavlja sistem OLTP (relacijski ali nerelacij- ski), saj se na ta način izognejo stroškom razširjanja in vzdrževanja obstoječih sistemov OLTP , lahko pa preprosto nadgradijo svoje obstoječe baze oz. najdejo kompatibilno oblačno rešitev kot nadgradnjo obstoje- čih baz (npr. Google Cloud SQL podpira implemen- tacijo klasične baze MySQL). Na ravni podatkovnega jezera zadostuje hramba podatkov v obliki objektov ali datotek, kar veliko podjetij že uporablja zaradi shranjevanja vseh podatkov v sistemih. To pomeni, da je za podjetja dovolj, da so podatki v obliki objek- tov ali datotek ustrezno organizirani glede na potre- be prihodnjih analiz in njihove uporabe v naslednjem koraku cevovoda. Glede na to, da večina rešitev za podatkovna jezera v oblaku temelji na odprtokodnem HDFSu, je odločitev o uporabi rešitve za podatkovno jezero predvsem odvisna od možnosti samostojnega vzdrževanja rešitve. Podjetja z večjim proračunom se ponavadi odločajo za uporabo zanesljive oblačne re- šitve, kot je Amazon S3 ali Google Object Storage, pri drugih komponentah cevovoda pa poskusijo biti čim bolj neodvisni od plačljivega ponudnika in uporabiti nadgrajeno različico komponente, ki jo že uporablja- jo (npr. transakcijska podatkovna baza ali skladišče, ročno razviti proces ETL, brezplačna orodja za vizua- lizacijo ali podatkovno analitiko). 6 SKLEP V članku smo predstavili teoretično ozadje načrto- vanja sodobnih IT-arhitektur za upravljanje velepo- datkov ter osnovne komponente takšnih sistemov. Področje upravljanja velepodatkov se tehnološko in- tenzivno razvija v zadnjem desetletju. Kot rezultat so nastale številne tehnologije različnih ponudnikov na trgu, kar predstavlja velik izziv pri izbiri tehnološke- ga sklada za podjetja, ki želijo izboljšati zmogljivost svojih obstoječih sistemov na ravni velepodatkov. Čez leta so se uporabljale različne rešitve za shranje- vanje in obdelavo velikih količin podatkov za namene OLTP ali OLAP , kot so transakcije relacijske in nere- lacijske podatkovne baze, podatkovna skladišča, po- datkovna jezera in (po novem) podatkovna kolišča. Slednje se vključujejo kot komponente za shranjeva- nje podatkov v sodobnih podatkovnih cevovodih, ki zagotavljajo pravilne podatkovne toke, od podat- kovnih virov do ciljne aplikacije ali orodij za podat- kovno analitiko. Točnost in učinkovitost upravljanja podatkov v tistih cevovodih se zagotovita z ustre- znim podatkovnim inženirstvom in IT-arhitekturo, ki Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 42 2023 - πtevilka 1 - letnik XXXI vključuje eno ali več rešitev za zajem, shranjevanje, obdelavo ter dostop do podatkov. Že več let je najbolj priljubljena dvostopenjska arhitektura, saj hkrati za- gotavlja hitrost poizvedb po transakcijskih podatkih, shranjenih v sistemih OLTP (oblačne ali on premise podatkovne baze), in učinkovitost kompleksnih poi- zvedb nad združenimi podatki, shranjenih v sistemih OLAP (podatkovna skladišča ali prilagojene široko- stolpčne baze). Kot je razvidno iz narejene analize tehnoloških skladov Google in Amazon, velike razlike med tema plačljivima ponudnikoma ni, saj sta arhitektura in način delovanja podatkovnega cevovoda v obeh pri- merih podobni in so uporabnikom na voljo močne in zelo razširljive rešitve. Prav tako temeljijo storitve, ki jih ponujajo na skoraj enakih osnovah ter se zgolj promovirajo z ločenimi blagovnimi znamkami in do- datnimi funkcionalnostmi. Z odprtokodnim skladom imajo Apache uporabniki večji nadzor nad posame- znimi komponentami arhitekture, vendar to zahteva neprekinjeno nadzorovanje sistema zaradi pravoča- snega ukrepanja za odpravljanje napak in skaliranje rešitev. Izbira tehnološkega sklada je torej odvisna od več dejavnikov, med katerimi sta najpomembnejši dostopnost človeških in finančnih virov v podjetju ter želena prilagodljivost in stopnja nadzora nad celo- tnim sistemom. V tem članku smo se predvsem omejili na podat- kovno inženirstvo in zagotavljanje IT-arhitekture za učinkovito uporabo in upravljanje velepodatkov, pri čemer pa smo izpustili določene izzive sodobnega po- datkovnega inženirstva, kot so zahteve po realnoča- sovni obdelavi dogodkovnih podatkov itn. Prav tako smo analizirali in predstavili zgolj dva od treh velikih ponudnikov oblačnih storitev (tj. Google in Amazon). Tabela 1: Pregled tehnoloških rešitev za implementacijo dvostopenjske arhitekture znotraj skladov Google, Amazon in Apache. Sklad Google Sklad Amazon Sklad Apache Podatkovno jezero Google Cloud Storage Amazon S3 Hadoop HDFS Podatkovno skladišče (OLAP) Google BigQuery Amazon RedShift + RedShift Spectrum - Apache Hive - Apache Doris Podatkovna baza (OL TP) - Google Cloud SQL ali Cloud Spanner (relacijska PB) - Google BigT able (nerelacijska PB) - Google Cloud MemoryStore (predpomnilnik) Amazon Aurora PostgreSQL + Citus Podatkovna analitika in strojno učenje* - V ertex AI in BigQuery ML - Apache Spark / Presto / Hive / Pig (vključuje uporabo rešitve Google DataProc) - Amazon QuickSight - Amazon SageMaker - Apache Hive - Apache Spark V prihodnosti bomo zajeli tudi analizo arhitektur Lambda in Kappa ter trenutno analizo razširili tudi na Microsoftov sklad in druge ponudnike, kot tudi predstaviti morebitne IT-arhitekture, ki kombinirajo uporabo komponent različnih ponudnikov. Prav tako se bomo osredotočili na analizo učinkovitosti in smo- trnosti uporabe zgolj infrastrukture kot storitve (angl. Infrastructure-as-a-Service, IaaS) ter na osnovi tega snovanja IT-arhitekture, ki temelji na skladu Apache. ZAHVALA Rezulati so delno financirani s strani raziskovalnega programa št. P2-0057 Javne agencije za raziskovalno dejavnost Republike Slovenije iz državnega prora- čuna ter projektov ZeRoW (1001036388) in Data4Fo- od2030 (101059473) financiranih iz okvirnega pro- grama EU za raziskave in inovacije – Obzorje H2020 in Obzorje Evropa. LITERA TURA [1] Memoona J Anwar, Asif Q Gill, Farookh K Hussain, and Muhammad Imran. Secure big data ecosystem architectu- re: challenges and solutions. EURASIP Journal on Wireless Communications and Networking, 2021(1):1–30, 2021. [2] Michael Armbrust, Ali Ghodsi, Reynold Xin, and Matei Zaha- ria. Lakehouse: a new generation of open platforms that unify data warehousing and advanced analytics. In Proceedings of CIDR, 2021. [3] Abhay Kumar Bhadani and Dhanya Jothimani. Big data: chal- lenges, opportunities, and realities. [4] Effective big data management and opportunities for imple- mentation, pages 1–24, 2016. [5] Citus Data. Citus dokumentacija. [Na spletu]. Dostopno: https://docs.citusdata.com/en/v11.1/get_started/what_is_ci- tus.html. [Dostopano: 27-okt-2022], 2022. [6] The Apache Software Foundation. Apache Sqoop dokumen- tacija. [Na spletu]. Dostopno: https://sqoop.apache.org/. [Dostopano: 27-okt-2022], 2019. Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov UPORABNA INFORMATIKA 43 2023 - πtevilka 1 - letnik XXXI [7] The Apache Software Foundation. Apache Doris dokumenta- cija. [Na spletu]. Dostopno: https://doris.apache.org/. [Dosto- pano: 27-okt-2022], 2022. [8] The Apache Software Foundation. Apache Hive dokumenta- cija. [Na spletu]. Dostopno: https://hive.apache.org/. [Dosto- pano: 27-okt-2022], 2022. [9] The Apache Software Foundation. Hadoop HDFS Architec- ture Guide. [Na spletu]. Dostopno: https://hadoop.apache. org/docs/r1.2.1/hdfs_design.html. [Dostopano: 27-okt-2022], 2022. [10] Paramita Ghosh. Data architecture challenges. [Na spletu]. Dostopno: https://www.dataversity.net/data- architecture- -challenges. [Dostopano: 4-okt-2022], junij 2022. [11] Josh Howarth. 30+ incredible big data statistics (2022). [Na spletu]. Dostopno: https://explodingtopics.com/blog/big-da- ta-stats. [Dostopano: 3-okt-2022], avgust 2022. [12] Oliver Hummel, Holger Eichelberger, Andreas Giloj, Dominik Werle, and Klaus Schmid. A collection of software engine- ering challenges for big data system development. In 2018 44th Euromicro Conference on Software Engineering and Ad- vanced Applications (SEAA), pages 362–369. IEEE, 2018. [13] Amazon Web Services Inc. AWS Serverless Data Analytics Pipeline. [Na spletu]. Dostopno: https://docs.aws.amazon. com/pdfs/whitepapers/latest/aws-serverless-data-analytics- -pipeline/aws- serverless-data-analytics-pipeline.pdflogical- -architecture-of-modern-data-lake-centric-analytics- plat- forms. [Dostopano: 27-okt-2022], april. [14] Amazon Web Services Inc. Amazon Aurora dokumentacija. [Na spletu]. Dostopno: https://aws.amazon.com/rds/aurora/. [Dostopano: 27-okt-2022], 2022. [15] Amazon Web Services Inc. Amazon AWS Glue dokumenta- cija. [Na spletu]. Dostopno: https://aws.amazon.com/glue/. [Dostopano: 27-okt-2022], 2022. [16] Amazon Web Services Inc. Amazon AWS S3 dokumentacija. [Na spletu]. Dostopno: https://aws.amazon.com/s3/. [Dosto- pano: 27-okt-2022], 2022. [17] Amazon Web Services Inc. Amazon RedShift dokumentaci- ja. [Na spletu]. Dostopno: https://aws.amazon.com/redshift/. [Dostopano: 27-okt-2022], 2022. [18] Amazon Web Services Inc. AWS Glue Components. [Na sple- tu]. Dostopno: https://docs.aws.amazon.com/glue/latest/ dg/components-overview.html. [Dostopano: 27-okt-2022], 2022. [19] Amazon Web Services Inc. Central storage: Amazon S3 as the data lake storage platform. [Na spletu]. Dostopno: https:// docs.aws.amazon.com/whitepapers/latest/building-data-la- kes/amazon-s3-data-lakestorage-platform.html. [Dostopa- no: 27-okt-2022], 2022. [20] Amazon Web Services Inc. Getting started with Amazon Redshift Spectrum. [Na spletu]. Dostopno: https://docs. aws.amazon.com/redshift/latest/dg/c-getting-started-using- -spectrum.html. [Dostopano: 27-okt-2022], 2022. [21] Google Inc. Google Cloud BigQuery dokumentacija. [Na sple- tu]. Dostopno: https://cloud.google.com/bigquery. [Dostopa- no: 27-okt-2022], 2022. [22] Google Inc. Google Cloud BigTable dokumentacija. [Na sple- tu]. Dostopno: https://cloud.google.com/bigtable. [Dostopa- no: 27-okt-2022], 2022. [23] Google Inc. Google Cloud DataProc dokumentacija. [Na spletu]. Dostopno: https://cloud.google.com/dataproc. [Do- stopano: 27-okt-2022], 2022. [24] Google Inc. Google Cloud MemoryStore dokumentacija. [Na spletu]. Dostopno: https://cloud.google.com/memorystore. [Dostopano: 27-okt-2022], 2022. [25] Google Inc. Google Cloud Spanner dokumentacija. [Na sple- tu]. Dostopno: https://cloud.google.com/spanner. [Dostopa- no: 27-okt-2022], 2022. [26] Google Inc. Google Cloud SQL dokumentacija. [Na spletu]. Dostopno: https://cloud.google.com/sql. [Dostopano: 27- okt-2022], 2022. [27] Google Inc. Google Cloud Storage dokumentacija. [Na sple- tu]. Dostopno: https://cloud.google.com/storage. [Dostopa- no: 27-okt-2022], 2022. [28] Godson Koffi Kalipe and Rajat Kumar Behera. Big data ar- chitectures: A detailed and application oriented review. In- ternational Journal of Innovative Technology and Exploring Engineering, 8:2182–2190, 2019. [29] Avita Katal, Mohammad Wazid, and Rayan H Goudar. Big data: issues, challenges, tools and good practices. In 2013 Sixth international conference on contemporary computing (IC3), pages 404–409. IEEE, 2013. [30] Jimmy Lin. The lambda and the kappa. IEEE Internet Compu- ting, 21(05):60–66, 2017. [31] Gaurav Mishra. Setting up a Data Lake architecture with AWS. [Na spletu]. Dostopno: https://www.srijan.net/resour- ces/blog/setting-up-a-data-lake-architecture-with-aws. [Do- stopano: 27-okt-2022], avgust 2019. [32] Pointer, Ian. What is Apache Spark? The big data platform that crushed Hadoop. [Na spletu]. Dostopno: https://www. infoworld.com/article/3236869/what-is-apache-spark-the- -big-data-platform-that- crushed-hadoop.html. [Dostopano: 27-okt-2022], marec 2020. [33] Zhi-Hua Zhou, Nitesh V Chawla, Yaochu Jin, and Graham J Williams. Big data opportunities and challenges: Discussions from data analytics perspectives [discussion forum]. IEEE Computational intelligence magazine, 9(4):62–74, 2014.  Martina Šestak je asistentka z doktoratom in raziskovalka na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. T renutno se raziskovalno ukvarja s sodobnimi arhitekturami za upravljanje velepodatkov , podatkovnimi bazami grafov in podatkovnimi prostori. Raziskovalno in aplikativno sodeluje tudi na več projektih, ki se odvijajo v okviru Inštituta za informatiko.  Muhamed T urkanović je visokošolski učitelj, izredni profesor , na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. Je vodja raziskovalne skupine Blockchain Lab:UM Inštituta za informatiko, namestnik predstojnika Inštituta za informatiko, vodja slovenskega EDIH-a DIGI-SI, vodja Digitalnega inovacijskega stičišča Univerze v Mariboru, vodja projektov H2020, Horizont Evropa, Interreg Alpine Space ter ARRS CRP . Njegovi trenutni raziskovalni interesi vključujejo področja tehnologij veriženja blokov , podatkovnih tehnologij ter digitalnih identitet. Martina Šestak, Muhamed Turkanović: Pregled in analiza tehnoloških skladov za implementacijo sodobnih it arhitektur velepodatkov