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