Jak debugować analizę danych?

Natknąłem się na następujący problem, który uznaję za raczej typowy.

Mam kilka dużych danych, powiedzmy, kilka milionów wierszy. Przeprowadzam na nim kilka nietrywialnych analiz, np. Zapytanie SQL składające się z kilku pod-zapytań. Otrzymuję pewien wynik, stwierdzając na przykład, że właściwość X rośnie z czasem.

Są dwie możliwe rzeczy, które mogą do tego doprowadzić:

1. X rzeczywiście rośnie z czasem
2. Mam błąd w mojej analizie

Jak mogę sprawdzić, czy zdarzyło się pierwsze, a nie drugie? Debuger krokowy, nawet jeśli taki istnieje, nie pomoże, ponieważ wyniki pośrednie mogą składać się z milionów linii.

Jedyne, co mogłem wymyślić, to jakoś wygenerować mały, syntetyczny zestaw danych z właściwością, którą chcę przetestować i uruchomić na nim analizę jako test jednostkowy. Czy są na to narzędzia? W szczególności, ale nie wyłącznie, SQL.

Oto sugestia:

• Zakoduj swoją analizę w taki sposób, aby można ją było uruchomić na podpróbkach.
• Kod uzupełniającej się procedury, która może próbkować, losowo, według czasu, według regionu lub ... Może to być specyficzne dla domeny. Tutaj wkracza Twoja wiedza.
• Połącz oba i sprawdź, czy wyniki są stabilne w podpróbkach.

Tak zwykle robię - przejmuję najważniejsze zmienne (opierając się na zrozumieniu i hipotezie firmy - zawsze możesz to później zmienić), grupując według tych atrybutów, aby zmniejszyć liczbę wierszy, które można następnie zaimportować do osi przestawnej. W każdym wierszu należy podać sumę i liczbę odpowiednich danych.

Upewnij się, że nie wstawiłeś żadnych filtrów w poprzednim kroku. Po zebraniu wszystkich danych na podsumowanym poziomie możesz bawić się w tabelach przestawnych i zobaczyć, co się zmienia / zwiększa lub zmniejsza.

Jeśli dane są zbyt duże, aby można je było streścić nawet przy ważnych parametrach, musisz podzielić je na 3–4 podzbiory, a następnie zrobić to ponownie.

Mam nadzieję, że to pomoże.

Najpierw musisz sprawdzić, czy implementacja algorytmu jest poprawna. W tym celu użyj małej próbki danych i sprawdź, czy wynik jest poprawny. Na tym etapie próbka nie musi być reprezentatywna dla populacji.

Po zweryfikowaniu implementacji należy sprawdzić, czy istnieje znaczący związek między zmiennymi, które próbujesz przewidzieć. Aby to zrobić, zdefiniuj hipotezę zerową i spróbuj odrzucić hipotezę zerową ze znacznym poziomem ufności. ( testowanie hipotez regresji liniowej )

Mogą istnieć struktury testów jednostkowych dla Twojej dystrybucji SQL. Ale użycie języka programowania, takiego jak R, będzie łatwiejsze do wdrożenia.

Lubię strategię wielostopniową:

1. Napisz czysty, łatwy do zrozumienia kod, w przeciwieństwie do kodu trudnego. Wiem, że statystycy lubią trudny kod, ale wykrywanie problemów w trudnym kodzie jest niebezpieczne. (Wspominam o tym, ponieważ mój przełożony lubił nieudokumentowane 500 wierszy skryptu pytona - baw się dobrze przy debugowaniu tego bałaganu i często go widziałem, szczególnie od osób, które nie pochodzą z branży IT)

2. Podziel kod na mniejsze funkcje, które można testować i oceniać w mniejszych rozmiarach.

3. Poszukaj połączonych elementów, np. Liczba obserwacji z warunkiem X wynosi Y - więc to zapytanie MUSI zwrócić Y. Najczęściej jest to bardziej złożone, ale wykonalne.

4. Kiedy uruchamiasz skrypt po raz pierwszy, przetestuj go małą próbką i dokładnie sprawdź, czy wszystko jest w porządku. Podczas gdy lubię testy jednostkowe w IT, błędy w skryptach statystycznych są często tak wyraźne, że są dobrze widoczne podczas dokładnej kontroli. Lub są to błędy metodyczne, które prawdopodobnie nigdy nie są wychwytywane przez testy jednostkowe.

To powinno wystarczyć, aby zapewnić czystą, jednorazową pracę. Ale dla szeregów czasowych, jak się wydaje, dodam, że powinieneś sprawdzić wartości poza zakresem, niemożliwe kombinacje itp. Dla mnie większość skryptów, które osiągnęły krok 4, są prawdopodobnie wolne od błędów - i tak pozostaną, chyba że coś się zmienia. I najczęściej dane się zmieniają - i to jest coś, co należy sprawdzić przy każdym uruchomieniu. Pisanie tego kodu może być czasochłonne i irytujące, ale pokonuje subtelne błędy z powodu błędów wprowadzania danych.