Ho deciso di fare la (S)recensione di un libro che mi e' capitato di leggere, per pura curiosita', dal momento che oggi come oggi nell' IT chi non produce dati non esiste, e dal momento che se lavori con aziende “grandine” hai – qualsiasi cosa tu faccia o meno – a che vedere con moli importanti di dati fantastici (e dove trovarli).
Il libro che vi consiglio di comprare solo se una guerra nucleare causasse una carenza di carta igienica e' il seguente.
Questo libro contiene tutto cio' che la scienza dei dati si propone di risolvere, presentando i problemi come se fossero cose belle, auspicabili e utili. Di fatto e' l'esaltazione del “dato cucinato”.
Per spiegarvelo ricorrero' ad un aneddoto.
Nel 2018 un certo CEO italiano chiamo' me ed altri senior (=trad: vecchi) a costruire un sistema di big data analytics, per una ragione: riceveva solo dati cucinati, ovvero i dati che secondo il libro sono quelli “giusti” perche' non “discriminano”.
Lui riceveva ogni tot tempo dei dati sotto forma di presentazioni. Essendo il CEO di una holding che poi possedeva ~40 telco locali, aveva un problema: ogni telco funzionava BENISSIMO. A dire della presentazione. Tutti erano stupendi, facevano tutto di piu' e meglio, e con meno soldi. I clienti aumentavano ed erano sempre piu' soddisfatti.
Il problema stava nel fatto che i report finanziari dicevano l'opposto. L'azienda si sfondava di spese inutili e progetti falliti e andava sempre peggio.
Cosi' il CEO (in persona!) ci chiese una cosa: di prelevare OGNI dato da OGNI dispositivo di proprieta' dell'azienda, metterlo in un grosso Hadoop , e poi fare in modo che lui ricevesse i dati “As a Service”, cioe' quando aveva bisogno di sapere qualcosa, avrebbe chiesto ad un suo assistente personale di scrivergli su un bel server Tableau tutta la matematica del caso, per avere i grafici o le tabelle e i numeri che voleva.
Prima invece, ogni caposquadra (o “manager”) faceva un report in excel. Che poi veniva tradotto in powerpoint e “presentato” al superiore. Che poi aggregava tutto, faceva il powerpoint e presentava al superiore. E dopo sei o sette di queste aggregazioni, l'azienda era stupenda.
Questo perche', per non “annoiare” il superiore coi decimali, si toglievano, con arrotondamenti bizzarri. Si combinavano i dati in maniera inspiegabile. Cioe' si cucinavano. Una terminologia gergale dell'ambiente IT quando si parla di dati, e' appunto “cooked”. Cucinati. Sono i dati che piacciono all'autrice del libercolo cui sopra.
Come potete capire, anche per un gruppo di 40 persone l'inizio fu un incubo. Quando abbiamo chiesto alle persone di contatto , nelle telco nazionali, che dati avessero e dove li tenessero,l' effetto fu desolante. Finimmo con l'entrare su OGNI server in ssh, controllare i file aperti in scrittura per capire che log venissero scritti, e poi verificare sui singoli sistemi che database ci fossero e che schemi ci fossero. Tre mesi per capire che dati fossero, e come gestirli secondo la documentazione di “Privacy by design”. Io dovevo farla, e fu un incubo.
Quindi: si fa presto a dire “dati”. Di questo non troverete traccia sul libro, perche' evidentamente la tizia che scrive non ha mai LAVORATO nel settore (e' una giornalista e “docente a contratto”). Comunque, la selezione dei dati , ovvero di cosa sia un “dato”, e' cruciale. Nel senso che la risposta e' “TUTTI”. Se un dato esiste, allora e' un dato. Fine.
Perche' questo? Perche' se ci scordiamo di contarlo ci scordiamo di proteggerlo e se ci scordiamo di proteggerlo il data breach finira' sui giornali e pagheremo una multa sino al 4% del fatturato.Lo dice la legge, che proviene anche dal GDPR. Quindi la risposta alla giornalista e' chiara: quali dati sono un dato? Tutti. MA lei non lavora nel campo, le PARLA del campo.
Comunque avuti i dati, classificati, deciso quali aggregare e queli tenere raw, e di conseguenza quali anonimizzare e quali pseudonimizzare , (nemmeno di questo la giornalista fa cenno nel libro, apparentemente per lei i dati sono un concetto magico che poi viene magicamente manipolato da magici “algoritmi”) , allora abbiamo cominciato a fare quello che fa il data processor, questa figura mitica prevista dal GDPR.
Per chi non e' del mestiere, un dato aggregato e' un dato che NON riporta nessuna identita' specifica, cioe' “i macellai romagnoli tradiscono le mogli il 30% delle volte”. L'alternativa e' un dato raw, o PII, che dice “Il macellaio Ivo Balboni tradisce la moglie con la fornaia di fronte, in via Scappavia”, che invece consente di identificare sia Ivo che la fornaia.
Comunque (non so se oggi sia ancora considerato Big Data), tiravamo su circa 16/17 PB al giorno. Diciamo “abbastanzina”.
Ma la cosa divertente era la dicotomia da quelli che pensano come la giornalista e i tecnici che hanno in mente la realta' misurabile, che guarda caso e' l'unica realta', perche' se una realta' non e' misurabile va archiviata al capitolo “La Fatina dei Denti”.
Quindi abbiamo uno scontro politico tra due filosofie. I tennici, che il CEO paga perche' vuole la verita', e un approccio politico, quello dei dati “cucinati”.
Dico “politico” perche' i dati venivano cucinati ad uno scopo politico
- guarda come siamo fichi, non ci tagliare il budget
- guarda come siamo fichi, promuovici
- guarda come siamo fichi, pagaci il bonus
- guarda come siamo fichi, facci l'endorsemen nel media interno
ognuna di queste azioni e' politica, perche' assegnare budget e promuovere sono azioni puramente politiche: l'assegnazione delle risorse (il budget) e' probabilmente una delle funzioni piu' politiche di un gruppo umano.
Di conseguenza, TUTTI i gruppi che contattammo per avere la lista completa dei dati, ci chiesero una riunione IN PRESENZA (cioe' vennero in Germania di persona, sperando di evitare la Minute of Meeting o di essere registrati), con le stesse identiche domande.
- Si maaaaa…. cosa ci fate coi dati?
- Li mettiamo a disposizione del CEO, che ci fa dei KPI
- Si ma… fare i KPI cosi' e' pericoloso, perche' il CEO non sa tante cose.
- Le cose che il CEO deve sapere sono nei dati, appunto.
- Eh, no. Per esempio, il CEO ricevera' il tempo che ci mettiamo a risolvere un ticket di priorita' uno, ma nei dati non c'e' scritto l' AMMORE che ci mettiamo.
- Non credo sia un dato. E non credo sia rilevante.
- Ma non e' vero, la customer satisfaction si conquista facendo tutto con l'amore per il cliente. Noi siamo “Customer Obsessed”. MA questo non si vede nel dato.
- Non credo che la legge ci consenta di tenere dati medici sulla salute mentale nel nostro hadoop.
- Si, ma allora il CEO vede solo quanto tempo impieghiamo, ma non l' AMMORE che ci mettiamo.
- La vita e' dura. Gia'. Ma la morte e' peggio, dicono.
Io le chiamavo riunioni Catbert perche' alla fine ci toccava di fare i Catbert della situazione.
La richiesta, cioe', era di mandare i dati a loro PRIMA , cosi' loro vedevano cosa stavamo dicendo al CEO di nascosto (secondo loro. In realta' i dati erano anche a loro disposizione, se facevano richiesta), ma secondo loro di nascosto. Cioe' il CEO gli stava rubando qualcosa, accedendo direttamente a dati che erano “loro”.
Insomma, avevamo DUE mentalita':
- quella di noi tecnici, per i quali un dato e' la trascrizione di un evento realmente accaduto, o almeno del fatto che l'evento sia realmente accaduto.
- quella dei politici, per il quale il dato esiste se e solo se la sua divulgazione sostiene una data tesi politica ovvero “il mio team merita soldi”.
Quando voi fate questo in un gruppo politico (OGNI gruppo umano e' politico per forza di cose) , non ne risulta solo”panico”. Ne risulta il tentativo di annacquare o di modificare i dati stessi, oppure di cercare una lettura “politica” che li “giustificasse”.
Per esempio, una di queste telco locali diceva di avere 9 milioni di utenti , ma erano in realta' sette, le altre erano SIM mai entrate in rete. Siccome questi non si lamentavano, erano tutti clienti soddisfatti. Tolti quei due milioni di sim mai entrate in rete, le cose cambiavano molto e i clienti non erano cosi' contenti.
Idem per alcuni sistemi, di cui uno che ricordo perche' di fatto gli unici utenti erano i tester. Per assicurarsi che il sistema funzionasse bene, il manager furbacchione aveva assunto un'azienda che faceva monitoraggio esterno (e fin qui bene) simulando degli utenti reali. Ne simulava tantissimi per controllare anche la reazione sotto stress, anche il comportamento a seconda della zona geografica di provenienza, eccetera. E poi non li cancellava mai.Cosicche' il sistema aveva un sacco di utenti, in numero crescente. Se toglievamo quelli di test, rimanevano solo dipendenti dell'azienda, che erano stati invitati ad usarlo. Wow.
Emersero anche diverse situazioni al confine. Telco locale di nazione A e telco locale di nazione B, e A sosteneva di avere una customer satisfaction migliore di B. Peccato che al confine tra A e B c'erano tantissime sim di B parcheggiate la notte, ovvero persone che vivevano in nazione A ma compravano le sim di nazione B.
Il dato cucinato, cioe', era mendace. Ed era mendace perche' era fatto per influenzare decisioni politiche (interne all'azienda, ma sempre politiche). Del resto l'azienda aveva piu' dipendenti che cittadini a San Marino , quindi per negare la politicita' delle decisioni interne dovremmo negare che a San Marino ci sia politica.
Spoiler: c'e'.
Il libro della Columbro e' semplicemente l'esaltazione del dato cucinato, e una spiegazione pseudotecnica con esempi triti e ritriti ,
Dentro l'azienda, il dato veniva cucinato per soddisfare la tesi politica “il mio gruppo merita piu' budget e piu' promozioni”, mentre nel libro della Columbro il dato andrebbe “cucinato” perche' “non discrimini”, cioe' soddisfi la tesi politica del “i numeri del gruppo X non sono diversi da quelli del gruppo Y, qualsiasi siano X e Y, ma a in particolare X, che Y ci fa schifo”.
Il problema dei dati cucinati e' che i dati non sono vivi da soli. Possono essere combinati. Nel caso di cui vi ho parlato, mi e' capitato di vedere il numero anti-fisico di “latenza negativa”, perche' qualcuno si era creato una sua tabella di dati cucinati (usando un proxy con un timeout) per dimostrare che il suo sistema era velocissimo.
Il problema e' che il dato poi venne riutilizzato, e ne risulto' una latenza negativa. Fu necessario lavorare un paio di settimane per scoprire che ci avevano messo un cache proxy di mezzo, con un bel timeout.
Lo scopo era quello di dire “ma i miei numeri, che vengono sempre dallo stesso Big Data, dicono una cosa diversa”. E' una tecnica di inquinamento dei dati di analytics, crearsi i propri dati e poi dire che la tua elaborazione e' sbagliata.
Il guaio di questo e' che, appunto, ha degli effetti collaterali. Per esempio, creare sistemi “sciamanici” che sono a conoscenza della response due secondi prima della request, semplicemente perche' qualcuno ha preso un dato cucinato (=senza i log del proxy di mezzo) e ha deciso di farsi i suoi numeri.
Allo stesso modo, posso prendere i dati cucinati in termini sociali, secondo l'ideologia della Columbro, e fare un esempio.
Allora, abbiamo che negli USA le prigioni sono piene di persone di colore. Si tratta del 17% della popolazione, pero' in carcere la percentuale e' doppia. Secondo la Columbro questo dato discrimina, perche' e' contro i necri. Quindi dovremmo cucinarlo tenendo conto di N cose che non sono davvero misurabili nel caso specifico, e dire che no, i Necri che sono davvero in prigione sono sempre il 17%.
Cosi' abbiamo soddisfatto il principio politico. Bene. Il guaio e' che prima o poi qualcuno che deve fare il budget per le carceri e il budget per i servizi sociali potrebbe decidere di servirsi del dato cucinato. Se chiedete a qualcuno di definire il budget per i necri nelle carceri, chiedera' subito “ma quanti sono”?
Il guaio e' che otterra' una cifra ottimistica, che salva la faccia ai necri, per poi lasciarli senza budget per i servizi sociali.
Morale: cucinare i dati e' pericoloso, perche' non sai mai dove finiscono, e non puoi essere coerente con tutti. L'unica cosa “coerente con tutti” e' la realta' degli eventi, E QUINDI , la maniera migliore di fare e' di non cucinarli.
Con questo non voglio dire che non ci siano scienziati e anche tecnici prezzolati che cucinano i dati: chi ha messo un proxy con un timeout per falsificare le performance del sistema ERA un tecnico. Ma non aveva capito che i dati possono venire riutilizzati in un contesto dove il significato attribuito, il bias, e' esattamente opposto. Oppure , in contesti nei quali la correzione produce disastri matematici, come latenze negative o divisioni per zero.
La strategia delle persone come la Columbro, invece, e' quella di dimostrare che esistano dati buoni e dati cattivi, ovvero che tutti i dati sono sbagliati, e solo se li corregge una persona della parte politica GIUSTA e per i motivi GIUSTI, allora i dati vanno bene.
In pratica si tratta di un campo che pratica l'estetica trascendentale: loro enunciano una tesi che piace perche' e' esteticamente bella. A quel punto arrivano i dati e smentiscono la tesi.
La cultura scientifica vorrebbe che se i dati non confermano la teoria, allora la teoria sia sbagliata. Ma la teoria gli piace. Cosi' , di fronte alla discrepanza tra dati e teoria, anziche' correggere la teoria si propongono di correggere i dati.
E lo presentano , aggiungendo supercazzole prematurate, come un'operazione scientifica.
Ed e' per questo che vi sconsiglio di comprare il libro in questione:
- non c'e' scienza.
- non c'e' matematica.
- ci sono tantissimi termini usati a sproposito, a partire da “algoritmo”, sistemati a casaccio per far credere che ci siano scienza e matematica
- non insegna nulla su come vadano trattati i dati
- la Columbro di fatto mostra di NON sapere cosa sia un “dato”.
Compratelo solo se nel raggio di 200 Km non si trova carta igienica.
Ha anche dei “pro”: vi fa capire come fanno i giornalisti a cagare , con la pretesa di fare “statistiche”, le cazzate che si leggono sui giornali.
Uriel Fanelli
Il blog e' visibile dal Fediverso facendo il follow a:
Contatti:
- Fediverse: @[email protected]
- MATRIX: @uriel:mtrx.keinpfusch.net
- GNU JAMI: ufanelli
