1 / 59

BIG DATA a Tudományban

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.

rae-sears
Download Presentation

BIG DATA a Tudományban

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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 • 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

  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

  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

  36. Másodlagos indexek • Alapművelet:adat megtalálása kulcs alapján • Nincsen scan művelet • Kereséshez mindenképp kell index

  37. Hadoop • Elosztott fájlrendszer • Futtatókörnyezet • Map és Reduce függvényt lehet implementálni • Ebből kell összerakni az adatfeldolgozó programot

  38. CAP-tétel elosztott adatbázisokra

  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 • „Egy idő után” konzisztenssé válik • Konzisztencia ablak

  46. Konfliktusok feloldása • Hiba miatt inkonzisztens állapot • Fel kell oldani • Gossip (pletyka) • Paxos

  47. RDBMS újragondolva

More Related