본문으로 건너뛰기
J
피드

Parquet/Iceberg를 대체할 Lance 포맷, 애니메이션으로 쉽게 이해하기

backend 약 4분
tags
#lance#parquet#iceberg#data-lake#object-storage
vote
0
댓글
북마크

Lance는 Parquet(파일 포맷) + Iceberg(테이블 포맷) + 카탈로그 스펙을 하나로 통합한 차세대 데이터 포맷임. 랜덤 읽기 최적화, 데이터 복사 없는 ad-hoc 컬럼 추가, BTree/역색인/벡터 인덱스 내장 등 기존 스택의 한계를 해결함. AI 시대의 멀티모달 데이터 레이크 수요가 이런 기술의 등장 배경임.

  • 1

    Lance 파일 포맷은 Parquet 대비 랜덤 읽기(WHERE id=123)에 최적화되면서 순차 읽기 성능도 유지

  • 2

    Lance 테이블 포맷은 Iceberg와 달리 데이터 복사 없이 ad-hoc 컬럼 추가 가능하며 MVCC 지원

  • 3

    BTree, 역색인(FTS), HNSW 벡터 인덱스를 테이블 레벨에서 내장 지원

  • 4

    SpiralDB의 vortex도 Parquet 경쟁 포맷으로 등장, LanceDB와 직접 경쟁 구도

  • 5

    2025년 빅데이터 업계 인수합병 활발: Datadog-Quickwit, Databricks-Neon

2025년 빅데이터 업계 주요 이벤트

  • 2025년 오브젝트 스토리지 기반 빅데이터 세계에서 굵직한 일들이 많았음: Iceberg V3 스펙 릴리스(VARIANT 타입 추가), turbopuffer의 오브젝트 스토리지 위 벡터 검색 발표, Apache Fluss의 Flink 기반 실시간 스트림 티어링 등
  • Datadog이 Quickwit을 인수했고, Databricks가 Neon을 인수함
  • 그런데 이 모든 것보다 더 중요한 게 레이더 밑으로 지나갔는데, 바로 Lance임

Lance란 무엇인가

  • Lance는 파일 포맷(Parquet 대응), 테이블 포맷(Iceberg 대응), 카탈로그 스펙(Iceberg REST catalog 대응)을 모두 포함하는 올인원 포맷임
  • 기존 빅데이터 스택에서 각각 별도 레이어로 존재하던 것들을 하나로 통합한 셈

Lance 파일 포맷 — Parquet와의 차이

  • Parquet는 컬럼 전체를 순차적으로 읽는 데 최적화되어 있지만, WHERE id = 123 같은 랜덤 읽기에는 느림
  • Lance 파일 포맷은 랜덤 읽기에 최적화되면서도 Parquet의 순차 읽기 성능은 그대로 유지함
  • Parquet가 기본 1MB 페이지 단위인 반면, Lance는 더 작은 단위로 데이터를 구성해서 포인트 쿼리 성능이 좋음

Lance 테이블 포맷 — Iceberg와의 차이

  • Iceberg에서 새 컬럼을 추가하려면 기존 데이터를 전부 복사해야 됨. Lance는 ad-hoc 컬럼 추가 시 데이터 복사 없이 바로 추가 가능함
  • Iceberg의 핵심인 MVCC(다중 버전 동시성 제어)는 그대로 지원함
  • 테이블 레벨에서 인덱스를 직접 지원하는 것도 큰 장점임: BTree, 역색인(Full-Text Search), 벡터 인덱스(HNSW) 등을 내장하고 있음

경쟁자와 AI 시대의 맥락

  • SpiralDB가 만든 vortex라는 오픈소스 파일 포맷도 Parquet의 경쟁자로 등장함. LanceDB와 직접 경쟁 구도
  • 이런 기술들이 등장한 배경은 AI 시대에 멀티모달 데이터 레이크의 필요성이 커졌기 때문임 — 텍스트, 이미지, 벡터 등 다양한 데이터를 하나의 레이크에서 처리해야 하는 수요가 폭발적으로 증가함
  • AI 소프트웨어 시대가 또 어떤 새로운 기술들을 만들어낼지 주목할 만함

오브젝트 스토리지 위의 데이터 레이크 스택이 AI 워크로드에 맞게 재편되고 있음. Parquet+Iceberg 조합이 사실상 표준이었지만, 벡터 검색과 멀티모달 데이터 처리가 필수가 되면서 Lance처럼 인덱스와 랜덤 액세스를 1급 시민으로 지원하는 포맷이 부상하는 흐름임.

prev

이전 기사 (P)

next

다음 기사 (N)

댓글

댓글

댓글을 불러오는 중...

관련 기사

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.