Discendenza dei dati - Data lineage

La derivazione dei dati include l' origine dei dati , cosa gli accade e dove si sposta nel tempo. La derivazione dei dati offre visibilità semplificando notevolmente la capacità di risalire alla causa principale degli errori in un processo di analisi dei dati .

Consente inoltre di riprodurre porzioni o input specifici del flusso di dati per il debug graduale o la rigenerazione dell'output perso. I sistemi di database utilizzano tali informazioni, denominate provenienza dei dati , per affrontare problemi simili di convalida e debug. La provenienza dei dati si riferisce alle registrazioni degli input, delle entità, dei sistemi e dei processi che influenzano i dati di interesse, fornendo una registrazione storica dei dati e delle loro origini. Le prove generate supportano attività forensi come l'analisi della dipendenza dai dati, il rilevamento e il ripristino di errori/compromessi, il controllo e l'analisi della conformità. "Il lignaggio è un semplice tipo di perché provenienza ."

La derivazione dei dati può essere rappresentata visivamente per scoprire il flusso/movimento dei dati dalla sorgente alla destinazione tramite vari cambiamenti e salti lungo il percorso nell'ambiente aziendale, come i dati vengono trasformati lungo il percorso, come cambiano la rappresentazione e i parametri e come il i dati si dividono o convergono dopo ogni salto. Una semplice rappresentazione del Data Lineage può essere mostrata con punti e linee, dove punto rappresenta un contenitore di dati per punti dati e le linee che li collegano rappresentano le trasformazioni che il punto dati subisce, tra i contenitori di dati.

La rappresentazione dipende ampiamente dall'ambito della gestione dei metadati e dal punto di riferimento di interesse. La derivazione dei dati fornisce le fonti dei dati e i salti del flusso di dati intermedi dal punto di riferimento con la derivazione dei dati all'indietro , conduce ai punti dati della destinazione finale e ai suoi flussi di dati intermedi con la derivazione dei dati in avanti . Queste viste possono essere combinate con la derivazione end-to-end per un punto di riferimento che fornisce una traccia di controllo completa di quel punto di interesse dei dati dalle origini alle destinazioni finali. All'aumentare dei punti dati o dei salti, la complessità di tale rappresentazione diventa incomprensibile. Pertanto, la migliore caratteristica della vista della derivazione dei dati sarebbe quella di poter semplificare la vista mascherando temporaneamente i punti dati periferici indesiderati. Gli strumenti che dispongono della funzione di mascheramento consentono la scalabilità della vista e migliorano l'analisi con la migliore esperienza utente sia per gli utenti tecnici che per quelli aziendali. La derivazione dei dati consente inoltre alle aziende di tracciare fonti di dati aziendali specifici allo scopo di tenere traccia degli errori, implementare modifiche nei processi e implementare migrazioni di sistema per risparmiare notevoli quantità di tempo e risorse, migliorando così enormemente l' efficienza della BI .

L'ambito della derivazione dei dati determina il volume di metadati necessari per rappresentare la sua derivazione dei dati. Di solito, la governance dei dati e la gestione dei dati determinano l'ambito della derivazione dei dati in base alle loro normative , strategia di gestione dei dati aziendali, impatto dei dati, attributi di reporting ed elementi di dati critici dell'organizzazione.

La derivazione dei dati fornisce l' audit trail dei punti dati al livello granulare più elevato, ma la presentazione della derivazione può essere eseguita a vari livelli di zoom per semplificare le vaste informazioni, in modo simile alle mappe web analitiche. Data Lineage può essere visualizzato a vari livelli in base alla granularità della vista. A un livello molto elevato, la derivazione dei dati fornisce quali sistemi interagiscono i dati prima di raggiungere la destinazione. Man mano che la granularità aumenta, sale al livello del punto dati in cui può fornire i dettagli del punto dati e il suo comportamento storico, le proprietà degli attributi e le tendenze e la qualità dei dati passati attraverso quel punto dati specifico nella derivazione dei dati.

La governance dei dati svolge un ruolo chiave nella gestione dei metadati per linee guida, strategie, politiche, implementazione. La qualità dei dati e la gestione dei dati master aiutano ad arricchire il lignaggio dei dati con più valore aziendale. Anche se la rappresentazione finale della derivazione dei dati è fornita in un'interfaccia, il modo in cui i metadati vengono raccolti ed esposti all'interfaccia utente grafica della derivazione dei dati potrebbe essere completamente diverso. Pertanto, la derivazione dei dati può essere ampiamente suddivisa in tre categorie in base al modo in cui vengono raccolti i metadati: derivazione dei dati che coinvolge pacchetti software per dati strutturati, linguaggi di programmazione e big data .

Le informazioni sulla derivazione dei dati includono metadati tecnici che coinvolgono le trasformazioni dei dati. Le informazioni sulla derivazione dei dati arricchite possono includere risultati dei test sulla qualità dei dati, valori dei dati di riferimento, modelli di dati , vocabolario aziendale , amministratori dei dati , informazioni sulla gestione dei programmi e sistemi informativi aziendali collegati ai punti dati e alle trasformazioni. La funzione di mascheramento nella visualizzazione della derivazione dei dati consente agli strumenti di incorporare tutti gli arricchimenti importanti per il caso d'uso specifico. Per rappresentare sistemi disparati in una visione comune, potrebbe essere necessaria la "normalizzazione dei metadati" o la standardizzazione.

Fondamento logico

Sistemi distribuiti come Google Map Reduce , Microsoft Dryad, Apache Hadoop (un progetto open source) e Google Pregel forniscono tali piattaforme per aziende e utenti. Tuttavia, anche con questi sistemi, l' analisi dei big data può richiedere diverse ore, giorni o settimane per l'esecuzione, semplicemente a causa dei volumi di dati coinvolti. Ad esempio, un algoritmo di previsione delle valutazioni per la sfida del Premio Netflix ha richiesto quasi 20 ore per essere eseguito su 50 core e un'attività di elaborazione delle immagini su larga scala per stimare le informazioni geografiche ha richiesto 3 giorni per essere completata utilizzando 400 core. "Si prevede che il Large Synoptic Survey Telescope genererà terabyte di dati ogni notte e alla fine memorizzerà più di 50 petabyte, mentre nel settore della bioinformatica, le più grandi case di sequenziamento del genoma 12 al mondo ora memorizzano petabyte di dati a testa". È molto difficile per uno scienziato dei dati rintracciare un risultato sconosciuto o imprevisto.

Debug dei big data

L' analisi dei big data è il processo di esame di grandi insiemi di dati per scoprire modelli nascosti, correlazioni sconosciute, tendenze di mercato, preferenze dei clienti e altre utili informazioni aziendali. Applicano algoritmi di apprendimento automatico ecc. Ai dati che trasformano i dati. A causa delle dimensioni enormi dei dati, potrebbero esserci caratteristiche sconosciute nei dati, forse anche valori anomali. È piuttosto difficile per uno scienziato dei dati eseguire effettivamente il debug di un risultato imprevisto.

L'enorme scala e la natura non strutturata dei dati, la complessità di queste pipeline di analisi e i lunghi tempi di esecuzione pongono sfide significative in termini di gestibilità e debug. Anche un singolo errore in queste analisi può essere estremamente difficile da identificare e rimuovere. Sebbene sia possibile eseguirne il debug eseguendo nuovamente l'intera analisi tramite un debugger per il debug graduale, ciò può essere costoso a causa della quantità di tempo e risorse necessarie. L'audit e la convalida dei dati sono altri importanti problemi a causa della crescente facilità di accesso a fonti di dati rilevanti per l'uso negli esperimenti, la condivisione di dati tra comunità scientifiche e l'uso di dati di terze parti nelle imprese commerciali. Questi problemi diventeranno solo più grandi e più acuti man mano che questi sistemi e dati continueranno a crescere. Pertanto, metodi più efficienti in termini di costi per analizzare il calcolo scalabile ad alta intensità di dati (DISC) sono fondamentali per il loro uso efficace e continuo.

Sfide nel debug dei big data

Larga scala

Secondo uno studio EMC/IDC:

• 2.8ZB di dati sono stati creati e replicati nel 2012,
• l'universo digitale raddoppierà ogni due anni da qui al 2020, e
• ci saranno circa 5,2 TB di dati per ogni persona nel 2020.

Lavorare con questa scala di dati è diventato molto impegnativo.

Dati non strutturati

I dati non strutturati di solito si riferiscono a informazioni che non risiedono in un database riga-colonna tradizionale. I file di dati non strutturati spesso includono testo e contenuti multimediali. Gli esempi includono messaggi di posta elettronica, documenti di elaborazione testi, video, foto, file audio, presentazioni, pagine Web e molti altri tipi di documenti aziendali. Si noti che sebbene questi tipi di file possano avere una struttura interna, sono comunque considerati "non strutturati" perché i dati che contengono non si adattano perfettamente a un database. Gli esperti stimano che l'80-90 percento dei dati in qualsiasi organizzazione non sia strutturato. E la quantità di dati non strutturati nelle imprese sta crescendo significativamente, spesso molte volte più velocemente di quanto crescano i database strutturati. " I big data possono includere sia dati strutturati che non strutturati, ma IDC stima che il 90% dei big data sia costituito da dati non strutturati".

La sfida fondamentale delle origini dati non strutturate è che sono difficili da estrarre, comprendere e preparare per l'uso analitico sia per gli utenti aziendali non tecnici che per gli analisti di dati. Al di là dei problemi di struttura, c'è l'enorme volume di questo tipo di dati. Per questo motivo, le attuali tecniche di data mining spesso tralasciano informazioni preziose e rendono laboriosa e costosa l'analisi dei dati non strutturati.

Lunga autonomia

Nell'ambiente aziendale competitivo odierno, le aziende devono trovare e analizzare rapidamente i dati rilevanti di cui hanno bisogno. La sfida consiste nell'esaminare i volumi di dati e nell'accedere al livello di dettaglio necessario, il tutto ad alta velocità. La sfida cresce solo all'aumentare del grado di granularità. Una possibile soluzione è l'hardware. Alcuni fornitori utilizzano una maggiore memoria e l' elaborazione parallela per elaborare rapidamente grandi volumi di dati. Un altro metodo consiste nel mettere i dati in memoria ma utilizzando un approccio di grid computing , in cui vengono utilizzate molte macchine per risolvere un problema. Entrambi gli approcci consentono alle organizzazioni di esplorare enormi volumi di dati. Anche questo livello di hardware e software sofisticati, poche delle attività di elaborazione delle immagini su larga scala richiedono da pochi giorni a poche settimane. Il debug dell'elaborazione dei dati è estremamente difficile a causa dei lunghi tempi di esecuzione.

Un terzo approccio di soluzioni avanzate di rilevamento dei dati combina la preparazione dei dati self-service con il rilevamento visivo dei dati, consentendo agli analisti di preparare e visualizzare simultaneamente i dati fianco a fianco in un ambiente di analisi interattivo offerto dalle società più recenti Trifacta , Alteryx e altri.

Un altro metodo per tenere traccia della derivazione dei dati sono i programmi di fogli di calcolo come Excel che offrono agli utenti la derivazione a livello di cella o la possibilità di vedere quali celle dipendono da un'altra, ma la struttura della trasformazione è persa. Allo stesso modo, l' ETL o il software di mappatura forniscono un lignaggio a livello di trasformazione, ma questa vista in genere non visualizza i dati ed è troppo grossolana per distinguere tra trasformazioni logicamente indipendenti (ad esempio trasformazioni che operano su colonne distinte) o dipendenti.

Piattaforma complessa

Le piattaforme Big Data hanno una struttura molto complicata. I dati sono distribuiti tra più macchine. In genere i lavori vengono mappati su più macchine e i risultati vengono successivamente combinati mediante operazioni di riduzione. Il debug di una pipeline di big data diventa molto impegnativo a causa della natura stessa del sistema. Non sarà un compito facile per lo scienziato dei dati capire quali dati della macchina hanno i valori anomali e le caratteristiche sconosciute che fanno sì che un particolare algoritmo dia risultati imprevisti.

La soluzione proposta

La provenienza dei dati o la derivazione dei dati può essere utilizzata per semplificare il debug della pipeline di big data . Ciò richiede la raccolta di dati sulle trasformazioni dei dati. La sezione seguente spiegherà la provenienza dei dati in modo più dettagliato.

Provenienza dei dati

La provenienza dei dati fornisce una registrazione storica dei dati e delle loro origini. La provenienza dei dati generati da trasformazioni complesse come i flussi di lavoro è di notevole valore per gli scienziati. Da esso, è possibile accertare la qualità dei dati in base ai dati e alle derivazioni ancestrali, rintracciare le fonti di errore, consentire la rievocazione automatizzata delle derivazioni per aggiornare i dati e fornire l'attribuzione delle fonti di dati. La provenienza è inoltre essenziale per il dominio aziendale in cui può essere utilizzata per eseguire il drill-down fino alla fonte dei dati in un data warehouse , tenere traccia della creazione della proprietà intellettuale e fornire una traccia di controllo per scopi normativi.

L'uso della provenienza dei dati è proposto nei sistemi distribuiti per tracciare i record attraverso un flusso di dati, riprodurre il flusso di dati su un sottoinsieme dei suoi input originali ed eseguire il debug dei flussi di dati. Per fare ciò, è necessario tenere traccia dell'insieme di input per ciascun operatore, che sono stati utilizzati per derivare ciascuno dei suoi output. Sebbene ci siano diverse forme di provenienza, come la provenienza della copia e la provenienza del come, le informazioni di cui abbiamo bisogno sono una semplice forma di provenienza del perché, o lignaggio , come definito da Cui et al.

Cattura del lignaggio

Intuitivamente, per un operatore T che produce l'output o, il lignaggio consiste di terzine di forma {I, T, o}, dove I è l'insieme degli input di T utilizzati per derivare o. L'acquisizione del lignaggio per ciascun operatore T in un flusso di dati consente agli utenti di porre domande come "Quali output sono stati prodotti da un input i sull'operatore T?" e "Quali input hanno prodotto output o nell'operatore T?" Una query che trova gli input che derivano da un output è chiamata query di tracciamento all'indietro, mentre una che trova gli output prodotti da un input è chiamata query di tracciamento in avanti. La traccia all'indietro è utile per il debug, mentre la traccia in avanti è utile per tenere traccia della propagazione degli errori. Le query di tracciamento costituiscono anche la base per riprodurre un flusso di dati originale. Tuttavia, per utilizzare in modo efficiente il lignaggio in un sistema DISC, dobbiamo essere in grado di acquisire il lignaggio a più livelli (o granularità) di operatori e dati, acquisire un lignaggio accurato per i costrutti di elaborazione DISC ed essere in grado di tracciare in modo efficiente più fasi del flusso di dati.

Il sistema DISC è costituito da diversi livelli di operatori e dati e diversi casi d'uso di lignaggio possono dettare il livello a cui è necessario acquisire il lignaggio. Il lignaggio può essere acquisito a livello del lavoro, utilizzando file e fornendo tuple di lignaggio della forma {IF i, M RJob, OF i }, il lignaggio può anche essere acquisito a livello di ciascuna attività, utilizzando record e dando, ad esempio, tuple di lignaggio di forma {(k rr, v rr ), map, (km, vm )}. La prima forma di lignaggio è chiamata lignaggio a grana grossa, mentre la seconda forma è chiamata lignaggio a grana fine. L'integrazione del lignaggio tra diverse granularità consente agli utenti di porre domande come "Quale file letto da un lavoro MapReduce ha prodotto questo particolare record di output?" e può essere utile nel debug su diversi operatori e granularità di dati all'interno di un flusso di dati.

Per catturare il lignaggio end-to-end in un sistema DISC, utilizziamo il modello Ibis, che introduce la nozione di gerarchie di contenimento per operatori e dati. Nello specifico, Ibis propone che un operatore possa essere contenuto all'interno di un altro e tale relazione tra due operatori si chiama contenimento dell'operatore . "Il contenimento dell'operatore implica che l'operatore contenuto (o figlio) esegua una parte dell'operazione logica dell'operatore contenitore (o padre)." Ad esempio, un'attività MapReduce è contenuta in un lavoro. Esistono relazioni di contenimento simili anche per i dati, chiamate contenimento dei dati. Il contenimento dei dati implica che i dati contenuti siano un sottoinsieme dei dati contenenti (superset).

Discendenza dati prescrittiva

Il concetto di derivazione dati prescrittiva combina sia il modello logico (entità) di come quei dati dovrebbero fluire con la derivazione effettiva per quell'istanza.

La derivazione e la provenienza dei dati si riferiscono in genere al modo o ai passaggi di un set di dati per arrivare allo stato attuale La derivazione dei dati, nonché tutte le copie oi derivati. Tuttavia, guardare indietro solo alle correlazioni di audit o di registro per determinare la discendenza da un punto di vista forense è errato per alcuni casi di gestione dei dati. Ad esempio, è impossibile determinare con certezza se il percorso seguito da un flusso di lavoro di dati fosse corretto o conforme senza il modello logico.

Solo combinando un modello logico con eventi forensi atomici è possibile convalidare le attività appropriate:

1. Copie autorizzate, join o operazioni CTAS
2. Mappatura dell'elaborazione ai sistemi su cui vengono eseguiti tali processi
3. Sequenze di elaborazione ad-hoc rispetto a quelle stabilite

Molti rapporti di conformità certificati richiedono la provenienza del flusso di dati, nonché i dati sullo stato finale per un'istanza specifica. Con questi tipi di situazioni, qualsiasi deviazione dal percorso prescritto deve essere presa in considerazione e potenzialmente risolta. Questo segna un cambiamento nel modo di pensare da un semplice modello di sguardo indietro a un framework più adatto a catturare i flussi di lavoro di conformità.

Genere attivo contro lignaggio pigro

La raccolta di discendenza pigra in genere acquisisce solo la discendenza a grana grossa in fase di esecuzione. Questi sistemi comportano bassi costi di acquisizione a causa della piccola quantità di lignaggio che catturano. Tuttavia, per rispondere a query di traccia a grana fine, devono riprodurre il flusso di dati su tutto (o gran parte) del suo input e raccogliere un lignaggio a grana fine durante la riproduzione. Questo approccio è adatto per i sistemi forensi, in cui un utente desidera eseguire il debug di un output errato osservato.

I sistemi di raccolta attivi acquisiscono l'intero lignaggio del flusso di dati in fase di esecuzione. Il tipo di lignaggio che catturano può essere a grana grossa oa grana fine, ma non richiedono ulteriori calcoli sul flusso di dati dopo la sua esecuzione. I sistemi di raccolta del lignaggio attivo a grana fine comportano costi di acquisizione maggiori rispetto ai sistemi di raccolta pigri. Tuttavia, consentono la riproduzione e il debug sofisticati.

attori

Un attore è un'entità che trasforma i dati; può essere un vertice Driade, singoli operatori di mappa e reduce, un lavoro MapReduce o un'intera pipeline di flussi di dati. Gli attori agiscono come scatole nere e gli input e gli output di un attore vengono sfruttati per catturare il lignaggio sotto forma di associazioni, dove un'associazione è una tripletta {i, T, o} che mette in relazione un input i con un output o per un attore t. La strumentazione cattura quindi il lignaggio in un flusso di dati un attore alla volta, inserendolo in un insieme di associazioni per ciascun attore. Lo sviluppatore del sistema deve acquisire i dati letti da un attore (da altri attori) e i dati scritti da un attore (ad altri attori). Ad esempio, uno sviluppatore può trattare Hadoop Job Tracker come un attore registrando l'insieme di file letti e scritti da ciascun lavoro.

Associazioni

L'associazione è una combinazione degli ingressi, delle uscite e dell'operazione stessa. L'operazione è rappresentata nei termini di una scatola nera conosciuta anche come l'attore. Le associazioni descrivono le trasformazioni che vengono applicate ai dati. Le associazioni sono memorizzate nelle tabelle di associazione. Ogni attore unico è rappresentato da una propria tabella di associazione. Un'associazione stessa assomiglia a {i, T, o} dove i è l'insieme degli input per l'attore T e o è l'insieme degli output dati prodotti dall'attore. Le associazioni sono le unità di base di Data Lineage. Le singole associazioni vengono successivamente messe insieme per costruire l'intera cronologia delle trasformazioni che sono state applicate ai dati.

Architettura

I sistemi Big Data scalano orizzontalmente, ovvero aumentano la capacità aggiungendo nuove entità hardware o software nel sistema distribuito. Il sistema distribuito agisce come un'unica entità a livello logico anche se comprende più entità hardware e software. Il sistema dovrebbe continuare a mantenere questa proprietà dopo il ridimensionamento orizzontale. Un importante vantaggio della scalabilità orizzontale è che può fornire la capacità di aumentare la capacità al volo. Il più grande vantaggio è che il ridimensionamento orizzontale può essere eseguito utilizzando hardware di base.

La funzionalità di ridimensionamento orizzontale dei sistemi Big Data dovrebbe essere presa in considerazione durante la creazione dell'architettura del negozio di lignaggio. Questo è essenziale perché anche lo stesso negozio di lignaggio dovrebbe essere in grado di scalare in parallelo con il sistema Big Data . Il numero di associazioni e la quantità di spazio di archiviazione necessari per memorizzare il lignaggio aumenteranno con l'aumento delle dimensioni e della capacità del sistema. L'architettura dei sistemi Big Data rende l'uso di un singolo archivio di lignaggio non appropriato e impossibile da scalare. La soluzione immediata a questo problema è distribuire il negozio di lignaggio stesso.

Lo scenario migliore consiste nell'utilizzare un archivio di derivazione locale per ogni macchina nella rete del sistema distribuito. Ciò consente al negozio di lignaggio di scalare anche orizzontalmente. In questo progetto, la derivazione delle trasformazioni dei dati applicate ai dati su una particolare macchina viene archiviata nell'archivio di derivazione locale di quella macchina specifica. L'archivio di derivazione in genere archivia le tabelle di associazione. Ogni attore è rappresentato da una propria tabella di associazione. Le righe sono le associazioni stesse e le colonne rappresentano input e output. Questo design risolve 2 problemi. Consente il ridimensionamento orizzontale del negozio di lignaggio. Se veniva utilizzato un singolo archivio di derivazione centralizzato, queste informazioni dovevano essere trasferite sulla rete, il che avrebbe causato una latenza di rete aggiuntiva. La latenza di rete viene inoltre evitata utilizzando un archivio di derivazione distribuito.

Ricostruzione del flusso di dati

Le informazioni memorizzate in termini di associazioni devono essere combinate in qualche modo per ottenere il flusso di dati di un particolare lavoro. In un sistema distribuito un lavoro è suddiviso in più attività. Una o più istanze eseguono una determinata attività. I risultati prodotti su queste singole macchine vengono successivamente combinati insieme per completare il lavoro. Le attività in esecuzione su macchine diverse eseguono più trasformazioni sui dati nella macchina. Tutte le trasformazioni applicate ai dati su una macchina sono memorizzate nell'archivio di derivazione locale di quelle macchine. Queste informazioni devono essere combinate insieme per ottenere la discendenza dell'intero lavoro. La discendenza dell'intero lavoro dovrebbe aiutare il data scientist a comprendere il flusso di dati del lavoro e può utilizzare il flusso di dati per eseguire il debug della pipeline dei big data . Il flusso di dati viene ricostruito in 3 fasi.

Tabelle di associazione

La prima fase della ricostruzione del flusso di dati è il calcolo delle tabelle di associazione. Le tabelle di associazione esistono per ogni attore in ogni negozio di lignaggio locale. L'intera tabella di associazione per un attore può essere calcolata combinando queste singole tabelle di associazione. Questo viene generalmente fatto utilizzando una serie di giunzioni di uguaglianza basate sugli attori stessi. In alcuni scenari le tabelle potrebbero anche essere unite utilizzando gli input come chiave. Gli indici possono essere utilizzati anche per migliorare l'efficienza di un join. Le tabelle unite devono essere archiviate su una singola istanza o su una macchina per continuare ulteriormente l'elaborazione. Esistono più schemi utilizzati per selezionare una macchina in cui verrà calcolato un join. Il più semplice è quello con il carico minimo della CPU. È inoltre necessario tenere presente i vincoli di spazio durante la selezione dell'istanza in cui si verificherà l'unione.

Grafico dell'associazione

Il secondo passaggio nella ricostruzione del flusso di dati consiste nel calcolare un grafico di associazione dalle informazioni di discendenza. Il grafico rappresenta i passaggi nel flusso di dati. Gli attori fungono da vertici e le associazioni da bordi. Ogni attore T è collegato ai suoi attori a monte ea valle nel flusso di dati. Un attore a monte di T è quello che ha prodotto l'input di T, mentre un attore a valle è quello che consuma l'output di T . Le relazioni di contenimento vengono sempre considerate durante la creazione dei collegamenti. Il grafico è costituito da tre tipi di collegamenti o bordi.

Link specificati in modo esplicito

Il collegamento più semplice è un collegamento specificato in modo esplicito tra due attori. Questi collegamenti sono specificati in modo esplicito nel codice di un algoritmo di apprendimento automatico. Quando un attore è a conoscenza del suo esatto attore a monte oa valle, può comunicare queste informazioni all'API di lignaggio. Queste informazioni vengono successivamente utilizzate per collegare questi attori durante la query di traccia. Ad esempio, nell'architettura MapReduce , ogni istanza della mappa conosce l'esatta istanza del lettore di record di cui utilizza l'output.

Link dedotti logicamente

Gli sviluppatori possono allegare archetipi del flusso di dati a ciascun attore logico. Un archetipo di flusso di dati spiega come i tipi figli di un tipo di attore si organizzano in un flusso di dati. Con l'aiuto di queste informazioni, si può dedurre un collegamento tra ciascun attore di un tipo di sorgente e un tipo di destinazione. Ad esempio, nell'architettura MapReduce , il tipo di attore della mappa è l'origine per reduce e viceversa. Il sistema lo deduce dagli archetipi del flusso di dati e collega debitamente le istanze della mappa con le istanze ridotte. Tuttavia, potrebbero esserci diversi processi MapReduce nel flusso di dati e il collegamento di tutte le istanze della mappa con tutte le istanze reduce può creare collegamenti falsi. Per evitare ciò, tali collegamenti sono limitati alle istanze di attore contenute all'interno di un'istanza di attore comune di un tipo di attore contenente (o padre). Pertanto, le istanze map e reduce sono collegate tra loro solo se appartengono allo stesso lavoro.

Collegamenti impliciti attraverso la condivisione di set di dati

Nei sistemi distribuiti, a volte sono presenti collegamenti impliciti, che non vengono specificati durante l'esecuzione. Ad esempio, esiste un collegamento implicito tra un attore che ha scritto su un file e un altro attore che ha letto da esso. Tali collegamenti collegano gli attori che utilizzano un set di dati comune per l'esecuzione. Il dataset è l'output del primo attore ed è l'input dell'attore che lo segue.

Ordinamento topologico

Il passaggio finale nella ricostruzione del flusso di dati è l' ordinamento topologico del grafico di associazione. Il grafo diretto creato nel passaggio precedente viene ordinato topologicamente per ottenere l'ordine in cui gli attori hanno modificato i dati. Questo ordine ereditario degli attori definisce il flusso di dati della pipeline o attività di Big Data.

Tracciare e riprodurre

Questo è il passaggio più cruciale nel debug di Big Data . Il lignaggio catturato viene combinato ed elaborato per ottenere il flusso di dati della pipeline. Il flusso di dati aiuta il data scientist o uno sviluppatore a esaminare in profondità gli attori e le loro trasformazioni. Questo passaggio consente al data scientist di individuare la parte dell'algoritmo che genera l'output imprevisto. Una pipeline di big data può andare storta in due grandi modi. Il primo è la presenza di un attore sospetto nel flusso di dati. Il secondo è l'esistenza di valori anomali nei dati.

Il primo caso può essere sottoposto a debug tracciando il flusso di dati. Utilizzando insieme le informazioni sulla discendenza e sul flusso di dati, uno scienziato dei dati può capire come gli input vengono convertiti in output. Durante il processo, gli attori che si comportano in modo imprevisto possono essere catturati. Questi attori possono essere rimossi dal flusso di dati o possono essere aumentati da nuovi attori per modificare il flusso di dati. Il flusso di dati migliorato può essere riprodotto per verificarne la validità. Il debug di attori difettosi include l'esecuzione ricorsiva di replay a grana grossa sugli attori nel flusso di dati, che può essere costoso in termini di risorse per lunghi flussi di dati. Un altro approccio consiste nell'ispezionare manualmente i log di derivazione per trovare anomalie, che possono essere noiose e richiedere molto tempo in diverse fasi di un flusso di dati. Inoltre, questi approcci funzionano solo quando il data scientist può scoprire risultati errati. Per eseguire il debug dell'analisi senza risultati errati noti, il data scientist deve analizzare il flusso di dati per rilevare comportamenti sospetti in generale. Tuttavia, spesso, un utente potrebbe non conoscere il comportamento normale previsto e non è in grado di specificare i predicati. Questa sezione descrive una metodologia di debug per analizzare retrospettivamente il lignaggio per identificare gli attori difettosi in un flusso di dati a più fasi. Riteniamo che i cambiamenti improvvisi nel comportamento di un attore, come la sua selettività media, la velocità di elaborazione o la dimensione dell'output, siano caratteristici di un'anomalia. Il lignaggio può riflettere tali cambiamenti nel comportamento dell'attore nel tempo e attraverso diverse istanze dell'attore. Pertanto, il lignaggio minerario per identificare tali cambiamenti può essere utile per il debug di attori difettosi in un flusso di dati.

Il secondo problema, ovvero l'esistenza di outlier, può essere identificato anche eseguendo la fase del flusso di dati e osservando gli output trasformati. Il data scientist trova un sottoinsieme di output che non è conforme al resto degli output. Gli input che causano queste cattive uscite sono i valori anomali nei dati. Questo problema può essere risolto rimuovendo l'insieme di valori anomali dai dati e riproducendo l'intero flusso di dati. Può anche essere risolto modificando l'algoritmo di apprendimento automatico aggiungendo, rimuovendo o spostando gli attori nel flusso di dati. Le modifiche al flusso di dati hanno esito positivo se il flusso di dati riprodotto non produce output errati.

Sfide

Anche se l'uso di approcci di derivazione dei dati è un nuovo modo di eseguire il debug di pipeline di big data , il processo non è semplice. Le sfide includono la scalabilità dell'archivio di lignaggio, la tolleranza ai guasti dell'archivio di lignaggio, l'acquisizione accurata del lignaggio per gli operatori della scatola nera e molti altri. Queste sfide devono essere considerate con attenzione e devono essere valutati i compromessi tra di loro per realizzare un progetto realistico per l'acquisizione della derivazione dei dati.

Scalabilità

I sistemi DISC sono principalmente sistemi di elaborazione batch progettati per un'elevata produttività. Eseguono diversi lavori per analisi, con diverse attività per lavoro. Il numero complessivo di operatori eseguiti in qualsiasi momento in un cluster può variare da centinaia a migliaia a seconda delle dimensioni del cluster. L'acquisizione del lignaggio per questi sistemi deve essere in grado di adattarsi sia a grandi volumi di dati che a numerosi operatori per evitare di essere un collo di bottiglia per l'analisi DISC.

Tolleranza ai guasti

I sistemi di acquisizione della derivazione devono anche essere tolleranti ai guasti per evitare di rieseguire i flussi di dati per acquisire la derivazione. Allo stesso tempo, devono anche gestire i guasti nel sistema DISC. Per fare ciò, devono essere in grado di identificare un'attività DISC non riuscita ed evitare di archiviare copie duplicate del lignaggio tra il lignaggio parziale generato dall'attività fallita e il lignaggio duplicato prodotto dall'attività riavviata. Un sistema di lignaggio dovrebbe anche essere in grado di gestire con garbo più istanze di sistemi di lignaggio locali che non funzionano. Ciò può essere ottenuto archiviando repliche di associazioni di discendenza in più macchine. La replica può fungere da backup in caso di perdita della copia reale.

Operatori scatola nera

I sistemi di lignaggio per i flussi di dati DISC devono essere in grado di acquisire un lignaggio accurato tra gli operatori black-box per consentire il debug a grana fine. Gli approcci attuali a questo includono Prober, che cerca di trovare l'insieme minimo di input in grado di produrre un output specificato per un operatore black-box riproducendo più volte il flusso di dati per dedurre l'insieme minimo e lo slicing dinamico, come utilizzato da Zhang et al. per acquisire la discendenza per gli operatori NoSQL attraverso la riscrittura binaria per calcolare le sezioni dinamiche. Sebbene producano un lignaggio altamente accurato, tali tecniche possono comportare notevoli spese generali di tempo per l'acquisizione o il tracciamento e potrebbe essere preferibile scambiare una certa accuratezza per prestazioni migliori. Pertanto, è necessario un sistema di raccolta del lignaggio per i flussi di dati DISC in grado di acquisire il lignaggio da operatori arbitrari con ragionevole accuratezza e senza spese generali significative nell'acquisizione o nel tracciamento.

Tracciamento efficiente

La traccia è essenziale per il debug, durante il quale un utente può inviare più query di traccia. Pertanto, è importante che il tracciamento abbia tempi di risposta rapidi. Ikeda et al. possono eseguire query di tracciamento all'indietro efficienti per i flussi di dati MapReduce, ma non sono generiche per diversi sistemi DISC e non eseguono query in avanti efficienti. Lipstick, un sistema di lignaggio per Pig, sebbene in grado di eseguire la tracciatura sia all'indietro che in avanti, è specifico per gli operatori Pig e SQL e può eseguire solo la tracciatura a grana grossa per gli operatori black-box. Pertanto, è necessario un sistema di lignaggio che consenta un efficiente tracciamento in avanti e all'indietro per sistemi DISC generici e flussi di dati con operatori black-box.

Replay sofisticato

Riprodurre solo input o porzioni specifici di un flusso di dati è fondamentale per un debugging efficiente e simulare scenari ipotetici. Ikeda et al. presentare una metodologia per l'aggiornamento basato sul lignaggio, che riproduce selettivamente gli input aggiornati per ricalcolare gli output interessati. Ciò è utile durante il debug per ricalcolare gli output quando è stato corretto un input errato. Tuttavia, a volte un utente potrebbe voler rimuovere l'input errato e riprodurre il lignaggio degli output precedentemente interessati dall'errore per produrre output privi di errori. Chiamiamo questo replay esclusivo. Un altro uso della riproduzione nel debug comporta la riproduzione di input errati per il debug graduale (chiamato replay selettivo). Gli attuali approcci all'utilizzo del lignaggio nei sistemi DISC non affrontano questi problemi. Pertanto, è necessario un sistema di derivazione in grado di eseguire replay sia esclusivi che selettivi per soddisfare le diverse esigenze di debug.

Rilevamento anomalie

Uno dei principali problemi di debug nei sistemi DISC è l'identificazione degli operatori difettosi. In lunghi flussi di dati con diverse centinaia di operatori o attività, l'ispezione manuale può essere noiosa e proibitiva. Anche se la derivazione viene utilizzata per restringere il sottoinsieme di operatori da esaminare, la derivazione di un singolo output può comunque estendersi su più operatori. C'è bisogno di un sistema di debug automatizzato poco costoso, che possa sostanzialmente restringere l'insieme di operatori potenzialmente difettosi, con ragionevole accuratezza, per ridurre al minimo la quantità di esame manuale richiesto.

Guarda anche

• Grafico aciclico diretto

Riferimenti