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

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

Оплачивает человечек аккуратненько коммуналку и смело гуляет, пинает поребрик. На кафешку денег уже нет.

Попробуйте polars вместо pandas. Увидите существенный рост скорости. И не придётся шаманить с СУБД.

но "шаманить с СУБД" тут более лучшая практика, при условии, что это не разовое исследование, а периодическое...
но polars хорош, вопросов нет.
Кстати, учитывая то, насколько все хорошо с табличками в R, даже интересно, было бы на нем быстрее или нет.

Объединять df надо только раз, списком. Метод append устарел, он копирует объекты, оттого и тормоза.

Сейчас действительно можно пробовать Polars. Но весьма быстры также FireDucks (и DuckDB вместо SQLite).

Впрочем, новая Pandas с движком Apache Arrow и своевременным преобразованием в нужные типы - и так быстра, не уступая Polars более чем в 4 раза. А это в наше время уже не разница.

Если нужно обрабатывать большие объемы данных, и нравится Python, я бы посмотрел на Apache Spark. Начать будет легко после pandas, а быстродействие в ворочании террабайтами будет ограничено только тем, сколько ресурсов вам не жалко для этого предоставить.

я прям ждал того, кто придет в комментарии со спарком. Не, базару ноль, мощь и вещь, но все описываемое в статье - влезает в память ноута. И спарк тут - оверкилл и попытка "надуть щеки". Если скулайт справляется, то на кой хрен монструозить что-то, что никогда не будет использовано даже на 10%?

и да "начать будет легко после pandas". Хм. Спарк, скорее, на с sql похоже, нежели на пандас....

Если уже написана логика на панде, проще всего будет ее так и перенести на спарк - для начала его вполне можно использовать без SQL, датафреймы у него практически те же. А SQL будет бонусом.

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

>> чего же тогда он толчет воду в ступе

В статье автор перешел от медленных аппендов (каждый раз создаётся копия df, ну такое себе) к быстрому встроенную скулайту. Просто взял и по шагам показал. Кажется, в этом идея была.

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

Мой адрес в попапе объекта не правильный. Соответственно и информация о кол-ве квартир. 11 парадных по 36 квартир. см Славы 64 у вас Славы 8.

Можно обойтись только средствами Pandas, если после извлечение данных сохранить маленькие датафреймы в файлы формата parquet. А потом загрузить все parquet файлы разом с диска в один DataFrame указав пандасу путь к папке с паркетами.

Да зачем вообще писать на диск? Это же постоянный доступ к HDD с соответствующим замедлением. Надо все максимально в раме делать. Только не так, как показано у автора со "словарем-накопителем", а хотя бы тупо сохранять в список все датафреймы, а потом один раз все склеить тем же concat().

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

Публикации