Il mercato dell'elaborazione distribuita e dei big data, a quanto pare, cresce del 18-19% all'anno. Questo significa che la questione della scelta del software per questi scopi rimane attuale. In questo post inizieremo da perché sono necessari i calcoli distribuiti, approfondiremo la scelta del software, parleremo dell'uso di Hadoop tramite Cloudera e, infine, discuteremo della scelta dell'hardware e di come influisca in vari modi sulle prestazioni.
Perché sono necessari i calcoli distribuiti nel business comune? Qui tutto è semplice e complicato allo stesso tempo. Semplice — perché nella maggior parte dei casi svolgiamo calcoli relativamente semplici su singole informazioni. Complicato — perché tali informazioni sono molte. Davvero molte. Di conseguenza, è necessario . Pertanto, gli scenari di utilizzo sono piuttosto universali: i calcoli possono essere applicati ovunque sia necessario considerare un numero elevato di metriche su un ancora maggiore insieme di dati.
Uno dei recenti esempi: la rete di pizzerie Dodo Pizza sulla base dell'analisi del database degli ordini dei clienti che, quando si tratta di scegliere una pizza con condimenti a piacere, gli utenti in genere operano solo con sei set di ingredienti di base più un paio di casuali. Di conseguenza, la pizzeria ha adattato gli acquisti. Inoltre, è riuscita a consigliare meglio agli utenti prodotti aggiuntivi offerti nel processo d'ordine, il che ha aiutato ad aumentare i profitti.
Un altro esempio: la razionalizzazione delle posizioni merceologiche ha permesso al negozio H&M di ridurre l'assortimento in alcuni negozi del 40%, mantenendo nel contempo il livello delle vendite. Questo è stato ottenuto escludendo le posizioni a bassa vendita, tenendo conto della stagionalità.
Scelta dello strumento
Lo standard di settore per questo tipo di calcolo è Hadoop. Perché? Perché Hadoop è un'ottima e ben documentata framework (quello stesso Habr offre molti articoli dettagliati su questo argomento), accompagnato da un insieme di utilità e librerie. È possibile fornire enormi insiemi di dati sia strutturati che non strutturati, e il sistema li distribuirà autonomamente tra le risorse computazionali. Inoltre, queste stesse risorse possono essere ampliate o disattivate in qualsiasi momento: è l'orizzontale scalabilità in azione.
Nel 2017, una influente società di consulenza, Gartner, , ha affermato che Hadoop presto si estinguerà. La ragione è piuttosto banale: gli analisti ritengono che le aziende inizieranno a migrare massicciamente verso il cloud, dove potranno pagare in base all'uso delle risorse di calcolo. Un secondo fattore importante che potrebbe "seppellire" Hadoop è la velocità operativa. Infatti, alternative come Apache Spark o Google Cloud DataFlow operano più velocemente di MapReduce, che è alla base di Hadoop.
Hadoop si basa su alcune colonne portanti, le più evidenti delle quali sono le tecnologie MapReduce (sistema di distribuzione dei dati per calcoli tra server) e il file system HDFS. Quest'ultimo è specificamente progettato per memorizzare informazioni distribuite tra i nodi del cluster: ogni blocco di dimensione fissa può essere posizionato su più nodi e, grazie alla replicazione, si garantisce la resilienza del sistema alle guasti dei singoli nodi. Invece della tabella dei file, si utilizza un server speciale denominato NameNode.
Nell'illustrazione qui sotto è riportato lo schema di funzionamento di MapReduce. Nella prima fase, i dati vengono suddivisi in base a un certo criterio; nella seconda fase, vengono distribuiti alle risorse di calcolo; nella terza fase, avviene il calcolo.
Inizialmente, MapReduce fu creato da Google per le esigenze del suo motore di ricerca. Successivamente, MapReduce è diventato open source, e il progetto è stato preso in carico da Apache. Google, nel frattempo, ha gradualmente migrato verso altre soluzioni. Un aspetto interessante: attualmente Google ha un progetto chiamato Google Cloud Dataflow, posizionato come il passo successivo dopo Hadoop, una sua veloce sostituzione.
Esaminando più 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 permette di affermare che la velocità di esecuzione delle soluzioni è praticamente identica. Inoltre, Apache Spark funziona ottimamente sul file system HDFS, permettendo di implementarlo sui server Hadoop.
Aggiungendo qui il volume della documentazione e delle soluzioni pronte su Hadoop e Spark rispetto a Google Cloud Dataflow, la scelta dello strumento diventa evidente. Inoltre, gli ingegneri possono decidere autonomamente quale codice eseguire — per Hadoop o Spark — in base al compito, all'esperienza e alla qualificazione.
Cloud o server locale
La tendenza verso il passaggio globale al cloud ha dato vita a un termine interessante come Hadoop-as-a-service. In questo scenario, la gestione dei server connessi è diventata fondamentale. Purtroppo, nonostante la sua popolarità, l'Hadoop puro è uno strumento piuttosto complesso da configurare, poiché molto deve essere fatto manualmente. Ad esempio, configurare singolarmente i server, monitorare le loro prestazioni e impostare con attenzione numerosi parametri. In breve, è un lavoro per appassionati, con un alto rischio di commettere errori o di trascurare qualcosa.
Per questo motivo, vari distributori hanno guadagnato particolare popolarità, poiché sono forniti fin dall'inizio di strumenti convenienti per il deploy e l'amministrazione. Uno dei più popolari è Cloudera, che supporta Spark e semplifica molte operazioni. Ha versioni sia a pagamento che gratuite, e quest'ultima offre tutte le funzionalità principali senza limitazioni sul numero di nodi.
Durante la configurazione, Cloudera Manager si collegherà ai vostri server tramite SSH. Un aspetto interessante: durante l'installazione è meglio specificare che si utilizzi il cosiddetto parcel: pacchetti speciali, ciascuno dei quali contiene tutti i componenti necessari, configurati per funzionare insieme. In sostanza, è una versione migliorata di un gestore di pacchetti.
Dopo l'installazione, si ottiene una console di gestione del cluster, dove è possibile visualizzare la telemetria dei cluster, i servizi installati, oltre a poter aggiungere/rimuovere risorse e modificare la configurazione del cluster.
Di conseguenza, davanti a voi si presenta il varco per quella navicella che vi porterà verso un luminoso futuro nel mondo del Big Data. Ma prima di dire 'partiamo', facciamo un passo indietro e vediamo cosa c'è sotto il cofano.
Requisiti hardware
Sul suo sito Cloudera menziona diverse configurazioni possibili. I principi generali su cui vengono costruite sono illustrati nell'immagine:
Un'immagine ottimistica può essere rovinata da MapReduce. Se si guarda di nuovo allo schema della sezione precedente, è chiaro che in quasi tutti i casi un'attività MapReduce può affrontare un "collo di bottiglia" durante la lettura dei dati dal disco o dalla rete. Questo è anche evidenziato nel blog di Cloudera. Di conseguenza, per qualsiasi calcolo rapido, incluso Spark, che è spesso usato per il calcolo in tempo reale, la velocità di input/output è molto importante. Pertanto, quando si utilizza Hadoop, è fondamentale che nel cluster siano presenti macchine bilanciate e veloci, che, a dirla tutta, non è sempre garantito nelle infrastrutture cloud.
L'equilibrio nella distribuzione dei carichi si ottiene utilizzando la virtualizzazione Openstack su server con potenti CPU multi-core. Ai data node sono assegnate le proprie risorse di elaborazione e dischi specifici. Nella nostra soluzione Atos Codex Data Lake Engine si ottiene un'ampia virtualizzazione, da cui beneficiamo sia in termini di prestazioni (si minimizza l'impatto delle infrastrutture di rete) sia in termini di TCO (si escludono server fisici superflui).
Nel caso di server BullSequana S200, otteniamo un carico piuttosto uniforme, privo di alcune strozzature. Nella configurazione minima sono inclusi 3 server BullSequana S200, ciascuno con due JBOD, e si possono opzionalmente collegare ulteriori S200, contenenti quattro data node. Ecco un esempio di carico nel test TeraGen:
I test con diversi volumi di dati e valori di replica mostrano risultati identici 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 sulla base della configurazione minima di 3 server BullSequana S200. Essa include 9 nodi dati e 3 nodi master, oltre a macchine virtuali riservate nel caso di 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 di 23,1 minuti.
Come si può espandere il sistema? Per il Data Lake Engine sono disponibili vari tipi di espansioni:
- Nodi di trasferimento dati: per ogni 40 TB di spazio utile
- Nodi analitici con possibilità di installazione di GPU
- Altre opzioni a seconda delle esigenze aziendali (ad esempio, se è necessario Kafka e simili)
Il complesso Atos Codex Data Lake Engine include sia i server stessi che il software preinstallato, che comprende il pacchetto Cloudera con licenza; Hadoop stesso, OpenStack con macchine virtuali basate su RedHat Enterprise Linux, sistemi di replica dei dati e backup (incluso attraverso un nodo di backup e Cloudera BDR — Backup e Disaster Recovery). Atos Codex Data Lake Engine è stata la prima soluzione con virtualizzazione a essere certificata .
Se ti interessano ulteriori dettagli, saremo lieti di rispondere alle tue domande nei commenti.
Fonte: habr.com
