Python 변환의 계산 엔진 선택
Pandas, Polars와 DuckDB는 단일 노드 실행을 사용하고 Spark는 여러 노드에 계산을 분산합니다. 운영 표 처리에는 Polars를 출발점으로 검토하고, SQL 중심 분석에는 DuckDB, 익숙한 Python 생태계와 작은 데이터의 탐색에는 Pandas를 사용할 수 있습니다.
단일 노드의 메모리와 처리 방식으로 감당하기 어려운 계산은 Spark가 적합합니다. 반대로 작은 작업에 Spark를 사용하면 분산 실행의 초기화와 자원 조정 비용이 계산보다 클 수 있습니다.
Foundry 기능 지원
이 비교는 Python transforms의 실행 방식에 관한 것입니다. Pipeline Builder의 같은 이름 엔진이나 입력/출력 조합과 지원 범위가 다를 수 있습니다.
| 기능 | 단일 노드 | Spark |
|---|---|---|
| 증분 변환 | 지원 | 지원 |
| 외부 변환 | 지원 | 지원 |
| Palantir LLM API의 snapshot | 지원 | 지원 |
| Palantir LLM API의 incremental | 지원 | 미지원 |
| 학습된 모델 입력 | 지원 | 지원 |
| 학습된 모델 출력 | 지원 | 미지원 |
| Media set API의 snapshot | 지원 | 지원 |
| Media set API의 incremental | 지원 | 지원 |
| 트랜잭션 중단 | 지원 | 지원 |
| 데이터셋 보안 표지 제거 | stop_propagating, stop_requiring 지원 | 지원 |
| 소스 보안 표지 제거 | 미지원 | 지원 |
| Data expectations | 제한된 범위 | 지원 |
| Tables API | 외부 compute pushdown | Foundry 내부 계산 |
| 이전 출력을 지정 스키마로 읽기 | 미지원 | 지원 |
allowed_run_duration 설정 | 미지원 | 지원 |
Deprecated run_as_user 설정 | 미지원 | 지원 |
| 자원 사용량 관찰 | 지원 | 지원 |
단일 노드는 출력의 sever_permissions를 지원하지 않습니다. 데이터셋 보안 표지 제거가 가능하다는 사실을 모든 권한 절단 옵션에 확대하지 않습니다.
이전 출력을 지정 스키마로 읽는 기능은 증분 출력의 첫 트랜잭션처럼 아직 commit된 스키마가 없을 때 중요합니다. Spark의 해당 API와 단일 노드의 첫 실행 처리를 구분해야 합니다.
자원 관찰의 화면도 다릅니다. 단일 노드는 Metrics telemetry를 사용하고 Spark는 Spark Details 등 분산 실행의 지표를 사용합니다.
엔진 특성
Pandas
작은 데이터 탐색과 빠른 코드 작성에 적합합니다. 문서와 연동 라이브러리가 많고 시계열 및 통계 기능이 풍부합니다. 일반적인 DataFrame 계산은 단일 스레드 중심이며 분산 실행을 제공하지 않습니다. 전체 데이터를 로컬 메모리에 읽는 방식의 비용을 고려합니다.
Polars
운영 파이프라인의 기본 선택으로 권장됩니다. Rust 기반의 열 지향 엔진과 Arrow 메모리 구조를 사용하며, 지연 실행으로 질의를 최적화하고 한 노드의 여러 CPU 코어를 사용할 수 있습니다.
지원하는 연산에는 cuDF-Polars를 통한 GPU 가속도 사용할 수 있습니다. 단순히 GPU를 예약하는 것과 GPU 엔진으로 질의를 실행하는 것은 별도 구성입니다.
DuckDB
DuckDB는 낮은 지연 시간이 중요한 분석용 SQL에 적합합니다. 질의 최적화와 자동 메모리 관리, 디스크 spill을 제공하여 한 노드의 자원을 활용합니다.
SQL이 주된 인터페이스이지만 Python Relation API로 filter, project, aggregate 등을 연결할 수도 있습니다. Pandas와 같은 DataFrame API를 그대로 제공하는 것은 아니며, Ibis나 SQLFrame 같은 어댑터도 선택할 수 있습니다.
Spark
큰 입력과 복잡한 분산 계산, 조직의 대규모 데이터 기반에 적합합니다. 여러 작업자, 디스크 spill과 Catalyst 최적화를 사용합니다. 데이터가 한 노드의 처리 방식으로 감당하기 어려울 때 확장할 수 있지만 작은 작업에는 비용이 큽니다.
크기 기준은 경험적 안내
다음 수치는 압축하지 않은 데이터와 일반적인 표 연산의 선택 기준입니다. 행의 너비, 자료형, 조인과 정렬의 상태 크기에 따라 크게 달라지며 API의 강제 한도가 아닙니다.
| 특성 | Pandas | Polars | DuckDB | PySpark |
|---|---|---|---|---|
| 적합한 데이터 크기의 예 | 1 GB 미만 | 1~50 GB | 1~50 GB | 50 GB 초과 |
| 행 수의 예 | 100만 미만 | 100만~2억 | 100만~2억 | 2억 초과 |
| 시작 비용 | 작음 | 작음 | 작음 | 큼 |
| 메모리 효율 | 상대적으로 낮음 | 높음 | 높음 | 좋음 |
| 주된 구문 | Python DataFrame | Python DataFrame | SQL 및 Relation API | Python DataFrame |
| 작은 데이터 계산 | 좋음 | 높음 | 높음 | 시작 비용의 영향 큼 |
| 중간 데이터 계산 | 불리할 수 있음 | 높음 | 높음 | 빠른 처리 가능 |
| 큰 데이터 계산 | 메모리 제약 큼 | 질의에 따라 다름 | 질의에 따라 다름 | 분산 처리에 적합 |
| 병렬 실행 | 기본 DataFrame 엔진의 자동 병렬화 없음 | 단일 노드 안에서 병렬 | 단일 노드 안에서 병렬 | 여러 노드에 분산 |
| 메모리 spill | 기본 제공하지 않음 | 제한적 | 자동 | 자동 |
필터 pushdown이나 스트리밍으로 전체 입력을 한 번에 메모리에 올리지 않는 질의라면 단일 노드에서도 테라바이트 규모 입력을 처리할 수 있습니다. 모든 연산이 이러한 방식으로 실행되는 것은 아니므로 크기 표만으로 Spark 여부를 결정하지 않습니다.
보통 50 GB를 넘고 입력 줄이기나 streaming 같은 최적화를 적용하기 어려울 때 Spark 전환을 검토합니다. 실제 자원 할당의 기본 8코어 및 64 GB 한도는 자원 설정의 정책을 따릅니다.
기존 Spark 변환 이전
예전부터 Spark로 작성한 파이프라인도 단일 노드에서 더 빠르거나 적은 자원으로 실행할 수 있습니다. 전체 코드를 번역하기 전에 SQLFrame으로 DuckDB 경로를 시험하여 처리 특성을 확인하는 방법이 권장됩니다.
고급 단일 노드 선택에는 여러 백엔드를 사용하는 Ibis, DuckDB의 원시 Parquet 접근, Apache DataFusion과 cuDF의 GPU 처리가 있습니다. 필요한 언어 API뿐 아니라 입력 형식, 지원 연산과 메모리 동작을 함께 비교해야 합니다.