Improving MapReduce Performance in Heterogeneous Environments

Improving MapReduce Performance in Heterogeneous Environments Minwei CHEN Université Claude Bernard Lyon 1 Master Recherche en Informatique M2 Technologies de l information et Web Email pro: minwei.chen@etu.univ-lyon1.fr CONTENTS I Intro 1 I-A Thématique générale.......... 1 I-B Principales conférences et revues du domaine................... 1 I-C Principaux laboratoires et auteurs du domaine................. 1 I-D Les auteurs de l article......... 2 I-E La conférence ou la revue dans laquelle l article est paru............. 2 I-F Problème que l article vise à résoudre. 2 II Résumé des contributions de l article 2 II-A Contexte................. 2 II-B Le planificateur LATE.......... 3 III Critique 3 III-A Critique de la partie état de l art.... 3 III-B Critique de l évaluation des résultats.. 4 III-C Autres points forts et points faibles.. 5 IV Impact de l article 5 References 5 Abstract Cet article a introduit les techniques natives de planification dans Apache Hadoop. Connaissant les points faibles du mécanisme et des stratégies par défaut dans les environnements hétérogènes, les auteurs ont proposé un nouveau planificateur avec une nouvelle stratégie ainsi que les tests de performances. Les auteurs ont trouvé des hypothèses invalides lors que l on est dans les systèmes cloud virtualisés, et c est le premier qui a pensé aux impacts du planificateur d Apache Hadoop sur les performances en milieu hétérogène, sachant que ce sujet est de plus en plus critique dans la production. Cependant, les auteurs ont laissé des travaux non-finis. La solution proposée pourrait considérer davantage les tâches map, l algorithme n est pas parfait dans certains cas et pourrait être mieux détaillé. De plus, les environnements cible pourraient être plus variants. I. INTRODUCTION A. Thématique générale dont fait partie l article Aujourd hui, la quantité de données liée aux connaissances humaines est en croissance exponentielle. Nous avons de plus en plus besoin de nouvelles technologies pour traiter et analyser efficacement des données échangées. En 2004, les chercheurs de Google ont publié le fameux modèle MapReduce qui est devenu vite la référence pour les calculs parallèles distribués. Un an plus tard, inspiré par ce modèle et deux autres articles de Google(Google File System et Big Table), deux employés de Yahoo! ont créé Hadoop, qui est maintenant le framework le plus utilisé dans le monde entier. Il permet aux applications de travailler avec des milliers de nuds et des pétaoctets(1po = 1000To) de données. Comme il a été déployé davantage sur les infrastructures différentes, notamment celles cloud, les gens ont distingué des inconvénients en milieu homogène(e.g. Amazon EC2, Microsoft Azure, etc). Ces points faibles réduisaient considérablement les performances de Hadoop dans ces environnements, donc il était nécessaire de trouver une solution. B. Principales conférences et revues du domaine Cette publication est plutôt dans le domaine des réseaux et communications, dont les conférences importantes sont comme IEEE INFOCOM, MOBICOM (Mobile Computing and Networking) et ACM SIGCOMM Conference. Dans un autre domaine voisin de calculs parallèles et distribués, on a ICDCS (International Conference on Distributed Computing Systems), PODC (Symposium on Principles of Distributed Computing), etc. Pour le domaine spécifique de MapReduce, VLDB conference et IEEE Big Data conference sont les deux les plus connues. Au niveau de revues, les principales dans ces domaines sont comme CACM (Communications of The ACM), TCOM (IEEE Transactions on Communications), TOCS (ACM Transactions on Computer Systems), TPDS (IEEE Transactions on Parallel and Distributed Systems). Pour le domaine spécifique de MapReduce, VLDB journal est le journal de la plus haute qualité. C. Principaux laboratoires et auteurs du domaine Pour les principaux laboratoires du domaine, à part du laboratoire AMP de l Université de Californie à Berkeley, il y a aussi de nombreux qui ont fait des travaux brillants : par exemple les laboratoires de Google et de Microsoft, le laboratoire GRIDS - Grid Computing and Distributed Systems

Laboratory de l Université de Melbourne, le groupe de bases de données de L université Yale, etc. Quant aux auteurs, à part les deux chercheurs Jeffrey Dean et Sanjay Ghemawat qui ont publié l article fondamental MapReduce, les trois derniers co-auteurs ont tous publié plusieurs articles de haute qualité. Beaucoup d autres auteurs comme Scott J. Shenker ont contribué au développement de ce domaine. D. Les auteurs de l article Tous les auteurs, Matei Zaharia, Andy Konwinski, Anthony D. Joseph, Randy H. Katz, Ion L. Stoica travaille actuellement dans le laboratoire AMP - ALGORITHMS MACHINES PEO- PLE de l Université de Californie à Berkeley, de la discipline Computer Science. Etant étudiant en doctorat dans ce dernier laboratoire, Maeti Zaharia concentre sur la gestion de données à très grande échelle pour les calculs intensifs. Il a publié une vingtaine d articles de haute qualité pendant les années précédentes y compris ceci. Andy Konwinski est un chercheur postdoctoral qui fixe son attention sur les systèmes distribués à grande échelle. Anthony D. Joseph est un professeur de la faculté informatique et il a commencé à publier des articles depuis l année 1991. Ses principaux champs de recherche sont l apprentissage automatique, Datacenters et la conception des systèmes mobiles distribués. Finalement, Randy H. Katz et Ion L. Stoica sont deux spécialistes très connus dans le domaine réseau et systèmes distribués. Ils sont aussi professeurs du département Génie Electrique et Informatique. Ion L. Stoica est le membre principal du projet P2P subventionné Chord et du projet Apache Spark (un système open source pour les grappes de serveurs). D ailleurs, la plupart des cinq auteurs sont contributeurs principaux du projet Apache Spark, qui est en plein essor. E. La conférence ou la revue dans laquelle l article est paru La conférence OSDI (Operating Systems Design and Implementation) où l article a été publié est une conférence annuelle sur le système d exploitation. Créée en 1994 par USENIX, environ 100-200 articles ont été soumis chaque année, parmi lesquels 10-20% ont finalement été acceptés (http://www.lamsade.dauphine.fr/~sikora/ratio/confs.php). F. Problème que l article vise à résoudre Comment peut-on mieux effectuer l exécution spéculative dans Hadoop afin d optimiser les performances. II. RÉSUMÉ DES CONTRIBUTIONS DE L ARTICLE Apparu dans l acte de conférence OSDI 2008, cet article est devenu vite un document de référence concernant l amélioration de performances pour les services basés sur les technologies MapReduce et Apache Hadoop. A. Contexte Fig. 1. Un exemple de MapReduce Dans un premier temps, il faut savoir comment Hadoop planifie des tâches et connaître quelles sont des éléments qui pourraient être erronnés. L implémentation de MapReduce dans Hadoop est similaire à celle native de Google [1]. Fig. 1 indique les procédures MapReduce. Concrètement, avec un seul master et plusieurs slaves gérés par ce master, les données à traiter qui se situent dans un système de fichiers distribué sont découpées en chunks d une taille unique. Ces chunks sont dupliqués afin d obtenir une meilleure tolérance aux fautes. Puis, chaque chunk est introduit dans une série de tâches : d abord la tâche map qui produit une liste de clés-valeurs générée par une fonction prédéfinie. Lors que toutes les tâches map sont terminées, les tâches reduce commencent à traiter la liste de clés-valeurs selon les clés dedans. Sachant que les tâches sont distribuées dans des slaves différents et donc sont parallèles, il existe un mécanisme de synchronisation - le planificateur qui distribue les tâches aux slaves qui ont des créneaux vides. Une stratégie importante est l exécution speculative dont le but est de réduire le temps de réponse des tâches. Quand un noeud(slave) a des créneaux vides, Hadoop choisit une tâche parmi ces trois catégories pour lui : 1)Tâches échouées, 2)Tâches pas encore commencées, 3)Tâches au choix pour l exécution spéculative(celles lentes ou moins finies). Avec l exécution spéculative, Hadoop cherche des tâches lentes à distribuer aux autres noeuds en utilisant un algorithme par défaut : une tâche map est divisée en copy et sort, puis copy, sort et reduce compte chacune un tiers du taux de terminaison. Enfin, Hadoop peut obtenir la priorité : en ajoutant ces trois chiffres, on peut calculer le taux d exécution des tâches qui s appelle aussi la note de progression. Toutes les tâches qui ont une note de moins de 0,2 et qui durent plus de 60 secondes sont marquées comme traînard, c est-à-dire celles qui sont les moins terminées. Ces traînards sont ensuite distribués en premier lieu. Hadoop considère aussi que les

tâches a une tendance d arriver et de sortir en vagues. Alors, en faisant des recherches, les auteurs ont trouvé six hypothèses établies au cours de la conception d Hadoop, et ont finalement prouvé que cinq des six ne sont pas validées au sein d un milieu hétérogène : Dans un environnement virtualisé, il est impossible de garantir la même débit et délai des noeuds, il existe trop de facteurs incertains comme le sous-système de stockage et l état du réseau. L exécution spéculative n est jamais gratuite car l algorithme est trop approximatif. En fait, pour cette raison, parfois on doit le désactiver pour avoir une meilleure performance. En réalité, les tâches copy, sort et reduce ne respectent pas une proportion de temps d exécution fixe, et donc on ne peut pas non plus dire qu une tâche est vraiment un traînard si elle n a pas une bonne note, puisque le système de note n est déjà pas correct. B. Le planificateur LATE Les auteurs ont implémenté un nouveau planificateur spéculatif qui contourne ces hypothèses invalides. L idée principale est d estimer les tâches dans l autres sens : le planificateur natif calcule le taux d exécution donc le pourcentage d achèvement d une tâche, alors ce nouveau essaie de savoir dans combien de temps une tâche va finir. Avant, un traînard est ce qui le moins fini, et maintenant c est la tâche qui va se terminer le plus tard. Voici le nouvel algorithme : On estime le taux d exécution d une tâche comme note de progression/t, où T égale au temps déjà écoulé. En faisant une soustraction, on aura le temps resté estimé. On calcule la vitesse d un noeud en additionnant toutes les tâches éffectuées dans ce noeud. SpeculativeCap est le nombre maximal des tâches speculatives sur un noeud à un moment donné. Cette valeur est prédéfinie et modifiable. SlowNodeThreshold est la limite des tâches effectuées par un noeud, en dessous de laquelle le système le considèrera incapable d ecécuter plus de tâches d exécution speculative. SlowTaskThreshold est la limite de la vitesse de progression d une tâche, en dessous de laquelle cette tâche sera "suffisamment lente" et prête à être distribuée à un noeud "capable" pour l exécution spéculative. Les trois dernières valeurs heuristiques sont à choisir manuellement. Voici deux exemples : Pour deux tâches lentes, si l une avec 90% finie est 5 fois plus lente que la moyenne et l autres avec 10% finie est 2 fois plus lente que la moyenne. Au cas où le temps resté de la première est estimé plus long que celui de la deuxième, cette première est distribuée plus tôt à un autre noeud pour l exécution speculative, même si la deuxième est quantitativement plus proche de la fin. Fig. 2. Un exemple simplifié de l exécution spéculative Si le nombre de tâches traitées d un noeud est inférieur à SlowNodeThreshold, ce noeud est considéré comme pas assez puissant. Le système va distribuer d abord les tâches aux noeuds qui sont plus capables pour les exécutions spéculatives. Généralement, on considère les deux côtés : le pourcentage fini d une tâche et la capacité - donc la vitesse d exécution des noeuds qui demandent de nouvelles tâches. III. CRITIQUE A. Critique de la partie état de l art Comment évaluer l efficacité et les possibilités d amélioration des services MapReduce offerts aux utilisateurs était un gros sujet pendant quelques années après la sortie du principe de MapReduce. Il était encore plus intéressant de redarder en même temps les environnements virtualisés cloud sachant que les services comme EC2 qui ont comme solution la possibilité de fournir un système de plusieurs noeuds sont en train de devenir non seulement le premier choix de milliers de startups(par exemple Facebook en 2008), mais aussi une alternative idéale pour beaucoup d établissements de recherche qui cherchent une capacité permettant d effectuer leurs calculs en masse. En ce moment-là, la plupart des articles concernant MapReduce s agissaient des rapports d évaluations [5] et des applications relativement simples [6]. Certains articles [7] [8] avaient commencé à discuter les mécanismes de la planification au sein d un groupe de serveurs, cependant, suite de l essor des services cloud, il ne fallait pas rester seulement dans les systèmes multi-processus et multi-threadé, c était le moment de toucher les environnements hétérogènes. Certains avaient essayé d identifier les tâches lentes [9], mais personne n avait lié ces aspects ensemble. Ensuite, un point illustre est que les auteurs ont trouvé que l exécution spéculative pourrait être un bon chemin de recherche. Imaginons que dans un système où les données sont distribuées dans plusieurs noeuds Fig. 2, quand les exécutions normales ont eu des soucis, par exemple un échec de disque dur, les autres noeuds peuvent constater la latence anormale

Fig. 3. Une preuve de l algorithme à amélioer puis vont commencer à traiter les données qui ont rencontré cet échec de disque. L exécution parallèle dans Hadoop était un champ innovant à attaquer, cependant, les articles [10] et [11] ne fournissaient pas une vue systématique en traitant principalement la prévision de branches selon probabilité mais pas la sélection de tâches à exécuter. Or, étant un sujet non traité, ce dernier pourrait être plus fiable. Même les seules références, le tout premier article [1] et un autre article publié en 2008 par les deux auteurs originaux [12] n ont pas découvert plus profondémment pour cette partie, qui pourrait surmonter les limites prétendues des autres travaux, et qui serait un point intéressant sur les systèmes de traitement intensif de données et sur les services cloud à grande échelle. Or, les auteurs n ont pas continué à chercher plus loin à cause de plusieurs raisons possibles. Avec le nouvel algorithme contenant trois variables heuristiques cité dans la partie 4, cet article a laissé un espace d amélioration des performances du délai de réponse en cas général. Une des conséquences est l existence d insuffisance de l algorithme, parce que l architecture du planificateur LATE n est pas parfaitement implémentée. Peut-être les auteurs voulaient juste donner une idée ou une orientation de recherche, alors ce point insuffisant est directement visible par les tests : Dans les pires cas comme Fig. 3, les performances obtenus avec le nouveau planificateur LATE pourrait être encore pire que sans rien. Même si ces cas ne sont pas ordinaires, de toute façon, ceci n est pas un bon symbol. Sur ce niveau, cet article n a pas beaucoup avancé par rapport aux autres travaux. Il vaudrait mieux donner au moins des indications pour les cas extrêmes. B. Critique de l évaluation des résultats Au moment de la publication de l article, il n y avait pas encore beaucoup d autres auteurs travaillant dans ce sens. En effet, étant un nouveau algorithme, l apparition de cet article nous a fourni un bon indicateur d amélioration de la qualité des services basés sur MapReduce. Dans la section 5, les auteurs ont éffectué les tests par quatre blocs suivants : Les tests concernant les impacts sur les performances des entrées/sorties des machines virtualisées dans EC2, pour donner une idée de la mesure d hétérogénéité. Les tests sur les temps de réponse, dans un environnement hétérogène d Amazon EC2 et puis dans un environnement local virtualisé. Ces tests ont prouvé que ce planificateur plus sérieux donne des performances de 20% à 220% meilleures que celles de l ancien planificateur. Les tests sur la sensibilité du choix de SpeculativeCap, SlowTaskThreshold et SlowNodeThreshold. La première évaluation supporte les deux suivants en prouvant l hétérogénéité des performances en raison de l effet de la contention. Dans des groupes de machines avec tailles différentes au sein d Amazon EC2, il existe un coefficient d environ 2,5 entre les meilleures et les pires performances des entrées/sorties, lors que plusieurs machines virtuelles sont hébergées dans un même host physique. Comme ce qu il est indiqué par les auteurs, ce test a été fait sur les machines virtuelles small sur EC2. Ce test est nécessaire pour montrer l erreur de certaines hypothèses du mécanisme natif, et en même temps, il comfirme l importance et la possibilité d une solution mieux améliorée. La deuxième et la troisième évaluation permettent d avoir des résultats quantitatifs. En faisant une série de tests de comparaison, nous pouvons voir la progression du nouveau planificateur LATE. La deuxième s est passée au sein d un environnement hétérogène sur Amazon EC2. Les tests ont été exécutés conséquemment dans les grilles de 100 et 243 machines, avec distinctement d un à sept et d un à sept machines virtuelles sur chacune des machines physiques, avec les benckmarks Sort, Grep et WordCount d Hadoop. La troisième s est passée au sein d un environnement local virtualisé, avec prèsque les mêmes tests de la deuxième évaluation. La quatrième partie concernant la sensibilité liée aux choix de SpeculativeCap, SlowTaskThreshold et SlowNodeThreshold, donc les trois principaux variables de la speculation. Les tests nous donnent des résultats indicatifs non seulement de l ajustement du planificateur, mais aussi de la variance des performances d un tel algorithme. Cette phase s est effectuée au sein d un environnement local puisqu il y avait un bug sur EC2. La tâche Sort a été utilisée comme la charge pour les tests. Les tests éffectués sont généralement rigoureux et ont finalement prouvé les affirmations des auteurs : tous les tests ont été répétés plusieurs fois pour le but d éliminer les facteurs instables. Comparé aux solutions existantes en ce momentlà, nous pouvons avoir une vue quantitative détaillée qui est en même temps assez concrète. Personnellement, en connaissant les architectures des systèmes actuellement utilisés, les sujets de tests ont été bien choisi pour mesurer les délais de réponse. Un petit bémol pourrait être que les tests pourraient contenir plus de variables, donc il vaudrait mieux avoir plus de combinaison des tâches et des configurations dans les tests : les chercheurs et les techniciens seront souvent plus satisfaits d avoir des tableaux de comparaison avec des statistiques plus détaillés. Par exemple, la taille des grilles de machines pourrait être un facteur à inclure dans les tests, puisqu il y a souvent une grande différence d utilisation entre les systèmes de tailles

variées. Enfin, par manque de ressources et de connaissance, je n ai pas pu déployer un même environnement pour tester. Or avec la concultation des documents [2] [3] et les indications décrites dans l article, l expérience avec un environnement localement virtualisé et avec une groupe de machine EC2 marché sur Hadoop, donc ce que les auteurs ont fait devrait être reproductible en donnant suffisamment de temps. C. Autres points forts et points faibles En fait, principalement deux autres points faibles potentiels, à part des tests qui pourraient être plus peuplés et plus complets, ont été trouvés pendant la lecture de cet article. D une part, au début, les auteurs ont décidé de travaliier avec les machines virtuelles de petites tailles qui proposaient un meilleur rapport de qualité-prix, ou plutôt performance-prix. Cependant, de nos jours, les machines virtuelles de grandes tailles sont beaucoup utilisées, pour les besoins spécifiques. Le manque de ce côté pourrait être un dommage au moins pour les applications liée. D autre part, l estimation du temps d exécution resté n est pas parfaite selon des cas : pour des tâches non typiques d Hadoop, l algorithme heuristique pourrait mal estimer ce temps. Sinon, pour le reste, les auteurs ont pu repérer un nouveau point donc les nouveaux variables d optimisation d Hadoop. Comme la distributeur de tâches et les services de parallélisation, le planificateur configurable est un composant important de la plateforme Hadoop et doit entrer dans la vision. De plus, c est bien pour les papiers ayant un objectif applicatif d avoir les tests analytiques comme ceux-ci. En conclusion, pour la totalité du travail, personnellement je n ai pas pu généré plus de critiques. Les articles fournissant la nouvelle vision et l utilisation des plateformes clous [15] [16] ont pu mieux réfléchir les impacts des fausses hypothèses préliminairement proposées par les plateformes intégrées dans les environnements hétérogènes. D ailleurs, les auteurs de ces articles ont pu mieux comprendre le principe des tests au sein des environnements hétérogènes. Les articles traitant la combinaison des deux côtés [18] [19] nous ont donné de noubreuses nouvelles idées innovantes par exemple l optimisation du partage de ressources dans une grille informatique et l amélioration des architectures multi-tâches pour les utilisations scientifiques, dans les environnements cloud comme Amazon EC2. Plusieurs parmi ces articles qui ont cité l article parlé ont aussi redigé par au moins un des cinq auteurs de cet article [13]. D ailleurs, nous ne pouvons pas nier que de plus en plus de nouveaux travaux réalisés [20] [21] [22] [23] ont hérité les stratégies initialement conçues par cet article : les influences de la configuration de MapReduce sur les tâches différentes, les performances en fonction du choix de planificateur, la pertinence du paramétrage et de l algorithme appliqué de planificateur, l importance de l exécution spéculative pour Hadoop au sein d un environnement hétérogène, etc. Suite aux impacts provoqués, plusieurs projets [24] [25] [26] ont aussi été lancé pour objectif de surmonter les limitations des environnements actuels de MapReduce comme Hadoop et de permettre ainsi le traitement de données à ultragrande échelle sur diverses architectures comme les clouds, les grilles de PC et les infrastructures hybrides construites en combinant ces types d architectures, en réfléchissant sur le côté d hétérogénéité, le planificateur d Hadoop et le mécanisme global de la distribution de tâche. IV. IMPACT DE L ARTICLE Cet article a été cité 112 fois selon ACM et 605 fois selon Google Scholar, c est déjà un chiffre considérable dans la communauté de MapReduce même celle de BigData et de Cloud Computing. Inspiré par cet article : Les articles concernant l implémentation de nouvelles fonctionnalités de MapReduce [12] ont commencé à chercher des outils supplémentaires par exemple les moniteurs de tâches qui pourraient améliorer les performances des systèmes en traçant les comportements de ressources. Les articles concernant l organisation de la planification au sein des systèmes basés sur Hadoop [13] [14] ont pu mieux comprendre l effet des traînards pendant des tâches parallèles. Certains ont pu mieux améliorer les argorithmes de la balance et le positionnement de tâches pour les systèmes sous charge dans les sénarios où les groupes de serveurs ont une grande quantité de données à traiter, avec un coût généralement limité et des machines virtuelles variées. REFERENCES [1] J. Dean and S. Ghemawat. MapReduce: Simplified Data Processing on Large Clusters. In Communications of the ACM, 51 (1): 107-113, 2008. 2, 4 [2] Tom White. Hadoop:The Definitive Guide,3rd Edition. O Reilly Media and Yahoo Press, May 2012 5 [3] Amazon Elastic Compute Cloud (Amazon EC2). aws.amazon.com/ec2 5 [4] B.Dragovic, K.Fraser, S.Hand, T.Harris, A.Ho, I.Pratt, A.Warfield, P.Barham, and R.Neugebauer. Xen and the art of virtualization. ACM SOSP 2003. [5] Ranger, Colby, et al. Evaluating mapreduce for multi-core and multiprocessor systems. High Performance Computer Architecture, 2007. HPCA 2007. IEEE 13th International Symposium on. IEEE, 2007. 3 [6] Yang, Hung-chih, et al. Map-reduce-merge: simplified relational data processing on large clusters. Proceedings of the 2007 ACM SIGMOD international conference on Management of data. ACM, 2007. 3 [7] Mor Harchol-Balter, Task Assignment with Unknown Duration. Journal of the ACM, 49 (2): 260-288, 2002. 3 [8] M.Crovella, M.Harchol-Balter, and C.D. Murta. Task assignment in a distributed system: Improving performance by unbalancing load. In Measurement and Modeling of Computer Systems, pp. 268-269, 1998. 3 [9] J. Bernardin, P. Lee, J. Lewis, DataSynapse, Inc. Using Execution statistics to select tasks for redundant assignment in a distributed computing platform. Patent number 7093004, filed Nov 27, 2002, issued Aug 15, 2006. 3 [10] E.B. Nightingale, P.M. Chen, and J.Flinn. Speculative execution in a distributed file system. ACM Trans. Comput. Syst., 24 (4): 361-392, November 2006 4

[11] G. Barish. Speculative plan execution for information agents. PhD dissertation, University of Southernt California. Dec 2003 4 [12] J Dean, S Ghemawat. MapReduce: simplified data processing on large clusters. In Communications of the ACM, 2008 4, 5 [13] Zaharia, Matei, et al. Delay scheduling: a simple technique for achieving locality and fairness in cluster scheduling. Proceedings of the 5th European conference on Computer systems. ACM, 2010. 5 [14] Chohan, Navraj, et al. "See spot run: using spot instances for mapreduce workflows." Proceedings of the 2nd USENIX conference on Hot topics in cloud computing. USENIX Association, 2010. 5 [15] Buyya, Rajkumar, et al. Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility. Future Generation computer systems 25.6 (2009): 599-616. 5 [16] Iosup, Alexandru, et al. Performance analysis of cloud computing services for many-tasks scientific computing. Parallel and Distributed Systems, IEEE Transactions on 22.6 (2011): 931-945. 5 [17] Ananthanarayanan, Ganesh, et al. "Reining in the Outliers in Map- Reduce Clusters using Mantri." OSDI. Vol. 10. No. 1. 2010. [18] Isard, Michael, et al. Quincy: fair scheduling for distributed computing clusters. Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles. ACM, 2009. 5 [19] Ananthanarayanan, Ganesh, et al. "Reining in the Outliers in Map- Reduce Clusters using Mantri." OSDI. Vol. 10. No. 1. 2010. 5 [20] Rizvandi, Nikzad Babaii, et al. "A study on using uncertain time series matching algorithms for MapReduce applications." Concurrency and Computation: Practice and Experience (2012). 5 [21] Xie, Jiong, et al. "Improving mapreduce performance through data placement in heterogeneous hadoop clusters." Parallel and Distributed Processing, Workshops and Phd Forum (IPDPSW), 2010 IEEE International Symposium on. IEEE, 2010. 5 [22] Chen, Qi, Cheng Liu, and Zhen Xiao. "Improving MapReduce Performance Using Smart Speculative Execution Strategy." (2013): 1-1. 5 [23] Afrati, Foto N., et al. "Designing good algorithms for MapReduce and beyond." Proceedings of the Third ACM Symposium on Cloud Computing. ACM, 2012. 5 [24] Current Big Data projects. University of Washington. www.cs.washington.edu 5 [25] News of Hadoop projects. blog.cloudera.com/blog/category/hadoop/ 5 [26] Project suggestions - Apache Hadoop. wiki.apache.org/hadoop/projectsuggestions 5