Как стать автором
Обновить

Комментарии 13

Я бы не стал просто переводить отрицательные числа в положительные. Сначала хорошо бы сверить данные в этих строках с другими источниками. Возможно, там проблема не только в лишнем минусе. Может эти строки лучше вообще отбросить. Или обработать как-то по-другому. Как знать.

Спасибо! Обдумаю это.

Я думая, там вообще может не быть проблемы. В данных о продажах отрицательные значения могут говорить о возврате товара.

Или так, например. В любом случае это повод сверить данные и проконсультироваться с кем-то, кто в курсе, как эти файлы заполняются и что значат эти минусы )

Отрицательные колво/цена/сумма в бухучете - это наверняка не ошибки ввода, а исправление ошибок (возможно методом "красного сторно" или исправительной проводкой, в т.ч. частичной, что часто бывает при пересортице).

Их нельзя удалять или лишать знака, чтобы не исказить итоги. Наиболее правильно - сгруппировать строки по всем аналитическим признакам, кроме даты. Кол-во строк в df уменьшится, останутся только положительные значения.

Если же останутся "минусы" - они будут постоянно мешать строить графики, смотреть статистики, приводить к ошибкам при расчетах std, средних итд.

Кстати да, про сторно и всякое такое не надо забывать, всё может быть.

Именно для ручной очистки данных я привык OpenRefine использовать, инструмент конкретно под это заточен, и визуально удобнее... но Ваш подход тоже надо взять на вооружение, особенно если один раз вручную выработанную последовательность преобразований надо потом многократно применять ко всем данным из того же источника.

Ну и главный недостаток, что у Pandas, что у OpenRefine - очень сильно кушают оперативку :( Были задачи, при которых 192 Гб не хватало (а больше у меня нет). Тут уже рекомендуют смотреть в сторону Polars и Spark, как следующий раз столкнусь с десятками Гб, прилетевших на анализ, - придётся осваивать :)

192 Гб не хватало

Почему бы не разделить на части? Или построчно?

Или выкинуть не нужные текстовые колонки, наверняка там есть колонки, которые можно обрабатывать не сразу все одновременно. Или превратить тексты в вектора и опять же сэкономить память.

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

.astype('category') уменьшит в 8-10X размер df в RAM и почти во столько же ускорит отборы/сортировки. В 32 Гб RAM поместится df на 100 млн. строк * 100 столбцов, это очень большая БД, скажем, примерно весь бухучет холдинга из Top-100 РФ за период 10 лет. В бухучете много повторяющихся сущностей, которые очень хорошо факторизуются (слова - в числа, т.е. коды).

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

Чтобы определять что является ошибкой надо либо быть экспертом в домене, либо иметь указание в ТЗ. А при описанном подходе весьма вероятно не исключить, а приумножить ошибки.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории