Dobos László Komplex Rendszerek Fizikája Tanszék BIG DATA a Tudományban

Tartalom Adatcunami Adatfeldolgozásra optimalizált hardver Tudományos adatbázisok RDBMS tudományos alkalmazásai noSQL adattárak RDBMS fejlesztési irányok Tömbadatbázisok

Moore-törvény

Exponenciális növekedés Elektronika Detektor-technika Adatmennyiség

Csillagászati adatbázisok mérete SDSS PanSTARRS LSST

Diszkek tárolókapacitása PMR: perpendicular magnetic recording GMR: giant magnetoresistance Forrás: Wikipedia PMR technológia GMR technológia

Tudományos adatok Csillagászat Részecskefizika Biológia Égtérképek: nagy statisztikus minták Adatpontok sok dimenzióban Részecskefizika Tű keresése a szénakazalban Biológia Fehérjehálózatok: gráfanalízis Genetika: mintaillesztés Ökológia: szenzorhálózatok Képadatbázisok (CT, MR, PET stb.) Internet kutatása Szociális hálózatok, hálózattomográfia Geofizika, meteorológia Sokrétegű képek, idősor analízis, turbulens jelenségek, raszter adatok

A negyedik paradigma Kísérlet Elmélet Szimuláció Adat-bányászat

Adattárházak Optimális hardver

Problémák Nem nő minden exponenciálisan Algoritmusok skálázása Adatátvitel sebessége Algoritmusok skálázása Ha nagyobb, mint o(n), akkor az exponenciálisan növekedő adatmennyiség egészére nem lesz lefuttatható Problémák particionálása

Adattároló egységek RAM Diszk SSD Gyors Lassú Írás? $$$$$ $ $$$

Diszk = szalag = 

1 TB-os lemez elolvasása Szekvenciálisan: 4,5 óra Random módon: 15-150 nap

Gene Amdahl törvényei Amdahl-szám: 1 bit IO / s 1 utasítás / s Törvények kiegyensúlyozott rendszerek esetére (1965) Teljes probléma: 1 = P + S Max gyorsulás: a = 1 / (S + P / N) Amdahl-szám: 1 bit IO / s 1 utasítás / s Memória: 1 bájt memória 1 utasítás / s

Amdahl-féle kiegyensúlyozott rendszerek OPS RAM IO Byte/s # of 100 Mb/s disks Disks × RAM # of 1 TB disks Giga 1009 Gigabyte 108 1 1011 Tera 1012 Terabyte 1,000 1014 100 Peta 1015 Petabyte 1000,000 1017 100,000 Exa 1018 Exabyte 1000,000,000 1020 100,000,000 Blue Gene: AIO = 0,013 Graywulf: AIO = 0,5 Amdahl: AIO = 1,25

Amdahl-klaszter

ELTÉn levő rendszerek Regionális Egyetemi Tudásközpont 3 × Dell PowerEdge 2950, 8 core Xeon, 16 GB RAM 6 × Dell MD1000 SAS, összesen kb. 45 TB SQL Server 2008 R2, 3GB/s szekvenciális IO JHU Graywulf rendszer node-jaival azonos Klimatizálás örök probléma „Jim Gray” klaszter az Informatikai karon 4 × Supermicro SuperServer SYS-6036ST-6LR „2 gép egy házban” konfiguráció Összesen 96 mag, 192 GB RAM, 112 TB diszk IO rendszer sebessége még nem ismert

Jim Gray törvényei Scale-out: Az adatfeldolgozás csak masszív párhuzamosítással oldható meg Az számolást kell vinni az adathoz és nem az adatot a számoláshoz

Scale-up Platform skálázása, memória használat

Scale-out (SMP) Algoritmusok párhuzamosítása nehéz

Scale-out (klaszter) Hálózat lassú!

Adatbázisok tudományos célra

Hagyományos eszközök R, matlab, IDL stb. Memória mérete korlátozó tényező Gyenge háttértár kihasználás Adatok fájlokban (sokszor csak TXT) Minimális adatbázis támogatás Ki kell húzni az adatot a feldolgozáshoz

Adatbázis-szerverek RDBMS noSQL Adatok RDBMS újításai DW célokra Sokfajta Legtöbb rendszer random műveletekre Az jöhet szóba, ami batch feldolgozást tud

RDBMS Üzleti célra fejlesztve Tranzakció kezelés és adattárház egyben Tudunk-e profitálni az adattárház funkciókból tudományos céllal? Elegendő-e a relációs adatmodell? Tudományban sokdimenziós adatok Elegendő-e a funkcionalitás? Matek könyvtárak?

OLTP vs. DW Sok kicsi, random művelet Kis késleltetés Szinkron redundancia Nagy vas elegendő Nagy, sok adatot érintő műveletek A gyors válasz annyira nem fontos Aszinkron redundancia elég Egy gépen nem fér el az adat

RDBMS nagy előnyei Deklaratív programozhatóság Készen kapjuk: A szerver optimalizálni tudja a lekérdezést Rengeteg előre megírt fizikai operátor Minden query végrehajtható (kérdés milyen gyorsan) Készen kapjuk: Párhuzamos query futtatás Optimalizált szekvenciális IO Optimalizált memória használat

RDBMS további előnyei Saját kód futtatása a folyamaton belül Nincsen kommunikációs költségtöbblet Matek könyvtárak integrálhatók Speciális indexek implementálhatók Standard API (ODBC, JDBC, OleDB) Széleskörű, üzleti színvonalú támogatás

RDBMS hátrányai A relációs adatmodell gyakran nem elég Tömbök (pl. nagy képek, adatkockák) Gráfok Üzleti szempontok szerint fejlődik Olyan irányba fejlődnek, ahonnan a pénz várható Nem elosztott rendszerek

noSQL

Web 2.0 Keresők, óriásáruházak, közösségi oldalak Dinamikus növekedés A nagy vasak nem bővíthetők a végtelenségig Hatalmas adatmennyiség Kevésbé strukturált adatok Magas rendelkezésre állás Nem baj, ha nem teljesen konzisztens RDBMS 

Elosztott rendszerek Elosztott rendszerekre nagy igény lett 1000+ nódus olcsó szerverekből A nódusok meghibásodás a napi rutin része RDBMS-nél máig megoldatlan a több gépre történő scale-out Fő probléma: elosztott JOIN Próbálkozások vannak, pl. MySQL Cluster, Graywulf stb. Megoldás: új megközelítésű adatbázisok

noSQL adatbázisok Igény elosztott rendszerekre Sürgős fejlesztési kényszer Az RDBMS nagyon bonyolult Legyen egyszerűbb, de elosztott! Min lehet spórolni? Egyszerűsített tranzakciós modell Nincsen ACID Nincsenek scan és join műveletek Imperatív programozás (nincsen optimalizációs logika)

Két fontos terület Nagy mennyiségű adat feldolgozása Rendszeres műveletek Sok adat redukálása Nagy számú felhasználó kiszolgálása Terhelés megosztása Random műveletek Adatok replikálása Adatbiztonsági okokból Terhelésmegosztás miatt

noSQL adatmodellek Key-Value (Redis, MongoDB, Scalien) Value lehet sokféle Dokumentum (bináris, xml stb.) String, lista, hash-tábla stb. BigTable (Google, Hbase, Cassandra) Sorok kulccsal Oszlopcsaládok (előre definiált) Oszlopok (nem előre definiált) Valójában key-value kompozit kulccsal Lehet még gráf, objektum stb.

Másodlagos indexek Alapművelet: adat megtalálása kulcs alapján Nincsen scan művelet Kereséshez mindenképp kell index Indexeket karban kell tartani Erre gyakran „gyári” támogatás is van

Hadoop Map/Reduce Elosztott fájlrendszer Futtatókörnyezet Map és Reduce függvény implementálható Ebből kell összerakni a programot A futtatás az adat kis darabjain történik Map: feldolgozza az adathalmaz egy kis darabját Reduce: összekombinálja két vagy több Map eredményét

Elosztott adatbázisok konzisztenciája

Elosztott adatbázis Adat particionálás (sharding) Vertikális particionálás Kulcs tartományok külön szervereken Funkcionális particionálás Függőleges particionálás Bizonyos oszlopok külön szervereken Redundancia Magas rendelkezésre állás Nem kell külön back-up Terheléselosztás + ezek kombinációi

Konzisztencia Biztonsági mentés helyett replikáció Az adatok több példányban tárolódnak Mi biztosítja, hogy a replikák konzisztensek maradnak? Kell valami replikációs protokoll Általában aszinkron Konzisztencia ablak Mennyi idő után válik a rendszer konzisztenssé

Rendelkezésre állás Az adatok folyton elérhetőek A válasz legyen gyors Több belépési pont Nincsen egyetlen kritikus elem sem Geo-redundancia A válasz legyen gyors Minimális késleltetés Még akkor is, ha a visszaadott adat nem konzisztens

Partíció tűrés Elosztott rendszer Több belépési pont Hálózati kapcsolat (lassú, törékeny) Több belépési pont A rendszer akkor is működőképes marad, ha egyes részei nem látják egymást Elosztott funkcionalitás

CAP-tétel C A háromból egyszerre csak kettő teljesíthető! A P

Tranzakciós modell lazítása ACID elosztott rendszernél nagyon drága (2PC) Hiba esetén nem lehet tranzakciót érvényesíteni Helyette: BASE basically available, soft-state, eventually consistent Eleve olyan rendszert feltételez, ahol vannak hibák A hibákat optimista módon kezeli A tranzakciók hatásai nem egy időben jelennek meg ehhez kellene a kétlépéses érvényesítés üzenet formájában, véges idő alatt terjednek

BASE BA: Basically available Soft-state Eventually consistent Főleg CP rendszer esetében Legalább a rendszer egy része maradjon elérhető Soft-state A változások véges ideig tartó üzenetekkel történnek A rendszer állapota akkor is változhat, ha épp nincsen input Minden adatra lehet egy érvényességi idő Ha ez lejárt, akkor meg kell vizsgálni, hogy konzisztens-e még Eventually consistent Főleg AP rendszer esetében A változások aszinkron propagálnak (gossip protokollok) „Egy idő után” konzisztenssé válik Konzisztencia ablak

Konfliktusok feloldása Hiba miatt inkonzisztens állapot Fel kell oldani Többségi szavazáson múló algoritmusok Pl. Paxos Node-ok quorumokba szerveződve szavaznak Időbélyegzőn alapuló algoritmusok Mindig a legfrissebb adat tekintendő

RDBMS BigTable Hadoop Deklaratív nyelv, optimalizáló  Optimalizált scan Elsődleges kulcs szerinti elérés Indexek szerinti keresés Join műveletek Párhuzamos végrehajtás Egyszerű sharding Tranzakciók ACID BASE Többlépéses tranzakciók Durability back-up/log replikáció Egyszerű load balancing Nem strukturált adat Szabványos API

RDBMS továbbgondolva

RDBMS fejlesztési irányok Elosztott JOIN Ferris wheel (óriáskerék) Column store Tömb adatmodell JIT fordító és vektorizált végrehajtás

Elosztott JOIN JOIN műveletek két tábla között Végrehajtás Lehetnek (részben) több szerveren Végrehajtás Azonosítani, hogy mi hol található meg A JOIN-hoz mindent egy helyre kell másolni Kérdés, hogy ez hogyan optimalizálható Minimális adatmozgatás legyen a hálózaton át Gyakran nem is az RDBMS része, hanem felső réteg

Graywulf Szalay Sándor Johns Hopkins Egyetem, Baltimore ELTE közreműködéssel SQL Server klaszterek tudományos célú felhasználása Load-balancing, probabilistic join, distributed join, array database stb. SkyQuery, turbulencia, stb. DataScope: klaszter DB + GPU integrációval

Ferris Wheel (óriáskerék) Megosztott scan műveletek (table/index) A query-k újrahasznosítják a másik által már elindított scaneket Nem az elején kezdik a scant, hanem „felülnek” a már futó scan műveletekre A tábla végére érve a scan tovább fut elölről

Column store RDMBS hagyományosan sorokat tárol B-fa struktúra, lapok, klaszterezett index stb. OLTP esetében ez az optimális Lap méret tradicionálisan kicsi (8k) Nagy scan műveletekre nem túl optimális Gond: széles táblák, keskeny queryk Felesleges beolvasni egy csomó dolgot Ötlet: tároljuk a táblát oszloponként!

Oszloponkénti tárolás Cél: felesleges oszlopokat ne olvassuk Tárolási modell: oszloponként folytonosan Jó nagy darabokban Minden oszlop azonos sorrendben Nem kell kulcsot tárolni, mint az indexek esetében Így csak egy sorrendben hatékony a keresés Egyes oszlopokat több sorrendben is érdemes tárolni Teljese tábla előállításához további speciális indexek is kellhetnek Könnyebb tömörítés CPU gyors, lemez lassú, így gyorsítható OLTP-re nem jó (beszúrás, törlés drága) Megpatkolható, pl. c-store, vertica

Tömb alapú adatbázisok Elsősorban tudomány célra Tábla helyett array az alap típus Tárolási modell Chunkok: egymáshoz közeli indexű cellák Tetszőleges irányú aggregálás gyors Column-store koncepciók működnek SQL nyelv megfelelő kiegészítésekkel DDL-ben: ARRAY stb. „kernel függvények”: aggregáltak megfelelői

SciDB Első kifejezetten tudományos célú DMAS Data Management and Analytics LSST csillagászati projekthez Array alapú, táblák nincsenek Query nyelv + direktben összeállítható query-plan Laptoptól a szerverklaszterig, felhőkig Minimális tranzakciós támogatás Hiba esetén roll-back lehetséges Külső adatforrások hatékony integrálása Tudományos adatoknál fontos Verziókezelés, provenance információk

JIT fordítás RDBMS előre megírt fizikai operátorok Általában mégis interpretált Projektorok Matematikai kifejezések Ez tömb-adatbázisoknál nem megy Az interpretált részlet a kurzoron belül futna Gépi kódra kell fordítani Valamilyen JIT fordítás kell Problémás, mert natív kód C-ben .NET, Java integráció segíthet Saját speciális assembler/interpreter (monetDB)

Vektorizált végrehajtás Hanyományosan kurzorok GetNextRow függvény Benne sok minden történik Page pool kezelés, projekció stb. Két adatsor között sok más művelet Gond: kiesik az adat a processzor cacheből Ha egyszerre be lehetne húzni sok sort Column-store modell erre ideális Iterátor helyett for ciklus Akár SSE utasítások is

TDK – diploma – PhD témák Csabai István É 5.102 csabai@complex.elte.hu Dobos László É 5.103 dobos@complex.elte.hu Komplex Rendszerek Fizikája Tanszék Asztrofizikai, biológiai, internetes adatbázisok és eszközök fejlesztése Elosztott RDBMS alkalmazások fejlesztése Virtuális Obszervatórium Sokdimenziós adatbázisok