Share
Mentre sempre più aziende scoprono l'importanza della scienza dei dati e dell'analisi avanzata per il loro risultato economico, è iniziato uno scontro di culture. Come possono questi campi in rapida crescita diventare parte dell'ecosistema di un'azienda, in particolare per le aziende affermate che esistono da un decennio o più?
I dati scienziati e professionisti IT hanno esigenze molto diverse quando si tratta di infrastrutture. Qui, esporrò alcuni di questi requisiti e discuterò su come andare al di là di essi e evolvere insieme.
Quando si avviano programmi di scienza dei dati all'interno delle aziende, spesso le questioni più importanti non derivano dalla tecnologia stessa, ma da semplici problemi di comunicazione. Le idee sbagliate interdipartimentali possono comportare un sacco di rancore tra i nuovi team di scienza dei dati e i dipartimenti IT.
Per combattere questo, esamineremo entrambe le prospettive e terremo conto di ciascuno dei loro bisogni. Inizieremo definendo cosa richiede un professionista IT per mantenere un flusso di lavoro di successo, quindi esamineremo ciò di cui ha bisogno uno scienziato dei dati per la massima efficienza. Infine, troveremo il terreno comune: come utilizzarlo per implementare un'infrastruttura sana per far prosperare entrambi.
Iniziamo dando un'occhiata a un'infrastruttura dati tipica per lo sviluppo IT e software.
Per quanto riguarda i dati, ci sono tre prerequisiti essenziali che qualsiasi dipartimento IT si concentrerà su:
Per questo motivo, gran parte dell'IT utilizza schemi basati su tabelle e spesso utilizza SQL (Structured Query Language) o una delle sue varianti.
Questa configurazione significa che ci sono un gran numero di tabelle per ogni scopo. Ognuna di queste tabelle è separata l'una dall'altra, con chiavi esterne che le connettono. A causa di questa configurazione, le query possono essere eseguite rapidamente, in modo efficiente e con la sicurezza in mente. Questo è importante per lo sviluppo del software, in cui i dati devono rimanere intatti e affidabili.
Con questa struttura, l'hardware richiesto è spesso minimo se confrontato con le esigenze della scienza dei dati. I dati memorizzati sono ben definiti e si evolve ad un ritmo prevedibile. Poco si ripetono i dati e il processo di interrogazione riduce la quantità di risorse di elaborazione richieste.
Vediamo come differisce la scienza dei dati.
Dall'altro lato, la scienza dei dati ha un diverso insieme di esigenze. Gli scienziati dei dati hanno bisogno della libertà di movimento con i loro dati e della flessibilità per modificare rapidamente i loro dati. Devono essere in grado di spostare i dati in modi non standard e elaborare grandi quantità alla volta.
Queste esigenze sono difficili da implementare utilizzando database altamente strutturati. La scienza dei dati richiede un'infrastruttura diversa, basandosi invece su dati non strutturati e schemi senza tabella.
Quando ci si riferisce a dati non strutturati, stiamo parlando di dati senza definizione intrinseca. È nebuloso fino alla forma data da uno scienziato dei dati. Per la maggior parte dello sviluppo, ogni campo deve essere di un tipo definito, ad esempio un numero intero o una stringa. Per la scienza dei dati, tuttavia, si tratta di supportare punti dati mal definiti.
Gli schemi senza tabella aggiungono più versatilità a questa configurazione quasi caotica, consentendo a tutte le informazioni di vivere in un unico posto. È particolarmente utile per gli scienziati di dati che hanno regolarmente bisogno di unire i dati in modi creativi e non strutturati. Le scelte più comuni includono varianti o strutture NoSQL che consentono diverse dimensioni, come i cubi OLAP.
Di conseguenza, l'hardware richiesto per la data science è spesso più consistente. Dovrà contenere la totalità dei dati utilizzati, nonché i sottoinsiemi di tali dati (sebbene questo sia spesso distribuito tra più strutture o servizi). L'hardware può anche richiedere notevoli risorse di elaborazione in quanto grandi quantità di dati vengono spostate e aggregate.
Tenendo presenti questi due gruppi di esigenze, ora possiamo vedere come possono verificarsi problemi di comunicazione. Prendiamo queste prospettive e usiamole per definire quali cambiamenti stiamo cercando e come. Quali problemi devono essere risolti quando si porta la scienza dei dati in un'impostazione IT tradizionale?
In un'impostazione IT tradizionale, i database di un dato business probabilmente seguono una struttura rigida, con tabelle divise per soddisfare esigenze specifiche, uno schema appropriato per definire ogni pezzo di dati e chiavi esterne per legarlo insieme. Questo rende un sistema efficiente di interrogare i dati. La natura esplorativa di alcuni metodi di data science può spingere al limite.
Quando un'attività comune potrebbe richiedere l'unione di una dozzina o più tabelle, i vantaggi delle strutture basate su tabelle diventano meno evidenti. Un metodo popolare per gestire questo è implementare un database NoSQL o multi-dimensionale secondario. Questo database secondario utilizza ETL regolari (Estrai, Trasforma, Carica) per mantenere le sue informazioni fresche. Questo aggiunge il costo dell'hardware aggiuntivo o dell'utilizzo del servizio cloud, ma minimizza ogni altro inconveniente.
Tieni presente che in alcuni casi, l'aggiunta di un database separato per la scienza dei dati può essere più conveniente rispetto all'utilizzo dello stesso database (specialmente quando entrano in gioco complicati problemi di licenza).
Questo problema specifico riguarda due disallineamenti menzionati:
Nell'IT tradizionale, le dimensioni del database sono ben definite, o rimangono della stessa dimensione o crescono ad un ritmo modesto. Quando si utilizza un database per la scienza dei dati, tale crescita può essere esponenziale. È comune aggiungere gigabyte di dati ogni giorno (o più). Con la dimensione di questo tipo di dati, un'azienda dovrà incorporare un piano per ridimensionare l'architettura interna o utilizzare una soluzione cloud appropriata.
Per quanto riguarda i dati non strutturati, può richiedere molte risorse in termini di spazio di archiviazione e potenza di elaborazione, a seconda degli usi specifici. Per questo motivo, è spesso inefficiente conservare tutto in un database che potrebbe essere utilizzato per altri scopi. La soluzione è simile al ridimensionamento in generale. Avremo bisogno di un piano per ridimensionare la nostra architettura interna per soddisfare queste esigenze o dovremo trovare una soluzione cloud appropriata.
L'ultima grande differenza di cui parleremo è l'uso delle risorse. Per l'IT, l'utilizzo delle risorse è in genere efficiente, ben definito e coerente. Se un database alimenta un sito eCommerce, esistono vincoli noti. Un professionista IT conoscerà all'incirca quanti utenti ci saranno in un determinato periodo di tempo, in modo che possano pianificare il provisioning hardware in base a quante informazioni sono necessarie per ciascun utente.
Con l'infrastruttura IT tradizionale, non ci saranno problemi incontrati se un progetto utilizza solo poche centinaia di righe da una manciata di tabelle. Ma un progetto che richiede ogni riga da due dozzine di tabelle può diventare rapidamente un problema. Nella scienza dei dati, le esigenze in termini di elaborazione e memorizzazione cambiano da progetto a progetto e questo tipo di imprevedibilità può essere difficile da supportare.
Nell'IT tradizionale, le risorse possono essere condivise con altre parti, che potrebbero essere un sito di produzione dal vivo o un team di sviluppo interno. Il rischio è che l'esecuzione di un progetto di scienza dei dati su larga scala potrebbe potenzialmente bloccare questi altri utenti per un periodo di tempo. Un altro rischio è che i server in possesso di un database potrebbero non essere in grado di gestire la quantità di elaborazione necessaria. Chiamare 200.000 righe da 15 tabelle e chiedere l'aggregazione dei dati in cima, diventa un problema. Questa quantità di query può essere estremamente onerosa su un server che normalmente potrebbe gestire un migliaio di utenti simultanei.
La soluzione ideale arriva al cloud computing. Questo affronta due fattori chiave. Il primo è che consente prestazioni di query lontane da qualsiasi database importante. Il secondo è che fornisce risorse di ridimensionamento che possono adattarsi a ciascun progetto.
Ora che abbiamo parlato in profondità delle esigenze, riassumiamolo. Un dipartimento IT e di informatica avrà bisogno di quanto segue per il successo a lungo termine:
Riassumiamo tutto in specifiche, in modo che possiamo mettere insieme una soluzione reciprocamente vantaggiosa. Ora daremo un'occhiata a come definire le risorse specifiche necessarie per un'organizzazione:
Dal lato IT, ci sono tre definizioni principali necessarie per creare l'infrastruttura necessaria. Questi sono:
Ecco come è possibile determinarne ciascuna.
Tutto inizia con le dimensioni dei dati iniziali necessarie e le aggiunte di dati in corso stimate.
Per le tue esigenze di dati iniziali, prendi le dimensioni definite del tuo attuale database. Ora sottrai qualsiasi colonna o tabella che non ti servirà nei tuoi progetti di scienza dei dati. Prendi questo numero e aggiungi la dimensione dei dati di tutte le nuove fonti che introdurrai. Le nuove fonti potrebbero includere dati o informazioni di Google Analytics dal tuo sistema Point of Sale. Questo totale sarà la memorizzazione dei dati che cercheremo di ottenere in anticipo.
Anche se le esigenze di archiviazione iniziali sono utili in anticipo, dovrai comunque considerare le esigenze dei dati in corso, poiché probabilmente aggiungerai più informazioni al database nel tempo. Per trovare queste informazioni, è possibile calcolare i dati aggiunti quotidianamente dai dati attualmente disponibili. Dai un'occhiata alla quantità di informazioni che sono state aggiunte al tuo database negli ultimi 30 giorni e poi dividile per 30. Quindi ripeti quello per ogni fonte d'informazione che userete, e aggiungili insieme.
Anche se questo non è preciso, c'è un vecchio mantra di sviluppo che dovresti raddoppiare il tuo preventivo, e lo useremo qui. Perché? Vogliamo tenere conto delle modifiche imprevedibili che potrebbero influire sulle esigenze di archiviazione dei dati, come la crescita dell'azienda, le esigenze per progetto o solo aree generali.
Con quel numero ora definito, moltiplicalo per 365. Questa è ora la tua crescita di dati prevista per un anno, che, una volta aggiunta all'importo iniziale, determinerà la quantità di spazio di archiviazione che devi considerare per ottenere.
A differenza delle esigenze di archiviazione dei dati, le esigenze di elaborazione sono molto più difficili da calcolare esattamente. L'obiettivo principale qui è decidere se si vuole mettere il carico pesante su query o su una macchina locale (o istanza cloud). Tieni presente che quando parlo di una macchina locale, non intendo solo il computer che usi normalmente, probabilmente avrai bisogno di una sorta di workstation ottimizzata per i calcoli più intensivi.
Per fare questa scelta, aiuta a pensare al più grande progetto di scienza dei dati che potresti eseguire entro il prossimo anno. La soluzione dati può gestire una query di tale dimensione senza diventare inaccessibile a tutti gli altri stakeholder? Se è possibile, allora sei a posto senza risorse aggiuntive necessarie. In caso contrario, sarà necessario pianificare una workstation di dimensioni appropriate o ridimensionare le istanze cloud.
Dopo aver deciso dove archiviare ed elaborare i tuoi dati, la prossima decisione è come. La creazione di un processo ETL manterrà il database dei dati personali ordinato e aggiornato e impedirà l'utilizzo di risorse non necessarie da altrove.
Ecco cosa dovresti avere nella tua documentazione ETL:
Con tutti i punti dati in mano, è il momento di scegliere una soluzione. Questa parte richiederà un po 'di ricerca e si affiderà molto alle tue esigenze specifiche, poiché in superficie tendono ad avere molte somiglianze.
Tre delle più grandi soluzioni cloud: Amazon Web Services (AWS), Google Cloud Platform (GCP) e Microsoft Azure offrono alcuni dei migliori prezzi e funzionalità. Tutti e tre hanno costi relativamente simili, sebbene AWS sia notevolmente più difficile da calcolare per (a causa della sua a la carte struttura dei prezzi).
Oltre al prezzo, ciascuno offre un'archiviazione dei dati scalabile e la possibilità di aggiungere istanze di elaborazione, anche se ciascuna chiama le "istanze" con un nome diverso. Quando cerchi informazioni su quale utilizzare per la tua infrastruttura, prendi in considerazione i tipi di progetti che utilizzerai di più, in quanto ciò potrebbe spostare il valore del prezzo e del set di funzionalità di ciascuno di essi..
Tuttavia, molte aziende selezionano semplicemente qualsiasi allineamento con il proprio stack tecnologico esistente.
Potresti anche voler installare la tua infrastruttura internamente, sebbene sia molto più complessa e non per i deboli di cuore.
Con tutte le tue anatre di fila, puoi iniziare l'implementazione! Per dare una mano, ecco alcuni consigli duramente guadagnati sul rendere il tuo progetto più semplice, dalla presentazione alla realizzazione.
Quando hai messo insieme per la prima volta il tuo processo ETL, non provare tutto in una volta! Ciò può mettere a dura prova le risorse e aumentare drasticamente i costi del cloud in caso di errore o se si deve tentare il processo più volte.
Invece, è una buona idea eseguire il processo utilizzando solo le prime 100 righe o più delle tabelle di origine all'inizio. Quindi esegui il trasferimento completo una volta che sai che funzionerà.
Lo stesso vale per qualsiasi query di grandi dimensioni eseguita su un'istanza cloud. Fare un errore che attira milioni di dati è molto più difficile su un sistema rispetto a uno che ne attira solo alcuni, soprattutto quando paghi per GB.
La maggior parte degli operatori cloud offre questa funzione come una funzione, quindi potresti non dovertene preoccupare. Il tuo team dovrebbe comunque discutere se vorrebbe creare i propri backup regolari dei dati, o se potrebbe essere più efficace ricostruire i dati nel caso in cui si presentasse la necessità.
Quando trasferisci i dati dei clienti sul cloud, assicurati che tutti gli interessati siano a conoscenza delle politiche di governance dei dati della tua azienda al fine di prevenire i problemi lungo la strada. Questo può anche aiutare a risparmiare un po 'sulla quantità di dati memorizzati nel cloud.
Quando esegui il tuo ETL da un database basato su tabella a uno non strutturato, fai attenzione alle procedure di denominazione. Se i nomi vengono trasferiti all'ingrosso, probabilmente avrai molti campi di tabelle diverse che condividono lo stesso nome. Un modo semplice per ovviare a questo all'inizio è nominare le nuove dimensioni nel database non strutturato come Oldtablename _ nomecolonna e poi rinominarli da lì.
Ora puoi pianificare le basi della tua infrastruttura di analisi e dati. Con molte delle domande e delle risposte chiave definite, il processo di implementazione e l'acquisizione del buy-in manageriale dovrebbero andare molto più facilmente.
Hai difficoltà a trovare risposte per la tua azienda? Ho sorvolato qualcosa di importante? Fatemi sapere nei commenti!
Accentsconagua