590 likes | 740 Views
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.
E N D
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
Csillagászati adatbázisok mérete PanSTARRS LSST SDSS
Diszkek tárolókapacitása Forrás: Wikipedia GMR: giantmagnetoresistance PMR: perpendicularmagneticrecording PMR technológia GMR technológia
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
Adattárházak Optimális hardver
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
Adattároló egységek • RAM • Gyors • $$$$$ • Diszk • Lassú • $ • SSD • Írás? • $$$
1 TB-os lemez elolvasása • Szekvenciálisan: 4,5 óra • Random módon: 15-150 nap
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
Amdahl-féle kiegyensúlyozott rendszerek • BlueGene: AIO = 0,013 • Graywulf: AIO = 0,5 • Amdahl: AIO = 1,25
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
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ú!
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 • Adatok • RDBMS újításai DW célokra • noSQL
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 • 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
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. MySQLCluster, 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
Másodlagos indexek • Alapművelet:adat megtalálása kulcs alapján • Nincsen scan művelet • Kereséshez mindenképp kell index
Hadoop • Elosztott fájlrendszer • Futtatókörnyezet • Map és Reduce függvényt lehet implementálni • Ebből kell összerakni az adatfeldolgozó programot
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 • 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 • 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ólegyszerre csakkettő 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 • 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
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
Konfliktusok feloldása • Hiba miatt inkonzisztens állapot • Fel kell oldani • Gossip (pletyka) • Paxos