Як налагодити аналіз даних?

Я зіткнувся з наступною проблемою, яку я повторюю досить типово.

У мене є кілька великих даних, скажімо, кілька мільйонів рядків. Я виконую на ньому нетривіальний аналіз, наприклад, SQL-запит, що складається з декількох підзапитів. Я отримую певний результат, констатуючи, наприклад, що властивість X з часом збільшується.

Зараз є дві можливі речі, які можуть призвести до цього:

1. X дійсно збільшується з часом
2. У мене помилка в аналізі

Як я можу перевірити, що відбулося перше, а не друге? Покроковий налагоджувач, навіть якщо такий існує, не допоможе, оскільки проміжні результати все ще можуть складатися з мільйонів рядків.

Єдине, про що я міг придумати, - це якось генерувати невеликий синтетичний набір даних із властивістю, яку я хочу перевірити та запустити аналіз на ньому як одиничний тест. Чи є інструменти для цього? Особливо, але не обмежуючись цим, SQL.

Ось пропозиція:

• Зашифруйте свій аналіз таким чином, щоб його можна було виконати на підпробах.
• Зашифруйте додаткову процедуру, яка може вибирати вибірки, або випадковим чином, або часом, або за регіонами, або ... Це може залежати від домену. Сюди потрапляють ваші знання.
• Об'єднайте ці два і подивіться, чи є результати стабільними для підпроб.

Це те, що я зазвичай роблю - беручи до уваги найважливіші змінні (грунтуючись на розумінні та гіпотезі вашого бізнесу - ви завжди можете переглянути їх згодом), згрупуйте ці атрибути, щоб зменшити кількість рядків, які потім можна імпортувати у Pivot. Ви повинні включити суму та кількість відповідних показників у кожному рядку.

Переконайтеся, що на попередньому кроці ви не ставите жодних фільтрів. Після того, як ви отримаєте цілі дані на підсумковому рівні, ви можете грати навколо зведених таблиць і бачити, що все змінюється / збільшується чи зменшується.

Якщо дані занадто великі, щоб їх можна було узагальнити навіть за важливими параметрами, вам потрібно розділити їх на 3 - 4 підмножини, а потім зробити це ще раз.

Сподіваюся, це допомагає.

Спочатку потрібно переконатися, що ваша реалізація алгоритму є точною. Для цього використовуйте невеликий зразок даних і перевірте, чи правильний результат. На цьому етапі вибірці не потрібно репрезентувати населення.

Після того, як реалізація буде перевірена, вам потрібно переконатися, що існує значна залежність між змінними, які ви намагаєтеся передбачити. Для цього визначте нульову гіпотезу та спробуйте відхилити нульову гіпотезу зі значним рівнем довіри. ( тестування гіпотез для лінійної регресії )

Можуть існувати одиничні тестові рамки для вашої дистрибуції SQL. Але використання мови програмування на зразок R буде легше реалізувати.

Мені подобається стратегія в кілька кроків:

1. Написати чистий простий для розуміння код, на відміну від коротко складного коду. Я знаю статистиків, як хитрий код, але виявити проблеми в хитрому коді небезпечно. (Я згадую про це, тому що мій керівник захоплювався недокументованими сценаріями python на 500 рядків - веселіться налагодженням цього безладу, і я часто бачив цю схему, особливо від людей, які не з інформаційних технологій)

2. Розбийте свій код на більш дрібні функції, які можна перевірити та оцінити на менших рівнях.

3. Шукайте підключені елементи, наприклад, кількість випадків із умовою X дорівнює Y, тому цей запит ОБОВ'ЯЗКОВО повертає Y. Найчастіше це складніший, але виконаний.

4. Коли ви запускаєте свій сценарій вперше, протестуйте його за допомогою невеликої підпробовки і уважно перевірте, чи все в порядку. Хоча мені подобаються одиничні тести в ІТ, помилки в скриптах статистики часто настільки виражені, що їх легко помітити, ретельно перевіряючи. Або це методичні помилки, які, ймовірно, ніколи не потрапляють в одиничні тести.

Цього має бути достатньо для забезпечення чистої "разової" роботи. Але для часового ряду, як вам здається, я додам, що вам слід перевірити наявність значень поза діапазону, неможливих комбінацій тощо. Для мене більшість сценаріїв, які досягли кроку 4, ймовірно, не мають помилок - і вони залишаться таким, якщо тільки щось змінюється. І найчастіше, дані змінюються - і це те, що слід перевіряти для кожного запуску. Написання коду для цього може забирати багато часу і дратувати, але воно перемагає тонкі помилки через помилки введення даних.