차세대 데이터 파일 포맷 F3, 디코더를 Wasm으로 파일 안에 넣자는 실험

• F3는 Parquet, ORC 이후 세대를 노리는 오픈소스 데이터 파일 포맷 연구 프로토타입임

  • 목표는 효율성, 상호운용성, 확장성이고, 이름도 Future-proof File Format에서 온 F3임
  • 논문 아이디어를 검증하는 코드라서 README에 대놓고 “운영 환경에서 쓰지 말라”고 적혀 있음

• 핵심 문제의식은 기존 컬럼형 포맷이 10년 전 하드웨어와 워크로드를 기준으로 만들어졌다는 점임

  • Parquet, ORC는 데이터 공유에는 엄청 성공했지만, 새 인코딩이나 새 처리 방식이 필요할 때 포맷과 구현체가 같이 발목을 잡는 경우가 생김
  • 일부 스펙 업데이트가 있어도 모든 배포 환경이 그걸 지원하는 건 아니라서, 결국 시스템 쪽에서 우회하거나 큰 재작성으로 이어질 수 있음

• F3의 제일 특이한 설계는 파일 안에 WebAssembly(Wasm) 디코더를 같이 넣는 방식임

  • F3 파일은 데이터, 메타데이터, 그리고 데이터를 해석할 Wasm 바이너리를 함께 포함하는 자기 설명형 파일(self-describing file)을 지향함
  • 네이티브 디코더가 없는 플랫폼에서도 Wasm 디코더를 실행해서 데이터를 읽을 수 있게 하자는 발상임
  • 디코더를 넣는 비용은 킬로바이트 수준이라고 설명하고 있어서, 저장 공간 오버헤드는 작게 잡고 있음

• 프로젝트 구조도 연구용 포맷 실험에 맞춰 꽤 노골적으로 나뉘어 있음

  • format에는 파일 포맷의 FlatBuffer 정의가 들어가고, fff-poc가 F3 포맷의 메인 구현임
  • fff-bench에는 논문에 나온 마이크로 벤치마크와 엔드투엔드 실험이 들어 있음
  • fff-ude* 계열 디렉터리는 User-Defined-Encoding, 즉 Wasm 기반 디코딩 구현과 관련됨

• 지금 당장 실무에 넣을 물건은 아님
  • 테스트도 Debian 12가 설치된 Intel 머신에서만 해봤다고 밝힘
  • 빌드는 Rust 기반이고, cargo build -p fff-poc, cargo test -p fff-poc 같은 식으로 PoC 패키지를 다루게 되어 있음
  • 그래도 논문과 벤치마크 재현 스크립트를 공개했다는 점에서 데이터 시스템 쪽 개발자라면 읽어볼 만한 떡밥임

---

기술 맥락

• F3가 고른 선택은 “파일 포맷에 디코더까지 포함하자”는 쪽이에요. 왜냐하면 데이터 포맷은 저장된 뒤 수년에서 수십 년 동안 살아남는데, 읽는 시스템의 구현체는 그 속도를 못 따라가는 경우가 많거든요.

• Parquet 같은 포맷은 이미 생태계가 크지만, 새 압축 방식이나 인코딩을 넣으려면 각 엔진이 전부 따라와야 해요. F3는 Wasm 디코더를 파일에 넣어서 이 병목을 줄이려는 거예요.

• 여기서 Wasm이 중요한 이유는 플랫폼 독립성과 샌드박스 실행이에요. 네이티브 플러그인을 아무거나 로드하는 건 위험하고 배포도 까다로운데, Wasm은 비교적 통제된 방식으로 “이 파일을 읽는 법”을 같이 운반할 수 있거든요.

• 다만 이건 아직 연구 프로토타입이에요. 실제 운영에서 쓰려면 성능뿐 아니라 보안 검증, 런타임 호환성, 장기 보존성, 여러 쿼리 엔진과의 통합 문제가 같이 풀려야 해요.