I database da migrare possono avere un’ampia gamma di rappresentazioni e contenuti dei dati. Dai semplici campi dati numerici ai campi con struttura e contenuto complessi, che possono contenere file, immagini, tabelle o anche oggetti personalizzati complessi (ad esempio nei formati XML, CLOB, BLOB ecc.).

La scoperta di dati più semplici può essere effettuata in modo semplice e molto efficiente utilizzando metodi tradizionali con alcune conoscenze e valori di base. Tuttavia, man mano che i dati diventano più complessi, questa efficienza diminuisce fino a quando i metodi tradizionali non sono più sufficienti.

Tali dati più complessi possono essere, ad esempio, testo non strutturato o file binari il cui tipo e contenuto non possono essere chiaramente identificati e interpretati. Per amor di discussione, trascuriamo il fatto che l’uso di tali tipi di dati nei database è giustificato solo in alcuni casi specifici, poiché questo problema si presenta spesso durante la migrazione di sistemi complessi. Questi formati di dati complessi sono solitamente non strutturati, strutturalmente solo un insieme di byte in un dato campo, sul quale l’utente spesso non dispone di informazioni affidabili a causa della documentazione incompleta. Senza metainformazioni è difficile trarre conclusioni sul tipo di contenuto e sulla sua interpretazione. Quindi il nostro primo compito è decidere riguardo a questi campi che tipo di dati contengono.

Il modo più ovvio per identificare i tipi di file sarebbe controllarne l’estensione, ma quando archiviate in un database, queste informazioni in genere non sono disponibili o, anche se lo fossero, non potrebbero essere utilizzate con la massima sicurezza. Supponendo che sia disponibile solo la versione binaria dei dati, ovvero Binary Large Object (BLOB), il primo passo è caricarla. Tutti i metadati sono codificati in questo BLOB, in base al formato del file.

A seconda del formato del file o del tipo di dati, i metadati nel file potrebbero essere visualizzati in diversi punti del file, nell’intestazione o alla fine del file. Oltre a identificare il formato del file, le intestazioni dei file possono anche contenere metadati sul file e sui suoi contenuti. I file basati su caratteri (testo) di solito hanno intestazioni basate su caratteri, mentre i formati binari di solito hanno intestazioni binarie, sebbene questo non sia uno standard, ma solo una pratica industriale.

La distribuzione dei valori dei byte in diversi tipi di file mostra un modello diverso per ciascun tipo. I primi tentativi si concentravano sulla distribuzione dei byte dell’intero file, ma i metodi più recenti eseguono campionamenti diversi, come l’analisi solo dei campioni dall’inizio, dalla fine e dalla parte centrale del file. Questi campioni possono fornire una buona base per apprendimento automaticoche può determinare (con una certa probabilità) il tipo di file sconosciuti utilizzando un modello costruito sulle diverse distribuzioni. In una procedura basata su BFD (Byte Frequency Distribution), non è necessario leggere l’intero file, il che fa risparmiare tempo. I valori estratti da diverse posizioni del file vengono analizzati statisticamente per ottenere un’impronta digitale specifica del file. Sulla base di questa impronta digitale, l’apprendimento automatico è in grado di trovare il tipo di file nel modello – quello che gli abbiamo insegnato con i file conosciuti – che meglio si adatta.

La figura seguente mostra la distribuzione dei byte di alcuni tipi di file:

Tieni presente che tutti i codici e gli esempi di dati di input/output in questo articolo derivano da Clarity Consulting Mignon attrezzo. Questo software di assistenza alla migrazione dei dati è il risultato di un progetto pluriennale di ricerca e sviluppo, parzialmente finanziato dall’Unione Europea.

Applicazione dell’apprendimento automatico al riconoscimento del formato dei file

L’apprendimento automatico può essere un metodo efficace per il riconoscimento del formato dei file, soprattutto quando si lavora con set di dati di grandi dimensioni. I seguenti modelli possono essere presi in considerazione per il rilevamento del formato file:

• L’ingenuo Bayes: Adatto per analisi basate su byte o sequenze, in cui vengono prese in considerazione le caratteristiche tipiche di ciascun formato di file, come distribuzioni di byte o modelli caratteristici.
• Supporta macchine vettoriali (SVM): Una buona scelta quando i confini tra i formati di file, ovvero le superfici decisionali, devono essere definiti sulla base della frequenza dei byte.
• Foresta casuale: Tra i metodi di apprendimento d’insieme, viene spesso utilizzato Random Forest perché può gestire molti formati di file diversi e può far fronte a dati rumorosi.
• Reti neurali convoluzionali (CNN): Le CNN sono in grado di riconoscere modelli di distribuzione dei byte e possono trattare i file come immagini in cui la frequenza dei byte viene interpretata come “pixel”, riconoscendo così diversi formati di file.
• Codificatore automatico: può essere utilizzato per l’apprendimento non supervisionato, in particolare per il rilevamento di anomalie, quando si tenta di rilevare file con uno schema di byte diverso da quello abituale per un dato formato di file.
• K-Vicini più vicini (KNN): Per set di dati di piccole dimensioni, questo può essere un modo semplice ma efficace per identificare i formati di file in base alla somiglianza dei file vicini più prossimi.
• Reti neurali ricorrenti (RNN): Poiché gli RNN gestiscono in modo efficiente dati sequenziali, possono essere utili per attività in cui le sequenze di byte in un file sono importanti.

Per il riconoscimento automatico del formato file, il file LightGBM (Light Gradient Boosting Machine) può essere una buona scelta per diversi motivi. Innanzitutto, è altamente efficiente su set di dati grandi e diversificati, ottimizzato per l’apprendimento e la previsione rapidi e quindi funziona bene per l’analisi dei formati di file con distribuzioni di byte di grandi dimensioni o molti campioni. Richiede poca memoria, il che può essere una considerazione importante quando si rilevano e classificano più formati di file in un sistema. È un membro della famiglia di modelli di potenziamento del gradiente, che può modellare in modo efficiente superfici decisionali complesse e questa precisione può essere fondamentale nel rilevamento del formato file in cui la frequenza dei byte può avere distribuzioni discrete.

La soluzione LightGBM è basata sui dati e poiché abbiamo bisogno di una maggiore quantità di dati per creare un modello della giusta qualità, nel nostro esempio abbiamo creato per questo un sistema di download quasi automatizzato. Per implementare il nostro sistema di download automatizzato, abbiamo utilizzato Selenium in Python per controllare il browser utilizzando un driver Firefox. Ciò ci ha permesso di cercare collegamenti ed elementi HTML e quindi eseguire azioni su di essi, come fare clic o inserire dati. Durante i download automatici, gestivamo tipi di file come CSV, DOC, DOCX, XML, JPG, JSON, PDF, PNG, XLS e XLSX, ma alcuni file, come MP3 o AVI, dovevano essere raccolti ed elaborati manualmente. I file sono stati raccolti da varie fonti, come kaggle.com per i file CSV e JSON, mentre le immagini PNG e JPG sono state scaricate da imgur.com. I video di YouTube sono stati scaricati in formato MP4 da btclod.com e convertiti in AVI utilizzando WinFF. Per i file ZIP, la compressione e il download venivano gestiti da script Python separati. I download automatizzati sono stati attentamente organizzati in una struttura di directory appropriata. Il volume di download e la qualità dei dati erano controllati da parametri all’interno del programma. Alcuni dei nostri dati di test sono stati raccolti manualmente per garantire che esistessero file diversi, ma non siamo stati in grado di raccogliere quantità sufficienti di tutti i tipi di file, quindi in molti casi i download automatici sono rimasti il ​​metodo principale per generare input.

Le quantità di dati di input ottenute sono state le seguenti:

Riconoscere i dettagli del modello di distribuzione della frequenza dei byte menzionato nell’introduzione è la base per costruire il modello LightGBM sui dati raccolti. L’elaborazione di un elenco completo di byte è costosa, quindi per determinare l’estensione del file, i dati vengono filtrati tramite un BFD, che può essere visto come una sorta di “impronta digitale parziale”. Usandoli come dati di input, siamo in grado di determinare il tipo di alcuni file per il modello. Questo viene fatto creando una HASH-MAP di frequenza da un array di byte, dove le chiavi sono i byte e i valori sono il numero di occorrenze. Poiché le chiavi sono numeri positivi (da 0 a 255), questa HASH-MAP può essere facilmente convertita in un array, accelerando il processo di normalizzazione. Normalizzare in questo caso significa costruire una distribuzione di probabilità dai valori di frequenza. Di conseguenza, la somma delle frequenze normalizzate darà un valore pari a 1. Questa forma normalizzata sarà la BFD.

Testare e mettere a punto il modello

Il problema principale nella definizione delle estensioni dei file era che il modello iniziale, che funzionava con 256 byte, non era in grado di distinguere tra formati simili come XML, JSON, ZIP, DOCX e XLSX. Di questi, il formato ZIP era particolarmente confuso perché sia ​​DOCX che XLSX contengono XML racchiuso in un file ZIP. Anche la confusione tra XML e JSON era comune, poiché sono molto simili nella struttura. A causa di questi fattori, la precisione del modello per questi tipi di file è rimasta bassa, rendendo necessario migliorare il modello e introdurre nuove funzionalità.

Per migliorare la precisione, sono state aggiunte le seguenti funzionalità

• Velocità in byte di 60, 62
• Velocità in byte di 123, 125
• Serie di byte sharedStrings

Per perfezionare il modello, abbiamo introdotto diverse funzionalità specifiche dei byte per identificare diversi tipi di file. Ad esempio, i byte 60 e 62, che corrispondono ai simboli “<" e ">“, hanno svolto un ruolo chiave nell’identificazione accurata dei file XML. Allo stesso modo, i byte 123 e 125, che rappresentano i caratteri “{” e “}”, sono stati utili per identificare i file JSON. Per riconoscere i file DOCX abbiamo utilizzato il rapporto della sequenza di byte ‘

Per il rilevamento dei file XLSX, la sequenza di byte “sharedStrings” ha funzionato molto bene perché tutti i file XLSX contengono il file sharedStrings.xml, che non viene analizzato dal formato ZIP. Tuttavia, questa caratteristica fu poi scartata perché la sua lunghezza lo rendeva troppo sensibile anche ai più piccoli cambiamenti. Sebbene queste funzionalità abbiano migliorato l’efficienza del modello, l’esatta identificazione dei file ZIP è rimasta problematica e abbiamo dovuto utilizzare un altro metodo per identificarli.

Poiché non sapevamo esattamente quali funzionalità sarebbero state necessarie per identificare in modo affidabile i file ZIP, abbiamo deciso di includere tutte le possibili combinazioni di 2 byte nel modello per aumentare la precisione. Tuttavia, questo approccio richiedeva molta memoria, tempo e processore poiché il processo di apprendimento doveva gestire un’enorme quantità di dati. Per ottimizzare questo, abbiamo pianificato di utilizzare solo le 500 funzionalità più importanti a 2 byte, riducendo così significativamente il carico sulle risorse computazionali senza compromettere l’efficienza del modello.

Sulla base delle nostre analisi iniziali, abbiamo raggiunto una precisione superiore al 90% per tutte le classi singolarmente, ad eccezione dei file XML, dove abbiamo raggiunto solo il 49%. Ciò indica che il modello potrebbe avere un problema di overfitting. L’overfitting può verificarsi quando il modello utilizza troppe funzionalità, costringendolo a prendere decisioni più velocemente, ad esempio, agli endpoint degli alberi decisionali. Ciò può comportare un’elevata precisione sul set di addestramento, ma una generalizzazione inferiore sui dati reali. Uno dei modi più efficaci per gestire il sovradattamento è ridurre il numero di funzionalità utilizzate.

Il modello finale contiene una combinazione di tre caratteristiche. Innanzitutto, 256 funzionalità a byte singolo che esaminano la frequenza di occorrenza di ciascun byte. Segue una funzionalità aggiuntiva che misura la proporzione dei simboli ‘<' e '>‘ (byte 60 e 62), particolarmente utili per riconoscere i file XML. Infine, il modello include 42 caratteristiche selezionate a due byte che, sulla base dell’analisi precedente, sono più rilevanti per l’identificazione del tipo di file. Queste funzionalità combinate aiutano ad aumentare la precisione del modello nell’identificazione di diversi tipi di file.

Dopo aver finalizzato il modello, nello stack di test sono state riscontrate le seguenti accuratezze, suddivise per tipo di file.

Poiché gli elementi di una colonna in una tabella sono dello stesso tipo, la precisione può essere aumentata classificando simultaneamente questi punti dati binari in un insieme, poiché anche se è presente un punto dati classificato erroneamente nell’insieme, gli altri punti dati spingeranno il livello media verso la classificazione corretta.

La figura sopra mostra la progressione della precisione per le 3 classi di precisione più basse (XLSX, XLS, XML) per diverse dimensioni dei set. Vengono scelte le tre classi di precisione più basse perché richiedono la dimensione del set più grande per ottenere una precisione complessiva del 100%. Il metodo ci consente di determinare la dimensione minima del set richiesta nel caso peggiore. Si può vedere che anche nel caso peggiore, la precisione media del modello aumenta fino a quasi il 100% quando si classificano 7 file alla volta.

Le misurazioni del runtime API per diverse dimensioni di set per il modello hanno prodotto i seguenti risultati (la dimensione media del file era di 5 MB e il test è stato eseguito su un computer con un processore Intel Core i7-2600 da 3,4 GHz e RAM da 1333 MHz).

Sono stati misurati i seguenti tempi di esecuzione in base all’utilizzo della memoria:

– 89.428 secondi con un utilizzo massimo di RAM di 7,28 GB

– 56.451 secondi con un utilizzo massimo di RAM di 4,55 GB

– 30.186 secondi con un utilizzo massimo di RAM di 2,58 GB

Implementazione basata su microservizi del riconoscimento dei file

Il servizio è containerizzato utilizzando Docker, basandosi sui moduli Python fastAPI e uvicorn. Nel processo di chiamata API, il sistema prima riceve la richiesta, quindi converte i dati ricevuti in formato binario (Base64). I dati binari vengono quindi utilizzati per generare il valore BFD (Byte Frequency Distribution) del punto dati. Una volta generato il BFD, il BFD associato al punto dati e un modello di tipo lightGBM vengono utilizzati per la classificazione del rilevamento del tipo di file. Il sistema registra gli eventi e gestisce eventuali errori. Infine, al termine del processo, il sistema invia una risposta all’utente.

L’immagine Docker è composta dai seguenti file:

• log, la posizione di results.log.
• models, questa cartella conterrà i modelli memorizzati
• main.py, questo è il modulo principale, questo è ciò che esegue uvicorn
• logger.py, questo è il modulo che esegue la registrazione
• bfd.py, il codice BFD
• model.py, il codice del modello
• dockerfile, script docker
• module_list.txt, elenco dei moduli da scaricare per dockerfile

La struttura del dockerfile è la seguente:

Nella chiamata al servizio la struttura Body contiene solo due campi “data”, questo attributo è un elenco di oggetti JSON e “id”. Questi oggetti JSON hanno un campo “bit” (che è una stringa contenente la versione codificata base64 del file).

La risposta dall’endpoint /predict è un oggetto JSON che contiene un codice di stato. La struttura dell’oggetto JSON è simile al corpo della richiesta. La risposta conterrà un campo “dati” il cui valore è un elenco. Questo elenco contiene oggetti JSON aggiuntivi che contengono i campi “id” e “pred”. Il valore del campo “id” può essere l’identificatore assegnato all’articolo inviato o un identificatore generato se non originariamente specificato per il campo “bit”. Il campo di previsione (“pred”) contiene anche un oggetto JSON che contiene coppie chiave-valore di estensione e probabilità.