BI-BIG.21 – DB technologie pro Big Data

Okruh 1 – BI-WI.21-4

CAP teorém a jeho vztah k NoSQL databázím

Základy distribuovaných systémů, 3 vlastnosti CAP, kategorie CA/CP/AP, BASE model, škálování, distribuce a replikace. Porovnání relačních a NoSQL databází.

📊 Big Data a distribuované systémy

Big Data – datasety tak velké nebo komplexní, že je nelze zpracovat tradičními nástroji (převážně relačními DB). Klíčový pojem: buzzword, stále se vyvíjí.

5V model Big Data:

Volume (Objem) – množství dat; petabyty a exabyty; každý den se generuje ~2,5 kvintilionu bajtů
Velocity (Rychlost) – rychlost vzniku a zpracování; streaming v reálném čase; každých 60 sekund hodiny videa na YouTube
Variety (Různorodost) – různé typy dat: strukturovaná (SQL tabulky), polostrukturovaná (JSON, XML), nestrukturovaná (~80 % světových dat: obrázky, videa, text)
Veracity (Důvěryhodnost) – spolehlivost a přesnost dat; věrohodnost klesá s objemem
Value (Hodnota) – schopnost extrahovat hodnotu z dat; klíčová pro business intelligence

Proč nestačí relační DB?

Facebook, Google, Amazon narazily na problém škálovatelnosti: přidávání HW (vertical scaling) nestačilo. Vznikly NoSQL databáze jako řešení pro distribuované prostředí s horizontálním škálováním.

📐 CAP teorém – definice a principy

CAP teorém (Eric Brewer, 2000) – distribuovaný systém může současně splňovat nejvýše dvě ze tří vlastností: Consistency, Availability, Partition tolerance.

⚠️ Klíčový princip

V praxi je Partition tolerance (P) vždy nutná – výpadky sítě se v distribuovaných systémech předpokládají jako normální stav ("co se může pokazit, pokazí se"). Proto volíme vždy mezi C a A.

Vlastnost	Česky	Co znamená	Kdy selhává
C – Consistency	Konzistence	Každý požadavek vrátí aktuální data nebo chybu; všechny uzly vidí stejná data ve stejný čas	Pokud replika nestihla synchronizaci, vrátí staré datum
A – Availability	Dostupnost	Na každý požadavek přijde odpověď (i za cenu neaktuálních dat); systém je vždy dostupný	Pokud systém raději odmítne odpovědět, než by vrátil nekonzistentní data
P – Partition tolerance	Tolerance výpadku	Systém funguje i při výpadku komunikace mezi uzly (rozdělení sítě)	Pokud vyžadujeme 100 % spolehlivou síť

Eric Brewer v roce 2012 upřesnil: hodnoty nejsou striktně binární – lze je nastavit na spektru. Cassandra např. dovoluje konfigurovat míru konzistence za běhu.

🗂️ Kategorie CAP: CA, CP, AP

CA – Konzistence + Dostupnost
Striktní synchronizace celé DB
Vyžaduje garantovanou komunikaci = nelze tolerovat výpadky sítě (P)
Příklady: většina SQL/relačních databází (MySQL, PostgreSQL, Oracle)
Použití: bankovní systémy, účetnictví – tam kde je konzistence kritická

CP – Konzistence + Tolerance výpadku
Při výpadku sítě systém odmítne odpovědět (raději nedostupný než nekonzistentní)
Relaxujeme dostupnost (A)
Příklady: HBase, MongoDB, Redis, Google BigTable
Použití: metadata distribuovaného filesystému, internetové bankovnictví

AP – Dostupnost + Tolerance výpadku

Dostupnost je klíčová, přijímáme eventuální konzistenci – data mohou být dočasně neaktuální, ale systém vždy odpovídá. Relaxujeme konzistenci (C).

Příklady: Apache Cassandra (výchozí), CouchDB, Dynamo, Voldemort
Použití: CDN, cache servery, zpravodajské servery, Facebook (stránka může být 5 min stará), IoT
Praktická volba: výchozí pro internetové služby

Segmentovaná konzistence

Systémy mohou různé části dat klasifikovat různě – čtení a zápis mohou mít jiné požadavky. Cassandra to umožňuje pomocí konfigurovatelných úrovní konzistence (ONE, QUORUM, ALL).

🧱 BASE model vs ACID

BASE – alternativa k ACID pro NoSQL distribuované systémy; klade důraz na dostupnost a škálovatelnost před striktní konzistencí.

ACID (relační DB)

Atomicity – transakce proběhne celá nebo vůbec
Consistency – DB zůstane konzistentní před i po transakci
Isolation – transakce jsou izolované od sebe
Durability – potvrzená data jsou trvale uložena

BASE (NoSQL DB)

Basically Available – systém je dostupný vždy, i při výpadcích (může vracet částečné výsledky)
Soft state – stav dat může být dočasně nekonzistentní; asynchronní replikace
Eventual consistency – data se nakonec dostanou do konzistentního stavu, ale ne okamžitě

Proč to tak je?

V distribuovaných systémech s tisíci uzly a nespolehlivou sítí je striktní ACID konzistence extrémně drahá. BASE obětuje okamžitou konzistenci výměnou za výkon, škálovatelnost a dostupnost. Eventuální konzistence je dostatečná pro většinu webových aplikací.

📏 Škálování, distribuce a replikace

Koncept	Horizontální (Scale Out)	Vertikální (Scale Up)
Princip	Přidání dalších uzlů (serverů) do clusteru	Upgrade stávajícího HW (více RAM, CPU)
Limit	Teoreticky neomezené; síťová latence	HW limity; vysoká cena
Technologie	NoSQL, cloud, distribuované systémy	Relační DB

Strategie distribuce dat v NoSQL:

Distribuce podle klíče – každý klíč mapován na konkrétní uzel; rychlé vyhledávání, ale nerovnoměrná zátěž
Hashovací funkce – hash klíče určí uzel; rovnoměrné rozložení zátěže; lepší škálovatelnost
Sharding – data rozdělena do fragmentů (shardů), každý na jiném uzlu; lineární horizontální škálování; ochrana proti výpadku jednoho serveru

Replikační modely:

Master-Slave (asynchronní) – jeden master (zápis), N slave (čtení); vhodné pro read-heavy workload; při výpadku masteru slave přebírá roli
Peer-to-Peer (synchronní) – všechny uzly rovnocenné; čtení i zápis na libovolný uzel; problém write-write konfliktů; řeší se "volební princip" (nadpoloviční shoda)

⚠️ Write-Write konflikt

V P2P replikaci mohou dva uzly přijmout zápis stejných dat ve stejný čas → trvalé poškození dat. Cassandra to řeší algoritmem Last-Write-Wins (vyhrávají novější časová razítka).

🗃️ Typy NoSQL databází a porovnání s relačními

"Not Only SQL" – databáze bez pevného schématu, horizontálně škálovatelné, CAP/BASE místo ACID.

Typ	Princip	Příklady	Vhodné pro
Klíč-Hodnota	Hashtable; rychlé GET/PUT	Redis, Riak, DynamoDB	Cache, session, profily uživatelů
Dokumentová	JSON/BSON dokumenty; flexibilní schéma	MongoDB, CouchDB	Katalogy, blog, e-commerce
Sloupcová (Column-family)	Data uložena po sloupcích; rodiny sloupců	Apache Cassandra, HBase	Big Data analýzy, IoT, časové řady
Grafová	Uzly a hrany; vztahy jako first-class citizens	Neo4j, JanusGraph	Sociální sítě, doporučovací systémy

Aspekt	Relační DB	NoSQL DB
Konzistence	ACID transakce	BASE / eventuální konzistence
Škálování	Vertikální	Horizontální (cluster)
Schéma	Pevné, dopředu definované	Flexibilní, schéma-free
Záloha	Pravidelné zálohy	Replikace dat
Objem dat	Předvídatelný lineární nárůst	Exponenciální, nepředvídatelný

📋 Shrnutí okruhu 1

CAP teorém: distribuovaný systém zvládne max. 2 ze 3 vlastností (C, A, P)
P (Partition tolerance) je v praxi vždy nutná → reálně volíme mezi CP a AP
BASE = alternativa k ACID; eventuální konzistence; klade dostupnost před konzistenci
NoSQL = horizontální škálování, flexibilní schéma, distribuce dat přes cluster
Distribuce: sharding (fragmenty), hashing (rovnoměrné rozdělení), replikace (záloha)

🎓 Kontrolní otázky a odpovědi:

❓ Vysvětlete CAP teorém a proč v praxi nelze mít všechny tři vlastnosti současně.

Distribuovaný systém nemůže zaručit Konzistenci, Dostupnost a Toleranci výpadku sítě najednou. V praxi jsou výpadky sítě nevyhnutelné, takže P musíme vždy tolerovat. Při výpadku sítě musíme vybrat: buď odmítneme odpovědět (zachováme C) nebo odpovíme potenciálně neaktuálními daty (zachováme A). To je fundamentální fyzikální omezení – synchronizace dat přes síť trvá čas.

❓ Co je to eventuální konzistence a proč ji NoSQL databáze používají?

Eventuální konzistence (eventual consistency) garantuje, že pokud přestanou přicházet nové zápisy, všechny uzly se nakonec dostanou do stejného stavu – ale ne okamžitě. NoSQL databáze ji používají, protože umožňuje dosáhnout vysoké dostupnosti a výkonu v distribuovaném prostředí, kde okamžitá synchronizace by byla příliš drahá.

❓ Jaký je rozdíl mezi horizontálním a vertikálním škálováním?

Vertikální (scale up) = přidání výkonu do jednoho serveru (více RAM, CPU, disk). Má HW limity a je drahé. Horizontální (scale out) = přidání dalších serverů do clusteru. Teoreticky neomezené, použitelný levný hardware. NoSQL databáze jsou designovány pro horizontální škálování.

❓ Jak se Cassandra kategorizuje v CAP teorému a proč?

Cassandra je ve výchozím nastavení AP (dostupnost + tolerance výpadku). Výchozí nastavení preferuje dostupnost: odpovídá vždy, i za cenu eventuálně nekonzistentních dat. Lze ji ale překonfigurovat na CP (konzistenci QUORUM nebo ALL), čímž obětujeme dostupnost ve prospěch konzistence.

Okruh 2 – BI-WI.21-5

MapReduce model: principy a využití pro dotazování Big Data

Programovací model MapReduce, fáze Map/Shuffle/Reduce, Hadoop ekosystém, HDFS, YARN, detailní flow výpočtu, praktické příklady WordCount.

🗺️ MapReduce – základní princip

MapReduce – programovací model a výpočetní framework (Google, 2004) pro paralelní zpracování velkých dat v distribuovaném prostředí. Základní myšlenka: "přivést výpočet k datům, ne data k výpočtu."

Tradiční přístup přesouvá data na jeden server ke zpracování – v Big Data to je nefektivní (data jsou příliš velká). MapReduce místo toho posílá kód (výpočet) k datům, kde data fyzicky leží. Výsledky se poté agregují.

Proč MapReduce?
Sharding bez MapReduce by neumožnil dotazovat všechny servery najednou
Transparentní paralelizace – programátor píše jednoduchou logiku, framework se postará o distribuci
Fault tolerance – pokud uzel selže, task se automaticky přerozdělí

⚙️ Fáze MapReduce: Map, Shuffle, Reduce

Celý výpočet probíhá ve třech logických fázích:

1. Fáze MAP
Vstupní data jsou rozdělena na InputSplits – každý split přiřazen jednomu Mapperu
RecordReader transformuje raw data na <klíč, hodnota> páry pro Mapper
Mapper aplikuje uživatelskou funkci a produkuje mezioutputs ve formě <klíč2, hodnota2>
Počet Mapperů = počet InputSplitů (nelze konfigurovat přímo, závisí na InputFormat)
Operace: map (1→1), filter (1→0 nebo 1), flatmap (1→N)

2. Fáze SHUFFLE & SORT
Partitioner rozhoduje, do kterého Reduceru data půjdou (výchozí: HashPartitioner dle klíče)
Combiner (volitelný) = "mini-reducer" na každém Mapperu; redukuje přenášená data přes síť; vhodný pro komutativní funkce (sčítání, počítání)
Shuffle = přesun dat z Map nodů na Reduce nody přes síť (HTTP/HTTPS) – kritické místo pro výkon sítě; data se zapisují na lokální disk
Sort = data jsou seřazena podle klíče (komparátor) než vstoupí do Reduceru

3. Fáze REDUCE
Reducer přijme všechna data pro svůj partition key seřazená
Aplikuje agregační logiku → výsledky uloží na HDFS
Výstupní soubory: part-r-0001, part-r-0002, ... + _SUCCESS
Počet Reducerů je konfigurovatelný (parametr job.setNumReduceTasks(N))
Výstupy různých reducerů nejsou vzájemně seřazeny

Příklad WordCount – počítání výskytů slov:

Map: Pro každé slovo emituj (slovo, 1)
Shuffle: Všechna (slovo, 1) se stejným slovem jdou ke stejnému Reduceru
Reduce: Sečti všechny jedničky pro každé slovo → (slovo, počet)

🐘 Apache Hadoop – ekosystém a architektura

Apache Hadoop – open-source framework pro distribuované ukládání a zpracování velkých dat. Klíčová vlastnost: přivést výpočet k datům, ne data k výpočtu.

Základní komponenty Hadoop:

HDFS – Hadoop Distributed File System; úložiště
YARN – Yet Another Resource Negotiator; správa zdrojů a plánování jobů
MapReduce – výpočetní engine
Common – sdílené knihovny

Výhody Hadoop: distribuovaný, rychlý, levný (commodity HW), bezpečný (fault tolerance), schopen zpracovat data jakéhokoliv typu (strukturovaná i nestrukturovaná).

HDFS – Hadoop Distributed File System
Master-Slave architektura: NameNode (master) + DataNodes (slaves)
NameNode – uchovává metadata (seznam souborů, bloků, repliky) v paměti (in-memory); single point of failure! Řeší se HA nastavením (Secondary NameNode, StandBy NameNode)
DataNode – uchovává datové bloky; posílá heartbeat NameNodu; provádí instrukce (vytvoř, smaž, replikuj blok)
Blok – základní jednotka HDFS; typicky 128 MB nebo 256 MB; každý soubor je rozdělen do bloků; bloky jsou replikovány (výchozí replikační faktor = 3)
Optimalizace: write-once/read-many; výborné pro batch zpracování (vysoká propustnost), nevhodné pro real-time (vysoká latence)

📖 Klíčová terminologie MapReduce

Termín	Popis
NODE	Fyzický stroj nebo virtuální kontejner s JVM
JOB	MapReduce program + konfigurace + vstupní data; největší jednotka výpočtu
ApplicationMaster	Master – řídí celý výpočet jobu; koordinuje Tasky
SPLIT	Logická část vstupních dat; reference na data (ne fyzická kopie)
TASK	Výpočet Map nebo Reduce funkce nad jedním Splitem
TASK ATTEMPT	Pokus provést Task na konkrétním Nodu; při selhání se opakuje
InputFormat	Definuje strategii čtení a rozdělení dat; typy: TextInputFormat, SequenceFileInputFormat
InputSplit	Reference na část dat; počet splitů = počet Mapperů
RecordReader	Připravuje [klíč, hodnota] páry pro Mapper ze Splitu
Mapper	Interface Mapper<K1,V1,K2,V2>; transformuje vstup na mezivýstup
Combiner	Stejný interface jako Reducer; pre-agregace dat před Shuffle; snižuje síťový přenos
Partitioner	Rozhoduje do kterého Reduceru jdou která data; výchozí: HashPartitioner
SHUFFLE	Přesun dat přes síť z Mapperů k Reducerům; kritické pro výkon
SORT	Seřazení dat dle klíče před vstupem do Reduceru; probíhá souběžně se Shuffle
Reducer	Interface Reducer<K2,V2,K3,V3>; agreguje výstup; výsledek na HDFS
OutputFormat	Definuje formát výstupních dat; typy: TextOutputFormat, SequenceFileOutputFormat

⚖️ Omezení MapReduce a proč vznikl Spark

Slabiny MapReduce
Pouze batch processing – nelze použít pro streaming, interaktivní dotazy nebo ML
Vysoká latence – mezi každou fází Map→Shuffle→Reduce se zapisuje na disk; pro iterativní algoritmy (ML) je to velmi pomalé
Verbózní kód – jednoduché operace vyžadují mnoho kódu (Java API)
Složité ladění a monitorování – dependency hell, Kerberos security, komplexní konfigurace

Proto vznikl Apache Spark, který zpracovává data in-memory a podporuje batch, streaming i ML v jednom frameworku.

📋 Shrnutí okruhu 2

MapReduce = programovací model pro distribuované zpracování; 3 fáze: Map, Shuffle+Sort, Reduce
Klíčový princip: výpočet k datům, ne data k výpočtu (minimalizace síťového přenosu)
Combiner = mini-reducer; snižuje data přenesená přes síť (vhodný pro komutativní funkce)
HDFS: NameNode (metadata, in-memory) + DataNodes (data, bloky); replikační faktor 3
Hadoop ekosystém: HDFS (storage) + YARN (resources) + MapReduce (compute)

🎓 Kontrolní otázky a odpovědi:

❓ Popište detailně průběh MapReduce výpočtu od vstupu po výstup.

1. Data načtena z HDFS. 2. InputFormat určí strategii čtení a rozdělení na InputSplity. 3. RecordReader vytvoří [klíč, hodnota] páry. 4. Mapper transformuje každý pár na mezioutput [klíč2, hodnota2]. 5. Volitelný Combiner pre-agreguje výstup Mapperu. 6. Partitioner určí, ke kterému Reduceru data patří. 7. Shuffle = přesun dat přes síť na Reduce nody. 8. Sort = seřazení dat dle klíče. 9. Reducer zpracuje seřazené páry a emituje výsledky. 10. OutputFormat zapíše výsledky na HDFS (part-r-XXXX soubory).

❓ K čemu slouží Combiner a kdy ho lze použít?

Combiner je "mini-reducer" na straně Mapperu. Provede částečnou redukci dat ještě před Shuffle fází – snižuje množství dat přenášených přes síť. Lze ho použít jen pro komutativní a asociativní operace (sčítání, Maximum, Minimum, Count). Nelze pro operace jako Average (průměr) – nejdřív musím sečíst všechna čísla a pak dělit.

❓ Jaký je rozdíl mezi HDFS blokem a InputSplitem?

HDFS blok je fyzická jednotka uložení dat na disku (typicky 128–256 MB). InputSplit je logická jednotka – reference na část dat, která bude zpracována jedním Mapperem. Split nemusí přesně odpovídat bloku. Počet Splitů = počet Mapperů. Počet bloků závisí na velikosti souboru a velikosti bloku.

Okruh 3 – BI-WI.21-6

Apache Cassandra – architektura, databázový model, distribuce dat

Masterless ring architektura, konzistentní hashování, Gossip protokol, struktura dat (Keyspace, Column Family, Row, Column), čtení a zápis, replikace, CQL jazyk.

🏛️ Apache Cassandra – úvod a charakteristika

Apache Cassandra – open-source distribuovaná sloupcově orientovaná databáze. Navržena Facebookem (2008) jako kombinace Amazon Dynamo (distribuce, replikace) + Google BigTable (datový model). Nyní spravována Apache Software Foundation.

Klíčové vlastnosti:

Master-less architektura – žádný "master" node; všechny uzly jsou si rovny; odolnost vůči SPOF (Single Point of Failure)
Lineární škálovatelnost – přidáním každého nového nodu roste výkon lineárně
Extrémní odolnost – Restart Free, Fail Free, Maintenance Free; zvládá 100 000+ nodů (Apple)
AP systém (výchozí) – dostupnost + tolerance výpadku; konfigurovatelné na CP
In-Memory – memtable struktura; po naplnění zápis na disk
CQL – vlastní dotazovací jazyk podobný SQL (bez JOINů)
Java platforma – multiplatformní díky JVM; OS Free

Co Cassandra převzala z Dynamo
Dělení dat pomocí konzistentního hashování (Hash Rings)
Replikace s verzovanými daty (Last-Write-Wins)
Distribuce clusteru a detekce chyb pomocí Gossip protokolu
Škálovatelnost na commodity hardware

🗄️ Databázový model Cassandry

Cassandra	Relační DB	Popis
Keyspace	Databáze	Nejvyšší kontejner; definuje replikační strategii, faktor, konzistenci; unikátní název v clusteru
Column Family	Tabulka	Definuje strukturu dat; každý řádek může mít různý počet sloupců
Row	Řádek	Kolekce sloupců identifikovaná Partition Key a Clustering Key
Column	Sloupec	Trojice: název + hodnota + timestamp; vždy definovaný datový typ
Super Column	N/A	"Tabulka v tabulce"; sloupec obsahující další sloupce; analogie 3. normální formy v SQL
Row Key	Primární klíč	Partition Key (určuje uzel) + Clustering Key (řazení uvnitř oddílu)

Primární klíče v Cassandře
Partition Key – hashuje se pro určení uzlu; všechny řádky se stejným PK jsou fyzicky na stejném uzlu
Clustering Key – určuje fyzické pořadí dat v rámci oddílu; umožňuje efektivní range queries
Složený PK: PRIMARY KEY ((partition_key), clustering_key1, clustering_key2)
Dotazy musí vždy specifikovat Partition Key – bez něj nebude dotaz efektivní (full table scan)

Keyspace – replikační strategie:

SimpleStrategy – jen pro testování; neumožňuje různý replikační faktor pro různá DC
NetworkTopologyStrategy – produkce; různý replikační faktor pro každé datacenter; zaručuje repliky na různých rackách v DC

💍 Masterless Ring architektura

Hash Ring – uzly Cassandry jsou uspořádány do kruhu. Každý uzel je zodpovědný za určitý rozsah hodnot hashů (token range). Data se hashují a umísťují na odpovídající uzel v kruhu.

Konzistentní hashování:

Klíč záznamu se zahashuje → hash = token → určí uzel
Na rozdíl od prostého hashování: přidání/odebrání uzlu přesune jen část dat (ne vše)
Virtuální uzly (vnodes) – každý fyzický uzel může hostit více virtuálních uzlů; lepší vyrovnání zátěže při přidání/odebrání nodu
Tabulka tokenů mapuje virtuální → fyzické uzly

Výhody masterless architektury
Žádný SPOF – výpadek libovolného nodu neohrozí systém
Bezešvé rozšiřování – nový node přidán bez výpadku, replikace proběhne sama
Data mohou být replikována do více datacenter
Last-Write-Wins – konflikty mezi replikami řeší timestamp; novější hodnota vyhrává

💬 Gossip protokol a detekce chyb

Gossip protokol – peer-to-peer komunikační protokol pro synchronizaci informací o stavu clusteru. Každý uzel "šeptá" (gossipuje) informace sousedním uzlům.

Jak Gossip funguje (1x za sekundu):

Uzel inkrementuje číslo svojí verze a vytvoří zprávu o svém stavu
Náhodně vybere jiný uzel a vymění si informace
Pokusí se komunikovat s nedostupnými uzly (pokud o nich ví)
Komunikuje se Seed nodem (pokud tak neučinil)

Informace sdílené přes Gossip: konfigurace clusteru, stav uzlů, umístění dat, verze informací (zastaralé se ignorují).

Seed uzly

Seed uzly jsou vstupní brány do clusteru pro nové uzly. Nový uzel kontaktuje Seed → dostane topologii clusteru → připojí se. Seed by měl být v clusteru vícekrát pro redundanci.

Detekce chyb – Phi Accrual Failure Detector

Gossip sám o sobě chyby nezjišťuje – to dělá Phi Accrual Failure Detector. Každý uzel sleduje heartbeaty ostatních uzlů a nezávisle rozhoduje, kdo je nedostupný. Nedostupné uzly nejsou automaticky odstraněny z clusteru – data se pro ně uchovávají jako hints a při obnovení komunikace jsou doručena.

✍️ Proces zápisu a čtení dat

Zápis dat:

Data zapsána do Commit Logu (WAL – Write-Ahead Log; obnova po havárii)
Data zapsána do Memtable (write-back cache v RAM)
Po naplnění limitu se Memtable propíše na disk jako SSTable (Sorted String Table)
SSTable je immutable soubor; nikdy se nemění, jen přidává nová verze

Čtení dat:

Bloom Filter – probabilistická struktura; rychle zjistí, zda klíč pravděpodobně v SSTable je (může mít false positive, ale ne false negative)
Key Cache – cache nejčastěji čtených klíčů s ukazatelem do SSTable
Partition Index – index všech klíčů; pro klíče nenalezené v cache
SSTable – fyzické čtení z disku
Memtable – slučuje data z SSTable s novějšími daty v Memtable

Škálovatelná konzistence (Tunable Consistency)

Cassandra umožňuje nastavit úroveň konzistence pro každou operaci zvlášť. Čím vyšší konzistence, tím nižší dostupnost.

Úroveň	Co znamená	Kdy použít
ONE	Stačí odpověď od 1 repliky	Nejrychlejší, nejnižší konzistence
TWO / THREE	Odpověď od 2/3 replik	Střední konzistence
QUORUM	Nadpoloviční většina (n/2 + 1)	Dobrý kompromis
LOCAL_QUORUM	Quorum v lokálním DC	Multi-DC nasazení
ALL	Všechny repliky musí odpovědět	Maximální konzistence, nízká dostupnost
ANY (jen zápis)	Uloženo jako hint, ještě není čitelné	Maximální dostupnost zápisu

Pravidlo pro konzistenci

Pokud úroveň zápisu + úroveň čtení > replikační faktor, je zaručena silná konzistence (čteme vždy nejnovější data). Např. RF=3: QUORUM čtení + QUORUM zápis = 2+2=4 > 3 → silná konzistence.

💻 CQL – Cassandra Query Language

CQL – "SQL minus joins, minus subqueries, plus collections." (Robert Stupp). Vlastní dotazovací jazyk Cassandry.

Co CQL nepodporuje: JOINy, poddotazy, cizí klíče, relace (je to NoSQL!).

Co CQL podporuje navíc:

Datové typy pro kolekce: list, map, set, frozen
Speciální typy: timeuuid (časové UUID v1), uuid (náhodné UUID v4), counter, inet (IP adresa)
Uživatelsky definované typy (UDT): CREATE TYPE
Uživatelsky definované funkce a agregace
Batch operace: BEGIN BATCH ... APPLY BATCH (atomické)
TTL (Time To Live): INSERT ... USING TTL 60 – automatické mazání
Materialized Views (experimentální)

Základní DDL/DML příkazy:

CREATE KEYSPACE – vytvoření keyspace s replikační strategií
CREATE TABLE – s definicí primárního klíče
INSERT INTO ... IF NOT EXISTS
SELECT – musí obsahovat Partition Key; bez něj ALLOW FILTERING (pomalé!)
UPDATE, DELETE, TRUNCATE, DROP
CREATE INDEX – sekundární indexy

📋 Shrnutí okruhu 3

Cassandra = AP distribuovaná sloupcová DB bez masteru; masterless ring architektura
Konzistentní hashování + Hash Ring – data distribuována pomocí hash tokenu klíče
Gossip protokol – peer-to-peer synchronizace stavu clusteru každou sekundu
Zápis: Commit Log → Memtable → SSTable (immutable); čtení: Bloom Filter → Key Cache → Partition Index → SSTable + Memtable merge
Tunable Consistency: ONE, QUORUM, ALL – kompromis mezi konzistencí a dostupností

🎓 Kontrolní otázky a odpovědi:

❓ Vysvětlete masterless ring architekturu Cassandry a jak distribuuje data.

Cassandra organizuje uzly do logického kruhu (ring). Každý uzel zodpovídá za rozsah hash hodnot (token range). Při zápisu se klíč záznamu zahashuje → výsledný token určí primární uzel. Data se replikují na sousední uzly v kruhu (dle replikačního faktoru). Virtuální uzly (vnodes) umožňují lepší vyrovnání zátěže – každý fyzický uzel může hostit více virtuálních tokenových rozsahů.

❓ Jak funguje Gossip protokol a k čemu slouží?

Gossip je peer-to-peer komunikační protokol. Každou sekundu každý uzel: (1) inkrementuje svou verzi, (2) náhodně vybere jiný uzel a vymění informace, (3) pokusí se kontaktovat nedostupné uzly, (4) komunikuje se seed uzly. Informace jsou verzované – starší se ignorují. Slouží k synchronizaci stavu clusteru (kdo je online, kde jsou data), ale samotnou detekci chyb provádí Phi Accrual Failure Detector.

❓ Popište proces zápisu a čtení dat v Cassandře.

Zápis: 1. Commit Log (WAL pro obnovu po havárii) 2. Memtable (in-memory cache) 3. Po dosažení limitu flush na disk jako SSTable (immutable). Čtení: 1. Bloom Filter (rychlá pravděpodobnostní kontrola, zda klíč existuje v SSTable) 2. Key Cache (nejčastěji čtené klíče) 3. Partition Index (index všech klíčů) 4. Compressed Offset Map → SSTable na disku 5. Merge s Memtable (novější data z RAM přebijí starší z SSTable).

❓ Co je Partition Key a Clustering Key a jaký je jejich účel?

Partition Key (klíč oddílu) určuje, na který uzel v clusteru data patří – hashuje se a výsledek určí token v Hash Ringu. Všechna data se stejným Partition Key jsou fyzicky na jednom uzlu. Clustering Key (seskupovací klíč) určuje fyzické pořadí dat uvnitř oddílu – umožňuje efektivní range queries v rámci jednoho oddílu. Dotazy bez Partition Key jsou extrémně pomalé (full table scan).

Okruh 4 – BI-WI.21-7

Apache Spark & Elastic Stack – distribuované výpočty a indexace

Spark: Driver/Executor architektura, RDD, DataFrame, DAG, transformace a akce, lazy evaluation. Elastic Stack: Elasticsearch indexace, Logstash pipeline, Kibana vizualizace, Beats.

⚡ Apache Spark – úvod a motivace

Apache Spark – unifikovaný framework pro distribuované výpočty nad velkými daty. Podporuje batch, streaming, ML, SQL dotazy a grafové výpočty v jednom systému. Napsán ve Scale, API pro Scala, Java, Python, R.

Proč Spark a ne jen MapReduce?

Kritérium	MapReduce (Hadoop)	Apache Spark
Rychlost	Disk I/O mezi každou fází (pomalé)	In-memory výpočty (10–100× rychlejší)
Iterativní algoritmy	Nevhodné – každá iterace = nový job → disk	Výborné – data v paměti přes iterace
Typy zpracování	Pouze batch	Batch, streaming, ML, grafy, SQL
API	Verbose Java API	Stručné API (Scala, Python, SQL)
Interaktivní shell	Ne	Ano (REPL)

Spark byl vyvinut na UC Berkeley (2009), od 2013 jako Apache projekt. Používá ho: Oracle, Cisco, Visa, Microsoft, Databricks, Amazon, Yahoo, Seznam a tisíce dalších firem.

🏗️ Spark architektura a klíčové principy

Driver/Executor – master/slave architektura. Driver řídí výpočet, Executor provádí tasky na worker nodech.

Klíčové principy Sparku:

Driver – hlavní program; koordinuje výpočet; posílá tasky Executorům; hostuje SparkContext
Executor – JVM proces na worker nodu; provádí tasky; drží data v paměti (cache)
In-memory výpočty – data zůstávají v RAM Executorů; eliminuje disk I/O mezi fázemi
DAG (Directed Acyclic Graph) – Spark builduje DAG transformací před spuštěním; optimalizuje plán výpočtu
Lazy Evaluation – transformace se nevykonají ihned; trigger je až Akce (collect, count, save). Umožňuje optimalizaci celého plánu.
Immutable data – RDD/DataFrame nelze modifikovat; transformací vznikají nové
Fault tolerant – při výpadku uzlu se ztracená partition dopočítá znovu z lineage (DAG záznamu)

SparkContext a submit

SparkContext je instance Spark aplikace – bez něj nelze výpočet spustit. Aplikace se submituje pomocí: spark-submit --class path.To.Class --master yarn [jar] [options]. Celý JAR je distribuován na každý node.

Hierarchy výpočetních jednotek:

Job – celý výpočet od akce; největší jednotka
Stage – logická část výpočtu oddělená Shuffle boundary (join, reduceByKey, groupBy); uvnitř Stage nejdou data přes síť
Task – výpočet jedné Stage nad jednou partition; na jednom Executoru v jednom vlákně

📦 RDD, DataFrame a Dataset API

RDD – Resilient Distributed Dataset
Dataset – kolekce objektů jakéhokoliv typu
Distributed – rozdělena na partitions; každá partition zpracována jiným Task/Executor
Immutable – nelze měnit; transformace vytváří nové RDD
Resilient – při výpadku uzlu se ztracená partition dopočítá z lineage (záznamu transformací)
In-memory – RDD se drží v RAM Executoru; rychlé, ale náročné na paměť
Nejnižší úroveň API; maximální flexibilita; typicky pro unstrukturovaná data

DataFrame a Dataset
Dataset – novější API (od v1.6); RDD + optimalizovaný execution engine + schéma; API pro Scala, Java
DataFrame – Dataset<Row>; organizovaný do pojmenovaných sloupců; konceptuálně tabulka; SQL-like operace
Lze dotazovat pomocí SQL: spark.sql("SELECT name FROM people WHERE age > 18")
Přístup i přes JDBC/ODBC
Catalyst optimizer automaticky optimalizuje plán dotazu

🔄 Transformace a Akce (Lazy Evaluation)

Transformace (lazy – nevykonají se okamžitě):

Narrow – data z jedné partition:

map, flatMap, filter
mapPartitions, sample, union
Lze "slepit" bez přesunu dat přes síť

Wide – data z více partition (způsobí Shuffle):

reduceByKey, groupByKey
join, repartition, coalesce
Vyžadují přesun dat přes síť → Stage boundary

Akce (eager – spouštějí výpočet):

collect() – vrátí všechna data do driveru
take(n) – prvních n prvků
count() – počet prvků
top(n) – top n prvků
fold(), aggregate()
foreach() – iterace přes prvky
saveAsTextFile() – uložení na disk

Lazy Evaluation – proč je to důležité

Spark neexekutuje transformace ihned. Místo toho builduje DAG (plán výpočtu). Až když nastane Akce, Spark zoptimalizuje celý plán (sloučí transformace, eliminuje zbytečné operace) a teprve pak spustí výpočet. To umožňuje Catalyst optimizér dosáhnout výkonu srovnatelného s ručně optimalizovaným kódem.

Shuffle boundary = Stage boundary – operace jako join, reduceByKey, groupByKey, repartition způsobí Shuffle (přesun dat přes síť). Každý Shuffle odděluje dvě Stage.

🔍 The Elastic Stack – přehled a komponenty

Elastic Stack (ELK) – sada nástrojů pro sběr, zpracování, ukládání, vyhledávání a vizualizaci dat. Komponenty: Elasticsearch + Logstash + Kibana (+ Beats).

Komponenta	Role	Popis
Elasticsearch	Úložiště + vyhledávač	Distribuovaný search engine; indexuje a ukládá data; RESTful API (JSON)
Logstash	Zpracování dat	Sběr, transformace a posílání dat do ES; pipeline: Input → Filter → Output
Kibana	Vizualizace	Webové UI pro Elasticsearch; dashboardy, grafy, mapy, ML detekce anomálií
Beats	Sběr dat	Odlehčené agenty pro sběr dat z různých zdrojů; posílají do ES nebo Logstash

🔬 Elasticsearch – architektura a indexace

Elasticsearch – distribuovaný RESTful search engine; open-source (Apache 2.0); postaven na Apache Lucene; implementován v Javě (JVM). Primárně pro realtimové vyhledávání.

Datová struktura (analogie s relační DB):

Index ≈ tabulka; předepisuje datový typ, schéma (mapping), nastavení shardů
Dokument ≈ řádek; jednotka dat uložená v indexu
Field ≈ sloupec; pole v dokumentu s definovaným typem a analyzérem

Cluster, Node, Shard:

Cluster – skupina spolupracujících nodů; jednoduše škálovatelný (přidání nodu)
Node typy: Datový (ukládá data), Master (správa clusteru), Clientský (proxy), Ingest (pre-processing)
Shard – jedna instance Lucene indexu; Primární shard + Replika shard
Elasticsearch distribuuje shardy automaticky; doporučeno min. 3 nody (64 GB RAM každý, SSD)

Indexace – jak funguje analýza textu

Každý dokument před uložením prochází analyzérem (pipeline):

Char filters – úprava textu (např. odstranění HTML tagů)
Tokenizer – rozdělení textu na tokeny (slova, interpunkce)
Token filters – lowercase, odstranění stop slov (předložky), stemming

Výsledné tokeny jsou uloženy do invertovaného indexu (obrácený index: slovo → dokumenty kde se vyskytuje). ES podporuje ~40 jazyků, včetně českého analyzéru (rozumí skloňování!).

Near Real-Time (NRT) vyhledávání

Nové dokumenty nejsou viditelné okamžitě, ale po procesu refresh (výchozí: každou sekundu pro aktivní indexy). Refresh = nový Lucene segment zapíše do file system cache → viditelný pro vyhledávání bez drahého fsync na disk. Proto "near" real-time.

🪵 Logstash – pipeline pro zpracování dat

Logstash – open-source nástroj pro sběr, normalizaci a obohacení dat z různých zdrojů. Napsán v JRuby (JVM). Centralizovaný "trychtýř" pro logy před indexací do Elasticsearch.

Architektura pipeline: Input → Filter → Output

Event Object – základní datová jednotka; zapouzdřuje tok dat pipeline
Input plugins – zdroje dat: file, stdin, beats, http, elasticsearch, twitter, kafka, azure_event_hub
Filter plugins – transformace: grok (regex parsing), mutate (přejmenování, konverze), json/csv/xml (parsování), geoip (GPS z IP adresy), date (parsování časových razítek), ruby (vlastní kód)
Output plugins – cíle: elasticsearch, file, stdout, email, http, mongodb, tcp

Perzistentní fronta

Výchozí nastavení: in-memory fronta (při výpadku Logstash ztrácíme data). Perzistentní fronta ukládá čekající zprávy na disk – ochrana před ztrátou dat při výpadku. Nevýhoda: bez replikace (ochrana proti disk failure).

Více pipeline: Logstash umožňuje spustit více pipeline v jednom procesu (konfigurace v pipelines.yml). Různé pipeline mohou mít různé nastavení výkonu a trvanlivosti.

💓 Beats a Kibana

Beats – odlehčené jednoúčelové agenty pro sběr dat; alternativa k těžkému Logstashi přímo na zdrojovém serveru:

Filebeat – čtení logů ze souborů; posílá do ES nebo Logstash
Metricbeat – metriky systému (CPU, RAM, disk)
Heartbeat – monitoring dostupnosti URL endpointů
Auditbeat – auditové logy z Linux auditd
Packetbeat – monitoring síťového provozu
Winlogbeat – Windows Event Logy
Journalbeat – systemd journal (Linux)
Lze napsat vlastní Beat pomocí libbeat knihoven

Kibana – webový analytický a vizualizační nástroj pro Elasticsearch:

Data View (dříve Index Pattern) – definuje zdroje dat (indexy, datastreamy)
Discover – interaktivní průzkum dat s KQL filtry
Visualize Library – tvorba grafů (Lens, heatmapy, koláčové grafy, histogramy, Aggregation based)
Dashboard – kompozice vizualizací; interaktivní přehled dat
Canvas – prezentace; flexibilnější než Dashboard; export do PDF
Maps – geospatial vizualizace; GeoJSON, animované mapy
Machine Learning – detekce anomálií (Phi Accrual)

KQL – Kibana Query Language

Dotazovací jazyk pro filtrování dat z ES v Kibaně. Podporuje: textové vyhledávání, filtrování podle polí, boolean operátory (AND/OR/NOT), rozsahové podmínky (>, <=), zástupné znaky (*), vnořená pole. Nepodporuje: regulární výrazy, fuzzy vyhledávání.

📋 Shrnutí okruhu 4

Spark = in-memory distribuovaný výpočetní framework; batch + streaming + ML + SQL v jednom
Lazy Evaluation + DAG = Spark builduje optimalizovaný plán; vykoná ho až při Akci
RDD (nízkoúrovňové, flexibilní) → DataFrame/Dataset (SQL-like, optimalizované Catalyst optimizérem)
Wide vs Narrow transformace: Wide (join, groupBy) způsobuje Shuffle = Stage boundary
Elastic Stack: Beats → (Logstash) → Elasticsearch → Kibana; distribuovaný search engine s inverzním indexem a NRT vyhledáváním

🎓 Kontrolní otázky a odpovědi:

❓ Vysvětlete princip Lazy Evaluation v Apache Spark a proč je výhodná.

Lazy evaluation znamená, že Spark nevykonává transformace okamžitě při jejich definici, ale buduje DAG (Directed Acyclic Graph) plánu výpočtu. Výpočet se spouští až při volání Akce (collect, count, save). Výhody: (1) Catalyst optimizér může zoptimalizovat celý plán před spuštěním (sloučit filtrování, eliminovat zbytečné výpočty), (2) Spark může přeskočit výpočet dat, která nakonec nejsou potřeba, (3) umožňuje pipelinování narrow transformací bez mezilehlého zápisu.

❓ Co je RDD, co znamenají jednotlivá písmena a jaké jsou jeho klíčové vlastnosti?

R = Resilient (odolný – při výpadku se dopočítá z lineage), D = Distributed (data rozdělena na partitions přes cluster), D = Dataset (kolekce objektů). Klíčové vlastnosti: Immutable (nelze měnit, jen transformovat na nové RDD), In-memory (data v RAM pro rychlý přístup), Lazy (transformace se nespouštějí okamžitě). Pokud uzel vypadne, Spark rekonstruuje ztracené partitions přehráním transformací z lineage (záznamu jak RDD vzniklo).

❓ Vysvětlete rozdíl mezi narrow a wide transformacemi ve Sparku.

Narrow transformace (map, filter, flatMap) potřebují data pouze z jedné partition – mohou být provedeny lokálně bez přesunu dat přes síť. Spark je může "slepit" do jedné Stage. Wide transformace (reduceByKey, groupByKey, join, repartition) potřebují data z více partitions → způsobují Shuffle (přesun dat přes síť). Shuffle je drahá operace a vytváří hranici Stage. Minimalizace wide transformací (a tím Shuffle) je klíčová pro výkon Spark aplikací.

❓ Jak funguje indexace dat v Elasticsearch a co je invertovaný index?

Při indexaci dokument prochází analyzérem: (1) Char filters (čištění textu), (2) Tokenizer (dělení na tokeny/slova), (3) Token filters (lowercase, stop words, stemming). Tokeny jsou uloženy do invertovaného indexu – datová struktura mapující každý token na seznam dokumentů, které ho obsahují (opak běžného indexu "dokument → slova"). Tato struktura umožňuje extrémně rychlé fulltextové vyhledávání. Near real-time = nové dokumenty jsou viditelné po refresh (výchozí každou sekundu).

❓ Popište architekturu Elastic Stack (ELK) a tok dat skrze systém.

Data tokují: Zdroje (servery, aplikace, IoT) → Beats (odlehčení agenti pro sběr dat z konkrétních zdrojů) → Logstash (centrální zpracování: Input plugin přijme data, Filter plugins transformují/normalizují, Output plugin pošle do ES) → Elasticsearch (indexuje a ukládá data v distribuovaném clusteru) → Kibana (webové UI pro vizualizaci, dashboardy, detekci anomálií pomocí ML). Beats mohou posílat data přímo do ES bez Logstash pro jednoduché případy.