Il mercato del calcolo distribuito e dei big data, secondo , sta crescendo del 18-19% all'anno. Ciò significa che la questione della scelta del software per questi scopi rimane rilevante. In questo post inizieremo con il motivo per cui abbiamo bisogno del calcolo distribuito, ci soffermeremo più in dettaglio sulla scelta del software, parleremo dell'utilizzo di Hadoop con Cloudera e infine parleremo della scelta dell'hardware e di come influisce sulle prestazioni in diversi modi.
Perché abbiamo bisogno del calcolo distribuito nell'attività ordinaria? Tutto è semplice e complicato allo stesso tempo. Semplice - perché nella maggior parte dei casi eseguiamo calcoli relativamente semplici per unità di informazione. Difficile, perché ci sono molte di queste informazioni. Così tanti. Di conseguenza, bisogna . Pertanto, i casi d'uso sono abbastanza universali: i calcoli possono essere applicati ovunque sia necessario tenere conto di un gran numero di metriche su un array di dati ancora più grande.
Un esempio recente: Dodo Pizza basato su un'analisi della base di ordini dei clienti, che quando scelgono una pizza con condimenti arbitrari, gli utenti di solito operano con solo sei serie di ingredienti di base più un paio di ingredienti casuali. Di conseguenza, la pizzeria ha adeguato gli acquisti. Inoltre, è stato in grado di consigliare meglio agli utenti prodotti aggiuntivi offerti in fase di ordine, il che ha aumentato i profitti.
Un altro esempio: la merce ha permesso a H&M di ridurre del 40% l'assortimento nei singoli negozi, mantenendo il livello delle vendite. Ciò è stato ottenuto escludendo le posizioni che vendono male e nei calcoli è stata presa in considerazione la stagionalità.
Selezione degli strumenti
Lo standard del settore per questo tipo di elaborazione è Hadoop. Perché? Perché Hadoop è un framework eccellente e ben documentato (lo stesso Habr pubblica molti articoli dettagliati su questo argomento), che è accompagnato da un intero set di utilità e librerie. Puoi inviare enormi set di dati sia strutturati che non strutturati come input e il sistema stesso li distribuirà tra la potenza di calcolo. Inoltre, queste stesse capacità possono essere aumentate o disattivate in qualsiasi momento: la stessa scalabilità orizzontale in azione.
Nel 2017, l'influente società di consulenza Gartner che Hadoop diventerà presto obsoleto. Il motivo è abbastanza banale: gli analisti ritengono che le aziende migreranno massicciamente verso il cloud, poiché lì potranno pagare in base all'utilizzo della potenza di calcolo. Il secondo fattore importante presumibilmente in grado di "seppellire" Hadoop è la velocità del lavoro. Perché opzioni come Apache Spark o Google Cloud DataFlow sono più veloci di MapReduce sottostante Hadoop.
Hadoop poggia su diversi pilastri, i più notevoli dei quali sono le tecnologie MapReduce (un sistema per la distribuzione dei dati per i calcoli tra i server) e il file system HDFS. Quest'ultimo è specificamente progettato per archiviare informazioni distribuite tra i nodi del cluster: ogni blocco di dimensioni fisse può essere posizionato su più nodi e, grazie alla replica, il sistema è resistente ai guasti dei singoli nodi. Invece di una tabella di file, viene utilizzato un server speciale chiamato NameNode.
L'illustrazione seguente mostra come funziona MapReduce. Nella prima fase i dati vengono suddivisi in base a un determinato attributo, nella seconda fase vengono distribuiti dalla potenza di calcolo, nella terza fase avviene il calcolo.
MapReduce è stato originariamente creato da Google per le esigenze della sua ricerca. Quindi MapReduce è passato al codice libero e Apache ha rilevato il progetto. Bene, Google è gradualmente migrato verso altre soluzioni. Una sfumatura interessante: al momento, Google ha un progetto chiamato Google Cloud Dataflow, posizionato come il passo successivo dopo Hadoop, come suo rapido sostituto.
Uno sguardo più attento mostra che Google Cloud Dataflow si basa su una variazione di Apache Beam, mentre Apache Beam include il ben documentato framework Apache Spark, che ci consente di parlare di quasi la stessa velocità di esecuzione della soluzione. Bene, Apache Spark funziona bene sul file system HDFS, che ti consente di distribuirlo sui server Hadoop.
Aggiungi qui il volume della documentazione e delle soluzioni già pronte per Hadoop e Spark rispetto a Google Cloud Dataflow e la scelta dello strumento diventa ovvia. Inoltre, gli ingegneri possono decidere autonomamente quale codice - sotto Hadoop o Spark - eseguire, concentrandosi sull'attività, sull'esperienza e sulle qualifiche.
Cloud o server locale
La tendenza verso la transizione generale al cloud ha persino dato origine a un termine così interessante come Hadoop-as-a-service. In tale scenario, l'amministrazione dei server connessi è diventata molto importante. Perché, ahimè, nonostante la sua popolarità, Hadoop puro è uno strumento piuttosto difficile da configurare, dal momento che devi fare molto a mano. Ad esempio, puoi configurare i server individualmente, monitorarne le prestazioni e ottimizzare molti parametri. In generale, lavori per un dilettante e c'è una grande possibilità di sbagliare da qualche parte o perdere qualcosa.
Pertanto, sono diventate molto popolari varie distribuzioni, inizialmente dotate di comodi strumenti di distribuzione e amministrazione. Una delle distribuzioni più popolari che supporta Spark e semplifica le cose è Cloudera. Ha sia versioni a pagamento che gratuite e in quest'ultima sono disponibili tutte le funzionalità principali e senza limitare il numero di nodi.
Durante la configurazione, Cloudera Manager si connetterà tramite SSH ai tuoi server. Un punto interessante: durante l'installazione, è meglio specificare che verrà eseguito dal cosiddetto pacchi: pacchetti speciali, ognuno dei quali contiene tutti i componenti necessari configurati per lavorare insieme. In effetti, questa è una versione così migliorata del gestore di pacchetti.
Dopo l'installazione, otteniamo una console di gestione del cluster, in cui è possibile visualizzare la telemetria per i cluster, i servizi installati, inoltre è possibile aggiungere / rimuovere risorse e modificare la configurazione del cluster.
Di conseguenza, il taglio di quel razzo appare davanti a te, che ti porterà nel brillante futuro dei BigData. Ma prima di dire "andiamo", andiamo avanti veloce sotto il cofano.
requisiti hardware
Sul loro sito Web, Cloudera menziona diverse possibili configurazioni. I principi generali con cui sono costruiti sono mostrati nell'illustrazione:
MapReduce può offuscare questa immagine ottimistica. Guardando di nuovo il diagramma nella sezione precedente, diventa chiaro che in quasi tutti i casi un lavoro MapReduce può incontrare un collo di bottiglia durante la lettura dei dati dal disco o dalla rete. Questo è anche notato sul blog di Cloudera. Di conseguenza, per qualsiasi calcolo veloce, anche tramite Spark, che viene spesso utilizzato per calcoli in tempo reale, la velocità di I/O è molto importante. Pertanto, quando si utilizza Hadoop, è molto importante che macchine equilibrate e veloci entrino nel cluster, che, per usare un eufemismo, non è sempre fornito nell'infrastruttura cloud.
L'equilibrio nella distribuzione del carico si ottiene attraverso l'uso della virtualizzazione Openstack su server con potenti CPU multi-core. Ai nodi dati vengono assegnate le proprie risorse del processore e determinati dischi. Nella nostra soluzione Motore Atos Codex Data Lake si ottiene un'ampia virtualizzazione, motivo per cui vinciamo sia in termini di prestazioni (l'impatto dell'infrastruttura di rete è ridotto al minimo) che di TCO (i server fisici extra vengono eliminati).
Nel caso di utilizzo dei server BullSequana S200, otteniamo un carico molto uniforme, privo di alcuni colli di bottiglia. La configurazione minima include 3 server BullSequana S200, ciascuno con due JBOD, più ulteriori S200 contenenti quattro nodi di dati collegati opzionalmente. Ecco un esempio di carico in un test TeraGen:
I test con diversi volumi di dati e valori di replica mostrano gli stessi risultati in termini di distribuzione del carico tra i nodi del cluster. Di seguito è riportato un grafico della distribuzione dell'accesso al disco in base ai test delle prestazioni.
I calcoli si basano su una configurazione minima di 3 server BullSequana S200. Include 9 nodi dati e 3 nodi master, oltre a macchine virtuali riservate in caso di implementazione della protezione basata su OpenStack Virtualization. Risultato del test TeraSort: la dimensione del blocco di 512 MB di un fattore di replica di tre con crittografia è di 23,1 minuti.
Come si può espandere il sistema? Sono disponibili vari tipi di estensioni per Data Lake Engine:
- Nodi dati: per ogni 40 TB di spazio utilizzabile
- Nodi analitici con la possibilità di installare una GPU
- Altre opzioni a seconda delle esigenze aziendali (ad esempio, se hai bisogno di Kafka e simili)
Il complesso Atos Codex Data Lake Engine include sia i server stessi che il software preinstallato, incluso il kit Cloudera con licenza; Hadoop stesso, OpenStack con macchine virtuali basate sul kernel RedHat Enterprise Linux, replica dei dati e sistemi di backup (incluso l'utilizzo di un nodo di backup e Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine è la prima soluzione di virtualizzazione ad essere certificata .
Se sei interessato ai dettagli, saremo lieti di rispondere alle nostre domande nei commenti.
Fonte: habr.com