Download
dobos l szl komplex rendszerek fizik ja tansz k n.
Skip this Video
Loading SlideShow in 5 Seconds..
BIG DATA a Tudományban PowerPoint Presentation
Download Presentation
BIG DATA a Tudományban

BIG DATA a Tudományban

93 Vues Download Presentation
Télécharger la présentation

BIG DATA a Tudományban

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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

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

  6. Diszkek tárolókapacitása Forrás: Wikipedia GMR: giantmagnetoresistance PMR: perpendicularmagneticrecording PMR technológia GMR technológia

  7. Tudományos adatok • Csillagászat • É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

  9. Adattárházak Optimális hardver

  10. Problémák • Nem nő minden exponenciálisan • 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

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

  12. Diszk = szalag = 

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

  14. GeneAmdahl törvényei • Törvények kiegyensúlyozottrendszerek 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

  15. Amdahl-féle kiegyensúlyozott rendszerek • BlueGene: AIO = 0,013 • Graywulf: AIO = 0,5 • Amdahl: AIO = 1,25

  16. Amdahl-klaszter

  17. ELTÉn levő rendszerek • Regionális Egyetemi Tudásközpont • 3 × Dell PowerEdge 2950, 8 coreXeon, 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 × SupermicroSuperServer 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

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

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

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

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

  22. Adatbázisok tudományos célra

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

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

  25. 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?

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

  27. RDBMS nagy előnyei • Deklaratív programozhatóság • 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

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

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

  30. noSQL

  31. 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 

  32. 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. MySQLCluster, Graywulf stb. • Megoldás: új megközelítésű adatbázisok

  33. 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)

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

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

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

  37. Hadoop Map/Reduce • Elosztott fájlrendszer • Futtatókörnyezet • Map és Reducefü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

  38. Elosztott adatbázisok konzisztenciája

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

  40. 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é

  41. Rendelkezésre állás • Az adatok folyton elérhetőek • 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

  42. Partíció tűrés • Elosztott rendszer • 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

  43. CAP-tétel C • A hárombólegyszerre csakkettő teljesíthető! A P

  44. 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 • basicallyavailable, soft-state, eventuallyconsistent • 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

  45. BASE • BA: Basicallyavailable • 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 • Eventuallyconsistent • Főleg AP rendszer esetében • A változások aszinkron propagálnak (gossip protokollok) • „Egy idő után” konzisztenssé válik • Konzisztencia ablak

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

  47. RDBMS továbbgondolva