#PARTAGE Big Data par l exemple Alexandre Chauvin Hameau Directeur de la production Malakoff Médéric @achauvin CT BIG DATA 10/12/2015
Soyons pragmatiques BIG DATA beaucoup de bruit pour des choses finalement assez usuelles et connues Vous en faites, nous en faisons et depuis longtemps : BI, analytics, dataviz, statistiques, calcul distribués Ce qui a vraiment changé : la vision du métier, la presse, les approches commerciales la technologie, notamment au niveau du stockage et de la distribution des calculs avec des solutions opensource le fait que des efforts soient placés dans l analyse et que la soif dans la donnée soit importante au plus haut de la hiérarchie
La DSI, outilleur du Big Data Le Big Data ce n est pas une approche technique, la connaissance du métier est indispensable Mais l informatique doit apporter la boîte à outils pour que le métier puisse creuser dans les données, inventer des modèles, découvrir des horizons Ceci est valable pour les données de tous les métiers, y compris ceux de la production, un très bon début pour se faire la main : l analyse des logs Pour diagnostiquer rapidement les incidents Pour anticiper Pour découvrir les aberrations en avance de phase À des fins sécuritaires (SIEM)
3 exemples, mis en place chez nous Collecte et visualisation des logs et des indicateurs techniques Moteur de recherche et statistiques sur l outil ITSM Hadoop pour l exploration des données Techniquement basés sur des solutions différentes pour des usages différents Du temps réel, de l indexation, de la recherche, de la visualisation rapide pour creuser dans le puits de données Du temps différé, batch, du calcul, la base à du décisionnel ou de la découverte de nouveaux modèles
1- Collecte et visualisation des logs et des indicateurs techniques Tous les systèmes informatiques construisent des journaux de log, les exploiter permet de découvrir des dysfonctionnements et d'anticiper des anomalies Elastic : point focal de consolidation des logs, non structuré donc souple, simple d'interrogation, massivement distribuable et résultats de recherche en temps réel Logstash : collecteur et découpeur de log - multi protocole, capacité avancées d'analyse pour le filtrage et le découpage (en champs dans Elastic). Couplé à nxlog pour la collecte sur serveurs (Windows & Linux) qui filtre et découpe à la source. Création d'un index Elastic par jour, plus de simplicité pour stockage et manipulation Kibana : visualisation des données dans une interface web 25 Go de données par jour de collecte pour 30M de documents
1- cluster technique elastic CT BIG DATA 10/12/15
1- kibana, quelques exemples CT BIG DATA 10/12/15
2- Moteur de recherche sur l outil ITSM Un de nos outils de base à la production est l'itsm, tous les changements, incidents, problèmes y sont manipulés quotidiennement Besoin fort de tableau de bord intégré et de recherche pour résolution ou analyse à froid Collecte des données sur l'outil et insertion dans elastic (via batch) 700 K documents à date Développements spécifiques pour le moteur de recherche et l'intégration dans l'outil de tableau de bord de production (php, symfony) Transfert du puits de données mysql vers elastic pour l'ensemble des indicateurs de production
3- Hadoop & Hive pour l exploration des données Construction d un cluster hadoop en mode «prospectif», dans une démarche de découverte, au cas où 18 nœuds sur du matériel de récupération, plutôt ancien (4 ou 8 cœurs, 8 Go de RAM, 130 Go de disque) CentOS 7 avec installation automatique sur kickstart + ansible Distribution Cloudera (base RPM) Utilisé par une équipe agile (MOE + métier + data scientist) autour de quelques idées pour la recherche d un modèle de prédiction et de conseil Sur un faible volume de quelques centaines de millions de lignes, 3 sources de données, manipulées par Hive en mode SQL, au total moins de 200 Go
A-t-on besoin d hadoop? Tout dépend de ce que l on fait! Pour des volumes de données faibles, on peut largement s en passer, c est beaucoup plus simple avec une base de données ([no]sql) Dès que l on traite des volumes plus conséquents et avec de multiples sources, alors le modèle distribué prend tout son sens 20 petits serveurs iront plus vite qu un gros, Imaginez 100 ou 1000! Une des clés est liée au volume de données brutes sur lesquelles on fera des traitements, on peut démarrer avec : >10 millions de lignes > 500 Go aujourd hui un serveur moyen c est 256 Go de RAM / 16 To de disque Mais les données seront plus simples à manipuler si elles sont traitées nativement avec des développements spécifiques (ie hors hive)
Performances SQL vs hadoop? Comparaison d'usage entre mysql, hive et un développement spécifique hadoop (python + pipe) sur la même source de données Temps comparés sur : chargement des données, count distinct, select avec substring, groupement complexe avec unicité MySQL plus performant jusqu'à 5.000.000 de lignes vs hive et 3.000.000 vs python Python toujours plus performant que hive (30 % à 100%) MySQL s'écroule à 10.000.000 de lignes :
Supervision de notre cluster hadoop collectd sur chaque nœud, logstash pour la collecte et insertion dans elastic, kibana pour la visualisation
Attention à l excès de confiance Hadoop ne fait par construction pas de temps réel, l approche batch est à privilégier, même si des solutions dynamiques sont désormais disponibles (ie spark in-memory map reduce) La configuration requiert un peu d expérience dans les environnements distribués et l open-source, mais pas de complexité particulière La manipulation de gros fichiers n est pas simple, notamment lorsque leur taille dépasse celle d un volume disque HDFS réparti les données sur l ensemble des nœuds du cluster Un file system ne propose généralement pas la même souplesse Nous avons utilisé glusterfs sur les mêmes disques que l HDFS pour la manipulation de fichiers intermédiaires (copie, découpage, compression, tests ) La supervision d un cluster hadoop n est pas implicite, tout est automatique et donc opaque. Plus il y a de nœuds et plus c est complexe à piloter Il faut écrire du code pour en tirer vraiment la quintessence Autres pistes : impala, amazon redshift, apache Tez, HP Vertica, looker.com, environnements très mouvants
Mais allez-y! Le rôle de la DSI et en particulier du CTO est de pousser à la mise en œuvre (interne ou service) de ce genre d infrastructure, a minima pour se faire la main et accompagner les métiers dans leurs expérimentations Le rôle des éditeurs et des constructeurs est d aller voir directement les métiers pour leur proposer leurs services, la concurrence est donc forte, mais les enjeux de localisation et de maîtrise des données sont énormes pour toutes les entreprises La suite technique de l aventure big-data est probablement autour du machine learning, mais c est une autre histoire