dmussman - Fotolia
Trois méthodes pour bien préparer ses fichiers mainframe à Hadoop
Les lacs de données Hadoop constituent un nouveau havre de paix pour les données patrimoniales qui ont encore une valeur analytique. Mais les méthodes de conversion à utiliser dans Hadoop diffèrent selon les besoins analytiques.
Alors que les entreprises sont en train de revoir leurs architectures de données pour soutenir nouvelles applications analytiques, il existe une tendance : l’enrichissement des grands entrepôts de données traditionnels par des environnements Big Data d’un nouveau type.
Si les data lakes Hadoop renferment généralement de nouveaux types de données, ils peuvent également servir de dépôt pour d’anciennes données qui ont toujours une valeur analytique exploitable.
C’est l'une des raisons pour lesquelles on intègre les systèmes Hadoop aux entrepôts de données : ils permettent de déplacer les données froides, peu consultées, d'un entrepôt de données vers les tables Hive s'exécutant au-dessus d’HDFS. Ce mélange des bases de données conventionnelles avec Hadoop est souvent une première étape dans la modernisation des données. Cela ouvre tout un champ d’applications autour de jeux de données Hadoop, qui redeviennent dès lors utiles.
Un aspect particulièrement prometteur concerne la migration de données historiques en volume vers de grands environnements de données pour en faciliter l’accès et l'analyse. Dans de nombreux cas, ces données sont stockées dans des fichiers mainframe, tels que les fichiers VSAM, IMS et COBOL. Lors de la planification d'une migration des données patrimoniales vers un lac de données, il convient de considérer les différentes alternatives de format cible, selon les cas d’usage.
Par exemple, si la mission est de déplacer les données d'une ancienne plateforme vers une autre plus moderne pour mettre en place un service de stockage continu, l'approche sensée pourrait être de simplement copier les fichiers mainframe vers HDFS et de tirer profit de la redondance et de la tolérance aux pannes des clusters Hadoop. Une fois les fichiers déplacés, vous pouvez préparer l'ancien système au décommissionnement.
Plus qu'un travail de récupération de données
Cependant, la récupération des données patrimoniales n’est plus le seul intérêt : on pense également à leur utilisation en production. Ces anciens jeux de données comprennent justement des années de données transactionnelles ou des logs opérationnels. Ceux-ci peuvent être soumis à diverses formes d'analyses avancées, (celle des séries chronologiques par exemple, ou via des algorithmes de Machine Learning), pour desceller des modèles qui peuvent aider à prédire les tendances à venir ou encore des opportunités de marché.
Si tel est votre objectif, la seule copie des fichiers existants ne sera pas suffisante, à moins que vos applications analytiques ne soient conçues pour lire le format source des mainframes. La question qui se pose alors est la suivante: Comment transformer ces fichiers patrimoniaux en données Hadoop, plus adaptées à l'analytique moderne?
Voici trois méthodes pour convertir les fichiers mainframe en formats qui peuvent supporter une analyse plus étendue :
- Transformation de fichier à fichier. Dans cette approche, les fichiers d'origine sont transformés dans un format moderne, tel qu'un fichier texte ASCII, et les instances de données originales sont conservées dans les nouveaux fichiers. Cela est adapté à un lac de données simple dans lequel les données Hadoop sont stockées et gérées comme des singulières. Cette option permet de maintenir les types d'utilisation des données qui ne reposent pas sur de nouvelles méthodes de gestion et d'analyse des données -- par exemple, dans les cas où les utilisateurs demandent des extraits de données à grande échelle qui ne requièrent que de simples scans des enregistrements. Par conséquent, les entreprises qui s’engagent dans la modernisation des données peuvent choisir cette option si elles souhaitent recevoir moins de résistance en interne.
- Stockage basé sur SQL. Cette approche consiste à exploiter les moteurs de données SQL qui sont superposés sur Hadoop. Exemples : Hive, Impala, Presto, Drill, IBM Big SQL et Spark SQL. L'alternative SQL-on-Hadoop est un peu plus complexe, car elle nécessite le recours à des processus d'intégration pour transformer les données en un format qui puisse être chargé dans HDFS ou un autre référentiel, puis interrogé via SQL. Cependant, avec cette méthode, les utilisateurs peuvent exécuter des requêtes SQL standard pour accéder aux données et les analyser. Cette option prend en charge les applications d'analyse dimensionnelle, les requêtes ad hoc directes et même un certain niveau d’automatisation de services.
- Stockage d'objets individuels. La troisième option consiste à transformer chaque instance de données en son propre objet en utilisant XML et JSON. Cela offre beaucoup plus de flexibilité lorsqu'il s'agit d'analyser des ensembles de données Hadoop parce que des objets stockés dans une architecture en cluster constituent un environnement idéal pour exécuter de programmes MapReduce ou Spark. Cette option peut toutefois nécessiter un travail supplémentaire pour transformer les données dans le format cible.
Alors, quelle est la meilleure façon de procéder? Cela dépend en grande partie des analyses que l’entreprise souhaite effectuer. Mais il faut reconnaître que la modernisation des données ne se fait généralement pas du jour au lendemain. En fait, avec le temps, les utilisateurs des données seront plus nombreux et leurs besoins en termes analytiques plus précis. Chaque approche pourra ainsi avoir son cas d’usage.
