Ing. Karel Klouda, Ph.D.
vedoucí katedry doc. RNDr. Ing. Marcel Jiřina, Ph.D.
děkan
ZADÁNÍ BAKALÁŘSKÉ PRÁCE
Název: Big Data architektura pro sběr streamovaných dat
Student: Martin Bendík
Vedoucí: Ing. Barbora Červenková DiS.
Studijní program: Informatika Studijní obor: Znalostní inženýrství
Katedra: Katedra aplikované matematiky Platnost zadání: Do konce letního semestru 2020/21
Pokyny pro vypracování
Cílem práce je navrhnout škálovatelnou architekturu pro sběr a transport velkého množství dat z produkčních serverů, která bude garantovat jejich spolehlivé doručení. Řešení bude podporovat jak batchové (Apache HDFS) tak streamové konzumenty (Apache Kafka).
V teoretické části práce se zaměřte na problematiku sběru velkého množství dat a návrh vhodných řešení používajících aktuální dostupné Big Data technologie.
V praktické části práce otestujte několik z navrhnutých řešení, porovnejte jejich spolehlivost, výkon, škálovatelnost, náročnost na implementaci i provoz a další vlastnosti.
Na základě výsledků porovnání vytvořte funkční prototyp systému založený na vámi zvoleném řešení.
Seznam odborné literatury
Dodá vedoucí práce.
Bakalárska práca
Big Data architektura pro sběr streamovaných dat
Martin Bendík
Katedra Znalostního inženýrství
Vedúci práce: Ing. Barbora Červenková, DiS.
1. júna 2020
Poďakovanie
Chcel by som sa poďakovať vedúcej práce Ing. Barboře Červenkové, DiS.
za ochotné a užitočné pripomienky a venovaný čas pri vedení práce. Ďalej by som rád poďakoval spoločnosti Seznam.cz, a.s, ktorá mi poskytla dáta, vý- počtovú infraštruktúru a priestor venovať sa téme bakalárskej práce. Tiež by som chcel poďakovať aj tímu Cílení v spoločnosti Seznam za zdieľané rady a skúsenosti z praxe.
Prehlásenie
Prehlasujem, že som predloženú prácu vypracoval(a) samostatne a že som uviedol(uviedla) všetky informačné zdroje v súlade s Metodickým pokynom o etickej príprave vysokoškolských záverečných prác.
Beriem na vedomie, že sa na moju prácu vzťahujú práva a povinnosti vyplývajúce zo zákona č. 121/2000 Sb., autorského zákona, v znení neskorších predpisov. V súlade s ustanovením § 46 odst. 6 tohoto zákona týmto udeľujem bezvýhradné oprávnenie (licenciu) k užívaniu tejto mojej práce, a to vrátane všetkých počítačových programov ktoré sú jej súčasťou alebo prílohou a tiež všetkej ich dokumentácie (ďalej len
”Dielo“), a to všetkým osobám, ktoré si prajú Dielo užívať.
Tieto osoby sú oprávnené Dielo používať akýmkoľvek spôsobom, ktorý ne- znižuje hodnotu Diela, a za akýmkoľvek účelom (vrátane komerčného využi- tia). Toto oprávnenie je časovo, územne a množstevne neobmedzené. Každá osoba, ktorá využije vyššie uvedenú licenciu, sa však zaväzuje priradiť kaž- dému dielu, ktoré vznikne (čo i len čiastočne) na základe Diela, úpravou Diela, spojením Diela s iným dielom, zaradením Diela do diela súborného či zpraco- vaním Diela (vrátane prekladu), licenciu aspoň vo vyššie uvedenom rozsahu a zároveň sa zaväzuje sprístupniť zdrojový kód takého diela aspoň zrovnateľ- ným spôsobom a v zrovnateľnom rozsahu ako je zprístupnený zdrojový kód Diela.
V Prahe 1. júna 2020 . . .. . .. . .. . .. . .. . .. . .
© 2020 Martin Bendík. Všetky práva vyhradené.
Táto práca vznikla ako školské dielo na FIT ČVUT v Prahe. Práca je chránená medzinárodnými predpismi a zmluvami o autorskom práve a právach súvisia- cich s autorským právom. Na jej využitie, s výnimkou bezplatných zákonných licencií, je nutný súhlas autora.
Odkaz na túto prácu
Bendík, Martin.Big Data architektura pro sběr streamovaných dat. Bakalárska práca. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2020.
Abstrakt
S rastúcim počtom užívateľov a služieb, ktoré využívajú online, rastie aj množ- stvo dát zaznamenávajúcich ich aktivitu. Tieto dáta sú často neštruktúrované, majú veľký objem a pribúdajú veľmi rýchlo. Typickým príkladom týchto dát sú logy. Záznamy z produkčných logov slúžia na analýzu premávky, správania užívateľov a ich záujmov s cieľom priniesť im čo najrelevantnejší obsah.
Táto práca sa zaoberá problematikou zberu a transportu veľkého množ- stva prúdových dát z produkčných serverov. Predstavuje a popisuje súčasné technológie veľkých dát, dávkové spracovanie a spracovanie v reálnom čase a porovnáva používané architektúry v tejto oblasti.
Súčasťou práce je tiež návrh architektúry určenej na zber a transport logov z produkčnýh serverov do systému na zasielanie správ Apache Kafka a do dis- tribuovaného súborového systému Apache HDFS a implementácia prototypu systému založeného na tejto architektúre.
Klíčová slova veľké dáta, prúdové dáta, logovanie, zber dát, architektúra, Apache Hadoop, Apache Flume, HDFS, Apache Kafka
As the number of users and services they use online grows, so does the amount of data that tracks their activity. These data are often unstructured, large in volume and growing very fast. Logs are a typical example of these data.
Records from production logs are used to analyze traffic, user behavior and interests in order to bring them the most relevant content.
This work deals with the collection and transport of large amounts of stream data from production servers. It presents and describes current Big Data technologies, batch processing and real-time processing and compares the architectures used in this area.
The work also includes the design of an architecture intended to collect and transport logs from production servers to the Apache Kafka messaging system and the distributed file system Apache HDFS, and the implementation of a prototype system based on this architecture.
Keywords Big Data, streaming data, logging, data collection, architecture, Apache Hadoop, Apache Flume, HDFS, Apache Kafka
Obsah
Úvod 1
Úvod do problematiky . . . 1
Cieľ práce . . . 2
Štruktúra práce . . . 2
1 Veľké dáta 3 1.1 História veľkých dát . . . 3
1.2 Čo sú veľké dáta . . . 4
1.3 Dávkové a prúdové spracovanie . . . 5
1.4 Výzvy prúdového spracovania . . . 6
1.4.1 Garancia spracovania dát . . . 6
1.4.2 Spracovanie v (takmer) reálnom čase . . . 7
1.4.3 Poradie spracovania udalostí . . . 7
1.4.4 Windowing . . . 8
1.4.5 Čas vzniku/spracovania . . . 9
2 Nástroje veľkých dát 11 2.1 Apache Hadoop . . . 11
2.1.1 Hadoop Distributed File System (HDFS) . . . 12
2.1.2 Hadoop YARN . . . 13
2.1.3 Hadoop MapReduce . . . 13
2.2 Apache Kafka . . . 14
2.2.1 Architektúra . . . 15
2.3 Transport dát . . . 16
2.3.1 Logovanie . . . 17
2.3.2 Udalosti . . . 17
2.3.3 Apache Flume . . . 17
2.3.4 Logstash . . . 19
2.3.5 Filebeat . . . 20
3.1.1 Výhody a nevýhody . . . 26
3.1.2 Prípady použitia . . . 26
3.2 Kappa . . . 26
3.2.1 Výhody a nevýhody . . . 27
3.2.2 Prípady použitia . . . 27
3.3 Mikroslužby . . . 27
3.3.1 Výhody a nevýhody . . . 28
3.3.2 Prípady použitia . . . 28
3.4 Zeta . . . 29
3.4.1 Výhody a nevýhody . . . 29
3.4.2 Prípady použitia . . . 29
3.5 Iot-a . . . 30
3.5.1 Výhody a nevýhody . . . 31
3.5.2 Prípady použitia . . . 31
3.6 Porovnanie . . . 31
4 Analýza a návrh architektúry 33 4.1 Úvod do problematiky . . . 33
4.1.1 Cielená reklama . . . 34
4.1.2 Clickstream . . . 34
4.1.3 Webový server . . . 34
4.2 Funkcionalita systému . . . 35
4.2.1 Vstupy a výstupy . . . 35
4.2.2 Funkčné požiadavky . . . 35
4.2.3 Nefunkčné požiadavky . . . 36
4.3 Návrh architektúry . . . 36
4.3.1 Vysokoúrovňová architektúra . . . 36
5 Výber transportnej technológie 39 5.1 Skript . . . 40
5.2 Výpočtová infraštruktúra . . . 40
5.2.1 Testovací stroj . . . 40
5.2.2 Kafka cluster . . . 40
5.2.3 Hadoop cluster . . . 41
5.3 Testovacie dáta . . . 41
5.4 Konfigurácia technológií . . . 41
5.4.1 Flume . . . 42
5.4.2 Logstash . . . 43
5.4.3 Filebeat . . . 44
5.5 Spoľahlivosť . . . 44
5.5.1 Strata dát . . . 44
5.5.2 Duplikáty . . . 45
5.6 Zaťaženie systémových zdrojov . . . 45
5.6.1 Procesor . . . 45
5.6.2 Pamäť . . . 47
5.6.3 Sieť . . . 47
5.7 Výkon . . . 49
5.8 Extrahovanie informácií z udalostí . . . 49
5.9 Kompresia výstupu . . . 50
5.10 Monitorovanie . . . 50
5.11 Rozšíriteľnosť . . . 51
5.12 Náročnosť na implementáciu a prevádzku . . . 51
5.13 Výsledok porovnania a výber technológie . . . 51
6 Implementácia a testovanie prototypu 53 6.1 Základný popis . . . 53
6.2 Vstupné dáta . . . 54
6.3 Konfigurácia prvého úseku . . . 55
6.4 Konfigurácia druhého úseku . . . 56
6.4.1 Jednoduchý agent . . . 56
6.4.2 Vylepšený agent . . . 57
6.4.3 Pridávanie agentov . . . 58
6.4.4 Porovnanie konfigurácií prototypu . . . 59
Záver 61
Literatúra 63
A Zoznam použitých skratiek 67
B Obsah priloženej SD karty 69
Zoznam obrázkov
1.1 Schéma príkladu dávkového spracovania. [5] . . . 5
1.2 Schéma príkladu prúdového spracovania. [5] . . . 6
1.3 Porovnanie rôznych metód windowingu. [8] . . . 8
2.1 Počítanie výskytu slov pomocou modelu MapReduce. [14] . . . 14
2.2 Vysokoúrovňová architektúra systému Apache Kafka. [15] . . . 15
2.3 Architektúra nástroja Flume. [17] . . . 18
2.4 Architektúra nástroja Logstash. [18] . . . 19
2.5 Architektúra nástroja Filebeat. [20] . . . 21
3.1 Všeobecný model architektúry veľkých dát. [22] . . . 23
3.2 Model Lambda architektúry podľa [21]. . . 25
3.3 Model Kappa architektúry podľa [21]. . . 27
3.4 Model architektúry mikroslužieb podľa [21]. . . 28
3.5 Model Zeta architektúry podľa [21]. . . 29
3.6 Model Iot-a architektúry podľa [21]. . . 30
4.1 Transportná časť všeobecnej architektúry veľkých dát. [22] . . . 36
4.2 Vysokoúrovňový návrh architektúry. . . 37
5.1 Rozdelenie architektúry na dva úseky. . . 39
5.2 Graf zaťaženia procesora na prvom úseku. . . 46
5.3 Graf zaťaženia procesora na druhom úseku. . . 46
5.4 Graf zachytávajúci množstvo využívanej pamäte. . . 47
5.5 Grafy zachytávajúce sieťové metriky na prvom úseku. . . 48
5.6 Grafy zachytávajúce sieťové metriky na druhom úseku. . . 48
6.1 Schéma prototypu. . . 53
6.2 Zoznam vytvorených topicov v Kafke. . . 56
6.3 Architektúra jednoduchého agenta na druhom úseku. . . 57
6.4 Architektúra vylepšeného agenta na druhom úseku. . . 58
Zoznam tabuliek
5.1 Základná špecifikácia testovacieho stroja. . . 40
5.2 Základná špecifikácia testovacieho Kafka clustera. . . 41
5.3 Základná špecifikácia testovacieho Hadoop clustera. . . 41
5.4 Porovnanie výkonu na prvom úseku. . . 49
5.5 Porovnanie výkonu na druhom úseku. . . 49
5.6 Porovnanie kompresie na výstupe druhého úseku. . . 50
6.1 Základná špecifikácia webových serverov a transportného servera. . 54
6.2 Základná špecifikácia Kafka clustera. . . 54
6.3 Základná špecifikácia Hadoop clustera. . . 54
6.4 Porovnanie výkonu rôznych konfigurácií prototypu. . . 59
Úvod
Úvod do problematiky
Rozmach informačných technológií ovplyvnil takmer všetky oblasti nášho kaž- dodenného života. Jednotlivcom i firmám pomáhajú urýchliť či zefektívniť ich prácu, zjednodušujú komunikáciu a poskytujú mnoho nových príležitostí.
Mnoho firiem, ktoré dnes patria medzi najhodnotnejšie na svete, využili práve nové možnosti, ktoré priniesla digitálna doba. Spoločnosti ako Apple, Amazon, Google, Microsoft a Facebook pôsobia v oblasti dátových technológií.
Sú si vedomé skutočnej hodnoty svojich dát a pomocou analýzy ich využívajú na svoj rast.
Údaje o tom, ako sa jednotliví používatelia správajú pri využívaní online služieb sú v súčasnosti využívané na poskytovanie relevantného obsahu či cie- lenie reklamy. S cieľom čo najrýchlejšie zaujať používateľa vhodným obsahom, je potrebné navrhnúť spoľahlivý a rýchly systém na zhromaždenie a spracova- nie týchto dát, ktoré typicky vznikajú na viacerých serveroch. Na tento účel je vhodné spracovanie dát v reálnom čase.
Veľké množstvo týchto dát vzniká pri využívaní online služieb ako sú naprí- klad spravodajstvo, nákupné portály, televízia či vyhľadávače. Veľkou platfor- mou, ktorá poskytuje množstvo online služieb je v Česku spoločnosť Seznam.
Keďže Seznam, a podobne aj mnoho iných online firiem, má značné príjmy z reklamy, snaží sa čo najrýchlejšie poskytnúť svojmu používateľovi relevantný obsah a rovnako tak reklamu, pri ktorej je pravdepodobné, že zaujme. Táto práca vznikala práve v prostredí spoločnosti Seznam, ktorá mi umožnila za- oberať sa danou témou a tiež poskytla potrebnú výpočtovú infraštruktúru a dáta.
Cieľ práce
Cieľom teoretickej časti práce je analyzovať prístupy k spracovaniu veľkého množstva prúdových dát, popísať a porovnať známe architektúry a moderné technológie transportnej vrstvy v oblasti veľkých dát.
Cieľom praktickej časti práce je navrhnúť škálovateľnú architektúru na zber, spoľahlivý transport a centralizáciu logov z viacerých serverov do sys- tému na zasielanie správ Apache Kafka a distribuovaného súborového systému Apache HDFS a vytvoriť prototyp systému založeného na tejto architektúre.
Štruktúra práce
Práca pozostáva zo šiestich kapitol. Prvé tri kapitoly tvoria teoretickú časť, ďalšie tri praktickú.
Prvá kapitola obsahuje úvod do problematiky veľkých dát, porovnanie dávkového a prúdového spracovania dát a popisuje výzvy, ktorým čelí prúdové spracovanie. V druhej kapitole je predstavených niekoľko nástrojov na prácu s veľkými dátami, ktoré boli využité aj v praktickej časti práce. Tretia kapitola je venovaná známym architektúram, ktoré sa používajú pri návrhu aplikácií v oblasti veľkých dát.
Úvodom do praktickej časti práce je štvrtá kapitola, ktorá sa zaoberá ana- lýzou a návrhom architektúry systému. Piata kapitola obsahuje porovnanie niekoľkých transportných technológií, ktorého účelom je výber vhodnej alter- natívy. V šiestej kapitole je popísaná implementácia prototypu a porovnanie jeho rôznych konfigurácií.
Kapitola 1
Veľké dáta
V tejto kapitole popíšem čo sú veľké dáta (angl.Big Data), porovnám prístupy k spracovaniu veľkých dát a predstavím problémy, ktorým musíme čeliť pri spracovaní veľkých dát.
1.1 História veľkých dát
Hoci je pojem Big Data zaužívaný už od prvej polovice 90. rokov 20. storo- čia, nie je známe kto je jeho autorom a dokonca neexistuje ani jeho presná definícia. [1] Predzvesťou veľkých dát ako ich poznáme dnes, bolo spracovanie (angl.data processing), skladovanie (angl.data warehousing) a analýza štruk- túrovaných dát uložených v relačných databázových systémoch (RDBMS), ktoré sa využívali napríklad v oblasti dolovania dát (angl.data mining), stro- jového učenia (angl.machine learning) a štatistickej analýzy. V tomto období boli položené základy modernej dátovej analýzy a dodnes sa využíva mnoho techník z tejto fázy, napríklad databázové dotazy. Toto obdobie sa nazývaBig Data 1.0 (1970–2000).
Od začiatku 21. storočia (Big Data 2.0 [2000–2010]) sa začal klásť veľký dôraz na analýzu údajov z webu. Vďaka nárastu používateľov, ktorí využí- vali služby online prostredníctvom internetu začali vznikať nové kolekcie dát.
Spoločnosti začali zbierať o užívateľoch a zákazníkoch dáta, ktoré popisovali ich chovanie a záujmy. Tieto údaje mali rôznu štruktúru. Jednalo sa naprí- klad o údaje o polohe, odvodenej od IP adresy, históriu vyhľadávania alebo postupnosť klikov na stránkach. Z hľadiska analýzy veľkých dát priniesol we- bový prenos založený na protokole HTTP masívny nárast pološtrukturova- ných a neštruktúrovaných údajov. Organizácie tak museli okrem štandard- ných štruktúrovaných typov údajov nájsť nové prístupy a riešenia ukladania údajov, aby sa s týmito novými typmi mohli vysporiadať, a aby ich mohli efek- tívne analyzovať. Príchod a rast údajov zo sociálnych médií výrazne prehĺbil potrebu nástrojov, technológií a analytických techník, ktoré by boli schopné
extrahovať zmysluplné informácie z týchto neštruktúrovaných údajov.
Hoci neštruktúrovaný obsah vznikajúci na webe je stále hlavným zame- raním mnohých organizácií v oblasti analýzy údajov a veľkých dát, veľký potenciál cenných informácií sa objavuje na poli mobilných zariadení. Táto problematika je kľúčová v aktuálnej fáze, v ktorej sa veľké dáta nachádzajú dnes –Big Data 3.0 (2010–súčasnosť). Mobilné zariadenia dnes vedľa údajov o správaní, ako napríklad kliknutia a vyhľadávacie dotazy, umožňujú ukladať a analyzovať údaje založené na polohe (údaje GPS), sledovať pohyb, analyzo- vať fyzické správanie a dokonca aj údaje súvisiace so zdravím (počet krokov, tepová frekvencia). Tieto údaje poskytujú úplne novú škálu príležitostí od do- pravy cez dizajn miest až po zdravotnú starostlivosť. Obrovským objemom údajov tiež prispieva skupina zariadení označovaná ako Internet of Things (IoT). IDC predpokladá objem vygenerovaných dát v roku 2025 na 163 ZB, čo predstavuje desaťnásobok oproti roku 2017. [2] To predstavuje stále nové príležitosti na extrakciu zmysluplných a hodnotných informácií z týchto dát.
1.2 Čo sú veľké dáta
Aj keď neexistuje jednotná definícia pojmu „veľké dáta“, často sa popisujú ako dáta, ktoré sú také veľké, rýchlo pribúdajúce alebo komplexné, že je ťažké alebo nemožné ich spracovať pomocou tradičných metód. Bližšie sa popisujú pomocou takzvanýchtroch V:
Volume (objem). Množstvo vygenerovaných a uložených údajov. Dáta môžu pochádzať z viacerých rôznych zdrojov, ktoré generujú obrovské objemy.
Velocity (rýchlosť). Rýchlosť akou sú dáta generované a spracované. Dáta zo zdrojov prúdia obvykle v reálnom čase a nepretržite a musí sa s nimi zaobchádzať včas.
Variety (rôznorodosť). Široká škála typu dát. Dáta môžu byť generované človekom, ale aj strojom. Môžu sa líšiť typom - od štruktúrovaných úda- jov v tradičných databázach až po neštruktúrované textové dokumenty, e-maily, videá a zvuky. [3]
Niektoré zdroje rozširujú tieto body na päť V pridaním ďalšich dvoch bo- dov:
Veracity (vierohodnosť). Vzhľadom k tomu, že ide o veľké dáta, je potrebné ustriehnuť, že ide o kvalitné a pravdivé údaje, ktoré môžeme analyzovať a prinesú nám pravdivú informáciu.
Value (hodnota). Surové dáta často obsahujú aj nepotrebné údaje a nepriná- šajú hodnotu priamo. Hodnotné informácie je potrebné extrahovať ich spracovaním. [4]
1.3. Dávkové a prúdové spracovanie
1.3 Dávkové a prúdové spracovanie
Podľa charakteru vstupných dát môžeme rozdeliť ich spracovanie nadávkové (angl. batch processing) aprúdové (angl.stream processing).
Dávkové spracovanie využíva ako vstup dávku alebo blok dát. Tieto dáta tiež nazývame historické či obmedzené, pretože pred spracovaním sú istý čas uložené a v dobe kedy sa začínajú spracovať už ďalšie záznamy do tejto sady nepribúdajú. Tento typ spracovania slúži dobre v situáciách, kedy po- trebujeme spracovať veľké množstvo dát a získať o nich detailné informácie.
Príkladom je spracovanie dát zozbieraných za celý predchádzajúci deň. Ty- pickým nástrojom na dávkové spracovanie veľkých dát je framework Hadoop MapReduce. [5]
Obr. 1.1: Schéma príkladu dávkového spracovania. [5]
Prúdové spracovanie naproti tomu umožňuje spracovať dáta v reál- nom čase, postupne ako vznikali. Jednotlivé riešenia, ktoré spracujú prúd dát sa líšia v tom, koľko dátových bodov spracujú v jednom čase. Skutočné prú- dové spracovanie je proces, kedy sa jednotlivé dátové body spracujú osobitne.
Mnoho výpočtových frameworkov však spracuje s vysokou frekvenciou malé dávky (angl. micro-batches). Teoreticky ide o dávkové spracovanie, v praxi však toto správanie simuluje prúdové spracovanie. To nám umožňuje dostať z dát hodnotné informácie takmer okamžite. Prúdové spracovanie slúži najmä na analýzu v reálnom čase. Zaujímavým príkladom, kedy môže hrať čas pri analýze kľúčovú úlohu, je odhaľovanie podvodov. Vďaka prúdovému spraco- vaniu je možné pri spracovaní transakcií zistiť nezrovnalosti, ktoré signalizujú problém v reálnom čase a tieto podvodné transakcie zastaviť ešte pred ich dokončením. [5] Medzi nástroje na spracovanie toku dát patria okrem iných ajApache Flink,Apache Storm aSpark Streaming.
Obr. 1.2: Schéma príkladu prúdového spracovania. [5]
Hlavným rozdielom je odozva – rýchlosť akou dostaneme výsledky spra- covania. Pri dávkovom spracovaní sa zaobchádza naraz s veľkým množstvom historických dát. To znamená, že samotné spracovanie trvá dlhšiu dobu a vý- sledky sú dostupné neskôr. Naopak, prúdové spracovanie poskytuje výsledky v reálnom čase, pretože napretržite spracuje oveľa menší objem dát.
1.4 Výzvy prúdového spracovania
Spracovanie veľkých dát, dávkové aj prúdové, čelí spoločným požiadavkam na škálovateľnosť, spoľahlivosť, dostupnosť a mnohým ďalším. Pri návrhu systému na spracovanie v reálnom čase sa však objavujú nové otázky na jeho vlastnosti alebo vzniká potreba ošetriť niektoré situácie, ktoré pri dávkovom spracovaní nemôžu nastať alebo si s nimi jednoducho poradí.
1.4.1 Garancia spracovania dát
Pri návrhu systému musíme myslieť na chyby, ako zlyhanie strojov alebo po- ruchy siete, ktoré môžu nastať. Garancia spracovania (alebo doručenia) dát znamená koľko krát systém spracuje jeden konkrétny dátový bod. Rozlišujeme tri úrovne garancie:
At most once. Spracovanie jeden alebo nula krát. To znamená, že ak na- stane chyba počas spracovania, systém sa nebude pokúšať spracovať daný dátový bod znova. Z toho vyplýva, že systém s touto sémantikou nezaručuje spoľahlivé spracovanie dát, je to však najjednoduchší spôsob.
Používa sa v prípadoch, kedy nám nevadí že nejaké dáta nebudú spraco- vané alebo je viacnásobné spracovanie nežiadúce. Napríklad pre systém, ktorý prijíma a zobrazuje údaje o polohe drona nepredstavuje problém
1.4. Výzvy prúdového spracovania strata jednej konkrétnej správy, pretože správy sú posielané často. Na- opak, viacnásobné spracovanie by mohlo priniesť nepresné a neaktuálne dáta a spôsobiť tak problémy.
At least once. Spracovanie minimálne raz znamená, že každá správa bude určite spracovaná. Môže sa však stať, že niektoré správy budú spraco- vané viac krát. To môže nastať v situácii, keď systém nedostal potvrde- nie o spracovaní správy a vykoná nový pokus napriek tomu, že prvý bol úspešný. At-least-once sémantiku využívajú systémy, ktoré si nemôžu dovoliť vynechať zo spracovania žiadne dáta, ale nevadí ich viacnásobné spracovanie. Napríklad aplikácia, ktorej úlohou je upozorniť majiteľa na vlúpanie v jeho dome na základe údajov z rôznych senzorov, musí zaručo- vať doručenie upozornenia a zároveň nie je kritický problém ak užívateľ dostane viac správ o konkrétnom vlúpaní.
Exactly once. Spracovanie práve raz aj pri chybách a následných opakova- ných pokusoch. Zatiaľčo pri dávkovom spracovaní to nie je ťažká úloha, pri spracovaní streamu si to vyžaduje isté úsilie. Jedným zo spôsobov ako to zabezpečiť jededuplikácia správ– každá správa musí byť unikátna (často sa dopĺňa o unikátny identifikátor [ID]) a ak je doručená viac krát, jednoducho sa zahodí. Príkladom systému s exactly oncesémantikou sú bankové systémy, ktoré spracujú finančné transakcie. [6]
1.4.2 Spracovanie v (takmer) reálnom čase
Pri prúdovom spracovaní, kedy záleží na rýchlosti, sa bližšie špecifikuje spra- covanie v reálnom (angl. real-time processing) a v takmer reálnom čase (angl.
near real-time processing).
Spracovanie v reálnom čase dovoľuje odozvu rádovo v milisekundách až sekundách. Presnú hodnotu nie je možné stanoviť a typicky sa líši naprieč konkrétnymi riešeniami. Intuitívne ale platí, že človek by nemal byť schopný zaznamenať oneskoreniereal-timesystému, alebo je striktne vylúčené aby mal systém akékoľvek znateľné oneskorenie. To musí byť splnené napríklad u au- tonómnych vozidiel pri detekcii možnej kolízie a následnej reakcii, ktorá musí byť vykonaná ihneď. [7]
Spracovanie v takmer reálnom časedovoľuje odozvu typicky v sekun- dách alebo jednotkách až desiatkach minút. To je pre väčšinu streamových ap- likácií postačujúce, omnoho jednoduchšie a lacnejšie akoreal-timespracovanie.
Near real-time spracovanie využívajú napríklad aplikácie určené na textovú komunikáciu.
1.4.3 Poradie spracovania udalostí
Sieťová latencia alebo zlyhanie strojov môžu spôsobiť, že jednotlivé dátové body sa počas doručenia či spracovania preusporiadajú a do cieľa dorazia
v inom poradí ako vznikli (angl. out-of-order data). To pri mnohých analy- tických aplikáciách, ktoré dáta sčítajú alebo triedia nepredstavuje problém.
Naopak, kritickou oblasťou je opäť bankovníctvo, kedy je nutné aby sa jed- notlivé transakcie spracovali presne v tom poradí, v akom vznikli. V opačnom prípade by mohla nastať nežiadúca situácia, kedy by bola zákazníkovi zamiet- nutá platba pre nízky zostatok na účte, hoci predtým prijal dostatočnú sumu na vykonanie tejto platby.
Na rozkľúčovanie poradia v akom správy vznikli slúži časová pečiatka (angl. timestamp). Pripája k jednotlivým správam pri ich vzniku aktuálny čas.
1.4.4 Windowing
Niektoré technológie, ktoré slúžia na prúdové spracovanie, v skutočnosti ne- spracujú v jednom momente iba jeden dátový bod. Prúdové spracovanie simu- lujú tak, že s vysokou frekvenciou spracujú malé dávky (angl.micro-batches).
Aj keď samotné spracovanie takýchto skupín dátových bodov je jednoduché, ich výber do dávky závisí od konkrétnej aplikácie a nesprávne zlučovanie dát do dávok môže spôsobiť, že výsledky spracovania kvôli tomu nebudú presné alebo úplne stratia výpovednú hodnotu. Túto problematiku nazývamewindo- wing a môžeme jej rozumieť ako rozdelenie dát vznikajúcich v čase do
”okie- nok“. V [8] sú popísané nasledovné tri metódy windowingu.
Obr. 1.3: Porovnanie rôznych metód windowingu. [8]
Fixné okienka (angl. fixed windows) delia dáta na segmenty s pevným ča- sovým intervalom. Všetky segmenty sú rovnako veľké (z hľadiska času) a ich obsah sa neprekrýva – každý dátový bod patrí do práve jedného seg- mentu. Fixné okienko je najjednoduchší prístup windowingu, na druhej strane môže byť pomerne nepresný. K nepresným výsledkom dochádza
1.4. Výzvy prúdového spracovania napríklad v prípadoch, kedy v spracovanom segmente chýbajú omeškané dáta.
Posuvné okienka (angl. sliding windows) sú zovšeobecnením fixných okie- nok a do istej miery riešia problém ich nepresnosti. Konkrétnou apli- káciou posuvných okienok je prípad, kedy je veľkosť okienka opäť fixná ale spravidla býva väčšia ako doba, o ktorú sa okienko posúva (frekven- cia s ktorou sa segmenty spracujú). Tým pádom sa ich obsah prekrýva a to umožňuje získať presnejšie výsledky vďaka širšiemu kontextu. Veľ- kosť okienka a doba o ktorú sa posúva nemusí byť rovnaká. Použitie posuvných okienok by bolo vhodné v aplikácii, ktorá by každú sekundu počítala priemer ceny akcií za posledných päť minút.
Okienka relácie (angl. session windows) kladú špeciálny dôraz na kontext udalostí. Narozdiel od predchádzajúcich metód majú okienka premen- livú veľkosť, ktorá sa dynamicky zväčšuje na základe vznikajúcich uda- lostí. Pri session windowingu je potrebné definovať časový prah, ktorý ľubovoľné dve súvisiace udalosti patriace do jedného okienka nesmú pre- siahnuť. Udalosti v jednom takto vzniknutom okienku môžu reprezento- vať napríklad kliky jedného užívateľa na webstránke počas jednej relá- cie (angl. session). To umožňuje efektívnejšie analyzovať jeho správanie a záujmy.
1.4.5 Čas vzniku/spracovania
Pri spracovaní prúdových dát typicky uvažujeme o dvoch časových doménach:
• Čas vzniku(angl. event time) – čas, kedy sa udiala udalosť.
• Čas spracovania(angl. processing time) – čas v ktorom udalosť spra- coval systém. [8]
V ideálnom prípade by tieto časy splývali a jednotlivé udalosti by boli spracované v momente ich vzniku. V skutočnosti je medzi nimi časový od- stup, ktorého veľkosť závisí od viacerých faktorov, napríklad od počtu udalostí generovaných na vstupe, ich distribúcie v čase, použitého softvéru alebo od vyťaženia hardvéru.
Zatiaľ čo processing time vieme zaznamenať a priradiť udalosti počas sa- motného spracovania, event time musí byť zachytený v systéme alebo na za- riadení, ktoré ho generuje, v podobe timestampu. Ten je následne možné pri spracovaní extrahovať.
Nie všetky aplikácie potrebujú poznať event time, mnohé však áno. Pat- ria medzi ne napríklad zaznamenávanie záujmov užívateľa v čase či detekcia anomálií.
Kapitola 2
Nástroje veľkých dát
Veľké dáta majú špecifické vlastnosti, ktoré ich odlišujú od
”tradičných“ dát.
Rovnako tak tradičné nástroje nie sú vhodné na správu, spracovanie a analýzu veľkých objemov dát v krátkom čase alebo efektívnym spôsobom. Preto je potrebné hľadať spôsoby zaobchádzania s dátami aj na základe ich vlastností.
V oblasti spracovania veľkých dát sa uplatnil napríklad princíp distribu- ovaného výpočtu (angl. distributed computing). Tento princíp masívneho pa- ralelného spracovania dát sa vyznačuje vlastnosťami, ako sú odolnosť voči chybám, automatické zotavenie z chýb, konzistencia výsledkov aj pri výpad- koch, heterogenita výpčtových zdrojov a v neposlednom rade horizontálna škálovateľnosť.
Nástrojov určených na prácu s veľkými dátami je dnes už obrovské množ- stvo. V tejto kapitole sa zameriam hlavne na predstavenie open source nástro- jov, ktoré úzko súvisia so zadaním práce, a ktoré využijem v praktickej časti práce.
2.1 Apache Hadoop
Jedným z najpopulárnejších nástrojov vzniknutých za týmto účelom jeApache Hadoop. Hadoop je open source framework určený na distribuované spracova- nie, ukladanie a analýzu veľkých dát naprieč klastrami počítačov. [9]
Projekt, ktorý dnes poznáme ako Hadoop, vznikal od roku 2002 pod náz- vom Apache Nutch. V jeho čele stál Doug Cutting a cieľom bolo vyvinúť we- bový vyhľadávací nástroj, ktorý by prehľadával a indexoval webové stránky.
Vtedajšie technológie však na efektívne riešenie nestačili.
Riešenie pre tento problém sa objavilo v roku 2003, resp. 2004, keď spo- ločnosť Google vydala články popisujúce distribuovaný súborový systémGFS (Google distributed file system), resp. model spracovania veľkého množstva dátMapReduce. Tieto dokumenty poslúžili ako základ pre implementáciu sú- častí Hadoopu, ktorý bol potom začlenený pod fulltextový vyhľadávací nástroj
Apache Lucene a neskôr v roku 2008 ako samostatný top-level projekt Apache Hadoop.
Prvá z veľkých spoločností začala využívať Hadoop v roku 2006 spoločnosť Yahoo!, dnes sú to giganti ako Facebook, Twitter či Spotify. [10]
Hadoop pozostáva z týchto modulov:
• Hadoop Common: Spoločné utility potrebné pre ostatné Hadoop mo- duly.
• Hadoop Distributed File System (HDFS): Distribuovaný súborový systém.
• Hadoop YARN: Platforma na správu zdrojov clustera a plánovanie úloh.
• Hadoop MapReduce: Framework určený k paralelnému spracovaniu veľkých dát.
• Hadoop Ozone: Objektové úložisko pre Hadoop. [11]
2.1.1 Hadoop Distributed File System (HDFS)
HDFS je distribuovaný súborový systém určený na používanie na bežne do- stupnom a relatívne lacnom, tzv. komoditnom hardvéri. [12] Vyznačuje sa najmä:
• Vysokou odolnosťou voči poruchámhardvéru. Cluster, ktorý tvorí inštanciu HDFS môže pozostávať zo stoviek až tisícok počítačov. To znamená, že pravdepodobnosť zlyhania niektorého z nich nie je zaned- bateľná. Implementácia HDFS preto obsahuje techniky na detekciu chýb a automatické zotavenie.
• Veľkými súbormirádovo v gigabajtoch až terabajtoch.
• Efektívnym opakovaným čítaním súborov, na ktoré je odladený na úkor opakovaného zápisu. Vychádza z modelu
”zapíš raz, čítaj opako- vane“ (angl.write-once-read-many).
• Vysokou priepustnosťou, do istej miery na úkor nízkej latencie. HDFS je totiž určený skôr na dávkové spracovanie ako na interaktívne použitie používateľmi.
• ”Presunom výpočtu k dátam“, čo radikálne urýchľuje výpočet oproti spôsobu, kedy by sa obrovské množstvo dát presúvalo na miesto, kde by sa vykonával výpočet. To minimalizuje zaťaženie siete a zvyšuje celkovú priepustnosť systému.
HDFS je založený na Master/Slave architektúre. To znamená, že clus- ter na ktorom je nainštalovaný pozostáva z jedného master uzla, nazývaného NameNodea viacerých dátových uzlov – DataNodes.
2.1. Apache Hadoop NameNode je master server. Spravuje súborový systém, udržiava si jeho štruktúru a metadáta uložených súborov. Spúšťa operácie súborového systému – otváranie, zatváranie, premenovanie súborov a zložiek. Tiež určuje mapovanie blokov na dátové uzly.
DataNode je slave server. Cluster typicky obsahuje viacero dátových uzlov.
Sú na nich uložené bloky súborov a sú zodpovedné za obsluhu požiada- viek na čítanie a zápis. Ďalej vykonávajú vytváranie, mazanie a repliká- ciu blokov na základe inštrukcií master servera.
Súbory uložené na HDFS sú interne rozdelené nabloky, ktoré sú uložené na množine dátových uzlov. Jednotlivé bloky sú z dôvodov spoľahlivosti repli- kované. To znamená, že jeden blok má viacero kópií a každá z nich je uložená na inom serveri. Počet kópií sa nazýva replikačný faktor. Za predpokladu, že cluster obsahuje viacero dátových uzlov (aspoň 2) tak pri zlyhaní niektorého z dátových uzlov pri replikačnom faktore väčšom ako jedna nedôjde k strate dát. Master uzol navyše tento výpadok zaznamená a zabezpečí uloženie stra- tených replík na iné dátové uzly.
2.1.2 Hadoop YARN
Apache Hadoop YARN je nástroj na riadenie zdrojov Hadoop clustera. Zdroje clustera sú hlavná pamäť, procesor, disk a sieť. Rozhoduje o ich rozdelení me- dzi všetky aplkácie bežiace na clusteri. Bol predstavený v Hodoop 2. Mal vylepšiť implementáciu MapReduce, ale je navrhnutý tak, aby podporoval aj iné distribuované výpočtové frameworky. Poskytuje high-level API na poža- dovanie zdrojov clustera a prácu s nimi. Toto rozhranie nevyužíva používateľ, ktorý píše kód aplikácie, ale samotný výpočtový framework. [9]
2.1.3 Hadoop MapReduce
Hadoop MapReduce je framework napísaný v programovacom jazyku Java, ktorý využíva programovací modelMapReduce. Je určený na dávkové spraco- vanie veľkých dát. Najdôležitejšou vlastnosťou MapReduce programov je, že sú paralelné a môžu byť spustené na viacerých strojoch. Vstup (angl. input) je rozdelený (angl. split) na časti a distribuovaný medzi jednotlivé stroje.
Model MapReduce rozdeľuje spracovanie na dve fázy:mapareduce. Každá fáza má na vstupe a výstupe dvojice kľúč-hodnota (angl. key-value), ktorých typy si môže zvoliť programátor. Programátor tiež implementuje dve funkcie:
map areduce. Funkciamapvytvorí pre každú dvojicu na vstupe množinu vý- stupných dvojíc. Výstupné dvojice sú následne zoskupené podľa kľúča a odo- vzdané funkciireduce. Tento proces sa nazýva shuffle. Funkciareduceprijíma kľúč a množinu hodnôt, ktoré mu prislúchajú. Hodnoty pre každý kľúč zlučuje a vytvára tak typicky menšiu množinu výstupov. [9]
Typickým príkladom programu postaveného na tomto modeli je počítanie výskytov jednotlivých slov v texte. V tomto prípade vstupnú dvojicu funkcie mapmôžu tvoriť napríklad číslo riadku (kľúč) a riadok textu (hodnota). Kľúč však v tejto fáze nebude potrebný. Výstupom funkcie map a zároveň vstu- pom funkcie reduce bude dvojica slovo (kľúč) a počet výskytov (hodnota).
Keďže jednotlivé časti textu boli analyzované osobitne, úlohou funkciereduce je pre identické kľúče (rovnaké slová) sčítať počty ich výskytov (hodnoty). Vý- stupom tejto funkcie a zároveň aj celého programu budú znova dvojice slovo a počet výskytov, tento raz ale budú vyjadrovať počet výskytov jednotlivých slov v celom texte. [13]
Obr. 2.1: Počítanie výskytu slov pomocou modelu MapReduce. [14]
2.2 Apache Kafka
Apache Kafka je distribuovaný systém na zasielanie správ (angl. distributed messaging system). Často býva súčasťou architektúry rôznych aplikácií, ktoré pracujú s prúdovými dátami. Ide o technológiu transportnej vrstvy, ktorá je založená na koncepte publikovania/odoberania (angl. publish/subscribe) dát.
Jednotlivé publikované a odoberané dáta sa nazývajú správy (angl.messages).
Tento koncept je charakteristický tým, že odosielateľ správy nezasiela priamo príjemcovi. Namiesto toho odosielateľ jednotlivé správy istým spôsobom klasi- fikuje a príjemca odoberá len triedy správ, o ktoré má záujem. Na to využívajú centrálny bod – sprostredkovateľa (angl.broker), ktorý prijíma správy od odo- sielateľov a vydáva ich odoberateľom. [15]
Zjednodušene si možno takýto systém predstaviť ako dátovú štruktúru fronta. Na jednej strane odosielateľ správy vkladá, na druhej strane, v rovna- kom poradí ako boli vložené, správy príjemca odoberá. Údaje sú v Kafke na istý čas perzistentne uložené a navyše môžu byť distribuované naprieč cluste-
2.2. Apache Kafka rom, na ktorom Kafka beží. To umožňuje uložené dáta chrániť pred poruchami a zároveň celý systém škálovať.
Obr. 2.2: Vysokoúrovňová architektúra systému Apache Kafka. [15]
2.2.1 Architektúra
Princípy fungovania Kafky, ktoré som popísal v predchádzajúcej sekcii intu- itívne, detailne popíšem pomocou pojmov, ktoré Kafka používa.
2.2.1.1 Broker
Jeden server v Kafka clusteri sa nazýva broker.
2.2.1.2 Message
Jeden záznam sa nazýva správa (angl. message). Skladá sa z kľúča (angl.
key), hodnoty a časovej známky (angl.timestamp). Kľúč je identifikátor danej správy a slúži na určenie oddielu (angl.partition), do ktorého sa uloží. Hodnota predstavuje samotné telo správy a časová známka vyjadruje najčastejšie čas vzniku správy. Správy nemajú z pohľadu systému žiadny význam. Sú uložené ako na pole bajtov a sú nemenné (angl. immutable).
2.2.1.3 Topic
Publikované správy sú kategorizované dotopicov. Ide o logické členenie správ.
Analógiou topicu je napríklad zložka v súborovom systéme. Do jedného topicu môže naraz zapisovať viacero producentov. Rovnako tak z jedného topicu môže viacero konzumentov čítať.
2.2.1.4 Partition
Topic je rozdelený do oddielov (angl. partitions). Oddiel je usporiadaná po- stupnosť správ. Každá správa v oddieli je určená posunom (angl.offset). Offset je vyjadrený celočíselnou hodnotou, ktorá rastie s pribúdajúcimi správami.
Oddiely sú tiež spôsob, akým Kafka poskytuje redundanciu a škálovateľ- nosť. Každý oddiel sa nachádza na inom serveri, čo znamená, že jeden topic môže byť horizontálne škálovaný na viacerých serveroch, aby poskytoval výkon ďaleko nad rámec možností jedného servera.
2.2.1.5 Producer
Používatelia Kafky sa delia na dva typy. Prvým z nich je producent (angl.
producer). Producenti zapisujú správy do topicov.
2.2.1.6 Consumer
Druhým typom používateľa je konzument (angl. consumer). Konzument číta správy z topicov v poradí, v akom boli zapísané. Systém si pre každého kon- zumenta udržuje jeho aktuálny offset. Podľa toho konzument pozná, ktoré správy už prečítal. Vďaka tomu môže konzument kedykoľvek zastaviť a znova spustiť čítanie správ bez toho, aby stratil svoju pozíciu.
2.3 Transport dát
V tejto sekcii popíšem niekoľko vybraných technológií určených na transport dát. Jedným z využití týchto technológií je streamový transport logov zo ser- verov, na ktorých sa zaznamenávajú, do externého úložiska. Dôvodom tohto transportu je centralizácia dát z viacerých serverov, ich spracovanie a náslendá analýza.
Predstavené technológie neskôr využijem v praktickej časti práce, ktorej cieľom je navrhnúť škálovateľnú architektúru na zber, transport a centralizáciu logov. Tam jednotlivé technológie pre tento prípad použitia z viacerých hľadísk porovnám a najvhodnejšiu technológiu využijem pri implementácii prototypu systému.
2.3. Transport dát 2.3.1 Logovanie
Logovanie je systematické zaznamenávanie informácií o činnosti programov alebo využívaní služieb. Tieto informácie sa typicky ukladajú v textovej po- dobe do súborov s príponou .log.
Služby, ktoré bežia distribuovane na viacerých serveroch zaznamenávajú logy lokálne. Môže ísť napríklad o webový server, ktorý zaznamenáva infor- mácie o prevádzke. Ak chceme s týmito dátami ďalej pracovať, je potrebné ich najprv zozbierať z jednotlivých serverov a uložiť ich na jedno miesto.
2.3.2 Udalosti
Dáta s ktorými nasledujúce technológie interne pracujú sa nazývajú udalosti.
Udalosť (angl. event) je jednoduchá dátová štruktúra pozostávajúca z tela (angl. body) a hlavičiek (angl.headers).
Telo udalosti tvorí samotný obsah udalosti. Hlavičky sú údaje doplňujúce informácie o udalosti. Môžu byť reprezentované napríklad pomocou dátovej štruktúry mapa s kľúčom aj hodnotou typu reťazec. Nie sú súčasťou samot- nej správy a slúžia na trasovanie, filtrovanie, vyjadrenie priority či severity.
K udalostiam môžu byť systémom priradené automaticky (napríklad označenie servera na ktorom udalosť vznikla) alebo extrahované priamo z tela (napríklad čas kedy udalosť nastala).
2.3.3 Apache Flume
Apache Flumeje distribuovaná a spoľahlivá služba na efektívne zhromažďova- nie, agregáciu a presun veľkého množstva dát z viacerých rôznych zdrojov do centralizovaného dátového úložiska. Najčastejšie sa jedná o záznamy z logov.
Dá sa jednoducho škálovať, má jednoduchú a flexibilnú architektúru založenú na streamovaní dátových tokov.
Flume je open source projekt Apache Software Foundation napísaný v prog- ramovacom jazyku Java. Je robustný a odolný voči chybám s laditeľnými mechanizmami spoľahlivosti a mnohými mechanizmami obnovy po zlyhaní.
Používa jednoduchý rozšíriteľný dátový model, ktorý umožňuje využitie pre online analytické aplikácie. [16]
2.3.3.1 Architektúra
Flume disponuje vysoko flexibilnou a modulárnou architektúrou. Podporuje mnoho typov vstupov a výstupov používaných v oblasti veľkých dát. Navyše umožňuje implementovať vlastné riešenie vstupu, výstupu či kanálu pre špe- cifické potreby používateľa.
Obr. 2.3: Architektúra nástroja Flume. [17]
2.3.3.2 Agent
Flume agent je JVM (Java Virtual Machine) proces, ktorý zastrešuje kom- ponenty, prostredníctvom ktorých udalosti prúdia zo zdroja do cieľa. Cieľom nemusí byť priamo dátové úložisko, ale aj iný agent. Výstup jedného agenta je možné pripojiť na vstup jedného alebo viacerých iných agentov. Takisto jeden agent môže mať na svoj vstup pripojené výstupy viacerých agentov. Ta- kéto spájanie agentov umožňuje vytváranie špecifických dátových tokov podľa potreby. Jednoduchým pridaním ďalších agentov je možné škálovať počet ser- verov a množstvo dát, ktoré generujú.
Komponenty z ktorých sa skladá agent sa nazývajú:Source(zdroj, vstup), Channel (kanál) aSink (výstup).
2.3.3.3 Source
Sourceje zodpovedný za získanie udalostí z externých zdrojov. Formát získa- vaných dát je možné konfigurovať, Flume ponúka množstvo alternatív ako na- príklad čítanie zo súborov, syslogu, z topicov streamingovej platformy Apache Kafka či načúvanie na rôznych sieťových portoch.
2.3.3.4 Channel
Keď Source príjme udalosť z externého zdroja, uloží ju do jedného alebo via- cerých kanálov.Kanál je dočasným pasívnym úložiskom pre prijaté udalosti, kým ich nespracuje Sink. Flume ponúka na výber napríklad Memory, File či Kafka Channel. Zatiaľčo Memory Channel ukladá udalosti v hlavnej pa- mäti, čo znamená, že je rýchly, File Channel je spoľahlivejší, pretože udalosti zapisuje na disk a pri zlyhaní sa dáta z kanálu nestratia.
2.3. Transport dát
2.3.3.5 Sink
Sink je výstupný komponent agenta. Odoberá udalosti z kanálov a postupuje ich ďalšiemu agentovi v topológii alebo ich zapisuje napríklad do externého úložiska HDFS alebo HBase, stremingovej platformy Kafka, indexovacieho systému Elasticsearch alebo inej cieľovej destinácie, či nepotrebné udalosti zahodí.
2.3.4 Logstash
Logstash je open source nástroj na zber údajov v reálnom čase. Dokáže ag- regovať údaje z rôznych zdrojov v rôznom formáte, transformovať ich podľa potreby a emitovať na výstupy podľa výberu. Je spoľahlivý, výkonný, škálo- vateľný, ľahko rozšíriteľný a jeho výhodou je pomerne jednoduchá konfigurá- cia a nasadenie. Bol navrhnutý primárne na zber logov, ale v skutočnosti je schopný pracovať prakticky takmer s akýmkoľvek typom udalostí. Je napísaný v programovacích jazykoch Java a Ruby a vyvíjaný spoločnosťou Elastic. [18]
Často býva používaný ako súčasť technologického balíka nazývanéhoElas- tic Stack. Do tohoto balíka patria technológie spoločnosti Elastic, menovite Logstash, Beats, Elasticsearch a Kibana. Beats a Logstash slúžia na zber dát, Elasticsearch na ich uloženie a Kibana na vizualizácie. Elastic Stack je popu- lárna platforma, ktorá slúži na správu logov, monitorovanie a analýzy.
2.3.4.1 Architektúra
Architektúra nástroja Logstash je flexibilná a modulárna, rovnako ako pri Flume. Pozostáva z dvoch povinných elementov – Input (vstup) a Output (výstup) – a jedného nepovinného –Filter. Tieto elementy sa nazývajú pluginy.
Logstash poskytuje viac ako 200 vstupných, výstupných a filtračných pluginov a navyše aj možnosť vytvoriť si vlastný.
Obr. 2.4: Architektúra nástroja Logstash. [18]
2.3.4.2 Input
Input konzumuje vstupné dáta a generuje z nich udalosti. Medzi často pou- žívané vsupné pluginy patria napríklad file– čítanie zo súborov, syslogalebo beats– výstup z nástrojov Beats.
2.3.4.3 Filter
Udalosti zo vstupných pluginov pokračujú postupne cez filtre. Filtre slúžia na spracovanie udalostí. Udalosti možno rôzne transformovať či vykonávať akcie na základe obsahu udalostí. Napríklad filterdropdokáže zahodiť udalosť obsahujúcu konkrétny údaj, filtermutateumožňuje pridávať, vymazávať alebo upravovať formát jednotlivých polí udalosti, filtergrok zase extrahovať údaje z tela udalostí, štruktúrovať ich a ukladať do hlavičiek.
2.3.4.4 Output
Po aplikovaní filtrov postupujú udalosti do finálnej fázy – navýstup. Výstupy zabezpečujú uloženie udalostí v rôznych formátoch na disk alebo do exter- ných úložísk ako Elasticsearch, HDFS alebo Kafka. Jedna udalosť môže byť spracovaná viacerými výstupnými pluginmi.
2.3.5 Filebeat
Filebeat je open source agent určený na streamovanie dát zo súborov. Bol navrhnutý ako doplnok k Logstashu. Logstash je síce robustná technológia s množstvom nástrojov na spracovanie udalostí, no má vysoké požiadavky na zdroje. Filebeat má na druhej strane obmedzenú funkcionalitu, zato má nižšie nároky na systémové zdroje. Nie vždy je totiž potrebné udalosti upravovať a transformovať, alebo je výhodnejšie vykonávať to v oddelenom prostredí a nezaťažovať tak servery, ktoré okrem generovania udalostí navyše aj obslu- hujú požiadavky užívateľov. [19]
Filebeat je napísaný v jazyku Go. K spusteniu nepotrebuje žiadne runtime prostredie, narozdiel od predchádzajúcich dvoch technológií, ktoré používajú virtuálny stroj JVM. Je súčasťou kolekcie nástrojov na zasielanie dát nazý- vanej Beats. Tá obsahuje navyše napríklad nástroj Metricbeat, ktorý zbiera a odosiela metriky operačného systému a služieb bežiacich na serveri, alebo nástroj Packetbeat slúžiaci na real-time analýzu sieťovej premávky.
2.3.5.1 Architektúra
Filebeat sa skladá z troch kľúčových komponentov –Input, Harvester a Spo- oler. Narozdiel od vyššie spomenutých technológií Flume a Logstash, dokázal Filebeat na začiatku pracovať iba s jedným typom vstupu, a to čítať zo súbo- rov. Neskôr pribudlo niekoľko iných ako napríklad Redis, Syslog, TCP, UDP, Kafka alebo Amazon S3.
2.3. Transport dát
Obr. 2.5: Architektúra nástroja Filebeat. [20]
2.3.5.2 Input
Input zodpovedá za identifikáciu súborov z ktorých sa majú čítať logy. Tie je možné definovať pomocou cesty v súborovom systéme.
2.3.5.3 Harvester
Pre každý identifikovaný súbor sa spustí Harvester. Ten číta obsah súboru riadok po riadku.
2.3.5.4 Spooler
Spooler prijíma udalosti od všetkých Harvesterov a agreguje ich do nakonfi- gurovaných výstupov.
Kapitola 3
Architektúry veľkých dát
Big Data architektúra popisuje koncept systému, ktorý pracuje s obrovským objemom dát počas ich ukladania, spracovania, analýzy a vizualizácie. [21]
Tieto dáta často mávajú rôzny formát a pochádzajú z rôznych zdrojov. Práve vysoká heterogenita dát si vyžaduje vybudovať systém, ktorý bude schopný transportovať ich na miesto, odkiaľ môžu byť efektívne spracované a analyzo- vané.
V dobe neustáleho rastu dát a vzostupe rozhodovania založeného na dá- tach (angl.data-driven decision-making) je pri návrhu nového systému mimo- riadne dôležité sústrediť sa nielen na súčasné, ale i budúce potreby. Základnou vlastnosťou Big Data architektúry je horizontálna škálovateľnosť, vďaka ktorej môžu systémy reagovať na nárast vstupných dát a zvyšovať tak výkon a prie- pustnosť. Pomôcť navrhnúť systém nám môžu aj existujúce architektúry.
V tejto kapitole popíšem jednotlivé fázy a aktivity, ktoré bývajú súčasťou systému postaveného na Big Data architektúre. Následne predstavím a po- rovnám najdôležitejšie existujúce architektúry v oblasti Big Data, ich výhody, nedostatky, špecifické požiadavky a prípady použitia v reálnom svete.
Obr. 3.1: Všeobecný model architektúry veľkých dát. [22]
Na obrázku 4.1 je všeobecný model Big Data architektúry podľa [22]. Slúži na objasnenie jednotlivých fáz spracovania dát. Základné komponenty, ktoré tvoria Big Data architektúru sú:
Zdroje dát (angl.data sources). Začiatok každého riešenia tvoria zdroje dát.
Môžu to byť databázy alebo iné úložiská dát, logovacie súbory web ser- vera, prúdy dát zo senzorov alebo IoT zariadení.
Úložisko dát (angl. data storage). Údaje zozbierané zo zdrojov dát sa zvy- čajne ukladajú do distribuovaného úložiska, akými sú napríklad Apache HDFS, HBase, Cassandra alebo Amazon S3.
Prijímanie správ v reálnom čase (angl.real-time message ingestion). Dáta zo streamových zdrojov, ktoré budú neskôr streamovo spracované, je po- trebné najprv určitým spôsobom zachytiť a uložiť. Na tento účel sa ty- picky využívajú systémy na zasielanie správ (angl. messaging systems), ako napríklad Apache Kafka.
Dávkové spracovanie (angl.batch processing). Na dávkové spracovanie a ana- lýzu historických dát sa používajú napríklad frameworky Apache Spark, MapReduce alebo Flink. Zvyčajne spracujú súbory za niekoľko hodín alebo dní a výstup zapisujú opäť do súborov.
Prúdové spracovanie (angl.stream processing). Nástroje na prúdové spra- covanie dát, ako napríklad Apache Storm alebo Apache Spark Strea- ming, načítavajú dáta zo systému na zasielanie správ, tie filtrujú, ag- regujú alebo nad nimi vykonávajú iné operácie a výsledok je následne zapísaný na zvolený výstup.
Úložisko analytických dát (angl. analytical data store). Výstupy spraco- vania, či už dávkového alebo prúdového, sú ukladané v štruktúrovanom formáte, na ktorý je možné sa dopytovať (angl. query). Úložisko analy- tických dát slúži aj na obsluhu týchto požiadavkov, typicky od rôznych analytických nástrojov, ktoré majú za úlohu interpretovať výsledky spra- covania. Úložisko môže byť implementované napríklad pomocou NoSQL technológií ako Apache HBase alebo Apache Cassandra.
Analýza a podávanie správ (angl. analysis and reporting). Hlavným cie- ľom systémov pracujúcich s veľkými dátami je získanie hodnotných in- formácií o údajoch pomocou analýzy. Preto môže architektúra tiež obsa- hovať vrstvu na interaktívnu analýzu a vizualizáciu výsledkov spracova- nia. Klasickými technológiami na analýzu sú Jupyter, Apache Zeppelin a Apache Hue.
Orchestrácia (angl. orchestration). Orchestračné technológie môžu poslúžiť na automatizáciu pracovných postupov systému, keďže často pozostá- vajú z operácií, ktoré sa neustále opakujú. V mnohých prípadoch je
3.1. Lambda užitočná utilita cron, ktorá slúži na plánovanie úloh v čase. Na auto- matizáciu nasadenia, škálovania a ďalšej správy aplikácií môže poslúžiť platforma Kubernetes.
3.1 Lambda
Lambda architektúru, ako škálovateľné riešenie na spracovanie údajov na dis- tribuovaných systémoch, odolné voči chybám, v roku 2011 navrhol, pomenoval a neskôr v [23] podrobne popísal Nathan Marz na základe vlastných skúseností s komplikovanými systémami v praxi. [24] Lambda architektúra tak patrí me- dzi prvé architektúry, ktoré boli navrhnuté na spracovanie veľkých dát. Pred- stavuje prístup, ktorého cieľom je poskytnúť presné výsledky v čo najkratšom čase. Môžeme ju rozdeliť na 3 časti.
Obr. 3.2: Model Lambda architektúry podľa [21].
Dávková vrstva (angl.batch layer) obsahuje agregované dáta zo zdrojov ulo- žené najčastejšie v distribuovanom súborovom systéme, a nástroje ur- čené na ich dávkové spracovanie. Dávkové spracovanie je proces, ktorý sa opakuje v pravidených intervaloch a pracuje s dátami, ktoré boli získané medzi nimi. Výstupom dávkového spracovania sú tzv. dávkové zobrazenia (angl. batch views). Dávkové zobrazenia predstavujú presné výsledky, keďže v momente ich generovania sú k dispozícii všetky údaje za dané obdobie.
Rýchla vrstva (angl. speed layer) má za úlohu vytvárať zobrazenia v reál- nom čase (angl.real-time views). Sú výsledkom prúdového spracovania, ktoré nepretržite načítava nové dáta ihneď po ich doručení zo zdroja.
Prúdové spracovanie nevyžaduje úplnosť dát, vďaka čomu môže táto vrstva poskytnúť výsledky v takmer reálnom čase. Výsledky síce nemu- sia byť tak presné ako dávkové zobrazenia, sú však dostupné takmer ihneď. Zobrazenia v reálnom čase prakticky poskytujú najnovšie možné
výsledky aj v čase medzi vygenerovaním dvoch, po sebe idúcich dávko- vých zobrazení. Hneď ako je dostupné nové dávkové zobrazenie, môže nahradiť a opraviť výsledky prúdového spracovania.
Obslužná vrstva (angl. serving layer) obsluhuje dotazy na výsledky spra- covania. K tomu využíva výstupy z rýchej aj dávkovej vrstvy, ktoré sú uložené v tejto vrstve.
3.1.1 Výhody a nevýhody
Systémy založené na Lambda architektúre poskytujú rozumnú rovnováhu rých- losti, presnosti a spoľahlivosti. Lambda architektúra poskytuje analýzu v reál- nom čase aj analýzu historických dát. Distribuované úložisko v dávkovej vrstve zabezpečuje odolnosť voči chybám systému. [25] Dávkovú a rýchlu vrstvu je možné vďaka ich oddeleniu nezávisle škálovať a podľa potreby rozšíriť.
Medzi nevýhody tohto riešenia patrí spravovanie kódov na dávkové aj prú- dové spracovanie, ktoré v skutočnosti vykonávajú podobné operácie, len nad inými sadami dát. Náročná je aj synchronizácia výsledkov dávkovej a rýchlej vrstvy tak, aby poskytované výsledky boli konzistentné.
3.1.2 Prípady použitia
Lambda architektúra nachádza využitie v aplikáciách, ktoré si vyžadujú ana- lýzu údajov v reálnom čase aj pravidelú analýzu údajov zozbieraných za dlhšie obdobie. Tiež je vhodná v prípade, že strata či poškodenie dát sú nežiadúce a kde musí byť zároveň klientom poskytnutá rýchla spätná väzba. [21] Taký- mito aplikáciami sú napríklad zber a analýza logov alebo analýza príspevkov na sociálnych sieťach, ktoré si vyžadujú vysokú dostupnosť a spoľahlivosť zá- roveň.
3.2 Kappa
Kappaarchitektúra bola navrhnutá tak, aby riešila niektoré nedostatky Lambda architektúry, ako napríklad udržiavanie častokrát redundantného kódu v dáv- kovej a rýchlej vrstve. [26] V Kappa architektúre bola oproti Lambde odstrá- nená dávková vrstva, pridaná možnosť zaznamenávať prúdové dáta v priebehu času a rýchla vrstva bola vylepšená tak, aby dokázala znova spracovať údaje za dlhšie časové obdobie. Na ukladanie prúdu dát zo zdrojov sa najčastejšie využívajú systémy na zasielanie správ, napríklad Apache Kafka.
3.3. Mikroslužby
Obr. 3.3: Model Kappa architektúry podľa [21].
3.2.1 Výhody a nevýhody
Vynechanie dávkovej vrstvy znamená, že systémy postavené na Kappa archi- tektúre vyžadujú menšie množstvo strojov. To ale znamená, že dáta nie sú uchovávané dlhodobo, ale iba vopred určené obmedzené časové obdobie. Ab- sencia spoľahlivej dávkovej vrstvy tiež môže viesť k chybám, ktoré je potrebné riešiť spätným spracovaním dát.
3.2.2 Prípady použitia
Pretože sa Kappa architektúra zameriava na rýchlu vrstvu, je obzvlášť vhodná pre systémy v reálnom čase, ako napríklad analýza záujmov užívateľa na we- bových službách, s cieľom poskytnúť mu čo najrýchlejšie relevantný obsah.
3.3 Mikroslužby
Architektúra mikroslužieb (angl.microservices) pozostáva z voľne prepojených služieb, ktoré bežia navzájom nezávisle na vyhradenom serveri a každá z nich vykonáva jednu konkrétnu úlohu. [21] Služby sú v podstate samostatné apli- kácie použiteľné vo viacerých systémoch. Na koordináciu väčšieho množstva mikroslužieb je vhodné použiť orchestračné nástroje.
Obr. 3.4: Model architektúry mikroslužieb podľa [21].
3.3.1 Výhody a nevýhody
Obrovskou výhodou je, že každá služba môže byť implementovaná v inom jazyku a využívať iné technológie. Nezávislosť služieb zjednodušuje škálovanie konkrétnych častí systému a zvyšuje odolnosť systému voči chybám. Pretože sú služby malé a vykonávajú jednu úlohu, sú jednoduchšie na pochopenie, implementáciu, údržbu a riešenie problémov. Na každej službe môže pracovať iný tím, čo umožňuje rýchly vývoj.
Na druhej strane stojí náročnejšia komunikácia. A to medzi jednotlivými službami, ale aj medzi vývojovými tímami. Často je nevyhnutný aj zvýšený prenos dát a ich redundantné uloženie.
3.3.2 Prípady použitia
Architektúra mikroslužieb nachádza uplatnenie v systémoch, ktoré vykonávajú mnoho úloh alebo pri tvorbe modulárnych systémov, kde je možné využiť už existujúce služby. Mnoho gigantov ako Netflix, eBay či Amazon si osvojilo tento prístup. [27]
3.4. Zeta
3.4 Zeta
Vo veľkých spoločnostiach čoraz rýchlejšie rastú očakávania a s nimi aj potreba rýchlejšieho spracovania a integrácie. ArchitektúraZetaprináša nový prístup, ktorý prepája technologické riešenie s podnikovou architektúrou spoločnosti.
Kladie dôraz na zabezpečenie a jednotný systém autentizácie naprieč všetkými komponentami vrámci spoločnosti.
Obr. 3.5: Model Zeta architektúry podľa [21].
Využíva kontajnery ako izolované prostredia, v ktorých sú spúšťané apli- kácie. [28] Všekty kontajnery majú prístup k zdieľanému distribuovanému úlo- žisku, kde sú uložené všetky dáta a bežia na spoločnom hardvéri. To umožňuje efektívne využívať systémové zdroje a aplikáciám ich priradzovať podľa po- treby. Uľahčená je tým pádom aj integrácia nových aplikácií, pretože odpadá potreba vytvárať dedikovanú infraštruktúru.
3.4.1 Výhody a nevýhody
Združovanie všetkých aplikácií do jednej infraštruktúry, ktoré prináša na prvý pohľad zjednodušenie v mnohých ohľadoch, môže byť zároveň aj nevýhodou.
Architektúra, ktorá obsahuje veľa aplikácií sa môže stať neprehľadnou. Rov- nako vzniká potreba oddelené kontajnery nejakým spôsobom spravovať.
3.4.2 Prípady použitia
Architektúra Zeta je vhodná pre veľké organizácie, ktoré spravujú ohromné množstvo údajov a nevyhnutne potrebujú mnoho aplikácií na ich rôzne spra-
covanie. Rôzne aplikácie totiž často pracujú s rovnakými dátami, preto je ich zdieľanie výhodné. Túto architektúru si adoptovala aj spoločnosť Google pri svojej službe Gmail. [28]
3.5 Iot-a
Svet IoT riešení vznikol pomerne rýchlo a živelne. Systémy na spracovanie dát, ktoré spracujú údaje z najrôznejšich zariadení pripojednch do internetu sú tak rôznorodé, že je náročné navrhnúť všeobecný koncept ich fungovania.
Vďaka využitiu v inteligentných riešeniach, ako sú inteligentné domácnosti (angl.smart homes) alebo inteligentné mestá (angl.smart cities), sa platforma IoT teší popularite a prirodzene sa zaradila k Big Data riešeniam.
Michael Hausenblas sa v [29] pokúsil navrhnúť architektúru s vysokou mierou abstrakcie, ktorá vychádza z požiadaviek na systémy platformy IoT.
Táto architektúra sa nazýva Iot-a (the Internet of things architecture) a je zložená z troch vrstiev.
Obr. 3.6: Model Iot-a architektúry podľa [21].
Prvá vrstva je typicky postavená na systéme na zasielanie správ (angl.mes- saging system), ktorý zachytáva prúd dát zo zdrojov. Odtiaľ môžu byť dáta prúdovo spracované.
3.6. Porovnanie Druhá vrstva, nazývaná tiež databázová, slúži na zoskupovanie čiastkových výsledkov prúdového spracovania z prvej vrstvy. Túto vrstvu je možné implementovať pomocou NoSQL databázy.
Tretia vrstva slúži na dávkové spracovanie dát. Je postavená nad distri- buovaným súborovým systémom. Údaje čerpá z prvej vrstvy. Výsledky tejto vrstvy korigujú aproximačné výsledky prvej vrstvy.
3.5.1 Výhody a nevýhody
Keďže sa jedná o pomerne abstraktný model, ktorý nie je možné v jednej forme použiť na všetky IoT systémy, je ťažké hodnotiť klady a zápory. Zaujímavé ale je, že požiadavky na výsledky je možné smerovať na všetky tri vrstvy.
3.5.2 Prípady použitia
Iot-a architektúra má praktické využitie napríklad v systéme inteligentnej do- mácnosti. Prvá vrstva poskytuje vďaka prúdovému spracovaniu výsledky tak- mer v reálnom čase, a dokáže tak napríklad rýchlo oznámiť majiteľovi domu vlúpanie alebo požiar. Výsledky databázovej vrstvy je možné použiť na moni- torovanie aktuálnej kondície domu a tretia vrstva poskytuje dlhodobé štatis- tiky zo všetkých senzorov.
3.6 Porovnanie
Predstavil som 5 významných návrhových modelov na spracovanie v oblasti veľkých dát. Vznikali v priemysle, ale aj v akademickom prostredí, v snahe vyriešiť reálne problémy.
Je náročné ich podrobiť priamemu porovnaniu, pretože každá z týchto architektúr sa zameriava na riešenie iných typov úloh. Pri návrhu je preto potrebné zvážiť požiadavky na konkrétny novovznikajúci systém. Konkrétne rýchlosť, akou chceme dostať výsledky, presnosť výsledkov, spoľahlivosť a šká- lovateľnosť systému, rýchlosť vývoja, udržateľnosť kódu a mnoho iných. Zvážiť, ktoré je nevyhnutne potrebné uspokojiť a kde je možné spraviť kompromis.
Kapitola 4
Analýza a návrh architektúry
V tejto kapitole bližšie predstavím problematiku logovania, zberu logov a ich analýzy za účelom cielenia reklamy používateľom. Definujem požiadavky, ktoré by mal spĺňať systém určený na centralizáciu logov. Následne na základe po- žiadaviek navrhnem vhodnú architektúru takéhoto systému.
4.1 Úvod do problematiky
Podpora (angl.promotion) je jedným zo štyroch základných bodov marketin- gového mixu. [30] Marketingový mix, označovaný aj ako
”štyri P“, popisuje marketingové nástroje, ktoré môžu firme pomôcť dosiahnuť ciele prostred- níctvom ovplyvnenia trhu. Popri produktovej, cenovej a distribučnej politike vyjadruje podpora spôsoby, akými môžu podniky propagovať svoj produkt alebo službu.
Najdôležitejšou časťou podpory je reklama. Úlohou reklamy je v prvom rade presvedčiť o kúpe. Existuje mnoho kanálov, ktorými je možné širiť re- klamu. Potenciálnych zákazníkov možno osloviť umiestnením fyzickej reklamy v podobe plagátov, billboardov či iných pútačov, alebo rôznymi médiami ako sú tlač, rozhlas a televízia. Voľba konkrétneho kanálu vo veľkej miere záleží na cieľovej skupine, ktorú má daná reklama osloviť.
Špeciálnym typom reklamy je internetová reklama. Hlavným druhom in- ternetovej reklamy je bannerová reklama. Ide o vyhradené plochy na webových stránkach, umiestnené v blízkosti primárneho obsahu. Oproti ostatným kaná- lom sa dá reklama na internete lepšie naplánovať. Je možné zakúpiť si počet zobrazení alebo počet kliknutí na reklamu.
Navyše je reklama na internete neporovnateľne flexibilnejšia. Na tom istom banneri sa môže rôznym používateľom zobraziť rôzna reklama. Takúto reklamu nazývame cielená reklama.
