Les bases de données à migrer peuvent avoir un large éventail de représentations et de contenus de données. Des simples champs de données numériques aux champs avec une structure et un contenu complexes, pouvant contenir des fichiers, des images, des tableaux ou même des objets personnalisés complexes (par exemple aux formats XML, CLOB, BLOB, etc.).

La découverte de données plus simples peut être effectuée facilement et très efficacement en utilisant des méthodes traditionnelles avec des connaissances de base et des ensembles de valeurs. Cependant, à mesure que les données deviennent plus complexes, cette efficacité diminue jusqu’à ce que les méthodes traditionnelles ne suffisent plus.

Ces données plus complexes peuvent être, par exemple, du texte non structuré ou des fichiers binaires dont le type et le contenu ne peuvent pas être clairement identifiés et interprétés. Par souci d’argumentation, ignorons le fait que l’utilisation de tels types de données dans les bases de données n’est justifiée que dans quelques cas spécifiques, car ce problème se pose souvent lors de la migration de systèmes complexes. Ces formats de données complexes sont généralement non structurés, structurellement seulement un ensemble d’octets dans un champ donné, sur lesquels l’utilisateur ne dispose souvent d’aucune information fiable en raison d’une documentation incomplète. Sans méta-informations, il est difficile de tirer des conclusions sur le type de contenu et son interprétation. Notre première tâche consiste donc à décider quel type de données ces champs contiennent.

Le moyen le plus évident d’identifier les types de fichiers serait de vérifier leur extension, mais lorsqu’elles sont stockées dans une base de données, ces informations ne sont généralement pas disponibles, ou même si elles l’étaient, elles ne pourraient pas être utilisées avec un maximum de confiance. En supposant que seule la version binaire des données est disponible, c’est-à-dire Binary Large Object (BLOB), la première étape consiste à la charger. Toutes les métadonnées sont encodées dans ce BLOB, selon le format du fichier.

Selon le format du fichier ou le type de données, les métadonnées du fichier peuvent apparaître à plusieurs endroits du fichier, soit dans l’en-tête, soit à la fin du fichier. En plus d’identifier le format de fichier, les en-têtes de fichiers peuvent également contenir des métadonnées sur le fichier et son contenu. Les fichiers (texte) basés sur des caractères ont généralement des en-têtes basés sur des caractères, tandis que les formats binaires ont généralement des en-têtes binaires, bien qu’il ne s’agisse pas d’une norme, mais simplement d’une pratique industrielle.

La distribution des valeurs d’octets dans différents types de fichiers présente un modèle différent pour chaque type. Les premières tentatives se sont concentrées sur la distribution des octets du fichier entier, mais les méthodes plus récentes effectuent un échantillonnage différent, par exemple en analysant uniquement les échantillons du début, de la fin et du milieu des fichiers. Ces échantillons peuvent constituer une bonne base pour apprentissage automatiquequi permet de déterminer (avec une certaine probabilité) le type de fichiers inconnus à l’aide d’un modèle construit sur les différentes distributions. Dans une procédure basée sur BFD (Byte Frequency Distribution), il n’est pas nécessaire de lire l’intégralité du fichier, ce qui permet de gagner du temps. Les valeurs extraites de plusieurs positions du fichier sont analysées statistiquement pour obtenir une empreinte propre au fichier. Sur la base de cette empreinte digitale, l’apprentissage automatique est capable de trouver le type de fichier dans le modèle – celui que nous lui avons appris avec des fichiers connus – qui lui correspond le mieux.

La figure ci-dessous montre la distribution en octets de certains types de fichiers :

Veuillez noter que tous les codes et exemples de données d’entrée/sortie dans cet article sont dérivés de Clarity Consulting. MigNon outil. Ce logiciel d’assistant de migration de données est le résultat d’un projet de R&D pluriannuel, partiellement financé par l’Union européenne.

Application de l’apprentissage automatique à la reconnaissance des formats de fichiers

L’apprentissage automatique peut être une méthode efficace pour la reconnaissance de formats de fichiers, en particulier lorsque vous travaillez avec de grands ensembles de données. Les modèles suivants peuvent être pris en compte pour la détection du format de fichier :

• Bayes naïf: convient à l’analyse basée sur les octets ou les séquences, où les caractéristiques typiques de chaque format de fichier, telles que les distributions d’octets ou les modèles caractéristiques, sont prises en compte.
• Machines à vecteurs de support (SVM): Un bon choix lorsque les limites entre les formats de fichiers, c’est-à-dire les surfaces de décision, doivent être définies sur la base de la fréquence des octets.
• Forêt aléatoire: Parmi les méthodes d’apprentissage d’ensemble, Random Forest est souvent utilisée car elle peut gérer de nombreux formats de fichiers différents et gérer des données bruitées.
• Réseaux de neurones convolutifs (CNN): Les CNN sont capables de reconnaître les modèles de distribution d’octets et peuvent traiter les fichiers comme des images où la fréquence d’octets est interprétée comme des « pixels », reconnaissant ainsi différents formats de fichiers.
• Encodeur automatique: peut être utilisé pour l’apprentissage non supervisé, notamment pour la détection d’anomalies, lorsque l’on tente de détecter des fichiers avec un modèle d’octet différent de celui habituel pour un format de fichier donné.
• K-Voisins les plus proches (KNN): Pour les petits ensembles de données, cela peut constituer un moyen simple mais efficace d’identifier les formats de fichiers en fonction de la similitude de leurs voisins les plus proches.
• Réseaux de neurones récurrents (RNN): Étant donné que les RNN gèrent efficacement les données séquentielles, ils peuvent être utiles pour les tâches où les séquences d’octets dans un fichier sont importantes.

Pour la reconnaissance automatique du format de fichier, le LumièreGBM (Light Gradient Boosting Machine) peut être un bon choix pour plusieurs raisons. Premièrement, il est très efficace sur des ensembles de données volumineux et diversifiés, optimisé pour un apprentissage et une prédiction rapides, et fonctionne donc bien pour l’analyse de formats de fichiers avec des distributions d’octets volumineuses ou de nombreux échantillons. Il nécessite peu de mémoire, ce qui peut être un facteur important lors de la détection et de la classification de plusieurs formats de fichiers dans un système. Il fait partie de la famille des modèles d’amplification de gradient, qui peuvent modéliser efficacement des surfaces de décision complexes et cette précision peut être critique dans la détection de formats de fichiers où la fréquence d’octets peut avoir des distributions discrètes.

La solution LightGBM est basée sur les données, et comme nous avons besoin d’une plus grande quantité de données pour construire un modèle de bonne qualité, nous avons créé un système de téléchargement quasi-automatisé pour cela dans notre exemple. Pour implémenter notre système de téléchargement automatisé, nous avons utilisé Selenium en Python pour contrôler le navigateur à l’aide d’un pilote Firefox. Cela nous a permis de rechercher des liens et des éléments HTML, puis d’effectuer des actions sur eux, comme cliquer ou saisir des données. Lors des téléchargements automatiques, nous traitions des types de fichiers tels que CSV, DOC, DOCX, XML, JPG, JSON, PDF, PNG, XLS et XLSX, mais certains fichiers, tels que MP3 ou AVI, devaient être collectés et traités manuellement. Les fichiers ont été collectés à partir de diverses sources, telles que kaggle.com pour les fichiers CSV et JSON, tandis que les images PNG et JPG ont été téléchargées depuis imgur.com. Les vidéos YouTube ont été téléchargées au format MP4 depuis btclod.com et converties en AVI à l’aide de WinFF. Pour les fichiers ZIP, la compression et le téléchargement étaient gérés par des scripts Python distincts. Les téléchargements automatisés ont été soigneusement organisés dans une structure de répertoires appropriée. Le volume de téléchargement et la qualité des données étaient contrôlés par des paramètres au sein du programme. Certaines de nos données de test ont été collectées manuellement pour garantir l’existence de différents fichiers, mais nous n’avons pas pu collecter des quantités suffisantes de chaque type de fichier. Dans de nombreux cas, les téléchargements automatiques sont donc restés la principale méthode de génération d’entrées.

Les quantités de données d’entrée obtenues étaient les suivantes :

La reconnaissance des détails du modèle de distribution de fréquence d’octet mentionné dans l’introduction constitue la base de la construction du modèle LightGBM sur les données collectées. Le traitement d’une liste complète d’octets est coûteux, donc pour déterminer l’extension du fichier, les données sont filtrées via un BFD, ce qui peut être considéré comme une sorte de « prise d’empreintes digitales partielle ». En utilisant ces données comme données d’entrée, nous sommes en mesure de déterminer le type de certains fichiers pour le modèle. Cela se fait en créant une HASH-MAP de fréquence à partir d’un tableau d’octets, où les clés sont les octets et les valeurs sont le nombre d’occurrences. Puisque les clés sont des nombres positifs (0 à 255), ce HASH-MAP peut être facilement converti en tableau, ce qui accélère le processus de normalisation. Dans ce cas, la normalisation signifie construire une distribution de probabilité à partir des valeurs de fréquence. De ce fait, la somme des fréquences normalisées donnera une valeur de 1. Cette forme normalisée sera le BFD.

Test et réglage du modèle

Le principal problème lors de la définition des extensions de fichiers était que le modèle initial, qui fonctionnait avec 256 octets, était incapable de distinguer des formats similaires tels que XML, JSON, ZIP, DOCX et XLSX. Parmi ceux-ci, le format ZIP était particulièrement déroutant car DOCX et XLSX contiennent du XML enveloppé dans un fichier ZIP. La confusion entre XML et JSON était également courante, car leur structure est très similaire. En raison de ces facteurs, la précision du modèle pour ces types de fichiers est restée faible, ce qui a rendu nécessaire l’amélioration du modèle et l’introduction de nouvelles fonctionnalités.

Pour améliorer la précision, les fonctionnalités suivantes ont été ajoutées

• Taux d’octets de 60, 62
• Taux d’octets de 123, 125
• série d’octets sharedStrings

Pour affiner le modèle, nous avons introduit plusieurs fonctionnalités spécifiques aux octets pour identifier différents types de fichiers. Par exemple, les octets 60 et 62, qui correspondent aux symboles « < » et « > », ont joué un rôle clé dans l’identification précise des fichiers XML. De même, les octets 123 et 125, qui représentent les caractères « { » et « } », ont été utiles pour identifier les fichiers JSON. Pour reconnaître les fichiers DOCX, nous avons utilisé le rapport de la séquence d’octets «

Pour la détection des fichiers XLSX, la séquence d’octets « sharedStrings » a très bien fonctionné car tous les fichiers XLSX contiennent le fichier sharedStrings.xml, qui n’est pas analysé par le format ZIP. Cependant, cette fonctionnalité a finalement été abandonnée car sa longueur la rendait trop sensible aux moindres changements. Bien que ces fonctionnalités aient amélioré l’efficacité du modèle, l’identification exacte des fichiers ZIP restait problématique et nous avons dû utiliser une autre méthode pour les identifier.

Comme nous ne savions pas exactement quelles fonctionnalités seraient nécessaires pour identifier de manière fiable les fichiers ZIP, nous avons décidé d’inclure toutes les combinaisons possibles de 2 octets dans le modèle pour augmenter la précision. Cependant, cette approche était extrêmement exigeante en termes de mémoire, de temps et de processeur, car le processus d’apprentissage devait gérer une énorme quantité de données. Pour optimiser cela, nous avons prévu d’utiliser uniquement les 500 fonctionnalités 2 octets les plus importantes, réduisant ainsi considérablement la charge sur les ressources de calcul sans compromettre l’efficacité du modèle.

Sur la base de nos analyses initiales, nous avons atteint une précision de plus de 90 % pour toutes les classes individuellement, à l’exception des fichiers XML, où nous n’avons atteint que 49 %. Cela indique que le modèle peut avoir un problème de surapprentissage. Un surajustement peut se produire lorsque le modèle utilise trop de fonctionnalités, ce qui l’oblige à prendre des décisions plus rapidement, par exemple aux extrémités des arbres de décision. Cela peut entraîner une grande précision sur l’ensemble d’apprentissage, mais une généralisation moins bonne sur des données réelles. L’un des moyens les plus efficaces de lutter contre le surapprentissage consiste à réduire le nombre de fonctionnalités utilisées.

Le modèle final contient une combinaison de trois fonctionnalités. Premièrement, 256 fonctionnalités sur un seul octet qui examinent la fréquence d’apparition de chaque octet. Vient ensuite une fonctionnalité supplémentaire qui mesure la proportion de symboles ‘<' et '>‘ (octets 60 et 62), particulièrement utiles pour reconnaître les fichiers XML. Enfin, le modèle comprend 42 fonctionnalités sélectionnées sur deux octets qui, sur la base d’une analyse précédente, sont les plus pertinentes pour l’identification du type de fichier. Ces fonctionnalités combinées contribuent à augmenter la précision du modèle dans l’identification des différents types de fichiers.

Une fois le modèle finalisé, les précisions suivantes ont été trouvées sur la pile de tests, ventilées par type de fichier.

Étant donné que les éléments d’une colonne dans un tableau sont du même type, la précision peut être augmentée en classant ces points de données binaires simultanément dans un ensemble, car même s’il y a un point de données mal classé dans l’ensemble, les autres points de données pousseront le moyenne vers la bonne classification.

La figure ci-dessus montre la progression de la précision pour les 3 classes de précision les plus basses (XLSX, XLS, XML) pour différentes tailles d’ensemble. Les trois classes de précision les plus basses sont choisies car elles nécessitent la taille d’ensemble la plus grande pour atteindre une précision globale de 100 %. La méthode nous permet de déterminer la taille minimale requise dans le pire des cas. On peut constater que même dans le pire des cas, la précision moyenne du modèle augmente jusqu’à près de 100 % lors de la classification de 7 fichiers à la fois.

Les mesures d’exécution de l’API pour différentes tailles d’ensemble pour le modèle ont donné les résultats suivants (la taille moyenne du fichier était de 5 Mo et les tests ont été effectués sur une machine équipée d’un processeur Intel Core i7-2600 3,4 GHz et d’une RAM de 1 333 MHz).

Les temps d’exécution suivants ont été mesurés en fonction de l’utilisation de la mémoire :

– 89,428 secondes avec une utilisation maximale de la RAM de 7,28 Go

– 56,451 secondes avec une utilisation maximale de la RAM de 4,55 Go

– 30,186 secondes avec une utilisation maximale de la RAM de 2,58 Go

Implémentation de la reconnaissance de fichiers basée sur des microservices

Le service est conteneurisé à l’aide de Docker, en s’appuyant sur les modules Python fastAPI et uvicorn. Dans le processus d’appel API, le système reçoit d’abord la demande, puis convertit les données reçues au format binaire (Base64). Les données binaires sont ensuite utilisées pour générer la valeur de distribution de fréquence d’octets (BFD) du point de données. Une fois le BFD généré, le BFD associé au point de données et un modèle de type lightGBM sont utilisés pour la classification de la détection du type de fichier. Le système enregistre les événements et gère les erreurs. Enfin, à la fin du processus, le système envoie une réponse à l’utilisateur.

L’image Docker se compose des fichiers suivants :

• log, l’emplacement de results.log.
• modèles, ce dossier contiendra les modèles stockés
• main.py, c’est le module principal, c’est ce que exécute uvicorn
• logger.py, c’est le module qui effectue la journalisation
• bfd.py, le code BFD
• model.py, le code du modèle
• fichier docker, script docker
• module_list.txt, liste des modules à télécharger pour dockerfile

La structure du dockerfile est la suivante :

Dans l’appel de service, la structure Body ne contient que deux champs « data », cet attribut est une liste d’objets JSON et « id ». Ces objets JSON ont un champ « bit » (qui est une chaîne contenant la version codée en base64 du fichier).

La réponse du point de terminaison /predict est un objet JSON qui contient un code d’état. La structure de l’objet JSON est similaire au corps de la requête. La réponse contiendra un champ « data » dont la valeur est une liste. Cette liste contient des objets JSON supplémentaires qui contiennent les champs « id » et « pred ». La valeur du champ « id » peut être soit l’identifiant attribué à l’élément soumis, soit un identifiant généré s’il n’est pas initialement spécifié pour le champ « bit ». Le champ de prédiction (« pred ») contient également un objet JSON qui contient des paires clé-valeur d’extension et de probabilité.