Como depurar a análise de dados?

Me deparei com o seguinte problema, que reconheço é bastante típico.

Eu tenho alguns dados grandes, digamos, alguns milhões de linhas. Eu executo algumas análises não triviais, por exemplo, uma consulta SQL que consiste em várias subconsultas. Recebo algum resultado, afirmando, por exemplo, que a propriedade X está aumentando com o tempo.

Agora, existem duas coisas possíveis que podem levar a isso:

1. X está realmente aumentando ao longo do tempo
2. Eu tenho um erro na minha análise

Como posso testar se o primeiro aconteceu, e não o segundo? Um depurador passo a passo, mesmo que exista, não ajudará, pois os resultados intermediários ainda podem consistir em milhões de linhas.

A única coisa em que pude pensar foi de alguma forma gerar um pequeno conjunto de dados sintéticos com a propriedade que eu quero testar e executar a análise nele como um teste de unidade. Existem ferramentas para fazer isso? Particularmente, mas não limitado a, SQL.

Aqui está uma sugestão:

• Codifique sua análise de forma que ela possa ser executada em subamostras.
• Codifique uma rotina complementar que pode amostrar aleatoriamente, ou por tempo, por região ou ... Isso pode ser específico do domínio. É aqui que o seu conhecimento entra.
• Combine os dois e veja se os resultados são estáveis ​​nas subamostras.

É o que eu normalmente faço - tomo as variáveis ​​mais importantes (com base no entendimento e na hipótese de negócios - você sempre pode revisá-las mais tarde), agrupe esses atributos para reduzir o número de linhas, que podem ser importadas para um Pivot. Você deve incluir a soma e a contagem das métricas relevantes em cada linha.

Certifique-se de não colocar nenhum filtro na etapa anterior. Depois de ter dados completos em um nível resumido, você pode brincar nas tabelas dinâmicas e ver o que as coisas estão mudando / aumentando ou diminuindo.

Se os dados forem grandes demais para serem resumidos, mesmo em parâmetros importantes, você precisará particioná-los em 3 - 4 subconjuntos e depois fazer isso novamente.

Espero que ajude.

Primeiro, você precisa verificar se sua implementação do algoritmo é precisa. Para isso, use uma pequena amostra de dados e verifique se o resultado está correto. Nesta fase, a amostra não precisa ser representativa da população.

Depois que a implementação é verificada, é necessário verificar se há um relacionamento significativo entre as variáveis ​​que você tenta prever. Para fazer isso, defina a hipótese nula e tente rejeitar a hipótese nula com um nível de confiança significativo. ( teste de hipótese para regressão linear )

Pode haver estruturas de teste de unidade para sua distribuição SQL. Mas usar uma linguagem de programação como R será mais fácil de implementar.

Eu gosto de uma estratégia de várias etapas:

1. Escreva um código limpo e fácil de entender, em vez de um código complicado. Conheço estatísticos como código complicado, mas detectar problemas em código complicado é perigoso. (Estou mencionando isso porque um supervisor meu gostava de scripts python de 500 linhas não documentados - divirta-se depurando essa bagunça e eu já vi muito esse padrão, especialmente de pessoas que não são de TI)

2. Divida seu código em funções menores, que podem ser testadas e avaliadas em stes menores.

3. Procure por elementos conectados, por exemplo, o número de casos com a condição X é Y - portanto, essa consulta DEVE retornar Y. Na maioria das vezes isso é mais complexo, mas factível.

4. Quando você estiver executando seu script pela primeira vez, teste-o com uma pequena subamostra e verifique cuidadosamente se está tudo em ordem. Embora eu goste de testes de unidade em TI, os erros nos scripts estatísticos costumam ser tão pronunciados que são facilmente visíveis, fazendo uma verificação cuidadosa. Ou são erros metódicos, que provavelmente nunca são detectados por testes de unidade.

Isso deve ser suficiente para garantir um trabalho "único" limpo. Mas, para uma série temporal como você parece, gostaria de acrescentar que você deve verificar valores fora do intervalo, combinações impossíveis etc. algo muda. E, na maioria das vezes, os dados estão mudando - e isso é algo que deve ser verificado a cada execução. Escrever código para isso pode ser demorado e irritante, mas supera erros sutis devido a erros de entrada de dados.