Le data lake dans l’industrie

Le data lake dans l’industrie

Mettre en place un data lake : peut-on utiliser un data lake généraliste pour les données industrielles ?

Le besoin de pouvoir manipuler des données en masse pour disposer d’informations et prendre les bonnes décisions anime depuis des années l’industrie. BI, Data-Warehouse, Big-Data, data lake (ou lac de données)… sont autant de technologies qui visent le même objectif : stocker de la donnée dans la durée et la traiter pour permettre aux organisations de mieux piloter leurs activités et d’améliorer leur performance.

Aujourd’hui, on peut être tenté de centraliser l’ensemble de ses données quel que soit le métier : commercial, marketing, R&D, production… au sein d’un data lake d’entreprise. Cette approche peut être attrayante pour de nombreuses raisons : centralisation des données dans un seul système d’information, possibilité de les croiser, standardisation…

Le data lake permet aux opérationnels et aux data scientists d’accéder rapidement à des masses énormes de données. Le manque d’exhaustivité, le manque de structure, le manque de performance sont des freins à de nombreuses initiatives industrielles basées sur la donnée. Nous allons aborder dans cet article les éléments spécifiques aux données industrielles et les implications qu’ils ont sur la mise en place d’un data lake (ou lac de données) pour cet usage.

 

Les spécificités des données dans les industries de procédés

Les données issues de procédés de production industriels sont relativement variées mais on observe cependant des constantes en terme de structure. On retrouve en particulier des données :

  • Temporelles (capteurs, contrôles en lignes…) ;
  • Relatives à des lots, opérations, campagnes, cycles (recettes, contrôles qualité, indicateurs, équipe, outillage…) ;
  • Relatives à des évènements (arrêts programmés ou non, alertes, changement d’outillage, de consommable…) ;
  • De traçabilité (où, quand et comment une opération, un lot, a été réalisé) et de généalogie (comment les différentes unités d’œuvre sont reliées entre elle, comment une opération met en œuvre un ou plusieurs lots des opérations précédentes…).

La manière de traiter ces données diffère d’un type de données à l’autre.

On observe donc que ces données sont très différentes de celles des autres métiers de l’entreprise, qui pour la plupart sont des données de type transactionnelles.

 

Les conséquences sur le stockage

Stocker des données temporelles ou des données de traçabilité, par exemple, nécessite des approches différentes afin de répondre aux exigences de performance, de coût et d’usage.

Pour les données temporelles, on doit être capable de traiter des requêtes sur de longues périodes avec des données potentiellement fines. Si on considère une donnée échantillonnée à la minute sur un an, on parle déjà de 525 600 points. Il faut donc être en mesure de gérer ces volumétries dans un temps court, tout en ayant une bonne efficacité de stockage et limiter le volume occupé par ces nombreuses données.

Pour cela, des bases de données spécialisées pour les séries temporelles ont émergé : TimeScaleDB, InfluxDB, KDB+, OpenTSB (HBase-Hadoop), Quasar DDB, Warp, Azure TS Insight, AWS Time Stream DB… L’offre dans le domaine est pléthorique. Pour autant choisir la bonne base de données de séries temporelles n’est pas un sujet simple. Cela dépend grandement des usages attendus.

Pour des données de traçabilité, au contraire, ce sera la capacité à être efficace dans la recherche des éléments requêtés et à reconstruire des arborescences, des généalogies qui va primer. Typiquement ce que l’on attend d’une base de données relationnelle performante.

Sur ces exemples, on voit vite qu’il sera nécessaire de mettre en œuvre une stratégie de stockage hybride, fonction de la typologie de données pour arriver au bon compromis fonctionnalités / performance / coût.

 

Les conséquences sur les traitements

Nous sommes enfin devant notre lac rempli de données. Comment ne pas nous noyer ? Un des premiers éléments est de structurer les données en leur adjoignant un contexte métier. Plusieurs approches s’opposent, certains prônent le fait de travailler sur des données peu structurées. De notre côté, nous sommes des adeptes de la structuration des données au plus tôt dans le processus, dès leur stockage. Le fait d’adjoindre un contexte métier va permettre de faciliter la vie de l’ensemble des utilisateurs du Data Lake, mais fondamentalement cela augmente le niveau d’information, donc ce que l’on peut espérer extraire de ces données.

Cela n’est pour autant pas suffisant pour extraire l’information attendue de ces données. Ce sont les recoupements des différents types de données entre elles et leur transformation qui vont permettre de construire ces informations. C’est là que les données des industries de procédés nécessitent un certain nombre de traitements que l’on retrouve relativement fréquemment :

  • Ré-échantillonnage, extrapolation de données temporelles asynchrones ou d’échantillonnages différents pour les combiner entre elles au travers de calculs ;
  • Agrégation de données temporelles selon des éléments de traçabilité (par exemple moyenne d’un paramètre sur une phase spécifique d’un lot de production) ;
  • Calculs statistiques pour bien appréhender la variabilité des données ;
  • Calculs pour construire un bilan matière, un rendement, une consommation spécifique…

Ces transformations, souvent spécifiques au métier de la production dans l’industrie de procédés, impliquent la prise en compte de nombreuses subtilités pour arriver au résultat, qui peuvent générer un niveau de complexité élevé pour la mise en place d’un data lake (lac de données). De même, tout comme pour le stockage des données, il est important de ne pas mettre de côté l’aspect performance, indispensable pour offrir une expérience utilisateur fluide.

 

Quid d’un data lake global, y compris pour les données industrielles

Revenons sur cette idée séduisante de standardisation en intégrant les données de l’outil de production dans un data lake global à l’entreprise. Elle apporte naturellement un certain nombre d’avantages :

  • Une seule architecture de data lake à gérer ;
  • Un stockage centralisé des données ;
  • Des outils standards pour l’ensemble des métiers de l’entreprise.

Cependant, comme nous avons pu le voir, les usages faits des données des procédés de production ont un certain nombre de caractéristiques qui peuvent rendre cette approche moins attrayante :

  • Une infrastructure et une architecture de données qui ne sont pas adaptées ni aux typologies de données traitées, ni aux besoins de performance nécessaires pour les usages attendus.
  • Des besoins de traitement des données qui nécessitent de nombreux développements spécifiques pour effectuer les transformations nécessaires pour construire les informations attendues, ce, au risque d’arriver à un système complexe et difficilement maintenable.
  • Le manque d’outils métier pour répondre aux besoins spécifiques des métiers liés à la production, la qualité, les procédés industriels… Et potentiellement le besoin de réaliser des développements spécifiques en fonction des besoins.
  • Cela amène à gérer la complexité d’un grand ensemble plutôt que de le diviser en ensembles plus cohérents et plus faciles à gérer.
  • Au final des coûts de mise en œuvre et de maintenance élevés ainsi que des temps de déploiement long pour réussir à répondre aux besoins.

 

Intérêt du data lake spécialisé ou « Process Data Lake »

Ce que nous appelons le « Process Data Lake », est un data lake spécialisé pour les données industrielles, accompagné d’outils métiers permettant de répondre rapidement et de manière très opérationnelle aux besoins.

C’est un cadre adapté aux stockage, traitement et utilisation de la donnée industrielle et qui offre :

  • Une architecture adaptée aux données industrielles et à leurs usages : comme expliqué plus haut la juxtaposition de types de bases de données divers répondant aux contraintes des séries temporelles (bases de données noSQL optimisées pour les séries temporelles) comme à celles des données de traçabilité (type relationnelle permettant la gestion des généalogies) ;
  • Des performances en ligne avec les besoins de traitement des utilisateurs : ceci est directement lié à la façon dont les données ont été structurées et stockées selon leurs spécificités ;
  • Un déploiement rapide : parce que les traitements les plus fréquents utilisés dans l’industrie de procédés cités ci-dessus (ré-échantillonnage, extrapolation, agrégations, calculs de bilan matière, rendement, construction de généalogies…) sont déjà pré-configurés ;
  • Un coût d’implémentation et de fonctionnement maitrisé : car vous bénéficiez de l’expérience accumulée auprès de multiples clients industriels et que nous assurons les fonctions de maintien en condition et d’évolution grâce à notre architecture Saas.

 

 

Quid de mettre ses données industrielles sur un data lake générique Hadoop ?

Quelques exemples d’impacts du choix d’un data lake générique sur les usages liés aux données industrielles. Des groupes industriels ont pu se lancer dans des démarches autour d’un data lake global basé sur des technologies Hadoop, voici les écueils rencontrés.

Une des premières difficultés a été la gestion des données sous forme de séries temporelles dans HBase, la base de données de Hadoop : il est nécessaire de regrouper ensemble les données qui ont une maille de temps trop fine, de prévoir des données pré-calculées pour les agrégats temporels (min, max, moyenne…) aux pas utiles pour les usages (15 minutes, 1 heure, 1 jour…). Cela génère une complexité dans la logique de calcul, mais aussi une grande inefficience en termes de volumétrie de stockage à cause des recopies. En parallèle, des systèmes comme HBase ne sont pas optimisés pour compresser efficacement des données temporelles.

Même en utilisant une surcouche de gestion des time-series (OpenTSDB par exemple), le traitement des séries temporelles souffre du coût engendré par le nombre de couches techniques et de la complexité de Hadoop.

La seconde difficulté a été le choix des indexations en fonction des usages. Ce type de bases de données colonnes est très sensible à ces choix car le design des clés de colonnes (Row Key) est primordial pour optimiser les requêtes. Dès que les recherches font appel aux caractéristiques des données qui ne composent pas la RowKey (les Tag), alors les performances sont très dégradées. Par exemple, si on s’intéresse aux données d’un capteur sur une période de temps, l’idéal est d’avoir un RowKey de type « SensorID-TimeStamp ». Ce qui s’avèrera inefficace sur d’autres types de recherche sauf à créer des duplicatas des tables avec chacune la RowKey adaptée à l’usage, au prix d’une augmentation de la complexité et du coût de stockage.

En conclusion, ce type d’approche nécessite un investissement en ressources très important pour gérer la complexité de Hadoop, et un très gros travail de design basé sur les usages pour permettre une réelle exploitation des données industrielles. Une fois implémenté, le coût de gestion et de maintenance de ce type d’architecture sera aussi très élevé du fait de sa complexité.

 

 

Auteurs : Mathieu Cura, Jean-François Hénon

Echangeons sur vos enjeux métier