Une erreur est survenue dans ce gadget

mardi 23 août 2011

10 Lessons Learned By Big Data Pioneers

Un petit article par InformationWeek qui a retenu mon attention ici. Les Yahoo, Facebook, Netflix et Google sont devenus des référents en matière de gestion de leur centaines de teraoctet de données... Mais ce qui est étonnant, c'est leur façon de faire de par leur origine et leur histoire.



L'optimisation... comme principe directeur
La vitesse des requêtes est LE critère à prendre en compte (Lesson 1 - Fast querying ensures productivity and timeliness) et pour cela il ne faut pas hésiter à compresser les données (Lesson 3 - Compression cuts storage cost) et même ranger les données pour que cela optimise cette compression (Lesson  4 - Sorting improves compression, cuts processing time). S'il le faut, il vaut mieux avoir moins de données pour des aspects de performance (Lesson 7 - In many industries, speed trumps scale). 

L'énorme dataware où l'on met tout en vrac avec une profondeur historique maximale et sur lequel on requête pendant des heures.... Cela n'arrive jamais...

La prévision devient une "science" vitale.
Regarder juste le nombre de lignes et projeter dans le futur la croissance ne va pas suffire (Lesson 2 - Be careful what you count when measuring Data growth). Il faut prendre en compte tous les facteurs d'évolution qui pourrait influer sur votre prévision. L'article cite que si le nombre de patient est resté stable pour la Harvard Medical School... la richesse du dossier médical a considérablement augmenté la taille des bases. Un autre point également intéressant est de regarder le sujet sous 6 critères (10 - Consider all dimensions of scalability)

  • Taille des données
  • Complexité des données
  • Nombre d'utilisateurs
  • Nombre de requêtes
  • Complexité des requêtes
  • Le temps de réponse souhaité

La tentation Hadoop...  
La première chose à comprendre d'Hadoop, ce n'est pas tant dans sa performance en tant que telle mais plutôt le rapport volumétrie traitée vesus prix (Lesson 5 - Hadoop appeal includes low cost and unstructured Data processing). Si vous cherchez à agréger des centaines de To de log... Il est clair qu'une base de données est une solution logicielle et matérielle bien trop coûteuse pour faire cela. Et surtout, dans sa nature même, il va vous éviter de "charger dans" une base de données (Lesson 6 - Hadoop helpers ease loading and processing pains).


Midi à... 14 heures
Le dernier point est plus étonnant... ou intéressant et que je résume par faut-il chercher midi à 14h ? Big Data ne veut pas forcément être en rupture avec tout l'acquis et ce qu'on maîtrise (Lesson 8 - Go with what you know if it fits). Et qu'il vaut mieux s'appuyer sur des succès passés (Lesson 9 - Build on success)... plutôt que succomber à des "nouvelles" sirènes !

Aucun commentaire:

Enregistrer un commentaire