# F3 - 미래를 위한 오픈소스 데이터 파일 포맷 > Clean Markdown view of GeekNews topic #23411. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=23411](https://news.hada.io/topic?id=23411) - GeekNews Markdown: [https://news.hada.io/topic/23411.md](https://news.hada.io/topic/23411.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-10-03T01:34:31+09:00 - Updated: 2025-10-03T01:34:31+09:00 - Original source: [db.cs.cmu.edu](https://db.cs.cmu.edu/papers/2025/zeng-sigmod2025.pdf) - Points: 9 - Comments: 1 ## Summary 데이터 분석과 머신러닝 워크로드가 복잡해짐에 따라, F3는 **상호운용성**, **확장성** 그리고 **효율성**을 동시에 해결할 수 있도록 **자기서술적 파일 구조**와 **WebAssembly(Wasm) 기반 디코더 임베딩**을 도입한 파일 포맷입니다. 기존 Parquet, ORC 등 구식 데이터 포맷의 하드웨어 및 접근 패턴 가정에 따른 한계를 뛰어넘어, F3는 **계단식 압축·벡터화 디코딩** 등 최신 인코딩 기술과 **플러그인 기반 디코딩 API**를 제공해 새로운 기능 추가와 파일 포맷 진화를 유연하게 지원합니다. F3는 미래 데이터 시스템의 변화에도 민첩하게 대응할 수 있는 오픈소스 파일 포맷으로 주목받고 있습니다. ## Topic Body - **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%의 성능 저하로 허용 가능한 범위 ## Comments ### Comment 44507 - Author: neo - Created: 2025-10-03T01:34:32+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45437759) - 빠르게 살펴본 결과, 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 토론](https://stackoverflow.com/questions/31812780/append-a-new-column-to-an-existing-parquet-file) - 요즘 압축 방식은 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에 대한 그의 작업이 오히려 더 신뢰감을 준다고 생각함 - 데이터와 코드를 섞는 건 고전적인 보안 실수임 - 유명인이 참여해도 실수가 사라지진 않음 - 물리학자들의 미래에는 적용되지 않을 것 같음 - 앞으로 20년간 CERN의 Large Hadron Collider에서 생산되는 엑사바이트급 데이터는 CERN이 자체 개발한 포맷을 사용함 - [CERN 데이터 포맷 관련 자료](https://cds.cern.ch/record/2923186/) - CERN은 이 분야에서 대부분 사람보다 훨씬 일찍부터 대용량 데이터를 다뤄왔음 - [Zebra 포맷 관련 역사적 자료](https://cds.cern.ch/record/2296399/files/zebra.pdf) - 컬럼 지향 저장 방식과의 차이를 잘 이해하지 못하는 점에 대해 양해를 구하고 싶음 - 왜 이게 혁신적인지 궁금한데, "작은 벡터 임베딩 데이터베이스를 샌드박스와 함께 전송하는 게 핵심인가?"라는 질문이 있음 - 논문에서 새로운 기반이 될 만한 느낌을 받았고, 프로젝트 명에서 프랑스식 아우라(?)도 받았음 - 본인은 내용 대부분을 이해하지 못하고, 그림과 색감은 예쁘고 대담하다고 느낌. 쉽게 설득되는 본인 입장에서 엄지 두 개 올림 - 핵심은 호환성 레이어임 - 예를 들어, 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의 메모리 안전 문제가 알려져 있음([관련 지적](https://rustsec.org/advisories/RUSTSEC-2021-0122.html)) - 오히려 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 변호사의 이슈로 무산됨 - 그래서 모두 각자 파일포맷 출시 - [Meta의 Nimble](https://github.com/facebookincubator/nimble) - [CWI의 FastLanes](https://github.com/cwida/FastLanes) - [SpiralDB의 Vortex](https://vortex.dev) - [CMU+Tsinghua F3](https://github.com/future-file-format/f3) - 연구적으로는 CMU+Tsinghua는 인코더 개발보다 WASM 삽입에 집중 - DuckDB의 Hannes가 Wes McKinney에게 처음 아이디어 제안 - Vortex 인코딩 구현이 Rust 기반이라 손질하면 대부분 WASM으로 컴파일 가능 - Vortex는 F3와 별개의 독립 프로젝트이며, F3는 현재 학술용 프로토타입임 - 독일에서도 올해 별도 WASM 활용 포맷 출시: [AnyBlox 포맷](https://github.com/AnyBlox)(파일 전체를 WASM으로 만듦. F3는 컬럼 그룹 단위) - 내년에 F4 발표도 기대하게 됨 - 소스코드가 어디 있는지 한참 찾았는데, [여기서 공개 중임](https://github.com/future-file-format/F3) - 데이터를 읽으려면 반드시 webassembly를 실행해야 하는 의무가 생겨, 의존성이나 bloat를 줄이고픈 환경에는 적합하지 않다고 생각함 - wasm은 단순함 - "web"과는 별개임 - 다른 이가 말했듯, wasm은 백업임 - 네이티브 코딩(biding)을 제공하면 성능이 더 좋아짐 - 네이티브 디코더가 있다면 WASM을 쓸 필요 없음 - 이 점은 초록글에도 명확히 나옴 - WebAssembly 모듈을 임베드한 첫 파일포맷 중 하나인 것 같음 - 압축 측면에서 특히 관심 있음. WASM preprocessor를 잘 설계하면 압축률이 크게 향상될 수 있다는 입장 - 나 역시 이 컨셉으로 파일포맷을 만들고 있음 - Alan Kay가 60년대에 한 프로그래머가 만든 것으로 추정되는 테이프 기반 저장 시스템을 ‘최초의 객체지향 시스템’이라 설명한 적 있음 - 테이프의 포맷이 특정 위치 읽기, 쓰기 루틴 셋을 포함 - 즉, 선행 사례(reference)가 존재함 - [관련 논문 링크](https://www.cs.tufts.edu/comp/150FP/archive/alan-kay/smalltalk-hopl-ii.pdf) (4페이지)