Transcript Adattárolás, erőforrások, biztonság Import/Export

BIG DATA
Kazi Sándor
Bevezetés, HDFS
2014.
Big Data „definíció” – szótári
Definí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ó” – 3V
Gartner 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éret
Velocity – adatsebesség
Variety – egyre többféle típusú adat
Veracity – igazságtartalom, tisztaság
Validity – helyesség
Variability – egyre rugalmasabb struktúrák
Value – nagy értékű
Visualisation – vizualizálhatóság
Big Data – gyakorlatiasabban
Mé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
3V
A 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ök
A 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étel
Elosztott 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 (…)
A
CA: relációs adatbázisok (Oracle, MySQL, …)
CP: HBase, BigTable, MongoDB, Redis
AP: Cassandra, Amazon DynamoDB, Voldemort
C
P
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ételek
Adatkö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
Streaming
Kell legyen streaming adathozzáférés
Egyszerű koherencia-modell
WORM: Write-Once-Read-Many
Hadoop – mi nem és mi igen?
NEM
Nem egy szoftver
Nem egy adatbázis
Nem 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és
Hé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ünk
Meghibásodások kezelése
• Akár hálózati hibák, vagy teljes gépek kiesése is
SPOF (el)kerülésére
• Már amennyire ez lehetséges
Adatsebesség növelésére
1TB felolvasása HDD-ről 60-120MB/s sebességgel 2,5-5 óra
1TB felolvasása SSD-ről 300-600MB/s sebességgel 0,5-1 óra
Skálázhatóság biztosítása
Nem csak CPU alapon
Hadoop – Csomagok (stack)
Eszközök
Menedzsment
Adattárolás, erőforrások, biztonság
Import/Export interfészek
Adattárolás, erőforrások,
biztonság
Adattárolás, erőforrások, biztonság
Hadoop Distributed FileSystem
Elosztott fájlrendszer
Adattárolás, erőforrások, biztonság
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ő
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
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
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Knox
 REST API gateway
 Authentikáció, authorizáció, audit, SSO (Single-Sign-On)
Sentry
 Jogosultságkezelés
 Szerep-alapú (role based)
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Hadoop adat interfészek
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
Sqoop
 SQL adatbázisok interfésze
Avro
 Szerializáció (objektum import/export)
Falcon
 Folyamat-életciklus menedzsment, adatáramlás-vezérlés,
adatfeldolgozás
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
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
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
Elemzés és adathozzáférés
Eszközök
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
Cascading
 Alkalmazás platform (JAVA réteg a MapReduce fölött)
Scalding
 Scala API a Cascadinghez
Eszközök
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
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
Eszközök
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
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)
Eszközök
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
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…”)
Eszközök
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
Storm
 Streaming feldolgozás
Spark
 Elosztott adatelemzés a memóriában
Shark
 „Hive a memóriában”
Eszközök
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
Hama
 Apache BSP
 Bulk Synchronous Parallel paradigma
 Graph Library hálózatelemzéshez
Eszközök
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
Drill
 SQL alapú elosztott lekérdező interaktív elemzésekhez
Accumulo
 Key-value adatbázis (noSQL)
Eszközök
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
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é
Eszközök
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
Menedzsment eszközök
Eszközök
Menedzsment
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
Oozie
 Hadoop workflow ütemezés
Zookeeper
 elosztott rendszer koordináció (Curator: ZooKeeper library-k)
Ambari
 Hadoop cluster monitoring és menedzsment
Eszközök
Menedzsment
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
Apache Software Foundation
 Open-source technológiák
Sok esetben cégektől kerültek ASL alá
 Scribe: Facebook
 Scalding, Storm: Twitter
 Tez: Hortonworks
Eszközök
Menedzsment
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
Disztribútoroktól is vásárolható
 Kompatibilitás
 Garanciák
 Support
 Oktatás
 …
Eszközök
Menedzsment
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
RapidMiner (Studio/Server)
 Elemző szoftver
Radoop
 integráció
Eszközök
Menedzsment
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
Eszközök
Menedzsment
YARN MRv2
Adattárolás, erőforrások, biztonság
HDFS
Import/Export interfészek
•
•
•
•
S3: Simple Storage Service
EC2: Elastic Compute Cloud
EMR: Elastic MapReduce
Kinesis: streaming
Apache Tajo
BigData adattárház
támogatás (ETL, stb.)
Adatelemző szoftver
Cloudera Impala
SQL query engine (Hadoopon)
Apache Whirr
Cloud interfész
Apache Nutch
Elosztott web keresőmotor
Monitoring rendszer
Apache Cassandra
Oszlop alapú NoSQL adatbázis
Apache Gora
Perzisztens adattárolás a
memóriában
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ügyelet
TaskTracker: Feladatkezelő egy node-nál
Slot: TaskTracker egy feldolgozó egysége
YARN óta:
ResourceManager: Globális erőforrásfelügyelet (Sched + AsM)
NodeManager: Container kezelő egy node-nál
Container
ApplicationMaster: Master, feladatelosztás és felügyelet
Végrehajtás – MRv1
A JobTracker kezeli az erőforrások elosztását is
Végrehajtás – YARN
1.
2.
3.
4.
5.
6.
7.
8.
Submit
AM Start
Checkin
Res-Req
Start
Heartbeat
State
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ése
Ha 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 – alapok
Cé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 – Namenode
Metaadat 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ása
2. A logok alapján az fsimage módosítása
3. Új fsimage checkpoint kiírása
SPOF
Ha leáll, felhasználói beavatkozás szükséges…
Sok kicsi fájl esetén sequence file vagy map file…
HDFS – Datanode és SNN
Datanode
– 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és
Klaszter méretezés, Node méretezés, példa
Tervezés – per node
Slave 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úra
Hortonworks: 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)
Tervezés – példa
Tegyü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ása
kb. 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án
4-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 – HDFS
Diszk (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