Il vecchio adagio “entra, spazzatura fuori” non è mai passato di moda. L'appetito vorace per i dati da parte dei modelli di analisi e apprendimento automatico ha aumentato l'urgenza di ottenere i dati corretti. La disciplina di DataOps è emersa in risposta alla necessità per analisti aziendali e data scientist di avere fiducia nei dati che popolano i loro modelli e dashboard.
La posta in gioco per ottenere dati corretti sta aumentando mentre gli ingegneri e gli scienziati dei dati stanno costruendo innumerevoli pipeline di dati per popolare i loro modelli. Ci preoccupiamo da tempo della deriva del modello AI e ML, ma potrebbe essere possibile lo stesso con le origini dati che si degradano o diventano obsolete? O con pipeline di dati in cui le operazioni deviano gradualmente a causa di problemi operativi come la latenza imprevista che potrebbe interrompere e annullare l'affidabilità del filtraggio o delle trasformazioni dei dati.
La disciplina di DataOps mette in luce l'uso dell'automazione per scalare la sfida della qualità dei dati. Tuttavia, l'applicazione di strumenti automatizzati per la qualità dei dati o la catalogazione non garantisce che i set di dati utilizzati siano quelli corretti o più pertinenti al problema, né possono garantire la freschezza o l'attualità. Nella migliore delle ipotesi, le risposte sono ad hoc: ci sono numerose fonti di derivazione dei dati, quindi la domanda spesso si riduce a quale versione della verità seguire. Inoltre, gli strumenti per la qualità dei dati potrebbero non fornire sempre una copertura completa. Per quanto riguarda i cataloghi di dati, nel migliore dei casi forniscono solo opportunità ai membri del team di commentare aneddoticamente l'utilità dei dati. Troppo spesso, DataOps si verifica su base ad hoc, interruzione/riparazione.
Un team di Uber ha sperimentato il problema in prima persona mentre affrontava problemi di fiducia mentre le pipeline di dati iniziavano a proliferare a migliaia. Kyle Kirwan, ex product manager di Uber, si è reso conto che i professionisti dei dati dovevano concentrarsi in modo più continuo sulla gestione della qualità e della pertinenza dei dati. In particolare, era necessaria una nuova disciplina per “Ingegneria dell'affidabilità dei dati”, modellata sull'ingegneria dell'affidabilità del sito, per mantenere un occhio costante.
Il risultato è Bigeye, una startup che ha appena ricevuto il suo secondo importante finanziamento (portando il totale a 66 milioni di dollari), che ha introdotto quella che definisce una piattaforma di “osservabilità dei dati” che può aiutare le organizzazioni a creare una pratica di ingegneria dell'affidabilità dei dati.
Fornito come servizio cloud, Bigeye campiona continuamente ogni set di dati, fornendo una sequenza temporale continua di profilazione dei dati per controllare continuamente parametri come conteggi di righe, cardinalità, duplicati, null e spazi vuoti, sintassi, valori previsti e altro valori anomali. Tiene inoltre traccia della “freschezza” in base ai timestamp del set di dati e quando è stato aggiornato l'ultima volta. Le soglie possono essere impostate manualmente o tramite suggerimenti algoritmici.
La relazione tra Data Observability e Data Reliability Engineering
Credit: Bigeye
In sostanza, Bigeye sta ai dati cosa Datadog sta alle app e, non a caso, il CEO di Datadog è uno dei membri del consiglio di amministrazione.
Bigeye non memorizza i dati grezzi di per sé, ma invece memorizza e tiene traccia delle metriche di salute nel tempo. Attualmente, Bigeye ha integrazioni per la maggior parte dei soliti sospetti tra cui Snowflake, Google BigQuery, Amazon Redshift, PostgreSQL, MySQL, SQL Server e Databricks.
A questo punto, Bigeye è progettato per trasformare la profilazione dei dati in un'attività continua e dinamica attraverso il campionamento costante dei feed di dati. Questo in sostanza fornisce il pezzo di osservabilità. Per abilitare l'ingegneria dell'affidabilità dei dati, Bigeye prevede di aggiungere flussi di lavoro per il monitoraggio e la gestione degli SLA, funzionalità per l'analisi delle cause principali. Parte di questo potrebbe essere affrontato attraverso l'analisi del lignaggio dei dati. Tuttavia, anche se le fonti dei dati continuano a essere comprovate, i blips nelle prestazioni del server o della rete potrebbero danneggiare i dati; ad esempio, un punto debole in un feed di rete potrebbe compromettere l'affidabilità dei dati derivati da fonti di serie temporali. È qui che il legame con l'osservabilità dell'applicazione potrebbe collegarsi per costruire il quadro completo e perché riteniamo che le sinergie con Datadog non siano solo teoriche.
Big Data
Dove è il launchpad del cloud ibrido di IBM? Sette modi per rendere reale la tecnologia in tempo reale per la tua organizzazione Machine learning all'avanguardia: TinyML sta diventando grande Quali sono le prospettive di Cloudera? McDonald's vuole “democratizzare” l'apprendimento automatico per tutti gli utenti nelle sue operazioni
Argomenti correlati:
Cloud Digital Transformation Robotica Internet of Things Innovation Software aziendale 