¿Cómo depurar el análisis de datos?

Me he encontrado con el siguiente problema, que reconozco es bastante típico.

Tengo algunos datos grandes, por ejemplo, unos pocos millones de filas. Ejecuto algunos análisis no triviales, por ejemplo, una consulta SQL que consta de varias subconsultas. Obtengo algún resultado, indicando, por ejemplo, que la propiedad X aumenta con el tiempo.

Ahora, hay dos cosas posibles que podrían conducir a eso:

1. De hecho, X aumenta con el tiempo
2. Tengo un error en mi análisis.

¿Cómo puedo comprobar que sucedió lo primero, en lugar de lo segundo? Un depurador por etapas, incluso si existe, no ayudará, ya que los resultados intermedios pueden consistir en millones de líneas.

Lo único que se me ocurrió fue generar de alguna manera un pequeño conjunto de datos sintéticos con la propiedad que quiero probar y ejecutar el análisis en él como una prueba unitaria. ¿Hay herramientas para hacer esto? Particularmente, pero no limitado a, SQL.

Aquí hay una sugerencia:

• Codifique su análisis de tal manera que pueda ejecutarse en submuestras.
• Codifique una rutina complementaria que pueda muestrear, ya sea al azar, por tiempo, por región o ... Esto puede ser específico del dominio. Aquí es donde entra tu conocimiento.
• Combine los dos y vea si los resultados son estables en las submuestras.

Esto es lo que normalmente hago: tomar las variables más importantes (basar la comprensión y la hipótesis de su negocio; siempre puede revisarlas más adelante), agruparlas según estos atributos para reducir el número de filas, que luego pueden importarse a un Pivot. Debe incluir la suma y el recuento de las métricas relevantes en cada fila.

Asegúrese de no poner ningún filtro en el paso anterior. Una vez que tenga datos completos en un nivel resumido, puede jugar en las tablas dinámicas y ver qué cosas están cambiando / aumentando o disminuyendo.

Si los datos son demasiado grandes para resumirse incluso en parámetros importantes, debe dividirlos en 3 - 4 subconjuntos y luego volver a hacerlo.

Espero eso ayude.

Primero debe verificar que su implementación del algoritmo sea precisa. Para eso, use una pequeña muestra de datos y verifique si el resultado es correcto. En esta etapa, la muestra no necesita ser representativa de la población.

Una vez que se verifica la implementación, debe verificar que existe una relación significativa entre las variables que intenta predecir. Para hacerlo, defina la hipótesis nula e intente rechazar la hipótesis nula con un nivel de confianza significativo. ( prueba de hipótesis para regresión lineal )

Puede haber marcos de prueba de unidad para su distribución de SQL. Pero usar un lenguaje de programación como R será más fácil de implementar.

Me gusta una estrategia de pasos múltiples:

1. Escriba código limpio y fácil de entender, en lugar de código corto y complicado. Sé que a los estadísticos les gusta el código complicado, pero detectar problemas en el código complicado es peligroso. (Menciono esto porque un supervisor mío era aficionado a las secuencias de comandos de python indocumentadas de 500 líneas: diviértete depurando ese desastre y he visto mucho ese patrón, especialmente de personas que no son de un entorno de TI)

2. Descomponga su código en funciones más pequeñas, que se pueden probar y evaluar en estados más pequeños.

3. Busque elementos conectados, por ejemplo, el número de casos con la condición X es Y, por lo que esta consulta DEBE devolver Y. La mayoría de las veces es más complejo, pero factible.

4. Cuando ejecute su script por primera vez, pruébelo con una pequeña submuestra y verifique cuidadosamente si todo está en orden. Si bien me gustan las pruebas unitarias en TI, los errores en los scripts de estadísticas a menudo son tan pronunciados que son fácilmente visibles haciendo una verificación cuidadosa. O son errores metódicos, que probablemente nunca sean detectados por las pruebas unitarias.

Eso debería ser suficiente para garantizar un trabajo limpio "único". Pero para una serie de tiempo como parece, agregaría que debe verificar los valores fuera de rango, combinaciones imposibles, etc. Algo cambia. Y con mayor frecuencia, los datos están cambiando, y eso es algo que debe verificarse en cada ejecución. Escribir código para eso puede llevar mucho tiempo y ser molesto, pero supera los errores sutiles debido a errores de entrada de datos.