요약
Polars 2.0이 스트리밍 엔진과 디스크 스필을 기본으로 켜고 SQL을 정식 기능으로 끌어올렸습니다.
Python·Rust용 데이터프레임 라이브러리 Polars의 창시자가 10월 6일 2.0 출시를 알렸습니다. 메모리보다 큰 데이터 처리, 성능, SQL 지원을 이번 판의 세 축으로 내세웠습니다.
왜 중요한가
- 별도 설정 없이도 램을 넘는 데이터를 디스크로 넘겨 가며 처리할 수 있게 됐습니다.
- SQL을 기본 API와 같은 급으로 다루면서 DuckDB 같은 분석용 SQL 엔진과 정면으로 겨루게 됐습니다.
- 기본 동작이 바뀌어 기존 코드에서 결과의 행 순서가 달라질 수 있습니다.
핵심 내용
- LazyFrame(지연 실행 데이터프레임)의 collect()가 이제 스트리밍 엔진을 기본으로 씁니다.
- 램 사용률이 약 80%에 이르면 디스크로 넘기기 시작하고, 디스크 한도는 기본 64GB입니다.
- TPC-H·TPC-DS(분석 쿼리 표준 벤치마크)에서 DuckDB·DataFusion과 겨뤄 한 항목만 빼고 가장 빨랐다고 밝혔습니다.
- join·group_by 같은 연산은 행 순서를 보장하지 않으므로, 필요하면 maintain_order=True를 켜야 합니다.
- Arrow의 Map 자료형을 지원하고, 타입이 맞지 않으면 곧바로 오류를 내도록 더 엄격해졌습니다.
HN 반응
- pandas를 대체할 만하냐는 질문에는 깔끔한 API와 속도를 들어 그렇다는 답이 많았고, 지리 공간 데이터 지원이 빈틈으로 꼽혔습니다.
- 분석은 DuckDB로 충분하다는 의견도 많았고, 아주 큰 조인은 DuckDB가 디스크를 더 잘 써서 낫다는 경험담도 나왔습니다.
예전에 Polars를 써 봤는데, 추천밖에 할 말이 없습니다.
DB가 제공하는 것 같은 아주 훌륭한 '쿼리 플래너'를 노트북이나 스크립트 같은 데서도 쓸 수 있는 느낌입니다. 제 생각에는 pandas보다 훨씬 낫습니다.
그냥 postgresql이나 sqlite를 쓰지, 왜 Polars를 쓰나요?
분석 워크로드에 최적화되어 있거든요(기본이 인메모리 컬럼 지향 레이아웃). PG와 sqlite는 OLTP DB고요. 그런 용도에서는 말도 안 되게 빠릅니다.
DuckDB와 비교하면 어떤가요?
DuckDB는 프로세스 내장형 OLAP인데, 저는 이걸 정말 많이 쓰고 있습니다. Polars도 써 보고 싶긴 한데, DuckDB가 제게는 워낙 날아다니는 것 같아서요.
진짜 데이터베이스는 내구성(durability)을 위해 속도를 최대 두 자릿수 배(100배)까지 치릅니다. DB가 데이터를 날리거나 정전 같은 일이 생겨도 데이터셋을 다시 만들어 낼 수 있다면, 쓰기가 많은 복잡한 쿼리를 15분이 아니라 10초에 끝낼 수 있다는 건 분석할 때 실제로 아주 유용합니다.
걔네는 데이터베이스니까요? Polars는 데이터베이스가 아니라 데이터 처리 엔진이잖아요. 쓰임새가 다르죠.
Polars 대신 데이터베이스를 쓰고 싶은 거라면, 비슷한 용도에서는 postgressql이나 sqlite보다 duckdb가 훨씬 나은 선택입니다.
요즘 흐름을 열심히 따라가고 있지는 않은데, Polars가 이제 Pandas를 완전히 대체할 수 있게 된 건가요? 한쪽이 더 잘 맞는 용도도 있나요?
최근 Python Bytes 팟캐스트(https://pythonbytes.fm/episodes/show/496/a-lake-house-in-seattle)에서 나온 얘기입니다.
Python 대 Rust, 속도로는 비교가 안 됩니다.
(위 에피소드 대본에 "Pandas should go extinct"라는 제목의 블로그 글 링크가 있습니다.)
저는 500행이나 1,000행 정도를 넘거나 컬럼이 엄청 많은 경우에는 거의 전부 DuckDB로 갈아탔습니다.
Polars도 훌륭하지만, DuckDB까지 갈 필요는 없는 경우에 Pandas 대신 쓰기에는 제가 Pandas API에 너무 익숙합니다.
아쉽네요. Pandas API는 별난 데다 레거시가 너무 많고, Polars는 그에 비하면 훨씬 깔끔하거든요. 저는 Spark와 Pandas를 먼저 써 본 뒤에 넘어갔는데, Polars는 멀티 워커 노드 병렬 처리까지 신경 써야 하는 부담이 없는 PySpark 같은 느낌이었습니다.
그냥 손에 익어서 그래요. Pandas를 10년 넘게 매일 써 왔으니까요. 그래도 언젠가는 Polars로 넘어가게 될 겁니다.
앞서 말했듯이 문제의 일부는, 성능이 중요할 때는 DuckDB 덕에 제가 너무 편하게 지내고 있다는 겁니다.
Polars는 사실상 99.9%의 경우에 Pandas를 완전히 대체할 수 있습니다. 제가 아는 유일한 예외는 지리 공간 데이터를 다룰 때인데, 널리 쓰이는 "Geopandas"에 해당하는 "Geopolars"가 아직 없기 때문입니다. 그래도 Geopolars는 활발히 개발 중이라 언젠가는 프로덕션에서 쓸 만해질 겁니다.
그런데 duckdb에는 지리 공간 패키지가 있고, 꽤 쓸 만합니다. 저도 그걸 계기로 duckdb를 처음 알게 됐어요. 전국 필지 데이터셋을 다루면서 전국 단위로 변환을 적용하고 결과를 다시 여러 parquet 파일로 저장해야 했는데, pandas 워크로드를 전부 duckdb로 바꾸는 쪽이 더 쉽고 비용도 적게 들었습니다.
올바른 길로 가고 있습니다. 저는 지리 공간 작업에 rust를 쓰는데, c, c++와의 격차가 빠르게 좁혀지고 있고 대부분의 경우 무시할 만한 수준입니다.
https://github.com/pola-rs/geopolars/tree/main 에서 가져왔습니다.
GeoPandas와의 비교
모방은 최고의 찬사입니다! GeoPandas는 (그 밑바탕인 shapely, GEOS 라이브러리와 함께) 프로덕션에서 쓸 수 있는 놀라운 도구입니다.
GeoPolars는 기능이나 안정성 면에서 GeoPandas에 한참 못 미치지만, 경쟁은 좋은 것이고, 순수 Rust 코어 덕분에 GeoPolars는 WebAssembly에서 훨씬 쉽게 쓸 수 있을 겁니다.
참고로 (당분간은) geopolars 개발을 https://github.com/pola-rs/geopolars/tree/dev 에서 시작했습니다.
정말 반가운 소식이네요!! 한 달쯤 전에 프로젝트를 봤을 때는 버려진 것처럼 보였는데, 메인 브랜치 밖에서 진행되던 개발을 놓쳤나 봅니다!
Pandas가 더 나은 경우는 이렇습니다. 제자리에서 살짝 고치거나 행 단위로 수정할 때, 덜 일반적인 데이터셋을 불러올 때, 전치(transposition)나 더 섬세한 행 기반 집계, 다축 조작이 필요할 때, 멀티프로세싱을 쓸 수 있을 때의 성능, 다른 라이브러리(플로팅이나 통계 등)와의 상호운용성... 거대한 데이터셋을 다뤄야 할 때는 DuckDB를 쓰세요. 속도는 지금도 Polars와 대등하고, 거대하거나 더 복잡한 조인을 처리할 때는 중간 결과를 디스크로 더 잘 내려 주기 때문에 DuckDB가 압도적으로 유리합니다. Polars는 저한테는 그냥 죽어 버렸거든요. 다만 Polars 2에서 그런 조인을 해 보지는 않았습니다.
저희는 GFQL(데이터프레임 위에서 도는 cypher 그래프 쿼리)을 pandas에서 polars로 CPU와 GPU 모드 모두 통째로 포팅했고, 엄청난 속도 향상을 얻었습니다. https://www.graphistry.com/blog/cypher-on-polars-cpu-gpu-graph-engine
인상적이었습니다!
예이기도 하고 아니오이기도 합니다. pandas가 인기를 끈 이유였던 데이터 과학자들을 대체하지는 못하지만, 파이프라인 용도로는 완전한 대체재입니다. 제 생각에는 spark도 이기고 있고요.
제가 알기로는 Polars가 더 빠르고, 외부 솔루션 없이도 더 잘 확장되고, API도 더 낫고, 거기에 Rust입니다. Pandas가 이기는 건 대다수가 쓰고 있고 예전에 써 왔던 것을 쓰고 싶을 때입니다. 속속들이 쓰다 보면 마주치는 사소한 문제에 대한 도우미나 레시피도 아마 더 많이 갖춰져 있겠지만, LLM 시대에는 그건 대수롭지 않다고 생각합니다.
숙련된 개발자 대다수는 이제 Polars를 쓰고 있습니다. 선택한 서드파티 라이브러리가 Narwhals를 지원하지 않아 발목이 잡힌 경우(예: Great Expectations, SHAP)만 빼고요. 따라야 할 더 중요한 흐름은 그쪽입니다.
제가 Pandas를 떠나게 된 계기도 API였습니다. 10년 넘게 가끔 Pandas를 썼는데도 사소하지 않은 쿼리는 매번 구글링해야 했거든요.
그런 점에서 저는 아직 쓸 만한 jq 대체재를 기다리고 있습니다...
jq 대체재는 이겁니다: https://github.com/01mf02/jaq
SQL을 배우고 Duck과 연동하세요. 메모리는 훨씬 적게 쓰면서 Pandas/Polaris 조합보다 100배는 빨라질 겁니다. 게다가 SQL은 말 그대로 어디서나 지원되고 Pandas API보다 훨씬 강력합니다. Duck은 Pandas Dataframe으로 결과를 내놓을 수 있지만, 그건 그냥 딕셔너리처럼 취급하세요. 처리, 필터링, 집계는 전부 Duck에서 하시고요.
jq 대체재로는 fx.wtf도 써 보세요. vi 키 바인딩을 지원하는 TUI 뷰어가 기본 내장되어 있습니다. fx.wtf에는 Ecmascript가 내장되어 있어서 JSON을 JS 표기법(JSON이 태어난 곳이죠)으로 쿼리할 수 있습니다. map/reduce/filter를 포함한 아무 JS 함수나 쓸 수 있고, 내일이면 까먹을 jq DSL을 배우는 대신 어떤 변환이든 할 수 있습니다.
지금 우리가 다 같이 댓글 달고 있는 그 발표에 따르면 Polars도 이제 SQL을 지원해요.
pandas 개발자를 피할 수 있다는 것만으로도 polars를 쓸 만한 훌륭한 이유라고 봅니다.
저한테는 이미 그렇습니다. API가 훨씬 마음에 들고, 제 머릿속 모델에도 훨씬 잘 맞습니다. 한번 써 보세요!
"Pandas should go extinct"를 보세요: https://news.ycombinator.com/item?id=49668198
요약하면, 그렇다는 겁니다.
어떤 면에서는 던전 앤 드래곤이 떠오르네요. Pandas는 워낙 인기가 많아서, 어느 한 용도에 가장 좋아서가 아니라 인기가 많다는 이유로 사람들이 배우고 씁니다. Polars는 더 깔끔하고 더 빠르고 프로덕션 용도로 쉽게 확장할 수 있어서, 로컬 분석용 작은 POC 스크립트도 아주 쉽게 프로덕션으로 옮길 수 있어요. 그런데도 Pandas에 남은 사람들이 있죠. 배우기가 너무 복잡했고 사소한 상처를 피하려고 외워야 할 자잘한 규칙이 너무 많았던 탓에, 또 다른 데이터 조작 도구를 배우는 건 정말 어려울 거라고 느끼는 겁니다.
던전 앤 드래곤도 똑같아요. 가장 인기가 많지만 규칙은 낡은 군더더기와 일부 현대적인 아이디어가 어색하게 뒤섞여 있어서, 배우는 데 엄청난 노력이 듭니다. 그래서 그걸 하는 사람 대부분은 다른 RPG 시스템을 시도해 볼 생각을 안 해요. 대부분은 처음부터 깔끔하게 설계되어서 훨씬 배우기 쉬운데도요.
복잡한 것을 배우는 데 적용된 매몰 비용 오류에, 경쟁 상대가 전혀 복잡하지 않아도 똑같이 복잡해 보이게 만드는 뿔 효과(후광 효과의 반대)까지 겹친 겁니다. 그래서 오래된 Pandas 사용자와 D&D 플레이어는 다른 선택지를 들여다보는 것조차 강하게 거부하죠. 이런 오래된 시스템을 배우는 좌절감이 일부 사람들에게 트라우마가 되어, 절대 벗어나지 않게 만든 셈입니다.