Benjamin Cornu Florian Joyeux Les choses à connaître pour (essayer) de concurrencer Facebook. 1
Sommaire Présentation générale Historique Facebook La face cachée de l iceberg (back end) Architecture globale Business Logic Thrift Scribe Persistance MySQL Memcached Cassandra Hadoop Hbase en digne remplaçant de Cassandra HBase Hive HayStack Le sharding Liaisons entités Algorithme et Fonctionnement Le visage de Facebook (front-end) L architecture PHP HipHop BigPipe Structurer les informations EdgeRank La fin d EdgeRank Le story bumping Le last actor L avenir de Facebook Webographie Back-end Front-end Structurer les informations 2
Mise en garde : Ce livre blanc est un recueil d'informations tirées d internet. Comme toutes informations tirées d internet, les données présentées dans ce recueil n ont pas la prétention de représenter la réalité dans son exactitude. Toutefois, même si elles ne sont pas parfaitement exactes, elles permettent de présenter le site Facebook et ses grandes fonctionnalités de façon plus ou moins précise. Certaines informations étant pour des raisons évidentes confidentielles, nous avons pris la liberté d imaginer comment pourraient être créées les fonctionnalités manquantes pour proposer une vision globale de la machinerie derrière le site Facebook. 3
Présentation générale Historique Facebook Facebook est un réseau social créé par Mark Zuckerberg en 2004. Ce service en ligne permet aux internautes d échanger des messages et de publier du contenu (photos, vidéos, liens,etc. ) entre amis. À sa création le site n était destiné qu aux étudiants d Harvard, mais il s est très vite répandu dans les autres grandes universités avant de devenir accessible à tous. Il compte aujourd hui plus d un milliard d utilisateurs actifs. En quelques années Facebook s est imposé comme l un des sites les plus consultés au monde et enregistre : 100 milliards de clics par jour, 50 milliards d images, 100 millions de requêtes par secondes, 3 trillions d objets qui utilisent le cache, un fichier de log journalier pèse 130 To. Pour satisfaire les utilisateurs, l architecture se compose entre autres de : 60 000 serveurs, 3000 serveurs pour les clusters Hive et Hadoop disposant chacun de : 8 coeurs, 12 To d espace disque, 32 go de RAM. Après ces quelques chiffres, si l envie vous venez de vouloir concurrencer Facebook, il peut être nécessaire de connaître certains points importants avant de se lancer à corps perdu dans la bataille. Facebook s apparente à un iceberg, pour bien comprendre les mécanismes mis en jeu par le site, nous le présenterons dans sa globalité de façon verticale. La première partie s articulera autour de son architecture physique et matérielle, ce que nous appellerons la face cachée de l iceberg. Dans un second temps, nous détaillerons la partie visible de l iceberg. Cette seconde partie correspond à ce qui est présenté aux visiteurs. Nous terminerons cette seconde partie avec les algorithmes qui permettent aux utilisateurs d'interagir entre eux et qui font de Facebook un véritable réseau social permettant de créer des interactions et des connexions virtuelles entre les utilisateurs. 4
La face cachée de l iceberg (back-end) Dans cette première partie, nous vous ferons découvrir l architecture ainsi que les différents outils utilisés par Facebook. Pour synthétiser la présentation, nous vous présenterons dans un premier temps cette partie sous son aspect global (sous la forme de plusieurs couches), puis de façon plus détaillée en reprenant chacune des couches ainsi que chacun de ses composants. Architecture globale Le schéma ci-dessus a été réalisé à partir du lien suivant : http://www.quora.com/facebook- Engineering/What-is-Facebooks-architecture?q=facebook+architecture Le front-end faisant l objet d une partie détaillée plus loin dans ce livre blanc, nous ne rentrerons pas dans les détails dans cette partie. 5
Business Logic La couche business logic correspond à la partie métier de l architecture, c est elle qui va définir comment les objets vont interagir les uns avec les autres, comment les données seront ajoutées/modifiées. Thrift Thrift est un langage de définition d'interface (IDL) conçu pour la création et la définition de services pour de nombreux langages. Il est utilisé en tant que framework RPC et a été développé par Facebook pour le «développement de services évolutifs multilangage». Une pile logicielle est jointe à un moteur de génération de code, permettant la création de services fonctionnant plus ou moins efficacement et en continu entre C#, C++ (sur systèmes POSIX), Cappuccino, Cocoa, D, Erlang, Go, Haskell, Java, Node.js, OCaml, Perl, PHP, Python, Ruby, et Smalltalk. Wikipédia Thrift, pour simplifier sa définition est un intermédiaire entre les données/fonctionnalités et les utilisateurs. Il met à disposition de l utilisateur un certain nombre de services (ces services peuvent être écrits avec différents langages, ce qui fait le réel intérêt de Thrift). Scribe Nous avons pris la décision de mettre Scribe au même niveau que Thrift dans la couche business logic (couche charnière de l architecture) car ce serveur et son champ d application couvrent une grande surface du back-end de Facebook. Scribe est un serveur permettant l agrégation en continu des logs. Il a été conçu pour supporter un très grand nombre de noeuds et pour être robuste sur le réseau. À chaque noeud du réseau interne de Facebook se trouve un serveur scribe configuré pour agréger les messages et les renvoyer vers un serveur central Scribe. Dans le cas où le serveur central ne serait pas disponible, les logs sont stockés localement en attendant une réponse du serveur central. Scribe est implémenté comme un service Thrift. Son implémentation fonctionne sur des milliers de machines et offre des dizaines de milliards de messages fiables par jour. 6
Persistance La couche de persistance de données correspond au stockage de toutes les informations se trouvant sur le réseau social (informations sur les utilisateurs, messages, photos, vidéos, etc.) Le couple Cassandra/Hadoop a été délaissé en 2010 par Facebook au profit de HBase mais nous tâcherons tout de même de présenter les technologies dans le but de comprendre la décision de cet abandon. MySQL MySQL est un serveur de bases de données relationnelles SQL développé dans un souci de performances élevées en lecture, ce qui signifie qu'il est davantage orienté vers le service de données déjà en place que vers celui de mises à jour fréquentes et fortement sécurisées. Wikipédia Sur la totalité des serveurs que possède Facebook, 20% sont des serveurs MySQL et sont épaulés pour la plupart par des serveurs Memcached. Le reste des serveurs de données sont des serveurs HBase. Depuis l apparition de la nouvelle timeline, les informations n ont plus le besoin d être remontées systématiquement, mais plutôt d être organisées de façon statique, ce qui rend plus légitime l utilisation de MySQL. Ci-dessous un lien vers la page Facebook, de la version de MySQL utilisée et modifiée : http://www.facebook.com/mysqlatfacebook Memcached Memcached est un système d'usage général servant à gérer la mémoire cache distribuée. Il est souvent utilisé pour augmenter la vitesse de réponse des sites web créés à partir de bases de données. Il gère les données et les objets en RAM de façon à réduire le nombre de fois qu'une même donnée stockée dans un périphérique externe est lue.[...]. Memcached a été initialement mis au point par Danga Interactive pour LiveJournal. En 2010, il est utilisé par d'autres sites, plusieurs très fréquentés, tels que YouTube, Reddit, Zynga, Facebook et Twitter. Wikipédia Memcached accroît les performances des sites Web fondés sur MySQL en capturant les données et les objets dans la mémoire afin de minimiser la charge de la base de données. 7
Facebook fait partie de ceux qui déploient Memcached et MySQL pour répondre à la demande de millions d'utilisateurs et de milliards de pages vues tous les mois. Cassandra Cassandra est un Système de Gestion de Base de données (SGBD) NoSQL, un des principaux projets de la Fondation Apache. Cassandra est conçue pour gérer des quantités massives de données réparties sur plusieurs serveurs (cluster), en assurant tout particulièrement une disponibilité maximale des données et en éliminant les points individuels de défaillance. Initialement développée par Facebook, l'application a été libérée dans l'espace open source [...]Cassandra est basée sur une structuration en paires clévaleur. L'architecture relationnelle est orientée colonne, avec des éléments plus traditionnels (stockage horizontal des paires). Wikipédia Le choix de passer à une base NoSQL (pour Not Only SQL) vient du fait que les SGBD relationnels classiques sont dimensionnés pour une quantité d informations et d utilisateurs limitée. Les SGBD classiques atteignent rapidement leur limite quand il s agit de traiter un site web fréquenté par des millions de visiteurs comme Facebook. C est en partant de ce constat que Facebook a créé Cassandra. L architecture orientée colonne permet de gagné en simplicité, en performance et en extensibilité. 8
Sur la page suivante se trouve une explication simple des différences entre un modèle relationnel classique et un modèle orienté colonne : http://fr.wikipedia.org/wiki/base_de_données_orientée_colonnes Hadoop Hadoop est un framework Java libre destiné à faciliter la création d'applications distribuées et échelonnables (scalables). Il permet aux applications de travailler avec des milliers de nœuds et des pétaoctets de données. Hadoop a été inspiré par les publications MapReduce, GoogleFS et BigTable de Google. Wikipédia Hadoop propose deux choses que l on peut coupler avec le SGBD Cassandra : Un système de fichier distribué (HDFS) qui permet l'abstraction de l'architecture physique de stockage, afin de manipuler un système de fichiers distribué (sur plusieurs disques durs) comme s'il s'agissait d'un disque dur unique. Un framework de calcul et de traitement (MapReduce). En suivant ce lien, vous trouverez une publication de Google concernant le fonctionnement détaillé de MapReduce : http://research.google.com/archive/mapreduce.html Fonctionnement de MapReduce Plus de détail sont disponibles concernant Hadoop sur la page Wikipédia : http://fr.wikipedia.org/wiki/hadoop 9
Hbase en digne remplaçant de Cassandra Face à certaines de ses évolutions, Facebook a dû prendre la décision de changer de technologie, c est ce qui est arrivé à Cassandra qui a été délaissé pour utiliser HBase dans le cadre du système de message comme l explique un ingénieur sur cette page : https://www.facebook.com/note.php?note_id=454991608919 HBase HBase est un SGBD NoSQL du même type que Cassandra, mais il apporte les avantages suivants : Plus rapide, Plus échelonnable, Propose une implémentation de base de MapReduce. Il peut de plus être mis en place sur HDFS (le système de fichier distribué de Hadoop), ce qui lui procure encore de nouveaux avantages. Hive Hive est un logiciel d'analyse de données permettant d'utiliser HBase avec une syntaxe proche du SQL. Hive a été initialement développé par Facebook. Le schéma ci-dessous permet de synthétiser l architecture de HBase avec Hive. 10
Le nombre de données agrégées par le site de Facebook étant toujours croissant, les ingénieurs travaillent sur de nouvelles façons d optimiser toujours plus les interactions avec les BDD. Sur la page se trouvant à cette adresse : https://code.facebook.com/posts/555001884578896/presto-interacting-with-petabytes-of-dataat-facebook/ Un ingénieur présente brièvement un nouvel outil de requêtage nommé Presto qui pourra à l avenir venir s ajouter aux nombreuses technologies utilisées par Facebook pour le traitement des données. HayStack Haystack est l outil développé par Facebook leur permettant de gérer des milliards de photos de façon optimisée. L outil d upload de photos est l une des fonctionnalités les plus utilisées de Facebook. Facebook stocke sur ses serveurs, plus de 260 milliards d images soit environ 20 petabytes! Et ce nombre ne fait que croître puisque 1 milliard d images sont mises en ligne chaque semaine. Lorsqu un utilisateur souhaite visionner une photo, la difficulté est d en trouver une photo parmi des milliards. Facebook a donc mis en place l architecture suivante afin qu une photo soit facilement retrouvée dans la base de données : 11
Pour plus d informations sur le fonctionnement réel de HayStack ainsi que sur cette architecture, consulter : http://technohandle.blogspot.fr/2012/11/facebook-haystack-image-data-store.html Le sharding Pour éviter de gérer des tables de données énormes, Facebook utilise l architecture de sharding et plus particulièrement le partitionnement horizontal. Le but du sharding est de répartir la charge sur plusieurs serveurs. Cette technique demande néanmoins de modifier sa façon d accéder aux données. (Sur quel serveur se trouvent les données que l on cherche?) Ci-dessous un schéma explique simplement les deux types de partitionnement : Dans le but de répliquer son architecture sur plusieurs sites, la partie Business Logic et la persistance sont encapsulées dans une entité appelée cellule. Chaque Cellule gère un certain nombre d utilisateurs (pour simplifier, une cellule gérera les utilisateurs A - F, une autre de F - O, etc.). De nouvelles cellules peuvent être ajoutées si c est nécessaire. La persistance est basée sur Hbase telle qu expliquée précédemment. Le partitionnement horizontal des données : 12
Les bénéfices du sharding : http://blog.octo.com/sharding/ 13
Liaisons entités Algorithme et Fonctionnement La suggestion d amis est l une des fonctionnalités importantes de Facebook, mais, comment fonctionne-t-elle? Après plusieurs recherches, on peut s apercevoir qu il est très difficile de trouver des informations sur le fonctionnement exact. Beaucoup d internautes se sont posé la question. Dans le billet suivant, un internaute a réussi à avoir quelques réponses d un employé de Facebook http://www.shinyshiny.tv/2010/12/the_facebook_friends_box_how_it_chooses_who_to_display. html Facebook baserait son algorithme sur plusieurs critères, dont les suivants : Le nombre de photos où l on est identifié avec une personne, Le nombre d amis en commun avec la/les personnes avec lesquelles on interagit le plus. En recherchant plus d information, nous avons trouvé un algorithme permettant de trouver nos meilleurs amis sur Facebook. Ceux avec qui nous communiquons le plus par l'intermédiaire de mentions J aime, de commentaires, de photos avec identification... https://github.com/gajus/facebook-friend-rank En fonction des mentions J aime et des commentaires, Des profils visités, Les fils d actualités où notre nom est mentionné, Personne dans le même lieu au même moment, Personne ayant le même lieu de résidence, Centre d'intérêt en commun. Facebook testerait également de nouveaux algorithmes pour élargir son réseau : Personne qu on pourrait connaître Personne qu on pourrait ne PAS connaître Personne qu on pourrait rencontrer Personne qu un proche peut nous présenter Personne avec qui on pourrait se réconcilier après une rupture Pour plus d informations sur ces différents algorithmes : http://jackbachelorblog.wordpress.com/2013/01/16/friend-suggestions/ 14
On peut également se pencher sur cet article où l auteur a développé des algorithmes permettant d'améliorer la recommandation d amis. Pour développer les algorithmes, l auteur se base sur plusieurs critères : Relation de travail Amis en commun Localisation commune Intérêts en commun Films en commun Éducation Religion / Politique Identification sur une photo On peut imaginer que Facebook utilise également certains de ces critères. http://www.cse.unr.edu/~mgunes/papers/cec11.pdf 15
Le visage de Facebook (front-end) L architecture Dans cette partie nous allons vous détailler la partie visible de l iceberg, la partie Front-End. De quelle façon a été développé Facebook ainsi que des outils utilisés pour améliorer la vitesse de rendu de page. Nous vous expliquerons également les raisons qui ont poussé l entreprise de Mark Zuckerberg à choisir certaines technologies. PHP HipHop Pour la partie front-end Facebook a choisi de développer son site dans le langage PHP. Un des avantages de PHP est qu il est dit interprété. Par conséquent le code écrit n a pas besoin d être compilé pour être exécuté. La facilité d apprentissage de ce langage dû à sa syntaxe est une des raisons principales qui a poussé Facebook à choisir ce langage. Il est donc aisé d écrire du code. PHP à l avantage d être non typé. Sa syntaxe ne demande donc pas à ce qu une variable soit précédée de son type (int, string, bool, etc.). Toujours dans la même optique, PHP permet de faire abstraction du type dans la déclaration d un tableau. La déclaration se fait de la façon suivante : $my_facebook_array = array( face, book, mark, zuckerberg ); Dans un autre langage, comme le C# par exemple, cette même déclaration aurait été écrite de la façon suivante : string[] myfacebookarray = new string[] { face, book, mark, zuckerberg }, Autre avantage, PHP dispose d une forte communauté de développeurs actifs. Il est donc facile de trouver une solution à un problème sur les documentations officielles ainsi que sur les forums dédiés. Cependant, dans le monde PHP tout n est pas rose. En effet, c est l un des langages demandant le plus de ressources au CPU ainsi que de consommation mémoire. Par exemple chaque inclusion de fichier fait augmenter le coût du CPU de façon linéaire. Pour avoir une idée plus précise des ressources demandées, voici quelques statistiques en fonction des langages utilisés par Facebook : 16
En sachant que la plus basse consommation est la plus optimale, on peut voir que le PHP est un langage beaucoup moins performant que peut l être le JAVA ou encore le C++. Lorsqu on doit gérer plus d un milliard d utilisateurs c est un problème majeur en termes de performances. Or, plus un site est rapide plus l expérience utilisateur est plaisante. Certaines solutions peuvent être mises en place pour pallier ce problème et ainsi améliorer le chargement d une page. La technique dite du lazy loading est une des solutions pour répondre à ce genre de problématique. Le principe du lazy loading est d attendre une action du visiteur pour charger une certaine portion de la page. On peut par exemple afficher des boutons seulement après avoir survolé une partie de la page. Si vous voulez voir le principe de ce mécanisme, il est utilisé par le site de clubic. http://www.clubic.com/jeu-video/actualite-604500-steam-bat-record-utilisateurs-connectessimultane.html Sur cette page on peut voir que les commentaires de fin de page sont affichés que si l utilisateur arrive à la fin de l article. Cette technique du lazy loading présente trois intérêts principaux. La page se charge beaucoup plus vite, Les ressources clientes sont économisées (dans un monde résolument tourné vers la mobilité ou la data, bande passante coûte chère), Les ressources serveur sont économisées Pour ce dernier point, si nous reprenons en compte l exemple du site de Clubic, le serveur de base de données n est appelé que si le lecteur a fini l article. L API Applicatif PHP Cache (APC) implémente parfaitement ce mécanisme de lazy loading ainsi que d autres techniques d amélioration de rendus de pages. Cependant, pour une entreprise ayant des millions d internautes ainsi que cent millions de requêtes à la seconde il n est pas permis qu une page soit longue au chargement. Facebook a donc décidé de développer son propre compilateur : 17
En 2008 Facebook décide de créer un ensemble d outils leur permettant d optimiser le développement, le débogage, l'exécution du code PHP. HipHop debugger (HPHPd) HipHop compiler (HPHPc) Ce dernier permettant de transformer du code PHP en code C++ qui comme nous l avons vu précédemment est un des langages les plus performants en terme de consommation CPU/mémoire. http://www.youtube.com/watch?v=p5s1k60mhqu Sur ce lien il est expliqué comment PHP peut être modifié en C++ tout en résolvent les problèmes de performance. L origine principale de ce projet était d améliorer les performances du site en diminuant la charge de ses serveurs. Le défi est alors réussi pour l équipe Facebook atteignant des performances six fois supérieures à ZEND (framework PHP) Cependant, en 2010 les performances ainsi que les possibilités d optimisation atteignent un plafond. Une des raisons est que certaines fonctions ne sont pas supportées par HipHop notamment les fonctions create_function() et eval(). De plus, HPHPc demande plusieurs processus de déploiement ce qui n est pas acceptable pour les développeurs PHP. Facebook décide donc de donner un nouveau souffle à Hip Hop for PHP en rendant tout d abord HipHop open source afin que la communauté participe à l amélioration de l outil, mais, il lance également un nouveau projet se basant sur une machine virtuelle : Hip Hop Virtual Machine (HHMV). HHVM a pour but d améliorer les forces de HPHPc tout en supprimant les faiblesses mentionnées précédemment. Pour augmenter les performances cette seconde génération de HPHPc ne transforme plus le code PHP en C++, mais le transforme directement en bytecode à l instar de la JVM de JAVA ou de la CLR de C#. La compilation se fait donc à la volée (Just In Time). Le fonctionnement de cette compilation se fait de la façon suivante : Lorsque la HHVM charge pour la première fois le projet, elle convertit le code php en bytecode. 18
Le bytecode est un code intermédiaire entre les instructions machines et le code source, il n'est pas directement exécutable. Le bytecode peut être créé à la volée et résider en mémoire (compilation à la volée, JIT en anglais) ou bien résider dans un fichier, généralement binaire qui représente le programme, tout comme un fichier de code objet produit par un compilateur. Il est appelé bytecode du fait de son format où chaque instruction est codée en binaire. Wikipédia Le bytecode est ensuite compilé et stocké en mémoire, mais seulement lors de l'exécution. Puis le compilateur (Just in time compiler) charge seulement la section de bytecode dont il a besoin. Ce qui a pour effet d améliorer les performances et la rapidité d'exécution d une application. Facebook a le souci de l optimisation. Rendre le site de plus en plus rapide est un de leurs objectifs quotidiens. Les équipes techniques n'hésitent pas étudier et refaire l existant. C est ce qui a motivé notamment le projet Big Pipe pour rendre l'expérience utilisateur encore plus agréable et plus rapide. Au travers de ce projet, ils ont trouvé le moyen de réduire le temps d affichage d une page web. Le modèle traditionnel de rendu de page. Aujourd hui lorsqu un utilisateur demande à afficher une page, une requête est envoyée au serveur web. Une fois la requête reçue, le serveur web charge la page demandée et la rend au navigateur afin que celui-ci l affiche et qu elle soit visible par l internaute. Pour expliquer ce mécanisme, prenons l exemple d une page type Facebook. Celle-ci comporte une actualité, une liste d amis, une liste d'évènements, de la publicité, etc. Plusieurs requêtes vont donc être exécutées afin de récupérer le contenu de chacun de ces éléments. Problème, dans ce modèle traditionnel d affichage d une page, le serveur attend que toutes les requêtes soient terminées avant de renvoyer le contenu final au navigateur. L utilisateur se voit donc contraint d attendre. BigPipe En quoi BigPipe révolutionne-t-il le rendu de pages web? 19
BigPipe se détache de ce modèle en découpant le contenu d une page web en plus petits morceaux appelé pagelet. L image ci-dessus montre comment une page de Facebook est décomposée en plusieurs pagelet. La page principale est donc découpée en plusieurs pagelet principaux : fil d'actualité pagelet, bar de recherche pagelet, liste d amis pagelet, etc. Chacun de ces pagelets est indépendant des autres. Lorsque la liste d amis s affiche à l écran, le fil d actualité peut être encore en chargement. 20
On peut voir que grâce à BigPipe les temps de latence au niveau de l affichage des pages Facebook sont réduits sur les navigateurs principaux. BigPipe est donc bien plus rapide que le modèle traditionnel de rendu de page. 21
Structurer les informations Facebook possède des millions de données sur les utilisateurs, pour toujours être plus attrayant et pertinent il se doit de gérer parfaitement l affichage de ces données. Nous avons pu voir jusqu à maintenant les différentes technologies qui composent Facebook, nous allons maintenant voir de quelle façon est géré l agencement des données sur le site. EdgeRank En 2006 le fil d actualités apparaît sur Facebook. Au départ ce fil d actualité propose aux utilisateurs d avoir le contenu le plus important de leur réseau social sur leur page d accueil sans pour autant aller visiter le profil de chaque ami. Les réglages de ce fil d actualité (le poids de chaque information) se font petit à petit selon les retours utilisateur, on augmente le degré d importance des photographies d un côté tout en baissant celui des statuts de l autre. Seulement Facebook grandit et ses fonctionnalités évoluent. Cela devient de plus en plus difficile de proposer un contenu pertinent en prenant en compte la quantité d informations que le fil d actualité peut proposer. C est à ce moment-là qu EdgeRank fait son apparition. Cet algorithme a pour but de déterminer quel contenu (Facebook appelle edge tout ce qui se passe sur Facebook, un statut, une photo, une vidéo, un commentaire, etc. ) mettre en haut du fil d actualité et dans quel ordre. Pour cela trois critères sont déterminés comme l explique le schéma ci-dessous : U = Affinity : Quel est le degré de relation entre l utilisateur et le contenu / source de l histoire. W = Weight : Quel est le poids du type de contenu. D = Decay : Quel est l âge du contenu (récent? Actuel?) Pour plus d information sur EdgeRank, le poids des éléments publiés, etc. : http://www.whatisedgerank.com Deux infographies résumant le fonctionnement d EdgeRank et le moyen de l utiliser : http://pullthetrigger.me/2013/04/29/how-facebook-edgerank-algorithm-works/ Avec EdgeRank, c est l utilisateur qui va déterminer quel sera le contenu de son fil d actualité selon son activité. Selon Facebook, «le but du fil d actualité est de fournir le bon contenu aux 22
bonnes personnes au bon moment afin qu elles ne ratent pas les histoires qui sont importantes pour elles. Idéalement, nous voulons que le fil d actualité affiche toutes les publications que les personnes veulent voir dans l ordre qu elles veulent les lire». Avec EdgeRank Facebook se rapproche de ce but, mais cet objectif est de plus compliqué à remplir quand on sait qu un utilisateur peut voir par jour en moyenne 1500 histoires (pages, amis, photos, etc.). Surtout si celui-ci passe un temps limité sur la plateforme qui en plus s actualise en temps réel. La fin d EdgeRank Le principe d EdgeRank et ses trois critères restent utilisés dans le nouvel algorithme (qui pour le moment n a pas de nom), mais ils sont maintenant parents de sous niveaux qui contiennent de nouveaux critères. Ce nouvel algorithme permettrait d afficher environ 20% des 1500 histoires quotidiennes en prenant en compte entre autres : la fréquence d interactions avec un ami, un utilisateur ou la publication d une page, les réactions globales à une publication (mentions J aime, partages, commentaires, etc.) et en particulier celles des amis, la fréquence des interactions avec le même type de publication dans le passé, le fait de maquer ou non une publication dans le fil d actualité. Il est aussi possible de filtrer sur les personnes ajoutées en amis ou même sur les pages que l on suit. Ce qui restreint dans un premier temps l affichage des informations dans le fil d actualité. 23
Le story bumping Le story bumping est une méthode pour pallier le fait que le fil d actualité est alimenté en temps réel. Un utilisateur n étant pas devant son écran 24h/24 il est évident qu il ratera des informations. Le principe de cette fonctionnalité permet de faire remonter en haut du fil les publications plus anciennes si elles reçoivent de l'intérêt ( mentions J aime, commentaires, partages). Le last actor Ce nouveau critère prend en compte les 50 dernières interactions qu un utilisateur a effectuées (mentions j aime, commentaires, partages). Plus un utilisateur interagit avec le même objet (amis, utilisateur ou page), plus les publications relatives à cet objet ont d importance et sont susceptibles d apparaître dans le fil d actualité. Grâce à ce principe, Facebook peut mettre en avant en temps réel des informations correspondantes aux centres d intérêt d un utilisateur à un moment donné. Ce nouvel algorithme apprend et s adapte finalement à chaque utilisateur pour rendre le contenu du fil d actualité de plus en plus ciblé. 24
L avenir de Facebook D après deux doctorants de l université de Princeton, le modèle de Facebook se comporterait comme une épidémie et serait donc voué à mourir d ici quelques années. Ces deux chercheurs se sont basés sur l évolution puis le déclin de MySpace et on de plus appliqué un modèle épidémiologique modifié pour décrire la dynamique des utilisateurs des réseaux sociaux. Se basant sur ces suppositions, ils en sont arrivés à la conclusion que le réseau social pourrait perdre 80% de ses utilisateurs d ici 2017. Pour le moment le site n enregistre pas de baisse d utilisateurs et le prix de son action augmente toujours. Wait & see. Source : http://www.challenges.fr/high-tech/20140123.cha9589/facebook-pourrait-perdre-80- de-ses-utilisateurs.html 25
26 Webographie Architecture globale : http://fr.slideshare.net/adititechnologies/facebook-architecture-breaking-it-open http://www.quora.com/facebook-engineering/what-is-facebooksarchitecture?q=facebook+architecture http://stackoverflow.com/questions/3533948/facebook-architecture http://blog-bhaskaruni.blogspot.in/2012/12/facebook-architecture.html http://www.makeuseof.com/tag/facebook-work-nuts-bolts-technology-explained/ http://www.infoq.com/presentations/scale-at-facebook http://www.makeuseof.com/tag/facebook-work-nuts-bolts-technology-explained/ Back-end Business Logic Thrift : http://fr.wikipedia.org/wiki/apache_thrift http://thrift.apache.org http://blog.cloudera.com/blog/2008/10/thrift-scribe-hive-and-cassandra-opensource-data-management-software/ Scribe https://github.com/facebook/scribe Persistance MySQL http://www.technologyreview.com/featuredstory/410312/how-facebook-works/ http://mashable.com/2011/12/15/facebook-timeline-mysql/ Memcached http://memcached.org http://fr.wikipedia.org/wiki/memcached Cassandra http://stackoverflow.com/questions/13911501/when-to-use-hbase-and-when-touse-hive http://shazsterblog.blogspot.fr/2012/11/hadoop-vs-cassandra-and-hbase.html http://perspectives.mvdirona.com/2009/02/07/facebookcassandraarchitecturea nddesign.aspx Hadoop http://stackoverflow.com/questions/13911501/when-to-use-hbase-and-when-touse-hive http://shazsterblog.blogspot.fr/2012/11/hadoop-vs-cassandra-and-hbase.html HBase