F3 - 미래를 위한 오픈소스 데이터 파일 포맷

(db.cs.cmu.edu)
9P by GN⁺ | ★ favorite | 댓글 1개
  • F3(Future-proof File Format) 는 차세대 오픈소스 컬럼형 스토리지 포맷으로, 상호운용성, 확장성, 효율성을 핵심 설계 원칙으로 하여 데이터 처리 및 컴퓨팅 환경의 변화마다 새로운 포맷을 만들 필요를 제거
  • 각 F3 파일은 자기서술적(self-describing) 구조로, 데이터와 메타데이터는 물론 WebAssembly(Wasm) 바이너리 디코더까지 내장하여 네이티브 디코더가 없어도 모든 플랫폼에서 호환성 보장
  • 최신 인코딩 기법(계단식 압축, 벡터화 디코딩)을 포함한 효율적인 스토리지 레이아웃을 제공하며, Parquet와 ORC의 레이아웃 문제점을 개선하여 I/O, 인코딩, 딕셔너리 단위를 분리
  • 플러그인 기반 디코딩 API와 Wasm 임베딩 메커니즘을 통해 개발자가 새로운 인코딩 스킴을 쉽게 추가할 수 있으며, 라이브러리 버전에 관계없이 모든 파일을 읽을 수 있어 Parquet의 상호운용성 문제 해결
  • 평가 결과 F3의 스토리지 레이아웃 효율성과 Wasm 기반 디코딩의 이점이 입증되었으며, 스토리지 오버헤드는 킬로바이트 수준으로 미미하고 Wasm 디코딩 성능 저하는 네이티브 대비 10~30%로 허용 가능한 수준

배경 및 동기

기존 컬럼형 포맷의 한계

  • Parquet와 ORC는 2010년대 초 Hive, Impala, Spark 같은 데이터 분석 시스템을 위해 개발되었으며, 데이터 웨어하우스 및 데이터 레이크 간 데이터 공유를 가능하게 함
  • 10년이 지난 현재 연구들은 이 포맷들이 현대 데이터 분석에 부족함을 보여주며, 이는 설계 당시의 구식 하드웨어 성능 가정과 워크로드 접근 패턴 가정에 기반했기 때문
    • 지난 10년간 스토리지와 네트워크 성능은 수십 배 향상되었으나 CPU 성능은 그렇지 않아, 시스템이 I/O가 아닌 컴퓨트에서 병목이 발생
    • 데이터 레이크의 부상으로 더 많은 데이터가 고대역폭·고지연 클라우드 스토리지(예: Amazon S3)에 저장됨
    • 애플리케이션이 더 이상 적은 수의 컬럼을 가진 테이블형 데이터만 저장하지 않음. ML 워크로드에서는 수천 개의 컬럼을 가진 넓은 테이블, 고차원 벡터 임베딩, 대용량 blob(이미지, 비디오) 등을 저장하는 것이 일반적
    • 랜덤 액세스나 업데이트를 수행하려는 요구도 증가했으나 기존 포맷은 이런 사용 패턴에 적합하지 않음
  • 최근 압축, 인덱싱, 필터링 방법의 발전이 이러한 결함을 해결하려 하지만, 기존 파일 포맷은 쉽게 확장 가능하도록 설계되지 않음
    • 새 기능을 추가하더라도 Parquet와 ORC 라이브러리의 다양한 언어 구현이 너무 많아 최신 버전을 기대하기 어려움
    • 구버전 라이브러리를 사용하는 시스템은 새 파일의 내용을 해독하지 못할 수 있어, 대부분의 시스템이 최소 공통분모 기능만 지원하여 상호운용성 문제 회피

새로운 파일 포맷들의 등장과 한계

  • 이를 극복하기 위해 Meta Nimble, Lance, TSFile, Bullion, BtrBlocks 등 완전히 새로운 파일 포맷 제안들이 등장
  • 그러나 이들도 전임자들과 동일한 실수를 범함
    • 현대의 하드웨어 및 워크로드 가정에 기반하여 설계
    • 새로운 기능을 지원하면서 기존 배포와의 상호운용성을 깨지 않도록 하는 쉬운 확장성을 촉진하지 못함
    • 이 중 하나가 Parquet나 ORC를 대체하는 주요 포맷이 되더라도, 10년 후에는 그들의 결함을 해결하기 위해 또 다른 포맷을 만들어야 하는 동일한 문제 발생

F3의 접근 방식

  • F3는 상호운용성, 확장성, 효율성을 동시에 달성하는 것을 목표로 함
  • F3의 핵심은 다음 세 가지 사양 정의:
    1. 파일 콘텐츠의 메타데이터
    2. 파일 내 인코딩된 데이터의 물리적 그룹화 레이아웃
    3. 데이터의 인코딩 스킴에 구애받지 않는 데이터 액세스 API
  • F3의 메타데이터 스킴은 테이블의 컬럼 부분집합을 검색하는 데 필요한 데이터를 최소화
  • F3는 Parquet의 포괄적인 "row group" 개념을 없애고 I/O, 인코딩, 딕셔너리 단위를 분리하여 레이아웃 문제 해결
  • 계단식 압축과 벡터화 디코딩 같은 최신 방법 통합

F3 개요

전체 구조

  • F3 파일은 메타데이터 부분과 데이터 부분으로 구성
    • 메타데이터 부분: OptionalData(OptData), Column Metadata(ColMetadata), Footer, Postscript
    • 데이터 부분: Row Groups(RG)로 구성되며 실제 데이터 포함
  • F3는 Parquet 및 ORC와 동일한 PAX 레이아웃 채택
  • 그러나 F3는 기존 포맷과 여러 핵심 차이점 존재:
    1. 메타데이터가 역직렬화 오버헤드 제거 (Parquet/ORC의 문제점 해결)
    2. 물리적 I/O Unit(IOUnit) 을 논리적 row group에서 분리하여 스토리지 미디어에 따라 IOUnit 크기를 독립적으로 조정 가능
    3. 딕셔너리 인코딩 범위를 논리적 row group에서 분리하여 각 컬럼마다 가장 효과적인 범위 결정 가능
    4. 각 IOUnit는 여러 Encoding Unit(EncUnit) 로 구성되며, EncUnit는 인코딩 및 디코딩의 최소 단위

상호운용성 및 확장성 메커니즘

  • F3는 공개 API를 노출하여 구현이 파일 내 압축된 데이터를 디코딩하는 방법 정의
  • 인코딩 방법을 플러그인으로 취급하여 핵심 라이브러리와 별도로 설치 및 업그레이드 가능
  • 모든 라이브러리 버전이 모든 파일을 읽을 수 있도록 WebAssembly(Wasm) 바이너리로 디코더 구현을 파일 내부에 임베딩
    • 즉, 모든 F3 파일에는 데이터와 그 데이터를 읽는 코드가 모두 포함됨
  • F3의 API는 네이티브 코드와 Wasm 버전에 대해 별도 구현이 필요 없으며, 동일한 코드가 변경 없이 두 타겟으로 컴파일됨
  • 이 설계는 F3를 미래 보장하고, 앞서 설명한 문제를 회피하며, 기존 솔루션보다 빠른 진화 가능
    • 개발자는 전체 플릿에서 라이브러리 버전 업그레이드 걱정 없이 Wasm 코드를 파일에 포함시켜 미래 인코딩 방법을 프로덕션 시스템에 배포 가능
    • Wasm 바이너리의 스토리지 오버헤드는 미미(킬로바이트 수준)하며, 네이티브 구현 대비 Wasm 디코딩 성능 저하는 최소(10~30%)

결론

  • F3는 상호운용성, 확장성, 효율성을 동시에 달성하는 차세대 컬럼형 파일 포맷
  • 효율적인 파일 레이아웃 설계로 기존 포맷의 비효율성 해결
  • 플러그인 기반 디코딩 API와 Wasm 임베딩으로 라이브러리 버전에 관계없이 모든 파일을 읽을 수 있는 미래 보장 메커니즘 제공
  • 프로토타입 평가 결과 레이아웃 설계의 효율성과 Wasm 메커니즘의 실용성 입증
  • Wasm 오버헤드는 킬로바이트 수준의 스토리지와 10~30%의 성능 저하로 허용 가능한 범위
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 빠르게 살펴본 결과, Parquet의 단점을 많이 보완한 것 같아서 기대감이 큼

    • Parquet 메타데이터는 Thrift 기반임에도 "이 필드가 있으면 저 필드도 반드시 있어야 한다"는 식의 주석만 있을 뿐 실제 검증 로직이 없어서 잘못된 Thrift를 넣으면 리더가 망가질 거라고 생각함

    • Parquet 메타데이터는 파싱해야 하므로, 버퍼 할당 및 메타데이터 파싱을 위한 동적 할당이 반복되어 너무 많은 힙 할당이 생김. Flatbuffers 방식을 채택한 이번 포맷은 Flatbuffer 바이트를 바로 해석할 수 있어 이 문제가 해결됨

    • 인코딩이 훨씬 강력하다고 느낌. 데이터베이스 업계에서 오래 전부터 주창해온 가볍고 조합 가능한 인코딩이 가능해진 것 같음. BtrBlocks, FastLanes같은 기존 포맷이 Parquet보다 우수했는데, 그들의 좋은 아이디어가 계승되어서 좋음

    • Parquet의 Dremel record-shredding은 너무 복잡해서 마음에 들지 않았는데 이번에는 사라져서 다행임

    • Parquet에서는 DataPage 내의 row 수가 달라서 원하는 row를 찾으려면 ColumnChunk 전체를 스캔해야 하지만, 이번 포맷은 원하는 DataPage(IOUnit)로 바로 점프 가능함

    • 무거운 압축은 제거하고 Delta/Dictionary/RLE만 남겼음. 무거운 압축은 실질적 이득이 없고 구현도 번거롭고, 외부 종속성도 많음

    • 전체적으로 대단한 발전임. 이 포맷이 데이터 분석 업계를 장악하길 기대함

    • 무거운 압축이 zstd나 brotli라면, 반복이 적은 문자열 컬럼에서 매우 유용함

      • 실제로 대부분 ASCII이고 공통 부분 문자열이 많아서 압축률이 1%까지 나온 경험이 있음

    • wasm 컴파일러가 들어가면 오히려 ‘heavy’ compression보다 더 많은 종속성이 생길 수 있음

      • 예전에는 CPU 자원이 네트워크나 디스크 대역폭보다 비교적 많았기에 무거운 압축이 더 의미 있었겠지만, 지금은 그 차이가 덜함

    • Parquet 파일에 컬럼 추가하기 관련 StackOverflow 토론

    • 요즘 압축 방식은 zstd로 정착한 것 같음?

    • Parquet는 의외로 복잡함. 제대로 효율적으로 쓰려면 불편하고 문서화도 부족한 세부 내용을 많이 숙지해야 하므로 쉽지 않음

  • Wes McKinney

    • Wes McKinney를 모르는 분들을 위해 설명하자면, 그는 Python에서 가장 널리 쓰이는 표 형식 분석 라이브러리 Pandas의 창시자임

    • 그가 만든 포맷은 출시 초반부터 시장의 신뢰를 얻을 수 있고 문제에 대해 오랜 기간 애정을 가지고 접근해왔기 때문에 그의 통찰은 특별히 중요하게 여겨짐

    • Andy Pavlo도 언급할 가치가 큼

      • 그는 데이터베이스 분야 전문가며, 데이터 중심의 삶을 사는 것으로 유명함
      • 그의 "What goes around comes around" 논문 두 편을 참고하면 데이터베이스 분야의 과거와 미래를 쉽게 조망할 수 있음
      • CMU Seminar Series도 훌륭하고, 그가 참여해 더욱 기대됨
      • 중국인 공동 저자분들에 대해서는 잘 모르지만 죄송하게 생각하고, 이 논문을 북마크해두고 꼼꼼히 읽어볼 계획임

    • Pandas의 영향력에는 팬으로서 동의하지만, 기술적으로는 Arrow 데이터 포맷이 데이터 생태계 전체에 더 큰 영향을 끼쳤다고 생각함(예시로 DataFusion 등)

      • 이제 F3의 실체가 무엇인지 확인해 보고 싶음(당신 덕분에 링크를 클릭하게 됨)

    • Wes McKinney는 Apache Arrow의 창시자이기도 함

      • 현대 데이터 분석의 핵심 컴포넌트임

    • Parquet에 대한 그의 작업이 오히려 더 신뢰감을 준다고 생각함

    • 데이터와 코드를 섞는 건 고전적인 보안 실수임

      • 유명인이 참여해도 실수가 사라지진 않음

  • 물리학자들의 미래에는 적용되지 않을 것 같음

  • 컬럼 지향 저장 방식과의 차이를 잘 이해하지 못하는 점에 대해 양해를 구하고 싶음

    • 왜 이게 혁신적인지 궁금한데, "작은 벡터 임베딩 데이터베이스를 샌드박스와 함께 전송하는 게 핵심인가?"라는 질문이 있음

    • 논문에서 새로운 기반이 될 만한 느낌을 받았고, 프로젝트 명에서 프랑스식 아우라(?)도 받았음

    • 본인은 내용 대부분을 이해하지 못하고, 그림과 색감은 예쁘고 대담하다고 느낌. 쉽게 설득되는 본인 입장에서 엄지 두 개 올림

    • 핵심은 호환성 레이어임

      • 예를 들어, ORCv2는 새로운 포맷 버전을 만들고 기능을 단계적으로 배포하려다가 결국 출시하지 못함
      • 만일 새로운 float 인코딩을 WASM shim과 함께 파일로 배포할 수 있었다면, 읽기 소프트웨어 업데이트나 호환성 문제 없이 쉽게 새로운 포맷을 전달할 수 있었음
      • Spark의 variant 타입처럼 복잡한 recombination이 필요할 때도 해석기 대신 바이트코드로 전달하면 훨씬 쉬움
      • 개인적으로 ORC 튜닝하며 밤새다 bench에서 잘 버텨주는 모습에 뿌듯함

    • 컬럼 저장 방식의 진짜 장점은 복잡한 네스티드 스키마를 primitive 값으로 쪼개서 저장할 수 있다는 점임

      • leaf 값을 직접 읽으면서 IO와 파싱 효율이 대폭 올라감
      • 포맷들은 최상위 레벨에서 row 그룹 단위로 파티셔닝됨
      • 이번 포맷은 Apache Arrow 버퍼를 데이터 페이지에서 직접 받을 수 있게 해줌(WASM 사용이나 네이티브 디코더로)
      • Parquet는 현재 매우 복잡함. Dremel 인코딩을 써서 primitive 값을 두 개의 정수 스트림(repetition/definition level)과 함께 저장, 일반인은 파싱하기 어려움
      • 특히 bit-packing+RLE이 혼합되어 있고, 레퍼런스 구현에서만 bit-packing 코드가 7만 4천 줄임
      • Arrow 버퍼로 변환하려면 상당한 작업이 필요함. F3라면 훨씬 쉽고 미래 호환성도 높을 것
      • 또, 메타데이터 random access가 가능해진다는 점도 큼
      • 예시로, GeoParquet 사용 시 SQLite 인덱스를 걸지 않으면 spatial query 하나에 평균 10분, 500개 파일 footer 파싱에 150MB Thrift 파싱이 요구됨
      • Flatbuffers 선택은 의외임. Flatbuffers의 메모리 안전 문제가 알려져 있음(관련 지적)
      • 오히려 SQLite 데이터베이스를 집어넣는 게 낫지 않을까 생각함

    • 컬럼 지향 저장의 진짜 이득은 전체 column을 한 번에 매우 빠르게 스캔할 수 있다는 데 있음

      • OS 버퍼를 아주 효율적으로 사용할 수 있게 해줌. 예를 들어 select a where b = 'x' 쿼리가 매우 빨라짐

  • wasm 디코더가 네이티브 대비 10-30% 느린 건 많이 아쉬움

    • 이를테면 처음부터 10-30% 성능 저하를 감수하는 것이고, 앞으로 디코더를 개선할 기회도 영구히 포기하는 것임

    • "전체 블록 디코딩 & 메모리 저장" 외의 고급 디코딩 기능도 못 쓰게 됨

    • 정말 왜 굳이 이렇게 만드는지 이해가 가지 않음

    • 속도가 중요하다면 wasm이 해답이 아니고, 속도가 별로라면 잘 알려진 인코딩을 쓰면 될 것임

    • WASM은 백업 용도로 제공됨

      • 네이티브 디코더(예: crate)가 설치되어 있으면 그걸 먼저 사용하고, 없으면 WASM으로 fallback
      • 10-30% 손해를 감수하는 건 파일을 아예 읽지 못하는 것보단 낫다는 입장임

    • 동의하는 부분도 있지만 얘기는 좀 더 복잡함

      • 이미 다양한 압축 방법 사용 시에도 비슷한 상황이 반복됨
      • 예를 들어 bitpack 방식이나 압축변경 시마다 "트랜스코딩", 즉 파일 재작성 필요
      • WASM 도입 후에도 마찬가지로 파일 재작성 필요
      • 미래지향성 확보가 그만한 가치가 있을지는 의문임. exabyte 규모 시스템에서 데이터 재인코딩은 정말 힘듦

  • Vortex와 F3의 관계가 정확히 이해되지 않음

    • 둘 다 "새로운 포맷을 만들지 않고도 인코딩 방식을 쉽게 추가 가능하도록 설계한다"는 비전을 얘기함

    • 소개글에는 Vortex의 인코딩 구현을 쓴다고 나와 있지만, 타입 시스템은 다르다고 적혀 있음

    • 프로젝트 진행 배경이 복잡함

      • 초기엔 CMU, Tsinghua, Meta, CWI, VoltronData, Nvidia, SpiralDB가 컨소시엄을 만들어 하나의 파일포맷을 통합하려 했음
      • 하지만 Meta NDA(비밀유지계약)에 관한 CMU 변호사의 이슈로 무산됨
      • 그래서 모두 각자 파일포맷 출시
      • 연구적으로는 CMU+Tsinghua는 인코더 개발보다 WASM 삽입에 집중
      • DuckDB의 Hannes가 Wes McKinney에게 처음 아이디어 제안
      • Vortex 인코딩 구현이 Rust 기반이라 손질하면 대부분 WASM으로 컴파일 가능
      • Vortex는 F3와 별개의 독립 프로젝트이며, F3는 현재 학술용 프로토타입임
      • 독일에서도 올해 별도 WASM 활용 포맷 출시: AnyBlox 포맷(파일 전체를 WASM으로 만듦. F3는 컬럼 그룹 단위)

  • 내년에 F4 발표도 기대하게 됨

  • 소스코드가 어디 있는지 한참 찾았는데, 여기서 공개 중임

  • 데이터를 읽으려면 반드시 webassembly를 실행해야 하는 의무가 생겨, 의존성이나 bloat를 줄이고픈 환경에는 적합하지 않다고 생각함

    • wasm은 단순함

      • "web"과는 별개임
      • 다른 이가 말했듯, wasm은 백업임
      • 네이티브 코딩(biding)을 제공하면 성능이 더 좋아짐

    • 네이티브 디코더가 있다면 WASM을 쓸 필요 없음

      • 이 점은 초록글에도 명확히 나옴

  • WebAssembly 모듈을 임베드한 첫 파일포맷 중 하나인 것 같음

    • 압축 측면에서 특히 관심 있음. WASM preprocessor를 잘 설계하면 압축률이 크게 향상될 수 있다는 입장

    • 나 역시 이 컨셉으로 파일포맷을 만들고 있음

    • Alan Kay가 60년대에 한 프로그래머가 만든 것으로 추정되는 테이프 기반 저장 시스템을 ‘최초의 객체지향 시스템’이라 설명한 적 있음

      • 테이프의 포맷이 특정 위치 읽기, 쓰기 루틴 셋을 포함
      • 즉, 선행 사례(reference)가 존재함
      • 관련 논문 링크 (4페이지)
답변달기