Comment déboguer l'analyse des données?

J'ai rencontré le problème suivant, que je reconnais est plutôt typique.

J'ai quelques grandes données, disons, quelques millions de lignes. J'exécute une analyse non triviale dessus, par exemple une requête SQL composée de plusieurs sous-requêtes. J'obtiens un résultat, déclarant, par exemple, que la propriété X augmente avec le temps.

Maintenant, il y a deux choses possibles qui pourraient mener à cela:

1. X augmente en effet avec le temps
2. J'ai un bug dans mon analyse

Comment puis-je tester que le premier s'est produit, plutôt que le second? Un débogueur pas à pas, même s'il existe, n'aidera pas, car les résultats intermédiaires peuvent toujours se composer de millions de lignes.

La seule chose à laquelle je pouvais penser était de générer en quelque sorte un petit ensemble de données synthétiques avec la propriété que je veux tester et d'exécuter l'analyse sur celui-ci comme un test unitaire. Existe-t-il des outils pour ce faire? Particulièrement, mais sans s'y limiter, SQL.

Voici une suggestion:

• Codez votre analyse de manière à pouvoir l'exécuter sur des sous-échantillons.
• Codez une routine complémentaire qui peut échantillonner, soit au hasard, soit par le temps, soit par région, ou ... Cela peut être spécifique au domaine. C'est là que vos connaissances entrent.
• Combinez les deux et voyez si les résultats sont stables entre les sous-échantillons.

C'est ce que je fais normalement - reprendre les variables les plus importantes (en fonction de votre compréhension et de votre hypothèse - vous pouvez toujours le réviser plus tard), regrouper par ces attributs pour réduire le nombre de lignes, qui peuvent ensuite être importées dans un pivot. Vous devez inclure la somme et le nombre des mesures pertinentes sur chaque ligne.

Assurez-vous de ne pas avoir mis de filtres à l'étape précédente. Une fois que vous avez des données entières à un niveau résumé, vous pouvez jouer dans les tableaux croisés dynamiques et voir ce que les choses changent / augmentent ou diminuent.

Si les données sont trop volumineuses pour être résumées même sur des paramètres importants, vous devez les partitionner en 3 à 4 sous-ensembles, puis recommencer.

J'espère que cela aide.

Vous devez d'abord vérifier que votre implémentation de l'algorithme est exacte. Pour cela, utilisez un petit échantillon de données et vérifiez si le résultat est correct. À ce stade, l'échantillon n'a pas besoin d'être représentatif de la population.

Une fois l'implémentation vérifiée, vous devez vérifier qu'il existe une relation significative entre les variables que vous essayez de prédire. Pour ce faire, définissez l'hypothèse nulle et essayez de rejeter l'hypothèse nulle avec un niveau de confiance significatif. ( test d'hypothèse pour la régression linéaire )

Il peut exister des frameworks de tests unitaires pour votre distribution SQL. Mais l'utilisation d'un langage de programmation comme R sera plus facile à implémenter.

J'aime une stratégie en plusieurs étapes:

1. Écrivez du code propre et facile à comprendre, par opposition au code court et délicat. Je connais les statisticiens comme le code délicat, mais repérer les problèmes dans le code délicat est dangereux. (Je mentionne cela parce qu'un de mes superviseurs aimait les scripts python de 500 lignes sans papiers - amusez-vous à déboguer ce gâchis et j'ai beaucoup vu ce modèle, en particulier de personnes qui ne sont pas issues de l'informatique)

2. Décomposez votre code en fonctions plus petites, qui peuvent être testées et évaluées dans des stes plus petites.

3. Recherchez les éléments connectés, par exemple le nombre de cas avec la condition X est Y - donc cette requête DOIT retourner Y. Le plus souvent, c'est plus complexe, mais faisable.

4. Lorsque vous exécutez votre script la première fois, testez-le avec un petit sous-échantillon et vérifiez soigneusement si tout est en ordre. Bien que j'aime les tests unitaires en informatique, les bogues dans les scripts de statistiques sont souvent si prononcés qu'ils sont facilement visibles en vérifiant soigneusement. Ou ce sont des erreurs méthodiques, qui ne sont probablement jamais détectées par les tests unitaires.

Cela devrait suffire pour assurer un travail "ponctuel" propre. Mais pour une série chronologique comme vous semblez l'avoir, j'ajouterais que vous devriez vérifier les valeurs hors plage, les combinaisons impossibles, etc. Pour moi, la plupart des scripts qui ont atteint l'étape 4 sont probablement sans bogue - et ils le resteront à moins que quelque chose change. Et le plus souvent, les données changent - et c'est quelque chose qui doit être vérifié pour chaque exécution. Écrire du code pour cela peut être long et ennuyeux, mais il bat les erreurs subtiles dues aux erreurs de saisie de données.