Face aux limitations des architectures de base de données classiques, les géants d'internet ont développé de nouvelles architectures. Ces nouvelles architectures permettent de dépasser des limites de volumétries pour traiter jusqu'à des Peta de données. En regard des technologies classiques de bases de données et de Datawarehousing, c'est tout un écosystème qui s'est développé.

Le chef de file de cet écosystème du bigData est la technologie Hadoop. Le cluster Hadoop est constitué d'HDFS (le système de fichiers distribués Hadoop) et Map/Reduce. La technologie logicielle développée permet de traiter beaucoup de données sur des matériels standards, donc à couts très réduits. L'approche consiste à rapprocher les données des ressources de calcul. Les gros volumes de données sont découpées en morceaux de 64 à 128 Mo, et sont répartis sur les noeuds du cluster avec HDFS. Chaque noeud réalise des traitements localement sur son lot de données (phase de Map), et dans une seconde étape (le Reduce) les résultats sont consolidés et synthétisés en 1 point du système de fichiers répartis. Cette explication de Map/Reduce est assez limitée, mais nous resterons ici à un niveau conceptuel. Map/Reduce permet de travailler de manière systématique sur des volumes de données importants, par exemple réaliser simplement un produit cartésien de millions de lignes. Cette facilité a un prix qui est celui d'une exécution en mode asynchrone, lancer un traitement prend du temps, et nécessite d'articuler les développements en conséquence. 

Parmis les technologies ayant de fortes similitudes, on va trouver MPP (Massively Parallel Processsing) qui est déjà très largement utilisé depuis très longtemps dans le monde du Datawarehouse. MPP consiste là aussi à répartir les traitements et à paralléliser ceux-ci. Le MPP consiste à répartir les données sur plusieurs noeuds et à traiter ces données localement, pour ensuite les consolider. MPP est donc très proche d'Hadoop, à la différence près d'être implémenté de manière très propriétaire. Aujourd'hui les leader du marché du Datawarehousing, Teradata, Netezza et bien d'autres ont adopté cette architecture. Lorsqu'il est vendu bundlé avec du Hardware, c'est dans des offres très haut de gamme qu'on retrouve MPP, et bien évidement a des tarifications très souvent élevée pour ne pas utiliser d'autre termes. La performance obtenue par les architectures MPP n'est pas le seul facteur d'adoption, la disponibilité d'interfaces standardisée de type SQL permet une facile intégration dans des outils tiers. Les offres de grands constructeurs présentent aussi l'énorme avantage de disposer d'un support intégré de bout en bout. 

Au même titre que Hadoop fait son entrée dans les offres des constructeurs de plateformes MPP afin de permettre une consolidation de leurs bases autour de leurs offres historiques, rien n'interdirait qu'il y ait un mouvement de plateformes MPP vers du hardware banalisé. Les bases MPP et hadoop ne répondent pas aux même problématiques, l'une est orienté traitement de masse et l'autre est orienté vers l'obtention de résultats rapidement voir en temps réel. Pour ces raisons il y a de la place pour plusieurs technologies dans cet écosystème bigData, et leurs imbrications sont nécessaires. Nous reviendrons plus en détails sur ces scénarios d'utilisation dans de prochains posts. 

• En cas de reboot, tout est perdu, il faut veiller à mettre en place des copies régulières des données.
• Le RamDisk utilise la mémoire qui est paginée sur le disque, donc si le système a subitement besoin de mémoire il peut basculer nos données sur disque avec un impact très lourd sur les performances.
• Comme tout disque d'OSX, ceux-ci sont cachés par le buffer unifié, avec le risque que la quantité de mémoire allouée au Ramdisk soit nécessaire de nouveau pour le buffer.

time dd if=/dev/zero of=/Volumes/OSX/outputfile bs=1024k count=1024

Une petite vidéo qui permet de voir le stockage de la carte perforée à nos jours. Format: A Brief History of Data Storage from Alan Warburton on Vimeo.

Amazon vient de rendre disponible la béta publique de son offre VPC. Virtual Private Cloud, c'est un peu le meilleur des deux mondes. comme je l'avais déjà signalé précédement, le cloud computing dans sa formule de "Infrastructure As A Service" voit encore aujourd'hui de nombreuses réticences dans les entreprises, principalement sur l'aspect public de l'infrastructure. Amazon souhaite amener les entreprises vers ses services d'infrastructures en leur permettant d'y accéder de manière très sécurisée.  VPC est un pont entre le réseau de l'entreprise et une partie "privatisée" du réseau Amazon. Pour entrer un peu plus dans le détail sur l'architecture de VPC, on a un routage IP qui est réalisé de manière encryptée par un protocole IPSEC vers  un pool de ressources AWS dans les datacenter d'Amazon.  Le client dispose de la pleine maîtrise de l'adressage IP et des politiques de sécurités appliquées sur les ressources placées dans ce cloud.  Le client va disposer de la même sécurité que si il devait louer des unités dans un datacenter externe et y installer ses serveurs, mais avec l'avantage de la souplesse du cloud.  L'utilisation de l'architecture Elastique de Amazon permet de retailler très facilement les ressources affectées, et de n'utiliser que ce qui est vraiment nécessaire à un instant T. Les usages qu'on peut imaginer entre autres d'un telle infrastructure seraient :

• La mis en œuvre de plan de continuité d'activité à moindre coûts. Par essence les ressources affectées aux plan de continuité d'activité ne sont utilisée que lorsque celui-ci est actif. Le reste du temps ces ressources sont inutilisées ou alors le sont pour des tâches secondaires, qui peuvent être arrêtées à tout moment. Le concept de base d'Amazon WS et EC2 , consiste à n'utiliser que ce dont vous avez besoin à un instant T.  Pour résumer le client en temps normal ne paye que la consommation de ressources nécessaire à synchroniser son datacenter avec les machines en attentes d'être activées pour le plan de reprise, d'où une approche financière des plus favorables.
• La mise à disposition d'une réserve de ressources pour effectuer des traitements ponctuels et fournir une puissance de calcul instantiable immédiatement. Dans de nombreux business il y a des opérations qui ont une forte saisonnalité, comme par exemple la production de fiches de payes, la réalisation d'inventaires de fin d'année. Autant sur de très gros systèmes, on a une logique de puissance installée et d'activation de tranches à la demandes que sur des architectures ouvertes de type x86, on peine un peu plus à avoir ce type de granularité. Là aussi, il faut prévoir le cas le plus défavorable et acquérir les ressources nécessaires quand bien même celles-ci sont inutilisées pendant les périodes creuses.  De nouveau les concepts évoqués précédemment vont permettre de disposer d'une puissance de traitement qui soit dans un état d'attente donc ne coûtant quasi rien et de mettre celle-ci en route en quelques minutes.

Il convient de rapprocher cette architecture de la possibilité de nos jours d'utiliser les outils de cloud computing dans le datacenter de l'entreprise, et de pouvoir migrer les ressources chez des providers tels Amazon. On se trouve donc aujourd'hui en face de trois type de cloud, le "cloud privé" qui est hébergé chez le clients sur ses propres serveurs physiques, le "cloud privé virtuel" qui donc est hébergé chez le fournisseur, mais vu comme une extension du réseau de l'entreprise, et pour finir le cloud public. Le gros challenge à venir va être la capacité de management et d'interopérabilité entre ces différentes briques qui commencent à être bien abouties. Pour aller plus loin je vous invite à consulter la pasge de présentation Amazon Virtual Private Cloud.

Une des grande capacité des architectures CloudComputing c'est la capacité de scalabilité de celles-ci. Google AppEngine ne déroge pas à la règle, avec une capacité à stocker de gros volumes de données, mais aussi à absorber de grands volumes de connections. Lorsqu'il est nécessaire de traiter des volumes de données importants, pour par exemple mettre à jour une base, ou déclencher des emailing, les temps de process peuvent s'accroître et sortir du cadre d'utilisation classique de la plate-forme. Il y a cependant des solutions pour bien gérer ces problématiques. Elles consistent essentiellement à structurer les accès aux données, et utiliser l'ensemble des outils disponibles. Prenons le cas assez simple d'une table qu'on va parcourir pour mettre à jour des enregistrements. A chaque objet renvoyé par la boucle "for", on enregistre la mise à jour dans la base.

for entity in MyModel.all().filter("color =",
   old_favorite).fetch(100):
   entity.color = new_favorite
   entity.put()

En faisant de cette manière, on fait 1 transaction pour récupérer les 100 enregistrements, puis 1 nouvelle transaction à chaque mise à jour, ce qui nous fait un total de 101 transactions. Dans le système de base de données "Bigtable" de Google Appengine c'est globalement l'appel à l'API qui coute cher. En comparaison avec ce qu'on a pu voir au dessus, il y a une autre façon de réaliser ce traitement :

updated = []
for entity in MyModel.all().filter("color =",
   old_favorite).fetch(100):
   entity.color = new_favorite
   updated.append(entity)
db.put(updated)

Le nombre de transaction chute de manière drastique puisqu'on passe de 101 à 2. L'opération d'enregistrement est beaucuop plus lourde que pouvaient l'être les 101 équivalentes, mais le nombre de call à l'API est réduit à maximum, donc plus efficace. Lorsque de gros volumes de données sont à traiter il peut arriver que le temps de traitement dépasse ce qui est autorisé pour l'exécution d'une requête par Google AppEngine. Depuis la dernière version de Google AppEngine, il est possible de gérer une file d'attente des traitements sur le serveur. Prenons ici l'exemple fourni dans la documentation, il s'agit d'un mailing de masse sur l'ensemble des utilisateurs d'une base. Il y a fort à parier que ce type traitement dépasse très largement dans sa globalité les quelques secondes autorisées pour l'exécution d'une requête. En découpant le traitement en des taches suffisamment petites, et en les mettant dans une file d'attente, ce traitement devient immédiatement scalable.

# for each user, add a task to send a custom email message
for u in users:
   taskqueue.add(url='/work/sendmail',
      params=dict(to=u.email,
         subject='Hello ' + u.name, body='this is a message!'))
return # finished now, emails will be sent offline when tasks execute

# task handler at /work/sendmail, automatically called for each task created above
class MailWorker(webapp.RequestHandler):
   def post(self):
      mail.send_mail('from_me@example.com',
                          self.request.get('to'),
                          self.request.get('subject'),
                          self.request.get('body'))

Après avoir regardé la structure générale du framework et l'organisation des fichiers, nous avons regardé la structure applicative. Cette fois ci nous allons nous atttaquer à un gros morceau puisque nous allons évoquer ensemble le moteur de rendu des pages HTML. Ceux qui sont habitués aux appli web développées en Python ne vont pas trop être surpris puisque Google s'est appuyé sur le reconnu Django. Nous allons passer en revue le fonctionnement de ce moteur, mais je vous recommande d'aller voir la documentation de Django pour approfondir le sujet. Après avoir fait donc ce rendu de base on va maintenant regarder comment créer des blocs de rendu, avec une possiblité d'organiser le code, et de réutiliser facilement celui-ci.

Dans le précédent post je vous avait présenté Google App Engine dans sa globalité, afin de positionner ce framework de développement. Maintenant nous allons entrer plus en détail avec la mis en oeuvre d'un petite application. Au titre vous aurez compris que tout ça va rester trivial pour le moment ! Pour aller un peu plus loin il peut être utile de structurer un peu le code et de pouvoir le décomposer en modules. Ici aussi rien d'extraordinaire, seulement des choses simples, que nous allons découvrir pas à pas. 

Ce post est le premier d'une série sur google App Engine le moteur d'exécution d'application de google en mode cloud computing. Ce framework s'appuie sur Python, langage largement utilisé sur les frontaux web de Google, et permet de déployer des applications sur les serveurs de Google. Tout ceci est d'une pris en main très rapide, même si vous n'avez pas de réelle expérience de Python. Je vous laisse découvrir ça. Principaux liens :

• App Engine Home
• Documentation
• Quotas
• Cookbooks