Overblog Suivre ce blog
Administration Créer mon blog

Le Big Data : une révolution en marche

4 Mai 2012 , Rédigé par benkirane Publié dans #Nouvelles technologies

Avec l'avènement des réseaux sociaux en particulier et du Web en général, le nombre de données produites est en constante augmentation. Chaque individu, aujourd'hui, génère un nombre très élevé d'informations. Cette volumétrie génère, elle-même, de manière automatique de la donnée. En effet, plus on a d'informations, plus on a besoin de l’indexée (moteurs de recherche, annuaires) ou simplement de la traiter pour y apporter de la plus-value (Business Intelligence, CRM, cyber-criminalité, ...). Les problématiques de stockage, traitement et restitution de ces données dans des temps raisonnables sont devenues primordiales.La solution Big Data alliée à des frameworks comme Haddop ou le Map Reduce, a vu le jour pour répondre à ces problématiques. Cette nouvelle notion apporte avec elle quelques révolutions technologiques mais aussi intellectuelles.

Le Big Data : la révolution des systèmes de gestion des données

La première révolution qu'apporte le Big Data est la façon dont les données sont gérées. Pour traiter des quantités énormes de données qui arrivent, en temps réel, à partir de sources très diverses (humains, robots, électroniques, capteurs, ...), les contraintes imposées par les SGBD relationnels associé à leur coût exorbitant (administration, licence, infrastructures) ne peuvent plus perdurer. Deux principales causes à cela: la première est la capacité faible d'évolution des systèmes relationnels et la seconde la nécessité de structurer les données.

Dans les systèmes actuels, il devient de plus en plus difficile de prévoir la quantité de données qui seront stockées. Des entreprises comme google, facebook, amazon ou autre twitter ne peuvent savoir au Go près quel volume de données elles auront à gérer et à quel moment. La nécessité de disposer d'un système fortement évolutif est primordial. C'est là qu'interviennent les bases de données NoSQL (Not Only SQL). Cette terminologie représente l'ensemble des bases de données non relationnelles. Elles répondent exactement aux problématiques soulevées précédemment:

  • Elles sont fortement évolutives. Leur architecture technique est complètement distribuée et basée sur des machines standards ( moins coûteuses). L'augmentation de la capacité de stockage est alors simple puisqu'il s'agit bien souvent d'ajouter quelques machines dans le système. Les données et les temps de calcul sont alors réparties sur l'ensemble de celles-ci de manière automatique.
  • Les données ne sont pas structurées. Il n'y a plus de notions de tables, de type de données et encore moins de relations entre elles. Les données sont stockées de façon brutes, les causes d'erreurs lors des enregistrements sont alors très limitées, voir inexistantes.

En réalité, le NoSQL n'est pas vraiment une révolution puisque le terme est apparu la première fois en 1998. C'est plutôt sa mise en œuvre à grande échelle depuis ces dernières années qui est une révolution. Les investissements des grandes entreprises de l'informatique moderne citées précédemment sur ce type de SGBD sont sans précédent.

Le Big Data : la révolution des algorithmes de calculs

L'idée première derrière l'utilisation du Big Data est le traitement de l'information à des fins politiques ou commerciales. L'important est d'apporter de la plus-value à ces volumes de données. C'est ce qu'on appelle la Business Intelligence. On traite, par exemple, le contenu des messages postés par un utilisateur afin de connaître ses aspirations et lui fournir du contenu personnalisé qui y réponds.

La volumétrie des données ne permet plus d'utiliser des algorithmes de calculs classiques par récupération de lots de données. Il est nécessaire de recourir à de nouveaux concepts de regroupement de données associé à un calcul distribué. C'est sur ces bases qu'a été imaginé le framework Map Reduce proposé par Google et faisant partie de la solution Hadoop (Apache).

En très simplifié, l'algorithme Map Reduce s'exécute en deux étapes:

  1. La partie Map associe une valeur ou un ensemble de valeurs à une clé personnalisée,
  2. La partie Reduce effectue un calcul sur chacune des valeurs en regroupant les données ayant une clé identique.

Pour comprendre en détail cet algorithme, je vous propose de lire le tutoriel Map Reduce sur le site officiel d'Hadoop.

La possibilité de paralléliser cet algorithme de traitement en fait un outil très puissant pour générer, efficacement, des données à forte valeur ajoutée.

Le Big Data : la révolution des usages

Comment souvent en informatique, des révolutions techniques entrainent souvent des révolutions en terme d'usage. Les applications mobiles en sont un bon exemple. Pour le Big Data, c'est la même chose! La capacité à stocker et traiter un nombre de données en constante augmentation et en temps réel a permis à de nombreuses entreprises d'innover. On a ainsi entendu parler ces dernières années de social TV, de voiture connectée ou encore d'habitat connecté.

Lire la suite

Architecture logicielle : Web services SOAP ou REST ?

3 Mai 2012 , Rédigé par benkirane Publié dans #Architecture logicielle

Le développement de services Web est devenu depuis quelques années un enjeu primordial pour certaines entreprises. Il permet, entre autres, de mettre à disposition à d'autres des services spécifiques à son domaine d'activité qu'ils soient gratuits ou, pour une meilleure qualité de service, payants. Les services Web offerts par google maps, par exemple, sont devenus en quelques années des standards dans le domaine de la géolocalisation. Pour leur mise en œuvre, plusieurs méthodes sont possibles: la traditionnelle basée sur SOAP et celle qui est en constante croissance, basée sur une architecture de type REST. Cet article ne se veut pas une éloge pour l'une ou l'autre des méthodes, il en résume les avantages et inconvénients. Le choix de l'utilisation de l'une ou l'autre doit bien être l'aboutissement d'une étude des besoins de chaque entreprise en fonction de son contexte propre.

SOAP

Au départ, les architectes d'entreprise ont privilégié les services Web de type SOAP. Les principaux avantages de ce protocole étant:
  • l'indépendance vis à vis du langage de programmation,
  • l'indépendance vis à vis de la plateforme où ils sont déployés,
  • son extensibilité,
  • l'utilisation du standard XML pour l'échange des messages,
  • le contenu des messages échangés qui incluent le format d'échange cela permet d'avoir un contrat personnalisé entre le fournisseur et le consommateur du service,
  • l'utilisation du protocole HTTP pour le transport qui permet de s'affranchir des problématique de firewalls: en réalité SOAP est indépendant de la couche de transport puisqu'il l'a redéfini (entête, format d'échange, type des données échangées, ...). Cependant, HTTP est le protocole de transport le plus largement utilisé par SOAP.

Ces avantages devaient permettre une interopérabilité entre des applications hétérogènes développées en Java, .NET ou PHP. Cependant, les architectes ont été confrontés à des problèmes parmi eux:

  •  SOAP étant extensible, plusieurs standards sont apparus, regroupés sous la forme WS-* :

    WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, WS-RemotePortlets, etc. Leur nombre croissant a abouti à l'augmentation de la complexité perçue de SOAP. De plus, des différences d'implémentations ont aboutis à des problèmes d’interopérabilité entre applications hétérogènes. 
  • pour que les applications puissent interagir entre elles, la description des Web services en WSDL et la définition d'un dictionnaire de données sont nécessaires dans l'entreprise. Cependant, dès qu'une erreur de conception de ce dictionnaire apparaît, l'implémentation des services Web devient problématique et couteuse. Ajoutée à cela, le coût de mise en œuvre des fichiers de description des services Web (le WSDL) et des fichiers de données (XSD). En résumé, le coût de mise en œuvre est souvent très élevé.
  • La conception des services Web en elle-même. Si un service est mal conçu, et cela peut arriver très vite, le nombre de données qu'il renvoie peut-être très important. Ajoutée à cela, la verbosité de SOAP, très rapidement, des problèmes de performance sont rencontrés qui induisent souvent à une remise en cause de la conception elle-même des services.

Le coût et la complexité d'implémentation générés par les inconvénients de SOAP ont remis en cause, complètement, les avantages de son utilisation. Les réseaux sociaux, dans un premier temps, avec leur volume de données échangées puis les autres entreprises, ensuite, se sont positionnées sur un autre moyen de mettre en œuvre des services Web moins couteux, plus simple à implémenter et surtout plus efficace. Cette méthode qui n'est pas nouvelle puisqu'elle est basée sur les fondamentaux du protocole HTTP est l'architecture REST (cf. mon billet précédent sur ce thème).

REST

Les architectures de type REST deviennent, de plus en plus, des standards dans les entreprises aujourd'hui. La plupart des consultants en informatique de gestion vous le diront. Cependant, au delà de l'effet de mode, la mise en œuvre de services Web basée sur cette architecture a de quoi séduire. Les principales motivations pour le choix de cette architecture sont:

  • l'indépendance vis à vis du langage de programmation,
  • l'indépendance vis à vis de la plateforme sur laquelle ils sont déployés,
  • la plus grande simplicité d'implémentation car la couche transport n'a pas besoin d'être redéfinie et il n'est plus nécessaire de créer un dictionnaire de données comme on le fait avec SOAP.
  • la non intégration du format d'échange au sein des messages. Cela induit une verbosité beaucoup plus faible et donc une performance accrue et une plus grande souplesse dans l'implémentation,
  • l'utilisation de multiples formats pour l'échange de données (XML, JSON, HTML),
  • qu'elle est plus proche de la conception et de la philosophie initiale du Web (URI, GET, POST, PUT et DELETE),
  • pas de gestion d'états du client sur le serveur.

Comme les services Web de type SOAP, ceux basés sur l'architecture REST ont le gros avantage d'être interopérables et indépendants de leur environnement de déploiement avec, en bonus, de meilleures performances. Cependant, ils ont des défauts conséquents à leur adhésion au protocole de transport HTTP:

  • une limitation en matière de sécurité,
  • il n'est pas fiable et ne garantit pas la bonne transmission des messages,
  • la limitation en terme d'actions possibles (CRUD uniquement),
  • les navigateurs actuels implémentent mal les opérations PUT et DELETE.
Dans la réalité, ces limitations ne sont pas vraiment un frein. La sécurité peut-être introduite de plusieurs façons différentes (tokens d'authentification, HTTPS, des outils comme Spring security en java). Les problèmes de standardisation des navigateurs sont détournés par surcharge de la méthode POST. Le vrai frein au choix de REST pour la mise en oeuvre de Web Services est le besoin propre à chaque application.

Conclusion

Internet existe depuis plusieurs décennies maintenant et, avec le retour des architectures REST, on peut se rendre compte que pendant ces années, beaucoup ont perdu les fondamentaux même du protocole HTTP. Les navigateurs, eux-mêmes, ne l'implémentent pas convenablement, ce qui est un comble. De mon point de vue, en tant que professionnel du Web, le plus grand avantage de REST est de revenir aux sources de la toile comme l'ont pensé ses créateurs. Le Web n'est pas un ensemble de pages HTML mais un ensemble de ressources dont l'une des représentations est le HTML. D'autres sont possibles comme JSON, XML, PDF, etc... Sur ces ressources, il est possible d'effectuer 4 opérations principales qui sont GET, POST, PUT et DELETE, du CRUD en résumé.

Ceci est important, lorsqu'on réfléchit au choix d’architecture logicielle. Si vos services Web sont orientés action (plus complexes que les opérations simples du CRUD) et qu'ils nécessitent une sécurité élevée ou un contrat rigide d'échange, SOAP sera, souvent, le protocole le plus adapté.

Si vos services Web sont orientés ressources avec des opérations simples sur celles-ci, REST sera le choix le plus judicieux. Le développement de ces services se focalisent plus sur l'identification des ressources. REST impose le reste de la conception par la possibilité d’implémenter les 4 actions ou verbes (HTTP) du CRUD.

 

Lire la suite