Big Data, la conservazione è un problema: ecco perché

La conservazione sostitutiva dei Big Data rappresenta in concreto un problema a causa della loro natura destrutturata. Il tema della conservazione dei database è sempre stato condizionato, o inquinato, dalla difficile mediazione linguistica e tecnica tra archivistica, informatica e legislazione che spesso ha cercato di trovare il giusto equilibrio tra le varie discipline.

Nel mese di ottobre 2019 AgID ha rilasciato la bozza della “Linee guida sulla formazione, gestione e conservazione dei documenti informatici” che introduce alcune e importanti novità, anche in tema di database e big data formalizzando finalmente il linguaggio JSON e dando maggiore attenzione anche al linguaggio SQL.

Le indicazioni così fornite sicuramente consentono di gestire le banche dati tradizionali, cioè quelle relazionali come MySQL o Postgresql, ma lasciano ancora diverse questioni aperte rispetto alla conservazione di dati gestiti secondo logiche diverse e soprattutto obiettivi diversi.

Big Data, il problema della conservazione

Il nodo è nel fatto che non abbiamo un documento informatico, ma abbiamo dati grezzi, destrutturati utili per scopi non definiti a priori e non programmabili. Si potrebbe anche dire, ma poi negheremo di averlo scritto, che questo tipo di dati non avrebbero neanche la necessità di essere conservati secondo il modello OAIS o le specifiche di conservazione disposte dall’AgID. Ma questo tipo di dati possono essere presenti nella Pubblica Amministrazione, pensiamo per esempio ai dati sanitari, oppure possono essere di varia natura, non sempre digitali, come progetti di sistemi previsionali dove la banca dati viene costruita digitalizzando le minute tecniche di manutenzione redatte quando non esistevano i computer.

I Big Data inoltre possono essere utilizzati per più analisi o ricerche, la loro esigenza non è di essere strutturati, perché altrimenti verrebbe definito a priori l’informazione che essi potrebbero produrre. Un database relazionale è costruito su una analisi e progetto logico che risponde ad esigenze di business^[1]: il database degli studenti di una scuola, la tabella utenti di un sistema informatico. Ma i Big Data possono produrre conoscenza perché vengono analizzati per cercare informazioni. Per esempio, cercare di prevenire le tendenze dell’influenza nel progetto di Google Flu Trends^[2], oppure per pianificare la manutenzione dei tombini di New York^[3] cercando di trovare correlazioni tra alcuni fattori che sono presenti quando si possono rompere, ma non esserne la causa.

Dati senza struttura logica

Il dato quindi in questo contesto dovrebbe rimanere sempre non strutturato. Questo ha portato alla nascita di modelli di dati che non sono supportati dal linguaggio SQL e che non lo supportano. Anzi si possono identificare diverse soluzioni per le quali non esiste un linguaggio comune, ma che non esclude di usare linguaggi^[4] diversi dall’XML per cercare di costruire modelli di conservazione efficaci. Su questo presupposto la menzione di JSON nell’allegato 2 “Formati di file e riversamento” è molto positivo, ma non tiene conto che il mercato dei database NoSQL, cioè il mondo di quel modello di dati che è più idoneo a gestire i Big Data, non è ancora ben rappresentato nel disegno del legislatore italiano.

Se leggiamo quanto indicato nelle Linee Guida, possiamo con certezza affermare che i Big Data non sono e non potranno costituire un documento informatico:

• “memorizzazione su supporto informatico in formato digitale delle informazioni risultanti da transazioni o processi informatici o dalla presentazione telematica di dati attraverso moduli o formulari resi disponibili all’utente;
• generazione o raggruppamento anche in via automatica di un insieme di dati o registrazioni, provenienti da una o più banche dati, anche appartenenti a più soggetti interoperanti, secondo una struttura logica predeterminata e memorizzata in forma statica”.

La mancanza di una soluzione

I Big Data non sono strutturati logicamente, quindi non li conserviamo? La risposta non può essere negativa e per ora non ha neanche una soluzione. Quando parliamo di assenza di una soluzione, dobbiamo anche sottolineare che la risposta del mercato alle esigenze di gestire questa tipologia di dati è stata molto ricca e articolata. Con la conseguenza di non poter fornire una base uniforme su cui costruire una risposta alla domanda. Il presupposto indicato dal legislatore sia per un file “.sql” o JSON è: “Il documento è adatto alla conservazione solo se eventuali riferimenti a documenti esterni implica che tali documenti sono anch’essi contenuti nel pacchetto di conservazione”.

Come si può notare la frase inizia con un problema, si parla ancora di documento, mentre come abbiamo visto il formato dei big data non deve essere strutturato, inoltre dato ancora più allarmante l’Allegato 4 delle Linee Guida richiama giustamente lo standard SIARD, il quale però ha il limite di occuparsi solo dei database relazionali^[5]. Il modello proposto, seppur corretto nel contesto, non aiuta ad affrontare la conservazione di questa grande mole di dati destrutturati. Pensiamo, per esempio, a Hadoop e al formato dei file Sequence oppure Avro, quest’ultimo inoltre in grado di salvare i dati insieme ai metadati con schemi anche indipendenti superando alcuni limiti di XML e di JSON. A questo punto possiamo fare alcune riflessioni per un tentativo di creare un framework operativo:

• il contesto: non possiamo che tenere conto di cosa stiamo mandando in conservazione e il perché lo vogliamo fare;
• la conservazione: conservare dati destrutturati risponde ad alcune esigenze fondamentali a cui l’archivistica propone soluzioni utili^[6]. Per esempio, è innegabile che dati conservati garantendo autenticità, integrità, accessibilità e intelligibilità siano più attendibili di dati non conservati in modo appropriato;
• lo scarto: probabilmente non si possono scartare i big data, e non per un motivo di coerenza delle relazioni tra i dati, ma perché anche il dato più antico può essere una leva per generare conoscenza
• il formato dei pacchetti di conservazione: le soluzioni come quelle del SIARD sono estremamente efficienti in contesti dove le relazioni sono predefinite ed è fondamentale conservarne la loro integrità. Se per esempio viene corrotto la matrice delle autorizzazioni di un sistema gestionale, si rischia di avere dati non conservati correttamente. Alcuni NoSQL come anche altri sistemi ci vengono incontro con i loro formati molto più efficienti dell’XML, parlo di JSON e di Avro. In questo caso si potrebbe pensare a esportazioni di dati in base alle specifiche del software originale, senza conversioni o riversamenti.
• l’accesso ai dati: non dimentichiamo che il modello OAIS ha diversi elementi che lo costituiscono, tra i quali l’accesso e la comunità di riferimento. Nel primo caso bisognerà sicuramente inserire la documentazione per leggere correttamente il linguaggio originario, per citarne alcuni, di Hadoop o MongoDB; nel secondo caso chiedersi se la comunità di riferimento ha ancora bisogno, ritorna quindi il concetto di utilità, di quei dati;
• la comunità di riferimento: questo istituto poco sviluppato in Italia, se non in alcune oasi di qualità come i poli archivistici regionali o alcuni conservatori particolarmente evoluti, sarebbe fondamentale per collegarci al primo punto, cioè al contesto. Per esempio, pensando a strategie di formazione, aumentando le competenze dei membri della comunità, creando strumenti di gestione della conoscenza che abbiano bisogno dei dati conservati per generare conoscenza.

Conclusione

Sulla base di queste prime riflessioni si può che dire la strada è tortuosa perché la Pubblica Amministrazione, cioè il primo cliente della normativa sulla conservazione, non è ancora pronta per usare in modo strutturato ed efficace i Big Data, anche se esistono casi interessanti soprattutto nel settore sanitario e vi è ancora una tardiva applicazione dell’art.71 del Codice dell’amministrazione digitale che quando sarà usato a piene mani e coordinato con le dinamiche del mercato informatico, potrà essere lo strumento per cogliere le occasioni che si stanno ormai concretizzando dalla blockchain all’IOT.

_

Note

1. Si tratta di una semplificazione, ma necessaria per definire meglio i campi di applicazione e di intervento. ↑
2. Il progetto lanciato nel 2008 e poi fallito quando sono emerse altre occorrenze che condizionavano l’algoritmo. Per esempio, se digito “aspirina”, non necessariamente la sto cercando perché ho l’influenza. Ma i fattori che incisero sono diversi. ↑
3. Si tratta di un progetto lanciato dalla città di New York nel 2007in collaborazione con la Columbia University. Furono identificati circa 106 fattori. I tombini nella città di Batman sono oltre 50.000. ↑
4. Un sintetico elenco, probabilmente non esaustivo, prevede: Hadoop Framework (HDFS, MapReduce, Hive, Hbase, Spark, Tez, Storm, Mahout, etc.); NoSQL, R e Python. ↑
5. Il SIARD afferma che “A relational database is treated as a single document to be archived, so that the references between the data in individual tables are preserved.” ↑
6. “utile” non viene usato a caso. Spesso ci dimentichiamo che ciò che proponiamo, su cui ragioniamo, deve avere una utilità nelle organizzazioni, private o pubbliche; altrimenti rimanendo nell’alveo della teoria fanno fatica ad essere adottate perché non rispondo ai contesti operativi e alle difficoltà che ogni organizzazione deve affrontare. ↑