Il mercato del calcolo distribuito e dei big data, a quanto pare , cresce del 18-19% all'anno. Pertanto, la scelta del software per questi scopi rimane attuale. In questo articolo inizieremo spiegando perché il calcolo distribuito è necessario, approfondiremo la scelta del software, parleremo dell'applicazione di Hadoop attraverso Cloudera e, per finire, discuteremo della selezione dell'hardware e di come influisce sulla prestazione in modi diversi.
Perché il calcolo distribuito è necessario nelle aziende comuni? Qui la situazione è semplice e complicata allo stesso tempo. Semplice perché, nella maggior parte dei casi, eseguiamo calcoli relativamente semplici per unità di informazione. Complicato perché ci sono molte informazioni. Moltissime. Di conseguenza, dobbiamo . Così, gli scenari di utilizzo sono abbastanza universali: i calcoli possono essere applicati ovunque sia necessario tenere conto di un grande numero di metriche su un insieme ancora più grande di dati.
Uno dei recenti esempi: la rete di pizzerie Dodo Pizza sulla base dell'analisi del database degli ordini dei clienti, quando scelgono una pizza con ingredienti a scelta, gli utenti di solito si orientano solo su sei combinazioni di ingredienti di base più un paio casuali. Di conseguenza, la pizzeria ha adattato gli acquisti. Inoltre, è riuscita a consigliare meglio agli utenti i prodotti aggiuntivi offerti durante il processo di ordinazione, aumentando così i profitti.
Un altro esempio: di prodotto ha permesso al negozio H&M di ridurre l'assortimento in alcuni punti vendita del 40%, mantenendo allo stesso tempo il livello delle vendite. Ciò è stato possibile escludendo articoli con scarse vendite, considerando anche la stagionalità.
Scelta dello strumento
Lo standard di settore per calcoli di questo tipo è Hadoop. Perché? Perché Hadoop è un ottimo framework ben documentato (questo stesso Habr pubblica numerosi articoli dettagliati in merito), accompagnato da un insieme di utilità e librerie. È possibile fornire set di dati enormi, sia strutturati che non strutturati, e il sistema si occuperà di distribuirli tra le risorse calcolative. Inoltre, queste risorse possono essere aumentate o disattivate in qualsiasi momento — proprio quella scalabilità orizzontale in azione.
Nel 2017, la rinomata società di consulenza Gartner , che Hadoop presto si estinguerà. Il motivo è abbastanza banale: gli analisti ritengono che le aziende inizieranno a migrare massicciamente nel cloud, poiché lì possono pagare in base all'utilizzo delle risorse computazionali. Un secondo fattore importante che potrebbe 'seppellire' Hadoop è la velocità di lavoro. Perché opzioni come Apache Spark o Google Cloud DataFlow funzionano più velocemente di MapReduce, alla base di Hadoop.
Hadoop si basa su diversi pilastri, i più importanti dei quali sono le tecnologie MapReduce (un sistema di distribuzione dei dati per i calcoli tra server) e il file system HDFS. Quest'ultimo è progettato specificamente per memorizzare informazioni distribuite tra i nodi di un cluster: ogni blocco di dimensioni fisse può essere posizionato su più nodi, e grazie alla replica, il sistema garantisce resilienza ai guasti di singoli nodi. Al posto di una tabella dei file, si utilizza un server speciale chiamato NameNode.
Nell'illustrazione qui sotto è mostrato il funzionamento di MapReduce. Nella prima fase, i dati vengono suddivisi secondo un certo criterio; nella seconda, vengono distribuiti in base alle capacità di calcolo; nella terza, avviene il calcolo.
Inizialmente, MapReduce è stato creato da Google per le esigenze del proprio motore di ricerca. Successivamente, MapReduce è diventato open source e il progetto è stato gestito da Apache. Nel frattempo, Google ha gradualmente migrato verso altre soluzioni. Un dettaglio interessante: attualmente Google ha un progetto chiamato Google Cloud Dataflow, posizionato come il passo successivo dopo Hadoop, come una sua rapida sostituzione.
Esaminando da vicino, si nota che Google Cloud Dataflow si basa su una variante di Apache Beam, che include un framework ben documentato di Apache Spark, il che significa che le soluzioni raggiungono praticamente la stessa velocità di esecuzione. Inoltre, Apache Spark funziona perfettamente su un file system HDFS, consentendo il suo deployment su server Hadoop.
Considerando anche la quantità di documentazione e soluzioni pronte per Hadoop e Spark rispetto a Google Cloud Dataflow, la scelta dello strumento diventa ovvia. Inoltre, gli ingegneri possono decidere autonomamente quale codice eseguire - sotto Hadoop o Spark - in base al compito, all'esperienza e alle competenze.
Cloud o server locale
La tendenza verso una transizione globale verso il cloud ha persino generato un termine interessante come Hadoop-as-a-service. In questo scenario, la gestione dei server collegati è diventata fondamentale. Purtroppo, nonostante la sua popolarità, Hadoop puro è uno strumento piuttosto complesso da configurare, poiché richiede molte operazioni manuali. Ad esempio, è necessario configurare i server singolarmente, monitorare le loro prestazioni e regolare con precisione numerosi parametri. In sostanza, è un lavoro da appassionati e c'è un grande rischio di commettere errori o di trascurare qualcosa.
Pertanto, vari distribuzioni che includono strumenti di distribuzione e gestione user-friendly hanno guadagnato grande popolarità. Una delle distribuzioni più popolari, che supportano Spark e semplificano tutto, è Cloudera. Ha versioni sia a pagamento che gratuite, e nell'ultima è disponibile tutta la funzionalità principale, senza limitazioni sul numero di nodi.
Durante la configurazione, Cloudera Manager si connetterà via SSH ai vostri server. Un aspetto interessante: durante l'installazione, è meglio specificare che dovrebbe avvenire in modo chiamato con pacchetti: pacchetti speciali, ciascuno dei quali contiene tutti i componenti necessari, configurati per funzionare insieme. Di fatto, è una versione migliorata del gestore di pacchetti.
Dopo l'installazione, otteniamo una console di gestione del cluster, dove è possibile visualizzare la telemetria dei cluster, i servizi installati, e inoltre potrete aggiungere/rimuovere risorse e modificare la configurazione del cluster.
Il risultato è che davanti a voi si presenta la cabina di quella navetta che vi porterà verso un luminoso futuro nel Big Data. Ma prima di dire "partiamo", diamo un'occhiata sotto il cofano.
Requisiti hardware
Sul sito di Cloudera vengono menzionate diverse configurazioni possibili. I principi generali su cui si basano sono illustrati nella figura:
Un aspetto ottimistico può essere influenzato da MapReduce. Se si osserva nuovamente il diagramma della sezione precedente, diventa chiaro che, nella maggior parte dei casi, il compito di MapReduce può affrontare un 'collo di bottiglia' quando legge i dati dal disco o dalla rete. Questo è anche menzionato nel blog di Cloudera. Di conseguenza, per qualsiasi calcolo rapido, incluso tramite Spark, spesso usato per elaborazioni in tempo reale, la velocità di input/output è cruciale. Pertanto, quando si utilizza Hadoop, è fondamentale che nel cluster siano presenti macchine bilanciate e veloci, il che, per non dire altro, non è sempre garantito nell'infrastruttura cloud.
L'equilibrio nella distribuzione dei carichi è raggiunto grazie all'uso della virtualizzazione OpenStack su server con potenti CPU multi-core. I nodi dati sono dotati di risorse di elaborazione dedicate e dischi specifici. Nella nostra soluzione Atos Codex Data Lake Engine si ottiene una virtualizzazione estesa, il che ci consente di guadagnare sia in termini di prestazioni (minimizzando l'impatto dell'infrastruttura di rete) sia in TCO (eliminando server fisici superflui).
Nel caso dell'utilizzo dei server BullSequana S200, otteniamo un carico piuttosto uniforme, privo di alcuni colli di bottiglia. La configurazione minima include 3 server BullSequana S200, ognuno con due JBOD, e opzionalmente possono essere collegati ulteriori S200 contenenti quattro nodi di dati. Ecco un esempio del carico nel test TeraGen:
I test con diversi volumi di dati e valori di replicazione mostrano risultati equivalenti in termini di distribuzione del carico tra i nodi del cluster. Di seguito è riportato un grafico della distribuzione dell'accesso al disco nei test di prestazioni.
I calcoli sono stati eseguiti su una configurazione minima composta da 3 server BullSequana S200. Essa include 9 nodi dati e 3 nodi principali, oltre a macchine virtuali riservate nel caso di un'implementazione della protezione basata su OpenStack Virtualization. Risultato del test TeraSort: dimensione del blocco di 512 MB con un fattore di replicazione pari a tre e crittografia che richiede 23,1 minuti.
Come può essere espanso il sistema? Sono disponibili diverse forme di espansione per il Data Lake Engine:
- Nodi di trasferimento dati: per ogni 40 TB di spazio utile
- Nodi analitici con capacità di installazione di GPU
- Altre opzioni in base alle esigenze aziendali (ad esempio, se è necessario Kafka e simili)
Il complesso Atos Codex Data Lake Engine comprende sia i server stessi che il software preinstallato, inclusi il pacchetto Cloudera con licenza; Hadoop stesso, OpenStack con macchine virtuali basate su RedHat Enterprise Linux, sistemi di replica dei dati e backup (inclusi quelli tramite nodo di backup e Cloudera BDR — Backup and Disaster Recovery). Atos Codex Data Lake Engine è stata la prima soluzione con virtualizzazione ad essere certificata. .
Se desidera maggiori dettagli, saremo lieti di rispondere alle sue domande nei commenti.
Fonte: habr.com
