# 9. Spracovanie dát

Základní pojmy a principy datových skladů, datové analytiky a business intelligence. Životní cyklus datového skladu. Analytika velkých dat, jazyky pro realizaci analytický úloh, analytika na úrovni databází. Pokročilé techniky zpracování dat, výkonnostní aspekty zpracování velkých dat. Příklady z praxe pro vše výše uvedené. (PA036, PA220, PA212)

---

## Základné pojmy a princípy dátových skladov, dátové analytiky a business intelligence

**Business intelligence (BI)** je proces analyzovania dát a prezentovania výsledkov (pomocou tabuliek, grafov) pre manažérov vo firme, ktorí využívajú tieto dáta na riadenie procesov.
- Príklad: dáta o predajoch na pobočkách sa analyzujú a pobočky s nízkym obratom sa zrušia, nakoľko sú stratové

BI sa zároveň dá chápať aj ako **sada nástrojov a aplikácií** pre:
- Zber dát
- Nachystanie dát pre uloženie a analýzu
- Vytvorenie a vykonávanie dotazov
- Vytvorenie reportov a dashboards
- Vizualizáciu dát

**Kľúčové problémy**
- Príliš komplexné a nepoužiteľné modely
- Duplikácia dát v rôznych systémoch
- Dáta sú určené na operatívne systémy (účtovníctvo)
- Zlá kvalita údajov****
- Dáta sú premenlivé

**Business Analyst** je človek, ktorý využíva dátový sklad na prehľadávanie informácií.
- Využíva ich na rozhodovanie -> **Decision Support System (DSS)**
- Model musí byť **ľahko zrozumiteľný**
- Dizajn je ovplyvňovaný najmä **dátami, nie aplikáciami**

**Enterprise Data Warehouse** može byť typu:
- OLTP - Online Transaction Processing
- Riadi sa ACID princípmi
- OLAP - Online Analytical Processing
- MOLAP (Multidimensional OLAP)
- ROLAP (Relational OLAP)
- HOLAP (Hybrid OLAP)

**Dátový sklad** (Data Warehouse - DW) je OLAP databáza, ktorá funguje ako centrálny zdroj pravdy pre analýzu a reporting. Dáta v sklade sa nemenia, iba sa k nim pridávajú nové údaje. Zvyčajne obsahuje historické, auditovateľné dáta.
- **OLAP** - jedná sa o databáze pre veľké množstvo analytických dát, nie na transakčné spracovanie
- Zamykanie objektov (riadkov, stĺpcov, tabuliek) nie je v takejto DB potrebné
- Často sa jedná o stĺpcové databázy (**columnar**), optimalizované na selekciu stĺpcov
- Dáta môžu byť denormalizované, NoSQL
- Používame princíp **ETL - Extract, Transform, Load**
- Dáta sa najprv získajú z nejakých neštruktúrovaných dát, potom sa očistia, transformujú sa do stĺpcov a pridajú do datového skladu
- Schémy sú zvyčajne hviezdicové (**star schema**) - máme tzv. **faktové tabuľky** a **tabuľky dimenzií**
- **Fakt** - analytická udalosť, obsahuje čísla, výpočty, hodnoty, ktoré nás analyticky zaujímajú
- **Dimenzia** - v podstate číselník, ktorý sa referencuje vo faktoch pomocou cudzích kľúčov (Time, Person, Store, Product...)
- **Snowflake schéma je antipattern**, dimenzie nemôžu referencovať iné poddimenzie
- Na OLAP sa dá používať RDBMS ako Postgres alebo špecifikované DB (Google BigQuery, Teradata)

**Vlastnosti** DW:
- **Subject-oriented** - týka sa iba jednej udalosti/entity
- **Integrated** - homogenizácia údajov, problém s NULLom
- **Non-volatile** - dáta sa po nahraní nemenia/nevymažú
- **Time-varying** - zmeny sú zaznamenávané, robia sa snapshoty

**Požiadavky** na DW:
- Informácie musia byť jednoducho prístupné
- Informácie musia byť konzistentné
- Informácie sa musia zobrazovať včas
- Informácie musia byť bezpečné
- Databáza musí byť prispôsobená na zmeny
- Používatelia ju musia akceptovať

**Data mart** je menší dátový sklad, ktorý obsahuje zlomkové údaje dané pre špecifické použitie napr. OLAP, Data Mining, Visualization.

**Alternatívne architektúry DW**:
- Samostatné data marts
- Veľa menších databáz
- Nie je jednoznačný zdroj pravdy
- Logické data marts - odporúčané

Typy **faktových tabuliek**:
- **Transaction** (Event) - faktami sú business event napr. predaj, typicky je možné na nich robiť súčty
- **Snapshot** - obsahuje fakty pre každú kombináciu dimezií v nejakom časovom rámci
- Cumulative snapshot - fakt pre každú kombináciu dimenzií v danom časovom rámci, od začiatku až po koniec procesu
- Fact-less - fakt pre jednu udalosť napr. stret so zákazníkom, je iba kombináciou dimenzií, neobsahuje measures
- Aggregate - agreguje niektoré záznamy do jedného
- Consolidated - fakty rovnakej granularity skombinované do jedného napr. predaje skombinované s predpoveďou predaja

Udalosti, ich fakty a dimenzie vieme určiť pomocou **techniky 7W**:
- Who, What, How much (fact), When, Where, Why, How
- Výber faktov závisí na zvolenej granularite

## Životný cyklus dátového skladu

Datový sklad vieme **vybudovať** dvoma spôsobmi:
- **Top-down** approach - tvoríme najprv celý DW a potom DMs
- **Bottom-up** approach
- Tvoríme najprv malé data marts a postupne sa dostávame vyššie
- Veľké výsledky v krátkom čase na rozdiel od Top-down
- Nevyžaduje vysoké náklady

**Životný cyklus** DW má nasledujúce **fázy**:
- Určenie cieľa a plánovanie
- Čo od systému očakávame, aký má byť rozsah dát, odhad ceny, rizík, prioritizácia subjektov (data marts)
- Návrh infraštruktúry
- Voľba vhodných nástrojov a technológií, architektonických riešení
- Návrh a vývoj data marts
- Voľba procesu
- Určenie granularity
- Identifikácia dimenzií
- Identifikácia faktov
- Čistenie dát a ich pridávanie do DW systému
- **ETL (Extract Transform Load)**
- **Extract**
- Získanie dát zo zdrojových databáz
- **Transform**
- Odstránienie duplicít
- Úprava dát aby sa dali vložiť do faktov a dimenzií
- Vyčistiť od nekompletných dát alebo dát s chybami (gramatické chyby, nekonzistencie, NULLs)
- Niekedy je nutné rozdeliť dáta do viacero stĺpcov (napr. meno na krstné a priezvisko)
- Je možné čiastočne automatizovať, ale často je nutné to robiť manuálne
- Zvyčajne máme viacero prostredí, najprv sa dáta vkladajú do Staging DB a potom do Production DB
- Je vhodné robiť ETL proces po menších častiach
- **Load**
- Najprv aktualizujeme dimenzie, aby sme mali prístup k cudzím kľúčom
- Potom pridáme fakty
- Je vhodné vypnúť integritné obmedzenia a po vložení ich zapnúť
- Je vhodné napĺňať po veľkých častiach
- Je možné využiť paralelizáciu
- Rozširovanie a údržba

Proces ETL sa môže vykonávať dvoma spôsobmi:
- **Query-Driven Data Integration**
- Dáta sa integrujú na požiadavku (lazy)
- Nepoužíva sa
- **Warehouse-Driven Data Integration**
- Eager loading - dáta sa nahrávajú vopred
- Dáta sa už nachádzajú v DW pre querying a analýzu
- Výhody - veľmi rýchle
- Nevýhody - duplikácia údajov, nemáme najčerstvejšie dáta
- Používa sa v praxi

**Hodnoty dimenzií** sa môžu počas života DW **zmeniť**.
- Príklad: pobočka obchodu sa presunie pod iný región - nastala zmena v dimenzii Region
- Potrebujeme zabezpečiť, akým spôsobom sa má táto zmena historicky vyhodnotiť
- Definujeme typy **SCD - Slowly Changing Dimension**
- SCD 0 - ignorujeme zmenu, nezaujíma nás ako sa to volá teraz
- SCD 1 - prepíšeme zmenu, nezaujíma nás ako sa to volalo predtým
- SCD 2 - pridáme nový riadok so zmenenou hodnotou, ale zachováme aj pôvodný (iba nový surrogate key)
- SCD 3 - pridáme nový stĺpec (málokedy použijeme)
- SCD 4 - pre časté zmeny použijeme tabuľku histórie (mini-dimenziu)
- SCD 5 - kombinácia SCD 4+1
- SCD 6 - kombinácia SCD 1+2+3
- SCD 7 - dve dimenzie typu SCD 1+2

**Data Cleaning** je proces, ktorý robíme počas kroku **Transform**:
- Dáta z rôznych zdrojov môžu mať rozny formát, naším cieľom je ich formát normalizovať - napr. Gender M/F, male/female, 0/1
- Využívame techniky similarity join, clustering, parsing
- Musíme sa rozhodnúť, ako klasifikovať nulové hodnoty "null values" - zvyčajne ich nechceme stratiť a nahradíme ich za nejaký znak, napr "N/A"

## Analytika veľkých dát (Big Data), jazyky pre realizáciu analytických úloh, analytika na úrovni databáz

Pojem **Big Data** definuje **analytické dáta**, ktoré kvôli svojej **rýchlej** a **kontinuálnej** tvorbe, **veľkému objemu**, či **zložitosti** vyľučujú tradičné spôsoby analytického spracovania.

Veľké dáta majú nasledujúce **vlastnosti**:
- Volume - veľkosť dát sa exponenciálne zvyšuje
- Velocity - dáta tečú rýchlo (z realtime zdrojov)
- Variety - rôzna štruktúra dát
- Veracity - pôvod dát, jednoznačnosť a pravdivosť (vieme jednoznačne určiť, odkiaľ pochádzajú)
- Value - sú dáta pre mňa hodnotné? majú pre mňa nejaký zmysel?
- Real-time processing - dáta sa spracujú v reálnom čase

Na **spracovanie** veľkých dát používame **distribuované DW**, ktoré pracujú na princípe **horizontálneho škálovania**.
- Stĺpcové (Cstore)
- HDFS, MapReduce (Hadoop)
- SW knižnica pre distribuované spracovávanie veľkých datasetov
- Apache Hive - poskytuje DML (UPDATE, DELETE, INDEX), syntax podobná SQL
- Apache Impala - podobné Hive ale má nízku odozvu
- Apache Kylin - používa Hive, ľahko sa integruje do Power BI
- NoSQL (HBase)
- In-Memory (VoltDB)

**MapReduce** je algoritmus, pomocou ktorého najprv prevedieme zoznam dát do key-value párov a potom nad jednotlivými skupinami vykonávame **agregačnú** funkciu. Výhodou je paralelné spracovanie na rôznych výpočetných jednotkách distribuovaného systému. Používa sa pri **batch processingu**.

Na **realizáciu analytických úloh** zvyčajne používame jazyk typu SQL, MapReduce algoritmy alebo špecifické DML jazyky NoSQL databáz (HiveQL). Prípadne môžeme používať **procedurálne jazyky**, ako napríklad PL/pgSQL (Postgres) alebo T-SQL (MSSQL).

V prípade, ak potrebujeme zabezpečiť analytiku dát v reálnom čase, použijeme metódy **stream processingu**.
- Príklad: Apache Storm, Apache Samza
- Zvyčajne sa jedná o vyhodnocovanie nad grafovými štruktúrami

Na **vyhodnocovanie dotazov** nad veľkými dátami využívame **multidimenzionálny model**. **Cieľom** OLAP systému je **multidimenzionálna analýza**. Kocky by mali byť organizované tak, aby boli odpovede na dotazy čo najrýchlejšie.
- Model kocky (cube)
- Skladá sa z buniek
- Typicky majú 4 až 12 dimenzií (hyperkocka)
- Sparse cube = obsahuje málo prázdnych buniek
- Dense cube = obsahuje veľa prázdnych buniek
- Pri vyšších dimenzíach sú viac "sparse"

**Relational OLAP (ROLAP)** využíva klasické relačné databáze (RDBMS), pričom používa hviezdicovú topológiu schémy a SQL dotazovací jazyk.
- Výhody - škáluje, flexibilita
- Nevýhody - veľkosť na disku, pomalšie odpovede na dotazy
- Typy dotazov
- Navigačný dotaz - získa iba jednu dimenziu
- Agregačný dotaz - sumarizuje dáta faktov

**Multidimensional OLAP (MOLAP)** využíva miesto relačných schém multidimenzionálne matice.
- Výhody - rýchle, zaberá menej miesta na disku
- Nevýhody - menej flexibilné, menej otvorený systém
- Implementácie
- MSSQL SSAS
- Oracle OLAP

**Hybrid OLAP (HOLAP)** je kombináciou ROLAP a MOLAP.
- Dáta sú uložené v relačných DB
- Agregácie sú uložené v multidimenzionálnych štruktúrach
- Výhody - škáluje, rýchle
- Nevýhody - zložité

Nad dátami tvoríme dotazy skrz **OLAP operácie**.
- Typické operácie
- Roll up - agregácia naprieč dimenziou (počet produktov v čase pre každú pobočku)
- Drill down - opak agregácie, hlbšia granularita (počet produktov pre každú pobočku za deň)
- Slice and dice - výber konkrétnej hodnoty dimenzie (počet produktov pre každú pobočku v roku 2000)
- Pivot - tvorba kontingenčnej tabuľky s danými kombináciami dimenzií
- Ďalšie operácie
- Aggregate functions
- Ranking and comparing
- Drill across
- Drill through
- Data densification

**Pivoting v ROLAP systéme** slúži na reprezentáciu agregácie prostredníctvom **kontingenčnej tabuľky**.
- Využitie hodnoty ALL (dummy hodnota)
- SQL `GROUP BY` je nedostačujúce pre veľké množstvo Big Data dimenzií (museli by sme použiť `UNION`)
- Používame špeficiké, nové keywords

**Grouping sets**

SELECT dept_name, job_title, COUNT(*) FROM Personnel GROUP BY GROUPING SET (dept_name, job_title);

**Rollup**

SELECT year, brand, SUM(qty) FROM sales GROUP BY ROLLUP (year, brand);

**Cube**

SELECT year, brand, SUM(qty) FROM sales GROUP BY CUBE (year, brand);

**Window functions**
- OVER

SELECT ... AVG(sales) OVER (PARTITION BY region ORDER BY month ASC ROWS 2 PRECEDING) AS SMA3, ... FROM ...

- FIRST_VALUE, LAST_VALUE, NTH_VALUE

SELECT ... FIRST_VALUE(sales) OVER (PARTITION BY channel ORDER BY sales) AS lowest_sales

- LAG, LEAD

SELECT ... LAG(sales, 1) OVER (PARTITION BY channel ORDER BY calendar) AS prev_sales

**Ranking**
- ROW_NUMBER

SELECT SalesOrderID, CustomerID, ROW_NUMBER() OVER (ORDER BY SalesOrderID) as RunningCountFROM Sales WHERE SalesOrderID > 10000 ORDER BY SalesOrderID

- RANK OVER, DENSE RANK OVER

SELECT channel, calendar, TO_CHAR(TRUNC(SUM(amount_sold), -6), '9,999,999') AS sales, RANK() OVER (ORDER BY TRUNC(amount_sold, -6)) DESC) AS rank, DENSE_RANK() OVER (ORDER BY TRUNC(SUM(amount_sold), -6)) DESC) AS dense_rankFROM sales, products
SELECT ... RANK() OVER (PARTITION BY channel ORDER BY SUM(amount_sold) DESC) AS rank_by_channel

- NTILE

SELECT ... NTILE(3) OVER (ORDER BY sales) NT_3 FROM ...

## Pokročilé techniky spracovávania dát, výkonnostné aspekty spracovania veľkých dát

Pre zaistenie rýchlosti sa v OLAP systémoch používa **redundancia** pomocou:
- Materializovaných pohľadov
- Indexov
- Denormalizovaného schéma

Ak sú naše dáta príliš veľké, môžeme ich rozdeliť pomocou **partitioningu**:
- Horizontal - rozdelenie riadkov do viacerých tabuliek
- Vertical - rozdelenie dát po stĺpcoch na viacero tabuliek
- Zvyčajne používame "view" na spájanie a prácu nad nimi
- Výhoda - parallel processing, security, recovery, partitions stored on different disks, each partition can be optimized for performance
- Nevýhoda - slow retrieval across partitions, complexity

Na zabezpečenie **rýchlosti** vo vyhľadávacích dotazoch chceme maximalizovať využitie **indexov**.
- Snažíme sa minimalizovať počet **sekvenčne skenovaných** riadkov (sequential scan)

**Typy** indexov:
- Hash
- B+ Tree - klasický samo-vyvažovací strom používaný v RDBMS, nepoužiteľné na multidimenzionálne dáta
- UB Tree - linearizuje multidimenzionálne dáta pomocou Z-curve
- R Tree - multidimenzionálny index, ale zle škáluje
- R+ Tree
- R* Tree
- X Tree
- **Bitmap Index**
- Tento index je vhodný pre dáta s malým množstvom možných hodnôt (napr. pohlavie, veľkosť oblečenia)
- Má podobný performance ako B+ strom pre read-only data
- Bitmapový index spočíva v kolekcii bitmáp (bitových vektorov), pričom tento vektor obsahuje kombináciu hodnôt 1 a 0 podľa toho, či je daný záznam s tabuľkou prepojený alebo nie
- Veľkost bitmapy závisí na počte záznamov
- Jednoduchá kombinácia AND/OR viacerých bitových máp
- **Range Encoded Bitmap Index**
- Používa sa pre dotazy typu od - do
- Idea: bit je nastavený vo všetkých vektoroch až po určitú hodnotu
- Vyžaduje usporiadanie dát
- Je efektívnejšie riešenie, nakoľko ide o prístup typu: NOT previous AND current
- Čiže nám stačí prečítať iba 2 bitové mapy
- Nevýhoda: priamy prístup vyžaduje tiež 2 čítania
- Príklad: Osoby narodené medzi 3. a 8. mesiacom (vrátane)
- (NOT A1) AND A7

**Bitmapové indexy** by sa mali používať iba ak je **malá selektivita** tj. málo typov možných hodnôt.
- Riadime sa pravidlom max. 1% kardinality
- Príklad: máme tabuľku A s 1,000,000 riadkami a tabuľku B s 10,000 riadkami - kardinalita 1% => oplatí sa použiť bitmapový index miesto B+

Je tiež dôležité **optimalizovať poradie JOIN a WHERE operácií**, práve kvôli kardinalite vzťahov medzi nimi.
- Príklad: je rozdiel, ak spravíme `JOIN (1,000,000 * 10,000)` a potom z toho robíme `WHERE`, než keď spravíme `(WHERE 1,000,000 => 1000) JOIN 10,000`
- Využívame tabuľky dimenzií na to, aby sme náš dotaz čo najviac špecifikovali
- Tabuľky dimenzií môžeme spojiť pomocou `CROSS JOIN` a potom v nich filtrovať

Vo všeobecnosti by sme mali preferovať `CROSS JOIN` **medzi dimenziami** ak ich cudzie kľúče nie sú všetky indexované, a ak sú, tak by sme mali použiť **prienik ich semi-joinov**. Nemali by sme preferovať plány generované RDBMS, nakoľko nie sú optimalizované na OLAP.

Ďaľšou technikou na zvýšenie rýchlosti je použitie **materializovaných pohľadov** (materialized views). Vieme ich pripraviť staticky alebo dynamicky. Musíme taktiež zvoliť, kedy má dochádzať k ich aktualizácii.
- **Staticky** - administrátor musí zvoliť, aké pohľady nám vylepšia rýchlosť dotazov
- **Dynamicky** - robí sa monitoring dotazov a optimalizácia podľa nich