KORE, Parquet보다 더 작고 빠르다는 새 컬럼형 바이너리 포맷 공개

• KORE는 분석 워크로드용 바이너리 파일 포맷을 표방하는 새 오픈소스 프로젝트임

  • 버전은 v0.1.0이고, “빅데이터용으로 가장 빠르고 가장 압축이 잘 되는 컬럼형 포맷”이라는 꽤 센 주장을 내세움
  • 타깃은 일반 파일 저장이 아니라 Spark 같은 분석 시스템에서 큰 테이블을 빠르게 읽고 거르는 쪽임

• README에서 가장 눈에 띄는 숫자는 압축률 38% vs Parquet 63%임

  • KORE 쪽 설명 기준으로는 같은 데이터를 저장할 때 KORE가 Parquet보다 훨씬 작게 저장된다는 의미임
  • 압축률이 낮을수록 원본 대비 크기가 작다는 뜻이라, 스토리지 비용과 스캔 I/O 양에 바로 영향을 줌

• 성능 주장도 꽤 공격적임. 컬럼 프루닝(column pruning)과 프레디킷 푸시다운(predicate pushdown)으로 131배 쿼리 속도 향상을 말함

  • 컬럼 프루닝은 필요한 열만 읽는 최적화임
  • 프레디킷 푸시다운은 필터 조건을 파일 읽기 단계로 내려보내서 필요 없는 데이터를 빨리 버리는 방식임
  • 둘 다 Parquet 같은 컬럼형 포맷이 이미 강하게 활용하는 최적화라, KORE가 정말 차이를 내려면 파일 구조나 메타데이터 설계에서 뭔가 더 세게 먹히는 지점이 있어야 함

• 무손실 검증도 언급됨

  • 40만 개 이상의 셀을 테스트했고 데이터 손실이 없었다고 설명함
  • 파일 포맷에서 “빠르다”보다 먼저 필요한 게 “읽고 쓴 값이 정확히 돌아오냐”라서, 이 항목 자체는 방향이 맞음

• Spark 통합을 제공한다는 점은 실사용 관점에서 꽤 중요함

  • PySpark로 읽기와 쓰기를 지원한다고 되어 있고, 자세한 문서는 python/README.md를 보라고 안내함
  • 빅데이터 포맷은 단독 라이브러리보다 Spark, 데이터레이크, 쿼리 엔진에 붙는 순간부터 진짜 평가가 시작됨

• 다만 현재 공개 상태는 조심해서 봐야 함

  • README에는 Cargo 메타데이터, 라이선스, CI, cargo test, cargo clippy 같은 배포 체크리스트가 남아 있음
  • 특히 “일부 긴 구현은 초기 export에서 스텁 처리됐다”는 문장이 있음
  • 런타임 기능이 필요한 경우 unimplemented!() 스텁을 실제 구현으로 바꾸라는 안내도 있어서, 아직 완성된 포맷 생태계라기보다는 초기 공개본에 가까워 보임

• 그래서 이 프로젝트를 보는 현실적인 포인트는 “Parquet 대체재 등장!”보다 “컬럼형 포맷 실험 하나가 꽤 야심찬 숫자를 들고 나왔다”에 가까움
  • Parquet은 포맷 자체보다 생태계가 강한 기술임
  • KORE가 의미 있으려면 압축률과 쿼리 속도뿐 아니라 타입 호환성, 스키마 진화, 병렬 읽기, 장애 케이스, 여러 엔진 지원까지 넘어야 함
  • 그래도 데이터 엔지니어라면 테스트 데이터 하나 던져보고 숫자가 어디까지 나오는지 확인해볼 만한 떡밥은 충분함

---

기술 맥락

• KORE가 노리는 지점은 “더 작은 파일, 더 적은 스캔, 더 빠른 분석”이에요. 분석 시스템에서는 CPU 연산보다 디스크와 네트워크에서 데이터를 얼마나 덜 읽느냐가 병목이 되는 경우가 많거든요.

• Parquet과 비교하는 이유도 명확해요. Parquet은 이미 컬럼형 저장, 압축, 컬럼 프루닝, 프레디킷 푸시다운을 제공하는 강한 기준점이라서, 새 포맷이 이 시장에 들어오려면 “우리도 지원함”이 아니라 “특정 조건에서 확실히 더 낫다”를 보여줘야 해요.

• PySpark 통합은 도입 장벽을 낮추려는 선택이에요. 데이터 팀 입장에서는 Rust 라이브러리만 있는 포맷보다, 기존 Spark 파이프라인에서 바로 읽고 쓸 수 있는 포맷이 훨씬 테스트하기 쉽거든요.

• 다만 초기 공개본에 스텁 구현이 있다는 건 꽤 큰 제약이에요. 파일 포맷은 벤치마크보다 엣지 케이스가 무서운데, 타입 변환, 누락값, 스키마 변경, 큰 파일 분할 읽기 같은 부분이 실제 구현인지 확인해야 해요.

• 결국 지금 단계의 KORE는 운영 도입 후보라기보다 검증할 만한 실험체에 가까워요. 성능 숫자가 재현되고 Spark 통합이 안정적이면 재미있어지지만, Parquet의 생태계 무게를 넘으려면 시간이 더 필요해요.