BIG DATA

Kazi Sándor

Bevezetés, HDFS

BIG DATA

2014.

Big Data „definíció” – szótáriDefiníció

„Nincs”Több is van

Oxford dictionary:„data sets that are too large and complex to manipulate or interrogate with standard methods or tools”

O’Reilly definíció (M. Loukides):„As storage capacity continues to expand, today’s “big” is certainly tomorrow’s “medium” and next week’s “small.” The most meaningful definition I’ve heard: “big data” is when the size of the data itself becomes part of the problem.”

Big Data „definíció” – 3VGartner definíció (D. Laney):

„Big data are high volume, high velocity, and/or high variety information assets that require new forms of processing to enable enhanced decision making, insight discovery and process optimization.”

A fenti definíciót szokás 3V-nek is nevezni:Volume – méretVelocity – adatsebességVariety – egyre többféle típusú adat

Veracity – igazságtartalom, tisztaságValidity – helyességVariability – egyre rugalmasabb struktúrákValue – nagy értékűVisualisation – vizualizálhatóság

Big Data – gyakorlatiasabbanMéret

50-100 GB alatt nem számít az adat „Big Data”-nak, mert egy nagy memóriával rendelkező felhő szolgáltatással ezek az adatok még nagyon jól kezelhetők

3VA konkrét felhasználásból (lényegében a V-kből) következtetünk, hogy big data problémával állunk-e szemben

EszközökA legfontosabb, hogy tudjuk-e az aktuális eszköztárunkkal jól kezelni az adatokat (ha igen, akkor nincs szükség ilyesmire)

„data sets that are too large and complex to manipulate or interrogate with standard methods or tools”

CAP-tételElosztott rendszerekben az alábbi tényezőkből maximum kettő garantálható egyszerre:C: Consistency/Konzisztencia

Adott időpillanatban minden node ugyanazt „ismeri”A: Availability/Rendelkezésreállás

Minden kérdésre érkezik válasz (folyamatos üzemidő)P: Partition-tolerance/Partícionálás-tűrés

A rendszer képes kezelni a hibákat (…)

CA: relációs adatbázisok (Oracle, MySQL, …)CP: HBase, BigTable, MongoDB, RedisAP: Cassandra, Amazon DynamoDB, Voldemort

C

A

P

SP

OF-

land

Eventually

consistent

Sorry, we’re closed

„We believe that more than half of the world’s data will be stored in Apache Hadoop by 2016”/Hortonworks, 2012./

Hadoop – alaptételekAdatközpontú

„A feladatot/számítást könnyebb szállítani, mint az adatot!”

HibatűrőLesznek hardver hibák, kezelni kell

MagasszintűA usernek ne kelljen a végrehajtás részleteivel foglalkozni

StreamingKell legyen streaming adathozzáférés

Egyszerű koherencia-modellWORM: Write-Once-Read-Many

Hadoop – mi nem és mi igen?NEM

Nem egy szoftverNem egy adatbázisNem SQL for Big Data

Eszközök, könyvtárak és módszerek egy keretrendszere (framework):Open Source (ASL)Jól skálázódóAutomatikus replikációAlkalmazás szintű hibatűrésHétköznapi hardveren (commodity hardware) vagy felhőben

Felhasználók és Fejlesztők

Hadoop – MotivációEmlékezzünk vissza a Big Data „definíciókra”

Lényegében a motivációt fogalmazták meg

Elosztott rendszerekre tervezünkMeghibásodások kezelése

• Akár hálózati hibák, vagy teljes gépek kiesése isSPOF (el)kerülésére

• Már amennyire ez lehetségesAdatsebesség növelésére

1TB felolvasása HDD-ről 60-120MB/s sebességgel 2,5-5 óra1TB felolvasása SSD-ről 300-600MB/s sebességgel 0,5-1 óra

Skálázhatóság biztosításaNem csak CPU alapon

Hadoop – Csomagok (stack)

Adattárolás, erőforrások, biztonság

Import/Export interfészek

Eszközök

Menedzsment




Hadoop Distributed FileSystemElosztott fájlrendszer

HDFS


MRv2 MapReduce interfész A továbbiakban ismertetett eszközök egy része épít rá, egy része nem

Yet Another Resource Negotiator YARN = fonálgombolyag „a MapReduce 2.0 elosztott operációs rendszere” Erőforráskezelő

HDFS

MRv2YARN

Adattárolás, erőforrások, biztonságHDFS

MRv2YARN

Mahout: ejtsd: „máháut” Skálázható gépi tanulási programkönyvtár biztosítását célozza meg Több implementált algoritmus Nem mindent triviális, és nem mindent lehet egyáltalán implementálni


Knox REST API gateway Authentikáció, authorizáció, audit, SSO (Single-Sign-On)

Sentry Jogosultságkezelés

Szerep-alapú (role based)

HDFS

MRv2YARN



HDFS

MRv2YARN

Hadoop adat interfészek



HDFS

MRv2YARN

Sqoop SQL adatbázisok interfésze

Avro Szerializáció (objektum import/export)

Falcon Folyamat-életciklus menedzsment, adatáramlás-vezérlés,

adatfeldolgozás



Flume, Chukwa, Scribe Loggyűjtés és aggregálás Adatgyűjtő és monitorozó rendszer elosztott rendszerekhez (Chukwa) Streaming logfeldolgozás A Scribe inkább push jellegű, a többi inkább pull

HDFS

MRv2YARN



Eszközök

HDFS

MRv2YARN

Elemzés és adathozzáférés



Eszközök

Cascading Alkalmazás platform (JAVA réteg a MapReduce fölött)

Scalding Scala API a Cascadinghez

HDFS

MRv2YARN



Eszközök

HBase: Ejtsd: „édzsbéz” Elosztott oszlopstrukturált és tömörített adatbázis (noSQL) Gyors aggregálhatóság, real-time írás/olvasás nagyméretű adatok felett

TEZ Több Map és Reduce művelet tetszőleges sorrendben Cascading support

HDFS

MRv2YARN



Eszközök

Hive: Adattárház Hadoop-kompatibilis fájlrendszerek felett Adatösszegzés, ad-hoc lekérdezések és nagy adathalmazok

analízisének támogatása Saját SQL-szerű lekérdező nyelv: HiveQL MapReduce támogatás (ha a HiveQL nem lenne hatékony)

HDFS

MRv2YARN



Eszközök

Pig: Mert a disznó gyakorlatilag bármit megeszik Platform nagyméretű adatok analízisére Saját magasszintű nyelv: Pig Latin Jól párhuzamosítható („… embarrassingly parallel…”)

HDFS

MRv2YARN



Eszközök

Storm Streaming feldolgozás

Spark Elosztott adatelemzés a memóriában

Shark „Hive a memóriában”

HDFS

MRv2YARN



Eszközök

Hama Apache BSP

Bulk Synchronous Parallel paradigma Graph Library hálózatelemzéshez

HDFS

MRv2YARN



Eszközök

Drill SQL alapú elosztott lekérdező interaktív elemzésekhez

Accumulo Key-value adatbázis (noSQL)

HDFS

MRv2YARN



Eszközök

Lucene Szövegelemzési, természetes nyelv feldolgozási eszközök indexelő és

kereső szolgáltatáshoz

Solr Keresőplatform a Lucene fölé

HDFS

MRv2YARN



Eszközök

Menedzsment

HDFS

MRv2YARN

Menedzsment eszközök



Eszközök

Menedzsment

Oozie Hadoop workflow ütemezés

Zookeeper elosztott rendszer koordináció (Curator: ZooKeeper library-k)

Ambari Hadoop cluster monitoring és menedzsment

HDFS

MRv2YARN



Eszközök

Menedzsment

Apache Software Foundation Open-source technológiák

Sok esetben cégektől kerültek ASL alá Scribe: Facebook Scalding, Storm: Twitter Tez: Hortonworks

HDFS

MRv2YARN



Eszközök

Menedzsment

Disztribútoroktól is vásárolható Kompatibilitás

Garanciák Support Oktatás

…

HDFS

MRv2YARN

RapidMiner (Studio/Server) Elemző szoftver

Radoop integráció



Eszközök

Menedzsment

HDFS

MRv2YARN



Eszközök

Menedzsment

HDFS

MRv2YARN

• S3: Simple Storage Service• EC2: Elastic Compute Cloud• EMR: Elastic MapReduce• Kinesis: streaming

Cloudera Impala

SQL query engine (Hadoopon)

Apache CassandraOszlop alapú NoSQL adatbázis

Apache GoraPerzisztens adattárolás a

memóriában

Apache Nutch

Elosztott web keresőmotor

Apache Tajo

BigData adattárház támogatás (ETL, stb.)

Adatelemző szoftver

Apache Whirr

Cloud interfész

Monitoring rendszer

Történeti áttekintés

YARN: Yet Another Res…YARN: Hadoop v0.23 óta („Hadoop 2.0”)

„a Hadoop 2.0 operációs rendszere”Elválasztották a feladatkezelést a MapReduce frameworktől

Előtte:JobTracker: Master, feladatelosztás és -felügyeletTaskTracker: Feladatkezelő egy node-nálSlot: TaskTracker egy feldolgozó egysége

YARN óta:ResourceManager: Globális erőforrásfelügyelet (Sched + AsM)NodeManager: Container kezelő egy node-nálContainerApplicationMaster: Master, feladatelosztás és felügyelet

Végrehajtás – MRv1A JobTracker kezeli az erő-források elosztását is

Végrehajtás – YARN1. Submit2. AM Start3. Checkin4. Res-Req5. Start6. Heartbeat7. State8. Finish

Ütemezés és KvótákÜtemezés

– FIFO: ez volt a legelterjedtebb eleinte MR esetében• kis slot igényű feladatnak is sokszor várni kellett

– Fair Scheduler• Idővel átlagosan ugyannyi erőforrást kap mindenki• Pool-okra osztja a jobokat és ezeknek oszt erőforrást

Kvóták– Ha a HDFS-en „elfogy” a hely

• Tipikusan egy-két nagy fájl miatt– Pl.: fájlok join-olásából keletkezve

– Két típus, részfára lehet definiálni:• Name quota: metaadat bejegyzések max. száma• Space quota: nomen est omen

Meghibásodások kezeléseHa egy taszk elhal, újraindítjuk (JT, AM)

– Elhal = nem jön HeartBeat, vagy hibát jelez– Nem tudjuk, miért halt el, ezért kell max. restart szám

• Lehet, hogy a programkód rossz

Spekulatív indítás is lehet:– Több helyen is elindítunk egy taszkot, a leggyorsabb nyer– Egyetlen lassú node kevésbé akasztja meg a dolgokat– Akkor jó, ha van szabad erőforrás

Ha elhal a JT/AM:– Amikor újraindul, minden taszk elölről kezdődik– Van HA megoldás: több JT/AM

• Probléma: konzisztencia közöttük

HDFS – alapokCélok / Elvárások / Alapelvek:

– Hibatűrés (és gyors elhárítás) (automatikus replikáció)– Streaming data – adatfolyam hozzáférés– Nagy adathalmazok– Egyszerű koherencia – WORM (write-once-read-many)– A számítást olcsóbb szállítani (mint az adatot)– Hordozhatóság (heterogén hardver)

Blokkalapú fájlrendszer– Tipikusan 64-256MB egy blokk– Általában jobb a „több átlagos” diszk, mint „pár extrém nagy”

Többféle szerver szerep:– Namenode– Datanode– Secondary Namenode

HDFS – NamenodeMetaadat tároló:

– Ő felel az fsimage (namespace image) tárolásáért:• A HDFS könyvtárstruktúra utolsó checkpointja

– Az fsimage nem közvetlenül íródik• Edit log: logfile írása append jelleggel

Namenode induláskor:1. fsimage felolvasása2. A logok alapján az fsimage módosítása3. Új fsimage checkpoint kiírása

SPOFHa leáll, felhasználói beavatkozás szükséges…Sok kicsi fájl esetén sequence file vagy map file…

HDFS – Datanode és SNNDatanode

– Adattároló node (blokkokat kap)• Metadat nélkül a blokkok kvázi „elvesztek”

– A replikáció klaszter szintű (default RF: 3)• Nincs szükség lokálisan RAID-re

– Időközönként jelentik a NN-nak, mi van náluk• Heartbeat

Secondary Namenode– „félreérthető elnevezés”: nem failover / HA node– Időközönként beszerkeszti az fsimage-be a logfile tartalmát

• Gyorsabb Namenode indulás

HDFS – Namenode++SPOF elkerülésére megoldás:

– Lokálisan RAID– Metaadat (fsimage + edit log) több helyen is tárolva– Egyszerre egy namenode aktív, a többi passzív– Plusz teher: Namenode konzisztencia fenntartása

Lassú indulás lehetséges okai:– Nagyra nőtt logfile

• Secondary Namenode probléma– Lassú diszk

• egy lassú diszk is elég lehet, hogy a teljes folyamat lassuljon– Redundáns tárhely bottleneck

• mindenhová kiírjuk az fsimage-et, párhuzamosan, egy is lassít

HDFS – Olvasás• A kliensek közvetlenül elérik a Datanode-okat érik el

HDFS – Írás• A replikációt már nem a kliens, hanem a Namenode indukálja

TervezésKlaszter méretezés, Node méretezés, példa

Tervezés – per nodeSlave node-ok:

– DataNode, TaskTracker/NodeManager, HBase RegionServer, …Master node-ok:

– Namenode– JobTracker/ResourceManager

• Elég egy slave node extra RAM-mal• Ha „master node”-ot kapnak, az segítheti a NN migrációt

(hibánál)Általánosságban:

– Lehetőleg maradjon üres memória-slot (bővíthetőség)– Érdemes „középkategóriából” választani

• Olcsóbb is, mint a top processzorok• Áramfelvétel általában optimálisabb

– Master gépeknél érdemes lehet redundáns PSU-t alkalmazni

Tervezés – architektúraHortonworks: Cluster Planning Guide link• Négyféle workload pattern

– Balanced: Kiegyenlített CPU és diszk kihasználtság– Compute Intensive: Inkább több/erősebb CPU kell– I/O intensive: Inkább több diszk kell– Unknown or evolving workload patterns

• Javaslat: balanced, vagy kis pilot után döntés• Per node: Slave illetve Master szerep

– Hálózat: „változó”

Szerep CPU Memória Diszk RAID, NAS

Slave 4-8 mag 24-48 GB 8-12 x 2-3 TB Nem

Master 16-24 mag 48-64 GB 4-8 x 1 TB Igen (+diszk)

http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.1.2-Win/bk_cluster-planning-guide/content/index.html

Tervezés – példaTegyük fel, hogy egy cég át szeretne térni Hadoop cluster-es szerverparkra, amelyen naponta 90GB új bejövő adatot szeretnének tárolni, mindig az utóbbi egy évre nézve.RF = 3, egy gép: 8-12 x 2-3TB

Adatmennyiség tárolásakb. 33TB, replikációval kb. 100TB

Egyéb tárolásra és elemzésekre +25%kb. 125TB

OS és Hadoop logok +10%kb. 140TB

Ezek alapján4-10 Datanode-ra van szükségünk gépkonfigurációtól függően.Ha ezt sokalljuk, logokról lévén szó, csökkenthetjük…

Tömörítés – HDFSDiszk (fájl szintű tömörítés)

1. gzip• Az egészet ki kell csomagolni, hogy egy szeletet megkapjunk

– MR jobnál a Map-hoz minden blokkot el kell juttatni

2. bzip2• Bárhol elkezdve értelmesen kicsomagolható• Lassú, és nem annyira hatékonyan tömörít, mint a gzip

– Nem nagyon használják

3. lzo• A gzip-hez hasonlít, de metaadat fájl segítségével elérhető, hogy ne

kelljen az összes szelet

Adattovábbítás:– Tipikusan Snappy tömörítéssel

• Nagyon kis overhead, stream tömörítés is• 20-30% teljesítménynyereség is lehet általa