\section{Contexte scientifique}

Dans un article publié dans la revue américaine Nature en 1960 (\cite{MathematicsNature}), Eugène Wigner s'intéresse à la capacité surprenante des mathématiques à formaliser, de manière souvent très concise, les lois de la nature. Un récent article intitulé \og The unreasonable effectiveness of data \fg (\cite{DataEffectiveness}) en propose un éclairage nouveau. Reprenant avec ironie une partie du titre de l'article d'Eugène Wigner, ses auteurs défendent la thèse selon laquelle les comportements humains ne se modélisent pas comme les particules élémentaires, et que des formules ne peuvent donner de réponse satisfaisante à de nombreux problèmes dans lequel des facteurs humains ou économiques ont un rôle important. Les auteurs proposent plutôt d'adopter un point de vue plus centré sur les données que sur un modèle spécifique. Forts de leur expérience appliquée chez Google, ils décrivent comment des algorithmes simples appliqués à des bases de données gigantesques peuvent fournir de meilleurs résultats que des algorithmes plus fins, appliqués à des bases de données plus petites.\\

Cet article illustre un phénomène nouveau : alors que de nombreux champs du savoir sont limités par un manque de données pour confirmer ou infirmer des théories, d'autres champs sont désormais confrontés au problème inverse qui consiste à réussir à exploiter des masses de données très volumineuses, souvent désignées par le terme \og Big Data \fg. Certains travaux avancent même que la manipulation et l'utilisation intelligente de ces immenses jeux de données pourrait devenir un nouveau pilier de la recherche scientifique au même titre que la théorie, l'expérimentation et la simulation (\cite{FourthParadigm}). D'autres travaux encore, comme ceux de Lin et Dyer dans \cite{MapReduceForTextMining}, soulèvent l'hypothèse que certains algorithmes, incapables de passer à l'échelle et de s'appliquer sur des gros volumes de données, risquent d'être délaissés par les praticiens et de se retrouver réduits au statut d'algorithmes jouets.\\

En statistiques comme ailleurs, le lien avec l'informatique se resserre donc, ouvrant des enjeux inter-disciplinaires en parties mésestimés il y a encore quelques années. Sur un plan théorique, cette multi-disciplinarité est déjà représentée en statistiques par des branches comme l'apprentissage statistique (machine-learning) ou les statistiques bayésiennes. Sur un plan pratique, elle était jusque récemment la chasse gardée de géants tels que Google (20 Pétaoctets de données analysées par jour en 2008 selon \cite{MapReduce2008}), de Youtube (2 milliards de vidéos visionnées par jour dès 2010 selon \cite{WebSiteMonitoring}), ou encore le projet européen du Large Hadron Collider (15 péta-octets par an). Elle s'est démocratisée et touche aujourd'hui un public bien plus large et se retrouve même au coeur des enjeux technologiques de nombreuses startups.\\

Comment gérer cette quantité phénoménale de données et de calculs? Une réponse possible est celle de répartir les tâches sur un ensemble d'unités de calcul et de stockage plutôt que de se restreindre à une seule machine. Comme expliqué dans l'ouvrage de Lin et Dyer (\cite{MapReduceForTextMining}), cette idée n'est pas nouvelle : en 1990, Leslie Valiant dans \cite{BridgingModel} faisait déjà le constat que l'avènement annoncé du calcul parallèle n'avait pas encore eu lieu. Bien que la démocratisation des algorithmes répartis soit annoncée partiellement en vain depuis des décennies, certains éléments portent à croire que s'entame actuellement ce phénomène. Tout d'abord, l'affaiblissement sensible des progrès dans la cadence des processeurs ne permet plus de résoudre les problèmes logiciels par l'attente de dispositifs matériels plus performants. Ensuite, la volonté de diminuer les consommations énergétiques des unités de calcul (pour améliorer l'autonomie mais aussi diminuer les coûts) tend à multiplier les coeurs des processeurs plutôt que leur cadence (on retrouve déjà ce phénomène par exemple dans l'Amiga ou plus récemment dans de nombreux smartphones qui multiplient les processeurs dédiés). D'un point de vue pratique, la solution du calcul réparti sur de nombreuses machines est d'ailleurs celle retenue le plus souvent par les géants cités précédemment.\\

La recherche et l'enseignement en statistiques devraient donc dans les années à venir offrir une place toujours plus grande à l'étude d'algorithmes répartis. Cette thèse s'inscrit dans cette thématique et a pour objet l'étude de la parallélisation de certains algorithmes de clustering.\\

\section{Contexte de la thèse}

Cette thèse est le fruit d'une collaboration entre la société Lokad et Télécom ParisTech.\\

Lokad est une jeune société éditrice de logiciels, spécialisée dans la prévision statistique de séries temporelles. Ces prévisions sont vendues à des entreprises pour gérer et optimiser leurs flux de clients, d'appels ou de stocks. Les clients principaux de Lokad sont les acteurs de la grande distribution, les e-commerces, etc. Pour rendre facilement exploitables ces prévisions, Lokad propose des logiciels en mode Software as a Service (SaaS), c'est-à-dire des applications hébergées par ses soins et accessibles directement depuis Internet, qui utilisent ces prévisions pour fournir des outils d'aide à la décision. Lokad fournit par exemple, via son application SalesCast, un système de gestion des stocks en déterminant les niveaux de stock à maintenir et les réapprovisionnements à effectuer. Lokad propose également, via son application ShelfCheck, un outil de détection d'indisponibilité d'un produit en rayonnage, reposant lui aussi sur des prévisions de ventes de produits.\\

Deux caractéristiques de Lokad inscrivent cette société dans les thèmes de calcul intensif et donc parallèle.\\

La première de ces caractéristiques est le caractère SaaS des logiciels développés par Lokad. Une utilisation classique des services de Lokad se déroule de la manière suivante : une application SaaS se charge d'accéder à la base de données du client ; cette application envoie les données via le réseau sur les serveurs de Lokad ; le moteur interne de prévision statistique s'applique ensuite aux données pour fournir des prévisions ; les prévisions sont enfin retournées au client via le réseau. Cette approche permet à Lokad d'avoir un contrôle fin sur la qualité des prévisions qu'elle délivre, mais elle implique que l'intégralité des tâches de calcul soit effectuée par les serveurs de Lokad.\\

La seconde de ces caractéristiques est la gestion automatisée des prévisions. Lokad a développé un moteur interne de prévision de séries temporelles qui ne requiert pas de travail direct d'un statisticien : pour chaque série temporelle à prévoir, ce moteur évalue la précision de chacun des modèles disponibles en production par validation croisée, et sélectionne automatiquement les prévisions du modèle le plus précis pour la série. L'automatisation des prévisions permet à Lokad de répondre à la demande de certaines entreprises dont la taille des données rendait très difficile des prévisions plus manuelles. C'est le cas par exemple de la grande distribution, où chaque enseigne possède des centaines de points de vente, et où le nombre de produits par point de vente peut atteindre 50 000 références. Cette automatisation implique également que la quantité de calcul à fournir est au moins proportionnelle au nombre de séries temporelles à prévoir, mais aussi au nombre de modèles et au nombre de points de validation croisée par modèle. Ainsi l'automatisation vient au prix de calculs bien plus intensifs.\\

Parallèlement, Télécom ParisTech est un acteur européen de référence dans les domaines des Sciences et Technologies de l'Information et de la Communication (STIC). Son laboratoire BILab, qui travaille en partenariat avec EDF, est spécialisé dans les technologies de l'aide à la décision, plus connues sous le nom de Business Intelligence (BI). En particulier, le BILab s'intéresse aux questions afférentes à la prévision statistique. En raison de la taille d'EDF, ces questions à l'origine statistique deviennent aussi liées à l'informatique et à la nécessité de gérer de gros volumes de données et des calculs coûteux.\\

Télécom ParisTech et Lokad se trouvent donc tous les deux à l'interface entre informatique et statistiques, à l'endroit même où les deux disciplines se rejoignent sur les problèmes d'algorithmes statistiques répartis.\\

Le concept récent de Cloud Computing (francisé en \og informatique dans les nuages\fg) est en train de modifier profondément le monde informatique. Le Cloud Computing propose une transition depuis le modèle économique dans lequel l'utilisateur possède les logiciels et les infrastructures matérielles vers un modèle dans lequel l'utilisateur est un simple locataire de services, qu'ils soient logiciels ou matériels. Le Cloud Computing abstrait et dématérialise donc l'espace physique dans lequel les calculs et les données sont gérés et ouvre des perspectives nouvelles pour les entreprises mais aussi pour la recherche académique.\\

Notre travail de thèse s'inscrit à l'intersection de ces différents sujets : statistiques, calcul réparti et Cloud Computing. Nos activités de recherche ont porté sur cette technologie naissante pour laquelle peu de travaux académiques ont à ce jour été réalisés. Notre travail a consisté à explorer les capacités et limites de ces technologies encore mal comprises, pour en appréhender les enjeux et proposer des manières pertinentes de paralléliser des algorithmes. Ce travail d'exploration et de synthèse donne naissance aux chapitres \ref{chap:cloudpres} et \ref{chap:azurepres}.\\

Les algorithmes que nous avons portés sur le cloud se répartissent en deux catégories. La première catégorie regroupe différents composants du moteur de prévision interne de Lokad que nous avons adaptés pour le cloud. Ces travaux, moins académiques, sont d'autant plus difficiles à partager que le code qui en découle est propriétaire. Ils nous ont cependant permis par induction de dégager quelques considérations générales sur la conception d'applications sur le cloud. Nous en présentons certaines dans le chapitre \ref{chap:conceptionCloud}.\\

La seconde catégorie d'algorithmes a trait aux méthodes de clustering\footnote{C'est à dire de classification non-supervisée} réparti, qui font l'objet principal des chapitres \ref{chap:KMeans} à \ref{chap:cloudDALVQ} du présent document. La question du clustering est un aspect très important de la prévision de séries temporelles chez Lokad. En effet, pour améliorer ses prévisions, Lokad utilise des méthodes dites \og multi-séries\fg. L'objet de ces méthodes est d'utiliser l'information contenue dans toutes les séries afin d'affiner la prévision de chacune d'entre elles. Un exemple d'utilisation est l'exploitation des saisonnalités : en dégageant des comportements saisonniers d'un ensemble de séries temporelles, certains modèles de Lokad sont capables d'affiner la composante saisonnière, plus bruitée sur une seule série temporelle. Le clustering est donc un outil essentiel pour Lokad, outil qu'il était nécessaire d'adapter à la plateforme de Cloud Computing.\\

Les algorithmes de clustering réparti considérés dans ce manuscrit mettent en lumière certaines des contraintes imposées par les plateformes de Cloud Computing, notamment en terme de communication. Le chapitre \ref{chap:KMeans} traite de la pallélisation d'un algorithme bien connu de clustering : le Batch K-Means. La version répartie de cet algorithme nécessite des communications importantes entre les différentes machines sur lesquelles il est parallélisé, ce qui limite en partie sa rapidité. Les deux chapitres suivants traitent d'un autre algorithme, cousin germain du Batch K-Means : l'algorithme de Vector Quantization (VQ). Cet algorithme, qui peut être considéré comme la version en-ligne du Batch K-Means, permet de contourner certains problèmes de communication inter-machines par l'introduction d'asynchronisme.\\

Les travaux scientifiques portant sur des calculs répartis de grande ampleur sont appliqués à des jeux de données dont l'échelle de taille peut se révéler très variable. Pour chaque ordre de grandeur du problème, les outils logiciels et matériels adéquats sont très différents ; on conçoit aisément qu'à des problèmes aussi différents en taille que l'indexation du web par Google Search ou l'affluence de trafic sur un petit site web, il est fourni des solutions très distinctes. Il est ainsi primordial de préciser quels sont les ordres de grandeur pour lesquels un travail donné est conçu. Nos travaux de thèse portent sur des calculs dont l'ampleur correspondrait sur une seule machine (mono-coeur) à une centaine d'heures, avec à notre disposition 250 machines. Les jeux de données les plus volumineux sur lesquels nous avons fait tourner nos algorithmes représentent environ 50 Go. Nous avons choisi de concentrer nos travaux sur ces ordres de grandeur qui reflètent la taille des données des clients les plus importants actuellement de Lokad.\\

La suite de cette partie introductive présente succinctement le contenu de chaque chapitre de ce manuscrit.

\section{Présentation des travaux}
\subsection{Chapitre 2 - Introduction au Cloud Computing}

Les progrès fulgurants des mécanismes de collecte des données n'ont pas été accompagnés de progrès aussi rapides dans le développement des processeurs. Cette réalité a incité au développement de systèmes physiques et logiciels permettant de répartir des charges de travail sur de multiples unités de calcul. Ces calculs intensifs ont tout d'abord été portés sur des architectures physiques dédiées, communément appelées super-calculateurs. Ces super-calculateurs étaient des dispositifs physiques conçus en faible quantité, spécifiquement pour réaliser des calculs intensifs. L'explosion du marché des ordinateurs personnels dans les années 80, puis d'Internet à la fin des années 90 a ouvert des perspectives nouvelles quant à la manière de répartir des calculs. De nouveaux systèmes sont alors apparus, reposant sur la collaboration de plusieurs agents administrativement distincts et mettant en commun une partie de leurs ressources. Parmi ces systèmes, on trouve des infrastructures de Grid Computing, comme Condor (\cite{Condor}), ou des systèmes plus récents, par exemple de Peer-To-Peer, comme Napster ou Folding@Home.\\

La parallélisation de calculs sur une vaste quantité de machines soulève de nombreuses difficultés, qu'elles aient trait à la communication entre les machines, à l'accès en écriture ou lecture à une mémoire partagée efficace, ou à la répartition de la charge de calcul sur les différentes unités disponibles. Les années 2000 ont vu l'émergence d'applications web consommant d'immenses ressources : c'est le cas par exemple de Google Search, de Bing, de Facebook, de Youtube, d'Amazon, etc. Les entreprises à la tête de ces applications ont développé des environnements logiciels (frameworks) mais aussi physiques (via la construction de centres de calcul spécifiques ou data centers) pour proposer des solutions aux difficultées susnommées.\\

Certaines de ces entreprises, rejointes par d'autres acteurs économiques, ont alors proposé de mettre en location un accès à ces différentes solutions, physiques et logicielles. Ces sociétés sont alors devenues des fournisseurs de Cloud Computing.\\

Le Cloud Computing a de très nombreuses implications techniques, scientifiques ou commerciales. Les différentes offres se catégorisent selon qu'elles offrent des solutions clef en main, ou au contraire qu'elles laissent plus de libertés à leurs utilisateurs au prix d'une complexité d'utilisation plus élevée. Parmi les solutions clef en main, on recense les offres de Software as a Service (Saas), comme Google Search, Gmail, Deezer, Facebook, etc. On y regroupe également de nombreuses solutions spécifiques, développées pour chaque client par des sociétés tierces (notamment des sociétés de services en ingénierie informatique (SSII)). Ce chapitre présente principalement les catégories d'offres de Cloud Computing les plus à même de permettre l'usage de calculs intensifs. Cette seconde catégorie d'offres est souvent celles des acteurs clouds les plus importants. Plus standardisées et orientées performance, ces dernières s'adressent à un public de développeurs exclusivement. Parmi elles, nous approfondirons les différences entre les offres de Platform as a Service (PaaS) et celles d'Infrastructure as a Service (IaaS).\\

Les offres de Cloud Computing analysées proposent un ensemble de technologies, parfois pré-existantes au concept de Cloud Computing, réunies dans une même pile technologique. Le chapitre \ref{chap:cloudpres} traite de ces différentes technologies. En particulier, nous donnons un apercu des difficultés que soulèvent un système de stockage de données réparti sur un ensemble de machines distantes. Nous présentons également certains des environnements logiciels construits pour aider le développement d'applications réparties, comme le célèbre MapReduce, conçu originellement par Google et repris de façon très générale.\\
%
%Ce chapitre s'organise comme suit : après une mise en contexte du Cloud Computing dans lequel nous ouvrons quelques perspectives, nous nous attachons à introduire les réalités économiques et historiques qui ont amené à l'émergence du Cloud Computing. Nous présentons ensuite plus avant ce qu'est le cloud. Pour celà, nous expliquons en quoi il se démarque de son aîné, le grid computing, puis nous présentons les différents niveaux de cloud disponibles (Software as a Service, Platform as a Service, Infrastructure as a Service, ...) ainsi que les différentes technologies qu'il regroupe. Une fois ce rapide tour d'horizon achevé, nous nous attachons à des considérations plus techniques sur les systèmes de stockage réparti et d'exécution parallèle de tâches. Enfin, nous donnons quelques exemples de fournisseur de Cloud Computing.\\

\subsection{Chapitre 3 - Introduction à Azure}

Microsoft est une société à la fois consommateur et fournisseur de Cloud Computing : consommateur tout d'abord en raison de ses besoins en interne, notamment pour une partie du moteur de recherche Bing ou pour le stockage de certaines données comme celles liées à la plateforme de jeu en ligne de la XBox 360. Ces besoins en interne ont amené Microsoft à fournir des efforts importants de recherche et développement dans les infrastructures matérielles et logicielles pour disposer d'une plateforme puissante. Ces efforts ont abouti sur des composants comme Cosmos, Scope (\cite{SCOPE}), Dryad (\cite{Dryad2007}) ou DryadLINQ (\cite{DryadLINQ}).\\

A la suite d'Amazon et de Google, Microsoft s'est lancé dans l'offre de cloud pour devenir également fournisseur de Cloud Computing. Son offre se répartit en deux grandes familles de produits. La première regroupe les applications classiques de Microsoft auparavant proposées en mode \og desktop\fg et aujourd'hui disponibles en version cloud. Parmi elles, on peut citer Office 365, qui est la version SaaS du pack Office. Les offres de SQL Server ont également été portées sur le cloud pour prendre le nom de SQL Azure. Ces migrations sur le cloud ne se font pas sans certaines difficultés liées au contexte de l'activité de Microsoft : les offres SaaS de Microsoft font en quelque sorte concurrence à leur pendant desktop, mais elles modifient également le positionnement de Microsoft par rapport à certains de ses partenaires dont l'activité principale consistait à garantir la bonne installation et maintenance de ces applications desktop chez les clients de Microsoft. Cependant Microsoft a affiché sa volonté de développer ces offres qui représenteront très probablement une part importante de son activité dans les prochaines années.\\

La deuxième famille de produits est une plateforme de Cloud Computing destinée aux éditeurs logiciels, appelée Azure. Cette plateforme permet à ses clients d'héberger des applications en mode SaaS, qui utilisent les ressources de CPU, de stockage et de bande-passante fournies par Azure. Microsoft a réutilisé une partie de la technologie développée dans Cosmos (comme expliqué dans \cite{AzureStorage}) pour construire un système de stockage dédié pour cette plateforme, appelé Azure Storage.\\

Le chapitre \ref{chap:azurepres} présente les caractéristiques et les enjeux techniques d'Azure. En particulier, nous nous intéressons aux abstractions de stockage proposées, ainsi qu'à la manière dont elles se sont positionnées par rapport aux différents compromis nécessaires aux solutions de stockage réparti, comme introduit dans le chapitre \ref{chap:cloudpres}. Nous présentons également quelques clefs du développement d'applications sur cette plateforme.\\

%Ce chapitre s'organise de la manière suivante : la première partie présente le contexte dans lequel la migration vers le cloud s'inscrit chez Microsoft. Nous montrons les axes suivant lesquels le Cloud Computing prendra une place croissante chez Microsoft. Les sections suivantes sont consacrées à Azure en particulier. Nous présentons tout d'abord la plateforme de calcul Azure Compute et détaillons l'organisation hiérarchique des applications hébergées sur cette plateforme. Dans un deuxième axe, nous nous intéressons au système de stockage de données d'Azure : Azure Storage. Ce système est présenté tout d'abord via les différentes interfaces qu'il propose pour ses utilisateurs (BlobStorage, TableStorage, QueueStorage), puis de l'intérieur avec un aperçu technique de l'architecture interne de ce système. Cet aperçu permet de mettre en lumière comment Azure Storage réussit le pari de fournir une plateforme efficace tout en garantissant une consistente forte des données. La section suivante de ce chapitre est consacrée à un exposé très bref des performances d'Azure. L'évaluation précise des performances est un exercice délicat, pour lequel nous renvoyons le lecteur vers d'autres travaux. Le but de cette section est de donner un ordre de grandeur du comportement d'Azure, ordre de grandeur qui a son importance pour l'élaboration des algorithmes qui seront portés sur cette plateforme dans les chapitres \ref{chap:KMeans} et \ref{chap:cloudDALVQ}. Enfin, nous présentons rapidement les prix actuels d'Azure et donnons quelques exemples de prix que représenteraient certains algorithmes.\\

\subsection{Chapitre 4 - Éléments de conception logicielle sur le cloud}

Le chapitre \ref{chap:conceptionCloud} présente certaines techniques ou schémas récurrents (dits \og design pattern \fg) rencontrés pendant le développement de nos applications sur le cloud. Ces techniques ont été bien souvent au coeur du développement des quatres applications sur lesquelles nous avons travaillé durant cette thèse. Les deux premières applications sont les implémentations cloud de l'algorithme réparti du Batch K-Means d'une part et de l'algorithme réparti de Vector Quantization d'autre part, respectivement étudiés dans les chapitres \ref{chap:KMeans} et \ref{chap:cloudDALVQ}.\\

Parallèlement à ces algorithmes, nous avons porté sur le cloud deux applications qui correspondent au coeur de la technologie de prévision de Lokad. La première de ces deux applications est le moteur de prévision de séries temporelles de Lokad. Ce moteur, utilisé en production pour fournir via son API les prévisions utilisées ensuite dans nos applications-clients, profite de la fiabilité et de l'élasticité proposées par Azure. La seconde application, Lokad Benchmark, est un outil interne qui réplique le moteur de prévision. Cet outil est utilisé pour améliorer la précision statistique de nos modèles, pour augmenter le potentiel de passage à l'échelle de notre moteur sur de plus gros jeux de données, et pour surveiller et \og profiler \fg l'exécution de prévisions.\\

Ces quatres applications s'inscrivent dans des contextes différents (prototype/en production) qui influent fortement sur le positionnement de l'application quant à de nombreux compromis: robustesse/efficatité, passage à l'échelle/facilité de maintenance, rapidité/précision, etc. À la lumière de ces quatre applications, nous présentons comment les différentes abstractions et primitives fournies par Azure peuvent être combinées pour bâtir des applications sur Azure. Nous soulignons également l'absence de certaines de ces briques \og élémentaires \fg, et les conséquences sur le design induites par ces absences.\\

\subsection{Chapitre 5 - Algorithmes de Batch K-Means réparti}

Les algorithmes de clustering ont un rôle central en statistiques. D'un point de vue théorique, ils représentent un problème d'apprentissage non supervisé très étudié. D'un point de vue pratique, ils sont un outil souvent indispensable pour l'exploration des données. Ces algorithmes proposent de résumer un jeu de données en un jeu de données plus petit mais cependant représentatif des données initiales. Ce résumé est réalisé en constituant des sous-groupes (également appelés clusters), déduits du jeu initial par le regroupement des données les plus proches suivant un certain critère de similarité.\\

Etant donnés un critère de similarité et un nombre fixé de sous-groupes, le problème de trouver un regroupement optimal au sens du critère est un problème calculatoirement très difficile, souvent irréalisable dans la pratique dès que la taille du jeu de données dépasse quelques dizaines de points\footnote{À titre d'exemple, le problème du K-Means théorique comme exposé dans \cite{BiauKMeans} est NP-complet, même dans le cas le plus simple du clustering dans le plan (\cite{KMeansIsNPhard})}. Des algorithmes d'approximation ont été proposés, fournissant une solution proche de la solution optimale. Parmi ces algorithmes, le Batch K-Means est un algorithme populaire, connu notamment pour sa simplicité de mise en oeuvre.\\

Les algorithmes de clustering comme le Batch K-Means sont utilisés dans des domaines très variés, qu'il s'agisse par exemple de biologie moléculaire, d'analyse de séries temporelles ou d'indexation du web pour les moteurs de recherche, etc. Chez Lokad, ces procédures sont utilisées pour former des sous-groupes au sein desquels les séries temporelles partagent un même comportement saisonnier. Il est alors plus aisé pour Lokad d'extraire une composante saisonnière de chaque sous-groupe plutôt que de chaque série temporelle, car la composante saisonnière, moyennée sur ce sous-groupe, se révèle souvent plus régulière que lorsqu'elle est extraite série par série.\\

Les algorithmes de clustering connaissent depuis une quinzaine d'années le développement d'un nouveau défi : celui de la parallélisation. En effet, l'évolution plus rapide des moyens de collecte des données que des moyens de calcul a conduit les statisticiens à paralléliser leurs tâches de calcul sur de nombreuses machines, mêlant ainsi toujours plus statistiques et l'informatique.\\

Les travaux du chapitre \ref{chap:KMeans} portent sur le problème du K-Means réparti, en particulier leur adaptation aux nouvelles architectures de calcul sur le cloud, développées au chapitre \ref{chap:cloudpres} et \ref{chap:azurepres}. Plus précisément, ils montrent comment le premier cadre théorique de Batch K-Means réparti, proposé par Dhillon et Modha  (\cite{DhillonModha2000}) dans le cas d'une architecture DMM\footnote{Distributed Memory Multiprocessors : architecture parallèle ne disposant pas de mémoire physique partagée.} disposant d'une implémentation MPI\footnote{norme définissant une bibliothèque de fonctions pour fournir des moyens de communications entre machines.}, ne s'applique que partiellement à Azure qui ne possède pour l'instant pas une telle implémentation. Ce chapitre propose une modification de l'algorithme qui permet de l'adapter à l'infrastructure proposée par Azure.\\

%Le chapitre \ref{chap:KMeans} s'organise de la sorte : après une brève introduction qui rappelle le contexte général du clustering et du batch K-Means en particulier, nous détaillons l'implémentation et le coût d'exécution de l'algorithme dans le cas séquentiel dans la section \ref{Sequential K-Means Algorithm Section}. Dans la troisième partie du chapitre, nous présentons les travaux précédents menés sur la parallélisation du Batch K-Means sur des architectures hardware dites Symmetric Multi-Processors (SMP) ou Distributed Memory Multi-processors (DMM). Ces travaux proposent à la fois une implémentation mais un modèle théorique de coût de l'algorithme et son évaluation en terme d'accélération de la convergence. Nous poursuivons ces travaux en détaillant plus en avant ce modèle de coût et en fournissant des conditions suffisantes pour garantir une bonne efficacité de l'implémentation parallèle. Dans la partie suivante, nous développons comment les algorithmes de Batch K-Means déjà proposés peuvent être adaptés à une architecture de Cloud Computing comme Azure et fournissons un modèle de coût pour la nouvelle implémentation proposée. La dernière partie de ce chapitre est consacrée à l'évaluation pratique de notre implémentation cloud.

\subsection{Chapitre 6 - Considérations pratiques pour
les algorithmes de Vector Quantization répartie}

Ce chapitre ainsi que le suivant présentent des travaux réalisés et écrits en collaboration avec Benoit Patra, qui était également doctorant au sein de la société Lokad. Nous sommes partis du constat du chapitre \ref{chap:KMeans} selon lequel les communications sur une plateforme de Cloud Computing via le stockage réparti sont coûteuses. La parallélisation du calcul d'un Batch K-Means, bien qu'assez satisfaisante, y est donc ralentie par les nombreuses communications nécessaires ainsi que par les processus de synchronisation de toutes les machines. Nous avons donc travaillé sur la parallélisation d'un autre algorithme de clustering, connu sous le nom d'algorithme de Vector Quantization (VQ) qui supprime ou limite ces problèmes et se montre donc selon nous plus adapté à une implémentation sur le cloud.\\

Tout comme le Batch K-Means, l'algorithme de VQ permet de calculer des sous-groupes pertinents en affinant des points de référence appelés centroïdes ou prototypes qui représentent les différents sous-groupes. Bottou et Bengio remarquent dans \cite{BottouBengioKMeans} que l'algorithme de VQ peut être vu comme la version \og en-ligne \fg du Batch K-Means: au fur et à mesure que l'algorithme de VQ traite des points tirés des données à résumer, il fait évoluer en conséquence les prototypes plutôt que de faire évoluer les points une fois qu'il a examiné toutes les données comme c'est le cas dans le Batch K-Means.\\

D'un point de vue statistique, le passage à un algorithme \og en-ligne \fg a présenté des difficultés particulièrement intéressantes. En effet, ce type d'algorithme est par essence séquentiel, et la parallélisation du calcul est moins naturelle que dans le cas d'un Batch K-Means, pour lequel une même instruction doit être appliquée indépendamment à de nombreux points (on parle alors de tâches exhibant une propriété dite de \og data-level parallelism \fg). Par certains aspects, l'algorithme de VQ appartient à la grande famille des algorithmes de descente de gradient stochastique. La parallélisation de ce genre d'algorithmes a déjà fait l'objet d'études (nous renvoyons le lecteur par exemple aux articles \cite{SlowLearners}, \cite{DekelShamir} et \cite{Zealous}). Dans le cas où le critère est convexe et suffisamment régulier, les stratégies classiques de parallélisation d'algorithmes de descente de gradient par moyennage des résultats des différentes machines mènent asymptotiquement à des accélérations de convergence optimales, comme démontré dans le récent article de Deker et al. (\cite{DekelShamir}), et obtiennent dans la pratique des résultats très satisfaisants, comme dans l'article de Langford et al. (\cite{SlowLearners}).\\

Dans le cas de l'algorithme de VQ, le critère n'est ni convexe ni suffisamment régulier, et le moyennage des résultats ne mène pas dans le cas général à de meilleures performances que l'algorithme séquentiel exécuté sur une seule machine. Ce résultat surprenant nous amène à reformuler l'algorithme proposé sous une forme qui souligne l'importance de la vitesse de décroissance du pas associé à la descente de gradient. Ce travail nous permet de donner un éclairage différent au précédent algorithme pour appréhender les mécanismes qui l'empêchent d'obtenir des accélérations de convergence satisfaisantes.\\

Enfin, nous proposons un nouvel algorithme de VQ répartie, qui évite les travers du précédent. En particulier, notre algorithme va additionner les termes de descente provenant des différentes machines, plutôt que d'en moyenner les valeurs. Cette modification de l'algorithme permet d'obtenir des accélérations de convergence satisfaisantes. Ces accélérations sont présentées en fin de chapitre.\\

%Le chapitre \ref{chap:practicalDALVQ} est organisé de la manière suivante :

\subsection{Chapitre 7 - Implémentation cloud d'un algorithme de Vector Quantization répartie et asynchrone}

Dans ce dernier chapitre, nous présentons le projet logiciel Cloud-DAVQ. Ce projet est la réalisation des algorithmes étudiés dans le chapitre précédent sur la plateforme de Cloud Computing de Microsoft : Windows Azure. Des implémentations ambitieuses d'algorithmes répartis de descente de gradient stochastique ont déjà été proposées, comme c'est le cas dans les articles de Louppe et al., Langford et al., ou Dekel et al. précédemment cités: \cite{Zealous}, \cite{SlowLearners} et \cite{DekelShamir}. Cependant, ces travaux se sont à notre connaissance restreints au cas plus simple où l'infrastructure de calcul possède une mémoire partagée efficace et où les coûts de communication sont donc très faibles (dans \cite{Zealous} et \cite{DekelShamir}), ou à un cas où la convexité du critère permet de supprimer les communications inter-machines sauf à la fin de l'algorithme (dans \cite{SlowLearners}). Ainsi, aucun des travaux précédents ne proposait d'exemples d'implémentation d'algorithmes de descente de gradient répartis dans un contexte où les communications sont à la fois nécessairement fréquentes et coûteuses.\\

D'un point de vue informatique, l'aspect \og en-ligne \fg de l'algorithme de VQ nous a semblé particulièrement pertinent, puisque c'est la suppression du caractère batch qui permet de retirer la nécessité de la synchronisation des machines. Le passage vers un algorithme \og en-ligne \fg parallélisé nous permet donc de construire un algorithme asynchrone, libérant nos machines de processus de synchronisation pénalisant les performances. Ce passage vers l'asynchrone permet dans les faits de supprimer deux mécanismes de synchronisation : le premier a trait aux organisations inter-machines, puisque chaque machine n'est plus bloquée dans ses communications et dans ses calculs par l'attente des résultats des autres unités de calcul. Le second mécanisme que nous supprimons est celui de la séquentialité lecture/calcul/écriture au sein de chaque machine. Par la suite, nous faisons référence à cet algorithme réparti asynchrone sous l'acronyme de Distributed Asynchronous Vector Quantization (DAVQ). Dans le cadre du DAVQ, chaque machine peut effectuer en parallèle (par un recouvrement à base de plusieurs threads) les tâches de calcul et de communication pour exploiter au mieux les ressources de CPU et de bande-passante.\\


%+ PRÉSENTATION DU CHAPITRE 