MapReduce: diferència entre les revisions

Contingut suprimit Contingut afegit
He afegit referències
Línia 84:
=== ''Output writer'' ===
L'''output writer'' escriu la sortida de la funció ''Reduce'' en memòria.
 
== Consideracions de Rendiment ==
No es garanteix que els programes MapReduce siguin ràpids. El principal avantatge d'aquest model de programació és explotar l'operació shuffle optimitzada de la plataforma, i només haver d'escriure les parts Map i Reduce del programa. No obstant això, en la pràctica, l'autor d'un MapReduce ha de tenir en compte el shuffle, ja que la quantitat de dades escrites per la funció Map pot tenir un gran impacte en el rendiment i l'escalabilitat.
 
La majoria d'implementacions de l'algorisme de MapReduce, requereixen escriure a memòria totes les comunicaciones, és per això que el cost de comunicació sovint domina al cost de computació. Per l'autor de l'algorisme és essencial equilibrar els dos costos.
 
Per tal de calcular el rendiment de MapReduce, cal tenir en compte la complexitat del mapping, el shuffle, l'ordenació (agrupació per la clau) i el reduce. La quantitat de dades produïdes en l'etapa de la funció de map, és un paràmetre clau que ens indicarà on es trobarà la major part del cost computacional (map o reduce). La reducció inclou l'ordenació que té una complexitat no lineal. Per tant, les divisions en grups petits de les dades redueixen el temps de classificació, però fins a un límit, ja que un gran nombre de reductors pot ser poc pràctic.
 
Per als processos que es completen ràpidament, i en els quals les dades caben en la memòria principal d'una sola màquina o d'un petit clúster, l'ús d'un framework MapReduce no sol ser eficaç. Aquests frameworks estan dissenyats per a recuperar-se de la pèrdua de nodes sencers durant la computació, és per això que escriuen els resultats intermedis en memòria distribuïda. Aquesta recuperació de fallades és costosa, i només resulta rendible quan el còmput implica molts ordinadors i un llarg temps d'execució del còmput. Una tasca que es completa en segons només pot reiniciar-se en cas d'error, i la probabilitat que almenys una màquina falli creix ràpidament amb la grandària del clúster. En aquesta mena de problemes, les implementacions que mantenen totes les dades en memòria i simplement reinicien un càlcul en cas de fallada d'un node o -quan les dades són prou petits- les solucions no distribuïdes seran sovint més ràpides que un sistema MapReduce.
 
== Distribució i Fiabilitat ==