Het afstemmen van prestaties helpt bij het optimaliseren van uw Hadoop uitvoering. In deze blog gaan we al die technieken voor MapReduce Job-optimalisaties bespreken.
In deze MapReduce tutorial geven we je 6 belangrijke tips voor MapReduce Job Optimization zoals de juiste configuratie van je cluster, LZO compressie gebruik, juiste afstemming van het aantal MapReduce taken etc.
Tips voor MapReduce-taakoptimalisatie
Hieronder staan enkele MapReduce-technieken voor taakoptimalisatie die u kunnen helpen bij het optimaliseren van de taakprestaties van MapReduce.
1. Juiste configuratie van uw cluster
- Met -noatime optie Dfs en MapReduce storage zijn aangekoppeld. Hierdoor wordt de toegangstijd uitgeschakeld. Verbetert dus de I/O-prestaties.
- Probeer de RAID op TaskTracker- en datanode-machines te vermijden. Dit vermindert over het algemeen de prestaties.
- Zorg ervoor dat u mapred.local.dir . heeft geconfigureerd en dfs.data.dir om naar één map op elk van uw schijven te verwijzen. Dit is om ervoor te zorgen dat al uw I/O-capaciteit wordt gebruikt.
- U moet de grafiek van het swapgebruik en het netwerkgebruik met software controleren. Als u ziet dat swap wordt gebruikt, moet u de hoeveelheid RAM die aan elke taak is toegewezen in mapred.child.java.opts verminderen. .
- Zorg ervoor dat u slim toezicht houdt op de gezondheidsstatus van uw schijfstations. Dit is een van de belangrijke methoden voor het afstemmen van de prestaties van MapReduce.
2. LZO-compressiegebruik
Voor tussenliggende gegevens is dit altijd een goed idee. Elke Hadoop-taak die een niet te verwaarlozen hoeveelheid kaartuitvoer genereert, profiteert van tussentijdse gegevenscompressie met LZO.
Hoewel LZO een beetje overhead aan de CPU toevoegt, bespaart het tijd door de hoeveelheid schijf-IO tijdens de shuffle te verminderen.
Stel mapred.compress.map.output in naar true om LZO-compressie in te schakelen
3. Correcte afstemming van het aantal MapReduce-taken
- Als in MapReduce-taak elke taak 30-40 seconden of langer duurt, wordt het aantal taken verminderd. De mapper of verloopstuk proces omvat de volgende dingen:eerst moet u JVM starten (JVM geladen in het geheugen). Vervolgens moet u JVM initialiseren. En na verwerking (mapper/reducer) moet u JVM de-initialiseren. En deze JVM-taken zijn erg kostbaar. Stel dat een mapper een taak slechts 20-30 seconden uitvoert. Hiervoor moeten we JVM starten/initialiseren/stoppen. Dit kan een aanzienlijke hoeveelheid tijd kosten. Het wordt dus ten strengste aanbevolen om de taak minstens 1 minuut uit te voeren.
- Als een taak meer dan 1 TB aan invoer heeft. Overweeg dan om de blokgrootte van de invoerdataset te vergroten naar 256M of zelfs 512M. Het aantal taken zal dus kleiner zijn. U kunt de blokgrootte wijzigen met het commando Hadoop distcp –Hdfs.block.size=$[256*1024*1024] /path/to/inputdata /path/to/inputdata-with-largeblocks
- Zoals we weten, duurt elke taak minstens 30-40 seconden. U moet het aantal mapper-taken verhogen tot een veelvoud van het aantal mapper-slots in het cluster.
- Voer niet te veel reductietaken uit - voor de meeste taken. Het aantal reduceertaken gelijk aan of iets minder dan het aantal reduceerslots in het cluster.
4. Combiner tussen Mapper en Reducer
Als het algoritme het berekenen van aggregaten van welke aard dan ook omvat, moeten we een Combiner gebruiken. Combiner voert enige aggregatie uit voordat de gegevens de reducer bereiken.
Het Hadoop MapReduce-framework wordt op intelligente wijze gecombineerd om de hoeveelheid gegevens die naar schijf moet worden geschreven, te verminderen. En die gegevens moeten worden overgedragen tussen de stadia Map en Reduce van de berekening.
5. Gebruik van het meest geschikte en compacte schrijfbare type voor gegevens
Big data-gebruikers gebruiken onnodig het schrijfbare type Tekst om over te schakelen van Hadoop Streaming naar Java MapReduce. Tekst kan handig zijn. Het is inefficiënt om numerieke gegevens van en naar UTF8-tekenreeksen te converteren. En kan zelfs een aanzienlijk deel van de CPU-tijd uitmaken.
6. Hergebruik van schrijfwaren
Veel MapReduce-gebruikers maken een veelgemaakte fout, namelijk het toewijzen van een nieuw schrijfbaar object voor elke uitvoer van een mapper/reducer. Stel, bijvoorbeeld, de implementatie van de woordentelling mapper als volgt:
public void map(...) {
...
for (String word: words) {
output.collect(new Text(word), new IntWritable(1));
} Deze implementatie zorgt voor de toewijzing van duizenden kortlevende objecten. Hoewel Java-afvalverzamelaar hier redelijk goed mee omgaat, is het efficiënter om te schrijven:
class MyMapper ... {
Text wordText = new Text();
IntWritable one = new IntWritable(1);
public void map(...) {
... for (String word: words)
{
wordText.set(word);
output.collect(word, one); }
}
} Conclusie
Daarom zijn er verschillende MapReduce-taakoptimalisatietechnieken die u helpen bij het optimaliseren van de MapReduce-taak. Zoals het gebruik van combiner tussen mapper en Reducer, door gebruik van LZO-compressie, juiste afstemming van het aantal MapReduce-taken, hergebruik van schrijfbaar.
Als u een andere techniek voor MapReduce-taakoptimalisatie vindt, laat het ons dan weten in de commentaarsectie hieronder.