MASARYKOVA

UNIVERZITA
FAKULTA INFORMATIKY

Prieskum možností ukladania

a analýzy sieťových tokov
v úložiskách platformy Google
Cloud

Diplomová práca

MILOŠ FERENČÍK

Brno, jar 2022

 MASARYKOVA
UNIVERZITA
FAKULTA INFORMATIKY

Prieskum možností ukladania

a analýzy sieťových tokov
v úložiskách platformy Google
Cloud

Diplomová práca

MILOŠ FERENČÍK

Vedúci práce: RNDr. Petr Velan, Ph.D.

Katedra počítačových systémov a komunikácií

Brno, jar 2022

Vyhlásenie

Vyhlasujem, že táto diplomová práca je mojím pôvodným autorským

dielom, ktoré som vypracoval samostatne. Všetky zdroje, pramene
a literatúru, ktoré som p r i vypracovaní používal alebo z nich čerpal,
v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj.

Miloš Ferenčík

Vedúci práce: R N D r . Petr Velan, Ph.D.

iii
Poďakovanie

Týmto by som chcel vyjadriť vďaku môjmu vedúcemu práce R N D r .

Petrovi Velanovi, Ph.D. za jeho čas, cenné rady a rýchle riešenie vznik­
nutých problémov. Ďalej sa chcem poďakovať mojím rodičom, kama­
rátom a obzvlášť mojej snúbenici za obrovskú podporu počas môjho
štúdia.

iv
Zhrnutie

Monitorovanie siete hrá kľúčovú rolu pre správny manažment akých­

koľvek sietí. Sú to práve sieťové toky, prostredníctvom ktorých môže
monitorovanie siete ponúknuť správcom siete širší pohlaď na dianie v
sieti. Táto práca sa snaží poskytnúť prehľad možností ukladania a ana­
lýzy sieťových tokov využitím úložísk platformy Google Cloud. Kon­
krétne porovnáva výkon dopytovania Google BigQuery nad dátami
uloženými v jeho natívnom úložisku s dátami uloženými v Google
C l o u d Storage vo formáte Apache Parquet.

Klučové slová

IPFIX, Apache Parquet, Google C l o u d , Google BigQuery,.

v
Obsah

Úvod 1

1 Využitie sieťových tokov 3

1.1 Riadenie siete 3
1.2 Profilovanie siete 3
1.3 Monitorovanie a plánovanie QoS 4
1.4 Bezpečnosť siete 4
1.5 Účtovanie a fakturácia služieb 6

2 Architektúra monitorovania sieťových tokov 7

2.1 Pozorovanie paketov 7
2.2 Vytvorenie a exportovanie tokov 9
2.3 Zbieranie sieťových tokov 11
2.4 Analýza sieťových tokov 13

3 Apache Parquet 15
3.1 Štruktúra parquet súboru 15
3.2 Metadáta 16
3.3 Kódovanie 17
3.4 Kompresia 18

4 Google BigQuery 19
4.1 Architektúra 19
4.1.1 Dremel 19
4.1.2 Colossus 21
4.1.3 Jupiter 21
4.1.4 Borg 22
4.2 Dopytovanie 22
4.3 Uloženie dát 23
4.3.1 Organizácia dát 23
4.3.2 Nahrávanie dát 23
4.3.3 Export dát 25
4.3.4 Formát uloženia 26
4.3.5 Optimalizácie pre zlepšenie výkonu dopytovania 26
4.4 Integrácia v G C P 29

vi
 4.5 Bezpečnosť 30

4.6 Poplatky 30

5 Proces generovania a uloženia dát 33

6 Metodológia 35
6.1 Dátové súbory 35

6.2 Prípadové štúdie 35

7 Výsledky 38

8 Záver 45

Bibliografia 4 6

A Obsah priloženého archívu 50

vii
Úvod

S narastajúcim počtom používateľov siete taktiež narastá jej zaťaženie,

čo má za následok, že siete sa neustále rozširujú a stávajú sa tak zložitej­
šími. To v praxi znamená stále vyššie nároky na riadenie a zaistenie jej
bezpečnosti, k čomu využívame tzv. monitorovanie siete. Existujú dve
možnosti: aktívne a pasívne monitorovanie. V aktívnom prístupe je do
siete vkladaná ďalšia prevádzka k získaniu informácií, pričom pasívny
prístup iba sleduje sieťovú prevádzku a nijako do nej nezasahuje. M e ­
dzi metódy pasívneho monitorovania radíme export sieťových tokov
a packet capturing. Packet capturing analyzuje obsah celých paketov
putujúcich po sieti, čo je náročnejšie v porovnaní s exportom sieťových
tokov, kde sa analyzuje iba hlavička paketu. Export sieťových tokov
tak predstavuje lepšiu volbu pre siete s vysokou sieťovou prevádzkou,
keďže spracováva menšie množstvo dát a je menej náchylný na poru­
šenie súkromia. Pracovná skupina pre IPFIX v rámci organizácie IETF
v práci [1] definovala sieťový tok takto: "Sieťový tok je množina IP
paketov, ktoré prechádzajú pozorovacím bodom v sieti počas určitého
časového intervalu. Všetky pakety patriace do konkrétneho toku majú
súbor spoločných vlastností."
P r i monitorovaní sietí s vysokou prevádzkou už hovoríme o ana­
lýze tzv. big data. V tomto scenári tradičné nástroje používané k ana­
lyzovaniu sieťových tokov pôsobia obmedzujúco, pretože doba na
vyhodnotenie analýzy takého veľkého objemu dát je príliš dlhá. V dneš­
nej dobe sa na analýzu b i g data používajú cloudové nástroje, ktoré
sú postavené na distribuovaných riešeniach. Preto sme sa rozhodli
vyskúšať analýzu sieťových tokov v týchto nástrojoch s očakávaním
rýchlejšieho vyhodnotenia.
Cieľom práce je urobiť prieskum možností a obmedzení p r i ukla­
daní a spracovávaní dát popisujúcich sieťové toky vo formáte Apache
Parquet v nástrojoch, ktoré ponúka Google C l o u d . Konkrétnejšie sa
zameriame na nástroj Google BigQuery, ktorý umožňuje analýzu dát
uložených vo svojom natívnom úložisku, ale aj v iných úložiskách
napríklad Google C l o u d Storage. Vyskúšame rôzne konfigurácie ulo­
ženia sieťových tokov vo formáte Apache Parquet v úložisku Google
C l o u d Storage a v úložisku BigQuery. Následne tieto konfigurácie
porovnáme na základe ceny a rýchlosti vyhodnotenia.

1
 Čo sa týka štruktúry zvyšku tejto práce, tak v kapitole 1 je popí­
sané, v akých oblastiach môžu byť aplikované sieťové toky. Kapitola 2
objasňuje celý proces od získavania sieťových tokov až po ich analýzu.
Formát Apache Parquet je popísaný v kapitole 3. Cieľom kapitoly 4
je priblížiť fungovanie nástroja Google BigQuery. Kapitola 5 popisuje
dátový súbor sieťových tokov použitý v následných porovnaniach.
Metódy použité v našich porovnaniach sú vysvetlené v kapitole 6.
V kapitole 7 sú uvedené výsledky porovnaní. Nakoniec tento doku­
ment uzavrieme v kapitole 8, kde vyvodíme naše závery.

2
1 Využitie sieťových tokov

V dnešnej digitálnej dobe, kedy takmer každý pracuje a komunikuje

prostredníctvom digitálnych zariadení, je potrebné mať dostatok adek­
vátnych informácií na správne riadenie a udržiavanie počítačových
sietí. Práve informácie zo sieťových tokov k tomu dopomáhajú. Sieťové
toky je možné zbierať na rôznych miestach ako chrbticová sieť, siete po-
skytovateľov internetových služieb, lokálne siete organizácií a firiem,
virtuálna sieť v Cloude. Podľa umiestnenia sú tieto informácie zaují­
mavé pre rôzne entity, napríklad administrátora siete, bezpečnostného
analytika, poskytovateľa internetových služieb, poskytovateľa obsahu.
V tejto kapitole si priblížime, kde všade vieme informácie zo sieťových
tokov aplikovať.

1.1 Riadenie siete

Monitorovanie siete na báze sieťových tokov prináša správcom siete

širší pohlaď na dianie v sieti. Aktuálne informácie o sieťových sme-
rovačoch a prepínačoch, vyťažení šírky pásma a iné i m umožňujú
identifikovať prevádzkové a konfiguračné problémy v sieti. Následne
vďaka znalosti kontextu ich aj efektívne vyriešiť.
Nástroje na monitorovanie siete disponujú viacerými schopnos­
ťami. Patrí sem reportovanie správ, vytváranie štatistík, upozorňovanie
na možné problémy, prehľadávanie a filtrovanie záznamov. Nahlásené
správy sa môžu týkať napríklad využitia šírky pásma jednotlivými
užívateľmi či stavu sieťových smerovačov a prepínačov, z čoho vieme
zistiť prípadné problémy v smerovaní. Upozornenia môžu poukázať
napríklad na prekročenie hranice vyťaženia siete, použitie nechceného
protokolu alebo aplikácie a iné. Jednou z najpoužívanejších štatistík je
identifikácia hostiteľov, ktorí vytvárajú najviac nepotrebnej komuniká­
cie [2].

1.2 Profilovanie siete

Zo záznamov sieťových tokov z dlhého časového obdobia vieme od­

hadnúť trendy nasledujúceho využitia siete, determinovať súčasné aj

3
 i . VYUŽITIE SIEŤOVÝCH TOKOV

budúce požiadavky sieťovej infrastruktury. N a základe predpovedí

plánovať kapacitu siete a tým znížiť riziko degradácie výkonnosti
siete a jej odstávok, predísť problémom s vysokou latenciou a úzkymi
hrdlami výkonnosti, prípadne zmeniť dizajn siete.
Poskytovatelia internetových služieb môžu na základe analýz sie­
ťových tokov optimalizovat peeringové dohody. Pre poskytovateľa
obsahu je to užitočný vstup pre profilovanie návštevnosti. Pre širokú
verejnosť môže byť zaujímavá informácia o počte pridelených IPv6
adries, či koľko percent prevádzky patrí protokolu IPv6 [3].

1.3 Monitorovanie a plánovanie QoS

Administrátorom siete vie pomôcť kontrolovať dodržiavanie zmluvy

o úrovni služieb (SLA) pomocou monitorovania výkonnostných para­
metrov siete ako napríklad doba odozvy, opakovanie prenosu, one­
skorenie, džiter (jitter), doručovanie paketov m i m o poradie, strata
paketov.
Naopak poskytovatelia internetových služieb a poskytovatelia ob­
sahu potrebujú na zabezpečenie kvality služieb informácie o dátach
putujúcich po sieti, napríklad akej aplikácii dáta patria. N a to sa pou­
žíva klasifikácia sieťových aplikácií, ktorá rozdeľuje sieťovú prevádzku
do určitých kategórií. Klasifikácia sieťových aplikácií je náročná úloha
kvôli technikám na zamaskovanie dát, ako je šifrovanie obsahu, dy­
namické porty či proprietárne komunikačné protokoly. Prístupy na
klasifikáciu sieťových tokov možno rozdeliť do troch kategórií: za­
ložené na portoch, na heuristike štatistík transportnej vrstvy a na
strojovom učení. Prístupy založené na portoch už nie sú spoľahlivé,
pretože niektoré aplikácie náhodne priraďujú porty. Prístupy založené
na heuristike a strojovom učení predstavujú alternatívne metódy [4].

1.4 Bezpečnosť siete

Vzhľadom k tomu, že v dnešnej dobe sa vyskytujú útoky, ktoré môžu

unikať a aj unikajú tradičným spôsobom ochrany, je potrebné sa zame­
rať na rozširovanie spektra použitých bezpečnostných prvkov. Sieťové
toky a ich analýza sa javia ako efektívny nastroj ochrany pred sieťo­
vými útokmi. Nástroje založené na sieťových tokoch nás upozornia

4
 i . VYUŽITIE SIEŤOVÝCH TOKOV

napríklad na neobvyklé prenosy dát, zneužitie komunikačných pro­

tokolov, používanie nepreferovaného šifrovania, cudzie zariadenia
a iné. Slúžia aj na odhalenie hrozieb nultého dňa (zero days attacks)
na základe pozorovania anomálií. Detekcia sieťových anomálií sa týka
hľadania vzorcov, ktoré nie sú očakávaným správaním používateľov.
N a odhalenie anomálií sa používa umelá inteligencia, adaptivně prahy,
heuristika, vzory chovania. N a druhej strane máme už známe útoky,
ktoré vykazujú na sieti nejaké charakteristiky. Tieto charakteristiky
sú väčšinou odhalené z agregovaných štatistík sieťových tokov. Ďal­
šou metódou odhaľovania bezpečnostného rizika je porovnávanie IP
adries zachytených na sieti s nebezpečnými IP adresami z čiernych
zoznamov. Pomocou sieťových tokov vieme napríklad odhaliť [4] [5]:

• Skenovanie portov
Skenovanie portov je útok, ktorý priamo neničí cieľový systém,
ale získa otvorené porty systému, ktoré sú použité v ďalších
útokoch v budúcnosti. Skenovanie je zvyčajne vykonávané syste­
maticky pomocou zasielania malých paketov.

• Útok na vyradenie služby (Denial of service)

Účelom útoku na vyradenie služby (DoS) alebo distribuované
vyradenie služby (DDoS) je, aby cieľový hostiteľ alebo sieťový
zdroj nebol schopný reagovať na ostatné požiadavky. Teda legi­
tímni používatelia zažívajú zníženú úroveň služieb alebo nemajú
prístup k službe vôbec.

• Červa (Worm)
Červ je samostatný škodlivý program. Využíva zraniteľnosť soft-
véru alebo sociálne inžinierstvo na oklamanie používateľov k re-
plikácii naprieč sieťou. Spektrum následkov po infiltrácii červa
zahŕňa rôzne nepríjemné efekty ako poškodenie údajov alebo
softvéru, DoS, krádež údajov atď. Detekcia skenovania portov
je jedným z dôležitých krokov p r i detekcii červov, a preto sa
v oboch typoch detekcie používa veľa podobných prístupov. Prí­
stupy založené na sieťových tokoch zahŕňajú: analýzu správania
hostiteľa na základe prichádzajúcich a odchádzajúcich pripojení,
koreláciu medzi údajmi zo sieťových tokov a údajmi z honeypot,
a detekciu hit-list červov pomocou grafovej analýzy.

5
 i . VYUŽITIE SIEŤOVÝCH TOKOV

• Botnet
Botnet je malvér v infikovanom zariadení, ktorý je ovládaný
vzdialene. Je považovaný za veľkú bezpečnostnú hrozbu, pre­
tože prostredníctvom neho sú vykonávané ďalšie kybernetické
zločiny ako DDoS útoky, spamovanie, phishing, krádež identity
a iné. N a ovládanie botnetov sa používajú komunikačné kanály
od centralizovaných IRC a H T T P po decentralizované P2P siete.
Detekcia botnetu je relatívne náročnejšia ako detekcia červov
či skenovanie portov. Najnovšie prístupy využívajú pokročilé
metodológie a kombinujú informácie na úrovni hostiteľa a siete.

Po odhalení niektorých hrozieb je potrebné potvrdiť ich riziko, či do­

plniť ďalšie informácie následnou forenznou analýzou komunikácie
medzi účastníkmi.
Hlavné výhody použitia sieťových tokov na odhalenie bezpečnost­
ných rizík sú fungovanie v šifrovanej komunikácii a nízka pamäťová
náročnosť, pretože nezávisia od obsahu paketu, a teda môžu byť pou­
žité aj na chrbticovej sieti s tisícmi tokov za sekundu.

1.5 Účtovanie a fakturácia služieb

Informácie zo štatistík sieťových tokov je možné použiť aj na účtovanie

a fakturáciu služieb založených na množstve prenesených dát. Avšak
tieto informácie neposkytujú úplnú spoľahlivosť, pretože môže dôjsť
k nepresnostiam p r i vytváraní a exportovaní sieťových tokov. Pri vy­
tváraní napríklad vtedy, keďje použitý sampling či filtering alebo keď
nastane preťaženie exportéra. P r i exportovaní vtedy, keďje použitý
U D P protokol, ktorý nezaručuje spoľahlivé doručenie správ. Tieto ne­
dostatky by mali byť zohľadnené hlavne p r i zvažovaní použitia pre
účtovanie, avšak aj p r i ostatných použitiach [3].

6
2 Architektúra monitorovania sieťových tokov

Monitorovanie sieťových tokov má široké spektrum uplatnenia, ako

bolo uvedené v kapitole 1. Proces monitorovania sieťových tokov sa
skladá zo štyroch etáp, ktoré sú najčastejšie vykonávané na dvoch za­
riadeniach, exportér a kolektor. V tejto kapitole si tieto etapy postupne
opíšeme. Celý proces je tiež znázornený na obrázku 2.1.

2.1 Pozorovanie paketov

Pozorovanie paketov je prvou etapou procesu. Jej úlohou je zachytávať

pakety zo siete a následne ich pred-spracovať pre ďalší krok.
Miesto, kde sa zachytávajú pakety zo siete sa nazýva pozorovací
bod. Nájsť v sieti vhodné umiestnenie pre pozorovací bod je kľúčovou
úlohou monitorovania siete. Pakety je možné zachytávať v drôtových,
bezdrôtových či virtuálnych sieťach. Najčastejšie sa zachytávajú v drô­
tových sieťach, ale keďže používanie cloudového prostredia je čoraz
rozšírenejšie, tým pádom aj zachytávanie vo virtuálnych sieťach sa
stáva častejším. Existujú dva spôsoby ako pripojiť zariadenie na zber
sieťovej prevádzky do drôtovej siete. Prvým spôsobom je vloženie
ďalšieho zariadenia napríklad Network T A P do siete, ktoré duplikuje
sieťovú prevádzku. Výhoda tohto spôsobu je, že prenášané dáta nie
sú nijak pozmenené a ich prenos je bez prestojov. D r u h o u možnos­
ťou je využitie metódy zrkadlenia portov na sieťovom zariadení. Táto
alternatíva avšak môže spôsobiť oneskorenie, modifikácie obsahu či
zmeniť poradie paketov. Vo virtuálnych sieťach sa nachádzajú virtu­
álně smerovače, ktoré podporujú zrkadlenie portov aj virtuálně TAP.
Po tom, čo bol paket zachytený v pozorovacom bode, dôjde k jeho
označeniu časovou známkou, čo je veľmi dôležité hlavne vtedy, ak
budú neskôr analyzované dáta z viacerých pozorovacích bodov. Po
označení nasleduje orezanie, ktoré napríklad z paketu zachová len
jeho hlavičku. V prípadoch, keď spracovanie sieťovej prevádzky pre­
sahuje limity použitého hardvéru, je vhodné použiť metódy na jej
zredukovanie ako vzorkovanie a filtrovanie, a tak z nekontrolovateľnej
straty paketov spraviť kontrolovateľnú stratu [2].
Vzorkovanie paketov je metóda, pri ktorej sú niektoré pakety zaho­
dené, aby sa znížilo množstvo dát, ktoré je potrebné spracovať v ďalších

7
 2. ARCHITEKTÚRA MONITOROVANIA SIEŤOVÝCH TOKOV

Zbieranie sieťových Maiiuáha analýza

tokov sieťových tokov
Exportér

Pozorovanie Automatická analýza

paketov - > sieťových toKcv sieťových toKov

•značenie časovou
Vzorkovanie
známkou

Obr. 2.1: Architektúra monitorovania sieťových tokov.

krokoch. Treba však podotknúť, že po použití vzorkovania je nároč­

nejšie odhaliť bezpečnostné hrozby [5]. Techniky vzorkovania môžu
byť rozdelené do dvoch kategórií:

• Systematické - patria tu vzorkovania založené na čase alebo

udalosti. Napríklad každú t sekundu sa zahodí paket alebo každý
n-tý prichádzajúci paket je zahodený.

• Náhodné - vzorkovanie závisí od použitej distribučnej funkcie

pravdepodobnosti. Napríklad prichádzajúce pakety sú rozdelené
do postupností o N paketoch a z nich je n náhodne zahodených.
Inou možnosťou je, že každý prichádzajúci paket môže byť od­
stránený s pravdepodobnosťou p, pričom p môže byť fixné alebo
odvodené z niektorej charakteristiky daného paketu.

Filtrovanie paketov odstráni pakety, ktoré nespĺňajú stanovenú

podmienku. Podobne ako vzorkovanie slúži táto metóda na redukova­
nie množstva dát. Filtrovanie paketov robíme väčšinou na základe [2]:

• vlastnosti paketu - hodnota vlastnosti paketu je zhodná s predom

definovanou hodnotou alebo spadá do nejakého rozsahu hodnôt.
Používa sa napríklad na zbieranie paketov len určitej aplikácie
alebo IP adresy.

8
 2. ARCHITEKTÚRA MONITOROVANIA SIEŤOVÝCH TOKOV

• hašovacej funkcie - hašovacia funkcia sa aplikuje na celý paket

alebo jeho časť a výsledok je porovnaný s predom definovanou
hodnotou alebo rozsahom.

2.2 Vytvorenie a exportovanie tokov

Druhou etapou monitorovania sieťových tokov je vytvorenie a expor­

tovanie tokov. Táto etapa sa deje na zariadení exportér, kde sa z prichá­
dzajúcich paketov vytvoria záznamy sieťových tokov, následne sa tieto
záznamy vložia do správy a sú exportované na kolektor. Jednotlivé
kroky tejto etapy sú tiež definované v štandarde Internet Protocol Flow
Information Export (IPFIX), ktorý bol štandardizovaný organizáciou
IETF.
IPFIX protokol používa informačné elementy (IE) na definovanie
atribútov v IPFIX záznamoch. IE je súbor informácií, ktoré špecifi­
kujú daný element. IE musí obsahovať unikátny a zmysluplný názov,
unikátny číselný identifikátor, popis sémantiky IE alebo tiež spôsob,
ako získať hodnotu pre tento IE, dátový typ, stav (aktuálny, neodpo­
rúčaný, zastaraný), prípadne môže obsahovať sémantiku dátového
typu, jednotky, rozsah a odkaz. Verejné IE sú uložené v registri, ktorý
spravuje organizácia I A N A [6].
Proces vytvárania sieťových tokov má aktívne sieťové toky uložené
ako záznamy v tabuľke. Prichádzajúce pakety sú klasifikované do
tokov podľa kľúčových IE. Klasifikácia prebieha tak, že sa vytvorí
haš z kľúčových IE paketu, ktorý je porovnaný s hašmi záznamov
v tabuľke. A k sa nájde zhoda, nekľúčové IE záznamu sieťového toku
sú aktualizované s IE z paketu, inak sa vytvorí nový záznam v tabuľke.
Môžme tiež povedať, že prichádzajúce pakety sú agregované podľa
kľúčových IE. Najčastejšími kľúčovými IE sú IP adresa a port zdroja
a cieľa, nekľúčovými IE sú počet prenesených paketov a bajtov.
Súčasťou procesu vytvárania sieťových tokov je aj určenie ich exspi-
rácie. Teda okamih, kedy je sieťový tok vhodný na ďalšie spracovanie.
V IPFIX štandarde sa uvádza, že sieťový tok môže byť exspirovaný
ak [7]:

• daný sieťový tok nebol aktualizovaný po dobu t. Tento časový

limit t musí byť väčší ako 0 a typicky býva nastavený v rozmedzí
15 sekúnd až 5 minút.

9
 2. ARCHITEKTÚRA MONITOROVANIA SIEŤOVÝCH TOKOV

• nastane obmedzenie zdrojov, napríklad je nedostatok pamäte na

uloženie ďalšieho sieťového toku.

• je sieťový tok aktívny po dobu t. Cieľom tohto časového limitu je

postupné spracovanie dlhotrvajúcich sieťových tokov. A k je exs-
pirovaný dlhotrvajúci sieťový tok, tak záznam v tabuľke nemusí
byť vymazaný, stačí, ak hodnoty nekľúčových IE sú vynulované.
Čas t musí byť väčší ako 0 a typicky býva nastavený v rozmedzí
120 sekúnd až 30 minút.
Nastavenie časových limitov na exspiráciu sieťových tokov je dôležitou
úlohou v procese vytvárania sieťových tokov. O d ich hodnôt závisí
viacero aspektov. Čím sú vyššie, tým je veľkosť tabuľky aktívnych
sieťových tokov väčšia, pretože obsahuje viac záznamov alebo trvá
dlhšie, kým môžu byť sieťové toky analyzované. Naopak čím sú nižšie,
tým väčšia záťaž je vyvíjaná na kolektor, pretože je poslaných viac
sieťových tokov [2].
Pred samotným exportom je možné spraviť vzorkovanie a filtro­
vanie, avšak už nie nad paketmi, ale nad záznamami sieťových tokov.
Cieľom je opäť znížiť záťaž pre následné spracovanie. Metódy vzorko­
vania a filtrovania sú podobné ako bolo popísané vyššie.
Posledným procesom v tejto etape je export sieťových tokov. Úlo­
hami exportného procesu sú vytvorenie IPFIX správy z exspirovaných
sieťových tokov, nastavenie kedy sa budú správy odosielať, či už peri­
odicky alebo na základe exportnej politiky a nastavenie transportného
protokolu, ktorý sa použije na odoslanie správy kolektoru. IPFIX pod­
poruje tri transportné protokoly SCTP ,TCP a U D P
IPFIX správa zobrazená na obrázku 2.2 obsahuje hlavičku, po kto­
rej nasleduje jedna alebo viacero množín, ktoré môžu byť rôzneho
typu. Hlavička sa skladá z verzie, dĺžky správy, času exportovania,
poradového čísla a unikátneho identifikačného čísla exportéra [8].
Množiny môžu byť jednou z týchto troch typov:
• dátová množina - obsahuje záznamy sieťových tokov rovnakého
typu, pričom typ už musel byť definovaný predtým pomocou
šablónového záznamu.

• šablónová množina - obsahuje šablónové záznamy, ktoré defi­

nujú typ sieťového toku. Definícia opisuje štruktúru a IE, ktoré
sieťový tok obsahuje.

10
 2. ARCHITEKTÚRA MONITOROVANIA SIEŤOVÝCH TOKOV

Hlavička Správy Čislo Verzie Dĺžka

s
Množina \ Čas Exportu
\

Množina Poradové čisk)

v
-s
Množina ID Exportéra
v

Množina

Obr. 2.2: IPFIX správa.

• alternatívna šablónová množina - podobne ako šablónová mno­

žina obsahuje šablónové záznamy, ktoré navyše definujú rozsah
použiteľnosti daného sieťového toku.

2.3 Zbieranie sieťových tokov

Treťou etapou monitorovania sieťových tokov je proces zbierania sieťo­

vých tokov. Prebieha na zariadení, ktoré voláme kolektor. N a kolektore
môže bežať súčasne viac týchto procesov. Jeho hlavnou úlohou je uložiť
záznamy sieťových tokov prijatých v IPFIX správach z jedného alebo
viacerých exportérov. Spôsob uloženia vo veľkej miere ovplyvňuje
výkon následnej analýzy dát. Rozlišujeme dva typy pamäte: volatilná
a perzistentná. Volatilná pamäť, teda nestála, má rýchlejšie čítanie
a zápis, avšak neslúži na dlhodobé uloženie dát. Preto sa väčšinou
používa len na uloženie dočasných výsledkov počas pred-spracovania
prichádzajúcich správ, prípadne u niektorých kolektorov sú dáta ana­
lyzované hneď ako prídu, a tak nie je potrebné ukladať sieťové toky
do dlhodobej pamäte. Avšak u tých kolektorov, kde sa predpokladá
neskoršia analýza, je potrebné dáta uložiť do perzistentnej pamäte na
dlhodobú úschovu. Keďže pri monitorovaní sietí s veľkou premávkou
vzniká veľké množstvo sieťových tokov, často sa tieto dáta pred dlho­
dobým uložením komprimujú, aby nezaberali veľa pamäte. Ďalšou
častou úpravou dát je takzvaná anonymizácia, kedy citlivé dáta ako

11
 2. ARCHITEKTÚRA MONITOROVANIA SIEŤOVÝCH TOKOV

napríklad IP adresy sú anonymizované, aby v prípade ich ukradnutia

nemohli byť zneužité.
P r i dlhodobej úschove sieťových tokov väčšinou zvažujeme tieto
tri typy uloženia:

• ploché súbory - vyznačujú sa rýchlym čítaním a zápisom, ale po­

skytujú iba obmedzené možnosti vyhľadávania. Patria tu textové
a binárne súbory. Tento typ úložiska využíva napríklad systém
nfdump.

• riadkovo orientované databázy - dáta z tabuľky sú uložené po

riadkoch, patria tu databázové systémy ako M y S Q L , PostgreSQL
a iné.

• stĺpcovo orientované databázy - dáta z tabuľky sú uložené po

stĺpcoch. Výhodami sú, že na zodpovedanie dopytu sú načítané
len potrebné stĺpce či efektívna kompresia, pretože dáta uložené
za sebou sú rovnakého typu. Tento typ úložiska využíva databá­
zový systém FastBit. V kapitole 3 sa bližšie pozrieme na stĺpcovo
orientovaný databázový formát Apache Parquet.

V prácach [9] [10] autori porovnávajú nástroje na analýzu sieťových

tokov, ktoré využívajú rôzne typy úložísk. Konkrétne v práci [9] sú
porovnávané nástroje nfdump a M y S Q L , v práci [10] zas nfdump
a FastBit. Z hľadiska spotreby miesta na disku, nfdump zaberá naj­
menej miesta. M y S Q L spotrebuje o tretinu viac miesta ako nfdump
a v prípade, že si vytvára aj indexy, tak jeho veľkosť môže vzrásť aj
niekoľkonásobne. P r i porovnaní nfdump a FastBit, rozdiel nie je až
tak markantný, avšak nfdump zaberá menej miesta. Treba ale podot­
knúť, že dáta neboli komprimované, pretože použitá verzia FastBit
nástroja to nepodporovala. Ďalšia charakteristika, ktorú porovnávali,
bol čas potrebný na zodpovedanie vybraných dopytov. Použité dopyty
obsahovali filtrovanie, agregáciu a zoskupovanie. N f d u m p prekonal
M y S Q L vo všetkých typoch dopytov. Pri porovnaní nfdump s FastBit,
bol FastBit rýchlejší takmer vo všetkých testovaných scenároch. Autor
to vysvetlil tak, že FastBit vždy potreboval načítať menej dát oproti
nfdump, či už kvôli použitému indexu alebo čítaniu len potrebných
stĺpcov pre vykonanie dopytu.

12
 2. ARCHITEKTÚRA MONITOROVANIA SIEŤOVÝCH TOKOV

2.4 Analýza sieťových tokov

Poslednou etapou monitorovania sieťových tokov je ich analýza. V tejto

etape výsledky z predchádzajúcich etáp začínajú dávať zmysel. A n a ­
lýza sieťových tokov má široké uplatnenie a jej jednotlivé oblasti pou­
žitia sú predstavené v 1 kapitole. Analýzy môžme rozdeliť podľa toho
kedy sa vykonávajú:

• za chodu v reálnom čase - dáta sú analyzované ihneď po prí­

chode na kolektor bez potreby ich uloženia. Samozrejme je to iba
skoro v reálnom čase, pretože ako bolo spomenuté v sekcii 2.2
vytváranie sieťových tokov väčšinou trvá istý čas [11].

• po dávkach - dáta sú po príchode na kolektor uložené do dlhodo­

bej pamäte po dávkach, napríklad jedna dávka obsahuje sieťové
toky za 5 minút. Následne sú tieto dáta analyzované s tým, že
k analýze môžu byť použité aj dáta z predchádzajúcich dávok.

• forenzná - analyzované sú dáta z minulosti.

N a analýzu sieťových tokov sa používajú rôzne prístupy [4]:

• štatistika - použitie štatistiky je základným prístupom, od kto­

rého sa odvíjajú ostatné. Štatistické metódy sú väčšinou ľahko
aplikovateľné a poskytujú celkom presné výsledky. Avšak sú
dobré len na detekciu už známych bezpečnostných hrozieb.

• strojové učenie - metódy strojového učenia získavajú vedomosti

z hľadania vzorov v dátach. Pred ich aplikáciou je ale potrebné
prejsť fázou učenia, kedy systém trénuje nad vzorovým súborom
dát. Strojové učenie sa používa napríklad na klasifikáciu sieťovej
prevádzky a detekciu anomálií.

• správanie sa siete - analýza na základe správania sa siete je

vhodná p r i odhaľovaní útokov nultého dňa. Prvým krokom
v tomto prístupe je zistiť normálne chovanie siete a následne
detegovať vzniknuté anomálie.

• heuristika - aplikovanie heuristiky je jednoduché, avšak vytvárať

kvalitné heuristiky je náročná činnosť. Heuristiky sa získavajú
dolovaním z predošlých dát.

13
 2. ARCHITEKTÚRA MONITOROVANIA SIEŤOVÝCH TOKOV

• vizualizácia - vo vizuálnej podobe môžu byť zobrazované dáta

zo sieťovej prevádzky alebo výsledky zo štatistík či strojového
učenia. Spraviť zmysluplnú a užitočnú vizualizáciu veľkého
množstva informácií s poskytnutím dostatočnej úrovne detailu
nie je jednoduchá úloha. Vizualizácie môžu zobrazovať rôzne
úrovne abstrakcie siete a používať rozličné typy grafov.

14
3 Apache Parquet

Uloženie a spracovanie veľkého objemu dát prinieslo nové výzvy. Jed­

nou z nich je aj rýchlosť vyhodnotenia dopytov, preto sa prešlo na ich
spracovanie v distribuovaných systémoch. Avšak na využitie poten­
ciálu distribuovaného systému musia byť dáta uložené tak, aby k n i m
mohlo byť přistupované paralelne. Taktiež u veľkého objemu dát sa
rieši veľkosť spotrebovanej pamäte či množstvo vstupno-výstupných
volaní p r i ich spracovaní. Tieto výzvy rieši aj dátový formát Apache
Parquet, ktorý si v tejto kapitole opíšeme.
Apache Parquet [12] je stlpcovo orientovaný databázový formát,
ktorý zlepšuje výkon spracovania dát a tiež znižuje náklady na ich ulo­
ženie. Taktiež je samo-opisný, pretože okrem dát obsahuje aj schému
uloženú v metadátach. Je to open-source projekt, ktorý patrí pod A p a ­
che Software Foundation. Apache Parquet podporuje ploché ale aj
vnorené dátové štruktúry vďaka implementácii algoritmov popísa­
ných v Dremel dokumente [13]. Okrem toho parquet súbor môže byť
vytvorený pomocou rôznych kódovaní a kompresií.

3.1 Štruktúra parquet súboru

Súbor parquet je navrhnutý hierarchicky, čo môžme vidieť na ob­

rázku 3.1. Súbor je horizontálne rozčlenený na logické oddiely nazý­
vané row-group. Počet záznamov v row-group je konfigurovatelný.
Každý row-group obsahuje jeden collumn-chunk pre každý stĺpec. Jed­
notlivé collumn-chunk sú v súbore uložené za sebou. Každý collumn-
chunk obsahuje minimálne jeden page, ktorý už viac nie je deliteľný
z hľadiska kódovania a kompresie. Page pozostáva z hlavičky, úrovne
opakovania, úrovne definície a hodnôt. Každá page musí obsahovať
aspoň jednu hodnotu, avšak úroveň opakovania a úroveň definície sú
voliteľné informácie, ktoré v prípade stĺpcu s nie vnorenou štruktúrou
môžu byť prázdne.
Dáta z jedného dátového súboru môžu byť uložené vo viacerých
parquet súboroch. Využíva sa to napríklad p r i použití hive partiti-
oning, čo je rozdelenie jednej tabuľky do viacerých na základe hodnôt
konkrétnych stĺpcov ako napríklad dátum. Teda konkrétny stĺpec je

15
 3- A P A C H E PARQUET

nie
Magic Number (4 bytes): "PARI"

Row group 0
Column a Footer
PageG F i l e M e t a D a t a (ThriftCompactProtocol)

Page header (ThriftCompactProtocol) Version (of the lormat)

Schema
Repetition levels extra key/value pairs
Definition levels
Row group 0 meta data:

values Column a meta data:

• type 1 path / encodings / codec
• num values
• offset of lirst data page
• offset of lirst index page
• compressed/uncompressed size
extra key/value pairs

Column b

Footer length (4 bytes)

Magic Number {4 byles): "PARI"

Obr. 3.1: Štruktúra parquet súboru. Zdroj: [12].

vyňatý z tabuľky a na základe jeho hodnôt je vytvorená priečinková

štruktúra, kde každej hodnote z daného stĺpca odpovedá jeden prie­
činok, v ktorom sa nachádza parquet súbor so záznamami z jeho
tabuľky [14]. Príkladné znázornenie môžme vidieť na obrázku 3.2.
Pri práci s formátom Apache Parquet existuje niekoľko úrovní
paralelizácie. Najvyššia úroveň je nad súbormi následne nad row-
group. Potom sa paralelizácia vykonáva nad column-chunks. Konečná
a najhlbšia úroveň paralelizácie je nad pages.

3.2 Metadáta

Rozlišujeme 3 typy metadát: metadáta pre súbor, metadáta pre column-

chunk a metadáta pre hlavičku page. Obsahujú dôležité informácie
týkajúce sa veľkosti, posunu na začiatok konkrétnej page, počtu hod­
nôt, typu kódovania, typu kompresie, typu údajov v stĺpcoch. Sú se-
rializované pomocou Thrift Compact Protokolu. Metadáta sú uložené

16
 3- A P A C H E PARQUET

I exportDate»2021 -08-07

export Date srclpv4 packets

IPv4

2021-08-08 147.251.48.1 20 147.251.48.31 31

• exporlDate»Ě021 -03-08
147 251.48.2 27
2021-08-07 147.251.48.3 31 packets
Partitioning podl'a\
exportDate
2021-08-08 147.251.48.2 15 147.251.48.1 20
I exportDate=2021 -08-09
147.251.48.2 15
2021-08-09 147.251.48.1 5

2021-08-07 147 251.48 2 27

Obr. 3.2: Hive partitioning.

na konci súboru, čo umožňuje zápis celého súboru na jedno prejde­

me. Vďaka tomuto dizajnu je tiež možné úplne oddeliť meta dáta od
dát a tým umožniť rozdelenie stĺpcov do viacerých súborov alebo
z jedného súboru metadát odkazovať na viacero súborov s parquet
dátami. O d verzie 2.0 sú v metadátach pre stĺpce uložené štatistiky
ako minimálna a maximálna hodnota, ktoré ešte viac zefektívnia ske-
novanie dát, pretože ak hľadaná hodnota nespadá do rozmedzia danej
row-group, môžme ju celú preskočiť.

3.3 Kódovanie

Apache Parquet formát podporuje veľa kódovaní a je navrhnutý tak,

aby mohol byť jednoducho rozšířitelný o ďalšie. Vo verzii 2.9 je možné
použiť plain, dictionary, R L E bit packed, delta binary packed, delta
length byte array, delta byte array a byte stream split kódovanie. Infor­
mácia o použitom kódovaní pre danú page je uložená v metadátach
pre page. Plain kódovanie je najjednoduchšie a môže byť použité na
všetkých typoch dát. Dictionary kódovanie vytvorí slovník s hodno­
tami vyskytujúcimi sa v danom stĺpci a namiesto hodnoty je uložený
jej kľúč zo slovníka. Názorný príklad pre dictionary kódovanie môžme
vidieť na obrázku 3.3.

17
 3- A P A C H E PARQUET

romplntcID | 21/ est as •at as •Ol

KeylBils] Value

00 257
inarv H
dine 01 259

10 262

templatelD | 00 •o Ol 00 0 03

Obr. 3.3: Dictionary kódovanie.

3.4 Kompresia

Kompresia je dôležitá technika, ktorá pomáha zmenšiť veľkosť pamäte

potrebnú na uloženie dát, v niektorých prípadoch aj viac ako o polo­
vicu. Kompresia vo formáte Apache Parquet je vykonávaná nad page,
čo umožňuje p r i dopytovaní robiť dekompresiu konkrétnej page až
keď sú dáta z nej potrebné. Apache Parquet vo verzii 2.9 podporuje
Snappy, GZIP, L Z O , BROTLI, L Z 4 a ZSTD kompresiu.

18
4 Google BigQuery

Spoločnosť Google v rámci svojej Google C l o u d Platformy ( G C P )

ponúka aj produkt Google BigQuery, ktorý slúži hlavne na analýzu
veľkého objemu dát. Je to vysoko škálovateľný dátový sklad, ktorý
alokuje zdroje dynamicky bez zásahu používateľa. Dopytovanie sa
vykonáva pomocou S Q L príkazov. Jeho vyhodnocovací stroj (query
engine) je schopný vyhodnotiť SQL príkaz nad terabajtami dát v rámci
sekúnd a nad petabajtami dát v rámci minút. Teda umožňuje používa­
teľom rýchlu analýzu veľkého množstva dát bez toho, aby sa museli
starať o infrastrukturu či riešiť indexy.

4.1 Architektúra

Google BigQuery je produkt, ktorý ponúka veľmi veľký výkon na ana­

lýzu dát. Z a týmto výkonom stojí aj rozhodnutie oddeliť výpočetně
zdroje o d úložiska. Toto oddelenie prináša mnoho výhod. Jednou
z nich je aj lepšie škálovanie, čo je dôležitá vlastnosť p r i zákazníkoch
s rôznymi potrebami. Jeden má uložené veľké množstvo dát, ale vý­
počty robí len ojedinelé, naopak druhý má uložené menšie množstvo
dát, ale robí nad nimi často náročné výpočty. Teda je možné rozširovať
buď výpočetné zdroje alebo pamäť podľa potrieb zákazníkov.
N a obrázku 4.1 môžme vidieť architektúru produktu Google B i ­
gQuery, kde celý systém je orchestrovaný cez Borg. Dáta sú uložené
v distribuovanom súborovom systéme Colossus. Dopyt je spracovaný
a orchestrovaný vyhodnocovacím strojom Dremel. Uložisko a výpo­
četné zdroje sú prepojené petabitovou sieťou Jupiter.

4.1.1 Dremel

BigQuery po prijatí dopytu deleguje Dremel [13] na jeho vyhodno­

tenie. Dremel je distribuovaný paralelný systém, ktorý sa stará o na­
plánovanie, rozdelenie dopytu na paralelné časti, spustenie a celkové
vyhodnotenie dopytu. V prvej časti Dremel prevedie S Q L príkaz na
graf tiež nazývaný dopytovací plán, ktorý má štruktúru stromu viď
obrázok 4.1. Dopytovací plán je rozdelený do série fáz dopytu takz­
vaných stages. Samostatná fáza pozostáva z podrobnejších krokov

19
 4- G O O G L E B I G Q U E R Y

Obr. 4.1: Architektúra produktu Google BigQuery. Zdroj: [15].

vykonávania [16]. Prevedenie prebieha tak, že koreňový server príjme

SQL dopyt, získa informácie z metadát a podľa heuristiky rozdelí
pôvodný SQL dopyt na nové paralelne spustitelné. Takto postupuje až
k najspodnejším uzlom, ktoré nazývame listy. Tie väčšinou čítajú dáta
z úložiska prípadne vykonávajú výpočty U z l y medzi listami a kore­
ňom nazývané mixers agregujú výsledky smerom k u koreňu [15].
Každý u z o l beží na takzvanom slote. Slot je jednotka výpočtovej
kapacity, tiež sa naň môžme pozerať ako na virtuálně C P U . Dremel na
začiatku automaticky vypočíta, koľko slotov vyžaduje každý dopyt,
v závislosti o d zložitosti dopytu a informácií z metadát. Avšak ich
počet sa môže za behu meniť [17].
Dopytovací plán v BigQuery je dynamický, čo znamená, že môže
byť upravený za behu. Jednou z najčastejšie zavádzaných fáz do plánu
počas vyhodnocovania dotazu je fáza s názvom Repartitioning. Táto
fáza sa používa na redistribúcie údajov medzi slotmi, aby nasledujúci
výpočet mohol prebehnúť na viacerých slotoch paralelne a tak sa
zlepšil výkon vyhodnotenia [16].
Proces, p r i ktorom si sloty predávajú dáta, nazývame BigQuery
shuffle. Vo väčšine prípadov prebieha cez vzdialenú volatilnú veľmi
rýchlu pamäť. Nazvime sloty, ktoré odosielajú dáta odosielateľ a ktoré
prijímajú príjemca. Potom BigQuery shuffle umožňuje mnohým odo­
sielateľom zapisovať do vzdialenej pamäte, zatiaľ čo príjemcovia môžu
čítať súbežne. Odosielateľ zapíše a indexuje vytvorené riadky v súvis­
l o m pamäťovom bloku. Tento index umožňuje príjemcom efektívny
prístup k príslušným riadkom, ktoré následne čítajú. BigQuery shuffle

20
 4- G O O G L E B I G Q U E R Y

sa nespráva ako bariéra, teda príjemca nemusí čakať, kým odosielateľ

zapíše všetky riadky, ale hneď po p r v o m zápise ich môže čítať, čo
umožňuje ďalšiu paralelnosť. V niektorých prípadoch objem dát, ktorý
sa má prerozdeliť medzi príjemcov, je príliš veľký na to, aby sa vykonal
vo volatilnej pamäti. V týchto prípadoch sú medzi-výsledky zapísané
do Colossus, odkiaľ si ich príjemcovia prečítajú [18].

4.1.2 Colossus

Colossus je najnovšia generácia distribuovaného súborového systému

od Google. Okrem produktu BigQuery využívajú tento systém aj ďal­
šie produkty od Google, napríklad Google C l o u d Storage (GCS). Aj
vďaka tomu existuje v BigQuery federatívne dopytovanie, ktoré umož­
ňuje analyzovať dáta uložené inde. Colossus sa stará o kompresiu,
šifrovanie, rozloženie dát na diskoch a ich replikáciu v rámci dátového
centra, ale tiež m e d z i viacerými dátovými centrami, aby nevznikol
jeden bod zlyhania. Okrem toho aby nedošlo k strate dát používa tiež
Reed Solomon kódy. Všetky operácie v rámci Colossus sú v súlade
s A C I D vlastnosťami. Colossus umožňuje používateľom BigQuery
škálovať úložný priestor na desiatky petabajtov údajov a p r i tom byť
dostatočne rýchly, aby umožnil BigQuery poskytovať podobný výkon
ako iné databázy [15].

4.1.3 Jupiter

Sieť Jupiter spoločnosti Google spája všetky stroje v rámci jedného

dátového centra. Vďaka topologii prepínačov, vlastnému hardvéru
a softvéru dokáže poskytnúť šírku pásma bisekcie až jeden petabit.
Inými slovami poskytuje dostatočnú šírku pásma, aby umožnila stoti­
síc strojom komunikovať s akýmkolVek iným strojom rýchlosťou 10 Gb
za sekundu. Pri takejto rýchlej sieti BigQuery môže pracovať normálne
bez toho, aby výpočetně zdroje a úložisko museli byť na rovnakom
mieste v rámci dátového centra. Rýchla sieť sa vrámci BigQuery vy­
užíva v dvoch prípadoch, keď sú dáta čítané z disku a p r i BigQuery
shuffle. V oboch prípadoch by pomalá sieť spôsobila spomalenie ce­
lého systému [19].

21
 4- G O O G L E B I G Q U E R Y

4.1.4 Borg

V dátovom centre sa nachádzajú stovky tisíc C P U , ktoré sú spravované

systémom Borg o d Google. Borg je správca klastrov. BigQuery má
v rámci dátového centra vyhradenú kapacitu, ktorá je systémom Borg
prideľovaná úlohám. Úlohou je v tomto prípade klášter Dremel.
Pri prevádzke veľkého dátového centra dochádza často k rôznym
problémom ako zlyhanie strojov, výpadok napájacích zdrojov, vý­
padok sieťových prepínačov a iné. Borg je postavený tak, aby tieto
problémy dokázal vyriešiť [15].

4.2 Dopytovanie

V BigqQuery sa dopytujú dáta pomocou štandardného SQL. Keď je

spustený dopyt, BigQuery automaticky vytvorí, naplánuje a spustí
úlohu dopytu. BigQuery spúšťa úlohy dopytov v dvoch režimoch [20]:

• interaktívny. Tento režim je predvolený. Úlohy sú spustené čo

najskôr. Avšak existuje limit na počet súbežne spustených úloh,
ktorý je 100.

• dávkový. Úloha je zaradená do fronty a je spustená, až keď sú

k dispozícii nečinné zdroje. A k sa nespustí do 24 hodín, režim
úlohy je zmenený na interaktívny.

Každá tabuľka v nástroji BigQuery je definovaná schémou, ktorá

popisuje názvy stĺpcov, typy údajov a ďalšie metadáta. V BigQuery
môžu byť dopytované nasledujúce typy tabuliek [20]:

• interné tabuľky - dáta sú uložené v BigQuery úložisku.

• externé tabuľky - dáta sú uložené v i n o m type úložiska, ktorý

podporuje dopytovanie z BigQuery.

• štandardný pohľad - virtuálna tabuľka definovaná S Q L príka­

zom, ktorá je vytvorená pred každým dopytom.

• materializovaný pohľad - pohľad je vytvorený a uložený v úlo­

žisku BigQuery pričom je periodicky aktualizovaný.

Nástroj BigQuery môže byť ovládaný viacerými spôsobmi:

22
 4- G O O G L E B I G Q U E R Y

• pomocou C l o u d Console, čo je webová konzola v rámci GCP.

• pomocou nástroja príkazového riadku b q.

• volaním rozhrania BigQuery REST A P I .

• používaním klientských knižníc, ktoré sú prístupné v jazykoch

Java, C#, Go, Node.js, PHP, Python a Ruby.

4.3 Uloženie dát

Uložené dáta v BigQuery sú pre používateľa zobrazené len z pohľadu

ich najvyššej vrstvy. Teda používateľ vidí dáta len ako množiny údajov
či tabuľky. Z a správu všetkých ostatných vrstiev nesie plnú zodpo­
vednosť BigQuery. Vďaka tomu môže uskutočňovať rôzne vylepšenia
a tým zlepšiť používateľom zážitok z používania. Niektoré z vylep­
šení sú: menenie kompresných pomerov, ukladanie do vyrovnávacej
pamäte, replikovanie, menenie kódovania alebo formátu údajov...

4.3.1 Organizácia dát

Dáta sú uložené v tabuľkách, ktoré BigQuery umožňuje používateľom

logicky usporiadať do takzvaných datasetov. P r i vytváraní datasetu
sa nastavuje lokácia, teda dátové centrum, kde budú dáta uložené
a dopytované. Lokácia datasetu sa po jeho vytvorení nedá zmeniť.
Avšak je možné urobiť kópiu datasetu na inej lokácii alebo vytvoriť
nový dataset na inej lokácii a dáta sem presunúť.

4.3.2 Nahrávanie dát

Štruktúrované dáta sa nahrávajú do tabuľky. Tabuľka je vytvorená buď

počas nahrávania alebo pred. Vytvorená tabuľka musí mať zadefino­
vanú schému dát, teda názov a typ stĺpcov. Vloženie dát do úložiska
BigQuery môže prebiehať dvoma spôsobmi.

Nahrávanie po dávkach

Prvým z nich je dávkové nahrávanie. Tento spôsob nahrávania je za­

darmo, ak je použitá metóda Load job. Preto je dobré použiť tento

23
 4- G O O G L E B I G Q U E R Y

spôsob vždy, keď je to možné. Napríklad ak sú zhromaždené všetky

dáta, ktoré majú byť analyzované alebo ak sú dáta pridávané každé
dve hodiny a neprekáža, že nebudú analyzované v reálnom čase. Dáv­
kové nahrávanie je limitované na 100 000 krát za deň. A k sa tento
limit často dosahuje, je lepšie zvoliť nahrávanie prúdom. Dáta môžu
byť nahráte z G C S alebo z lokálneho súboru. Nahrávanie z G C S je
rýchlejšie vďaka lepšiemu sieťovému prepojeniu, avšak niekedy môže
dochádzať k zbytočnej duplikácii dát. Taktiež je potrebné si dať pozor
na umiestnenie, pretože C l o u d Storage bucket musí byť umiestnený
v rovnakom regióne ako BigQuery dataset. N a druhej strane nahráva­
nie z lokálneho súboru je obmedzené na veľkosť 10 M B [21]. Existuje
aj alternatívna možnosť na nahrávanie dát z lokálneho súboru, a to
pomocou BigQuery Storage Write A P I v pending móde. Avšak tento
spôsob je spoplatnený [22].
Nahrávanie metódou Load job podporuje viaceré formáty: CSV,
JSON, Avro, Parquet a ORC. Nahrávané dáta môžu byť komprimované
alebo nekomprimované. Použiť komprimované dáta bude rýchlejšie
p r i posielaní dát cez sieť s nižšou prenosovou rýchlosťou a bude za­
berať menej miesta na lokálnom úložisku, ale pre BigQuery to bude
znamenať krok navyše a to dekomprimovanie dát. Dekomprimovanie
dát z formátov A v r o , Parquet, O R C je možné robiť paralelne, pre­
tože súbory nie sú komprimované ako celok, ale po blokoch. Formáty
J S O N a C S V nepodporujú komprimovanie po blokoch a teda ich de-
komprimácia sa nedá vykonávať paralelne. N a obrázku 4.2 môžme
vidieť porovnanie výkonu nahrávania dát pre podporované formáty,
komprimované a nekomprimované [23].

Faster

Avro (Compressed)

A v r o (Uncompressed)

Parquet/ORC
O
•
CSV/
UKÍ:

JSON BigQuery
CSV ( C o m p r e s s e d )

JSON ( C o m p r e s s e d )

Slower

Obr. 4.2: Výkon nahrávania dát pre podporované formáty. Zdroj: [23].

24
 4- G O O G L E B I G Q U E R Y

Nahrávanie prúdom dát (streaming)

Nahrávanie prúdom dát pokrýva prípady, kedy používateľ potrebuje

analyzovať postupne prichádzajúce dáta takmer v reálnom čase. Dáta
po príchode do BigQuery nie sú ihneď uložené do úložiska ale pretrvá­
vajú vo vyrovnávacej pamäti, odkiaľ môžu byť dopytované [23]. Tento
spôsob nahrávania je spoplatnený a vykonáva sa pomocou BigQuery
Storage Write A P I v committed móde. Ponúka však prvé 2 TB dát za
mesiac zadarmo. N a komunikáciu používa gRPC framework, ktorý
umožňuje posielať dáta aj v binárnom formáte. Požiadavky na zápis sú
asynchrónne s tým, že ich poradie je garantované. Rozhranie BigQuery
Storage Write A P I je možné použiť priamym volaním rozhrania gRPC
alebo pomocou knižníc dostupných pre jazyky Java, Python a Go [22].

4.3.3 Export dát

Dáta uložené v BigQuery úložisku alebo výsledky dopytov môžu byť

exportované do iného typu úložiska troma spôsobmi.

Export job

Tento spôsob exportu dát je jediný, ktorý je zadarmo až do 50 TB za

deň. Umožňuje exportovať dáta aj do lokálneho úložiska vo formáte
C S V a J S O N . Avšak veľkosť dát musí byť menšia ako 10 M B a je to
možné spraviť len z Cloud Console. Najviac podporovaný je export do
GCS, kedy dáta môžu byť vo formáte CSV, JSON, Appache Avro a A p -
pache Parquet v komprimovanej a nekomprimovanej podobe. Lokácia
G C S bucket musí byť v rovnakom regióne ako BigQuery. Veľkosť dát
exportovaných do jedného súboru musí byť menšia ako 1GB, avšak je
možné ich jedným príkazom exportovať do viacerých súborov. Export
do G C S je prístupný z C l o u d Console, nástroja príkazového riadku
bq a tiež rozhrania A P I [24].

Export S Q L príkaz

Export dát je možný len do G C S . Použitie Export S Q L príkazu je

spoplatnené takisto ako ostatné dopyty v BigQuery. Avšak pri exporte
výsledku dopytu je možné Export S Q L príkaz zreťaziť pred dopyt
a zaplatiť tak len raz.

25
 4- G O O G L E B I G Q U E R Y

BigQuery Storage Read A P I

Poslednou možnosťou je použiť BigQuery Storage Read API, ktoré po­

dobne ako BigQuery Storage Write API používa na komunikáciu gRPC
framework. Posielané dáta sú buď vo formáte Appache Avro alebo A p -
pache Arrow. Umožňuje používateľovi vybrať si, ktoré stĺpce z tabuľky
chce exportovať, prípadne nastaviť jednoduchý filter, ktorý přefiltruje
dáta predtým, ako budú exportované. Tento spôsob je spoplatnený,
ale export prvých 300 TB dát za mesiac je zadarmo, ako aj export
dočasných tabuliek, kde sú uložené výsledky dopytov [25].

4.3.4 Formát uloženia

Dáta po nahratí do BigQuery sú konvertované do proprietárneho

formátu Capacitor. Capacitor je stĺpcovo orientovaný formát, ktorý po­
dobne ako Appache Parquet podporuje polovičné štruktúrované dáta.
Aby bolo dosiahnuté čo najefektívnejšie kódovanie a komprimovanie
dát, Capacitor sa snaží predtým dáta optimálne zoradiť, pričom berie
do úvahy relevantné faktory ako typ údajov (napr. dlhý reťazec vs.
celé číslo) a ich budúce využitie. Kým sú stĺpce dát kódované, BigQu­
ery zhromažďuje rôzne štatistiky, ktoré uchováva v metadátach. Tieto
údaje sú neskôr použité na optimalizáciu p r i ukladaní do Colossus
a p r i zostavovaní dopytovacieho plánu v Dremel [26].

4.3.5 Optimalizácie pre zlepšenie výkonu dopytovania

Zmenou usporiadania dát v úložisku je možné dosiahnuť zlepšenie

výkonu dopytovania pre niektoré dopyty. BigQuery má vstavaný opti­
malizátor úložiska, ktorý pomáha usporiadať údaje do optimálneho
tvaru pre dopytovanie pravidelným prepisovaním súborov. O k r e m
toho umožňuje aj používateľovi spraviť pár vecí na vylepšenie úlo­
žiska.

Automatizované administratívne databázové úlohy

BigQuery spúšťa na pozadí procesy, ktoré kontrolujú, či je možné opti­

malizovat úložisko. Existuje viacero dôvodov, kedy je optimalizácia
spustená. M e d z i tieto dôvody radíme napríklad zmenu niektorého
z parametrov systému, vznik nových vylepšení vo formáte Capacitor

26
 4- G O O G L E B I G Q U E R Y

alebo ak boli pôvodne dáta nahrávané po malých kúskoch čo znamená,

že zo širšieho pohľadu nie sú optimálne uložené. Keď systém nájde
príležitosť na zlepšenie úložiska, automaticky spustí úlohu na kon­
vertovanie dát. Tieto úlohy môžu bežať paralelne s dopytmi, pričom
neznižujú výkon dopytov, ani i m nezaberajú zdroje. Akonáhle je nové
optimalizované úložisko dokončené, atomicky nahradí staré. BigQu­
ery vykonáva túto údržbu zadarmo a bez toho, aby o nej užívateľ
vedel [26].

Partitioning

Partitioning je proces, pri ktorom je vytvorená špeciálna tabuľka, ktorá

je rozdelená na segmenty. Takto rozdelená tabuľka na segmenty umož­
ňuje p r i dopytoch s filtrom na stĺpec, podľa ktorého je tabuľka rozde­
lená, znížiť množstvo skenovaných dát a tak razantne znížiť náklady
a čas na ich vyhodnotenie. Nové dáta, ktoré sú vložené do tabuľky
sú automaticky priradené do prislúchajúceho segmentu. BigQuery
podporuje nasledujúce rozdelenia pri partitioning [27]:

• rozdelenie podľa času nahratia dát. V tabuľke je vytvorený nový

stĺpec s časom nahratia konkrétneho záznamu. Používateľ si
môže zvoliť rozmedzie segmentov na hodinu, deň, mesiac a rok.
Táto možnosť je užitočná, ak sú údaje filtrované podľa toho, kedy
boli pridané.

• rozdelenie podľa stĺpca s časovým typom. Typ stĺpca môže byť

DATE, TIMESTAMP alebo DATETIME. Podobne ako v predchádzajú­
com prípade si používateľ môže zvoliť rozmedzie segmentov na
hodinu, deň, mesiac a rok. Táto možnosť je užitočná, ak sú údaje
filtrované na základe hodnoty času v tabuľke.

• rozdelenie do intervalov podľa číselnej hodnoty daného stĺpca.

Pri tvorbe je potrebné definovať stĺpec, začiatok, koniec a inter­
val. Táto možnosť je užitočná, ak sú údaje filtrované na základe
celočíselného stĺpca v tabuľke.

Partitioning je vhodné použiť hlavne pri veľkých tabuľkách, ktoré

sú počas analýzy často filtrované podľa rovnakého stĺpca, pretože cena
analýzy bude lacnejšia.

27
 4- G O O G L E B I G Q U E R Y

ipf ix_table-_partiti oned

ipfix_tat>le export D a t e srtlPv4 packets

export Date srclPv4 packets 2021-0B-Ů7 147.251.48.3

20210807
2021 -OB-OB 147251.48.1 20 2021-0B-07 147.251.48.2 27

2021 - 0 6 - 0 7 147.251.48.3 31
Partitioning padl'a\
exportDate
2021 -OB-OB 147251.402 15 2021-OB-OB 147.251.48.1
20210808
2021 oe-09 147.251.48.1 5 2021-06-03 147.251.48.2

2021 -OB-07 147.251.4Ô.2 27

20210809 2021-0B-09 147 251.48.1 5

Obr. 4.3: BigQuery partitioning.

Clustering

Clustering je proces, pri ktorom je vytvorená špeciálna tabuľka, ktorá

má záznamy zoradené podľa vybraných stĺpcov. Je možné vybrať až
štyri stĺpce. Zoradenie je robené postupne, najskôr podľa prvého vybra­
tého stĺpca, potom druhého a tak ďalej. Preto záleží v akom poradí sú
stĺpce vybraté. Po nahratí nových dát do tabuľky, BigQuery spustí na
pozadí zadarmo proces, ktorý opätovne zoradí všetky dáta v tabuľke.
Najednej tabuľke môže byť použitý partitioning aj clustering [27].
Clustering zlepšuje výkon dopytov, ktoré:

• obsahujú S Q L príkaz WHERE so stĺpcom použitým v clustering.

BigQuery naskenuje len hľadaný blok záznamov. Treba si ale
dať pozor na poradie filtrov. Najlepšie je zvoliť najskôr filter pre
partitioning a potom zoradiť filtre v rovnakom poradí ako boli
zvolené stĺpce v clustering. P r i použití filtra len n a d stĺpcom,
ktorý nebol v clustering zvolený ako prvý, musia byť skenované
všetky dáta.

• agregujú údaje nad stĺpcom použitím v clustering.

• obsahujú SQL príkaz join podľa stĺpca použitého v clustering.

28
 4- G O O G L E B I G Q U E R Y

ipfix_table ipfix_t ab le_ c lu s tered

2021 -0B-0& 147.251.4«. 1 20 147.251.48.1 2021-08-08 20

Clustering p o d ľ a \
2021-0B-07 147.251.48.3 31 147.251.48.1 2021-08-09 5
srclPv4

2021 -OB-OB 147.251 48.2 15 147.251.48.2 2021-08-08 15

2021-0B-09 147.251,48.1 S 147.251.48.2 2021-08-07 27

2021-0B-07 147.251,48.2 27 147.251.48.3 2021-08-07 31

Obr. 4.4: BigQuery clustering.

4.4 Integrácia v GCP

Produkty v G C P sú navrhnuté tak, že každý produkt je zodpovedný

za niečo iné. Teda máme tu viac úzko špecializovaných produktov,
ktoré medzi sebou navzájom interagujú. Preto treba spomenúť aspoň
niektoré produkty, ktoré rozširujú funkcionalitu pre Google BigQu­
ery [19].

• Cloud Monitoring a C l o u d Logging skúmaním logov poskytujú

zákazníkom prehľad o používaní BigQuery v rámci ich organi­
zácie.

• Cloud Dataproc poskytuje možnosť čítať, spracovávať a zapisovať

dáta do BigQuery tabuliek používajúc Apache Spark programy.
Preto BigQuery môže slúžiť ako pamäťová vrstva pre Hadoop
orientované dátové jazerá.

• Federatívne dopyty v BigQuery umožňujú analyzovať dáta ulo­

žené v G C S , C l o u d S Q L , Bigtable, Spanner alebo Google Drive.
Vďaka federatívnym dopytom môže BigQuery slúžiť ako vy­
hodnocovací stroj pre dátové jazero, ktorého pamäťová vrstva je
v GCS.

• Google Data Studio slúži na vizualizáciu dát z BigQuery. Umož­

ňuje vytvoriť nástenku s rôznymi typmi grafov.

29
 4- G O O G L E B I G Q U E R Y

• BigQuery M L umožňuje vytvárať a spúšťať modely strojového

učenia v nástroji BigQuery pomocou štandardných dopytov SQL.

• Cloud Scheduler a Cloud Functions umožňujú spúšťať BigQuery

dopyty plánovane alebo v rámci procesov.

4.5 Bezpečnosť

Bezpečnostný model BigQuery je úzko integrovaný so zvyškom GCP.

V rámci tohto modelu je definované, že každý používateľ alebo zaria­
denie, ktoré chce získať prístup k zdroju:

• sa musí overiť pomocou svojich prihlasovacích údajov.

• musí mať oprávnenie na prístup k uvedenému zdroju.

• musí komunikovať šifrované.

N a autentifikáciu a autorizáciu BigQuery používa systém riadenia

prístupu I A M o d Google. V I A M sú povolenia zoskupené do rolí,
ktoré môžu byť následne pridelené jednotlivým používateľom alebo
skupinám používateľov na určitej úrovni zdrojov. Napríklad na úrovni
projektu môže mať používateľ rolu správcu.
Vďaka I A M je tiež možné zdielať tabuľky alebo pohľady medzi
používateľmi bez toho, aby museli byť kopírované. Stačí používateľovi
prideliť rolu s potrebnými oprávneniami.
V rámci Virtual Priváte C l o u d ( V P C ) je možné nastaviť pravidlá
brány firewall na ochranu pred používateľmi, ktorí sa pokúšajú získať
prístup k údajom z v o n k u alebo sa pokúšajú exportovať dáta tretím
stranám.
O šifrovanie dát sa stará BigQuery na pozadí. Predtým ako sú dáta
zapísané na disk, sú šifrované. N a šifrovanie používa Google vlastné
kľúče, avšak používateľ ich môže nahradiť vlastnými. Taktiež keď dáta
opúšťajú C l o u d , sú počas komunikácie šifrované [28].

4.6 Poplatky

Poplatky v BigQuery môžme rozdeliť na dve časti:

30
 4- G O O G L E B I G Q U E R Y

• poplatky za analýzu. Čo predstavuje náklady na S Q L dopyty,

užívateľom definované funkcie, skripty a určité príkazy jazyka
D M L (Data manipulation Language) a jazyka definície údajov
( D D L ) , ktoré skenujú tabuľky.

• poplatky za úložisko. Čo predstavuje náklady na uloženie na-

hratých dát do BigQuery.

Vyúčtovanie za použitie BigQuery je viazané na projekt, ktoré je možné

zobraziť na stránke C l o u d Billing v C l o u d Console.
V rámci poplatkov za analýzu ponúka BigQuery dva cenové mo­
dely:

• v p r v o m modeli, používateľ platí za veľkosť skenovaných dát

každým dopytom. Veľkosť dát sa vypočíta podľa dátových typov
pre jednotlivé stĺpce, pričom n u l l hodnoty sú za 0 B. Používateľ
má k dispozícii 2000 slotov, ktoré sú zdieľané m e d z i všetkými
dopytmi vrámci projektu. Niekedy sa môže stať, že ich počet
je nižší, ak je po nich v rámci dátového centra veľký dopyt. Z a
každý dopyt je účtované minimálne 10 M B , s výnimkou, že dopyt
skončí s chybou alebo výsledok je získaný z cache.

• v druhom modeli si používateľ vie rezervovať určitý počet slotov,

ktoré m u budú nepretržite prístupné, odkedy ich rezervuje, až
pokiaľ ich nezmaže. Z a rezerváciu sa platí paušálne, pričom na
výber sú tri viazanosti: na sekundu, na mesiac a na rok.

Čo sa týka poplatkov za úložisko, tak cena je založená na množstve

dát uložených v tabuľkách, keď sú nekomprimované. Veľkosť dát sa
vypočíta podľa dátových typov pre jednotlivé stĺpce, pričom n u l l
hodnoty sú za 0 B. Dáta nahráte do BigQuery sú najskôr účtované
ako aktívne úložisko. A k sa však tabuľka alebo segment tabuľky po
partitioning nemodifikuje po dobu 90 dní, tak začne byť účtovaný ako
dlhodobé úložisko.
V tabuľke 4.1 sú zobrazené poplatky za analýzu, úložisko, BigQu­
ery Storage Write API, BigQuery Storage Read A P I a za GCS pre region
europe-westl platné k Aprílu 2022 [29].

31
 4- G O O G L E B I G Q U E R Y

Tabulka 4.1: Poplatky.

Operácia Cena Poznámka

Dopyt 6$zaTB Prvý TB za mesiac je zadarmo
Sekundová 4.8 $ za 100 rezervovaných slotov
rezervácia hodinu
Mesačná 2400$ za 100 rezervovaných slotov
rezervácia mesiac
Ročná 2040$ za 100 rezervovaných slotov
rezervácia mesiac
Aktívne 0.02$ za G B Prvých 10 G B je každý mesiac
úložisko za mesiac zadarmo.
Dlhodobé 0.01 $ za G B Prvých 10 G B je každý mesiac
úložisko za mesiac zadarmo.
BigQuery 0.025$ za G B Prvé 2 TB za mesiac sú zadarmo.
Storage Write
API
BigQuery 1.1 $ za TB Prvých 300 TB za mesiac je
Storage Read zadarmo.
API
G C S Standard 0.02$ za G B
za mesiac
Čítanie z G C S zadarmo
Standard
G C S Nearline 0.01 $ za G B Dáta musia byť uložené aspoň
za mesiac 30 dní.
Čítanie z G C S 0.01 $ za G B
Nearline
G C S Coldline 0.004$ za G B Dáta musia byť uložené aspoň
za mesiac 90 dní.
Čítanie z G C S 0.02$ za G B
Coldline
G C S Archíve 0.0012$ za Dáta musia byť uložené aspoň
G B za mesiac 365 dní.
Čítanie z G C S 0.05$ za G B
Archíve

32
5 Proces generovania a uloženia dát

V tejto kapitole opíšeme, ako sme vygenerovali a uložili dáta neskôr

použité v našich experimentoch. Celý proces je znázornený na ob­
rázku 5.1. Tiež poskytneme štatistiky o uložených súboroch.
^•dataset-GCS-1

/ ^•exportDaie=2021-03-07 exportDaie=2Ü21 -OB-Üä ^•eKporiDate=202l-08-09

lasüacdä 1 _mi nule .parquet

dasdacds 1 minute, par Quel
/ gegfhsfajl _minute_parque.t
jwzsagvr_1_minu1e. parquet
. . •. J.... •. 1 minule.parquet
megihsfa_1_minute_parquet
c.Lg.71- y . n j ^ l nwzsagvr 1 minute.parquel

Vygeneruj 1 minútu záznamov

Konvenuj do formátu Apache Parquet dataset GCS 5
Ulož do priečinku dataset-GCS-1 v GCS

M
^•expor:Dale=2G2l-03-07 exportDate=2Q21 - W. - Q 6 expo rtDate=2021-08-09

ú dasdacds 6 minute.parquet aasdaeds_5_minuie_parquet lasdaeds 5_minute parquet

Ü getf-sra 5 minule.parquet bsgfhsfa 5 minule.parquet megthsfa 5 minule.parquet
jwzsacrvr & minute.parquet cwzsagvr 5 minute, parquet nwzsagvr 5 minute.parquel
Google

Konvertuj do formátu Apache Parquet

Ulož do priečinku dataset-GCS-5 v GCS

^•exportDate=3Q21-03-07 e«poHDate=2021 -OS-OS expo rtDate=2021-08-09

Konvertuj do formátu Apache Parquet
Ulož do priečinku datase1-GCS-6ü v GC3 *
d a sdacds_6fl _m i nuieparquet
gecf sla 60 ni"'jte.p-a-qyet
,n
jivzsagvr •-•u TI nut&.pa-aus:
aasdacds 60 minute,parquet lasdacds 60 minule.parquet
begfhsfa 60 minute.parquel iied"sf£ S<.' ni-'ute.pa-quet
cwzsagvr 60 minute.parquel nwzsagvr 60 minule.parquet

Obr. 5.1: Proces generovania a uloženia dát.

Rozhodli sme sa, že v našich experimentoch použijeme nami vy-

generované záznamy sieťových tokov. A b y vygenerované záznamy
sieťových tokov pôsobili čo najreálnejšie, bol nám poskytnutý súbor
s IPFIX záznamami z reálnej siete. V tomto súbore sa nachádza šesť
rôznych typov záznamov sieťových tokov. Hlbšou analýzou súboru
sme získali konkrétne hodnoty alebo rozpätia hodnôt pre atribúty jed­
notlivých typov záznamov, ktoré sme následne použili p r i generovaní.
Vygenerované dáta obsahujú približne 10000 záznamov sieťových
tokov za sekundu, čo by malo odpovedať počtu záznamov sieťových
tokov v univerzitnej sieťovej prevádzke. Typ nasledujúceho sieťového
toku b o l vždy vybraný náhodne zo 6 dostupných typov s rovnakou
pravdepodobnosťou.
Vygenerované dáta boli uložené vo formáte Apache Parquet na
úložisko G C S . Rozhodli sme sa použiť formát Apache Parquet, pre­
tože tento formát je vhodný na analýzu veľkého objemu dát. Apache
Parquet poskytuje viacero nastavení. V nasledujúcich experimentoch
nás bude zaujímať vplyv veľkosti row-group na výkon dopytovania,
preto sme sa rozhodli, že počas generovania dát ich budeme postupne
ukladať po dávkach, pričom použijeme tri rôzne veľkosti jednotlivých

33
 5- PROCES GENEROVANIA A ULOŽENIA DÁT

Tabulka 5.1: Datasety.

Názov Velkost' Velkost Uložisko

dávky row-group
v minútach v MB
dataset-GCS-1 1 25 GCS
dataset-GCS-5 5 125 GCS
dataset-GCS-60 60 1501 GCS
dataset-GCS-60-B 60 125 GCS
dataset-BigQuery BigQuery

dávok. P r i uložení dávky vznikol vždy nový parquet súbor s jednou

row-group. Po dokončení nám vznikli tri dátové súbory s rovnakými
dátami, ale ich parquet súbory obsahujú row-gruop rozdielnej veľ­
kosti viď tabuľka 5.1. Pri ukladaní dávok do formátu Apache Parquet
sme tiež nastavili veľkosť page na 1 M B , na stĺpcoch s malým počtom
rozdielnych hodnôt sme použili slovníkové kódovanie, celé sme to
komprimovali algoritmom G Z I P a použili sme partitioning podľa
dní n a d stĺpcom i p f i x : exportľime. N a obrázku 5.1 môžme vidieť
štruktúru priečinkov, ktorá vznikla v G C S .
Po spustení prvých dopytov nad dátovými súbormi sme zistili, že
pre dataset-GCS-60 je výkon nástroja príliš nízky. Preto sme vytvorili
nový dátový súbor dataset-GCS-60-B, kde sme nastavili obmedzenie,
že row-group môže obsahovať najviac 3 milióny záznamov. Teda p r i
uložení dávky, ktorá obsahuje záznamy sieťových tokov za 60 minút,
vznikol jeden parquet súbor s 13 row-group.
Po vygenerovaní a uložení všetkých dát v G C S vo formáte A p a ­
che Parquet, sme vytvorili dátový súbor aj v BigQuery úložisku, kde
sme nahrali dáta z jedného dátového súboru v GCS. Nahratie v troch
meraniach trvalo v priemere 170 sekúnd. Pre tento dátový súbor sme
nastavili partitionig podľa dní n a d stĺpcom i p f i x : exportľime tak,
aby sa zhodoval s ostatnými dátovými súbormi.
Každý vytvorený dátový súbor obsahuje vygenerované záznamy
sieťových tokov za tri dni, o d 0:00 7.8.2021 do 24:00 9.8.2021. To pred­
stavuje okolo 2592 miliónov záznamov sieťových tokov. Každý dátový
súbor v úložisku G C S zaberá 108 GB. N a druhej strane dátový súbor
v úložisku BigQuery zaberá 480 G B .

34
6 Metodológia

V tejto kapitole predstavíme metodiku použitú na porovnanie výkonu

nástroja BigQuery. Všetky dopyty boli spustené v BigQuery cez klient­
skú knižnicu v jazyku Python. Pre každý dopyt musela byť vytvorená
úloha dopytu, ktorá po dokončení obsahovala okrem iného aj čas spus­
tenia a ukončenia. Dobu medzi týmito dvoma hodnotami, ktorú tiež
môžme nazvať čas odozvy dopytu, použijeme na porovnávanie vý­
konu. V prvej sekcii popíšeme dátové súbory použité v našej dátovej
analýze, zatiaľ čo v druhej sekcii definujeme niekoľko prípadových
štúdií použitých v našom porovnaní.

6.1 Dátové súbory

V rámci našich experimentov budeme porovnávať výkon dopytovania

nástroja BigQuery nad dátami uloženými v G C S vo formáte Apache
Parquet a v úložisku BigQuery vo formáte Capacitor. Zatiaľ čo vo for­
máte Capacitor je možné nastaviť len partitioning a clustering, pretože
o ostatné sa stará nástroj BigQuery sám, vo formáte Apache Parquet
sa nám poskytuje viacero nastavení. Konkrétne nás najviac zaujíma
vplyv veľkosti row-group na výkon dopytovania, pretože záznamy
sieťových tokov sú získavané postupne a my chceme minimalizovať
čas medzi ich získaním a dopytovaním. To nás viedlo k vytvoreniu
piatich typov dátových súborov spomenutých v tabuľke 5.1.

6.2 Prípadové štúdie

N a d vyššie uvedenými dátovými súbormi boli spúšťané rôzne typy

operácií, ktoré označujeme tiež prípadové štúdie. Použili sme rovnaké
prípadové štúdie ako v práci [10] a to:

1. Agregácia: V prvej prípadovej štúdii sú získané informácie ako

celkový počet záznamov, súčet poslaných paketov a bajtov. A g ­
regácia je spustená na všetkých záznamoch, ale použitá je len
podmnožina stĺpcov.

35
 6. M E T O D O L Ó G I A

2. Filtrovanie + agregácia: V druhej prípadovej štúdii vyhľadáme

počet záznamov s cieľovým portom 53.

3. Filtrovanie + výpis: Tretia prípadová štúdia je zameraná na filtro­

vanie a výpis väčšieho množstva informácií. Vypísané sú všetky
informácie zo sieťových záznamov, ktoré použili internetový
protokol verzie 6 a ich cieľový port je 53.

4. Zoskupovanie + agregácia + zoradenie 1: V štvrtej prípadovej štúdii

vyhľadáme päť zdrojových adries IPv4 verzie, z ktorých bolo
odoslaných najviac dát. Používame filtrovanie, zoraďovanie a ag-
regáciu podľa jedného stĺpca.

5. Zoskupovanie + agregácia + zoradenie 2: Posledná prípadová štú­

dia obsahuje rovnaké funkcie ako predchádzajúca, ale agregácia
je podľa viacerých stĺpcov. Záznamy sú zoskupené podľa štan­
dardnej pätice a následne sú zoradené podľa veľkosti odoslaných
dát.

A b y sme zistili, ako sa BigQuery správa v závislosti na veľkosti

dopytovanej množiny údajov, pre každý dátový súbor sme testovali
jeho výkon na báze časového prírastku. Teda prvý test sa vykoná
na množine údajov z dátového súboru o d začiatku po prvý časový
prírastok, druhý na množine údajov z dátového súboru od začiatku
po druhý časový prírastok atď. Množina údajov sa tak s každým
vykonaním dopytu zväčšuje, až kým sa nepoužije celý dátový súbor.
Toto aplikujeme pre každú prípadovú štúdiu.
Tabuľka 6.1 ukazuje syntax dopytov reprezentujúcich prípadové
štúdie.
V rámci našich experimentov sme najskôr spustili testy s časovým
prírastkom jeden deň. Pre správny výber množiny údajov sme do kaž­
dého S Q L dopytu pridali príkaz WHERE date <= <dátum dňa>. Táto
klauzula bola vždy umiestnená v rámci príkazu WHERE ako prvá, aby
nástroj BigQuery mohol využiť partitioning použitý v dátových súbo­
roch. Vzhľadom k tomu, že časovým prírastkom jeden deň sa nám po
zobrazení zdal príliš veľký, spustili sme nové testy s časovým príras­
tkom jedna hodina. D o S Q L dopytov, ktorých časový prírastok nebol
celý deň, sme okrem klauzuly date <= <dátum dňa> pridali aj klau­
zulu AND exportľime <= <timestamp dňa s-konkrétnou hodinou>.

36
 6. M E T O D O L Ó G I A

Tabulka 6.1: Dopyty.

Prípad štúdie C. SQL dopyt

Agregácia Ql S E L E C T count(*), sum(packets),
sum (bytes) F R O M <table_id>
Filtrovanie + Q2 SELECT count(*) F R O M <table_id>
agregácia W H E R E dst_port = 53
Filtrovanie + Q3 S E L E C T date, protocol, src_IPv6, dst_IPv6,
výpis src_port, dst_port, packets, bytes F R O M
<table_id> W H E R E dst_port = 53 A N D
ip_version = 6
Zoskupovanie Q4 S E L E C T src_IPv4, S U M (packets) A S
+ agregácia + packets, SUM(octetDeltaCount) A S bytes,
zoradenie 1 count(*) F R O M <table_id> W H E R E
ip_version = 4 G R O U P BY src_IPv4
O R D E R BY bytes DESC LIMIT 5
Zoskupovanie Q5 S E L E C T protocol, src_IPv4, dst_IPv4,
+ agregácia + src_IPv6, dst_IPv6, src_port, dst_port,
zoradenie 2 SUM(packets), SUM(bytes) A S bytes,
count(*) F R O M <table_id> G R O U P BY
protocol, src_IPv4, dst_IPv4, src_IPv6,
dst_IPv6, src_port, dst_port O R D E R BY
bytes DESC LIMIT 5

Avšak tento prístup nezobrazuje výsledok dopytu spusteného len nad

dátami z konkrétneho časového intervalu, pretože napríklad ak spus­
tíme dopyt nad prvými dvoma hodinami, najskôr sa načítajú dáta pre
celý prvý deň a následne sa filtrujú záznamy za prvé dve hodiny. A b y
sme dosiahli spustenie dopytov s časovým prírastkom jedna hodina
len nad dátami z konkrétneho časového intervalu, bola by potrebná
zmena partitioningu v datasetoch z dní na hodiny. Pre formát Capa­
citor by to znamenalo spustiť jeden D D L príkaz, pre formát Apache
Parquet by bolo potrebné načítať dáta do pamäte a uložiť so zmenou
v partitioningu, prípadne vygenerovať nové dátové súbory. Vzhľadom
k tomu, že na tento postup nezostali financie, tak nebol vyskúšaný.

37
7 Výsledky

V tejto kapitole predstavíme výsledky našich meraní, ktoré zobrazujú

čas odozvy pre každú prípadovú štúdiu nad každým dátovým súbo­
rom. Testy s časovým prírastkom jeden deň sú zobrazené v stĺpcovom
grafe, kde pre každý deň existuje stĺpec, ktorý zobrazuje výsledok pre
daný dátový súbor. Tieto testy boli spustené päť krát. Testy s časovým
prírastkom jedna hodina sú vykreslené ako normálny graf, ktorý opi­
suje vzťah m e d z i veľkosťou množiny údajov (na horizontálnej osi)
a časom odozvy na dopyt v sekundách (na vertikálnej osi). Tieto testy
boli spustené tri krát. Výsledky v grafoch zobrazujú priemerný čas
všetkých spustení s príslušnou štandardnou chybou.

Tabulka 7.1: Počet pridelených zdrojov pre prvý stage dopytovacieho

plánu všetkých dopytov.

Dátové súbory 2021-08-07 2021-08-08 2021-08-07

dataset-GCS-1 1440 2880 4320
dataset-GCS-5 288 576 864
dataset-GCS-60 144 288 432
dataset-GCS-60-B 144 288 432
dataset-BigQuery 1000 2000 3000

Tabuľka 7.1 zobrazuje počet pridelených zdrojov v p r v o m stage

dopytovacieho plánu, ktorý je zodpovedný za načítanie dát z úlo-
žiska, pre jednotlivé dátové súbory v riadkoch a pre veľkosť vstupnej
množiny dát v stĺpcoch. Môžme vidieť, že so zvyšujúcou sa vstupnou
množinou dát rastie aj množstvo pridelených zdrojov. N a grafoch sa
to prejavuje tak, že merania nad rôznou veľkosťou dát sú približne
rovnaké.
BigQuery pre dátové súbory uložené vo formáte Apache Parquet
neprideľuje počet zdrojov podľa počtu row-group, pretože počet zdro­
jov pre dataset-GCS-5 a dataset-GCS-60-B, ktoré majú rovnaký počet
row-group, sa nezhoduje. Tieto dátové súbory sa líšia v počte parquet
súborov, čo odpovedá aj počtu pridelených zdrojov. Teda BigQuery
pre dátové súbory uložené vo formáte Apache Parquet prideľuje počet
zdrojov podľa počtu parquet súborov. Čím viac zdrojov tým rýchlejší je

38
 7- VÝSLEDKY

výpočet, avšak tým viac času sa strávi čakaním, keďže zdroje nemusia
byť ihneď k dispozícii.

Tabulka 7.2: Približný počet stage v rámci každého dopytu.

Dátové súbory Dopyt č.

1 2 3 4 5
dataset-GCS-1 2 2 3 7 7
dataset-GCS-5 2 2 3 8 11
dataset-GCS-60 2 2 3 11
dataset-GCS-60-B 2 2 3 11 11
dataset-BigQuery 2 2 3 7 7

V tabuľke 7.2 je zobrazený počet stage v dopytovacom pláne pre

každý dopyt. Toto vymenovanie je približné, pretože v rámci rôznych
meraní sa hodnoty mohli jemne líšiť. Pre hodnoty v stĺpcoch platí, že ak
je vyššia, tak pre daný dátový súbor bol vykonaný repartition navyše.
A k však zoberieme do úvahy, že dopytovací plán pre dataset-BigQuery
by m a l byť čo najlepší, pretože je uložený v jeho natívnom úložisku,
potom sa nám podarilo nájsť alternatívny typ uloženia s rovnakým
dopytovacím plánom pre naše prípadové štúdie.
Vo všetkých prípadových štúdiách dosahuje BigQuery najlepšie vý­
sledky pre dataset-BigQuery. Najhoršie výsledky, ktoré sa od ostatných
dramaticky líšia dosahuje pre dataset-GCS-60.

2D21-08-07 2021-08-08 2021-08-09

N e t w o r k d a t a [days]

Obr. 7.1: Agregácia po dňoch.

39
 7- VÝSLEDKY

— 1 — dataset-Big Query
— 1 — dataset-GCS-1
—\— dataset-GCS-5
—I— dataset-GCS-60-B

• I
/VvV A.
i, ..a i -
^\

N e t w o r k d a t a [hours]

Obr. 7.2: Agregácia po hodinách.

Z grafov pre prípadovú štúdiu agregácia vyplýva, že filtrovanie je

vykonané rýchlejšie, ak je vykonané na viacerých zdrojoch, pretože
v grafe 7.2 je vyhodnotenie pre dataset-GCS-1 rýchlejšie ako pre dataset-
GCS-5 iba v časoch, kedy je navyše použitá filtrácia, teda nie pre celé
dni.
Graf 7.2 poukazuje na rázny skok pre dataset-GCS-60-B v 43. hodine.
Spôsobilo to jedno meranie, ktoré trvalo 43 sekúnd, čo sa výrazne
líšilo od ostatných, ktoré trvali okolo 7 sekúnd. Problémom bolo, že
na výsledný zápis sa dlho čakalo a tiež dlho trval. Pravdepodobne bol
uskutočnený na chybnom stroji. Z grafu 7.4 vyplýva, že merania pre

2D21-08-07 2 021-08-08 2021-0B-09

N e t w o r k d a t a [days]

Obr. 7.3: Filtrovanie + agregácia po dňoch.

40
 7- VÝSLEDKY

celé d n i sú nižšie. Je to spôsobené tým, že dopyt spustený na celom

dni neobsahuje filtrovanie po hodinách.

N e t w o r k d a t a [hours]

Obr. 7.4: Filtrovanie + agregácia po hodinách.

BigQuery najdlhšie trvalo vyhodnotiť dopyty pre prípadovú štúdiu

filtrovanie + výpis, z čoho môžme usúdiť, že zápis veľkého množstva
výsledkov do úložiska je pre BigQuery náročnou úlohou na čas.

dataset-Big Query
dataset-GCS-1
dataset-GCS-5
dataset-GCS-60-B
dataset-GCS-60

2021-08-07 2 021-08-08 2021-0B-G9

N e t w o r k d a t a [days]

Obr. 7.5: Filtrovanie + výpis po dňoch.

V grafe 7.5 môžme vidieť, že štandardná chyba pre dataset-GCS-

1 n a d množinou údajov pre dva d n i je velká. Je to spôsobené tým,
že dve merania vyšli 4-krát horšie ako ostatné, pretože BigQuery sa
pred posledným stage rozhodol nespraviť Repartition a tak posledný
výpočet trval približne 87 sekúnd namiesto 6 sekúnd.

41
 7- VÝSLEDKY

Graf 7.6 poukazuje na to, že merania po 27. hodinu majú rastúcu

tendenciu. To je spôsobené tým, že v treťom dopyte je potrebné vypísať
veľké množstvo dát a vypisovanie prebiehalo len z jedného zdroja. Pri­
bližne medzi 28. až 47. hodinou sú dáta stále vypisované len z jedného
zdroja, avšak veľkosť vypisovaných dát pravdepodobne presiahla ne­
jakú kritickú hranicu, keďže vypisovanie trvá omnoho dlhšie. O d 48.
hodiny BigQuery vykonáva Repartition a vypisovanie hodnôt pre­
bieha z desiatich zdrojov.

Obr. 7.7: Zoskupovanie + agregácia + zoradenie 1 po dňoch.

Z výsledkov pre prípadové štúdie Zoskupovanie + agregácia + zo­

radenie vyplýva, že počet pridelených zdrojov pre tieto typy dopytov

42
 7- VÝSLEDKY

je dôležitý, pretože s narastajúcim počtom zdrojov je čas odozvy do­

pytu nižší. Tiež si môžme všimnúť, že počet stĺpcov, nad ktorými je
vykonané zoskupenie, má vplyv na dĺžku času odozvy dopytu.

—1— dataset-Big Query

—1— dataset-GCS-l
—1— dataset-GCS-5
—1— dataset-GCS-eO-B

.Á f 1
-4 HA
Str
T |

" ^w- —•-—

0 12 24 3& 48 60 72
N e t w o r k d a t a [hours]

Obr. 7.8: Zoskupovanie + agregácia + zoradenie 1 po hodinách.

Merania nad dataset-GCS-60 pre prípadovú štúdiu Zoskupovanie

+ agregácia + zoradenie 2 neboli uskutočniteľné, pretože dopytovanie
končilo s chybovou správou, že zdroje vyčerpali svoju pamäť.

2 021-OS-07 2 021-08-08 2 021-08-09

N e t w o r k d a t a [days]

Obr. 7.9: Zoskupovanie + agregácia + zoradenie 2 po dňoch.

43
 7- VÝSLEDKY

• 12 24 36 48 60 72
N e t w o r k d a t a [hours]

Obr. 7.10: Zoskupovanie + agregácia + zoradenie 2 po hodinách.

44
8 Záver

V tejto práci sme sa snažili overiť, či použitie cloudových distribu­

ovaných nástrojov predstavuje efektívnejší a rýchlejší spôsob analýzy
sieťových tokov. A l e taktiež nájsť najlepší spôsob uloženia v rámci
nástrojov v Google C l o u d , z ktorých ich bude možné analyzovať ná­
strojom Google BigQuery.
Porovnaním rýchlostí vyhodnotenia analýzy sieťových tokov tra­
dičnými nástrojmi s cloudovými distribuovanými nástrojmi dôjdeme
k očakávaným záverom. Práca [10] pracovala s rôznymi Frameworkmi
IPFIX kolektorov. Aj napriek tomu, že dátový súbor použitý v ich práci
bol o polovicu menší ako ten náš, vyhodnotenie pre rovnaké prípadové
štúdie sa pohybovalo u nich v rádoch minút, kdežto vyhodnotenie
na nami skúmanom cloudovom distribuovanom nástroji trvalo krat­
šie, a to v rádoch sekúnd. Preto si dovolíme konštatovať, že použitie
nástroja Google BigQuery sa javí ako veľmi výhodný spôsob analýzy
sieťových tokov z časového hľadiska.
Pri hľadaní optimálneho spôsobu uloženia záznamov sieťových
tokov nás okrem časového hľadiska zaujíma aj to finančné. Keďže vý­
počet účtovaných bajtov za vykonané dopyty je jednotný, cena dopytov
nad dátovými súbormi uloženými v G C S alebo BigQuery úložisku
je rovnaká. Preto cenový rozdiel bude len v poplatkoch za úložisko.
Výhodou GCS je, že dáta môžu byť uložené v komprimovanej podobe
a za túto veľkosť sú aj účtované na rozdiel od BigQuery, kde si účtujú
za veľkosť nekomprimovaných dát. V našom prípade sme dáta mali
uložené v G C S Standard, takže cena za mesiac pre náš dátový súbor
bola okolo 108 GB * 0.02 $ = 2.16 $, v prípade úložiska BigQuery to
bolo 480 GB * 0.02 $ = 9.6 $. A k by sme mali dáta uložené v BigQuery
úložisku viac ako 90 dní, tak cena by klesla na polovicu. N a druhej
strane vyhodnotenie dopytov z BigQuery úložiska bolo vždy rýchlejšie
ako z G C S , avšak bavíme sa o rozdieloch v sekundách, čo v mnohých
prípadoch nie je obmedzujúce.
A k by sme sa rozhodli pre uloženie sieťových tokov vo formáte
Apache Parquet v úložisku GCS, tak z výsledkov vyplýva, že najlepšia
konfigurácia je jeden parquet súbor pre každú minútu sieťových dát.
Pri tejto konfigurácii by sme tiež minimalizovali čas medzi zachytením
sieťových tokov a možnosťou ich dopytovania.

45
Bibliografia

1. Q U I T T E K , J.; ZSEBY, T.; C L A I S E , B.; Z A N D E R , S. Requirements

for IP Flow Information Export (IPFIX). 2004-10. R F C , 3917. IETF.
Dostupné tiež z: h t t p : //tools. i e t f . org/rf c/rf c3917.txt.
2. H O F S T E D E , R ; ČELEDA, P.; T R A M M E L L , B.; D R A G O , L ;
SADRE, R ; SPEROTTO, A ; PRAS, A. Flow Monitoring Explained:
From Packet Capture to Data Analysis W i t h NetFlow and IP-
FIX. IEEE Communications Surveys Tutorials. 2014, vol. 16, no. 4,
s. 2037-2064. Dostupné z DOI: 10.1109/COMST. 2014.2321898.
3. ZSEBY, T ; B O S C H I , E.; B R O W N L E E , N ; C L A I S E , B. IP Flow
Information Export (IPFIX) Applicability. 2009-03. RFC, 5472. IETF.
Dostupné tiež z: h t t p : //tools. i e t f . org/rf c/rf c5472 . t x t .
4. LI, B.; SPRINGER, J.; BEBIS, G . ; H A D I G U N E S , M . A survey of
network flow applications. Journal of Network and Computer Appli­
cations. 2013, vol. 36, no. 2, s. 567-581. ISSN 1084-8045. Dostupné
z DOI: h t t p s : //doi . org/10.1016/j . jnca.2012.12.020.
5. SPEROTTO, A . ; S C H A F F R A T H , G . ; S A D R E , R ; M O R A R I U , C ;
P R A S , A . ; STILLER, B. A n Overview of IP Flow-Based Intru­
sion Detection. IEEE Communications Surveys and Tutorials. 2010,
vol. 12, s. 343-356. Dostupné z DOI: 10.1109/SURV. 2010.032210.
00054.
6. Q U I T T E K , J.; B R Y A N T , S.; C L A I S E , B.; A I T K E N , P.; M E Y E R , J.
Information Model for IP Flow Information Export. 2008-01. R F C ,
5102. IETF. Dostupné tiež z: h t t p : / / t o o l s . i e t f . o r g / r f c/
rfc5102.txt.
7. S A D A S r V A N , G . ; B R O W N L E E , NT.; C L A I S E , B.; Q U I T T E K , J. Ar­
chitecture for IP Flow Information Export. 2009-03. R F C , 5470. IETF.
Dostupné tiež z: h t t p : //tools. i e t f . org/rf c/rf c5470 . t x t .
8. C L A I S E , B. Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of IP Traffic Flow Information. 2008-01. RFC,
5101. IETF. Dostupné tiež z: h t t p : / / t o o l s . i e t f . o r g / r f c/
rfc5101.txt.

46
 BIBLIOGRAFIA

9. HOFSTEDE, R.; SPEROTTO, A . ; FIOREZE, T ; PRAS, A . The Net­

work Data H a n d l i n g War: M y S Q L vs. N f D u m p . In: A A G E S E N ,
Finn A r v e ; K N A P S K O G , S vein Johan (eds.). Networked Services
and Applications - Engineering, Control and Management. Berlin,
Heidelberg: Springer Berlin Heidelberg, 2010, s. 167-176. ISBN
978-3-642-13971-0.
10. V E L A N , P. Practical experience w i t h IPFIX flow collectors. In:
2013IFIP/IEEE International Symposium on Integrated Network Man­
agement (IM 2013). 2013, s. 1021-1026.
11. ČERMÁK, M . ; JIRSÍK, T ; LASTOVIČKA, M . Real-time analysis
of NetFlow data for generating network traffic statistics using
Apache Spark. In: NOMS 2016 - 2016IEEE/IFIP Network Operati­
ons and Management Symposium. 2016, s. 1019-1020. Dostupné z
D o i : 10.1109/NOMS. 2016.7502952.
12. Apache Parquet [online]. Brno: Apache Software Foundation [cit.
2022-04-07]. Dostupné z: https : //parquet. apache. org.
13. M E L N I K , S.; G U B A R E V , A . ; L O N G , J.; R O M E R , G . ; S H I V A K U -
M A R , S.; T O L T O N , M . ; VASSILAKIS, T. Dremel: Interactive Anal­
ysis of Web-Scale Datasets. In: Proc. of the 36th Infi Confon Very
Large Data Bases. 2010, s. 330-339. Dostupné tiež z: http://www.
vldb2010.org/accept.htm.
14. T H U S O O , A ; S A R M A , J.; JAIN, N ; S H A O , Z . ; C H A K K A , P ; A N ­
T H O N Y , S.; L I U , H ; W Y C K O F F , P.; M U R T H Y , R. Hive: A Ware­
housing Solution over a Map-Reduce Framework. 2009, vol. 2,
no. 2, s. 1626-1629. ISSN 2150-8097. Dostupné z DOI: 10 .14778/
1687553.1687609.
15. TERESHKO, T ; TIGANI, J. BigQuery under the hood [online]. Brno:
Google, 2016-01 [cit. 2022-04-20]. Dostupné z: https : //cloud,
google.com/blog/products/bigquery/bigquery-under-the-
hood.
16. Query plan and timeline [online]. Brno: Google [cit. 2022-04-20].
Dostupné z: https : / /cloud . google . com / bigquery / query -
plan-explanat i on.
17. Understand slots [online]. Brno: Google [cit. 2022-04-20]. D o ­
stupné z: https://cloud.google.com/bigquery/docs/slots.

47
 BIBLIOGRAFIA

18. A H M A D I , H . In-memory query execution in Google BigQuery [on-

line]. Brno: Google, 2016-08 [cit. 2022-04-20]. Dostupné z: h t t p s :
//cloud.google.com/blog/products/bigquery/in-memory-
query-execution-in-google-bigquery.
19. L A K S H M A N A N , V.; T I G A N I , J. Google BigQuery: The Definitive
Guide : Data Warehousing, Analytics, and Machine Learning at Scale.
O'Reilly Media, 2019. ISBN 9781492044468. Dostupné tiež z: h t t p s :
//books.google.cz/books?id=LRF7xgEACAAJ.
20. T H A L L A M , R. BigQuery explained: How to query your data [online].
Google, 2020-09 [cit. 2022-04-23]. Dostupné z: https : //cloud,
google.com/blog/topics/developers-practitioners/bigque
ry-explained-querying-your-data.
21. Batch loading data [online]. Brno: Google [cit. 2022-04-20]. D o -
stupné z: https : //cloud. google . com/bigquery/docs/batch-
loading-data.
22. Perform batch and streaming using the BigQuery Storage Write API
[online]. Brno: Google [cit. 2022-04-20]. Dostupné z: https : //
cloud.google.com/bigquery/docs/write-api.
23. T H A L L A M , R. BigQuery explained: How to ingest data into BigQuery
so you can analyze it [online]. Google, 2020-09 [cit. 2022-04-20].
Dostupné z: https://cloud.google.com/blog/topics/develo
pers-practitioners/bigquery-explained-data-ingestion.
24. Exporting table data [online]. Brno: Google [cit. 2022-04-22]. D o -
stupné z: https://cloud.google.com/bigquery/docs/exporti
ng-data.
25. Use the BigQuery Storage Read API to read table data [online]. Brno:
Google [cit. 2022-04-22]. Dostupné z: https : / / c l o u d . google .
com/bigquery/docs/reference/storage.
26. P A S U M A N S K Y , M . Inside Capacitor, BigQuery's next-generation
columnar storage format [online]. Google, 2016-04 [cit. 2022-04-
20]. Dostupné z: https : //cloud. google. com/blog/products/
bigquery / i n s i d e - c a p a c i t o r - bigquerys - next - g e n e r a t i o n -
columnar-storage-format.

48
 BIBLIOGRAFIA

27. JARETT, L. BigQuery Admin reference guide: Storage internals [on-

line]. Google, 2021-07 [cit. 2022-04-23]. Dostupné z: https : //
cloud.google.com/blog/topics/developers-practitioners/
bigquery-admin-reference-guide-storage.
28. Overview of data security and governance [online]. Google [cit. 2022-
04-23]. Dostupné z: https : / /cloud . google . com/bigquery/
docs/data-governance.
29. BigQuery pricing [online]. Google [cit. 2022-04-23]. Dostupné z:
https://cloud.google.com/bigquery/pricing.

49
A Obsah priloženého archívu

Súčasťou práce je priložený archív formátu .zip, ktorého obsah je

nasledujúci:

• /LICENSE

• /README.md

• /create_external_table_in_bigquery.py Skript na vytvorenie exter­

ných tabuliek v BigQuery.

• /create_graphs.py Skript na vytvorenie grafov z nameraných vý­

sledkov.

• /duration_results_day.csv Výsledky meraní pre dopyty po dňoch.

• /duration_results_hour.csv Výsledky meraní pre dopyty po hodi­

nách.

• /generate_and_save_data_in_gcs.py Skript na vygenerovanie a

uloženie IPFIX záznamov v G C S .

• /images Adresár obsahujúci obrázky použité v práci.

• /info_from_sample.py Skript na získanie vzorových hodnôt pre

jednotlivé atribúty IPFIX záznamov použitých p r i generovaní.

• /load_data_f rom_gcs_to_bigquery.py Skript na vytvorenie tabuľky

v natívnom úložisku BigQuery.

• /run_queries.py Skript na meranie výkonu BigQuery dopytov.

• /sample.json Vzorka IPFIX záznamov.

• /time.txt Súbor obsahujúci časovú známku, od ktorej sú genero­

vané IPFIX záznamy.

50