Ogni workload è unico, e quindi una configurazione di Hadoop cluster (una collezione di software open source che consentono la creazione di ambienti di computing e di storage distribuiti) che funziona bene per un carico di lavoro può non essere ottimale per un altro. Il modo migliore per verificare l’idoneità di una configurazione è quello di metterla alla prova con più workload attivi. Una strada per raggiungere questo scopo è quella di creare uno standard di riferimento, ovvero una baseline. Quindi si può comparare tutte le diverse configurazioni da provare con questa baseline e verificare se si è ottenuto l’effetto desiderato.
Per creare una configurazione standard di riferimento occorre partire da una default configuration (come quelle proposte dalle diverse distribuzioni di Hadoop commerciali o in versioni community, scaricabili gratis dal web) e far girare un programma (job) rappresentativo di quelli che utilizzerete una volta che il cluster sarà lanciato in produzione. Dopo aver fatto girare il job, dovete analizzare la sua storia, verificare quanto tempo ha impiegato per svolgere il suo compito e calcolare una media.
File e informazioni contenute
Quando si lancia un job, il sistema crea due file: un file .XML che descrive la configurazione del job e un file contenente lo status del job. Il file relativo al job status è utile per tracciare l’effetto dei cambiamenti alla configurazione in quanto contiene, appunto, le informazioni di stato (running, failed, succeeded, etc.) e le metriche di runtime (task completati, numero di errori, di thread bloccati, etc.). Per vedere i dati di job status si può utilizzare il comando Hadoop ‘job’, seguito dal nome di quest’ultimo. Se non siete sicuri di identificare bene un job, si può aggiungere ad ‘hadoop job’ il parametro ‘-List All’.
Come effettuare le prove
Se utilizzate il metodo della comparazione con la baseline per analizzare gli effetti dei cambiamenti di configurazione, è bene ricordarsi di eseguire un cambiamento alla volta. Se effettuate più cambiamenti in una volta sola, e quindi ricevete un risultato inatteso nel job status file, risulta difficile determinare quale modifica, o quali modifiche, hanno causato il comportamento inaspettato. Provare un cambiamento alla volta può essere noioso, ma è il modo migliore per ottenere il maggiore controllo possibile delle prestazioni del cluster.
File di configurazione specifici per un ambiente
Fra i molti singoli file che si possono esaminare per effettuare un’ottimizzazione precisa (fine-tune) di un cluster Hadoop ci sono quelli cosiddetti site-specific configuration file e default configuration file.
Un esempio di file di configurazione site-specific di Hadoop e il core-site.xml. Questo file consente sia di controllare la dimensione dei read/write buffer sia la quantità di memoria dedicata al file system. Si può utilizzare core-site.xml anche per mettere un limite allo storage dei dati, i quali, com’è noto, nell’era dei big data possono raggiungere moli estremamente elevate.
Un altro file utilizzabile per definire un aspetto chiave della configurazione di un cluster Hadoop è hdfs-site.xml. L’acronimo HDFS sta per Hadoop Distributed File System. Tramite il file hdfs-site.xml si possono cambiare i path (percorsi) dei namenode e dei datanode che costituiscono il file system distribuito di Hadoop. I namenode sono i nodi che ospitano i file system di nodo, in cui sono memorizzati i nomi delle cartelle e dei file (metadata) contenuti nei datanode che fanno capo a loro (e che possono essere ricercati inviando un’apposita richiesta al namenode). I datanode sono i server in cui sono memorizzati i dati veri e propri. Si può utilizzare il file hdfs-site.xml anche per definire impostazioni di data replication.
Un altro importante site-specific file da tenere presente, soprattutto se si prevede di trattare big data, è mapred-site.xml. Questo file consente di configurare il sistema map reducer utilizzato in un ambiente Hadoop. I map reducer sono framework impiegati laddove le moli di big data da analizzare sono superiori alle capacità dei singoli server di un Hadoop cluster. Con questi strumenti (come MapReduce e Spark) è possibile creare ambienti di gestione, store e processing parallelo che offrono performance ottimali anche a fronte di data set molto grandi. Il file mapred-site.xml consente di abilitare o escludere l’uso di determinati datanode e tasktracker (i nodi che accettano i task di map reducing) e di definire inoltre il corretto path verso MapReduce (generalmente in bundle nelle distribuzioni Hadoop).
Default configuration file
I file di configurazione di default sono quelli che devono essere trattati da un intero cluster Hadoop come read-only (non devono, cioè, poter essere modificati). Uno di questi è core-default.xml. Questo file permette di configurare parametri come quelli relativi al monitoraggio dello stato di salute di un sistema e il valore di timeout di una sessione zookeeper. (Zookeeper è servizio di distribuzione gerarchica di carichi di lavoro fra diversi nodi implementato su un server. Durante la sessione deve essere mantenuta una connessione TCP-IT con un client).
Hdfs-default.xml viene utilizzato per configurare l’HDFS, limitare il numero di item (oggetti) che possono essere presenti in una directory, fissare un numero massimo di blocchi per file ed eseguire altri task di configurazione tipiche per un file system.
Mapred-default.xml, infine, è il file che contiene i settaggi relativi al map reducer. Con questo file, per esempio, è possibile definire il numero di virtual core e la quantità di memoria da richiedere per ciascun task map allo schedulatore del map reducer.
