코드 아래의 엔진이 교체되었습니다
Polars 2.0은 근본적이고 종종 눈에 띄지 않는 변화를 구현했습니다. 기본 쿼리 엔진이 교체된 것입니다. 코드 수정 없이도 기존 쿼리는 이제 이전의 인메모리 시스템에서 벗어나 새로운 스트리밍 엔진(streaming engine)에서 실행됩니다. 이러한 핵심 아키텍처 변경은 업그레이드 즉시 모든 Polars 사용자에게 영향을 미칩니다.
이전의 인메모리 엔진은 창고처럼 작동하여, 처리를 시작하기 전에 전체 데이터셋을 RAM에 로드해야 했습니다. 쿼리 단계는 완전히 로드된 이 데이터를 기반으로 실행되었습니다. 이 방식은 전체 데이터셋이 사용 가능한 메모리에 들어갈 때만 빨랐으며, 더 큰 작업에 대한 확장성을 제한했습니다.
새로운 스트리밍 엔진은 조립 라인과 유사한 다른 패러다임을 채택합니다. 데이터를 CPU 캐시에 맞게 특별히 크기가 조정된 작은 모셀(morsels)로 분할합니다. 이 모셀들은 쿼리 계획에 따라 순차적으로 처리되지만, 결정적인 차이점이 있습니다.
이러한 파이프라인 방식의 청크 기반 접근 방식은 상당한 속도 향상의 직접적인 원인입니다. 이제 쿼리의 서로 다른 부분이 별도의 모셀에서 동시에 실행될 수 있으므로, 한 단계가 전체 데이터셋이 처리될 때까지 기다려야 했던 이전의 병목 현상이 제거되었습니다. 이러한 동시성(concurrency)은 효율적이고 지속적인 처리 라인을 가능하게 하여 복잡한 작업을 훨씬 더 빠르게 만듭니다. 엔진의 변화는 데이터를 국소화하고 계속 이동시킴으로써 CPU 활용도를 극대화하는 것을 목표로 합니다.
속도의 대가: 데이터 순서가 뒤바뀝니다
새로운 스트리밍 엔진의 병렬 처리는 상당한 비용을 수반합니다. 즉, 행 순서(row order)가 더 이상 보장되지 않습니다. 조인(join), 그룹화(group-by), 언피벗(unpivot)을 포함한 작업은 입력값과 다른 순서로 행을 반환할 수 있습니다. 이러한 동작은 여러 작업이 조립 라인의 작업자들처럼 독립적으로 완료되는 엔진의 데이터 "모셀" 병렬 처리 방식을 반영합니다.
이 변화는 침묵의 오류(silent failures) 가능성 때문에 Polars 2.0의 가장 위험한 변경 사항입니다. 코드는 충돌하지 않으며 계산된 수치는 산술적으로 올바를 수 있습니다. 그러나 하위 프로세스가 입력 행 순서에 암묵적으로 의존하는 경우, 데이터가 잘못된 엔티티에 연결되어 오류를 발생시키지 않고 분석을 손상시킬 수 있습니다. 이러한 문제는 명시적인 예외보다 감지하기가 훨씬 어렵습니다.
이제 정렬을 위해서는 명시적인 의도가 필수적입니다. 작업에 특정 행 순서가 필요한 경우 Polars에 직접 알려야 합니다. 예를 들어, 조인 작업은 이제 왼쪽 순서를 유지하기 위해 maintain_order='left'를 허용합니다. 이 설계는 암묵적인 편의성을 명시적인 정확성(explicit correctness)과 맞바꾸어, 개발자가 정렬 요구 사항을 선언하도록 강제합니다.
Polars 2.0은 데이터 순서에 대한 선언적 접근 방식을 강제하여 감지되지 않는 데이터 손상을 초래할 수 있는 가정을 방지합니다. explain() 함수가 쿼리의 기본 동작을 밝힐 수는 있지만, 개발자는 정렬 영향에 대해 사전에 검토해야 합니다. 이러한 변화는 과거의 암묵적 보장보다 성능과 강력한 데이터 무결성에 대한 의지를 강조하며, 데이터 파이프라인의 더 큰 명확성을 추구합니다.
의도적으로 문제를 일으키는 '지루한' 릴리스
Polars 2.0은 주요 신기능을 제공하지 않습니다. 대신 라이브러리의 내부 기반을 강화하는 정리 릴리스(cleanup release) 역할을 합니다. 이 버전은 마이너 업데이트에 대한 하위 호환성보다 장기적인 일관성과 아키텍처의 견고함을 우선시하여 의도적으로 파괴적인 변경 사항을 도입합니다.
수십 개의 메서드가 이름이 변경되거나 제거되었습니다. 주요 변경 사항은 다음과 같습니다:
melt가unpivot로 변경됨read_csv가scan_csv().collect()로 변경됨LazyFrame.profile()이 제거됨join_nulls가nulls_equal로 변경됨- 정수를 직접 categorical로 캐스팅하려면
cat.to()를 사용해야 함 concat은 이제 사용자의 의도를 추측하는 대신 높이가 일치하지 않으면 거부함
Polars는 이러한 변경 사항에 대해 유용한 AttributeRemovedError를 발생시킵니다. 이 오류는 사용할 새로운 함수나 메서드를 명확하게 설명하여 사용자의 마이그레이션을 안내합니다.
이러한 철학은 모호함과 잠재적 문제를 런타임으로 미루는 경향이 있는 Pandas의 접근 방식과 극명하게 대비됩니다. Polars는 오류를 조기에 포착하여 실행 전 코드를 더 예측 가능하고 견고하게 만드는 것을 목표로 합니다. 이러한 파괴적 변경 사항과 매우 상세한 오류 메시지는 Polars의 예방적 설계 전략의 핵심입니다.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
결론: 지금 업그레이드할 것인가, 기다릴 것인가, 아니면 검토할 것인가?
새로운 streaming engine을 통해 5배 더 빠른 성능을 제공한다는 Polars의 주장은 보편적인 벤치마크가 아닌 기대치입니다. 이 엔진은 기반 기술이지만 아직 진정한 out-of-core 처리를 제공하지는 않으며, 데이터는 여전히 RAM 내에 적재되어야 합니다. 2.0 릴리스는 메모리보다 큰 데이터셋을 처리할 미래의 기능을 위해 라이브러리를 준비하는 단계입니다.
현재 Polars 2.0은 release candidate 단계이며, --pre 플래그를 사용하여 설치해야 합니다. 이 버전은 아직 안정적이지 않으며, streaming engine에서 group_by_dynamic이 datetime 범위를 벗어나는 오류를 일으키는 고우선순위 문제와 같은 버그가 존재합니다. 또한 str.to_datetime은 이제 예외를 발생시키는 대신 null을 반환할 수 있으며, limit 메서드는 join 이후에 조기 종료되지 않습니다.
새로운 프로젝트는 처음부터 업데이트된 API를 채택하기 위해 Polars 2.0으로 시작하는 것을 고려해야 합니다. 기존 코드베이스의 경우 무작정 업그레이드하는 것은 권장되지 않습니다. 개발자는 행 순서(row order)에 암묵적으로 의존하는 join이나 group-by와 같은 작업이 있는지 코드를 검토해야 합니다. 데이터 일관성을 보장하고 예기치 않은 데이터 무결성 문제를 방지하려면 명시적으로 정렬을 추가하거나 maintain_order 플래그를 활용하십시오.
자주 묻는 질문(FAQ)
Polars 2.0의 가장 큰 변화는 무엇인가요?
기본 쿼리 엔진이 새로운 'streaming' 엔진으로 교체되었습니다. 이 엔진은 데이터를 더 작고 병렬적인 청크로 처리하여 상당한 성능 향상을 제공하지만, 그 대가로 기본적으로 원래의 행 순서를 보장하지 않습니다.
Polars 2.0에서 행 순서가 바뀌는 이유는 무엇인가요?
새로운 streaming engine은 데이터 청크('morsels')에 대한 작업을 병렬화합니다. 속도를 극대화하기 위해 이 청크들을 원래 순서대로 재조합하는 과정을 기다리지 않습니다. 이제 maintain_order=True와 같은 매개변수를 사용하여 순서 유지를 명시적으로 요청해야 합니다.
Polars 2.0이 정말 5배 더 빠른가요?
'5배 더 빠르다'는 수치는 Polars 팀의 기대치일 뿐 보장된 벤치마크가 아닙니다. 새로운 엔진이 눈에 띄게 빠르긴 하지만, 실제 성능 향상은 하드웨어, 데이터셋, 실행 중인 특정 작업에 따라 달라집니다.
Polars 2.0에서 'streaming'이란 무엇을 의미하나요?
현재 'streaming'은 CPU 캐시 크기에 맞춰 데이터를 조각으로 처리하는 청크 및 파이프라인 실행 모델을 의미합니다. 아직 데이터셋이 컴퓨터의 RAM보다 클 수 있는 진정한 out-of-core 처리를 의미하지는 않습니다.
Polars 2.0을 프로덕션 환경에서 사용해도 안전한가요?
초기 2.0 버전은 release candidate입니다. 행 순서와 같은 중요한 동작 변화와 몇 가지 알려진 버그를 고려할 때, 중요한 프로덕션 환경에 배포하기 전에 기존 코드베이스를 철저히 검토하고 안정적인 릴리스를 기다리는 것이 현명합니다.