Polars 2.0 출시 후보 공개, 스트리밍 엔진 기본 적용
Pre-Release of Polars 2.0
Polars가 2.0 릴리스 후보를 공개했습니다. 이번 메이저 업그레이드는 새로운 기능보다는 과거의 설계 결정을 제거하고 기본 설정을 개선하는 데 초점을 맞춥니다. 가장 큰 변화는 모든 LazyFrame 쿼리가 기본적으로 스트리밍 엔진에서 실행된다는 점으로, 메모리 사용량과 성능이 크게 개선될 것으로 기대됩니다. 또한 데이터 타입 불일치에 대해 더 엄격해져 잠재적인 버그를 조기에 발견할 수 있습니다. 마이그레이션 가이드와 함께 제공되며, 사용자는 기존 동작을 유지하도록 선택할 수도 있습니다.
Polars 2.0은 더 나은 기본값(가장 중요한 것은 스트리밍 엔진)과 더 나은 API에 관한 것입니다. 우리는 이번 릴리스가 다소 지루하기를 바랍니다.
HN 토론
120- benrutter
벤라이터:
> 우리는 Polars 2.0을 대규모 기능 릴리스로 만들려는 의도가 없습니다. 사실 여러분이 지루하다고 느끼길 바랍니다. 이 메이저 버전을 올리는 이유는 과거에 내린 설계 결정 중 현재 우리를 막고 있는 것들을 제거하고, 더 많은 사용자에게 이로울 더 합리적인 기본값으로 변경하고 싶기 때문입니다.
저는 이 관점이 저를 아주 단조로운 사람으로 보이게 한다는 걸 알지만, 프로젝트들이 세마버를 이렇게 진지하게 다루는 모습을 보는 걸 좋아합니다! 버전 업은 반짝이는 새 기능보다는 오래된 잔재를 제거하는 데 초점을 맞춰야 합니다.
저는 한동안 polars를 사용해 왔는데, 안정성에 대한 그들의 집중은 처음에 전환을 결심하게 한 큰 이유였습니다!
- perrygeo
페리지오:
저에게 polars의 초능력은 프로덕션 안정성입니다.
Pandas는 모든 문제를 런타임으로 미루는 경향이 있으며, 특히 열 유형과 누락 값에 대해 온갖 숨겨진 휴리스틱을 사용합니다. 모든 엣지 케이스를 테스트했는지 알기 어렵습니다. 코드를 테스트하는 유일한 방법은 모든 데이터 변형을 던져보는 것입니다. 노트북 앞에 앉아 데이터를 검증하고 '정리'할 인내심이 있다면 괜찮습니다. 하지만 int 열을 기대했는데 float가 들어와 데이터 파이프라인이 실패했을 때 새벽 3시에 호출을 받는다면 그리 좋지 않습니다.
Polars는 기본적으로 더 엄격하고 플래너를 통해 비용을 앞당깁니다. 결과 앱은 프로덕션에서 눈에 띄게 더 안정적입니다. 코드를 테스트하고 실제 데이터에서 작동할 것이라는 합리적인 확신을 가질 수 있습니다.
저는 API의 인체공학이나 문법에는 별 관심이 없습니다. 둘 다 괜찮습니다. 핵심은 런타임에서 데이터 변형을 어떻게 처리하느냐입니다. 변형에 대해 깨지지 않는 일반 코드를 작성할 수 있나요? Pandas는 불가능합니다. Polars는 확실히 가능합니다!
보너스: polars에는 Rust API도 있는데, 컴파일러가 프로그램이 모든 엣지 케이스를 처리한다는 것을 효과적으로 증명할 수 있습니다. 수년간 무인으로 실행되는 Rust polars 앱을 작성하는 것은 흔한 일입니다.
- trombonechamp
트롬본챔프:
성능 외에 maintain_order=False가 기본값이어야 할 이유가 있나요? polars가 많은 과학적 데이터 분석 파이프라인에서 사용되고, 비결정적 동작은 과학 컴퓨팅에서 잘 문서화된 버그의 원인이기 때문입니다(예: https://pmc.ncbi.nlm.nih.gov/articles/PMC6919963/). 새로운 기본값은 사용자가 코드가 올바른지 판단할 때 API의 구현 세부 사항을 머릿속에 유지하도록 요구합니다. 과학 컴퓨팅에서는 정답을 미리 알 수 없어 버그가 조용히 지나가며 잘못된 결과를 낼 수 있기 때문에 이는 까다롭습니다.
- bbstats
비비스탯:
"대신 사용: int → categorical의 경우 .cat.to(dtype), categorical → int의 경우 .cat.physical()"에 필요한 코드 예제가 없는 것이 정말 짜증납니다!
- lmeyerov
엘메예로프:
스트리밍 및 일반적으로 out-of-core로 나아가는 것은 훌륭합니다.
우리는 최근에 GFQL에 Polars 백엔드를 추가했는데(데이터베이스 없이 데이터프레임에서 Cypher 그래프 쿼리), CPU와 GPU 모드 모두에서 매우 인상적이었습니다. pandas/cudf에 비해 눈에 띄는 개선이 있었고, GFQL이 큰 데이터셋뿐만 아니라 저지연과 같은 더 많은 범주에서 인기 있는 시스템을 능가할 수 있게 했습니다: https://www.graphistry.com/blog/cypher-on-polars-cpu-gpu-gra...
- bobson_dugnutt5
밥슨_더그넛5:
저는 polars를 사랑합니다. 직장에서 사람들이 pandas를 버리고 polars를 사용하도록 전도하는 일을 많이 했습니다.
- Kydlaw
키들로:
Polars 주변의 활동을 보니 기쁩니다. Pandas와 SQL에 비해 향상된 인체공학 덕분에 이 라이브러리는 데이터 처리의 표준이 되었습니다.
하지만 최근에는 좀 조용했고, 그래서 최근에 DuckDB를 점점 더 많이 살펴보기 시작했습니다... AWS의 DuckLab 인수 전까지는요.
- arn3n
아른3n:
기본적으로 스트리밍 엔진을 사용하기로 한 결정은 정말 흥미롭습니다. 제 직감으로는 이것이 배치 처리로 더 병렬화할 수 있는 다른 데이터프레임 연산보다 느릴 것 같습니다. 왜냐하면 스트리밍 엔진은 필연적으로 행을 순차적으로 처리하기 때문입니다. 제 직감이 틀렸거나 polars의 자동 병렬화를 과대평가하고 있는 걸까요?