Come eseguire il debug dell'analisi dei dati?

Mi sono imbattuto nel seguente problema, che riconosco è piuttosto tipico.

Ho alcuni dati di grandi dimensioni, diciamo, alcuni milioni di righe. Eseguo alcune analisi non banali su di esso, ad esempio una query SQL composta da diverse sottoquery. Ottengo alcuni risultati, affermando, ad esempio, che la proprietà X sta aumentando nel tempo.

Ora, ci sono due possibili cose che potrebbero portare a questo:

1. X sta davvero aumentando nel tempo
2. Ho un bug nella mia analisi

Come posso verificare che sia accaduto il primo, anziché il secondo? Un debugger graduale, anche se esistente, non aiuta, poiché i risultati intermedi possono ancora consistere in milioni di righe.

L'unica cosa a cui potevo pensare era di generare in qualche modo un piccolo set di dati sintetici con la proprietà che volevo testare ed eseguire l'analisi su di esso come test unitario. Ci sono strumenti per farlo? In particolare, ma non limitato a, SQL.

Ecco un suggerimento:

• Codifica la tua analisi in modo tale che possa essere eseguita su sottocampioni.
• Codifica una routine complementare che può essere campionata, in modo casuale, in base al tempo o in base alla regione o ... Questo può essere specifico del dominio. Qui è dove entra la tua conoscenza.
• Combina i due e verifica se i risultati sono stabili tra i sottocampioni.

Questo è ciò che faccio normalmente - riprendo le variabili più importanti (in base alla comprensione e all'ipotesi della tua attività - puoi sempre rivederle in seguito), raggruppare questi attributi per ridurre il numero di righe, che possono quindi essere importate in un Pivot. È necessario includere la somma e il conteggio delle metriche pertinenti su ciascuna riga.

Assicurati di non inserire alcun filtro nel passaggio precedente. Una volta che hai interi dati a un livello riepilogativo, puoi giocare nelle tabelle Pivot e vedere quali cose stanno cambiando / aumentando o diminuendo.

Se i dati sono troppo grandi per essere riepilogati anche su parametri importanti, è necessario suddividerli in 3-4 sottoinsiemi e ripetere l'operazione.

Spero che sia d'aiuto.

Innanzitutto è necessario verificare che l'implementazione dell'algoritmo sia accurata. Per questo usa un piccolo campione di dati e controlla se il risultato è corretto. In questa fase il campione non deve essere rappresentativo della popolazione.

Una volta verificata l'implementazione, è necessario verificare l'esistenza di una relazione significativa tra le variabili che si tenta di prevedere. Per fare ciò, definire l'ipotesi nulla e provare a rifiutare l'ipotesi nulla con un livello di confidenza significativo. ( test di ipotesi per regressione lineare )

Potrebbero esserci framework di unit test per la tua distribuzione SQL. Ma usare un linguaggio di programmazione come R sarà più facile da implementare.

Mi piace una strategia a più passaggi:

1. Scrivi un codice pulito e di facile comprensione, al contrario del codice breve. Conosco gli statistici come il codice ingannevole, ma individuare i problemi nel codice ingannevole è pericoloso. (Sto menzionando questo perché un mio supervisore era appassionato di script Python da 500 righe non documentati - divertiti a eseguire il debug di quel pasticcio e ho visto molto quel modello, soprattutto da persone che non provengono da un ambiente IT)

2. Suddividi il codice in funzioni più piccole, che possono essere testate e valutate in punti più piccoli.

3. Cerca gli elementi collegati, ad esempio il numero di casi con condizione X è Y, quindi questa query DEVE restituire Y. Molto spesso questo è più complesso, ma fattibile.

4. Quando esegui lo script per la prima volta, testalo con un piccolo sottocampione e controlla attentamente se tutto è in ordine. Mentre mi piacciono i test unitari nell'IT, i bug negli script statistici sono spesso così pronunciati che sono facilmente visibili facendo un controllo accurato. Oppure sono errori metodici, che probabilmente non vengono mai rilevati dai test unitari.

Ciò dovrebbe essere sufficiente per garantire un lavoro pulito "una tantum". Ma per una serie temporale come sembra, aggiungerei che dovresti controllare valori fuori range, combinazioni impossibili ecc. Per me, la maggior parte degli script che hanno raggiunto il punto 4 sono probabilmente privi di bug - e rimarranno così a meno che qualcosa cambia. E molto spesso, i dati stanno cambiando - e questo è qualcosa che dovrebbe essere controllato per ogni corsa. Scrivere codice per questo può richiedere tempo e fastidioso, ma batte errori sottili dovuti a errori di immissione dei dati.