Zpracov´an´ı velk´ych dat logistiky v automotive

Zpracov´ an´ı velk´ ych dat logistiky v automotive

Diplomov´ a pr´ ace

Studijn´ı program: N2612 – Elektrotechnika a informatika Studijn´ı obor: 1802T007 – Informaˇcn´ı technologie Autor pr´ace: Bc. Luk´aˇs Voseck´y

Vedouc´ı pr´ace: Mgr. Jiˇr´ı Vran´y, Ph.D.

Konzultant: Ing. Jakub Vancl (ˇSkoda Auto a.s.)

Zadání diplomové práce

Zpracování velkých dat logistiky v automotive

Jméno a příjmení: Bc. Lukáš Vosecký Osobní číslo: M18000156

Studijní program: N2612 Elektrotechnika a informatika Studijní obor: Informační technologie

Zadávající katedra: Ústav nových technologií a aplikované informatiky Akademický rok: 2019/2020

Zásady pro vypracování:

1. Seznamte se s problematikou velkých dat a platformami pro jejich zpracování jako Splunk, Cloudera Hadoop a Power BI.

2. Navrhněte řešení pro transformaci, manipulaci a přenos dat ze softwarové platformy Splunk do Cloudera Hadoop. Zaměřte se na univerzálnost a přenositelnost zpracování datového toku.

3. Implementujte prototyp navrženého řešení pomocí jazyka Python.

4. Vytvořte reporty v Power BI pro otestování funkčnosti celého datového toku a pro základní ukázkovou vizualizaci.

Rozsah grafických prací: dle potřeby Rozsah pracovní zprávy: 40-50 stran

Forma zpracování práce: tištěná/elektronická

Jazyk práce: Čeština

Seznam odborné literatury:

[1] POWELL, Brett. Mastering Microsoft Power BI: Expert techniques for effective data analytics and business intelligence. 1. Birmingham, UK: Packt Publishing, 2018. ISBN 978-1788297233.

[2] KELLEHER, John D. a Brendan TIERNEY. Data science. Cambridge, Massachusetts: The MIT Press, [2018]. ISBN 978-0262535434.

[3] VANDERPLAS, Jacob T. Python data science handbook: essential tools for working with data.

2016. ISBN 978-1491912058.

Vedoucí práce: Mgr. Jiří Vraný, Ph.D.

Ústav nových technologií a aplikované informatiky Konzultant práce: Ing. Jakub Vancl

Škoda Auto a.s.

Datum zadání práce: 9. října 2019 Předpokládaný termín odevzdání: 18. května 2020

prof. Ing. Zdeněk Plíva, Ph.D.

děkan

L.S.

Ing. Josef Novák, Ph.D.

vedoucí ústavu

Prohlášení

Prohlašuji, že svou diplomovou práci jsem vypracoval samostatně jako pů- vodní dílo s použitím uvedené literatury a na základě konzultací s vedou- cím mé diplomové práce a konzultantem.

Jsem si vědom toho, že na mou diplomovou práci se plně vztahuje zákon č. 121/2000 Sb., o právu autorském, zejména § 60 – školní dílo.

Beru na vědomí, že Technická univerzita v Liberci nezasahuje do mých au- torských práv užitím mé diplomové práce pro vnitřní potřebu Technické univerzity v Liberci.

Užiji-li diplomovou práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom povinnosti informovat o této skutečnosti Technickou univerzi- tu v Liberci; v tomto případě má Technická univerzita v Liberci právo ode mne požadovat úhradu nákladů, které vynaložila na vytvoření díla, až do jejich skutečné výše.

Současně čestně prohlašuji, že text elektronické podoby práce vložený do IS/STAG se shoduje s textem tištěné podoby práce.

Beru na vědomí, že má diplomová práce bude zveřejněna Technickou uni- verzitou v Liberci v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách a o změně a doplnění dalších zákonů (zákon o vysokých školách), ve znění pozdějších předpisů.

Jsem si vědom následků, které podle zákona o vysokých školách mohou vyplývat z porušení tohoto prohlášení.

9. dubna 2020 Bc. Lukáš Vosecký

Podˇ ekov´ an´ı

Chtˇel bych pˇredevˇs´ım podˇekovat vedouc´ımu m´e diplomov´e pr´ace panu Mgr. Jiˇr´ımu Vran´emu, Ph.D. za podporu, vstˇr´ıcnost a mo- tivaci k lepˇs´ım v´ysledk˚um. D´ale bych r´ad podˇekoval Ing. Jaku- bovi Vanclovi, kter´y byl mou oporou po celou dobu m´e st´aˇze ve Skoda Auto. V neposledn´ı ˇradˇˇ e dˇekuji Karlovi Tvrzn´ıkovi, Milanovi Such´emu a J´anovi Such´emu za cenn´e rady a z´ıskan´e zkuˇsenosti.

Zpracov´ an´ı velk´ ych dat logistiky v automotive

Abstrakt

Tato pr´ace ˇreˇs´ı probl´em zpracov´an´ı, transformace a pˇrenosu dat z platformy Splunk do data lake Cloudera Hadoop a n´aslednˇe do Power BI. C´ılem pr´ace je navrh- nout a implementovat univerz´aln´ı a pˇrenositelnou aplikaci v jazyce Python, kter´a bude tento probl´em ˇreˇsit. Na z´akladˇe anal´yz moˇznost´ı komunikace v´yˇse zm´ınˇen´ych syst´em˚u je vytvoˇrena univerz´aln´ı aplikace, kter´a se skl´ad´a z nˇekolika Python skript˚u.

Univerz´alnost a pˇrenositelnost je zajiˇstˇena t´ım, ˇze se pro jin´y zdroj dat ze Splunku bude mˇenit pouze jeden konfiguraˇcn´ı skript a ostatn´ı z˚ustanou beze zmˇeny. Navrˇzen´a aplikace byla nasazena do produkce a ´uspˇeˇsnˇe ˇreˇs´ı prvn´ı use case pro sklad logistiky, kter´y je v t´eto pr´aci pops´an.

Kl´ıˇ cov´ a slova:

zpracov´an´ı, transformace a pˇrenos velk´ych dat, big data, Splunk, Python, Cloudera Hadoop, Power BI

Automotive Logistic Big Data Analysis

Abstract

The issue discussed in this work concerns processing, transforming and transferring of data from Splunk platform to Cloudera Hadoop data lake and then to Power BI.

The main goal of this work is to design and implement a universal and transferable application in Python language which is supposed to solve this issue. The universal

application consisting of several Python scripts is based on analyses of communi- cation capabilities between the systems mentioned above. For any other source of Splunk type data, there is only one configuration script that needs to be changed, hence the needs of universality and transferability are met. The application was put into production and is now solving first use case in a logistic warehouse which is described in this work.

Key words:

processing, transforming and transferring of big data, big data, Splunk, Python, Cloudera Hadoop, Power BI

Obsah

Seznam obr´azk˚u. . . 10

Seznam zkratek . . . 11

Uvod´ 12 1 Big Data 14 1.1 Historie . . . 15

1.2 Souˇcasn´y stav . . . 16

1.2.1 Pˇrek´aˇzky . . . 17

1.2.2 Datov´a ´uloˇziˇstˇe . . . 17

1.2.3 Datov´a anal´yza . . . 21

2 N´astroje pro big data 23 2.1 Splunk . . . 23

2.1.1 Nasazen´ı Splunku . . . 24

2.1.2 Search Processing Language . . . 25

2.1.3 Pouˇzit´ı . . . 25

2.1.4 Dalˇs´ı vlastnosti . . . 27

2.2 Apache Hadoop . . . 27

2.2.1 Hadoop ekosyst´em - z´akladn´ı moduly . . . 27

2.2.2 Hadoop ekosyst´em - pˇr´ıdavn´e moduly . . . 29

2.2.3 Hadoop distribuce . . . 31

2.3 Power BI. . . 31

3 N´avrh ˇreˇsen´ı 33 3.1 Souˇcasn´y stav . . . 33

3.2 Anal´yza zp˚usobu komunikace mezi syst´emy . . . 34

3.2.1 Pˇrenos dat ze Splunku do Cloudera Hadoop . . . 35

3.2.2 Pˇrenos dat ze serveru do Cloudery Hadoop . . . 37

3.2.3 Pˇrenos dat z Hadoop do Power BI . . . 37

3.2.4 Pˇrenos logovan´ych event˚u do Splunku. . . 38

3.3 N´avrh univerz´aln´ı aplikace . . . 38

4 Implementace ˇreˇsen´ı 40 4.1 Implementace datov´eho toku . . . 40

4.2 Vytvoˇren´a aplikace . . . 42

4.3 Logov´an´ı a testov´an´ı ˇreˇsen´ı. . . 48

4.3.1 Logov´an´ı ud´alost´ı . . . 48 4.3.2 Testov´an´ı k´odu . . . 50 4.4 Kontrola datov´eho toku a v´ysledn´a anal´yza dat . . . 52

5 Z´avˇer 56

A Obsah pˇriloˇzen´eho CD 60

Seznam obr´ azk˚ u

1.1 3 V’s of big data. Pˇrevzato z [4].. . . 16

2.1 Vzorov´y model Splunk architektury . . . 24

2.2 Uk´azka v´ysledku vyhled´av´an´ı z testovac´ıho datasetu . . . 25

2.3 Cloudera Hadoop ekosyst´em. Pˇrevzato z [16]. . . 30

4.1 Sch´ema datov´eho toku . . . 40

4.2 Sch´ema aplikace . . . 42

4.3 Sch´ema datov´eho modelu . . . 47

4.4 Uk´azka ´uspˇeˇsn´ych event˚u odeslan´ych do Splunku . . . 49

4.5 Uk´azkov´a vizualizace 1. Data byla upravena. . . 54

4.6 Uk´azkov´a vizualizace 2. Data byla upravena. . . 55

Seznam zkratek

TB Terabyte

BI Business Intelligence SW Software

SQL Structured Query Language

CAP Consistency, Availability and Partition Tolerance ACID Atomicity, Consistency, Isolation and Durability DML Data Manipulation Language

DDL Data Definition Language

RDBMS Relational Database Management System DW Data Warehouse

DL Data Lake

ODBC Open Database Connectivity SPL Search Processing Language HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

Uvod ´

Pojem big data v souˇcasn´e dobˇe nem´a sjednocenou a ust´alenou definici. Existuje jich v´ıce, jelikoˇz kaˇzd´y m˚uˇze vn´ımat vlastnosti velk´ych dat trochu jinak. Dle m´eho n´azoru je nejl´epe vystihuj´ıc´ı Gartnerova definice: Velk´a data jsou velkoobjemov´a, rychl´a a/nebo r˚uznorod´a informaˇcn´ı aktiva, kter´a vyˇzaduj´ı n´akladovˇe efektivn´ı, ino- vativn´ı formy zpracov´an´ı informac´ı, kter´e umoˇzˇnuj´ı lepˇs´ı pˇrehled, rozhodov´an´ı a au- tomatizaci proces˚u [3]. Podrobnˇejˇs´ı vysvˇetlen´ı se nach´az´ı d´ale v kapitole 1.

Dle [1] je pojem big data v souˇcasnosti velice pouˇz´ıvan´y oproti pˇredchoz´ım rok˚um. At’ uˇz jde o automobilov´y nebo jin´y pr˚umysl, tento pojem se v r˚uzn´ych odvˇetv´ıch vyskytuje ˇcasto. V n´avaznosti na to nen´ı ´uplnˇe probl´em big data z´ıskat nebo je generovat. Probl´em spoˇc´ıv´a v jejich zpracov´an´ı a obecnˇe v manipulaci s nimi.

Existuje mnoho syst´em˚u, kter´e dok´aˇz´ı big data zpracov´avat, ukl´adat a trans- formovat. Spr´avn´y v´ybˇer syst´emu z´avis´ı na v´ıce ukazatel´ıch, napˇr´ıklad na cenov´e dostupnosti, zkuˇsenostech se syst´emy, jejich spoleˇcn´e komunikaci a podobnˇe. V t´eto pr´aci se jedn´a o n´asleduj´ıc´ı: Splunk pro z´ısk´av´an´ı dat a jejich prvotn´ı parsov´an´ı a vi- zualizaci, Cloudera Hadoop pro jejich ukl´ad´an´ı a Power BI pro koncovou datovou anal´yzu.

Tato pr´ace se zab´yv´a pˇrenosem, zpracov´an´ım a transformac´ı dat pr´avˇe mezi tˇemito syst´emy za ´uˇcelem z´ısk´an´ı dat ze Splunku do data lake Cloudera Hadoop pro jejich ukl´ad´an´ı a n´aslednˇe z´ısk´an´ı z data lake do Power BI. Jak je pops´ano v kapitole3.2, je v´ıce zp˚usob˚u, jak toho doc´ılit. C´ılem je zautomatizovat cel´y proces z´ısk´av´an´ı dat ze Splunku do Cloudera Hadoop. To hlavnˇe z d˚uvodu zamezen´ı moˇzn´e chybovosti pˇri ruˇcn´ım exportov´an´ı dat (do csv soubor˚u), uˇsetˇren´ı pr´ace, n´aklad˚u a ˇcasu. Tato ´uskal´ı spolu s pˇresnˇejˇs´ım popisem ruˇcn´ıho z´ısk´av´an´ı dat ze Splunku

jsou pops´ana v kapitole 3.1.

Vytvoˇren´a aplikace v jazyce Python ˇreˇs´ı prvn´ı pˇrenos dat mezi syst´emem Splunk a Cloudera Hadoop. D˚uraz byl kladen na univerz´alnost a pˇrenositelnost aplikace. To je z toho d˚uvodu, ˇze pˇrenos˚u dat pro r˚uzn´e aplikace (myˇsleno r˚uzn´a data z r˚uzn´ych syst´em˚u) bude pˇrib´yvat. V t´eto pr´aci byl ˇreˇsen pˇrenos dat konkr´etnˇe pro sklad logistiky.

V z´avˇeru pr´ace je vytvoˇrena datov´a anal´yza v Power BI pro otestov´an´ı funkˇcnosti cel´eho datov´eho toku a z´akladn´ı uk´azkov´a vizualizace.

1 Big Data

Co vlastnˇe term´ın big data znamen´a? Na to nen´ı bohuˇzel v souˇcasnosti jednoduch´e odpovˇedˇet. V dneˇsn´ı dobˇe je to velice pouˇz´ıvan´y term´ın, kter´y nab´yv´a na popularitˇe.

Souˇcasn´a spoleˇcnost je obklopena velk´ym mnoˇzstv´ım zaˇr´ızen´ı vˇseho moˇzn´eho druhu, kter´a velk´a data generuj´ı nebo jiˇz zpracov´avaj´ı.

Definice

Definice big data m´a za sebou dlouh´y v´yvoj vzhledem k v´yvoji technologi´ı a spoleˇcnosti. V souˇcasnosti neexistuje jednotn´a ust´alen´a definice. Mnoho vˇedeck´ych pracovn´ık˚u a ˇreditel˚u spoleˇcnost´ı zavedlo sv´e definice na z´akladˇe analytick´ych pˇr´ıstup˚u nebo pro sv´a vyuˇzit´ı velk´ych dat. Napˇr´ıklad dle ´utvaru Leadership Coun- cil for Information Advantage je big data souhrn nekoneˇcn´ych dataset˚u (sestaven´a pˇrev´aˇznˇe z nestrukturovan´ych dataset˚u) [2]. Tato definice se zamˇeˇruje prim´arnˇe na velikost dat, coˇz je obecn´y probl´em v tˇechto definic´ıch, protoˇze tato definice unik´atnˇe nedefinuje big data od jin´eho datasetu. Jak je pops´ano v kapitole1.1, charakteristik jako velikost dat je v´ıce a proto existuj´ı lepˇs´ı definice, neˇz je tato. Gartnerova definice je pravdˇepodobnˇe nejl´epe vystihuj´ıc´ı charakteristikou big data: Velk´a data jsou vel- koobjemov´a, rychl´a a/nebo r˚uznorod´a informaˇcn´ı aktiva, kter´a vyˇzaduj´ı n´akladovˇe efektivn´ı, inovativn´ı formy zpracov´an´ı informac´ı, kter´e umoˇzˇnuj´ı lepˇs´ı pˇrehled, roz- hodov´an´ı a automatizaci proces˚u [3].

Ovˇsem z definice nevypl´yv´a pˇresn´a velikost dat, jen jejich vlastnosti. Nen´ı totiˇz pˇresnˇe definov´ano, jak´y objem dat je povaˇzov´an za big data. Lze ovˇsem pˇredpokl´adat, ˇze by se mohlo jednat o des´ıtky TB a v´ıce.

Business Inteligence

Stejnˇe jako big data, BI nem´a jednotnou definici. Tento term´ın si opˇet proˇsel velk´ym v´yvojem, ovˇsem prvn´ı zm´ınka byla v roce 1958 ze spoleˇcnosti IBM [6]. Jedna z mnoha definic je napˇr´ıklad tato: BI je framework sest´avaj´ıc´ı z mnoˇziny koncept˚u, teori´ı a metod pro vylepˇsen´ı obchodn´ıho rozhodov´an´ı skrze pomocn´e syst´emy [7]. Zjed- noduˇsenˇe ˇreˇceno, jedn´a se o sadu n´astroj˚u, kter´e pracuj´ı s daty za ´uˇcelem interpretace v´ysledk˚u. Pˇr´ıkladem jsou n´astroje Power BI, SAP BI, Splunk a dalˇs´ı.

1.1 Historie

Prvn´ı zm´ınka o term´ınu big data poch´az´ı z roku 1980. V´yzkumn´ıci z Oxford English Discovery zjistili, ˇze sociolog Charles Tilly byl prvn´ım ˇclovˇekem, kter´y pouˇzil term´ın big data v jedn´e vˇetˇe sv´eho ˇcl´anku. Zaj´ımavost´ı je, ˇze jiˇz v roce 1944 Fremont Ryder spekuloval o tom, ˇze v roce 2040 bude m´ıt knihovna Yale 200 mili´on˚u z´aznam˚u kv˚uli explozi informac´ı.

Mezi lety 1997 a 2000 byl term´ın big data pouˇz´ıv´an v r˚uzn´ych akademick´ych ˇcl´anc´ıch. Avˇsak v roce 2001 pˇriˇsel prvn´ı zlomov´y bod ohlednˇe tohoto term´ınu. Byla to takzvan´a

”3 V’s of big data. High-volume, High-velocity and High-variety.“ Auto- rem je Doug Laney [3]. Doug Laney poukazuje na velikost dat (high-volume), rych- lost, kterou jsou data generov´ana (high-velocity) a r˚uznorodost dat (high-variety).

Modifikace modelu 3 V’s je 4 V’s, kter´a pˇriˇsla v roce 2011 od spoleˇcnosti IBM.

Volume, Velocity a Variety z˚ust´avaj´ı, ale je k nim nav´ıc pˇrid´ano Veracity, coˇz znaˇc´ı kvalitu dat, kter´a jsou dostupn´a k anal´yze. Pokud je low veracity, znamen´a to, ˇze se v datech nach´az´ı vˇetˇs´ı procento nepotˇrebn´ych nebo nezaj´ımav´ych ´udaj˚u. Do toho vstupuj´ı i chybˇej´ıc´ı ´udaje a podobnˇe.

Je moˇzn´e ˇr´ıci, ˇze rok 2005 byl pro term´ın big data zlomov´y. V roce 2005 Tim O’reilly publikoval ˇcl´anek

”What is web 2.0“, ve kter´em byl pouˇzit term´ın big data v modern´ım kontextu [5]. Z´aroveˇn v tento rok byl vytvoˇren Framework Hadoop spoleˇcnost´ı Yahoo!. Hadoop byl nasazen nad jiˇz existuj´ıc´ı model MapReduce od spoleˇcnosti Google, kter´y byl vytvoˇren v roce 2004. Obˇe tyto technologie jsou kl´ıˇcov´e

pro pr´aci s velk´ymi daty.

Obr´azek 1.1: 3 V’s of big data. Pˇrevzato z [4].

Probl´em v dob´ach bez tˇechto syst´em˚u spoˇc´ıval v tom, ˇze se data dala pouze z´ısk´avat, ale nebylo moˇzn´e s nimi d´ale efektivnˇe nakl´adat. Neexistovaly ˇz´adn´e pro- pracovan´e syst´emy pro jejich zpracov´an´ı jako Hadoop a MapReduce. Tyto techno- logie pˇriˇsly aˇz v nadch´azej´ıc´ıch letech.

N´asleduj´ıc´ı roky pˇrich´azely vyhled´avac´ı syst´emy, NoSQL datab´aze a dalˇs´ı, o kter´ych je naps´ano v dalˇs´ıch kapitol´ach.

1.2 Souˇ casn´ y stav

Big data jsou spojena s velk´ymi datasety a s velikost´ı dat, kter´a je nad r´amec flexi- bility bˇeˇzn´ych relaˇcn´ıch datab´az´ı k z´ısk´an´ı, uloˇzen´ı, zpracov´an´ı a vyhodnocen´ı dat.

V dneˇsn´ım digit´aln´ım svˇetˇe jsou data generov´ana z r˚uzn´ych zdroj˚u a velkou rych- lost´ı pˇremist’ov´ana z jednoho m´ısta na druh´e. Anal´yza velk´ych dataset˚u umoˇznila obrovsk´y posun v mnoha odvˇetv´ıch.

1.2.1 Pˇ rek´ aˇ zky

Soukrom´ı

Soukrom´ı je jednou z nejvˇetˇs´ıch pˇrek´aˇzek nejen v oblasti velk´ych dat. Naprost´a vˇetˇsina lid´ı m´a obavy ohlednˇe zpracov´an´ı jejich osobn´ıch informac´ı. Jak bylo jiˇz zm´ınˇeno, big data jsou vˇsude kolem n´as a zaˇr´ızen´ı, kter´a lid´e vlastn´ı, je vyuˇz´ıvaj´ı.

Pˇr´ıkladem by mohla b´yt anal´yza z´akazn´ık˚u na z´akladˇe nakupovac´ıch vzor˚u: kde z´akazn´ıci nakupuj´ı, co nakupuj´ı a za kolik penˇez. To uˇz samozˇrejmˇe supermarkety v dneˇsn´ı dobˇe vyuˇz´ıvaj´ı pomoc´ı karet pro z´akazn´ıky.

ˇSum v datech

Bohuˇzel data nejsou vˇzdy ˇcist´a a proto je potˇreba je od ˇsumu vyˇcistit. Tomuto procesu ˇciˇstˇen´ı dat se ˇr´ık´a data cleansing nebo data wragling. Jde o situaci, kdy v atributech nˇekter´e hodnoty chybˇej´ı, nebo kdy obsahuj´ı hodnoty, kter´e tam nepatˇr´ı (nˇekter´e jsou nav´ıc) a podobnˇe. ˇCasto se stane, ˇze z vˇetˇs´ı mnoˇziny dat je ve v´ysledku znatelnˇe menˇs´ı mnoˇzina. Jde v podstatˇe o takovou hru, kdy se hled´a jen to podstatn´e a data se r˚uznˇe transformuj´ı do pˇrehlednˇejˇs´ı podoby.

1.2.2 Datov´ a ´ uloˇ ziˇ stˇ e

Pravdˇepodobnˇe nejjednoduˇsˇs´ım zp˚usobem ukl´ad´an´ı dat v poˇc´ıtaˇc´ıch je st´ale uloˇzen´ı do souboru. K tomu nen´ı zapotˇreb´ı ˇz´adn´y speci´aln´ı SW, pouze textov´y nebo bin´arn´ı soubor. Nen´ı potˇreba ˇz´adn´e speci´aln´ı pˇripojen´ı, staˇc´ı m´ıt pˇr´ıstup k souboru a pr´ava zapisovat do nˇej. Nev´yhodou se st´av´a nekonzistence dat souboru a jeho n´asledn´e pro- hled´av´an´ı. Pˇri zvˇetˇsuj´ıc´ı se velikosti souboru je obt´ıˇznˇejˇs´ı jeho zpracov´an´ı. V dneˇsn´ı dobˇe se kv˚uli big data mluv´ı o NoSQL datab´az´ıch, pˇritom souˇcasn´e klasick´e relaˇcn´ı datab´aze jsou mnohdy lepˇs´ım ˇreˇsen´ım.

Relaˇcn´ı datab´aze

Relaˇcn´ı datab´aze maj´ı za sebou dlouhou historii v´yvoje, a t´ım p´adem stoj´ı na pevn´e p˚udˇe. Jedna z jejich nejvˇetˇs´ıch v´yhod je dotazovac´ı jazyk SQL. Ten m´a pevn´y mate- matick´y z´aklad, a proto jsou v mnoha pˇr´ıpadech relaˇcn´ı datab´aze lepˇs´ım ˇreˇsen´ım neˇz NoSQL. Relaˇcn´ı datab´aze je typ datab´aze, kter´a ukl´ad´a a zprostˇredkov´av´a pˇr´ıstup datov´ym bod˚um, kter´e jsou spoleˇcnˇe propojeny. Z´aroveˇn jsou zaloˇzeny na relaˇcn´ım modelu, coˇz je intuitivn´ı pˇr´ımoˇcar´a cesta reprezentov´an´ı dat v tabulk´ach. [8]

V´yhody:

• SQL

• Pevnˇe dan´a struktura

• Rozs´ahl´a komunita

• Transakce

• Rychlost vyhled´av´an´ı Nev´yhody:

• Vertik´aln´ı ˇsk´alovatelnost (vyˇsˇs´ı cena)

• Pˇri r˚ustu objemu dat roste sloˇzitost udrˇzitelnosti a flexibility

NoSQL datab´aze

Datab´aze NoSQL (Not only SQL) je datab´aze, kter´a se pouˇz´ıv´a pro ukl´ad´an´ı velk´eho mnoˇzstv´ı dat. Datab´aze jsou distribuovan´a, nerelaˇcn´ı, open source a horizont´alnˇe ˇsk´alovan´a [9]. Jsou navrˇzena pro distribuovan´a datov´a ´uloˇziˇstˇe. V souˇcasn´e dobˇe se neukl´adaj´ı pouze data ve formˇe textu. Je potˇreba uloˇzit soci´aln´ı vazby (grafy), geo- grafick´a data, logy syst´em˚u (kdy jejich velikost ˇcasto exponenci´alnˇe roste), a pr´avˇe proto jsou navrˇzeny NoSQL datab´aze. Pravdˇepodobnˇe nejvˇetˇs´ı nev´yhodou oproti relaˇcn´ım datab´az´ım je absence transakc´ı ve vˇetˇsinˇe NoSQL datab´az´ı. Zde plat´ı tak- zvan´y CAP teor´em. CAP teor´em znamen´a konzistenci, dostupnost a odd´ılovou to- leranci.

• Konzistence: Data dostupn´a na vˇsech stroj´ıch po aktualizac´ıch a dalˇs´ıch akc´ıch

• Dostupnost: Data mus´ı b´yt vˇzdy dostupn´a

• Odd´ıln´a tolerance: Po dobu chybovosti stroje nebo nˇejak´e chyby datab´aze mus´ı fungovat v bˇeˇzn´em reˇzimu bez zastaven´ı ˇcinnosti

Bohuˇzel nelze splnit vˇsechny tˇri moˇznosti, a proto se vol´ı kombinace po dvou dle poˇzadavk˚u. Typicky se vol´ı kombinace konzistence a dostupnosti.

V´yhody:

• Moˇznost volen´ı datab´aze dle datov´eho modelu

• Nevyˇzaduj´ı pevn´e sch´ema datab´aze

• Podpora nestrukturovan´ych dat a nepˇredv´ıdateln´ych dat Nev´yhody:

• Nepouˇz´ıvaj´ı se JOIN operace

• Nem´a deklarativn´ı dotazovac´ı jazyk

• Pˇr´ıpadn´a konzistence upˇrednostnˇena pˇred ACID vlastnostmi

Dokumentovˇe orientovan´e NoSQL datab´aze

Dle pr˚uzkumu StackOverflow z roku 2019 je nejrozˇs´ıˇrenˇejˇs´ı NoSQL datab´az´ı Mon- goDB z t´eto kategorie [10]. Na rozd´ıl od relaˇcn´ıch datab´az´ı, kde jsou data uloˇzena v tabulk´ach, dokumentovˇe orientovan´e datab´aze maj´ı dokumenty. Dokumenty lze zhruba pˇrirovnat k ˇr´adk˚um v tabulce, ale s t´ım rozd´ılem, ˇze dokumenty jsou mno- hem v´ıce flexibiln´ı, protoˇze jsou bez pˇredem dan´eho sch´ematu (schema-less). Doku- menty b´yvaj´ı standardn´ıho form´atu (xml, json). Zde je opˇet vidˇet velk´y rozd´ıl od relaˇcn´ıch datab´az´ı, protoˇze jsou ˇr´adky v tabulce ˇcasto identick´e (myˇsleno v ide´aln´ım pˇr´ıpadˇe, kdy jsou data konzistentn´ı a napˇr´ıklad v atributu datum se opravdu nach´az´ı datum), kdeˇzto v pˇr´ıpadˇe dokumentovˇe orientovan´ych datab´az´ı m˚uˇze b´yt struktura jednotliv´ych dokument˚u naprosto odliˇsn´a, ale tak´e v´ıce ˇci m´enˇe podobn´a [11].

Grafov´e datab´aze

Grafov´e datab´aze jsou v podstatˇe zaloˇzeny na teorii graf˚u. Grafy jsou sloˇzeny z vr- chol˚u, hran a jejich ohodnocen´ım (vztah). V tˇechto datab´az´ıch vrcholy znamenaj´ı entity, ohodnocen´e hrany mezi vrcholy znaˇc´ı atributy a hrany reprezentuj´ı vztah mezi vrcholy.

V relaˇcn´ıch datab´az´ıch je obrovsk´y probl´em naznaˇcit vztahy mezi objekty, a to je pr´avˇe silnou str´ankou grafov´ych datab´az´ı. Pravdˇepodobnˇe nejzn´amˇejˇs´ım pˇr´ıkladem je datab´aze Neo4j [12].Ta umoˇzˇnuje efektivn´ı grafov´e zpracov´an´ı v re´aln´em ˇcase pomoc´ı pˇr´ım´eho indexovan´eho pˇr´ıstupu k sousedn´ım uzl˚um z dan´eho uzlu [13].

Nˇekter´e grafovˇe orientovan´e datab´aze mohou splˇnovat ACID. Ovˇsem vznik´a ot´azka za jakou cenu. Pointa pouˇz´ıv´an´ı NoSQL datab´az´ı je v jejich s´ıle ˇsk´alovatelnosti a pr´ace s big daty, ovˇsem pokud jsou pouˇzity ”levnˇe”, jsou NoSQL datab´aze pouˇzity jako alternativa k RDBMS.

Datab´aze typu kl´ıˇc-hodnota

Jak n´azev napov´ıd´a, data jsou uloˇzena v p´aru kl´ıˇc hodnota. Dalo by se ˇr´ıci, ˇze tento typ datab´az´ı je v podstatˇe rodiˇcem vˇsech NoSQL datab´az´ı [11]. Kl´ıˇc je unik´atn´ı identifik´ator k dan´ym dat˚um. Nejpouˇz´ıvanˇejˇs´ım z´astupcem tohoto typu datab´aze je dle dotazn´ıku Redis [10]. Z´aroveˇn je to dle hodnocen´ı nejv´ıce obl´ıben´a datab´aze mezi v´yvoj´aˇri.

Data Warehouse

Data warehouse (DW) je velkokapacitn´ı ´uloˇziˇstˇe, kter´e je um´ıstˇeno nad datab´azemi.

Je navrˇzeno pro ukl´ad´an´ı stˇrednˇe velk´ych strukturovan´ych dat pro ˇcast´e a opakovan´e anal´yzy. ˇCast´e vyuˇzit´ı DW je ke sdruˇzov´an´ı dat z v´ıce zdroj˚u. Nˇekter´e DW jsou schopn´e pracovat s nestrukturovan´ymi daty, ale nen´ı to bˇeˇzn´e. Protoˇze jsou data strukturovan´a, sch´ema je determinov´ano jeˇstˇe pˇred t´ım, neˇz mohou b´yt data pˇrid´ana do DW.

Charakteristiky:

• Data jsou typicky nahr´av´ana z transakˇcn´ıch syst´em˚u a z´aroveˇn jsou oˇciˇstˇena

• Zachycuje data a organizuje do sch´emat

• Sch´ema je definov´ano jeˇstˇe pˇred t´ım, neˇz se data nahraj´ı

• Pouˇzit´ı pro generov´an´ı report˚u a dashboard˚u

Typick´ymi z´astupci DW jsou SAP Bussiness Warehouse, Snowflake a Oracle Exadata Database Machine.

Data Lake

Data lake (DL) je centralizovan´e ´uloˇziˇstˇe navrˇzen´e pro ukl´ad´an´ı strukturovan´ych i nestrukturovan´ych dat jak´ehokoliv typu a bez velikostn´ıch limit˚u. Typicky se data pˇrenesou rovnou ze syst´em˚u, kter´e je generuj´ı, pˇr´ımo do DL bez jak´ekoliv ´upravy.

Kaˇzd´emu datov´emu elementu DL pˇriˇrad´ı unik´atn´ı identifik´ator, kter´y je uloˇzen, a n´aslednˇe umoˇzˇnuje lehˇc´ı vyhled´av´an´ı pomoc´ı dotaz˚u. DL je sp´ıˇse povaˇzov´an za big data platformu pro nestrukturovan´a data.

Charakteristiky:

• Data jsou typicky nestrukturovan´a, ve sv´e p˚uvodn´ı podobˇe

• Ide´aln´ı ´uloˇziˇstˇe pro hlubok´e anal´yzy nestrukturovan´ych dat s pomoc´ı analy- tick´ych n´astroj˚u, strojov´eho uˇcen´ı a podobnˇe

• Sch´ema je definov´ano aˇz po uloˇzen´ı dat. D´ıky tomu nen´ı potˇrebn´a prvotn´ı reˇzie a d˚usledkem je vyˇsˇs´ı flexibilita

Typick´ymi pˇredstaviteli DL jsou Hadoop, Microsoft Azure Data Lake, Amazon AWS Data Lake.

1.2.3 Datov´ a anal´ yza

Datov´a anal´yza je proces, kter´y pˇrinese dat˚um smysl [14]. Obecnˇe se skl´ad´a z nˇekolika krok˚u, kter´e na sebe navazuj´ı. Z´aroveˇn se mohou jednotliv´e kroky mˇenit

v z´avislosti na tom, jestli jsou data strukturovan´a nebo nestrukturovan´a, pokud jsou jiˇz dopˇredu pˇripraven´a a podobnˇe. Pokud data nejsou nijak oˇciˇstˇen´a, to znamen´a, ˇze jsou v p˚uvodn´ı podobˇe, je prvn´ım krokem oˇciˇstˇen´ı dat. To je proces, kdy je potˇreba proj´ıt velkou ˇc´ast´ı datasetu, naj´ıt chybˇej´ıc´ı a nepotˇrebn´a data, duplicitn´ı hodnoty, anom´alie a nˇejak´ym zp˚usobem napravit tyto nedostatky. Zde je potˇreba zn´at kaˇzd´y atribut a v´yznam cel´eho datasetu, jelikoˇz odstranˇen´ı nˇekter´ych atribut˚u, byt’ je- jich hodnoty mohou b´yt napˇr´ıklad nˇekde pr´azdn´e a podobnˇe, m˚uˇze b´yt kritickou chybou pro datovou anal´yzu. V dalˇs´ım kroku prob´ıh´a anal´yza kvality datasetu po- moc´ı statistick´ych metod, jako v´ypoˇcet medi´anu, smˇerodatn´e odchylky a podobnˇe.

V tomto kroku se zjist´ı, jak je dataset rozloˇzen a jak´e m´a vlastnosti. N´aslednˇe jiˇz m˚uˇze prob´ıhat samotn´a datov´a anal´yza pomoc´ı analytick´ych n´astroj˚u jako Splunk 2.1, Power BI 2.3 a dalˇs´ı.

2 N´ astroje pro big data

V t´eto kapitole jsou pops´any n´astroje, kter´e jsou pouˇzity v t´eto pr´aci. N´astroj˚u exis- tuje v´ıce, ale c´ılem bylo propojit pr´avˇe tyto konkr´etn´ı n´astroje pro pr´aci s velk´ymi daty.

2.1 Splunk

Splunk je softwarov´a platforma, kter´a slouˇz´ı prim´arnˇe ke zpracov´an´ı a vizualizaci typicky strojov´ych dat (napˇr´ıklad data ze senzor˚u, robot˚u, komunikaˇcn´ıch proto- kol˚u (MQ, MQTT) a dalˇs´ı). Splunk akceptuje t´emˇeˇr jak´ykoliv form´at dat hned po instalaci. Jin´ymi slovy, Splunk nem´a pevnˇe definovan´e sch´ema. Naopak prov´ad´ı ex- trakci atribut˚u v ˇcase hled´an´ı. Mnoho datov´ych form´at˚u je rozpozn´ano ihned (json, csv...), ty kter´e nejsou, mohou b´yt specifikov´any v konfiguraˇcn´ıch souborech nebo aˇz pˇri hledac´ıch v´yrazech. Splunk je tedy n´astroj pro vyhled´an´ı, anal´yzu a reporting velk´eho mnoˇzstv´ı dat, typicky strojov´ych dat v re´aln´em ˇcase. Tento n´astroj je op- timalizovan´y pro rychl´e indexov´an´ı a naˇc´ıt´an´ı perzistentn´ıch nestrukturovan´ych dat do syst´emu. Splunk je n´astroj, kter´y prim´arnˇe pouˇz´ıv´a logy. Z´aroveˇn nemus´ı fungo- vat jako n´astroj pro reporting v re´aln´em ˇcase, i kdyˇz v tom je jeho velk´a s´ıla. Soubory do nˇej mohou b´yt nahr´any jednotlivˇe pro jedno´uˇcelov´e datov´e anal´yzy. Bˇehem f´aze indexov´an´ı, kdy Splunk zpracov´av´a pˇr´ıchoz´ı data, indexer udˇel´a velk´y z´asah: oddˇel´ı od sebe jednotliv´e ud´alosti, kdy jedna ud´alost koresponduje s jedn´ım z´aznamem v souboru. Kaˇzd´e ud´alosti pˇrid´a timestamp a nˇekter´e dalˇs´ı atributy jako napˇr´ıklad stroj, ze kter´eho z´aznam poch´az´ı. Pot´e jsou kl´ıˇcov´a slova ud´alosti pˇrid´ana do in- dexov´eho souboru pro zrychlen´ı pozdˇejˇs´ıho vyhled´av´an´ı a samotn´e textov´e ud´alosti

jsou komprimov´any do soubor˚u pˇr´ımo v souborov´em syst´emu.

2.1.1 Nasazen´ı Splunku

Nasazen´ı spoˇc´ıv´a v tom, ˇze se nainstaluje forwarder na m´ısto (typicky server), kde je uloˇzen log soubor. Tento forwarder pˇrepos´ıl´a data z logu do indexeru. Indexer je kom- ponenta, kter´a je um´ıstˇena jiˇz na Splunk serveru, a kter´a efektivnˇe uchov´av´a data na nˇejakou definovanou dobu. Tato data jsou indexov´ana pro rychl´e vyhled´av´an´ı a nad nimi je jiˇz pouˇzita fin´aln´ı komponenta search head, pomoc´ı kter´e se prov´ad´ı anal´yza dat. Vzorov´y model by mohl vypadat napˇr´ıklad takto.

Obr´azek 2.1: Vzorov´y model Splunk architektury

Na tomto modelu lze vidˇet, ˇze kaˇzd´a aplikace m´a sv˚uj vlastn´ı forwarder. To je z toho d˚uvodu, ˇze instalace forwarderu je um´ıstˇena k samotn´ym log˚um. Z´aroveˇn jiˇz

na forwarderu se mohou filtrovat data, kter´a m´a pos´ılat indexeru, coˇz je pro kaˇzdou aplikaci jinak. Indexer jiˇz nemus´ı b´yt jin´y pro r˚uzn´e aplikace.

2.1.2 Search Processing Language

Tento jazyk obsahuje mnoho pˇr´ıkaz˚u, funkc´ı a argument˚u, kter´e jsou naps´any tak, aby bylo pouˇzit´ı co nejjednoduˇsˇs´ı a z´aroveˇn efektivn´ı za ´uˇcelem z´ısk´an´ı poˇzadovan´ych v´ysledk˚u z dat. Existuj´ı n´asleduj´ıc´ı komponenty SPL:

Hledan´e v´yrazy

To jsou konkr´etn´ı v´yrazy, kter´e jsou ps´any ve vyhled´avac´ım boxu pro z´ısk´an´ı speci- fick´ych z´aznam˚u z dat, kter´a splˇnuj´ı dan´a krit´eria.

1 index=* host="bro_http" 404 | table time src url

Zdrojov´y k´od 1: Uk´azka SPL na testovac´ı dataset

Tento search job prohled´a vˇsechny indexy. Host se oznaˇcuje konkr´etn´ı zdroj zaˇr´ızen´ı. Najde ud´alosti, ve kter´ych se vyskytuje ˇretˇezec 404, a n´aslednˇe data pˇretransformuje do podoby n´asleduj´ıc´ı tabulky.

Obr´azek 2.2: Uk´azka v´ysledku vyhled´av´an´ı z testovac´ıho datasetu

2.1.3 Pouˇ zit´ı

Splunk je v´yraznˇe pouˇz´ıvan´y ve velk´ych spoleˇcnostech, typicky tam, kde jsou v´yrobn´ı linky. Forwarder je nasazen na ´uloˇzn´ych m´ıstech, kde jsou ukl´ad´any logy, at’ uˇz

z v´yrobn´ıch syst´em˚u nebo z jin´eho m´ısta. Pˇri nˇejak´e zmˇenˇe, nebo v definovan´ych intervalech forwarder pos´ıl´a data do Splunku, kde prob´ıh´a datov´a anal´yza a jej´ı v´ysledky jsou zobrazeny pomoc´ı graf˚u, statistik a tabulek v reportech, dashboardech a alertech.

Reporty

Reporty jsou v´ysledky vyhled´avac´ıch dotaz˚u, kter´e mohou zobrazit statistiky a vizu- alizace ud´alost´ı. Reporty mohou b´yt spuˇstˇeny kdykoliv a mohou zachytit nejnovˇejˇs´ı data pˇri kaˇzd´em spuˇstˇen´ı. Z´aroveˇn mohou b´yt sd´ıleny s ostatn´ımi uˇzivateli a hlavnˇe mohou b´yt pˇrid´any do dashboard˚u.

Dashboardy

Dashboard je kolekce objekt˚u (report˚u, odkaz˚u a podobnˇe). Umoˇzˇnuj´ı n´am kom- binovat v´ıce report˚u dohromady, a t´ım ucelit pˇr´ıbˇeh dat na jedno velk´e pl´atno.

Dashboard se skl´ad´a z panel˚u, kter´e v sobˇe maj´ı grafy, statistiky a podobnˇe, coˇz jsou jednotliv´e reporty.

Alerty

Alerty jsou akce, kter´e se spust´ı pˇri specifick´e ud´alosti, kdy jsou splnˇeny urˇcit´e podm´ınky definovan´e uˇzivatelem. C´ılem alert˚u je z´ıskat napˇr´ıklad logov´an´ı akc´ı, kter´e jsou nˇejak´ym zp˚usobem kritick´e a tyto alerty odeslat pomoc´ı e-mailu nebo na specifick´y endpoint.

Casovaˇˇ ce

Casovaˇˇ ce slouˇz´ı k nastaven´ı trigger˚u pro spouˇstˇen´ı report˚u automaticky bez uˇzivatelsk´eho z´asahu. Ty mohou b´yt dle definice spouˇstˇeny v r˚uzn´ych interva- lech: mˇes´ıˇcnˇe, t´ydnˇe, dennˇe nebo pro specifick´y ˇcasov´y rozsah. T´ım m˚uˇze doj´ıt k zlepˇsen´ı v´ykonu (rychlosti) v dashboardech pˇri otevˇren´ı uˇzivatelem. ˇCasovaˇce dis- ponuj´ı moˇznost´ı automatick´eho zas´ılan´ı reportu po skonˇcen´ı ˇcinnosti.

2.1.4 Dalˇ s´ı vlastnosti

Splunk disponuje mnoha addony a sadami n´astroj˚u, kter´e se daj´ı pˇridat k z´akladn´ı verzi. Nˇekter´e jsou samozˇrejmˇe placen´e. Zaj´ımav´e addony pro Splunk jsou napˇr´ıklad Splunk Analytics for Hadoop - pro ucelen´e vyhled´av´an´ı a analyzov´an´ı Hadoop dat se Splunk Enterprise. N´aslednˇe r˚uzn´e konektory pro pˇr´ıpojen´ı k datab´azi (ODBC, DB Connect), mobiln´ı addon a Amazon Web Services [15]

Velmi zaj´ımav´y n´astroj pro Splnuk je Splunk Machine Learning Toolkit, kter´y disponuje knihovnami pro machine learning a Pythonem spolu s knihovnami Pandas, NumPy, SciKit, SciPy a dalˇs´ımi. T´ımto zp˚usobem je moˇzn´e vyˇreˇsit situaci z´ısk´an´ı dat ze Splunku pro machine learning.

2.2 Apache Hadoop

Apache Hadoop je framework, kter´y umoˇzˇnuje distribuovan´e zpracov´an´ı velk´ych da- taset˚u napˇr´ıˇc clustery s vyuˇzit´ım jednoduch´ych programovac´ıch model˚u. Je navrˇzen pro ˇsk´alov´an´ı od jednoho serveru aˇz k tis´ıc˚um stroj˚u, kde kaˇzd´y z nich nab´ız´ı lok´aln´ı komunikaci a ukl´ad´an´ı. Abychom se nemuseli spol´ehat na hardware pro doruˇcen´ı vy- sok´e dostupnosti, Hadoop je navrˇzen tak, aby detekoval a vyˇreˇsil selh´an´ı na aplikaˇcn´ı vrstvˇe. Z´akladn´ı myˇslenka je takov´a, ˇze se data rozdˇel´ı a uloˇz´ı napˇr´ıˇc kolekc´ı stroj˚u (cluster). Pot´e je na ˇradˇe pr´ace s daty na m´ıstˇe, kde jsou skuteˇcnˇe uloˇzena. Tedy v tomto pˇr´ıpadˇe uˇz v clusteru. V t´eto f´azi je jednoduch´e pˇrid´avat stroje do clusteru dle r˚ustu dat.

2.2.1 Hadoop ekosyst´ em - z´ akladn´ı moduly

Hadoop se skl´ad´a z mnoha modul˚u, nˇekter´e jsou povinn´e a nˇekter´e lze pˇrid´avat a odeb´ırat dle potˇreby ˇreˇsen´ı.

Hadoop HDFS

Hadoop HDFS je distribuovan´y souborov´y syst´em, kter´y pracuje s velk´ymi datasety.

Je to nejspodnˇejˇs´ı vrstva cel´eho Hadoop ekosyst´emu pro ukl´ad´an´ı dat. Data mohou b´yt t´emˇeˇr v jak´ekoliv formˇe (json, csv, txt, ...).

Soubor, nahran´y do HDFS, je rozdˇelen do nˇekolika blok˚u o velikosti 64 MB (z´akladn´ı velikost), kde kaˇzd´y blok dostane sv´e unik´atn´ı jm´eno. Po nahr´an´ı souboru do clusteru bude kaˇzd´y blok uloˇzen do jednoho nodu v clusteru. Na kaˇzd´em stroji v clusteru bˇeˇz´ı takzvan´y DataNode. O tom, jak´ym zp˚usobem z´ısk´ame z rozdˇelen´ych blok˚u zpˇet p˚uvodn´ı soubor, se star´a NameNode. Informace uloˇzen´e v NameNode se naz´yvaj´ı Metadata. V r´amci bezpeˇcnosti existuje kopie NameNodu pro pˇr´ıpad v´ypadku hlavn´ıho NameNodu. Dalˇs´ı bezpeˇcnostn´ı prvek je takov´y, ˇze Hadoop vy- tvoˇr´ı tˇri kopie kaˇzd´eho bloku souboru a n´ahodnˇe je rozdˇel´ı do tˇrech nod˚u.

Jeden z hlavn´ıch c´ıl˚u HDFS je rychl´e zotaven´ı z hardwarov´ych chyb. Protoˇze jedna HDFS instance se m˚uˇze skl´adat z nˇekolika tis´ıc server˚u, selh´an´ı nˇekter´eho z nich je nevyhnuteln´e. HDFS byl postaven tak, aby detekoval tato selh´an´ı a au- tomaticky se z nich zotavil. Jin´ymi slovy, HDFS a ostatn´ı hlavn´ı moduly Hadoopu pˇredpokl´adaj´ı, ˇze hardwarov´e chyby mohou nastat, a t´ım p´adem jsou pˇripraveny na rychl´e a automatick´e zotaven´ı.

Hadoop YARN

Z´akladn´ı myˇslenkou Yarnu je rozdˇelen´ı funkcionalit ˇr´ızen´ı zdroj˚u a pl´anovaˇce ´uloh na rozdˇelen´e daemony. Myˇslenka je takov´a, ˇze existuje jeden centr´aln´ı spr´avce zdroj˚u a potom pro kaˇzd´y daemon jeden aplikaˇcn´ı spr´avce.

Hadoop MapReduce

MapReduce je model pro paraleln´ı zpracov´an´ı velk´eho mnoˇzstv´ı dat. Jelikoˇz s´eriov´e zpracov´an´ı velk´eho souboru je pomal´e, MapReduce je navrˇzen tak, aby zpracov´aval data paralelnˇe. Soubor je tedy rozdˇelen do blok˚u a kaˇzd´y je z´aroveˇn zpracov´av´an.

MapReduce se rozdˇeluje na dvˇe ˇc´asti. Prvn´ı je mapovac´ı, kdy se nejdˇr´ıve seskup´ı spoleˇcn´e atributy s hodnotami (key, value) podle kl´ıˇce. Takto seskupen´e ˇc´asti jsou n´aslednˇe dle ´ulohy posl´any na redukˇcn´ı ˇc´ast, kde jsou data jiˇz seˇrazena a pˇripravena k fin´aln´ı ´upravˇe. Napˇr´ıklad, mˇejme dataset mˇest s obchody a jejich trˇzbami. V ma- povac´ı ˇc´asti se seskup´ı stejn´a mˇesta (key) a jejich trˇzby. N´aslednˇe takto setˇr´ıdˇen´a mˇesta jsou zvl´aˇst’ posl´ana redukˇcn´ı ˇc´asti, kde kaˇzd´y

”reducer“ poˇc´ıt´a roˇcn´ı trˇzby pro jedno mˇesto.

Psan´ı MapReduce k´odu je podporov´ano jazyky Python, Java, Ruby a dalˇs´ımi.

Hadoop Common

Hadoop Common je kolekce bˇeˇzn´ych utilit a knihoven, kter´e podporuj´ı ostatn´ı mo- duly. Je to nezbytn´a ˇc´ast cel´eho frameworku spolu s Yarn, MapReduce a HDFS.

Je br´an jako z´akladn´ı/kl´ıˇcov´y modul cel´eho frameworku, protoˇze zprostˇredkov´av´a z´akladn´ı sluˇzby jako napˇr´ıklad abstrakci operaˇcn´ıho syst´emu, na kter´em je fra- mework nasazen, a i jeho souborov´eho syst´emu.

2.2.2 Hadoop ekosyst´ em - pˇ r´ıdavn´ e moduly

Pˇr´ıdavn´ych modul˚u je opravdu mnoho, proto jsou zde vyps´any pouze ty nejzn´amˇejˇs´ı, kter´e jsou s touto prac´ı do jist´e m´ıry spjaty.

Psan´ı MapReduce k´odu nen´ı ´uplnˇe snadn´e (je vyˇzadov´ana znalost nˇekter´eho programovac´ıho jazyku podporovan´eho MapReduce - Java, Python apod.). Proto vznikly n´astroje jako je Impala a Hive. Nam´ısto psan´ı k´odu tyto n´astroje umoˇzˇnuj´ı vyuˇz´ıt SQL pro dotazov´an´ı. Dalˇs´ı moˇznost´ı je Pig, kter´y umoˇzˇnuje analyzovat data pomoc´ı jednoduch´eho skriptovac´ıho jazyku.

Impala

Apache Impala je paralelnˇe zpracov´avaj´ıc´ı SQL dotazovac´ı n´astroj pro data, kter´a jsou uloˇzena v clusteru bˇeˇz´ıc´ım na Apache Hadoop. Impala podporuje HDFS

i Apache HBase, d´ale podporuje autentizaci pomoc´ı Kerberos. Nejvˇetˇs´ı v´yhoda Im- paly je zp˚usob dotazov´an´ı na HDFS. Impala totiˇz nevyuˇz´ıv´a MapReduce, a tedy se dotazuje na pˇr´ımo. T´ım dojde k uˇsetˇren´ı ˇcasu pro startov´an´ı MapReduce. Pouˇz´ıv´a se tedy pro rychl´e anal´yzy nebo pro velk´e datasety. ˇCasto je Impala pouˇz´ıv´ana jako n´astroj pro z´ısk´an´ı dat do Power BI pomoc´ı direct query.

Hive

Hive je pomalejˇs´ı alternativa k Impala, a to z d˚uvodu vyuˇzit´ı MapReduce. Hive interpreter pˇremˇen´ı SQL na MapReduce k´od, kter´y je pot´e spuˇstˇen na clusteru.

Jin´ymi slovy, pˇri kaˇzd´em dotazu je nutn´e spustit MapReduce job. Coˇz m˚uˇze b´yt opravdu pomal´e pˇri velk´em mnoˇzstv´ı dat. Proto se Hive sp´ıˇse pouˇz´ıv´a pˇri menˇs´ım mnoˇzstv´ı dat, nebo u aplikac´ı, kde nez´aleˇz´ı na ˇcase dokonˇcen´ı. Hive je optimalizovan´y pro spouˇstˇen´ı dlouh´ych batch-processing jobs.

Hue

Apache Hue je open source online editor, kter´y slouˇz´ı pro pr´aci s daty uloˇzen´ymi v HDFS pomoc´ı SQL. Umoˇzˇnuje pouˇz´ıt nˇekolik interpretr˚u (Impala, Hive, MySQL, SparkSQL a dalˇs´ı). Z´aroveˇn umoˇzˇnuje generov´an´ı graf˚u a statistik.

Obr´azek 2.3: Cloudera Hadoop ekosyst´em. Pˇrevzato z [16].

2.2.3 Hadoop distribuce

Propojit vˇsechny tyto pˇr´ıdavn´e modely dohromady s hlavn´ımi ˇc´astmi Hadoop eko- syst´emu je obecnˇe celkem n´aroˇcn´e. Vˇsechny moduly Hadoop ekosyst´emu jsou open- source. Jen nˇekter´e moduly spolu nejsou kompatibiln´ı a m˚uˇze nastat hodnˇe kompli- kac´ı. Proto existuj´ı jiˇz r˚uzn´e distribuce, napˇr´ıklad CDH, kter´a zabal´ı cel´y ekosyst´em s pˇr´ıdavn´ymi moduly dohromady pro snadnou instalaci.

Cloudera

Spoleˇcnost Cloudera vlastn´ı Hadoop distribuci nesouc´ı n´azev Cloudera distribution including Apache Hadoop (CDH). Je to open source platformn´ı distribuce zahrnuj´ıc´ı Apache Hadoop, kter´a je postavena tak, aby splˇnovala poˇzadavky spoleˇcnost´ı. Tato distribuce z´aroveˇn obsahuje mnoho dalˇs´ıch kritick´ych open source projekt˚u, kter´e s Hadoop souvis´ı. Obsahuje tedy Hadoop core, Hive, HBase, Impala, Hue a mnoho dalˇs´ıch [17]. Z´aroveˇn obsahuje syst´emy, kter´e pom´ahaj´ı s integrac´ı dat a cel´eho syst´emu.

mapR

Alternativn´ı distribuc´ı je mapR. Jedn´a se o v´ıce univerz´aln´ı distribuci, protoˇze nen´ı postaven´a ˇcistˇe na HDFS. MapR m´a sv˚uj vlastn´ı souborov´y syst´em, MAPRFS. To pˇrin´aˇs´ı sv´e v´yhody, hlavnˇe co se t´yˇce bezpeˇcnosti.

2.3 Power BI

Power BI je n´astroj od spoleˇcnosti Microsoft, kter´y se pouˇz´ıv´a pro datovou anal´yzu.

Skl´ad´a se z mnoha konektor˚u, sluˇzeb a aplikac´ı. Je moˇzn´e ho pouˇz´ıt v podobˇe desk- topov´e nebo mobiln´ı aplikace. Power BI disponuje mnoha konektory pro naˇcten´ı dat, jako naˇcten´ı ze souboru, z datab´aze nebo z cloudov´e ˇci jin´e datov´e plat- formy. Napˇr´ıklad pro Hadoop existuje Power BI konektor pro Impalu. Protoˇze je objem dat ˇcasto velk´y a kaˇzd´a aktualizace dat (napˇr´ıklad z datab´aze) trv´a delˇs´ı

dobu (v z´avislosti na objemu dat), Power BI disponuje takzvan´ym direct query. To umoˇzˇnuje naˇc´ıtat data ze zdroje definovan´y ˇcas (pouze nov´a data).

Pr´ace s Power BI pˇri tvorbˇe report˚u je celkem intuitivn´ı, ale z´aroveˇn to neub´ır´a na

´

uˇcinnosti. To stejn´e plat´ı i pro naˇc´ıt´an´ı dat z r˚uzn´ych zdroj˚u. Pˇri pr´aci se souborem (napˇr´ıklad csv), Power BI pozn´a oddˇelovaˇc a podle nˇej rozdˇel´ı jednotliv´e atributy.

Pokud by ho n´ahodou nerozpoznal, je moˇzn´e ho ruˇcnˇe urˇcit.

Pˇri pr´aci s mal´ym objemem dat nebude v desktopov´e verzi probl´em. Pr´ace s vˇetˇs´ım poˇctem dat m˚uˇze b´yt uˇz limituj´ıc´ı. Napˇr´ıklad pˇri pr´aci s nˇekolika GB dat z datab´aze se m˚uˇze zd´at, ˇze aktualizace graf˚u je ponˇekud pomal´a. Je to z toho d˚uvodu, ˇze po vytvoˇren´ı datov´ych pˇripojen´ı a transformaci dat, jsou data naˇctena do datov´eho modelu pˇr´ımo do aplikace. Jedna z hlavn´ıch pˇrednost´ı Power BI jsou propo- jen´e komponenty v jednom reportu. To znamen´a, ˇze pokud jsou v reportu vytvoˇreny vizualizace (graf, tabulka) a z´aroveˇn nˇejak´e filtrov´an´ı, tak se potom pˇrenese filtrov´an´ı na kaˇzdou vizualizaci. Z´aroveˇn vytvoˇren´ych report˚u m˚uˇze b´yt v´ıce a nˇekter´e (nebo vˇsechny) komponenty a filtry mohou b´yt pouˇzity napˇr´ıˇc jednotliv´ymi reporty.

3 N´ avrh ˇ reˇ sen´ı

V t´eto kapitole je vysvˇetleno, jak´y je souˇcasn´y stav z´ısk´av´an´ı dat ze Splunku pro sklad logistiky. S t´ım souvis´ı pops´an´ı situac´ı, ve kter´ych vznik´a chybovost. N´aslednˇe je pops´ano, jak´e jsou moˇznosti komunikace mezi pouˇzit´ymi syst´emy. Z t´eto anal´yzy jsou vybr´any nejlepˇs´ı zp˚usoby, kter´e jsou n´aslednˇe aplikov´any.

3.1 Souˇ casn´ y stav

Ve skladu logistiky jsou autonomn´ı roboti, kteˇr´ı vykl´adaj´ı boxy do reg´al˚u a tak´e je nakl´adaj´ı na p´as. Z´aroveˇn ukl´adaj´ı sv´e stavy a chyby do soubor˚u. Tyto soubory jsou prohled´av´any a jejich data jsou nahr´av´ana pomoc´ı Splunk forwarderu do Splunku, kde prob´ıh´a datov´a anal´yza. Probl´em je v tom, ˇze pˇr´ıstup ke Splunku je do jist´e m´ıry omezen a pr´ace s n´ım vyˇzaduje pokroˇcil´e znalosti. Jin´ymi slovy, tvorba report˚u ve Splunku nen´ı tak jednoduch´a, jako napˇr´ıklad v Power BI. To znamen´a, ˇze reporty a dashboardy ve Splunku tvoˇr´ı skupina datov´ych specialist˚u. To stejn´e plat´ı pro jejich sebemenˇs´ı zmˇeny. Dalo by se totiˇz ˇr´ıct, ˇze Splunk nen´ı urˇcen´y prim´arnˇe pro business view.

Konkr´etnˇe se jedn´a o chyby pˇri vykl´ad´an´ı box˚u a jejich dalˇs´ı manipulaci. Ve Splunku jsou data oˇciˇstˇena a parsov´ana do pouˇziteln´e podoby pro n´asledn´e vykreslen´ı tabulek a graf˚u. Vˇzdy na konci smˇeny (tedy po 8 hodin´ach: 6:00, 14:00, 22:00) zamˇestnanec pˇristoup´ı ke Splunku, exportuje naparsovan´a a oˇciˇstˇen´a data do souboru typu csv, kter´y st´ahne a nahraje do pˇredem definovan´e sloˇzky s urˇcit´ym n´azvem. V t´eto sloˇzce se n´aslednˇe soubory nahr´avaj´ı do Power BI. Tento proces je velice neefek- tivn´ı a zdlouhav´y. Pˇri tomto procesu vznik´a z´aroveˇn velk´a chybovost. Exportovan´e

soubory mus´ı b´yt vˇzdy na konci smˇeny uloˇzeny na stanoven´e m´ısto s pˇredem defino- van´ym jm´enem. ˇCasto se st´av´a, ˇze tato krit´eria nejsou dodrˇzena a n´aslednˇe vznikaj´ı dalˇs´ı probl´emy. Prim´arnˇe z tohoto d˚uvodu vznikla tato pr´ace, aby byl cel´y tento proces efektivnˇejˇs´ı a univerz´aln´ı. To znamen´a jak´akoliv data ze Splunku uloˇzit do data lake a n´aslednˇe je z´ıskat do platformy Power BI.

Kritick´a m´ısta pro tento use case jsou tedy n´asleduj´ıc´ı:

• Sloˇzit´a tvorba report˚u ve Splunku (je potˇreba skupina datov´ych specialist˚u)

• Ukl´ad´an´ı souboru na spr´avn´e m´ısto

• Zad´av´an´ı spr´avn´eho n´azvu exportovan´eho csv souboru

• ˇCas trv´an´ı ruˇcn´ıho exportov´an´ı souboru

• ˇCas str´aven´y opravou po pˇr´ıpadn´em chybn´em uloˇzen´ı souboru

Kromˇe prvn´ıho bodu jsou ostatn´ı zp˚usoben´e lidskou chybou, kterou bohuˇzel nelze vˇzdy ovlivnit. Pakliˇze soubor nen´ı na spr´avn´em m´ıstˇe se spr´avn´ym jm´enem, nelze ho automaticky nahr´at do Power BI. Je tedy potom potˇreba soubor naj´ıt a napravit chybu.

Ovˇsem obecnˇe se jedn´a o to, ˇze pokud jsou potˇreba data ze Splunku z´ıskat, v souˇcasn´e situaci je vˇzdy potˇreba data ruˇcnˇe st´ahnout. Jde tedy o automatizaci cel´eho tohoto procesu z´ısk´av´an´ı csv soubor˚u pro libovoln´y datov´y zdroj ze Splnuku.

3.2 Anal´ yza zp˚ usobu komunikace mezi syst´ emy

Na ´upln´em zaˇc´atku je vˇzdy potˇreba zanalyzovat syst´emy, kter´e spolu budou nˇejak´ym zp˚usobem komunikovat. V t´eto pr´aci se jedn´a hlavnˇe o syst´em Splunk, Cloudera Ha- doop a Power BI. Existuje nˇekolik zp˚usob˚u, jak pˇren´aˇset data mezi tˇemito syst´emy.

Vzhledem k tomu, ˇze data jsou jiˇz odes´ıl´ana pomoc´ı Splunk forwarderu na Splunk indexy, staˇc´ı se v tomto pˇr´ıpadˇe zamˇeˇrit na ˇc´ast pˇren´aˇsen´ı dat mezi Splunkem, Clouderou Hadoop a n´aslednˇe Power BI. Data ze Splunku do Cloudery Hadoop lze pˇren´est v´ıce zp˚usoby.

3.2.1 Pˇ renos dat ze Splunku do Cloudera Hadoop

Hadoop connector

Prvn´ı moˇznost´ı je odl´evat data pˇr´ımo ze Splunku do data lake (Cloudera Hadoop) a z nˇej pot´e pomoc´ı Impala connectoru do Power BI. Tato moˇznost je pravdˇepodobnˇe nejv´ıce pˇr´ımoˇcar´a a zd´a se nejjednoduˇsˇs´ı. Ovˇsem m´a to sv´e nev´yhody. Tou nejvˇetˇs´ı nev´yhodou je zat´ıˇzen´ı Splunku pˇri odl´ev´an´ı dat. Uˇz v t´eto situaci je relativnˇe zat´ıˇzen a pˇri dalˇs´ı vˇetˇs´ı z´atˇeˇzi by se mohl zpomalit cel´y jeho chod, coˇz by mˇelo kritick´y do- pad, jelikoˇz je pouˇz´ıv´an nejen pro anal´yzu tohoto skladu, ale pro v´ıce aplikac´ı. Zvl´aˇst’

kdyˇz jsou chyby generov´any v podstatˇe kaˇzdou minutu.

Z t´eto kritick´e negativn´ı vlastnosti vyplynulo zam´ıtnut´ı t´eto metody pro tuto apli- kaci. Nicm´enˇe tuto metodu je moˇzn´e pouˇz´ıt pro doc´ılen´ı jin´e potˇreby. Nejvˇetˇs´ı z´atˇeˇz totiˇz nespoˇc´ıv´a v samotn´em odl´ev´an´ı dat, ale jiˇz v parsov´an´ı dat. Tedy pokud se pouze odl´evaj´ı nezpracovan´a raw data nebo s minim´aln´ı ´upravou, lze tento zp˚usob vyuˇz´ıt jako z´alohu dat, jelikoˇz ve Splunk indexerech data z˚ust´avaj´ı pˇribliˇznˇe mˇes´ıc (konfigurovateln´a doba).

Splunk REST API

Splunk disponuje REST API, pomoc´ı kter´eho lze z´ısk´avat data, zakl´adat alerty a podobnˇe. Velkou v´yhodu tohoto API je to, ˇze ho vystavuj´ı i Splunk frontend nody, takˇze zjednoduˇsenˇe ˇreˇceno, pˇripojen´ı pomoc´ı API nezatˇeˇzuje hlavn´ı backen- dov´y Splunk node.

Splunk nab´ız´ı jiˇz pˇripraven´e bal´ıˇcky pro pr´aci s REST API pro jazyky Python, Java a dalˇs´ı, kter´e velice usnadˇnuj´ı pr´aci [18]. V t´eto pr´aci je pouˇzit bal´ıˇcek pro Python.

Tento bal´ıˇcek v sobˇe obsahuje ˇreˇsen´ı pro autentizaci, autorizaci, z´ısk´av´an´ı dat, zakl´ad´an´ı alert˚u, odes´ıl´an´ı soubor˚u do Splunku a dalˇs´ı. D´av´a tedy nejvˇetˇs´ı smysl pouˇz´ıt pr´avˇe toto ˇreˇsen´ı.

Bal´ıˇcek nab´ız´ı celkem ˇctyˇri moˇzn´e metody, pomoc´ı kter´ych lze z´ısk´avat data:

• Blocking search. Tento typ vyhled´av´an´ı umoˇzˇnuje vytvoˇrit search job, kter´y bˇeˇz´ı synchronnˇe v takzvan´em blokovac´ım m´odu. To znamen´a, ˇze se job vr´at´ı

aˇz pot´e, co se z´ıskaj´ı vˇsechny v´ysledky. Z job objektu lze pot´e z´ıskat v´ıce informac´ı. Napˇr´ıklad, jak dlouho job trval, kolik bylo vr´aceno event˚u, jak´e bylo pˇriˇrazeno job ID a dalˇs´ı.

• Normal search. Normal search vytvoˇr´ı klasick´y search job, stejnˇe jako bloc- king search. Rozd´ıl je v tom, ˇze normal search vr´at´ı ihned search ID, pomoc´ı kter´eho je nutn´e vyhledat search job a n´aslednˇe ho st´ahnout. Ovˇsem opˇet se mus´ı ˇcekat, neˇz se search job dokonˇc´ı.

• One-shot search. Toto je ta nejjednoduˇsˇs´ı a nejpˇr´ımoˇcaˇrejˇs´ı metoda. Jedn´a se o to, ˇze se vytvoˇr´ı takzvan´y jedno´uˇcelov´y search. Na rozd´ıl od ostatn´ıch metod nevytv´aˇr´ı a nevrac´ı search job, ale naopak se zablokuje, dokud nen´ı search dokonˇcen a nen´ı vr´acen stream obsahuj´ıc´ı eventy. To tak´e ale znamen´a, ˇ

ze nejsou vr´aceny informace o searchi. Je vr´acen pouze stream event˚u a pokud nˇekde nastane nˇejak´a chyba (napˇr´ıklad v parsov´an´ı dat nebo v samotn´em searchi), tak Splunk vr´at´ı chybovou hl´aˇsku, kter´a se m˚uˇze napˇr´ıklad zalogovat.

Tato metoda je z tˇechto d˚uvod˚u v pr´aci pouˇzita, jelikoˇz je ze searche z´ısk´ano to nejpodstatnˇejˇs´ı - moˇzn´a chybov´a hl´aˇska a nebo tok event˚u.

• Export search. Export search je ta nejv´ıce spolehliv´a metoda, kterou lze z´ıskat vˇetˇs´ı mnoˇzstv´ı dat, protoˇze se eventy vrac´ı jako tok dat na rozd´ıl od ostatn´ıch metod popsan´ych v´yˇse, kdy je na serveru po nˇejakou dobu uloˇzen search job. Takˇze jak´ekoliv limitace ze strany serveru, co se t´yˇce objemu dat, pro tuto metodu neplat´ı. Export search se spust´ı okamˇzitˇe a z´aroveˇn hned po spuˇstˇen´ı zaˇcne pˇren´aˇset data klientovi.

Tedy Splunk REST API bylo nakonec vybr´ano jako implementaˇcn´ı ˇreˇsen´ı pro tuto ˇc´ast z´ısk´av´an´ı dat z d˚uvodu velk´eho mnoˇzstv´ı zp˚usob˚u, jak s daty pracovat a z´aroveˇn z d˚uvodu menˇs´ıho zat´ıˇzen´ı Splunku. Toto REST API bude komunikovat se Splunkem z linuxov´eho serveru, kde budou um´ıstˇeny Python skripty, generuj´ıc´ı csv soubor.

3.2.2 Pˇ renos dat ze serveru do Cloudery Hadoop

V dalˇs´ım kroku je potˇreba soubor ze serveru nahr´at do Cloudery Hadoop. To lze doc´ılit pomoc´ı UC4 jobu.

UC4 job

UC4 je software pro pl´anovan´e spouˇstˇen´ı job˚u, d´ıky kter´emu lze napˇr´ıklad pˇren´aˇset soubory napˇr´ıˇc architekturami a ´uloˇziˇsti. M´a mnoho konfigurovateln´ych parametr˚u.

V t´eto pr´aci je pouˇzit pr´avˇe na pˇrenos csv souboru z linuxov´eho serveru, kde csv vznik´a, na c´ılov´y linuxov´y server, kde se csv ukl´ad´a do Cloudery Hadoop. Pˇr´ıklady konfigurovateln´ych parametr˚u jsou napˇr´ıklad smaz´an´ı souboru po pˇrenosu, moˇznost zaslat informace o chybn´em stavu a dalˇs´ı. Tento zp˚usob byl vybr´an z d˚uvodu jiˇz otestovan´e funkˇcnosti na jin´ych projektech.

3.2.3 Pˇ renos dat z Hadoop do Power BI

Opˇet je zde v´ıce moˇznost´ı, jak doc´ılit poˇzadovan´eho pˇrenosu. Existuje totiˇz v´ıce connector˚u a kaˇzd´y z nich funguje trochu jinak. Pro uk´azku jsou zde uvedeny dva pˇr´ıklady, z toho Impala connector je pouˇzit v t´eto pr´aci.

ODBC

Klasick´y ODBC connector nab´ız´ı pouze z´akladn´ı jednoduch´y import dat. To m˚uˇze b´yt v´yhodn´e, pokud se data v datab´az´ı jiˇz nemˇen´ı nebo se mˇen´ı jen velmi m´alo.

Impala connector

Impala connector je n´astroj, kter´ym lze efektivnˇe z´ısk´avat data z Hadoop, a to hlavnˇe z toho d˚uvodu, ˇze pouˇz´ıv´a optimalizovan´e dotazy pro z´ısk´an´ı dat, jelikoˇz Impala b´yv´a souˇc´ast´ı Hadoop ekosyst´emu. Z´aroveˇn nab´ız´ı takzvan´e DirectQuery, coˇz je automatick´e stahov´an´ı dat pˇri nˇejak´e zmˇenˇe dat v Hadoop. DirectQuery m´a tu v´yhodu, ˇze n´aslednˇe stahuje pouze data, kter´a jsou nov´a nebo zmˇenˇen´a. D´ıky tomu je Power BI pˇri aktualizaci dat rychlejˇs´ı, neˇz kdyby se data naˇc´ıtala pomoc´ı klasick´eho

Importu, kdy se naˇc´ıt´a vˇse. Tento connector bude pouˇzit z d˚uvodu automatick´eho stahov´an´ı nov´ych dat, coˇz je vlastnost, kter´a je jedn´ım z poˇzadavk˚u na funkcionalitu ˇreˇsen´ı.

3.2.4 Pˇ renos logovan´ ych event˚ u do Splunku

Z´akladn´ı myˇslenkou je logovat do souboru vˇzdy po zpracov´an´ı dat, pokud pˇrenos probˇehl ´uspˇeˇsnˇe. To bude platit i ve fin´aln´ı implementaci. Ovˇsem aby se nemusel implementovat nˇejak´y mechanizmus v Pythonu pro zas´ıl´an´ı alert˚u, je moˇzn´e vyuˇz´ıt Splunku pro vizualizaci log˚u aplikace a pˇr´ıpadn´e vytv´aˇren´ı alert˚u.

Prvn´ı moˇznost´ı je instalace forwarderu na serveru, kter´y bude data ze souboru odes´ılat. Tato varianta je pro tento ´uˇcel zbyteˇcnˇe komplikovan´a, jelikoˇz se eventy vytv´aˇr´ı vˇzdy na konci smˇeny (tedy tˇri ˇr´adky za jeden den). Existuje tedy druh´y zp˚usob, mnohem elegantnˇejˇs´ı. Splunk disponuje HTTP Event Collectorem, pomoc´ı kter´eho lze zas´ılat data. To znamen´a, ˇze se data mohou odes´ılat pomoc´ı curl funkce do Splunku pomoc´ı HEC vˇzdy po zalogov´an´ı eventu. Tedy napˇr´ıklad minutu pot´e, co probˇehlo staˇzen´ı dat a vytvoˇren´ı eventu do logu. Toto ˇreˇsen´ı nevyˇzaduje ˇz´adnou dalˇs´ı instalaci komponent (jako v pˇredeˇsl´e moˇznosti instalace forwarderu na server).

Tedy ve Splunku staˇc´ı vytvoˇrit token pro index, do kter´eho se data budou pos´ılat.

N´azev indexu by mˇel odpov´ıdat n´azvu aplikace, kter´a ˇreˇs´ı nˇejak´y probl´em.

V tomto pˇr´ıpadˇe to m˚uˇze b´yt napˇr´ıklad dataextract. V budoucnosti budou pˇrib´yvat aplikace, kter´e toto ˇreˇsen´ı budou pouˇz´ıvat. To znamen´a, ˇze v jednom indexu bude moˇzn´e vidˇet vˇsechny aplikace, kter´e stahuj´ı data ze Splunku. Ty se n´aslednˇe budou moci r˚uznˇe filtrovat.

3.3 N´ avrh univerz´ aln´ı aplikace

Po z´ısk´an´ı dat pomoc´ı REST API je potˇreba data rozparsovat a zapsat do csv sou- boru. Vˇsechno toto zpracov´an´ı dat a ukl´ad´an´ı do souboru prob´ıh´a na linuxov´em serveru.

Idea je takov´a, ˇze budou existovat celkem tˇri python skripty pro z´ısk´an´ı dat a je-

jich ukl´ad´an´ı do souboru csv. Kl´ıˇcov´ym skriptem a teoreticky jedin´ym mˇeniteln´ym by byl konfiguraˇcn´ı skript. V tomto skriptu by byly definov´any ´udaje pro auten- tizaci, samotn´eho search jobu, parsovac´ıch parametr˚u, v´ystupn´ıho souboru a logo- vac´ıho souboru. N´aslednˇe skript pro autentizaci uˇzivatele, kter´y by byl kompletnˇe univerz´aln´ı, jelikoˇz pˇrihlaˇsovac´ı ´udaje by byly definovan´e v konfiguraˇcn´ım souboru.

N´aslednˇe hlavn´ı skript, ve kter´em prob´ıh´a z´ısk´an´ı dat ze Splunku, jejich parsov´an´ı a ukl´ad´an´ı do souboru. V tomto skriptu by se teoreticky nemuselo nic mˇenit, jelikoˇz SPL dok´aˇze dobˇre z´ıskat data pomoc´ı samotn´eho dotazu.

Samotn´e automatizace spouˇstˇen´ı skript˚u lze doc´ılit napˇr´ıklad pomoc´ı cron jobu.

V nˇem se definuje pˇresn´y ˇcas, kdy m´a b´yt skript spuˇstˇen, a t´ım p´adem i ˇcas z´ıskan´eho csv souboru.

4 Implementace ˇ reˇ sen´ı

V t´eto kapitole je pops´ana celkov´a implementace datov´eho toku spolu s vytvoˇrenou univerz´aln´ı aplikac´ı pro z´ısk´av´an´ı dat ze Splunku. Z´aroveˇn s touto aplikac´ı je pops´an logovac´ı syst´em samotn´e aplikace i jej´ı testy.

4.1 Implementace datov´ eho toku

Z anal´yzy pouˇzit´ych syst´em˚u popsan´ych v kapitole 3.2 vypl´yv´a n´asleduj´ıc´ı sch´ema, ve kter´em je zn´azornˇena celkov´a implementace datov´eho toku.

Obr´azek 4.1: Sch´ema datov´eho toku

Cel´y proces transformace dat funguje n´asledovnˇe. Cron job spouˇst´ı hlavn´ı skript, kter´y je popsan´y v kapitole 4.2, vˇzdy na konci smˇeny, tedy 6:01, 14:01 a 22:01 pˇr´ıkazem: python3 main.py –c error codes config.py. Pomoc´ı pˇrep´ınaˇce –c se vybere poˇzadovan´y konfiguraˇcn´ı soubor pro danou aplikaci. Tento soubor je d´ale popsan´y v kapitole 4.2. D´ale se tento soubor importuje do hlavn´ıho skriptu a n´aslednˇe je zavol´an autentizaˇcn´ı skript splunk auth.py, popsan´y v kapitole 4.2, s konfiguraˇcn´ım skriptem ve vstupn´ım parametru. V nˇem se vytvoˇr´ı session, se kterou se d´ale pracuje v hlavn´ım skriptu, ve kter´em prob´ıh´a samotn´e parsov´an´ı dat a ukl´ad´an´ı do csv souboru. Vˇsechny zraniteln´e ˇc´asti k´odu jsou zabalen´e v bloku try except, d´ıky kter´emu nem˚uˇze doj´ıt k neˇcekan´emu stavu aplikace, a se pˇredejde pˇr´ıpadn´emu uloˇzen´ı chybn´ych dat.

Celkov´a doba od z´ısk´an´ı dat aˇz po vytvoˇren´ı csv souboru trv´a pr˚umˇernˇe 5,5 vteˇrin se smˇerodatnou odchylkou 1,75. Tento ˇcasov´y ´udaj byl vypoˇc´ıt´an nad eventy za dobu jednoho mˇes´ıce od nasazen´ı do produkce. D˚uvodem je celkem rozs´ahl´y search job query, kter´y je ve skuteˇcnosti sloˇzen ze dvou a je spojen pomoc´ı operace append.

Pokud by se search job rozdˇelil na dva, bylo by potˇreba vytvoˇrit druh´y konfiguraˇcn´ı soubor a nˇejak´ym zp˚usobem synchronizovat z´apis do jednoho csv souboru. D´ale by byl potˇreba dalˇs´ı cronjob pro spouˇstˇen´ı aplikace s jin´ym konfiguraˇcn´ım souborem.

Doˇslo by tedy k vˇetˇs´ımu rozsahu aplikace pro tento use case, ale bylo by oˇcek´av´ano, ˇze by opravdu doˇslo k rychlejˇs´ımu z´ısk´av´an´ı dat. Bylo totiˇz zmˇeˇreno, ˇze pokud se search query pustily samostatnˇe ve Splunku, pr˚umˇern´a doba z´ısk´an´ı dat byla 2 vteˇriny. Vzhledem k tomu, ˇze je tento ˇcas zanedbateln´y, z˚ustal jako ˇreˇsen´ı jeden search job. V n´asleduj´ıc´ı tabulce je zn´azornˇen rozd´ıl zpracov´an´ı dat ve Splunku a v Pythonu pˇri pouˇzit´ı jednoho search jobu. Tyto hodnoty byly vypoˇc´ıt´any nad eventy za dobu jednoho mˇes´ıce od nasazen´ı do produkce.

Python Splunk Pr˚umˇern´y ˇcas (s) 5,5 6,4 Smˇerodatn´a odchylka 1,75 1,59

Tabulka 4.1: Porovn´an´ı hodnot pro zpracov´an´ı dat ve Splunku a Pythonu

Jakmile je v´ystupn´ı soubor vytvoˇren, UC4 job ho pˇrenese na server Cloudery Ha- doop, kde prob´ıh´a nahr´an´ı do data lake a n´aslednˇe jsou data pˇripravena k pouˇzit´ı.

P˚uvodn´ı soubor je smaz´an, aby se soubory zbyteˇcnˇe nehromadily. Pokud by se n´ahodou stalo, ˇze by doˇslo k jak´emukoliv v´ypadku jednoho z job˚u nebo serveru a podobnˇe, je moˇzn´e vˇzdy csv soubor ruˇcnˇe exportovat ze Splunku a nahr´at ho na sd´ılen´y disk, kde UC4 job tyto soubory v definovan´e ˇcasy nahraje do Cloudery Hadoop. Dalˇs´ı moˇznost´ı je opˇet i ruˇcn´ı import csv soubor˚u do Cloudery Hadoop.

4.2 Vytvoˇ ren´ a aplikace

Vytvoˇren´a aplikace pro tento use case se skl´ad´a celkem z pˇeti python skript˚u. Jak jiˇz bylo zm´ınˇeno, cel´a aplikace je postaven´a tak, aby ji bylo moˇzn´e pˇren´aˇset z jednoho zdroje dat na dalˇs´ı. To ve skuteˇcnosti znamen´a, ˇze pˇri pouˇzit´ı pro jin´y use case je potˇreba zmˇenit pouze jeden skript, a to pr´avˇe ten konfiguraˇcn´ı.

Obr´azek 4.2: Sch´ema aplikace

Pˇreruˇsovanou ˇc´arou je zn´azornˇeno pouˇzit´ı dalˇs´ı aplikace. Tedy je zapotˇreb´ı pouze vytvoˇrit nov´y konfiguraˇcn´ı skript s nov´ymi parametry, a t´ım p´adem je potom novˇe vznikl´y csv soubor bez jak´ychkoliv dalˇs´ıch ´uprav.

Konfiguraˇcn´ı skript

V konfiguraˇcn´ım skriptu pro jin´e datov´e zdroje je moˇzn´e mˇenit n´asleduj´ıc´ı parame- try: samotn´y search job, v´ystupn´ı promˇenn´e ze search jobu, interval pro z´ısk´an´ı dat, v´ystupn´ı soubor a popˇr´ıpadˇe log soubor.

V´ystupn´ımi promˇenn´ymi jsou myˇsleny parametry, kter´e se z cel´eho search jobu na- konec z´ıskaj´ı. Aplikace je totiˇz postaven´a tak, aby Splunk search job mˇel na konci form´atov´an´ı do tabulky. To znamen´a, ˇze search job bude vypadat n´asledovnˇe:

1 index=example_search ... | table

Zdrojov´y k´od 2: Poˇzadovan´y form´at search jobu

Za pˇr´ıkaz table (form´atov´an´ı do tabulky) se n´aslednˇe automaticky vloˇz´ı parame- try, kter´e jsou ruˇcnˇe vloˇzeny do datov´e struktury list pˇred samotn´ym search jobem.

D´ıky tomuto ˇreˇsen´ı je potom v hlavn´ım skriptu moˇzn´e automaticky ukl´adat hodnoty do csv souboru, jelikoˇz n´azvy sloupc˚u jsou totoˇzn´e s tˇemito parametry.

Na v´ystupn´ı soubor jsou kladen´e jist´e n´aroky. T´ım je myˇsleno, ˇze soubor mus´ı b´yt pro integraci do Cloudery Hadoop vˇzdy form´atu csv a k´odov´an´ı utf-8. Pakliˇze by se nˇekdy situace zmˇenila, aplikace je na to pˇripraven´a, jelikoˇz v konfiguraˇcn´ım souboru je oddˇelen´y jak n´azev a k´odov´an´ı souboru, tak i jeho pˇr´ıpona. Dalˇs´ım poˇzadavkem je ukl´ad´an´ı timestampu za n´azev souboru, kter´y pˇredstavuje ˇcas vytvoˇren´ı souboru.

Tedy pro tento konkr´etn´ı use case: cakl errorcodes YYYYMMDDHHmmss.csv, kde cakl je n´azev aplikace, errocodes je n´azev tabulky a na konci je form´at timestampu.

Vkl´ad´an´ı timestampu je opˇet ˇreˇseno automaticky bez ruˇcn´ıho z´asahu.

Autentizaˇcn´ı skript

Tento skript opˇet nevyˇzaduje ˇz´adn´y z´asah. Je volan´y z hlavn´ıho skriptu a jednoduˇse si z´ısk´a ´udaje z konfiguraˇcn´ıho souboru a vytvoˇr´ı si session se Splunk frontend no- dem, kterou n´aslednˇe poˇsle do metody pro z´ısk´an´ı dat. Tato session m´a v z´akladn´ı konfiguraci timeout jednu hodinu, coˇz tedy plat´ı i v tomto pˇr´ıpadˇe. Samozˇrejmˇe je to konfigurovateln´y atribut, kter´y lze zmˇenit v obecn´e konfiguraˇcn´ı sekci serveru.

Nejdˇr´ıve je potˇreba vytvoˇrit Splunk uˇzivatele s pr´avy a rolemi pro REST API a obecnˇe REST API povolit na nˇejak´em nodu (tyto vlastnosti nejsou v´ychoz´ı). Pro vytvoˇren´ı session je potˇreba tedy zn´at jm´eno a heslo Splunk uˇzivatele s rol´ı REST API user, host, port a voliteln´y parametr scheme, coˇz je typ spojen´ı (HTTP nebo HTTPS).

1 NAME = os.path.basename(__file__)

2 def create_instance(config):

3 """ Creates session

4 returns service object

5 """

6 USER = config.user['USERNAME']

7 PWD = config.user['PASSWORD']

8 HOST = config.connection['HOST']

9 PORT = config.connection['PORT']

10 try:

11 service = client.connect(

12 host=HOST,

13 port=PORT,

14 username=USER,

15 password=PWD,

16 scheme="https"

17 )

18 return service

19 except Exception as e:

20 log_event("error", NAME + " " + str(e))

21 sys.exit(1)

Zdrojov´y k´od 3: Vytvoˇren´ı Splunk session

Hlavn´ı skript

Jak bylo jiˇz zm´ınˇeno, v hlavn´ım skriptu se dˇeje hlavn´ı ˇc´ast transformace dat. Vzhle- dem k poˇzadavku na univerz´alnost a pˇrenositelnost ˇreˇsen´ı je naˇc´ıt´an´ı konfiguraˇcn´ıho skriptu ˇreˇseno pomoc´ı parametru pˇri spouˇstˇen´ı hlavn´ıho skriptu. Funkcionalita je uk´az´ana na n´asleduj´ıc´ım bloku k´odu.

1 if __name__ == '__main__':

2 parser = argparse.ArgumentParser(description='Splunk ETL into hadoop')

3 parser.add_argument("--c", type=str,

4 help="Enter python config file with extension", required=True)

5 args = parser.parse_args()

6 config_name = args.c

7

8 if os.path.isfile(config_name):

9 # in case of another location of config file, or for cron usage

10 config_name = config_name.split("/")[-1]

11 # import of config file from args

12 config_name = config_name.split(".")

13 conf = importlib.import_module(config_name[0])

14 else:

15 log_event("error", NAME +

16 " Config file from command line arguments does not exist: " +

17 config_name)

18 sys.exit(1)

Zdrojov´y k´od 4: Naˇcten´ı konfiguraˇcn´ıho souboru

Po z´ısk´an´ı a naˇcten´ı konfiguraˇcn´ıho skriptu je vytvoˇrena Splunk session. Pokud tento proces probˇehl v poˇr´adku, dalˇs´ım krokem je odesl´an´ı pomoc´ı REST API search job a z´ısk´an´ı v´ysledk˚u. Jak bylo zm´ınˇeno v kapitole 3.2.1, pro odesl´an´ı a z´ısk´an´ı dat je pouˇzit oneshot search. Oneshot search potˇrebuje ve vstupn´ıch atributech samotn´y search job a slovn´ık parametr˚u. Mezi tyto parametry patˇr´ı ˇcasov´y interval, ve kter´em se maj´ı data st´ahnout. Tento ´udaj je opˇet br´an z konfiguraˇcn´ıho souboru. Je t´ım myˇslen ˇcas nejstarˇs´ı ud´alosti. Druh´y ˇcasov´y ´udaj je ˇcas nejnovˇejˇs´ı ud´alosti, tedy ˇcas ve chv´ıli, kdy se operace odehr´av´a. N´aslednˇe m´od search jobu, coˇz je v pˇr´ıpadˇe oneshotu normal mode a nakonec limit pro poˇcet event˚u. Tento limit je nepovinn´y parametr a bez jeho definov´an´ı je limit 100 event˚u. Pro z´ısk´an´ı vˇsech event˚u je