Pandas는 멸종해야 한다

Pandas가 느리다는 이유만으로 복잡한 분산 쿼리 시스템으로 넘어갈 필요는 없음. 약 100GB 부근의 작업은 Polars와 DuckDB 같은 고성능 단일 머신 도구로 처리할 수 있음 Amazon Redshift 통계에 행 크기와 처리량 가정을 적용하면, 테이블의 94.68%는 100GB 미만, 쿼리의 86.9%는 80GB 이하 데이터를 다루는 것으로 추산됨. 직접 측정한 데이터 크기가 아니라 가정에 의존한 계산임 10억 행 CSV 벤치마크에서 Pandas는 4분 28초, Polars는 5.04초, DuckDB는 5.19초가 걸림. 두 대안은 메모리 사용량도 크게 줄임 Apache Arrow를 활용하면 전체 코드를 다시 쓰지 않고 Pandas, Polars, DuckDB를 섞어 시험할 수 있음. 다만 Pandas에서 Arrow 기반 데이터를 만들려면 dtype_backend="pyarrow"를 명시해야 함 도구 선택은 작업 특성과 전환 비용에 따라 달라지며, Pandas 자체도 개선 중임. Pandas가 느리다는 이유만으로 분산 시스템을 선택하기보다 두 대안을 직접 비교할 필요가 있음 Pandas의 한계와 분산 시스템 사이의 공백 일반적인 분석 도구 도입 경로는 Excel → Pandas → 분산 처리 도구로 이어짐 GB 단위에서 Pandas로 넘어가고, 수십 GB에 이르면 메모리 부족, 느린 계산, 복잡한 API에 부딪히기 시작함 전통적인 다음 선택지는 Spark, DataBricks, Snowflake, Dask처럼 빅데이터를 겨냥한 도구임 Pandas가 한계에 도달하는 규모와 분산 시스템이 정말 필요한 규모 사이에는 점점 커지는 공백이 있음 약 100GB 부근의 작업은 Polars와 DuckDB 같은 현대적인 단일 머신 도구로 효과적으로 처리할 수 있음 대부분의 작업은 분산 시스템의 추가 복잡성을 정당화할 규모에 끝내 도달하지 않을 수 있음 실제로 얼마나 많은 작업이 빅데이터인가 Amazon의 2024년 논문 Why TPC is not enough: An analysis of the Amazon Redshift fleet은 Redshift 운영 텔레메트리와 업계 표준 벤치마크의 쿼리 패턴을 비교하며, 쿼리 실행 시간과 테이블 크기 통계를 공개함 다음 두 가정을 적용하면 데이터 규모를 대략 추산할 수 있음 Redshift 테이블의 평균 행 크기를 1KB로 가정함 모든 클러스터가 머신 10대로 구성되고, 각...