Polars 2.0 в первом релиз-кандидате переводит LazyFrame-запросы на streaming engine по умолчанию и обещает прирост скорости примерно до 5 раз. Для разработчиков и data engineering-команд это не просто приятный апгрейд: старые пайплайны могут начать возвращать строки в другом порядке, хотя данные внутри останутся формально корректными.
О предрелизе пишет The New Stack: главный выигрыш Polars 2.0 связан с тем, что вызов collect() для LazyFrame теперь по умолчанию уходит в потоковый движок. Раньше режим auto для lazy-запросов фактически выбирал in-memory engine, то есть запрос собирался в памяти. Новый вариант обрабатывает данные батчами, снижает риск упереться в RAM и лучше подходит для больших таблиц, где Python-инструменты обычно начинают грустить, а ноутбук — шуметь.
Polars — open source-библиотека для работы с табличными данными, которую часто рассматривают как более быструю альтернативу привычному pandas в задачах анализа, подготовки датасетов и ETL. Ее используют разработчики, аналитики и data engineers, которым нужно чистить, объединять и агрегировать большие наборы данных без постоянного переписывания всего на Spark. Поэтому смена дефолтного движка в major-релизе бьет ровно по рабочим сценариям: join, group_by, unpivot, выгрузки в файлы, регрессионные тесты, отчеты.
Скорость — понятная приманка. Команда Polars ожидает, что streaming engine в сумме будет примерно в 5 раз быстрее. Формулировка важна: это не гарантия для каждого запроса и не независимый бенчмарк на вашей инфраструктуре. На одних пайплайнах выигрыш даст обработка батчами и меньший расход памяти, на других результат будет зависеть от операций, формата входных данных и железа. Но сама идея здравая: если не держать весь датасет и промежуточные результаты в памяти, многие тяжелые lazy-запросы становятся заметно практичнее.
Цена апгрейда — порядок строк. Потоковый движок не гарантирует его для операций, где порядок не является частью логического результата: например, для join, group_by и unpivot. Это выглядит как мелочь ровно до момента, когда downstream-код сравнивает CSV построчно, snapshot-тест ждет прежнюю раскладку, BI-слой берет первые N строк, а ML-пайплайн молча сопоставляет массивы по позиции. Самое неприятное здесь не падение с ошибкой, а тихое изменение поведения.
Polars предлагает два основных способа снизить риск. Первый — явно сортировать результат там, где порядок действительно важен. Второй — включать сохранение порядка через maintain_order в операциях, которые это поддерживают: например, для left join можно запросить сохранение порядка левой таблицы. Если команда хочет отложить миграцию поведения, можно оставить in-memory engine как дефолт через настройку engine affinity или выбирать старый движок на уровне конкретного запроса. Но это уже сознательный компромисс: меньше сюрпризов сейчас, меньше выгоды от нового исполнения.
Изменение хорошо показывает, куда движется класс DataFrame-библиотек. Пользователи хотят скорость и работу с данными крупнее доступной памяти, но при этом годами пишут код, который опирается на неявные свойства старого исполнения. Порядок строк — классический пример такого контракта-призрака: в документации его может не быть, но в продакшене он давно стал частью поведения. Major-релиз как раз и нужен, чтобы такие дефолты менять без притворства, будто ничего не произошло.
Для команд на Polars практический план простой: не обновлять production-пайплайны на релиз-кандидат вслепую, прогнать тесты на данных, где порядок строк имеет значение, и отдельно проверить join, group_by, unpivot и SQL-запросы, которые материализуются через lazy API. Там, где порядок нужен бизнес-логике, его лучше зафиксировать явно. Там, где он был случайным удобством, стоит переписать проверки так, чтобы они сравнивали содержимое, а не историческую раскладку строк.
Polars 2.0 выглядит как редкий major-релиз без парада новых кнопок: главная новость спрятана в дефолтах. Если финальная версия выйдет с тем же поведением, выиграют те команды, которые заранее отделят настоящие требования к данным от привычек старого движка. Остальным придется объяснять, почему отчет не сломался, а всего лишь стал другим.