BIG DATA a Tudományban
description
Transcript of BIG DATA a Tudományban
BIG DATA A TUDOMÁNYBAN
Dobos LászlóKomplex Rendszerek Fizikája Tanszék
Tartalom1. Adatcunami2. Adatfeldolgozásra optimalizált hardver3. Tudományos adatbázisok
RDBMS tudományos alkalmazásai4. noSQL adattárak5. RDBMS fejlesztési irányok6. Tömbadatbázisok
Moore-törvény
Exponenciális növekedés
Elektronika Detektor-technika Adatmennyiség
Csillagászati adatbázisok mérete
SDSS PanSTARRS LSST
Diszkek tárolókapacitása
Forr
ás: W
ikip
edia
GM
R: g
iant
mag
neto
resi
stan
ceP
MR
: per
pend
icul
ar m
agne
tic re
cord
ing
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
A negyedik paradigma
Kísérlet
Elmélet
Szimuláció
Adat-bányás
zat
Optimális hardverAdattárházak
Problémák Nem nő minden exponenciálisan
Adatátvitel sebessége
Algoritmusok skálázásaHa 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? $$$
Diszk = szalag =
1 TB-os lemez elolvasása Szekvenciálisan: 4,5 óra Random módon: 15-150 nap
Gene Amdahl törvényei 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ória1 utasítás / s
Amdahl-féle kiegyensúlyozott rendszerek
Blue Gene: AIO = 0,013 Graywulf: AIO = 0,5 Amdahl: AIO = 1,25
OPS RAM IO Byte/s
# of100 Mb/s
disks
Disks ×
RAM# of 1 TB disks
Giga
1009 Gigabyte
108 1 1011 1
Tera 1012 Terabyte
1011 1,000 1014 100
Peta
1015 Petabyte
1014 1000,000 1017 100,000
Exa 1018 Exabyte
1017 1000,000,000
1020 100,000,000
Amdahl-klaszter
ELTÉn levő rendszerek Regionális Egyetemi Tudásközpont
3 × Dell PowerEdge 2950, 8 core Xeon, 16 GB RAM6 × Dell MD1000 SAS, összesen kb. 45 TBSQL Server 2008 R2, 3GB/s szekvenciális IOJHU Graywulf rendszer node-jaival azonosKlimatizálás örök probléma
„Jim Gray” klaszter az Informatikai karon4 × 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
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ú!
Adatbázisok tudományos célra
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ásKi kell húzni az adatot a feldolgozáshoz
Adatbázis-szerverek RDBMS
AdatokRDBMS ú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 adatokElegendő-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éstRengeteg előre megírt fizikai operátorMinden query végrehajtható (kérdés milyen gyorsan)
Készen kapjuk:Párhuzamos query futtatásOptimalizált szekvenciális IOOptimalizá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öbbletMatek könyvtárak integrálhatókSpeciá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ődikOlyan irányba fejlődnek, ahonnan a pénz
várható
Nem elosztott rendszerek
noSQL
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-outFő probléma: elosztott JOINPróbálkozások vannak,
pl. MySQL Cluster, 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 bonyolultLegyen egyszerűbb, de elosztott!
Min lehet spórolni?Egyszerűsített tranzakciós modellNincsen ACIDNincsenek scan és join műveletekImperatív programozás
(nincsen optimalizációs logika)
Két fontos terület Nagy mennyiségű adat feldolgozása
Rendszeres műveletekSok adat redukálása
Nagy számú felhasználó kiszolgálásaTerhelés megosztásaRandom műveletekAdatok 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 kulccsalOszlopcsalá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
CAP-tétel elosztott adatbázisokra
Elosztott adatbázis Adat particionálás (sharding)
Vertikális particionálásKulcs tartományok külön szervereken
Funkcionális particionálásFüggőleges particionálásBizonyos oszlopok külön szervereken
RedundanciaMagas rendelkezésre állásNem kell külön back-upTerhelé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 ablakMennyi idő után válik a rendszer konzisztenssé
Rendelkezésre állás Az adatok folyton elérhetőek
Több belépési pontNincsen egyetlen kritikus elem semGeo-redundancia
A válasz legyen gyorsMinimális késleltetésMé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 pontA 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 A háromból
egyszerre csakkettő teljesíthető!
C
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 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
BASE BA: Basically available
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 „Egy idő után” konzisztenssé válik Konzisztencia ablak
Konfliktusok feloldása Hiba miatt inkonzisztens állapot Fel kell oldani
Gossip (pletyka) Paxos
RDBMS BigTable HadoopDeklaratív nyelv, optimalizáló Optimalizált scan Optimális kulcs szerinti elérés Join műveletek Párhuzamos végrehajtás Klaszterezhetőség Tranzakciók ACID BASERedundancia
Load balancing Nem strukturált adat Szabványos API
RDBMS újragondolva
RDBMS fejlesztési irányok Elosztott JOIN Column store Ferris wheel (óriáskerék) Tömb adatmodell
Elosztott JOIN JOIN műveletek két
Graywulf Szalay Sándor
Johns Hopkins Egyetem, Baltimore ELTE közreműködéssel
SQL Server klaszterek tudományos célú felhasználásaLoad-balancing, probabilistic join, distributed
join, array database stb.SkyQuery, turbulencia, stb.
Column store RDMBS hagyományosan sorokat tárol
B-fa struktúra, lapok, klaszterezett index stb.OLTP esetében ez az optimálisLap méret tradicionálisan kicsi (8k)Nagy scan műveletekre nem túl optimális
Gond: széles táblák, keskeny querykFelesleges beolvasni egy csomó dolgot
Ötlet: tároljuk a táblát oszloponként!
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
Csak egy sorrendben hatékony a keresés Egyes oszlopokat több sorrendben is érdemes tárolni JOIN 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
Ferris wheel
Tömb alapú adatbázisok Elsősorban tudomány célra Tábla helyett array az alap típus
Tárolási modell: chunkok
SciDB