Trh pro distribuované výpočty a velká data, podle , roste o 18-19 % ročně. To znamená, že otázka výběru softwaru pro tyto účely zůstává aktuální. V tomto příspěvku začneme tím, proč potřebujeme distribuované výpočty, podrobněji se zastavíme u výběru softwaru, budeme hovořit o použití Hadoop s Cloudera a nakonec si povíme o výběru hardwaru a jak to ovlivňuje výkon. v různých cestách.
Proč potřebujeme distribuované výpočty v běžném podnikání? Vše je jednoduché a složité zároveň. Jednoduché – protože ve většině případů provádíme relativně jednoduché výpočty na jednotku informace. Těžko – protože takových informací je hodně. Tolik. V důsledku toho člověk musí . Případy použití jsou tedy zcela univerzální: výpočty lze použít všude tam, kde je třeba vzít v úvahu velké množství metrik na ještě větším datovém poli.
Jeden nedávný příklad: Dodo Pizza na základě analýzy zákaznické základny vyplývá, že při výběru pizzy s libovolnými polevami uživatelé obvykle operují pouze se šesti základními sadami surovin plus několika náhodnými. Podle toho pizzerie přizpůsobila nákupy. Navíc dokázala uživatelům lépe doporučit další produkty nabízené ve fázi objednávky, což zvýšilo zisky.
Další příklad: zboží umožnilo H&M snížit sortiment v jednotlivých prodejnách o 40 % při zachování úrovně tržeb. Toho bylo dosaženo vyloučením špatně prodejných pozic a při výpočtech byla zohledněna sezónnost.
Výběr nástroje
Průmyslovým standardem pro tento druh výpočetní techniky je Hadoop. Proč? Protože Hadoop je vynikající, dobře zdokumentovaný framework (tentýž Habr vydává mnoho podrobných článků na toto téma), který je doprovázen celou sadou utilit a knihoven. Jako vstup můžete odeslat obrovské sady strukturovaných i nestrukturovaných dat a systém je sám rozdělí mezi výpočetní výkon. Navíc lze tyto stejné kapacity kdykoli zvýšit nebo deaktivovat – stejná horizontální škálovatelnost v akci.
V roce 2017 vlivná poradenská společnost Gartner že Hadoop brzy zastará. Důvod je poměrně banální: analytici se domnívají, že společnosti budou masivně migrovat do cloudu, protože tam budou moci platit na základě využití výpočetního výkonu. Druhým důležitým faktorem údajně schopným „pohřbít“ Hadoop je rychlost práce. Protože možnosti jako Apache Spark nebo Google Cloud DataFlow jsou rychlejší než MapReduce základní Hadoop.
Hadoop spočívá na několika pilířích, z nichž nejpozoruhodnější jsou technologie MapReduce (systém pro distribuci dat pro výpočty mezi servery) a souborový systém HDFS. Ten je speciálně navržen pro ukládání informací distribuovaných mezi uzly clusteru: každý blok pevné velikosti lze umístit na několik uzlů a díky replikaci je systém odolný proti selhání jednotlivých uzlů. Místo tabulky souborů se používá speciální server s názvem NameNode.
Obrázek níže ukazuje, jak MapReduce funguje. V první fázi jsou data rozdělena podle určitého atributu, ve druhé fázi jsou distribuována podle výpočetního výkonu, ve třetí fázi probíhá výpočet.
MapReduce původně vytvořil Google pro potřeby svého vyhledávání. Poté MapReduce přešel do bezplatného kódu a Apache převzal projekt. No a Google postupně migroval na jiná řešení. Zajímavá nuance: v současné době má Google projekt nazvaný Google Cloud Dataflow, který je dalším krokem po Hadoop, jako jeho rychlá náhrada.
Bližší pohled ukazuje, že Google Cloud Dataflow je založen na variantě Apache Beam, zatímco Apache Beam obsahuje dobře zdokumentovaný framework Apache Spark, který nám umožňuje mluvit o téměř stejné rychlosti provádění řešení. Apache Spark funguje dobře na souborovém systému HDFS, což vám umožňuje nasadit jej na servery Hadoop.
Přidejte sem objem dokumentace a hotových řešení pro Hadoop a Spark proti Google Cloud Dataflow a výběr nástroje bude zřejmý. Navíc se inženýři mohou sami rozhodnout, který kód - pod Hadoopem nebo Sparkem - vykonají, se zaměřením na úkol, zkušenosti a kvalifikaci.
Cloud nebo místní server
Trend k obecnému přechodu na cloud dokonce dal vzniknout tak zajímavému pojmu jako Hadoop-as-a-service. V takovém scénáři se velmi důležitá stala správa připojených serverů. Protože, bohužel, navzdory své popularitě je čistý Hadoop poměrně složitým nástrojem na konfiguraci, protože musíte hodně dělat ručně. Můžete například konfigurovat servery jednotlivě, sledovat jejich výkon a dolaďovat mnoho parametrů. Obecně platí, že práce pro amatéra a je velká šance se někde podělat nebo něco přehlédnout.
Velkou oblibu si proto získaly různé distribuce, které jsou zpočátku vybaveny pohodlnými nástroji pro nasazení a správu. Jednou z nejpopulárnějších distribucí, která podporuje Spark a usnadňuje věci, je Cloudera. Má placenou i bezplatnou verzi - a v té druhé jsou k dispozici všechny hlavní funkce a bez omezení počtu uzlů.
Během nastavení se Cloudera Manager připojí přes SSH k vašim serverům. Zajímavý bod: při instalaci je lepší určit, aby byla provedena tzv balíky: speciální balíčky, z nichž každý obsahuje všechny potřebné součásti nakonfigurované pro vzájemnou spolupráci. Ve skutečnosti se jedná o takovou vylepšenou verzi správce balíčků.
Po instalaci získáme konzolu pro správu clusteru, kde můžete vidět telemetrii pro clustery, nainstalované služby a navíc můžete přidávat/odebírat prostředky a upravovat konfiguraci clusteru.
Výsledkem je, že se před vámi objeví řezání té rakety, které vás zavede do světlé budoucnosti BigData. Než ale řekneme „pojďme“, pojďme rychle vpřed pod kapotu.
hardwarové požadavky
Cloudera na svých stránkách zmiňuje různé možné konfigurace. Obecné principy, podle kterých jsou postaveny, jsou znázorněny na obrázku:
MapReduce dokáže tento optimistický obrázek rozmazat. Když se znovu podíváme na diagram v předchozí části, je jasné, že téměř ve všech případech může úloha MapReduce narazit na úzké hrdlo při čtení dat z disku nebo sítě. To je také uvedeno na blogu Cloudera. Výsledkem je, že pro jakékoli rychlé výpočty, včetně přes Spark, který se často používá pro výpočty v reálném čase, je rychlost I/O velmi důležitá. Při použití Hadoopu je proto velmi důležité, aby se do clusteru dostaly vyvážené a rychlé stroje, které, mírně řečeno, nejsou vždy poskytovány v cloudové infrastruktuře.
Rovnováhy v rozložení zátěže je dosaženo použitím virtualizace Openstack na serverech s výkonnými vícejádrovými CPU. Datovým uzlům jsou přiděleny jejich vlastní procesorové prostředky a určité disky. V našem rozhodnutí Atos Codex Data Lake Engine je dosaženo široké virtualizace, a proto vítězíme jak z hlediska výkonu (minimalizuje se dopad síťové infrastruktury), tak celkových nákladů na vlastnictví (odpadají další fyzické servery).
V případě použití serverů BullSequana S200 získáme velmi rovnoměrné zatížení, bez některých úzkých míst. Minimální konfigurace zahrnuje 3 servery BullSequana S200, každý se dvěma JBOD, plus volitelně připojené další S200 obsahující čtyři datové uzly. Zde je příklad zatížení v testu TeraGen:
Testy s různými objemy dat a hodnotami replikace vykazují stejné výsledky, pokud jde o rozložení zátěže mezi uzly clusteru. Níže je uveden graf rozložení přístupu na disk podle výkonnostních testů.
Výpočty jsou založeny na minimální konfiguraci 3 serverů BullSequana S200. Zahrnuje 9 datových uzlů a 3 hlavní uzly a také vyhrazené virtuální stroje pro případ nasazení ochrany založené na OpenStack Virtualization. Výsledek testu TeraSort: Velikost bloku 512 MB s replikačním faktorem tři se šifrováním je 23,1 minuty.
Jak lze systém rozšířit? Pro Data Lake Engine jsou k dispozici různé typy rozšíření:
- Datové uzly: na každých 40 TB využitelného prostoru
- Analytické uzly s možností instalace GPU
- Další možnosti v závislosti na obchodních potřebách (například pokud potřebujete Kafku a podobně)
Komplex Atos Codex Data Lake Engine zahrnuje jak samotné servery, tak předinstalovaný software, včetně sady Cloudera s licencí; Samotný Hadoop, OpenStack s virtuálními stroji založenými na linuxovém jádře RedHat Enterprise, systémy replikace dat a zálohování (včetně použití záložního uzlu a Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine je první virtualizační řešení, které bylo certifikováno .
Pokud vás zajímají podrobnosti, rádi zodpovíme naše dotazy v komentářích.
Zdroj: www.habr.com