lakeFS vs DVC: 버전 관리, 파일 시스템이 되기를 원하다
업데이트 날짜: 2025년 9월 28일
12 분
lakeFS vs DVC: 버전 제어가 파일 시스템이 되기를 원한다
데이터 버전 제어에 대해 이야기할 때 사람들은 모두 Git이 모든 것에 적용되는 것처럼 고개를 끄덕이지만, 실제로는 페타바이트 단위의 데이터를 팀 전체에서 사용하려고 할 때 Git은 코드에 특화된 도구였다는 것을 깨닫게 됩니다. 사람들은 “S3 버킷을 저장소처럼 다루세요”라고 말하지만, 이는 마치 오케스트라에게 카주가 악기라는 이유로 사용하라고 말하는 것과 같습니다.
이것은 슬로건을 공유하는 두 가지 세계관에 대한 이야기입니다. 바로 lakeFS vs DVC입니다. 둘 다 데이터, 모델, 실험이 혼란스러워지는 상황에서 제정신을 유지할 수 있다고 약속하지만, 문제에 접근하는 방식은 정반대입니다. DVC는 개발자 우선의 Git 인접 툴킷으로, 저장소와 함께 사용됩니다. lakeFS는 스토리지 네이티브 레이어로, 객체 저장소를 브랜치, 커밋, 병합이 가능한 버전 관리 파일 시스템으로 바꿔줍니다. 멜로디는 같지만, 키가 다른 셈입니다.
만약 결론을 보러 오셨다면, 이미 어느 진영에 속해 있는지 알고 계실 겁니다. 일상적으로 큰 파일과 모델 체크포인트를 재현 가능하게 이동하는 데 어려움을 겪고 있다면 DVC는 매우 영리한 연장 코드처럼 느껴질 것입니다. 만약 데이터 거버넌스, 격리, 데이터 레이크에 대한 재현 가능한 읽기에 어려움을 겪고 있다면 lakeFS는 실제 집에 회로 차단기를 설치하는 것처럼 느껴질 것입니다.
물론 둘 다 사용할 수도 있습니다. 이는 회피가 아니라, 데이터 작업이 같은 티셔츠를 입은 여러 직업이라는 것을 인정하는 것입니다.
상황 설명: DVC와 lakeFS는 실제로 무엇을 하는가
- DVC (Data Version Control): Git 내부에 있는 것이 아니라, Git 옆에 존재합니다. Git에 포인터 (작은 메타 파일) 버전을 저장하고, 실제 대용량 아티팩트(데이터 세트, 모델, 이미지)는 S3, GCS, Azure, SSH 또는 로컬 캐시와 같은 원격 저장소에 저장합니다. CLI 기반 파이프라인, 재현성을 위한
dvc.lock, 실험 추적, 동기화를 위한dvc push/pull을 사용할 수 있습니다.
- lakeFS: 객체 저장소(S3, GCS, Azure Blob) 앞에 위치하여 브랜치와 커밋을 스토리지 네임스페이스의 주요 기능으로 만듭니다. 읽기와 쓰기는 격리된 브랜치를 통해 이루어집니다. “production”에서 브랜치를 생성하고, 변환을 실행한 다음, 테라바이트 단위의 데이터를 복사하지 않고 다시 병합할 수 있습니다. 데이터 레이크를 위한 Git과 유사한 의미 체계입니다.
다시 말해, DVC는 데이터 관리를 개발자 워크플로우에 접목시키고, lakeFS는 워크플로우 의미 체계를 데이터 레이어에 새겨 넣습니다.
핵심적인 차이점 (그리고 그 이유)
DVC는 대용량 데이터를 코드베이스의 확장처럼 취급합니다. 모든 것은 Git 저장소에서 시작됩니다.
*.dvc 파일을 커밋하고, 종속성을 잠그고, 파이프라인을 오케스트레이션합니다. 출처가 생성한 코드 옆에 있는 ML 실험에 적합합니다.lakeFS는 이를 뒤집습니다. 데이터 레이크가 진실의 원천입니다. 브랜치는 은유가 아니라, 동일한 기본 객체에 대한 네임스페이스입니다. 즉, 다음이 가능합니다.
- 200TB 데이터 세트의
feature/try-new-schema브랜치를 몇 초 만에 시작할 수 있습니다.
- Spark/Presto/Trino를 해당 브랜치에서 실제처럼 실행할 수 있습니다. 왜냐하면 실제이기 때문입니다.
- 전체 레이크를 섞지 않고 병합(또는 중단)할 수 있습니다.
영리한 Git 훅으로 이를 흉내 낼 수 없습니다.
lakeFS vs DVC: 마케팅 용어 없는 사용 사례
DVC가 유리한 경우
- 모델 중심 팀: 재현 가능하고 공유 가능해야 하는 코드, 데이터 스냅샷 및 실험이 있습니다. DVC의 실험 추적 및
dvc repro파이프라인이 빛을 발합니다.
- 단일 저장소 규율: 조직이 Git에 있습니다. 스토리지 추상화를 만들지 않고 “데이터를 코드로” 취급하고 싶습니다. DVC는 친숙하고
git add data.dvc로 끝납니다.
- 예산 및 단순성: 실행할 인프라 레이어가 없습니다. DVC는 일반 S3 버킷 및 권한 정책과 함께 작동할 수 있습니다. CLI는 간단합니다. 로컬 우선은 기능입니다.
lakeFS가 유리한 경우
- 대규모 팀 격리: 여러 팀이 서로 방해하지 않고 동일한 레이크에서 쓰기/읽기를 안전하게 실행해야 합니다. 브랜치 기반 격리가 핵심입니다.
- 거버넌스 및 감사: 스토리지 경계에서 커밋 기록, 재현 가능한 스냅샷 및 정책 훅을 제공합니다. 규칙이 중요한 곳에서 규칙을 적용할 수 있습니다.
- 대규모 엔진, 대규모 테이블: Spark, Hive, Presto, Trino, Snowflake 외부 테이블 - 객체 저장소를 사용하는 도구입니다. lakeFS는 URL 수준에서 통합됩니다. 컴퓨팅 스택은 새로운 트릭을 배울 필요가 없습니다.
둘 다 사용하는 경우 (그리고 똑똑하다고 느끼는 경우)
- 저장소에 연결된 모델 아티팩트 및 파이프라인에는 DVC를 사용하고, 레이크의 원시 및 큐레이션된 데이터 세트에는 lakeFS를 사용합니다. lakeFS 커밋 해시를 참조하는 DVC에서 데이터 세트 버전을 추적하고 고정합니다. 코드는 Git에 있고, 데이터 의미 체계는 레이크에 있습니다. 다른 레이어가 두 작업 모두 잘 수행할 수 있다고 가장할 필요가 없습니다.
lakeFS vs DVC: 실제적인 장단점
설정 및 운영
- DVC: CLI를 설치하고 원격을 구성합니다. 캐시 크기, 스토리지 비용 및 액세스를 관리합니다. Git은 홈베이스로 유지됩니다. 마찰이 최소화됩니다.
- lakeFS: 서비스를 실행합니다. 서버, 메타데이터, GC, 브랜칭 정책, 자격 증명이 있습니다. 어렵지는 않지만 인프라입니다. 데이터 레이크에서 실제 격리 및 원자성 커밋을 얻을 수 있습니다.
성능 및 확장성
- DVC: 로컬 캐시 및 하드링크를 사용하면 큰 아티팩트를 푸시/풀하는 것이 빠를 수 있지만 모델은 기본적으로 클라이언트 중심입니다. 페타바이트를 밀리초 만에 분기하지 않고 필요에 따라 참조하고 조각을 이동합니다.
- lakeFS: 분기는 메타데이터 비용이 저렴합니다 (copy-on-write). 읽기는 객체 저장소 읽기이기 때문에 “네이티브 속도”입니다. 쓰기는 간접 비용이 발생하지만 “전 세계 복사” 페널티는 없습니다. 병합 충돌이 존재하지만 코드 줄이 아닌 객체/키 수준에 있습니다.
재현성
- DVC:
dvc.lock은 코드, 매개 변수 및 데이터 아티팩트 해시를 함께 묶습니다. 지난달의 실험을 다시 실행하면 동일한 비트가 생성되어야 합니다. 이것은 코드 경계에서의 재현성입니다.
- lakeFS: 데이터 경계에서의 재현성: “커밋 Y 시점의 테이블 X를 읽습니다.” 분석 또는 백필을 위해 전체 입력 표면을 시간 여행할 수 있습니다.
협업 모델
- DVC: 개발자 중심 협업 - PR, 검토 및 실험. ML 루프에 적합합니다: 데이터 → 훈련 → 평가 → 배송.
- lakeFS: 데이터 팀 중심 협업 - 수집, 변환 및 유효성 검사를 위한 분기. 분석 루프에 적합합니다: 수집 → 모델 (dbt/ETL) → 게시 → 제공.
쉬운 영어로 된 데이터 계약
사람들은 “데이터 계약”이라고 말하고 스키마 레지스트리 스크린샷을 흔들기 시작합니다. 쉬운 버전은 다음과 같습니다.
- DVC에서 계약은 파이프라인에 암시적으로 있습니다. 종속성으로 선언한 파일이 계약을 구성합니다. 변경하면 파이프라인이 인식합니다.
- lakeFS에서는 병합 시 계약을 적용할 수 있습니다. 병합 전 훅은 유효성 검사 (스키마 검사, 행 수, null 임계값)를 실행하고 잘못된 데이터가
main브랜치에 도달하는 것을 차단할 수 있습니다. 방의 어른입니다.
개발자 경험 (DX): 실제 적용
- CLI 인체 공학: DVC의 CLI는 독단적이지만 예측 가능합니다.
dvc add,dvc push,dvc exp run. lakeFS의 CLI (및 UI)는 데이터 세트 수준에서 브랜치/커밋을 생각합니다.lakefs branch create,commit,merge.
- 사고 모델: DVC는 개발자에게 데이터를 해시가 있는 타사 바이너리처럼 취급하도록 요청합니다. lakeFS는 데이터 엔지니어에게 레이크를 격리 레이어가 있는 저장소처럼 취급하도록 요청합니다.
- 인지 부하: DVC는 저장소별 의례를 추가합니다. lakeFS는 인프라 및 정책을 추가합니다. 팀이 이미 있는 곳 (IDE 또는 데이터 플랫폼)을 기반으로 독을 선택하십시오.
비용: 시간, 돈 및 클라우드 이그레스 문제
- 스토리지: 둘 다 객체 저장소를 효율적으로 사용합니다. DVC는 캐시를 엉성하게 사용하면 아티팩트를 복제할 수 있습니다. lakeFS는 변동이 발생할 때까지 저렴한 copy-on-write 메타데이터에 의존합니다.
- 이그레스 및 이동: DVC의 푸시/풀은 더 많은 객체 변동을 일으킬 수 있습니다. lakeFS 읽기는 대부분 패스 스루입니다. 이그레스 비용으로 밤에 잠을 이루지 못하면 lakeFS의 “복사 없는 브랜치” 모델이 좋습니다.
- 운영 오버헤드: DVC의 비용은 주로 개발자 시간입니다. lakeFS의 비용은 서비스 유지 관리 (백업, 업그레이드, 정책)입니다.
날카로운 모서리 (아무도 이에 대해 이야기하고 싶어하지 않음)
- DVC 병합 충돌은 마법이 아닙니다: CSV 행을 병합하는 것이 아닙니다. 어떤 blob이 이기는지 조정하고 있습니다. 세분화된 병합의 경우 실제 데이터 처리가 여전히 필요합니다.
- lakeFS 병합 의미 체계는 SQL이 아닙니다: S3 경로를 분기하고 병합할 수 있지만 의미 체계 테이블 변경 (파티션 재구성, upsert)을 조정하는 것은 lakeFS가 아닌 사용자의 작업입니다. 데이터베이스가 아닌 파일 시스템으로 생각하십시오.
- 액세스 제어가 다릅니다: DVC는 Git의 소셜 모델 (PR, 검토)을 상속합니다. lakeFS는 IAM 및 정책 훅과 통합됩니다. 조직이 이미 데이터에 대한 IAM을 중앙 집중화한 경우 lakeFS가 자연스럽게 느껴집니다. GitHub에 있는 경우 DVC가 올바르게 느껴집니다.
통합: 엔진, 오케스트레이터 및 실제 세계
- DVC: GitHub/GitLab CI, Makefiles, Airflow 및 로컬 개발과 잘 작동합니다. ML 실험의 경우 DVC의 실험 추적 및 아티팩트 관리가 핵심입니다.
- lakeFS: Spark, Hive, Trino, Presto, dbt (외부 테이블을 통해), Airflow 및
s3a://repo/branch/path를 읽는 모든 엔진과 잘 작동합니다. 트릭은 컴퓨팅이 동일한 스토리지 언어를 사용한다는 것입니다.
버즈워드 없는 보안 및 규정 준수
- DVC: 보안은 클라우드 스토리지 및 Git 권한에 달려 있습니다. 감사 가능성은 파이프라인 수준 (무엇이 무엇을 언제 생성했는지)에 있습니다.
- lakeFS: 모든 커밋은 감사 검사점입니다. 훅은 병합 전에 데이터를 스캔할 수 있습니다. GDPR 스타일의 “무엇이 언제 변경되었는지”에 관심이 있다면 lakeFS가 더 적합합니다.
쉬운 영어로 된 정면 대결
- 기본 키워드—“lakeFS vs DVC”는 단순한 비교가 아니라 철학의 분기점입니다. DVC는 대용량 파일 및 실험을 위한 Git의 장점입니다. lakeFS는 데이터가 실제로 있는 곳에 Git과 유사한 의미 체계를 제공합니다.
- 주로 데이터를 다루는 코드를 사용하는 경우 DVC가 더 만족스러울 것입니다.
- 때때로 코드를 만나는 데이터를 주로 사용하는 경우 lakeFS를 선택할 가능성이 높습니다.
- 두 가지 모두 사용하는 경우 축하드립니다. 정상입니다. 코드 중심 루프에는 DVC를 사용하고 레이크 중심 루프에는 lakeFS를 사용합니다. “둘 다”는 우유부단한 것이 아니라 정확합니다.
툴링 과대 광고에 대한 참고 사항 (그리고 Sider.AI가 적합한 위치)
도구는 시간을 절약하거나 엉망진창을 방지할 때만 흥미롭습니다. 다른 모든 것은 데모입니다. Sider.AI는 실제로 여기서 도움이 됩니다. 레이크인 척하는 것이 아니라, 파이프라인에 대해 추론하고, 보호 장치 검사를 생성하고, 문서와 차이점을 정직하게 유지하는 숭고하지 않은 작업을 수행합니다. DVC와 lakeFS를 함께 연결하려면 Sider.AI는 “차단기에 레이블을 지정하십시오.”라고 말하고 레이블을 인쇄하는 현명한 친구입니다.
실습 시나리오: 실제 lakeFS vs DVC
시나리오 1: ETL을 위한 기능 격리
- Bronze/Silver/Gold 레이크를 유지 관리합니다. 다운스트림 대시보드를 손상시키지 않고 클릭스트림 수집을 위한 새 스키마를 테스트하고 싶습니다. lakeFS를 사용하면
silver에서etl/schema-v2를 분기하고, 작업을 실행하고, 격리 상태에서 유효성을 검사하고, 검사가 통과되면 병합합니다. 섀도우 버킷이 없고 야간 복사가 없습니다.
시나리오 2: 재현 가능한 훈련 실행
- 매주 모델을 훈련합니다. DVC는 정확한 데이터 세트 스냅샷 (
data.dvc가 lakeFS 커밋 또는 S3 버전을 가리킴), 매개 변수 및 코드를 고정합니다.dvc repro가 실행을 회전시킵니다. 모델, 메트릭 및 플롯은 푸시하고 공유할 수 있는 아티팩트입니다. 감사관은 이것을 좋아합니다. 미래의 당신도 마찬가지입니다.
시나리오 3: 잘못된 게시 수정
- 누군가가 잘못된 Parquet 세트를
main에 게시합니다. lakeFS를 사용하면 마지막으로 올바른 커밋 또는 브랜치로 롤백하고 패치한 다음 병합합니다. DVC를 사용하면 파이프라인에서 수정하고 아티팩트를 다시 푸시합니다. 둘 다 작동합니다. “게시”가 “모두가 읽는 레이크”를 의미하는 경우 lakeFS가 더 좋습니다.
눈물 없는 마이그레이션 및 공존
- 진실을 명명하는 것부터 시작하십시오. 어떤 데이터 세트가 시스템 기록입니까? 어떤 데이터 세트가 임시입니까? 시스템 기록을 lakeFS에 넣습니다. 실험 아티팩트를 DVC에 넣습니다.
- 얇은 통합: DVC 매개 변수 또는 메타데이터에 lakeFS 커밋 ID를 저장합니다. 불변 데이터 세트 버전처럼 취급합니다.
- 레이크를 끓이지 마십시오: 격리로 실제 돈이나 주말을 절약할 수 있는 곳에서 lakeFS를 채택하십시오. 재현성으로 재실행을 절약할 수 있는 곳에서 DVC를 채택하십시오.
변증법: 어느 쪽이든, 어디에 진실이 있는가
소프트웨어 팀은 모든 것을 지배하는 하나의 도구를 원합니다. 그것은 잘못된 질문입니다. 올바른 질문: 진실은 어디에 있습니까?
- 진실이 저장소 (코드, 구성 및 훈련한 특정 파일)에 있는 경우 DVC는 Git의 자연스러운 확장입니다.
- 진실이 레이크 (테이블, 파티션 및 회사를 지원하는 객체 키)에 있는 경우 lakeFS는 커밋 시간 제정신을 제공합니다.
둘 다 버전 제어의 형태입니다. 데이터가 있는 곳에 실제로 있는 것은 하나뿐입니다.
lakeFS vs DVC: 사람들이 실제로 묻는 질문에 대한 빠른 답변
- “DVC가 데이터 레이크를 대체할 수 있습니까?” 아니요. 아티팩트를 구성하고 실험을 제정신으로 만들 수 있습니다. S3가 트랜잭션 저장소처럼 작동하게 만들지 않습니다.
- “lakeFS가 ML 실험 추적기를 대체할 수 있습니까?” 또한 아니요. 실험의 입력/출력을 버전 관리할 수 있지만 ROC 곡선에는 관심이 없습니다.
- “이것은 Git LFS일 뿐입니까?” 자전거는 금속이 적은 자동차와 같다고 말하는 것과 같습니다. DVC는 Git 인접하지만 데이터 파이프라인을 이해합니다. lakeFS는 페타바이트에 Git을 끌어들이지 않고 Git과 유사한 의미 체계를 제공합니다.
복잡성에 대한 간단한 단어 (어딘가에 지불)
모든 추상화는 나중에 청구될 청구서입니다. DVC의 청구서는 개발자 의례 및 가끔 아티팩트 래글링입니다. lakeFS의 청구서는 서비스를 실행하고 객체 저장소에 대한 새로운 병합 의미 체계를 배우는 것입니다. 도구가 무료로 보이면 주의력을 충전하고 있는 것입니다.
분리 샷
“lakeFS vs DVC”는 대결처럼 읽힙니다. 같은 악기를 연주하지 않는 두 명의 음악가와 같습니다. 드러머에게 멜로디를 전달하도록 요청하지 않고, 바이올린에게 행진 밴드를 위해 시간을 지키도록 요청하지 않습니다. 코드가 루프를 소유하는 곳에서 DVC를 사용하십시오. 데이터가 방을 소유하는 곳에서 lakeFS를 사용하십시오. 그리고 두 세계에 모두 살고 있다면 좋습니다. 즉, 주의를 기울이고 있다는 의미입니다.
Git을 래핑하든 S3를 래핑하든 버전 제어의 진짜 요점은 커밋 해시가 아닙니다. 세상을 깨뜨리지 않고 변경할 수 있는 권한입니다. 다른 모든 것은 탭 바일 뿐입니다.
키워드 친화적인 일반 연설 제목 (요청했기 때문에)
ML 파이프라인을 위한 lakeFS vs DVC
ML 파이프라인이 개별 데이터 세트 및 모델 아티팩트가 있는 코드 중심인 경우 DVC가 더 잘 통합됩니다. Git의 포인터 파일, 해시, 추적된 실험. 여러 팀에 공급하는 데이터 중심 파이프라인의 경우 lakeFS는 전체 레이크에서 브랜치 기반 격리로 승리합니다.
데이터 거버넌스를 위한 lakeFS vs DVC
lakeFS는 스토리지 경계에서 감사 가능한 커밋 및 병합 훅을 제공합니다. DVC는 파이프라인 경계에서 출처를 제공합니다. 법률적으로 불변 검사점을 원하는 경우 lakeFS입니다. 엔지니어링에서 재현 가능한 실행을 원하는 경우 DVC입니다.
객체 스토리지를 위한 DVC 및 lakeFS 중에서 선택
객체 스토리지는 트랜잭션을 수행하지 않습니다. DVC는 객체 수준 해시 및 푸시/풀로 이를 해결합니다. lakeFS는 copy-on-write 메타데이터 및 브랜치 의미 체계로 이를 지원합니다. 고통이 저장소 또는 버킷에 있는지에 따라 선택하십시오.
두통 없이 lakeFS와 DVC를 결합
lakeFS를 사용하여 레이크를 버전 관리합니다. 실험이 정확한 입력에 고정되도록 DVC에 커밋 ID를 표시합니다. 모델 아티팩트를 DVC 원격에 보관합니다. 원시 및 큐레이션된 데이터 세트를 lakeFS 브랜치에 보관합니다. 승인되지 않은 해킹이 필요하지 않습니다.
FAQ
Q1: ML 실험에 더 나은 것은 lakeFS 또는 DVC입니까?
ML 실험의 경우 DVC가 일반적으로 승리합니다. 코드, 매개 변수, 데이터 세트 및 모델을 함께 묶고 lakeFS는 레이크 수준에서 데이터 세트 격리 및 시간 여행을 처리합니다.
Q2: lakeFS와 DVC를 함께 사용하여 엉망진창이 되지 않도록 할 수 있습니까?
예. lakeFS 커밋을 사용하여 레이크 데이터 세트를 버전 관리하고 DVC에서 해당 커밋 ID를 참조하십시오. DVC가 아티팩트 및 파이프라인을 처리하도록 합니다. lakeFS가 객체 스토리지에서 브랜치 및 병합을 처리하도록 합니다.
Q3: DVC가 데이터 레이크 또는 lakeFS를 대체합니까?
아니요. DVC는 Git 주변의 대용량 파일 및 실험을 구성합니다. S3를 트랜잭션 저장소로 바꾸지 않습니다. lakeFS는 레이크 앞에 앉아 브랜칭, 커밋 및 격리를 추가합니다.
Q4: lakeFS는 소규모 팀에게는 과잉입니까?
종종 그렇습니다. 다중 팀 격리 또는 거버넌스를 저글링하지 않는 경우 DVC의 단순성이 매력적입니다. lakeFS는 브랜치 기반 격리 및 감사 추적이 실제 돈이나 중단을 절약할 때 의미가 있습니다.
Q5: lakeFS와 DVC의 비용을 비교하면 어떻습니까?
DVC의 비용은 개발자 시간과 push/pull 과정에서 발생하는 스토리지 변동에 따라 달라집니다. lakeFS의 비용은 서비스 실행 및 정책 관리에 따라 달라지지만, 브랜치 생성이 저렴하고 이그레스에 유리합니다.
