Polars 2.0 RC, LazyFrame 기본 엔진을 스트리밍으로 바꾸고 행 순서 보장을 선택 사항으로 전환

Polars 2.0 첫 릴리스 후보를 공개했으며, 정식 2.0은 수주 내 배포 예정이고 전체 마이그레이션 가이드를 제공함
모든 LazyFrame collect()가 기본적으로 스트리밍 엔진을 사용하며, Polars는 대부분 쿼리에서 메모리 사용량과 성능이 크게 개선되고 집계 기준 최대 5배 빨라질 것으로 예상함
스트리밍 기본값에서는 join, group_by, unpivot 등의 행 순서가 기본 보장되지 않으며, 필요한 쿼리는 maintain_order=True 또는 조인별 순서 옵션을 지정해야 함
기존 동작이 필요한 경우 pl.Config.set_engine_affinity("in-memory")로 프로세스 전체 기본 엔진을 바꾸거나 collect(engine="in-memory")를 쿼리별로 지정 가능함
2.0은 is_in의 손실형 타입 변환을 오류로 처리하고, 높이가 다른 데이터프레임의 가로 결합도 기본적으로 ShapeError를 내도록 바꿔 묵시적 null 채우기를 막음

Hacker News opinions

Polars가 2.0에서 화려한 기능 대신 과거 설계를 걷어내려는 건 좋게 봄. 안정성을 중시해서 처음 도입했는데, 시맨틱 버전을 진지하게 지키는 태도도 이유였음.

다만 Polars는 마이너 버전인 1.44에서 1.45로 갈 때도 deprecation, 제거, 변경이 잦아서 매번 릴리스 노트를 읽게 됨.

메이저 버전은 원래 호환성을 깨는 변경을 뜻하는 거 아닌가? 새 기능보다 deprecated cruft 제거가 메이저 버전의 이유라는 말은 이상하지 않음.

정식 출시를 몇 주 뒤에 한다는 문구를 보면 바로 흥미가 식음.

나는 큰 프로젝트가 RC 기간을 두는 편이 좋음. Elixir용 Polars 래퍼인 Explorer를 쓰는데, 래퍼와 대규모 사용자가 미리 테스트할 시간이 생김.

회사에서 Pandas 대신 Polars를 쓰라고 꽤 권했음. 지금도 Polars를 계속 씀.

Pandas와 Polars 문법은 둘 다 별로라서 SQL이 훨씬 읽기 좋게 느껴짐.

동료 권유로 Pandas에서 Polars로 옮겼고 만족함. Pandas API는 더 불편하고 느리다고 봄.

가이드에서 차이점을 읽어도 가벼운 Pandas 사용자 입장에서는 Polars가 왜 명백히 더 나은지 잘 모르겠음.

스트리밍 엔진을 기본으로 하면 배치 처리보다 병렬화가 어려워 느릴 것 같았음. 내가 Polars의 자동 병렬화를 과대평가한 건지 궁금함.

여기서 streaming은 끝없는 입력을 처리하는 온라인 스트리밍 뜻이 아님. 계산 그래프 노드가 캐시 크기 배치인 morsel을 주고받아 불필요하게 전체 데이터를 메모리에 올리지 않는 실행 모델이고, 지원하지 않는 연산은 기존 in-memory 엔진으로 폴백함.

과학 계산 파이프라인에서는 비결정적 동작이 버그 원인인데, maintain_order=False 기본값은 걱정됨. 사용자가 API 내부 동작을 기억해야 하고 정답을 미리 모르는 분석에서는 오류가 조용히 지나갈 수 있음.

SQL도 원하는 순서는 쿼리에 명시하는 게 표준임. 순서가 필요하면 명시적으로 지정하는 쪽이 맞다고 봄.