Big Data

Quand le volume ou la fréquence fait plier les outils habituels, il faut changer d’architecture plutôt qu’ajouter des rustines.

Le terme est galvaudé. Dans les faits, on parle de Big Data à partir du moment où les outils classiques — un tableur, une base relationnelle sur un seul serveur — ne suivent plus. Ce seuil dépend moins du volume brut que de ce que vous voulez en faire.

Les signes que le seuil est franchi

• Une requête qui prenait dix secondes en prend maintenant dix minutes.
• Le fichier de référence ne s’ouvre plus, ou plus qu’avec un logiciel spécifique.
• Vous avez renoncé à analyser certaines données parce que c’est trop lourd.
• Les traitements de nuit débordent sur la journée de travail.

Les réponses possibles

Avant de parler de cluster ou de cloud, on regarde souvent l’évidence : une indexation manquante, un modèle de données mal pensé ou un traitement qui recalcule tout au lieu de traiter l’incrément. Beaucoup de projets présentés comme des chantiers Big Data se règlent en optimisant l’existant, pour une fraction du budget.

Quand un changement d’échelle est réellement nécessaire, les pistes sont le partitionnement, les bases orientées colonnes, le traitement par flux plutôt que par lots, ou l’externalisation du calcul. Chaque option a un coût d’exploitation et un coût d’apprentissage qu’il faut mettre en face du gain attendu.

Ma position

Je commence toujours par chercher la solution la moins coûteuse et la plus réversible. Une architecture distribuée impose des compétences que toutes les structures n’ont pas, et un engagement chez un fournisseur dont on ne sort pas facilement. Ce n’est justifié que si le besoin le justifie vraiment.