Az elosztott számítástechnika és a big data piaca szerint , évente 18-19%-kal nő. Ez azt jelenti, hogy a szoftverek e célokra történő kiválasztásának kérdése továbbra is aktuális. Ebben a bejegyzésben azzal kezdjük, hogy miért van szükségünk az elosztott számítástechnikára, részletesebben kitérünk a szoftver kiválasztására, szó lesz a Hadoop Cloudera-val való használatáról, végül pedig a hardver kiválasztásáról és a teljesítményre gyakorolt hatásáról. különböző módon.
Miért van szükségünk elosztott számítástechnikára a hétköznapi üzleti életben? Minden egyszerű és bonyolult egyszerre. Egyszerű – mert a legtöbb esetben viszonylag egyszerű számításokat végzünk információegységenként. Nehéz – mert sok ilyen információ van. Sok. Ennek következtében az embernek muszáj . Így a felhasználási esetek meglehetősen univerzálisak: a számítások mindenhol alkalmazhatók, ahol nagyszámú mérőszámot kell figyelembe venni egy még nagyobb adattömbön.
Egy friss példa: Dodo Pizza A vevői rendelési bázis elemzése alapján megállapítható, hogy a tetszőleges feltétekkel ellátott pizza kiválasztásakor a felhasználók általában csak hat alapvető hozzávalókészlettel plusz néhány véletlenszerű hozzávalóval operálnak. Ennek megfelelően a pizzéria korrigálta a vásárlásokat. Ezenkívül a rendelési szakaszban felkínált további termékeket jobban tudta ajánlani a felhasználóknak, ami növelte a profitot.
Még egy példa: Az árucikk lehetővé tette a H&M számára, hogy 40%-kal csökkentse a választékot az egyes üzletekben, miközben megtartotta az eladások szintjét. Ezt a rosszul értékesített pozíciók kizárásával érték el, és a számításoknál figyelembe vették a szezonalitást.
Szerszám kiválasztása
Az ilyen típusú számítástechnika iparági szabványa a Hadoop. Miért? Mert a Hadoop egy kiváló, jól dokumentált keretrendszer (ugyanaz a Habr sok részletes cikket közöl erről a témáról), amelyhez segédprogramok és könyvtárak egész sora társul. Bemenetként hatalmas mennyiségű strukturált és strukturálatlan adatot is beküldhet, és a rendszer maga osztja el ezeket a számítási teljesítmény között. Ezenkívül ugyanezek a kapacitások bármikor növelhetők vagy letilthatók – ugyanaz a vízszintes skálázhatóság működés közben.
2017-ben a befolyásos tanácsadó cég, a Gartner hogy a Hadoop hamarosan elavulttá válik. Az ok meglehetősen banális: az elemzők úgy vélik, hogy a cégek tömegesen migrálnak a felhőbe, hiszen ott a számítási teljesítmény felhasználása alapján tudnak majd fizetni. A második fontos tényező, amely állítólag képes "eltemetni" a Hadoopot, a munka sebessége. Mert az olyan lehetőségek, mint az Apache Spark vagy a Google Cloud DataFlow, gyorsabbak, mint a Hadoop mögöttes MapReduce.
A Hadoop több pilléren nyugszik, amelyek közül a legfigyelemreméltóbb a MapReduce technológiák (a számítások szerverek közötti adatelosztására szolgáló rendszer) és a HDFS fájlrendszer. Ez utóbbi kifejezetten a fürtcsomópontok között elosztott információk tárolására szolgál: minden fix méretű blokk több csomóponton is elhelyezhető, és a replikációnak köszönhetően a rendszer ellenáll az egyes csomópontok meghibásodásának. A fájltábla helyett egy speciális, NameNode nevű szervert használnak.
Az alábbi ábra a MapReduce működését mutatja be. Az első szakaszban az adatokat egy adott attribútum szerint osztják fel, a második szakaszban számítási teljesítmény alapján osztják el, a harmadik szakaszban a számítás történik.
A MapReduce-t eredetileg a Google hozta létre a keresési szükségletekre. Ezután a MapReduce ingyenes kódba ment, és az Apache átvette a projektet. Nos, a Google fokozatosan átállt más megoldásokra. Érdekes nüansz: pillanatnyilag a Google-nak van egy Google Cloud Dataflow nevű projektje, amely a Hadoop után következő lépésként pozicionálható, ennek gyors pótlásaként.
Közelebbről szemlélve látható, hogy a Google Cloud Dataflow az Apache Beam egy változatán alapul, míg az Apache Beam tartalmazza a jól dokumentált Apache Spark keretrendszert, aminek köszönhetően szinte azonos sebességű megoldás-végrehajtásról beszélhetünk. Nos, az Apache Spark jól működik a HDFS fájlrendszeren, amely lehetővé teszi a telepítést a Hadoop szervereken.
Adja hozzá a Hadoop és a Spark a Google Cloud Dataflow elleni dokumentációjának és kész megoldásainak mennyiségét, és nyilvánvalóvá válik az eszköz kiválasztása. Sőt, a mérnökök maguk dönthetik el, melyik kódot – Hadoop vagy Spark alatt – hajtsák végre, a feladatra, a tapasztalatra és a képesítésekre összpontosítva.
Felhő vagy helyi szerver
A felhőre való általános átállás tendenciája még egy olyan érdekes kifejezést is eredményezett, mint a Hadoop-as-a-service. Ebben az esetben a csatlakoztatott szerverek adminisztrációja nagyon fontossá vált. Mert sajnos népszerűsége ellenére a tiszta Hadoop meglehetősen nehezen konfigurálható eszköz, mivel sokat kell kézzel csinálni. Például egyenként konfigurálhatja a szervereket, figyelheti teljesítményüket, és számos paramétert finomhangolhat. Általánosságban elmondható, hogy amatőrnek dolgozz, és nagy esély van arra, hogy valahol elrontsd, vagy kihagyj valamit.
Ezért nagyon népszerűvé váltak a különféle disztribúciók, amelyeket kezdetben kényelmes telepítési és adminisztrációs eszközökkel szereltek fel. Az egyik legnépszerűbb disztribúció, amely támogatja a Sparkot és megkönnyíti a dolgokat, a Cloudera. Fizetős és ingyenes verziója is van - az utóbbiban pedig az összes fő funkció elérhető, és a csomópontok számának korlátozása nélkül.
A beállítás során a Cloudera Manager SSH-n keresztül csatlakozik a szerverekhez. Egy érdekesség: telepítéskor érdemesebb megadni, hogy azt az ún csomagokat: speciális csomagok, amelyek mindegyike tartalmazza az összes szükséges összetevőt úgy, hogy együttműködjenek egymással. Valójában ez a csomagkezelő továbbfejlesztett változata.
Telepítés után kapunk egy fürt felügyeleti konzolt, ahol láthatjuk a fürtök telemetriáját, a telepített szolgáltatásokat, valamint hozzáadhatunk/eltávolíthatunk erőforrásokat és szerkeszthetjük a fürt konfigurációját.
Ennek eredményeként a rakéta vágása megjelenik előtted, ami a BigData fényes jövőjébe visz. De mielőtt azt mondanánk, hogy "gyerünk", ugorjunk előre a motorháztető alatt.
hardverkövetelmények
Weboldalukon a Cloudera különböző lehetséges konfigurációkat említ. Az általános elvek, amelyek alapján épülnek, az ábrán láthatók:
A MapReduce elmoshatja ezt az optimista képet. Ha újra megnézzük az előző szakasz diagramját, világossá válik, hogy szinte minden esetben egy MapReduce-feladat szűk keresztmetszetet találhat az adatok lemezről vagy hálózatról történő olvasásakor. Ezt a Cloudera blog is megjegyzi. Ennek eredményeként bármilyen gyors számításhoz, beleértve a valós idejű számításokhoz gyakran használt Sparkot is, az I / O sebesség nagyon fontos. Ezért a Hadoop használatakor nagyon fontos, hogy kiegyensúlyozott és gyors gépek kerüljenek a klaszterbe, ami finoman szólva sem mindig biztosított a felhő infrastruktúrájában.
A terheléselosztás egyensúlya az Openstack virtualizáció használatával érhető el a nagy teljesítményű többmagos CPU-kkal rendelkező szervereken. Az adatcsomópontokhoz saját processzorerőforrásokat és bizonyos lemezeket osztanak ki. A mi megoldásunkban Atos Codex Data Lake Engine széles körű virtualizációt érünk el, ezért nyerünk mind a teljesítmény (a hálózati infrastruktúra hatása minimális), mind a TCO (kiesnek a plusz fizikai szerverek) terén.
A BullSequana S200 szerverek használata esetén nagyon egyenletes terhelést kapunk, néhány szűk keresztmetszettől mentesen. A minimális konfiguráció 3 BullSequana S200 szervert tartalmaz, mindegyik két JBOD-val, valamint további négy adatcsomópontot tartalmazó S200-as opcionálisan csatlakoztatható. Íme egy példa a terhelésre egy TeraGen tesztben:
A különböző adatmennyiséggel és replikációs értékekkel végzett tesztek ugyanazokat az eredményeket mutatják a fürtcsomópontok közötti terheléseloszlás tekintetében. Az alábbiakban a lemezelérés teljesítménytesztek szerinti megoszlásának grafikonja látható.
A számítások legalább 3 BullSequana S200 szerver konfigurációján alapulnak. Tartalmaz 9 adatcsomópontot és 3 fő csomópontot, valamint fenntartott virtuális gépeket az OpenStack virtualizáción alapuló védelem telepítése esetén. TeraSort teszt eredménye: 512 MB blokkméret hármas replikációs faktor titkosítással 23,1 perc.
Hogyan bővíthető a rendszer? Különféle típusú bővítmények állnak rendelkezésre a Data Lake Engine-hez:
- Adatcsomópontok: minden 40 TB felhasználható területre
- Analitikai csomópontok GPU telepítésének lehetőségével
- Egyéb lehetőségek az üzleti igényektől függően (például ha Kafkára és hasonlókra van szüksége)
Az Atos Codex Data Lake Engine komplexum magában foglalja mind a szervereket, mind az előre telepített szoftvereket, beleértve a Cloudera készletet licenccel; Maga a Hadoop, OpenStack a RedHat Enterprise Linux kernelen alapuló virtuális gépekkel, adatreplikációs és biztonsági mentési rendszerek (beleértve a biztonsági mentési csomópont és a Cloudera BDR – Biztonsági mentés és katasztrófa-helyreállítás) használatát. Az Atos Codex Data Lake Engine az első virtualizációs megoldás, amely tanúsítvánnyal rendelkezik .
Ha érdekelnek a részletek, kommentben szívesen válaszolunk kérdéseinkre.
Forrás: will.com