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.