Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

Dobos László Komplex Rendszerek Fizikája Tanszék

Hasonló előadás


Az előadások a következő témára: "Dobos László Komplex Rendszerek Fizikája Tanszék"— Előadás másolata:

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

2 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

3 Moore-törvény

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

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

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

7 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

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

9

10 Adattárházak Optimális hardver

11 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

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

13 Diszk = szalag = 

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

15 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

16 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

17

18 Amdahl-klaszter

19 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

20 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

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

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

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

24 Adatbázisok tudományos célra

25 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

26 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

27 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?

28 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

29 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

30 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

31 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

32 noSQL

33 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 

34 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

35 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)

36 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

37 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.

38 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

39 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

40 Elosztott adatbázisok konzisztenciája

41 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

42 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é

43 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

44 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

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

46 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

47 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

48 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ő

49 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

50 RDBMS továbbgondolva

51 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

52 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

53 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

54 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

55 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!

56

57 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

58 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

59 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

60 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)

61 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

62 TDK – diploma – PhD témák
Csabai István É Dobos László É 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


Letölteni ppt "Dobos László Komplex Rendszerek Fizikája Tanszék"

Hasonló előadás


Google Hirdetések