Netezza – to pravé řešení pro analytický datový sklad – technický pohled na řešení Martin Pavlík 23. Listopadu 2011

MPP architektura – Koncept “Shared Nothing” – Rozdělení práce na několik menších úloh Velká úloha je rozdělena vertikálně do série menších úloh Menší úlohy běží paralelně / naprosto nezávisle Pro každou menší úlohu je přiděleno stejné množství fyzických zdrojů Komunikace mezi jednotlivými úlohami je jen na začátku a konci Přínosy – Obrovské úlohy jsou vykonány ve významně kratším čase – Maximální využitelnost zdrojů Masivní paralelní architektura “Rozděl a panuj”

Massively Parallel Intelligent Storage  Network Fabric SMP Host Front End Netezza TwinFin Appliance High-Speed Loader/Unloader ODBC 3.X JDBC Type 4 OLE-DB SQL/92 Execution Engine SQL Compiler Query Plan Optimize Admin Source Systems Client High Performance Loader 3rd Party Apps DBA CLI ETL Server SOLARIS LINUX HP-UX AIX WINDOWS TRU64 High-Performance Database Engine Streaming joins, aggregations, sorts S-Blade Processor & streaming DB logic S-Blade Processor & streaming DB logic S-Blade Processor & streaming DB logic S-Blade Processor & streaming DB logic

High-Performance Database Engine Streaming joins, aggregations, sorts S-Blade Processor & streaming DB logic S-Blade Processor & streaming DB logic S-Blade Processor & streaming DB logic S-Blade Processor & streaming DB logic Execution Engine Massively Parallel Intelligent Storage  Network Fabric SMP Host Front End Netezza TwinFin Appliance High-Speed Loader/Unloader SQL Compiler Query Plan Optimize Admin SQL Snippets SQL Source Systems Client High Performance Loader 3rd Party Apps DBA CLI ETL Server SOLARIS LINUX HP-UX AIX WINDOWS TRU64

Zpracování toku dat jednotkou S-Blade Jádro (Core) FPGAJádro CPU Dekomprese dat Projekce Selekce, Autorizace Komplexní ∑ Joiny, Aggr, atd. Datová Cache Select sex, age, count(*) From MultiBillionRowTable Where BirthDate < ’01/01/1967’ And PostCode like ’SW%’ Group by sex, age; Každý S-Blade obsahuje 8 n-tic s vlastním: Diskem Datovou cache Jádrem FPGA jednotky Jádrem CPU

High-Performance Database Engine Streaming joins, aggregations, sorts, etc. S-Blade Processor & streaming DB logic S-Blade Processor & streaming DB logic S-Blade Processor & streaming DB logic S-Blade Processor & streaming DB logic Asymmetric Massively Parallel Processing™ Massively Parallel Intelligent Storage  Network Fabric SMP Host Front End Netezza TwinFin Appliance High-Speed Loader/Unloader SQL Compiler Query Plan Optimize Admin Consolidate Execution Engine ODBC 3.X JDBC Type 4 OLE-DB SQL/92 Source Systems Client High Performance Loader 3rd Party Apps DBA CLI ETL Server SOLARIS LINUX HP-UX AIX WINDOWS TRU64

Specifikace IBM Netezza Kapacita (uživatelská data):128 TB Scan rate:144 TB/h Load Speed: 0.5 TB/h Počítáme s kompresním poměrem 1:4

S-Blade / SPU / Snippet Processing Unit

Propojení S-Blades a disků 5 ze 6 S-Blades vlastní 8 disků Každý S-Blade má v sobě: 8 jader CPU 8 jader FPGA => CPU:FPGA:disk je 1:1:1 6. S-Blade vlastní pouze 6 disků 2 jádra CPU a FPGA jsou nevyužitá Protože 2 disky zůstavají volné do zálohy Níže uvedené údaje platí pro half-rack systém IBM Netezza , který má 6 S- Blades

V systému jsou použity 1TB disky – Ty jsou rozděleny na 1/3 Všechna uživatelská data jsou replikována z Primary do Mirror oblasti Výpadek disku je transparentní pro uživatelské dotazy – Na Spare (volný) disk jsou automaticky zreplikovaná data„nemocného“ disku S využitím odpovídajícího disku z páru (jen se otočí Primary a Mirror oblasti) Disk mirroring & řešení výpadku disku

Disky, které patřily „nemocné“ jednotce S-Blade jsou rovnoměrně rozdistribuovány zbývajícím jednotkám S-Blade Read-only dotazy jsou automaticky restartovány Všechny zápisové operace jsou přerušeny, označeny jako aborted a spustí se znovu od místa posledního checkpointu Řešení výpadku jednotky S-Blade

Data jsou na jednotlivé disky (a potažmo tedy i jádra CPU a FPGA) distribuována pomocí hashování dle tzv. distribučního klíče – Rovnoměrná distribuce je základem vysoké výkonnosti Implicitní distribuce je RANDOM Distribuce dat a její dopad na výkonnost

Data jsou na disk ukládána po tzv. extentech – Má velikost 3 MB Pro sloupce tabulek jsou udržovány tzv. zónové mapy – Udržují informace o minimální a maximální hodnotě v daném extentu Využití tzv. zónových map

Jak mohou zónové mapy omezit čtení z disku Cust_ID = 300 Ext 1 Ext 3 Vysoká selektivita je především u tabulek, které jsou setřízené podle atributu z where klauzule

Clustered Based Tables a jejich přínos Jsou řešením pro časté situace, kdy se v … Ve WHERE klauzulích V JOINech … … používá více než 1 atribut Data jsou v tabulce seřazena dle křivky vyplňující Hilbertův prostor 2 atributy 3 atributy 2 hodnoty4 hodnoty 8 hodnot ….

A B C D ZM IZM II A 2 A4 A – B3 – 4* B4 B3 A3 A2 A – B1 – 2** A1 B1 B2 C2 C – D1 – 2* C1 D1 D2 D3 C – D3 – 4 C3 C4 D4 Clustered Base Tables – ilustrační příklad Myšlenka tzv. Clustered base tables je založena na křivce vyplňující hilbertův prostor

Implicitní výkonnost je vysoká Zónové mapyClustered Base Tables Koncepty, které posouvají výkonnost ještě o kus dál Výkonnost systému je extrémně vysoká i bez nich Masivní paralelismus a FPGA Distribuční klíče

sloupce Původní záznam je označen jako smazaný Záznam je INSERTován Do tabulky je vložen nový záznam Záznam je UPDATEován I „změněný“ záznam je označen jako smazaný Záznam je DELETEován Realizace transakcí v Netezze

Děkuji za pozornost