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

 (github.com/future-file-format)
3P by GN⁺ | ★ favorite | 댓글 1개
  • F3는 효율성, 상호운용성, 확장성을 염두에 두고 설계된 데이터 파일 형식임
  • Parquet 같은 이전 세대 형식의 레이아웃 한계를 바로잡는 데이터 조직 방식을 제공하면서, 내장 Wasm 디코더를 통해 상호운용성과 확장성을 유지함
  • 자체 설명형 F3 파일은 데이터와 메타데이터뿐 아니라 데이터를 디코딩하는 WebAssembly 바이너리를 함께 담는 구조임
  • 파일에 디코더를 내장하는 방식은 킬로바이트 단위의 최소 저장 공간을 요구하며, 네이티브 디코더가 없을 때도 어떤 플랫폼에서든 호환성을 보장하기 위한 설계임
  • 개발자가 새 인코딩 방식을 쉽게 추가할 수 있도록 데이터 조직 구조와 범용 API를 제공하는 Future-proof File Format 프로젝트임
  • 현재 상태는 논문의 아이디어를 검증하는 연구 프로토타입이며, 프로덕션 사용 금지 대상임
  • 빌드는 Intel 머신의 Debian 12에서만 테스트되었고, PoC 패키지 빌드와 단위 테스트는 cargo build -p fff-poc, cargo test -p fff-poc로 실행하는 방식임
  • 파일 형식 정의는 FlatBuffer 기반이며, 주요 코드와 Wasm 디코딩 구현, 논문 실험용 벤치마크와 스크립트를 함께 제공함
  • 라이선스는 MIT License임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 왜 이렇게 추천을 많이 받았는지 잘 모르겠고, 랜딩 페이지도 별로라서 논문을 보는 편이 나아 보임: https://dl.acm.org/doi/epdf/10.1145/3749163
    Parquet의 단점을 일부 보완하려는 컬럼 지향 저장 형식처럼 보이지만, 이런 형식의 진짜 승부처는 호환성이고 새 형식은 등장하는 순간 그 점에서 불리함
    Parquet은 최초로 널리 퍼졌다는 이유만으로도 너무 강하고, 논문에 따르면 가장 많이 쓰이는 Parquet 버전도 2013년의 가장 오래된 버전이라 Parquet조차 Parquet을 대체하지 못한 셈임
    F3가 이를 넘으려면 아주 강한 결과가 필요해 보이는데, 그렇게 보이지는 않음
    개인적으로 Parquet의 가장 큰 불만인 파일당 단일 테이블 문제도 다루지 않아 이름도 좀 과장된 느낌이고, 디코딩용 Wasm 바이너리를 넣으면서도 그 덩어리를 파싱하려면 FlatBuffers가 필요하다는 점도 목적을 흐림
    주된 성과는 임의 접근 개선처럼 보이지만, 컬럼 지향 저장은 원래 임의 접근을 포기하고 빠른 분석을 얻기 위해 생긴 것이며 F3는 Wasm 디코더 때문에 빠른 분석을 희생하는 것 같아 이해가 잘 안 됨

    • Parquet의 파일당 단일 테이블은 파일 형식 자체보다 쿼리 엔진이 파일 형식에 부여한 기대에 가까움
      Spark, DataFusion, DuckDB는 다중 테이블 파일을 받아도 뭘 해야 할지 잘 모를 것임
      Parquet이 많은 일을 잘하는 건 맞지만, 먼저 나왔다는 이유만으로 영원히 유일한 분석용 파일 형식이어야 한다는 뜻은 아님
      빠른 분석과 최신 기계학습형 작업 부하는 본질적으로 일괄 스캔과 임의 접근이 섞여 있음
      F3 저자 일부가 Parquet의 단점을 자세히 다룬 논문도 쓴 적 있음: https://www.vldb.org/pvldb/vol17/p148-zeng.pdf
      최근 나온 Vortex, Lance, F3 같은 형식들은 그 논문에서 정리한 문제를 풀려 하고 있음
      Lance에는 흥미로운 아이디어가 있고, Vortex는 Parquet의 블랙박스 인코더를 투명한 인코딩으로 바꿔 확장성과 성능에 집중함
      이를 통해 대량 디코딩과 요소 단위 디코딩의 절충을 줄여 효율적인 전체 스캔과 매우 빠른 임의 접근을 함께 얻을 수 있음
      예를 들어 LangChain은 Parquet 파일 기반 시스템을 Vortex로 다시 만들고 큰 속도 향상을 봤다고 설명함: https://www.langchain.com/blog/introducing-smithdb
      참고로 Vortex를 개발하고 있어서 “새 형식을 왜 만들까”라는 질문을 직접 많이 고민해 봄
    • Parquet의 단순함은 단점이 아니라 장점이라고 봄
      여러 테이블이 필요하면 Parquet 파일 여러 개를 tar로 묶으면 되고, tar와 Parquet 라이브러리가 있는 어떤 언어에서도 읽기 쉬워서 아름답게 단순함
    • Parquet을 다룰 때 .parquetz라는 형식을 상상한 적 있음
      압축하지 않은 Parquet 파일을 여러 개 담은 zip 파일이라면 단일 파일로 여러 테이블을 옮길 수 있고, 범위 요청으로 접근도 가능할 것임
    • 요즘 대부분의 랜딩 페이지가 ChatGPT로 만든 듯한 잡음으로 가득한 것에 비하면, 이건 오히려 변화가 있음

  • 언어별 SDK나 라이브러리에 의존하지 않고, 없으면 내장된 Wasm 메서드로 폴백할 수 있다는 점은 꽤 기발함
    “각 자기기술형 F3 파일은 데이터와 메타데이터뿐 아니라 데이터를 디코딩하는 WebAssembly(Wasm) 바이너리도 포함한다. 각 파일에 디코더를 내장하는 데 필요한 저장 공간은 작고(킬로바이트 단위), 네이티브 디코더가 없을 때도 모든 플랫폼에서 호환성을 보장한다”

    • 공격자가 일부러 손상된 파일을 만들 필요도 없고, 데이터 파일 자체에 공격 코드를 넣으면 되는 건가?
    • 멋져 보이지만 복잡도가 높은 형식에서는 무너질 수 있을 것 같음
      PDF용 내장 디코더는 어떤 모습일까?
      파일 바이트와 강하게 결합되어 있으니 파일 작성자가 어떤 형식이 합리적인지 고를 수는 있겠지만, 모든 형식에 유일한 “정답 디코딩 단계”가 있는 건 아님
    • 이게 어떻게 동작해야 하는지 이해가 안 됨
      디코더는 무엇으로 디코딩하는가?
      데이터 종류에 완전히 의존할 텐데, 어떤 형식은 바이트 스트림이고, 어떤 형식은 2차원 픽셀 평면이며, 또 어떤 형식은 정점, 2차원 픽셀 평면, UV 맵이 필요하고, 어떤 경우에는 객체 그래프가 더 자연스러움
    • Applet의 재등장처럼 보임
    • Wasm이 C 바인딩보다 나은 점이 무엇인가?

  • 사람들이 뭘 보고 이야기하는지 모르겠음
    README에는 이것이 무엇인지, 어떤 문제를 푸는지에 대한 정보가 거의 없고, FlatBuffers 설명과 소스 코드 디렉터리 링크만 보임
    어떤 맥락을 놓친 걸까?

  • “왜”가 조금 더 필요해 보임
    Parquet의 단점을 극복한다고 하는데, 어떤 단점인지 궁금함
    넓은 도구 지원은 확실히 아닐 것임
    왜 Parquet이나 ORC를 떠나 이 구조를 써야 하는가?

    • “왜”는 README 끝의 참고문헌에 연결되어 있고, 이 저장소만 단독으로 소비하라고 만든 것은 아닌 듯함
      논문부터 보는 편이 좋음: https://doi.org/10.1145/3749163
    • 무슨 이야기를 하는지 처음엔 전혀 몰랐지만, Parquet이 하드웨어를 잘 고려하지 않고 메타데이터가 다소 전역적이라는 점에 대한 좋은 포인트가 있음
      이 글이 흥미로웠음: https://medium.com/@reliabledataengineering/f3-the-future-pr...
    • 이 중 상당수는 Parquet에 개발 시간을 더 투입하면 처리할 수 있을 것 같음
    • 논문에서는 Parquet, ORC, Nimble, Lance, TSFile, Bullion, BtrBlocks를 언급함

  • 어떤 사람들은 천재적이라고 했지만, 성가신 HN 회의론자 역할을 해보자면 다소 어리석어 보임
    데이터 압축 형식은 디코딩 후 그 데이터로 무엇을 할지에 비하면 부차적임
    오디오 파일과 SVG 이미지는 완전히 다르고, 비디오를 원시 픽셀로 푸는 내장 VM이 있다고 해서 텍스트 편집기에서 그 비디오를 재생할 수 있는 건 아니므로 근본적으로 새로운 상호운용성이 생기지는 않음
    새 형식마다 여전히 형식별 처리가 필요함
    예를 들어 H.265보다 나은 비디오 압축 방식을 만들었지만 모든 플랫폼이 지원하지 않을 때, 디코더를 내장해 구형 하드웨어에서 재생하게 하는 용도는 있을 수 있음
    하지만 그 역시 약점을 드러냄. 구형 하드웨어가 미래의 비디오 형식을 소프트웨어 디코딩으로 잘 처리할 가능성은 낮고, 이 아이디어가 1990년대에 나왔다고 해서 i386에서 Netflix를 볼 수 있게 되지는 않았을 것임
    마찬가지로 Word 2021 파일을 Word 97에서 열 수 있게 해줬을지도 의심스럽고, 데이터 구조 사이에 1:1 대응이 없음
    이런 호환성이 확실한 승리가 아니라면 목표가 무엇인지 모르겠음
    단점은 분명함. 디코더에 고쳐야 할 버그가 생기면 이미 그 디코더를 내장한 모든 파일을 어떻게 패치할 것인가?
    여기에 크기 오버헤드와 보안 위험도 있고, 모든 형식 파서에 상당한 공격 표면을 추가하는 셈이라 원격 코드 실행, 자원 고갈 공격 등의 기회가 늘어남
    항상 틀린 접근은 아니지만, 이득이 무엇인지가 중요함

    • 이 계열의 형식이 푸는 문제를 아직 접하지 않은 것 같음
      컬럼 지향 저장 형식을 찾아보면 장단점은 요즘 꽤 잘 정리되어 있음
      물론 비디오 디코딩용은 아님

  • 일부 현대적 형식의 장점은 도구들이 매우 높은 체감 속도로 읽을 수 있다는 것임
    예를 들어 DuckDB는 자체 네이티브 형식이나 Parquet을 읽을 때 온갖 최적화를 적용할 수 있음
    그런데 형식을 이해하려면 Wasm 덩어리를 실행해야 하는 형식에도 그런 최적화를 효과적으로 적용할 수 있을지 잘 모르겠음
    SIMD가 아니든 SIMD 최적화가 되었든 데이터를 한 번 훑는 동안 그 패스가 쿼리를 이해하지 못한다면 이미 손해를 봤을 수 있음
    논문 앞부분만 훑었으니 실제 형식은 들리는 것보다 덜 일반적일 수도 있음

    • 이해하기로는 폴백 메커니즘임

  • 자체 압축 해제 EXE를 대체하는 모습은 어느 정도 상상되지만, 특정 파일 형식을 고르는 이유의 상당수는 그 형식이 제공하는 구체적 기능 때문임
    자기기술형 시스템도 다른 형식과 똑같이 “경쟁 기능이 너무 많고 아무도 전부 처리하지 못하는” 상태에 빠질 수 있음
    예를 들어 이 파일은 효율적으로 mmap될 수 있는가?
    내부적으로 tar를 흉내 내면 가능할지도 모르지만 실행해 보기 전에는 모름
    특정 바이트 위치로 이동해 일부만 압축 해제할 수 있는가?
    ISO-36898533 탐색의 사전 공개 버전만 지원하고, 사용 중인 파일 라이브러리는 6년 전에 그 지원을 제거했을 수도 있음
    가운데 1MB를 다시 쓰면 디스크의 해당 페이지만 바꾸면 되는가, 아니면 전체를 다시 써야 하는가?
    Wasm 덩어리가 이를 위한 API 97개를 지원하고, 그중 35개는 이름만 다른 복사본이라 데이터보다 커졌지만 아무도 신경 쓰지 않았을 수 있음
    결국 인식 가능한 선택지는 19개인데 CPU의 네이티브 Wasm 가속기는 두세 개만 처리해서 여전히 코드를 심하게 특화해야 할 수도 있음
    적어도 *.tar.gz라면 무엇이 가능한지 어느 정도 짐작은 됨

  • 좋음. 세상에는 더 나은 데이터 형식이 늘 필요함
    다만 README에 Parquet과 다른 파일 형식 대비 장점을 바로 적으면 더 관심을 얻을 것 같음
    누군가 https://github.com/future-file-format/f3에 들어갔을 때 왜 써봐야 하는지 볼 수 있어야 함
    장점과 지표를 올리고, 지표는 유리한 것만 골라도 됨
    좋은 사용처가 있을 가능성은 있지만, 현재 README만 보면 누가 왜 써야 하는지 명확하지 않음

  • PB 단위 데이터를 10년 이상 보관한다면, 파일을 읽기 위해 미래에도 Wasm 인터프리터가 존재하고 충분히 빠를 것이라고 의존하고 싶지 않음
    Parquet처럼 단순하고 문서화가 잘 된 바이트 명세를 원함
    게다가 디코딩 로직을 Wasm 바이너리 안에 넣는 것은 콜드 스토리지여야 할 곳에 능동 실행 계층을 추가하는 일임

    • WinRAR 형식도 미디어 파일에서 최신 압축을 달성하려고 아카이브 일부로 RAR VM 바이트코드를 포함
      샌드박스 처리되어 널리 받아들여졌고, Wasm에도 같은 샌드박스 능력이 있음
      장기 보관에는 오히려 더 낫다고 볼 수 있음
      압축 해제 프로그램을 따로 들고 다닐 필요가 없고, 아카이브 파일 자체에 들어 있기 때문임
    • 단일 데이터 레코드를 읽을 때마다 10년 된 맞춤형 데이터 파싱 함수를 실행하고 싶지 않다는 뜻인가?

  • 디코딩이 실패하면 다른 누군가가 넣은 Wasm을 디버그해야 하고, 거기에 임의의 버그가 들어 있을 수 있다는 게 걱정됨
    프로젝트가 관리하고 테스트하는 표준 디코더 라이브러리가 있으면 도움이 될 수 있겠지만, 그러면 이 방식이 제공하는 유연성의 장점을 죽이는지는 잘 모르겠음

    • Wasm은 결정적 실행이므로 내 쪽에서 디코딩이 실패했다면 만든 쪽에서도 실패했어야 함
      즉 내 시스템이 새로 만든 문제가 아니고, 어떤 클라이언트와도 독립적으로 그들이 재현할 수 있어야 함
답변달기