BIG DATA a Tudományban

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

10. Adattárházak Optimális hardver

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

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

13. Diszk = szalag = 

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

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

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

18. Amdahl-klaszter

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

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 • Adatok • RDBMS újításai DW célokra • noSQL

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 • 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. MySQLCluster, 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

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

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

40. CAP-tétel elosztott adatbázisokra

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 • 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 • 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ólegyszerre csakkettő 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 • 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

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

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

50. RDBMS újragondolva