Роман с Data Science. Как монетизировать большие данные

На каждом из этапов желательно проводить отдельную проверку. Получение данных – часто это код, например SQL, – проверить относительно легко: посмотреть, нужные ли данные были использованы. Кстати, при планировании очень полезно обсуждать, каким образом будет решаться задача, на что обратить внимание и какие данные могут понадобиться. При этом взять за основу можно похожие задачи из прошлого опыта. В процессе проверки будет легче соотнести решение задачи с тем вариантом, о котором договорились на планировании. Советую ограничивать время на такие задачи, иначе можно искать инсайт до бесконечности. Очистку данных и анализ проверить сложнее, но если там есть код, это упрощает дело.

Есть одна проблема с блокнотами (jupyter notebooks) – скрытые ошибки. В блокнотах выполняются разовые задачи (ad-hoc), и поэтому аналитики пренебрегают стандартами разработки – инспекциями кода и тестами. Как с этим бороться? Есть несколько способов проверить код и выводы.

Во-первых, проверяющий может очень внимательно просмотреть все решение на предмет ошибок. Это трудоемко, ведь по сути ему придется построить решение чуть ли не с нуля в своей голове. Во-вторых, можно воспользоваться другими источниками данных, которые хотя бы косвенно могли бы подтвердить вывод. В-третьих, можно последовать совету Кэсси Козырьков, директора по принятию решений в Google, из ее статьи «Самая мощная идея в анализе данных» [26]: сделать случайное разделение данных на два датасета (набора данных). По первому набору аналитик будет искать причину, а по второму проверяющий проверит выводы аналитика. Такой подход всегда используется в машинном обучении и называется валидацией (validation).

Хочу сделать важное замечание относительно решений, которые не используют код. В чем сложность их проверки? Представьте, что вы работаете в Excel и уже получили данные в виде файла. Вы должны загрузить его в Excel, проверить, почистить, написать формулы, построить таблицу или сводную таблицу (что удобнее для проверки). Теперь поставьте себя на место проверяющего. Часть операций в Excel делается мышью, данные можно копировать и вставлять блоками, протокола всех действий нигде нет. Чтобы посмотреть формулу – нужно кликнуть, а если таких формул много? И вы их «протягивали», а если ошиблись, исправили и не обновили все формулы? Чуть лучше с интерфейсами, где блоки выстраиваются графически и соединяются стрелками. Приходится щелкать по каждому блоку, проверять, все ли корректно. С кодом проверить все намного проще – все операции с данными написаны текстом! Не нужно никуда щелкать, все видно сразу. Еще один плюс кода – можно очень быстро пересчитать задачу – просто запустить код. В безкодовых решениях аналитику придется писать протокол – что и как он делал по шагам. Это облегчит проверку и даст возможность безболезненно повторить задачу в будущем. Конечно, Excel и другие визуальные инструменты очень ускоряют работу, я сам пользуюсь ими и не отговариваю вас. Моя задача обозначить плюсы и минусы этих подходов – что вам ближе, решать только вам.

Эти нюансы я понял, только когда стал работать в Retail Rocket, так как требования к качеству были значительно выше, чем на моих предыдущих местах работы. Раньше я проверял только результат, а теперь – все решение целиком.

Как тестировать и выкладывать изменения в рабочую систему

Если задача вносит изменения в рабочую систему, то следующий шаг проверки – выкладка (deploy) изменений. Здесь все выглядит стандартно для разработки, и вы можете использовать практики, принятые у ваших разработчиков. В аналитике Retail Rocket мы использовали CI/CD на основе GitLab, когда все изменения выкладываются нажатием одной кнопки. Мы думали, кто это должен делать, и после различных экспериментов сошлись на том, что это должен делать исполнитель задачи. Как таковых инженеров тестирования у нас нет, поэтому исполнитель переводит задачу в статус тестирования (Testing). Далее делает выкладку, следит за тем, чтобы тесты были выполнены и изменения отразились на работе системы. Например, проверяет, что нужные отчеты работают и предоставляют информацию в требуемом виде. Цели выкладки: отразить изменения в рабочей системе, проверить, что все работает так, как этого требует задача.

Как защищать задачу перед инициатором