Do GPUs Really Need New Tabular File Formats?

본 논문은 Parquet 파일의 GPU 스캔 성능 병목 현상이 포맷 자체가 아닌 비최적화된 CPU 중심 구성에서 비롯된다는 것을 입증하고, Parquet 사양을 변경하지 않고도 GPU 인지 설정을 적용하면 유효 읽기 대역폭을 125GB/s 까지 향상시킬 수 있음을 보여줍니다.

핵심

거대한 도서관(데이터)이 창고(하드 드라이브)에 저장되어 있다고 상상해 보세요. 또한 이 도서관의 책을 읽고 질문에 답하는 일을 담당하는 초고속 로봇 사서(GPU)가 있습니다.

수년 동안 이 도서관은 Parquet이라는 특정 filing system(파일링 시스템)으로 정리되어 왔습니다. 이 시스템은 인간 사서를 염두에 두고 설계되었습니다: 즉, 인간이 한 번에 하나씩 쉽게 집어 올릴 수 있도록 책을 작고 관리하기 쉬운 더미로 묶는 방식입니다.

하지만 로봇 사서는 다릅니다. 로봇은 한 번에 더미 하나만 집어 올리는 것이 아니라, 수천 개의 손을 가지고 있어 수십 개의 더미를 동시에 잡을 수 있습니다. 그러나 도서관이 여전히 인간을 위해 조직되어 있기 때문에, 로봇은 다음 더미를 받아오기를 기다리는 시간을 대부분 보내거나, 자신의 손의 아주 작은 부분만 사용하고 있습니다. 로봇은 놀라울 정도로 빠르지만, 도서관의 조직 방식이 이를 억제하고 있는 것입니다.

이 논문은 단순한 질문을 던집니다: 로봇을 위해 완전히 새로운 filing system을 발명해야 할까요?

저자들은 이렇게 답합니다: 아닙니다. 대신, 몇 가지 간단한 규칙을 사용하여 기존 책들을 재배열하기만 하면 됩니다.

다음은 네 가지 주요 "규칙"을 사용하여 그들이 문제를 해결한 방법입니다:

1. "더 많은 더미" 규칙 (페이지 수 증가)

• 문제: 기존 시스템은 섹션의 모든 데이터를 하나의 거대하고 무거운 책에 넣었습니다. 로봇이 이를 읽으려 했지만, 책을 분할하기에는 너무 커서 한 번에 한 손만 사용할 수 있었습니다.
• 해결책: 그들은 그 거대한 책들을 작고 얇은 여러 페이지로 잘랐습니다. 이제 로봇은 100 개의 손으로 한 번에 100 개의 페이지를 잡을 수 있습니다.
• 결과: 로봇은 더 이상 기다리지 않습니다. 모든 손을 동시에 바쁘게 사용하고 있습니다.

2. "큰 상자" 규칙 (행 그룹 크기 증가)

• 문제: 기존 시스템은 로봇에게 우표 크기의 작은 택배를 보냈습니다. 로봇이 빠르더라도, 드라이브와 로봇 사이의 연결(배송 트럭)이 너무 많은 작은 택배로 인해 막힙니다.
• 해결책: 그들은 우표 대신 크고 가득 찬 이삿짐 상자를 보내기 시작했습니다.
• 결과: 배송 트럭이 이제 전속력으로 주행할 수 있어, 로봇이 지속적으로 데이터로 공급받게 됩니다.

3. "스마트 포장" 규칙 (인코딩 유연성)

• 문제: 기존 시스템은 범용적인 일률적인 방법으로 책을 포장했습니다. 때로는 책을 더 작게 만들기도 했지만, 종종 큰 도움이 되지 않았습니다.
• 해결책: 그들은 각 책을 개별적으로 살펴보고 책을 줄이는 최고의 방법을 선택했습니다. 책에 반복되는 단어가 많다면, 책을 작게 만드는 특수 코드를 사용했습니다. 책이 이미 짧다면 그대로 두었습니다.
• 결과: 책들이 선반에서 더 적은 공간을 차지하므로, 배송 트럭이 운반해야 할 무게가 줄어들어 전체 과정이 빨라집니다.

4. "랩핑하지 마라" 규칙 (불필요한 압축 제거)

• 문제: 때로는 기존 시스템이 책이 이미 작을 때도 무거운 비닐 포장(압축)으로 책을 싸곤 했습니다. 로봇은 이를 풀기 위해 시간을 보내야 했고, 이는 에너지를 낭비했습니다.
• 해결책: 그들은 이렇게 결정했습니다: "비닐 포장이 패키지를 눈에 띄게 작게 만들지 않는다면, 사용하지 마라."
• 결과: 로봇은 불필요한 포장 제거 단계를 건너뛰어 시간을 절약합니다.

대망의 결말: 로봇 대 인간

저자들은 이 새로운 배열을 테스트했습니다.

• 기존 방식: 로봇은 느렸으며, 초능력을 거의 사용하지 못했습니다.
• 새로운 방식: 기존 Parquet 파일을 재구성하기만 하고(새로운 포맷을 발명하지 않고), 데이터 읽기 속도 측면에서 로봇을 125 배 더 빠르게 만들었습니다.

또한 로봇이 배송 트럭과 동기화되어 작동할 때(읽기와 처리를 겹쳐서), 효율성이 더욱 높아진다는 것을 보여주었습니다. 실제로 이 재구성된 로봇은 배송 트럭 자체의 이론적 속도 한계에 거의 도달할 정도로 빨랐습니다.

결론

이 논문은 도서관을 불태우고 처음부터 새로운 도서관을 지을 필요가 없다고 결론 내립니다. 우리는 단지 몇 가지 스마트한 조정으로 책을 다시 정리하기만 하면 됩니다.

데이터를 포장하고 그룹화하는 방식을 약간 조정함으로써, 기존 Parquet 포맷은 이미 현대 GPU 에서 번개처럼 빠른 속도로 실행될 수 있습니다. 이는 모두에게 새로운 시스템을 배우는 번거로움을 덜어주고, 모든 기존 소프트웨어를 호환되게 유지하면서도 우리가 원했던 막대한 속도 향상을 제공합니다.

기술 요약

기술 요약: GPU 는 정말 새로운 표 형식 파일이 필요한가?

문제 제기

Apache Parquet 은 현대 분석 시스템에서 사실상의 열(columnar) 파일 형식이지만, 그 기본 구성 가이드라인은 CPU 중심 실행 엔진에 맞춰져 있습니다. GPU 가속 데이터 처리가 보편화됨에 따라, CPU 에 최적화된 Parquet 파일은 종종 GPU 하드웨어를 심각하게 저활용하여 인위적인 성능 병목 현상을 초래합니다. 광범위한 CPU 측 테스트에도 불구하고, Parquet 읽기는 GPU 가속 분석에서 여전히 주요 병목 현상으로 남아 있습니다. 예를 들어, NVIDIA RAPIDS 팀은 TPC-H 벤치마크 실행 시간의 약 85% 가 쿼리 연산자가 아닌 Parquet 스캔에 소요된다고 보고합니다. 이는 다음과 같은 핵심 연구 질문을 제기합니다: GPU 는 정말 새로운 표 형식 파일이 필요한가, 아니면 기존 Parquet 구성을 최적화하여 고성능을 달성할 수 있는가?

방법론

저자들은 Parquet 구성 선택이 GPU 스캔 성능에 미치는 영향을 평가하기 위해 체계적인 연구를 수행했습니다. 실험 환경은 로컬 NVMe SSD 에서 GPUDirect Storage(GDS) 를 통해 가장 큰 TPC-H SF300 테이블 (lineitem) 을 읽는 단일 NVIDIA A100 GPU 를 사용했습니다. 이 연구는 NVIDIA RAPIDS cuDF 라이브러리를 기반으로 구축되어 I/O 와 GPU 연산을 완전히 오버랩하는 GPU 가속 분석 시스템인 PystachIO를 활용했습니다.

방법론은 다음을 포함합니다:

1. 기준선 확립: DuckDB 의 기본 설정 (열 청크당 단일 페이지, 행 그룹 (RG) 당 122,880 행, Parquet V1 인코딩, 표준 압축) 을 사용하여 Parquet 파일을 생성합니다.
2. 구성 반복: 네 가지 특정 차원을 테스트하기 위해 파일 매개변수를 체계적으로 수정합니다:
   • 페이지 수: GPU 커널 그리드 크기에 맞추기 위해 RG 당 페이지 수를 증가시킵니다.
   • 행 그룹 (RG) 크기: GDS 에 적합한 더 큰 I/O 단위를 생성하기 위해 RG 당 행 수를 증가시킵니다.
   • 인코딩 유연성: Parquet V1 과 V2 방식 모두에서 최적의 인코딩을 청크별로 선택할 수 있도록 허용합니다.
   • 압축 선택성: 크기 감소가 특정 임계값 (10%) 을 초과하지 않는 열 청크의 경우 압축을 생략합니다.
3. 도구 개발: 저자들은 기존 Parquet 파일을 파일 형식 명세를 변경하지 않고 이러한 최적화된 구성으로 변환하는 Parquet 재작성 도구(Rust 로 작성) 를 개발했습니다.
4. 성능 지표: 평가는 다양한 데이터셋 규모 (최대 SF1000) 에 대한 TPC-H 쿼리 (Q6 및 Q12) 에 대한 유효 읽기 대역폭 (논리적 원시 데이터 크기 나누기 스캔 실행 시간) 과 엔드투엔드 쿼리 실행 시간에 초점을 맞췄습니다.

주요 기여 및 통찰

이 논문은 실험 결과에서 도출된 네 가지 주요 통찰을 제시합니다:

1. 페이지 수 최적화: GPU 디코딩 커널은 페이지 간에 병렬화됩니다. 기본 구성은 종종 페이지가 너무 적어 GPU 가 저활용되는 결과를 낳습니다. 페이지 수를 100 이상으로 증가시키면 디코딩 효율성과 저장소 버스 대역폭이 크게 향상됩니다.
2. RG 크기 최적화: GPU I/O 스택 (GDS) 은 CPU 스택과 다르게 동작하며, 저장소 대역폭을 포화시키기 위해 더 큰 I/O 단위 (MiB 규모) 를 선호합니다. 기본 RG 크기 (약 100KB 청크로 이어짐) 는 최적이지 않습니다. RG 크기를 수백만 행(예: 1,000 만 행)으로 증가시키면 GDS 가 SSD 를 포화시킬 수 있습니다.
3. 인코딩 유연성: 인코딩을 Parquet V1 으로 제한하면 압축 효율이 제한됩니다. V1 과 V2 방식 모두에서 가장 작은 인코딩 크기를 선택할 수 있도록 허용하면 (예: 정수형에 Delta Binary Packed 사용) 압축 비율이 향상됩니다. 이는 I/O 병목 현상을 줄이고 GPU 에서 효율적인 V2 디코딩을 활용합니다.
4. 불필요한 압축 회피: 무작위로 압축을 적용하면 디압축 오버헤드가 추가됩니다. 이 연구는 크기 감소가 10% 임계값 미만일 때 압축을 생략하면 성능이 향상됨을 보여줍니다. 특히 GPU 가 연산에 묶인 시나리오 (예: 여러 SSD 에서 읽는 경우) 에서 그렇습니다.

결과

이러한 GPU 인지 구성을 완전히 준수하는 Parquet 파일에 적용함으로써, 저자들은 다음과 같은 결과를 달성했습니다:

• 유효 대역폭: 최적화된 구성은 4 개 SSD 를 사용하여 최대 125 GB/s의 유효 읽기 대역폭을 달성하여 기준선 대비 극적인 개선을 보였습니다.
• 확장성: 인코딩 유연성이 적용된 경우 유효 대역폭은 SSD 수에 따라 선형적으로 확장되었으나, 기본 구성은 일찍 포화되었습니다.
• 쿼리 성능: TPC-H 쿼리 (Q6 및 Q12) 에서 최적화된 Parquet 파일을 사용한 GPU 시스템은 CPU 시스템 (ClickHouse 및 DuckDB) 보다 훨씬 우수한 성능을 보였으며, SSD 대역폭으로 정의된 이론적 최소 실행 시간과 근접한 수준을 유지했습니다.
• 새로운 형식 불필요: 이 연구는 새로운 파일 형식으로 전환하지 않고도 고성능 GPU 성능을 달성할 수 있음을 보여주어, Parquet 생태계의 상호 운용성 이점을 유지합니다.

중요성 및 주장

이 논문은 고성능 GPU 분석을 위해 새로운 파일 형식이 반드시 필요한 것은 아님을 주장합니다. 대신, 성능 격차는 주로 CPU 중심 기본값에서 유래한 최적화되지 않은 구성 선택의 결과입니다.

• 실용적 지침: 이 작업은 GPU 데이터베이스를 위한 Parquet 최적화에 대한 최초의 실용적 지침을 제공하여, 형식 교체 대신 구성을 통해 상당한 가속화를 가능하게 합니다.
• 미래 작업의 기준선: 저자들은 향후 GPU 파일 형식을 위한 강력한 기준선을 확립합니다. 그들은 제안된 새로운 형식이 최적화되지 않은 기본값을 개선하는 것을 넘어, 이러한 최적화된 Parquet 구성 (~125 GB/s 달성) 을 능가해야 한다고 주장합니다.
• 생태계 보존: 기존 Parquet 명세 및 생태계와의 호환성을 유지함으로써, 독점적이거나 새로운 형식으로 마이그레이션하는 것과 관련된 비용을 회피합니다.
• 하드웨어 독립성: GPU 에 초점을 맞추고 있지만, 재작성 도구는 하드웨어 특정적이지 않습니다. 이는 대상 하드웨어의 특성에 따라 구성을 적용하므로, 어떤 하드웨어에서든 빈번한 쿼리는 이러한 재작성을 통해 혜택을 받을 수 있음을 시사합니다.

저자들은 GPU 메모리 내 디코딩을 목표로 하는 새로운 형식이 존재하지만, 실제 시나리오에서의 지배적인 병목 현상은 여전히 저장소 I/O 라고 결론지었습니다. 따라서 완전히 새로운 파일 형식 설계를 고려하기 전에 기존 Parquet 형식을 최적화하여 저장소 처리량을 극대화하고 디압축 오버헤드를 최소화하는 것이 시급하고 중요한 단계입니다.