우리는 모두 'Python Tax'를 받아들였고, Pandas 3.0이 이제 그것을 줄였다.

Source: Dev.to

저도 겪어봤습니다: 3 GB 정도 되는 “작은” CSV 파일을 16 GB 메모리 머신에서 Pandas DataFrame으로 로드했는데, 모든 것이 멈춰버렸죠. 데이터를 수동으로 청크로 나누고, 컬럼을 삭제하고, OOM(Out‑of‑Memory) 신이 자비를 베풀기를 바라는 전통적인 우회 방법들은 마치 파이썬을 사용한 대가를 내는 세금과도 같았습니다.

수년간 우리는 이것을 Python Tax 라고 받아들였고, 객체 dtype가 유연성의 대가라고 스스로에게 말했습니다. 실제로는 이것이 RAM 낭비의 거대한 원인이었습니다.

왜 기존 접근 방식이 비효율적이었는가

• 10년 동안 Pandas는 문자열을 NumPy object dtype으로 저장했습니다.
• 각 문자열은 무거운 Python 객체 헤더에 감싸여, 단순한 문자 배열이 포인터들의 파편화된 혼합물로 변했습니다.
• 1천만 행을 다룰 때, 단순히 데이터를 저장하는 것이 아니라 수백만 개의 별도 Python 객체를 저장하게 되는 것이었습니다.

Pandas 3.0의 혁신적인 변화

Pandas 3.0이 출시되면서 기본 문자열 저장 방식이 PyArrow 기반의 전용 str 타입으로 전환되었습니다. 별도의 플래그나 엔진 튜닝 없이, 그냥 pd.read_csv()만 사용하면 됩니다.

벤치마크 결과

숫자는 터무니없을 정도입니다: 간단한 업그레이드만으로 텍스트 중심 데이터의 메모리 사용량을 절반 이상 줄일 수 있습니다.

요점

Pandas 3.0이 완벽하진 않지만, 문자열이 주를 이루는 워크로드에서는 이 업그레이드를 무시하면 불필요한 클라우드 비용을 지불하는 셈입니다.

가장 이상했던 Pandas “Out of Memory” 이야기는 무엇인가요?

Repository: GitHub link