Что может пойти не так еще до этапа анализа данных

 Сегодня поделюсь небольшим эпизодом из работы аналитика. Возможно вы слышали, такое выражение, которое часто встречается в мире аналитики: “Garbage in - Garbage Out”. Если у тебя мусор на входе, то на выходе тоже получишь мусор.

Поэтому, чтобы результаты анализа данных не оказались мусором, аналитикам приходится тщательно подготавливать данные еще до самого анализа. Данные чистят, приводят к единому формату, избавляются от пустых (NaN) значений и т.д. Библиотека Pandas позволяет производить широчайший диапазон манипуляций с датафреймом на стадии пред-анализа. А что, если исходные данные таковы, что они даже не загружаются в датафрейм? Обо этом сегодняшний мини-кейс.

Итак, мы имеем датасет с информацией о ценах и скидках на товары южно-азиатского онлайн-ритейлера Lazada. Посмотрим как он выглядит в редакторе Notepad++

Датасет небольшой, всего 985 строк.

Пробуем загрузить данные в Pandas.

Упс. Интерпретатор Python споткнулся и отказывается загружать данные.

 Смотрим, на сообщение об ошибке: “ожидалось увидеть 16 полей в строке, а увидели 17”. Из этого сообщения понимаем, что у нас “кривой” датасет, в котором количество полей в разных строках разное. Мы пока не знаем сколько таких строк, но как минимум одна есть. Вы не можете загрузить такой датасет в Pandas и приступить к анализу, если структура данных не имеет табличную форму, т.е. количество столбцов  в каждой строке должно быть одинаковым.

Что же делать? В этом посте я показывал 2 способа загрузки данных.

Вот здесь то нам и пригодится первый способ, который работает с датасетом построчно. Воспользуемся им и загрузим данные в список.

 Отлично! Данные загрузились. Теперь давайте посмотрим, что не так с нашими строками и напишем небольшой скриптик, который выведет нам информацию о том, какова длина каждой строки.

Итак. мы видим, что встречаются строки длиной в 16, 11 и 17 столбцов. Нас интересуют строки которые больше 16, именно такие строки не дают загрузить данные в датафрейм. Информацию о них скрипт занес в с словарь wrong.

Всего 19 таких строк и мы видим, что попадаются значения даже в 20 столбцов! Давайте посмотрим на 63 строку и сравним ее с 64.

Мы видим, что часть данных в 63 строке разделены более детально. В отдельные столбцы занесена информация об оперативной памяти, жестком диске, процессоре и операционной системе, тогда как в 64 строке это все содержится в одном столбце.

Здесь нам надо вспомнить, про структуру файла формата CSV. CSV - это сокращение от Comma Separated Values, т.е. значения разделенные запятыми. Каждый столбец данных отделяется от другого запятой (к слову сказать, разделителями в CSV могут быть и точка с запятой и пробелы и апострофы, но это не наш случай)

Делаем предположение, что в кривых строчках просто оказалось больше запятых чем нужно, что и приводит к неверному определению столбцов.

Откроем опять наш датасет в Notepad++ и посмотри на сами строчки. Из-за того, что нумерция индексов  в Pyrhon начинатся с 0, а также учитывая строку заголовка, нумерция строк в Notepad++ будет на 2 шага больше.

На скриншоте вторая двойная кавычка закрылась раньше, чем закончилась строка с конфигурацией модели компьютера, поэтому все последующие запятые стали восприниматься интерпретатором, как следующие по порядку столбцы.

Выход простой - обнаружить все такие вхождения и убрать закрывающую двойную кавычку в середине строки. Такую операцию мы проделываем с каждой из найденных строк и после сохранения изменений запустим скрипт проверки заново.

Пробуем загрузить данные в датафрейм.

Все получилось!

Резюме

Этот кейс достаточно простой, но на самом деле могут встречаться и более серьезные искажения в данных, где ручной правкой не обойтись и надо будет дополнительно писать скрипты для трансформации исходных данных, прежде чем заняться самим анализом. Специалисты-аналитики оценивают, что в среднем на этап очистки и трансформации данных может уходить от 50 до 70 процентов рабочего времени аналитика.