Modernizzare i dati enterprise: Hadoop, Netezza e la svolta nelle piattaforme dati

Lo stato dell’ecosistema dati

Esaminando l’ecosistema dati di qualsiasi banca di primo livello si trovano strati di storia. Un mainframe. Un warehouse Oracle acquisito negli anni 2000. Un’appliance Netezza acquistata per far funzionare il reporting normativo. Un cluster Hadoop creato da un team di analisi. Carichi di lavoro SAS. Tableau. SQL Server. Una presenza crescente su Azure o AWS. Ogni strato era la risposta giusta al problema di qualcuno nel giorno in cui è stato acquistato.

Il compito dell’architetto dati enterprise non è sostituire tutto con un’unica splendida piattaforma. È tracciare i confini: quali carichi di lavoro appartengono a quale piattaforma, quali piattaforme sono strategiche, quali tattiche e quali a fine vita. Poi, cosa altrettanto importante, deve far rispettare quei confini — fornendo consulenza, approvando e raccomandando la scelta della piattaforma per ogni nuova iniziativa.

Hadoop come area strategica di acquisizione

Hadoop era la scelta strategica per i carichi di lavoro nuovi e non strutturati. Lo schema-on-read permetteva di acquisire dati grezzi senza concordare prima uno schema di destinazione; HDFS e il metastore Hive offrivano un’unica collocazione fisica per le join tra domini; l’ecosistema aperto (Spark, Hive, Impala, notebook a valle) dava ai singoli team di analisi la flessibilità necessaria senza creare infrastrutture su misura.

La regola architetturale che abbiamo scritto era semplice: se un nuovo carico di lavoro acquisisce dati grezzi di eventi, esegue join tra domini o serve data scientist che richiedono calcolo flessibile, la piattaforma scelta è Hadoop. Se esegue reporting normativo a livello di riga su un data mart rigorosamente modellato, resta dov’è.

Netezza come affidabile strumento tattico

Netezza non andava sostituito. Doveva smettere di accumulare carichi di lavoro per cui non era stato progettato. L’appliance resta eccellente nel proprio campo: SQL strutturato, basato su insiemi e dalla forma prevedibile, su tabelle dei fatti nell’ordine dei terabyte. Data mart normativi, reporting finanziario, aggregazione del rischio: tutti carichi adatti a Netezza, tutti rimasti.

Da Netezza abbiamo rimosso i carichi che non avrebbero dovuto trovarsi lì: analisi esplorative ad hoc su flussi di eventi grezzi, join tra domini da eseguire nell’area di acquisizione e staging ETL che usava il warehouse come tabella temporanea. Spostarli ha liberato l’appliance, consentendole di svolgere meglio il suo vero compito.

L’albero decisionale per scegliere la piattaforma

Per approvare le scelte di piattaforma delle nuove iniziative serve un albero decisionale ripetibile, non una riunione. Quello che abbiamo usato:

• Si tratta di reporting normativo su un data mart modellato? → Stack warehouse esistente (Netezza o Oracle).
• Acquisisce dati grezzi di eventi con schema flessibile? → Area di acquisizione Hadoop.
• È un carico di lavoro transazionale? → Database operativo, non l’insieme dei warehouse.
• È un’analisi esplorativa basata su notebook? → Hadoop con accesso in sola lettura ai data mart modellati tramite federazione.
• Il dataset è nuovo e il sistema che lo utilizza è nativo cloud? → Percorso verso una piattaforma dati cloud, con un flusso unidirezionale deliberato verso l’ecosistema on-premise.

Quell’albero, insieme a una verifica dell’architettura dati enterprise all’inizio di ogni iniziativa, ha impedito la proliferazione incontrollata dell’ecosistema. L’albero è più importante delle scelte tecnologiche che produce.

Governance senza burocrazia

La governance dei dati ha una cattiva reputazione perché spesso si limita a politiche senza strumenti per applicarle. La versione che funziona in una banca di primo livello è quella in cui la governance fornisce strumenti e misure di controllo insieme alle politiche: un catalogo di metadati davvero aggiornato, una classificazione dei dati applicata all’acquisizione, una tracciabilità automatica invece che curata manualmente e un percorso chiaro di escalation per le eccezioni, che esistono sempre.

Il nostro ruolo di architetto dati enterprise faceva da ponte tra il team di governance e i team di realizzazione. La governance stabiliva le regole; noi ci assicuravamo che si riflettessero sempre nella scelta della piattaforma. I progetti che lo facevano bene erano più veloci, non più lenti, perché non dovevano rifare il livello dati sei mesi dopo.

Cosa significa per la tua strategia dati

• Non cercare l’unica piattaforma perfetta. Cerca il confine giusto tra due o tre piattaforme.
• Dismetti rimuovendo carichi di lavoro, non piattaforme. La piattaforma si ridimensiona naturalmente quando smetti di assegnarle il lavoro sbagliato.
• Revisione architetturale all’inizio, non alla fine. Approvare presto la scelta della piattaforma costa dieci volte meno che ricostruire.
• Tracciabilità e classificazione all’acquisizione. Aggiungerle a posteriori è la forma più costosa di debito tecnico in un ecosistema dati.
• Il cloud è una destinazione, non una scadenza. Migra i carichi che ne traggono vantaggio; lascia gli altri dove sono.

Stai ripensando il tuo ecosistema dati?

SEYSO ha fornito consulenza sull’architettura dati enterprise a banche di primo livello: scelta delle piattaforme, eliminazione dei duplicati e governance di ecosistemi dati multipiattaforma. Se devi affrontare uno stack di warehouse proliferato, un cluster Hadoop sottoutilizzato o una migrazione dei dati al cloud da pianificare per fasi, parliamone.