Which is better for ML experiments: lakeFS or DVC?

For ML experiments, DVC usually wins. It ties code, parameters, datasets, and models together, while lakeFS handles dataset isolation and time travel at the lake level.

Can I use lakeFS and DVC together without a mess?

Yes. Use lakeFS commits to version your lake datasets and reference those commit IDs in DVC. Let DVC handle artifacts and pipelines; let lakeFS handle branches and merges on object storage.

Does DVC replace a data lake or lakeFS?

No. DVC organizes large files and experiments around Git; it doesn’t turn S3 into a transactional store. lakeFS sits in front of your lake and adds branching, commits, and isolation.

Is lakeFS overkill for small teams?

Often, yes. If you’re not juggling multi-team isolation or governance, DVC’s simplicity is appealing. lakeFS makes sense when branch-based isolation and audit trails save real money or outages.

How do costs compare for lakeFS vs DVC?

DVC’s costs skew toward developer time and storage churn during push/pull. lakeFS’s costs skew toward running the service and managing policies, but branching is cheap and egress-friendly.

lakeFS เทียบกับ DVC: ระบบควบคุมเวอร์ชันที่อยากเป็นระบบไฟล์

สิ่งหนึ่งเกี่ยวกับการควบคุมเวอร์ชันข้อมูลคือ ทุกคนพยักหน้าเห็นด้วยราวกับว่ามันคือ Git สำหรับทุกสิ่ง -- จนกระทั่งคุณพยายามใช้มันจริง ๆ กับข้อมูลขนาดเพตะไบต์ในทีม แล้วตระหนักว่าจริง ๆ แล้ว Git คือ Git สำหรับโค้ดเท่านั้น พวกเขาพูดว่า “แค่จัดการกับ S3 bucket ของคุณเหมือนเป็น repo” ซึ่งก็เหมือนกับการบอกวงซิมโฟนีให้ใช้คาซู เพราะในทางเทคนิคแล้วมันก็เป็นเครื่องดนตรีประเภทเครื่องเป่า

นี่คือเรื่องราวเกี่ยวกับมุมมองสองแบบที่ใช้สโลแกนเดียวกัน: lakeFS เทียบกับ DVC ทั้งสองสัญญาว่าจะนำความปกติสุขมาสู่ที่ซึ่งข้อมูล โมเดล และการทดลองมักจะหายไป แต่พวกเขาโจมตีปัญหาจากคนละทิศทาง DVC เป็นชุดเครื่องมือที่เน้นนักพัฒนาเป็นอันดับแรก อยู่ติดกับ Git และไปด้วยกันกับ repo ของคุณ lakeFS เป็นเลเยอร์ที่เน้นการจัดเก็บข้อมูลเป็นหลัก ซึ่งเปลี่ยน object store ของคุณให้เป็นระบบไฟล์ที่มีการควบคุมเวอร์ชันด้วย branches, commits และ merges ทำนองเดียวกัน แต่ลายเซ็นคีย์ต่างกัน

ถ้าคุณมาที่นี่เพื่อหาคำตัดสิน: คุณอาจรู้อยู่แล้วว่าคุณอยู่ค่ายไหน ถ้าความเจ็บปวดในแต่ละวันของคุณคือการย้ายไฟล์ขนาดใหญ่และ model checkpoints ไปมาพร้อมความสามารถในการทำซ้ำ DVC จะให้ความรู้สึกเหมือนเป็นสายต่อพ่วงที่ฉลาดมาก ถ้าความเจ็บปวดของคุณคือการกำกับดูแลข้อมูลแบบหลายทีม การแยกส่วน และการอ่านซ้ำได้บน data lake lakeFS จะให้ความรู้สึกเหมือนการติดตั้ง circuit breakers ในบ้านจริง ๆ

และใช่ คุณสามารถใช้ทั้งสองอย่างได้ นั่นไม่ใช่การหลีกเลี่ยง มันคือการยอมรับว่างานด้านข้อมูลคืองานหลายอย่างที่สวมเสื้อยืดตัวเดียวกัน

ภาพรวม: DVC และ lakeFS ทำอะไรได้บ้าง

DVC (Data Version Control): อยู่ข้าง Git ไม่ได้อยู่ข้างใน Git คุณควบคุมเวอร์ชัน ตัวชี้ (ไฟล์ meta ขนาดเล็ก) ใน Git และจัดเก็บ artifacts ขนาดใหญ่จริง ๆ -- datasets, models, images -- ใน remote เช่น S3, GCS, Azure, SSH หรือ local cache คุณจะได้รับ pipelines ที่ขับเคลื่อนด้วย CLI, dvc.lock เพื่อความสามารถในการทำซ้ำ, การติดตามการทดลอง และ dvc push/pull เพื่อซิงค์

lakeFS: อยู่หน้า object store ของคุณ (S3, GCS, Azure Blob) และทำให้ branches และ commits เป็นคุณสมบัติระดับเฟิร์สคลาสของ namespace ในการจัดเก็บข้อมูล การอ่านและการเขียนจะเห็น branches ที่แยกจากกัน คุณสามารถสร้าง branch จาก “production” รัน transformations และ merge กลับ -- โดยไม่ต้องคัดลอกเทระไบต์ มันเป็นความหมายเชิง Git สำหรับ data lake ของคุณ

กล่าวอีกนัยหนึ่งคือ DVC เพิ่มการจัดการข้อมูลลงใน workflow ของนักพัฒนา lakeFS สลักความหมายเชิง workflow ลงใน data layer

ความแตกต่างหลัก (และเหตุผลที่มันสำคัญ)

DVC ปฏิบัติต่อข้อมูลขนาดใหญ่เหมือนเป็นส่วนขยายของ codebase ของคุณ ทุกอย่างเริ่มต้นด้วย Git repo: คุณ commit ไฟล์ *.dvc, lock dependencies และ orchestrate pipelines เหมาะอย่างยิ่งสำหรับการทดลอง ML ที่ provenance อยู่ข้างโค้ดที่สร้างมันขึ้นมา

lakeFS พลิกมัน: data lake คือแหล่งที่มาของความจริง Branches ไม่ใช่ metaphors -- แต่เป็น namespaces ที่ครอบคลุม objects พื้นฐานเดียวกัน นั่นหมายความว่าคุณสามารถ:

Spin up branch feature/try-new-schema ของ dataset ขนาด 200 TB ได้ในไม่กี่วินาที

รัน Spark/Presto/Trino บน branch นั้นเหมือนกับว่ามันเป็นของจริง เพราะมันเป็นของจริง

Merge (หรือ abort) โดยไม่ต้องสับเปลี่ยนทั้ง lake

คุณไม่สามารถหลอกสิ่งนั้นด้วย Git hooks ที่ฉลาด

lakeFS เทียบกับ DVC: Use Cases ที่ไม่มีการโฆษณาเกินจริง

เมื่อ DVC ชนะ

ทีมที่เน้นโมเดลเป็นศูนย์กลาง: คุณมีโค้ด, data snapshots และ experiments ที่ต้องทำซ้ำได้และแชร์ได้ การติดตาม experiment ของ DVC และ pipelines dvc repro โดดเด่น

วินัย single-repo: องค์กรของคุณอยู่ใน Git คุณต้องการ “data as code” โดยไม่ต้องประดิษฐ์ storage abstraction DVC เป็นที่คุ้นเคย, git add data.dvc, เสร็จสิ้น

งบประมาณและความเรียบง่าย: ไม่มี infra layer ให้รัน DVC สามารถทำงานร่วมกับ S3 bucket ธรรมดาและนโยบาย permissions ได้ CLI ตรงไปตรงมา Local-first เป็นคุณสมบัติ

เมื่อ lakeFS ชนะ

การแยกทีมในระดับ scale: คุณต้องการให้หลายทีมรัน writes/reads บน lake เดียวกันได้อย่างปลอดภัยโดยไม่รบกวนซึ่งกันและกัน การแยกส่วนตาม branch คือประเด็นสำคัญ

การกำกับดูแลและการตรวจสอบ: Commit history, reproducible snapshots และ policy hooks ที่ storage boundary คุณสามารถบังคับใช้กฎที่สำคัญ

Big engines, big tables: Spark, Hive, Presto, Trino, Snowflake external tables -- เครื่องมือที่สื่อสารกับ object stores lakeFS ผสานรวมในระดับ URL compute stack ของคุณไม่จำเป็นต้องเรียนรู้เทคนิคใหม่ ๆ

เมื่อคุณใช้ทั้งสองอย่าง (และรู้สึกฉลาด)

DVC สำหรับ model artifacts และ pipelines ที่เชื่อมโยงกับ repo lakeFS สำหรับ raw และ curated datasets ใน lake ติดตามและ pin dataset versions ใน DVC ที่อ้างอิง lakeFS commit hash โค้ดอยู่ใน Git ความหมายเชิงข้อมูลอยู่ใน lake ไม่มีใครต้องแสร้งทำเป็นว่าอีก layer หนึ่งสามารถทำงานทั้งสองอย่างได้ดี

lakeFS เทียบกับ DVC: Trade-offs เชิงปฏิบัติ

Setup และ Operations

DVC: ติดตั้ง CLI, กำหนดค่า remotes คุณจะต้องจัดการกับ cache size, storage costs และ access Git ยังคงเป็น home base ของคุณ แรงเสียดทานน้อยที่สุด

lakeFS: คุณกำลังรัน service มี server, metadata, GC, branching policies, credentials ไม่ยาก แต่เป็น infrastructure การตอบแทนคือการแยกส่วนจริงและการ commits แบบ atomic บน data lake

Performance และ Scale

DVC: การ push/pull artifacts ขนาดใหญ่อาจเร็วด้วย local cache และ hardlinks แต model นั้นขับเคลื่อนโดย client เป็นหลัก คุณจะไม่ branch petabyte ใน milliseconds คุณจะอ้างอิงมันและย้ายชิ้นส่วนตามความจำเป็น

lakeFS: branching นั้น metadata-cheap (copy-on-write) การอ่านเป็น “native speed” เพราะเป็นการอ่าน object store เท่านั้น การเขียนทำให้เกิด indirection แต่ไม่ใช่ค่าปรับ “copy the world” Merge conflicts มีอยู่ แต่เป็นที่ระดับ object/key ไม่ใช่บรรทัดของโค้ด

Reproducibility

DVC: dvc.lock ของคุณเชื่อมโยงโค้ด, params และ data artifact hashes เข้าด้วยกัน การ re-running experiment จากเดือนที่แล้วควรสร้าง bits เดียวกัน นั่นคือ reproducibility ที่ code boundary

lakeFS: reproducibility ที่ data boundary: “อ่านตาราง X ณ commit Y” คุณสามารถ time-travel input surface ทั้งหมดของคุณสำหรับการวิเคราะห์หรือ backfills

Collaboration Model

DVC: developer-centric collaboration -- PRs, reviews และ experiments เหมาะอย่างยิ่งสำหรับ ML loop: data → train → evaluate → ship

lakeFS: data-team-centric collaboration -- branches สำหรับ ingestion, transformation และ validation เหมาะอย่างยิ่งสำหรับ analytics loop: ingest → model (เช่น dbt/ETL) → publish → serve

Data Contracts ในภาษาที่เข้าใจง่าย

ผู้คนพูดว่า “data contracts” และเริ่มโบก screenshots ของ schema registry นี่คือเวอร์ชันที่เข้าใจง่าย:

ด้วย DVC contract เป็น implicit ใน pipeline ของคุณ: ไฟล์ที่คุณประกาศว่าเป็น dependencies เป็น contract เปลี่ยนแปลงมัน แล้ว pipeline ของคุณจะรู้

ด้วย lakeFS contract สามารถบังคับใช้ได้ที่ merge: pre-merge hooks สามารถรัน validations (schema checks, row counts, null thresholds) และ block data ที่ไม่ดีจากการเข้าถึง main branch มันคือผู้ใหญ่ในห้อง

Developer Experience (DX): ที่ซึ่ง Rubber Meets the Road

CLI ergonomics: CLI ของ DVC มีความเห็น แต่คาดเดาได้: dvc add, dvc push, dvc exp run CLI (และ UI) ของ lakeFS คิดใน branches/commits ที่ระดับ dataset: lakefs branch create, commit, merge

Mental model: DVC ขอให้นักพัฒนาปฏิบัติต่อข้อมูลเหมือน binaries ของ third-party ที่มี hashes lakeFS ขอให้ data engineers ปฏิบัติต่อ lake เหมือน repo ที่มี isolation layers

Cognitive load: DVC เพิ่ม per-repo rituals lakeFS เพิ่ม infra และ policies เลือกยาพิษของคุณตามที่ทีมของคุณอาศัยอยู่แล้ว -- IDEs หรือ data platforms

Cost: Time, Money และ Cloud-Egress Headaches

Storage: ทั้งสองใช้ออบเจ็กต์สโตร์อย่างมีประสิทธิภาพ DVC สามารถทำซ้ำ artifacts ได้หากคุณประมาทกับ cache lakeFS อาศัย metadata แบบ copy-on-write ซึ่งราคาถูกจนกว่าคุณจะ churn

Egress และ movement: การ push/pull ของ DVC สามารถสร้างออบเจ็กต์ churn ได้มากขึ้น การอ่าน lakeFS ส่วนใหญ่เป็นการ pass-through หาก egress costs ทำให้คุณนอนไม่หลับ model “branch without copy” ของ lakeFS เป็นมิตร

Ops overhead: ค่าใช้จ่ายของ DVC ส่วนใหญ่เป็นเวลาของนักพัฒนา ค่าใช้จ่ายของ lakeFS คือ service maintenance -- backups, upgrades, policies

The Sharp Edges (ไม่มีใครชอบพูดถึงสิ่งเหล่านี้)

DVC merge conflicts ไม่ใช่ magic: คุณไม่ได้ merging CSV rows คุณกำลัง reconciling ว่า blobs ไหนชนะ สำหรับ fine-grained merges คุณยังคงต้องมีการประมวลผลข้อมูลจริง

lakeFS merge semantics ไม่ใช่ SQL: คุณสามารถ branch และ merge S3 paths ได้ แต่การ reconciling semantic table changes (partition reshuffles, upserts) เป็นงานของคุณ ไม่ใช่งานของ lakeFS คิดว่าเป็นระบบไฟล์ ไม่ใช่ฐานข้อมูล

Access control แตกต่างกัน: DVC สืบทอด Git’s social model (PRs, reviews) lakeFS ผสานรวมกับ IAM และ policy hooks หากองค์กรของคุณรวมศูนย์ IAM สำหรับข้อมูลแล้ว lakeFS จะรู้สึกเป็นธรรมชาติ หากคุณอยู่ใน GitHub DVC จะรู้สึกถูกต้อง

Integrations: Engines, Orchestrators และ Real World

DVC: เล่นได้ดีกับ GitHub/GitLab CI, Makefiles, Airflow และ local dev สำหรับ ML experiments การติดตาม experiment และการจัดการ artifacts ของ DVC เป็นจุดดึงดูด

lakeFS: เล่นได้ดีกับ Spark, Hive, Trino, Presto, dbt (ผ่าน external tables), Airflow และ engine ใด ๆ ที่อ่าน s3a://repo/branch/path เคล็ดลับคือ compute ของคุณพูดภาษา storage เดียวกัน

Security และ Compliance ที่ไม่มี Buzzwords

DVC: security ขึ้นอยู่กับการจัดเก็บข้อมูลบนคลาวด์และสิทธิ์ Git ของคุณ Auditability อยู่ที่ระดับ pipeline -- อะไรสร้างอะไร และเมื่อใด

lakeFS: ทุก commit เป็น audit checkpoint Hooks สามารถสแกนข้อมูลก่อน merge หากคุณสนใจเกี่ยวกับ GDPR-style “อะไรเปลี่ยนแปลงเมื่อใด” lakeFS จะเหมาะสมกว่า

A Plain-English Head-to-Head

Primary keyword—“lakeFS vs DVC” ไม่ใช่แค่การเปรียบเทียบ แต่เป็นทางแยกในปรัชญา DVC คือ Git-with-benefits สำหรับไฟล์ขนาดใหญ่และ experiments lakeFS คือ Gitlike semantics ที่ข้อมูลของคุณอยู่จริง

หากวันของคุณส่วนใหญ่เป็น โค้ด ที่สัมผัส ข้อมูล คุณจะมีความสุขกับ DVC มากกว่า

หากวันของคุณส่วนใหญ่เป็น ข้อมูล ที่บางครั้งพบกับ โค้ด คุณมักจะเลือก lakeFS

หากวันของคุณเป็นทั้งสองอย่าง ยินดีด้วย คุณเป็นเรื่องปกติ ใช้ DVC สำหรับ code-facing loop และ lakeFS สำหรับ lake-facing loop “ทั้งสองอย่าง” ไม่ใช่การไม่เด็ดขาด แต่แม่นยำ

A Note on Tooling Hype (And Where Sider.AI Fits)

เครื่องมือจะน่าสนใจก็ต่อเมื่อช่วยประหยัดเวลาหรือป้องกันความยุ่งเหยิง ทุกสิ่งอื่น ๆ เป็นเพียงการสาธิต Sider.AI ช่วยได้จริง ๆ ที่นี่ -- ไม่ใช่โดยการแสร้งทำเป็น lake ของคุณ แต่โดยการทำงานที่ไม่น่าดึงดูดใจ: ช่วยให้คุณใช้เหตุผลเกี่ยวกับ pipelines ของคุณ สร้าง guardrail checks และทำให้เอกสารและ diffs ของคุณซื่อสัตย์ หากคุณกำลังจะเชื่อม DVC และ lakeFS เข้าด้วยกัน Sider.AI คือเพื่อนที่สมเหตุสมผลที่พูดว่า “ติดฉลาก breakers ของคุณ” แล้วพิมพ์ฉลาก

Hands-On Scenarios: lakeFS vs DVC in the Wild

Scenario 1: Feature Isolation for ETL

คุณดูแลรักษา Bronze/Silver/Gold lake คุณต้องการทดสอบ schema ใหม่สำหรับการ clickstream ingestion โดยไม่ทำลาย downstream dashboards ด้วย lakeFS branch etl/schema-v2 off silver รัน jobs ของคุณ validate ใน isolation และ merge หลังจาก checks ผ่าน ไม่มี shadow buckets ไม่มี overnight copies

Scenario 2: Reproducible Training Runs

คุณ train models ทุกสัปดาห์ DVC pins dataset snapshot ที่แน่นอน (data.dvc ชี้ไปที่ lakeFS commit หรือ S3 version), params และโค้ด dvc repro spins the run model, metrics และ plots เป็น artifacts ที่คุณสามารถ push และ share Auditors ชอบสิ่งนี้ อนาคตคุณก็ชอบเช่นกัน

Scenario 3: Fixing a Bad Publish

มีคน publish Parquet set ที่ผิดรูปแบบไปยัง main ด้วย lakeFS คุณ roll back ไปยัง last good commit หรือ branch patch และ merge ด้วย DVC คุณกำลังแก้ไขใน pipeline และ re-pushing artifacts ทั้งสองอย่างได้ผล lakeFS จะดีกว่าเมื่อ “publish” หมายถึง “lake ที่ทุกคนอ่าน”

Migration and Coexistence Without Tears

เริ่มต้นด้วยการ ตั้งชื่อความจริงของคุณ: Datasets ใดเป็น system-of-record Datasets ใดเป็น ephemeral ใส่ system-of-record ใน lakeFS ใส่ experiment artifacts ใน DVC

Thin integration: จัดเก็บ lakeFS commit IDs ใน DVC params หรือ metadata ปฏิบัติต่อพวกเขาเหมือน dataset versions ที่ immutable

อย่าต้มทั้ง lake: นำ lakeFS มาใช้ในที่ที่ isolation ช่วยประหยัดเงินหรือ weekends ให้คุณได้จริง ๆ นำ DVC มาใช้ในที่ที่ reproducibility ช่วยประหยัดการ re-runs ให้คุณได้

The Dialectic: It’s Not Either/Or, It’s Where the Truth Lives

Software teams ต้องการเครื่องมือเดียวที่จะครองพวกเขาทั้งหมด นั่นเป็นคำถามที่ผิด คำถามที่ถูกต้อง: ความจริงอยู่ที่ไหน

หากความจริงอยู่ใน repo -- โค้ด, configs และไฟล์เฉพาะที่คุณ train on -- DVC เป็นส่วนขยายตามธรรมชาติของ Git

หากความจริงอยู่ใน lake -- ตาราง partitions และ object keys ที่ขับเคลื่อนบริษัทของคุณ -- lakeFS ให้ commit-time sanity แก่คุณ

ทั้งสองเป็นรูปแบบของการควบคุมเวอร์ชัน มีเพียงหนึ่งเดียวที่อาศัยอยู่ที่ซึ่งข้อมูลอยู่

lakeFS เทียบกับ DVC: คำตอบด่วนสำหรับคำถามที่ผู้คนถามจริง ๆ

“DVC สามารถแทนที่ data lake ของฉันได้หรือไม่” ไม่ได้ มันสามารถจัดระเบียบ artifacts ของคุณและทำให้ experiments เป็นปกติได้ มันจะไม่ทำให้ S3 ทำงานเหมือน transactional store

“lakeFS สามารถแทนที่ ML experiment tracker ของฉันได้หรือไม่” ไม่ได้เช่นกัน มันสามารถควบคุมเวอร์ชัน input/output ของ experiments ได้ แต่ไม่ได้สนใจเกี่ยวกับ ROC curves ของคุณ

“นี่ไม่ใช่แค่ Git LFS ใช่ไหม” นั่นเหมือนกับการบอกว่าจักรยานเป็นแค่รถยนต์ที่มีโลหะน้อยกว่า DVC อยู่ติดกับ Git แต่เข้าใจ data pipelines lakeFS ให้ Git-ish semantics แก่คุณโดยไม่ต้องลาก Git เข้าไปใน petabytes

A Brief Word on Complexity (คุณจ่ายที่ไหนสักแห่ง)

ทุก abstraction เป็นบิลที่ครบกำหนดในภายหลัง บิลของ DVC คือ developer ritual และ occasional artifact wrangling บิลของ lakeFS คือการรัน service และเรียนรู้ merge semantics ใหม่สำหรับ object stores หากเครื่องมือดูเหมือนฟรี แสดงว่ามันกำลังเรียกเก็บความสนใจของคุณ

The Parting Shot

“lakeFS vs DVC” อ่านเหมือนการเผชิญหน้า มันเหมือนนักดนตรีสองคนที่ไม่ได้เล่นเครื่องดนตรีเดียวกันมากกว่า คุณไม่ได้ขอให้มือกลองแบกทำนอง และคุณไม่ได้ขอให้ไวโอลินรักษาระดับเวลาสำหรับวง marching band ใช้ DVC ในที่ที่โค้ดเป็นเจ้าของ loop ใช้ lakeFS ในที่ที่ข้อมูลเป็นเจ้าของห้อง และถ้าคุณอยู่ในทั้งสองโลก ดี: นั่นหมายความว่าคุณกำลังให้ความสนใจ

เพราะจุดประสงค์ที่แท้จริงของการควบคุมเวอร์ชัน -- ไม่ว่าจะ wrap Git หรือ wrap S3 -- ไม่ใช่ commit hash แต่เป็นการอนุญาตให้เปลี่ยนแปลงสิ่งต่าง ๆ โดยไม่ทำลายโลก ทุกสิ่งอื่น ๆ เป็นเพียง tab bar

Keyword-Friendly, Plain-Speech Headings (เพราะคุณถาม)

lakeFS เทียบกับ DVC สำหรับ ML pipelines

หาก ML pipelines ของคุณมีโค้ดจำนวนมากที่มี datasets ที่ไม่ต่อเนื่องและ model artifacts DVC จะผสานรวมได้ดีกว่า: pointer files ใน Git hashes tracked experiments สำหรับ data-heavy pipelines ที่ป้อนให้กับหลายทีม lakeFS ชนะด้วย branch-based isolation ทั่วทั้ง lake

lakeFS เทียบกับ DVC สำหรับ data governance

lakeFS ให้ auditable commits และ merge hooks แก่คุณที่ storage boundary DVC ให้ provenance แก่คุณที่ pipeline boundary หากกฎหมายต้องการ immutable checkpoints นั่นคือ lakeFS หากวิศวกรรมต้องการ reproducible runs นั่นคือ DVC

Choosing between DVC and lakeFS for object storage

Object storage ไม่ได้ทำ transactions DVC ทำงานรอบ ๆ สิ่งนั้นด้วย object-level hashes และ push/pull lakeFS พิงไปที่สิ่งนั้นด้วย copy-on-write metadata และ branch semantics เลือกตามว่าความเจ็บปวดของคุณอยู่ใน repo หรือ bucket

Combine lakeFS and DVC without headaches

ใช้ lakeFS เพื่อควบคุมเวอร์ชัน lake พื้นผิว commit IDs ไปยัง DVC เพื่อให้ experiments pin ไปยัง inputs ที่แน่นอน เก็บ model artifacts ใน DVC remotes เก็บ raw และ curated datasets ใน lakeFS branches ไม่จำเป็นต้องมี unsanctioned hacks

FAQ

Q1:อะไรดีกว่าสำหรับการทดลอง ML: lakeFS หรือ DVC? สำหรับการทดลอง ML โดยปกติแล้ว DVC จะชนะ มันเชื่อมโยงโค้ด พารามิเตอร์ ชุดข้อมูล และโมเดลเข้าด้วยกัน ในขณะที่ lakeFS จัดการการแยกชุดข้อมูลและการเดินทางข้ามเวลาในระดับ lake

Q2:ฉันสามารถใช้ lakeFS และ DVC ร่วมกันได้หรือไม่โดยไม่ยุ่งเหยิง ได้ ใช้ lakeFS commits เพื่อควบคุมเวอร์ชันชุดข้อมูล lake ของคุณ และอ้างอิง commit IDs เหล่านั้นใน DVC ให้ DVC จัดการ artifacts และ pipelines ให้ lakeFS จัดการ branches และ merges บน object storage

Q3:DVC แทนที่ data lake หรือ lakeFS หรือไม่ ไม่ DVC จัดระเบียบไฟล์ขนาดใหญ่และ experiments รอบ Git มันไม่ได้เปลี่ยน S3 ให้เป็น transactional store lakeFS นั่งอยู่หน้า lake ของคุณและเพิ่ม branching commits และ isolation

Q4:lakeFS มากเกินไปสำหรับทีมเล็ก ๆ หรือไม่ บ่อยครั้ง ใช่ หากคุณไม่ได้จัดการกับการแยกหรือการกำกับดูแลแบบหลายทีม ความเรียบง่ายของ DVC เป็นที่น่าดึงดูดใจ lakeFS สมเหตุสมผลเมื่อการแยกตาม branch และ audit trails ช่วยประหยัดเงินหรือ outages ได้จริง ๆ

Q5: ค่าใช้จ่ายของ lakeFS กับ DVC แตกต่างกันอย่างไร ค่าใช้จ่ายของ DVC จะเน้นไปที่เวลาของนักพัฒนาซอฟต์แวร์และการเปลี่ยนแปลงพื้นที่จัดเก็บข้อมูลระหว่างการ push/pull ค่าใช้จ่ายของ lakeFS จะเน้นไปที่การรันบริการและการจัดการนโยบาย แต่การสร้าง branch นั้นมีราคาถูกและเป็นมิตรกับการ egress

lakeFS vs DVC: Version Control Wants to Be a Filesystem