Il fallimento dei Big Data

Ciao a tutti, raccolgo qui alcuni spunti di riflessione maturati durante la mia esperienza lavorativa (e di miei colleghi) su questo tema in una finestra di ca. 2 anni (2015-2017):

  • Struttura e Organizzazione: se il concetto di Big Data è visto come una mera evoluzione dell’Enterprise DataWarehouse (ovvero un insieme di dati strutturati e non strutturati), piuttosto che un sistema flessibile che “lavori” e fornisca in modalità “smart” e “veloce” informazioni utili al Management, ad esempio attraverso una struttura centralizzata, questo è un caso tipico di “fallimento”. Molte volte alla fine non esistono dati non strutturati perché vengono sempre applicate regole “vincolanti”. In generale l’approccio ai progetti Big Data dovrebbe avere una  filosofia “Agile”.
  • Data Acquisition e Data Ingestion: queste importanti strutture sono anche loro la chiave del successo dei Big Data, ma a volte però risultano “poco” flessibili e reattive, solitamante perchè considerate una “commodity” e quindi delocalizzata, con il solo obiettivo di ridurre i costi
  • Model Development (Data Science – DS):  l’Algoritmo applicato a volte risulta troppo complesso e strutturato per poter essere verificato in termini di qualità del modello stesso. A volte è necessario introdurre semplificazioni, filtri e aggiustamenti manuali. Il lavoro principale dei DS avviene – ad es. – tramite R o Python, in quanto più flessibile e di immediata verifica. Il DS sta diventando sempre più meno utile in quanto i principali modelli che servivano in tutte le industry oramai sono stati più che sviluppati e messi a regime, il suo ruolo non è più necessario come ad es. 2 anni fa e possono essere facilmente sostituibili utilizzando software ad hoc che producono modelli predittivi (magari con qualche punto di affidabilità minore, ma accettabile economicamente)
  • Data Preparation: preparazione dei dati per l’industrializzzione (es. SPARK), anche qui troviamo gli stessi problemi di Data Acquisition e Data Ingestion, solamente che di solito non è delocalizzato
  • Data Quality: Big Data presuppone una qualità relativamante minore con l’aumento della mole dati da gestire. Ma comunque deve essere una fase di processo da implementare fion da subito e non lasciato, come spesso succede, ad implementazioni successive
  • Industializzazione del Processo (Spark): il framework di SPARK (es. Hadoop) non risponde sempre in termini di performance e risultato a quello che riescono a fare i DS, pertanto il modello non è esattamente replicabile al 100% a causa principalmante delle differenze tra i limiti tecnici dei diversi strumenti utilizzati. In più un framework utilizza risorse (cluster, CPU, RAM, etc..) non sempre ottimizzate perfettamante, se non dopo un periodo significativo di lavoro in produzione a carico completo (es. tutto lo storico disponibile)
  • Fruizione dei risultati: l’output dei modelli non sempre è di facile produzione ed interpretazione, a volte il risultato ottenuto viene spesso confutato da altri modelli stand-alone utilizzati in “proprio”
  • Costo Elevato di Progetto e relativo ROI: attenzione ai costi Progettuali, di mantenimento e al relativo ROI

Ma quindi come poter affrontare ed indirizzare i punti fin qui esposti ?

  1. Riorganizzazione della struttura di Analytics e relativa gestione IT, la quale deve essere composta da risorse con mentalità “smart” & “agile”, che devono saper dialogare e sfruttare appieno le potenzialità delle tecnologie Big Data (Volume, Variety, Velocity, Veracity), senza portarsi dietro regole “tradizionali” del passato (es. normalizzazione spinta delle base dati)
  2. Team di Data Science dovrebbe essere composto da persone con skills di statistica avanzata ed anche di skill del relativo settore di apparteneza (es. Retail, GDO, Banking), per avere una visione più vicina a quella del Business e soddisfare meglio le relative necessità, concentrandosi su KPI significativi del settore in questione
  3. Team di Data acquisition e Data ingestion “agili”, in quanto i progetti “data driven” necessitano di team flessibili, proattivi e reattivi, non necessariamente delocalizzati o considerati delle commodity
  4. Modelli statistici (Machine Learning – Algoritmi) più semplici e comprensibili ai bisogni del Business, semplici da manutenere e meno costosi da implementare (più adatti all’approccio “agile”)
  5. Definizione di un framework di data quality condiviso all’inizio del progetto (la qualità dei risultati dipende anche dalla qualità del dato in input)
  6. Approccio al Progetto differente tramite: (1) Analisi delle best practices di settore e scouting prima del kick-off del progetto per capire le altre Aziende, gli altri Settori che cosa fanno e in che modo, (2) pianificazione di massima più veritiera senza vincolarsi a sprint standard di 6 settimane quando la realtà tecnologica richiede di per se tempi macchina lunghi
  7. Confrontare i risultati del modello industrializzato con eventuali altri modelli Stad Alone già esistenti
  8. Partnership tecnologica con società fornitrici di HW e SW, in quanto l’utilizzo di SW complesso necessita di supporto ad-hoc per non bloccare i lavori ed evitare workaround perniciosi. Es. CLOUDERA, SPARK, R ENTERPRISE, ovvero contare sempre sull’ultima versione disponibile ed avere supporto diretto dai Vendor anche in modalità SaaS
  9. Industrializzazione più flessibile direttamente in linguaggio statistico R tramite R suite (es. R ENTERPRISE), che consentirebbe più flessibilità e velocità nei relativi sviluppi

Grazie a tutti per l’attenzione

2 Replies to “Il fallimento dei Big Data”

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *