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 (…) CA: relációs adatbázisok (Oracle, MySQL, …) CP: HBase, BigTable, MongoDB, Redis AP: Cassandra, Amazon DynamoDB, Voldemort C A P Eventually consistent SPOF-land 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) Menedzsment Eszközök 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

Adattárolás, erőforrások, biztonság 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ő Adattárolás, erőforrások, biztonság YARN MRv2 HDFS

Adattárolás, erőforrások, biztonság 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 Adattárolás, erőforrások, biztonság YARN MRv2 HDFS

Adattárolás, erőforrások, biztonság Knox REST API gateway Authentikáció, authorizáció, audit, SSO (Single-Sign-On) Sentry Jogosultságkezelés Szerep-alapú (role based) Adattárolás, erőforrások, biztonság YARN MRv2 HDFS

Hadoop adat interfészek Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság 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 Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság 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 Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Elemzés és adathozzáférés Eszközök Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság Import/Export interfészek Cascading Alkalmazás platform (JAVA réteg a MapReduce fölött) Scalding Scala API a Cascadinghez Eszközök Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság 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 Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság 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 Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság 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 Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság 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 Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság Import/Export interfészek Hama Apache BSP Bulk Synchronous Parallel paradigma Graph Library hálózatelemzéshez Eszközök Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság Import/Export interfészek Drill SQL alapú elosztott lekérdező interaktív elemzésekhez Accumulo Key-value adatbázis (noSQL) Eszközök Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság 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 Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság Import/Export interfészek Menedzsment eszközök Menedzsment Eszközök Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság Import/Export interfészek Oozie Hadoop workflow ütemezés Zookeeper elosztott rendszer koordináció (Curator: ZooKeeper library-k) Ambari Hadoop cluster monitoring és menedzsment Menedzsment Eszközök Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság 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 Menedzsment Eszközök Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság Import/Export interfészek Disztribútoroktól is vásárolható Kompatibilitás Garanciák Support Oktatás … Menedzsment Eszközök Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság Import/Export interfészek RapidMiner (Studio/Server) Elemző szoftver Radoop integráció Menedzsment Eszközök Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Adattárolás, erőforrások, biztonság Import/Export interfészek Menedzsment Eszközök Adattárolás, erőforrások, biztonság YARN MRv2 HDFS Import/Export interfészek

Apache Tajo BigData adattárház támogatás (ETL, stb.) S3: Simple Storage Service EC2: Elastic Compute Cloud EMR: Elastic MapReduce Kinesis: streaming Adatelemző szoftver Cloudera Impala SQL query engine (Hadoopon) Apache Whirr Cloud interfész Apache Nutch Elosztott web keresőmotor Monitoring rendszer Apache Gora Perzisztens adattárolás a memóriában Apache Cassandra Oszlop alapú NoSQL adatbázis

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 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: fsimage felolvasása A logok alapján az fsimage módosítása Ú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) gzip bzip2 lzo Az egészet ki kell csomagolni, hogy egy szeletet megkapjunk MR jobnál a Map-hoz minden blokkot el kell juttatni bzip2 Bárhol elkezdve értelmesen kicsomagolható Lassú, és nem annyira hatékonyan tömörít, mint a gzip Nem nagyon használják 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