Hệ thống quản lý phiên bản dữ liệu

 (dvc.org)
2 điểm bởi GN⁺ 2024-10-21 | 1 bình luận | Chia sẻ qua WhatsApp
  • Data Version Control là một bộ công cụ theo mô hình tương tự Git để quản lý dữ liệu như quản lý mã nguồn, giúp các nhóm dữ liệu, AI/ML và khoa học dữ liệu áp dụng các thực hành kỹ thuật phần mềm
  • Với hạ tầng AI/ML và dữ liệu quy mô lớn, lakeFS đảm nhiệm nhu cầu này, hướng tới việc xử lý kho đối tượng đa phương thức và data lake ở quy mô petabyte trong môi trường vận hành AI phức tạp và dữ liệu lớn
  • Với các dự án khoa học dữ liệu quy mô nhỏ, phần mở rộng Git của DVC phù hợp hơn, cho phép từng nhà khoa học dữ liệu đưa quản lý phiên bản dữ liệu vào quy trình làm việc với mức overhead thấp
  • DVC được cung cấp miễn phí dưới dạng mã nguồn mở và cũng có tiện ích DVC for VS Code; kho lưu trữ GitHub hiển thị 15.713 sao
  • Khi cộng đồng DVC gia nhập lakeFS family, bạn cũng có thể xem riêng phần phân định vai trò giữa lakeFS và DVC cùng các FAQ liên quan

Vai trò của Data Version Control

  • Data Version Control theo đuổi mục tiêu “quản lý dữ liệu theo cách quản lý mã nguồn”
  • Thông qua mô hình tương tự Git, công cụ này giúp các nhóm dữ liệu, AI/ML và khoa học dữ liệu tận dụng các thực hành tốt nhất của kỹ thuật phần mềm
  • Các trường hợp sử dụng được chia thành hai nhánh lớn
    • Nhóm hạ tầng AI/ML và dữ liệu
    • Quy trình làm việc cục bộ và các dự án khoa học dữ liệu quy mô nhỏ

Đối tượng của từng sản phẩm và cách bắt đầu

  • lakeFS là hạ tầng quản lý phiên bản dữ liệu dành cho các nhóm AI doanh nghiệp và kỹ thuật dữ liệu
    • Nhắm đến môi trường vận hành AI phức tạp và dữ liệu lớn
    • Xử lý kho đối tượng đa phương thức và data lake ở quy mô petabyte
    • Có các liên kết bắt đầu gồm Get started with lakeFS và Book a Demo
  • DVC là phần mở rộng Git dành cho từng nhà khoa học dữ liệu
    • Hướng tới quản lý phiên bản dữ liệu dễ dùng cho các dự án khoa học dữ liệu quy mô nhỏ
    • Có thể áp dụng vào quy trình khoa học dữ liệu với overhead tối thiểu
    • Liên kết bắt đầu là Get started with DVC
  • Có thể dùng trong VS Code thông qua tiện ích DVC for VS Code
  • Cộng đồng DVC đã gia nhập lakeFS family; các tài liệu liên quan gồm lakeFS and DVC và FAQs
  • Kho GitHub của DVC là treeverse/dvc, và trên trang hiển thị 15.713 sao

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-10-21
Ý kiến trên Hacker News

  • Trong 5 năm qua, tôi đã dùng DVC cho hầu hết các dự án; ưu điểm là nó hoạt động giống Git
    Nếu các nhà khoa học hiểu branch, commit và diff thì họ cũng có thể hiểu DVC. Nhược điểm cũng là nó hoạt động giống Git, vì trên thực tế nhiều nhà khoa học thường không hiểu rõ hoặc không dùng branch, commit và diff. Điểm hay nhất là về cơ bản nó buộc bạn phải tuân theo Ten Simple Rules for Reproducible Computational Research. Trong các nhóm tôi từng làm việc, tính tái lập là một thách thức lớn

    • Tôi cũng cảm thấy tương tự, và rào cản học Git khá lớn, ở mức nào đó cũng dễ hiểu
      Các nhà nghiên cứu biết Git là gì và biết nó có giá trị, nhưng họ nghĩ việc học mất quá nhiều thời gian và muốn tiến nhanh. Vì những nhà nghiên cứu như vậy, tôi bắt đầu tạo một công cụ tên là Calkit(https://github.com/calkit/calkit) nhằm đơn giản hóa và tích hợp Git với DVC. Tôi muốn thuyết phục họ rằng làm việc theo cách có thể tái lập về lâu dài sẽ nhanh hơn, và nhờ đó công sức của họ có thể được dùng trực tiếp hơn để thúc đẩy cả lĩnh vực phát triển nhanh hơn

  • Tôi là maintainer kiêm tác giả của DVC, rất vui khi thấy DVC lên trang nhất
    Tôi có thể trả lời các câu hỏi về DVC và dự án chị em DataChain https://github.com/iterative/datachain. DataChain là một công cụ quản lý phiên bản dữ liệu với các giả định hơi khác, có sẵn biến đổi dữ liệu và không cần sao chép tệp

    • Nếu toàn bộ tệp dữ liệu đều là tệp văn bản thì khác biệt giữa DVC và Git thuần là gì?
    • Tôi chủ yếu tư vấn với vai trò kỹ sư dữ liệu và không phải chuyên gia MLOps, nhưng tôi quan tâm đến phần này
      Chúng tôi có 10 năm tệp Parquet từ hơn 300 topic Kafka, và hiện đang migrate sang Apache Iceberg. Chúng tôi dự định chỉ backfill khi cần, và sẽ rất tốt nếu có thể theo dõi quá trình đó bằng Git. Tôi muốn biết công cụ này có phù hợp với mục đích như vậy không. Một khả năng khác là theo dõi thay đổi schema theo cách tốt hơn hiện nay. Tôi đã ở trong lĩnh vực này hơn 20 năm và thấy anything-as-code rất hợp với dữ liệu

  • Rất vui khi thấy DVC được thảo luận ở đây
    Với tư cách là công cụ, nó đã đơn giản hóa rất nhiều việc quản lý phiên bản dữ liệu và mô hình, và là một bước ngoặt lớn với nhiều người trong lĩnh vực MLOps. Đặc biệt, đây là một cách thông minh để liên kết trực tiếp các tệp lớn trong bất kỳ object storage nào với kho Git, mà không cần application server riêng như git-lfs hay viết lại Git. Tại DagsHub https://dagshub.com, chúng tôi đã tích hợp trực tiếp với DVC từ lâu, giúp các nhóm có thể trực quan hóa và gán nhãn dataset, quản lý mô hình, chạy thí nghiệm cộng tác, theo dõi code·dữ liệu·mô hình ở cùng một nơi. Nếu bạn đã dùng hoặc đang cân nhắc DVC, cũng có lựa chọn dùng nó như một thành phần trong toolchain gần với end-to-end hơn

  • Tôi tò mò nó so với Oxen thì thế nào
    https://github.com/Oxen-AI/Oxen

    • Tôi là maintainer của Oxen; lý do ban đầu tạo Oxen là vì DVC khá chậm và có nhiều tính năng không cần thiết
      Bên trong, chúng tôi tối ưu cấu trúc cây Merkle, thuật toán băm, giao thức mạng, v.v. để nó nhanh ngay cả với dataset lớn. https://oxen.ai cũng có một frontend khá ổn để xem và truy vấn dữ liệu
    • Nếu có thể dùng cái này cùng GitHub thì có lẽ tôi sẽ chuyển ngay khỏi DVC
    • Tôi mới nghe về Oxen lần đầu nhưng nó trông là một phương án thay thế rất thú vị, và muốn nghe từ người đã dùng cả hai
      Ấn tượng ban đầu của tôi là DVC được tạo ra để dùng cùng Git, theo kiểu DVC quản lý một thư mục bất kỳ bên trong kho Git, còn Oxen có vẻ giống một giải pháp thay thế kho lưu trữ dữ liệu riêng hơn. Ngoài ra Oxen có nhiều tích hợp với dataframe, dữ liệu dạng bảng, dữ liệu huấn luyện/suy luận AI, dường như bổ sung những phần DVC không có. Ngược lại, DVC tích hợp DAG pipeline engine đầy đủ, import/export và các backend có thể thay thế

  • Tôi chưa hình dung rõ nó tương tác với dữ liệu như thế nào
    Nếu đang lưu Delta table trên ADLS và không thể kéo dữ liệu production về local thì liệu vẫn dùng được không? Nếu chỉ cần xem Delta log để chuyển về phiên bản cũ thì tôi cũng tự hỏi có lý do gì để dùng DVC không

    • Theo cách tôi dùng, DVC gần giống git LFS hỗ trợ nhiều backend, cũng có thể xem như một git-annex đơn giản hơn
      Bên cạnh đó có thêm các tính năng chuyên cho MLOps. Nó tiện khi quản lý phiên bản cho việc huấn luyện mô hình với dữ liệu thay đổi trên S3

  • Chúng tôi cũng đã xem xét DVC, nhưng với một số use case nhất định thì mô hình Git không hữu ích lắm
    Đó là các tệp video khổng lồ gần như không thay đổi, và cần một bản sao dữ liệu ở phía nguồn, thêm một bản sao trên từng hệ thống chạy huấn luyện. Cuối cùng chúng tôi dùng tệp và thư mục trên NAS, và nó hoạt động đủ tốt. Có vẻ có thể dùng cách hybrid: chỉ quản lý metadata của dataset bằng DVC và versioning phần đó. Tuy nhiên chuyện này đã từ vài năm trước, và tôi tò mò hiện nay có thêm giải pháp quản lý phiên bản dữ liệu on-premise nào không. Lần cuối tôi tìm thì hầu hết có vẻ thiên về cloud

  • Tò mò DVC có ưu điểm gì so với Apache Iceberg
    Nếu có ai đã dùng cả hai thì muốn nghe quan điểm

    • Nếu tò mò về điều này thì cũng nên xem Icechunk, vừa được mã nguồn mở trong tuần này
      Nó tương tự Apache Iceberg nhưng là công cụ cho dữ liệu đa chiều như Zarr. https://earthmover.io/blog/icechunk và https://news.ycombinator.com/item?id=41850352
    • Chưa thấy ưu điểm rõ rệt, có cảm giác như đang dùng một công cụ quen thuộc vào chỗ không phù hợp
      Iceberg có thể được thiết kế phù hợp hơn với các mô hình thay đổi chậm hơn so với cách này
    • Đầu óc còn hơi lộn xộn, nhưng thử diễn đạt thì một ví dụ tốt về dữ liệu blob ở đây là một tập các file video 1080p rất dài
      Tóm lại, dữ liệu blob phi cấu trúc thì nên đưa vào DVC, còn dữ liệu có cấu trúc thì đưa vào Iceberg. Điểm DVC tốt hơn Iceberg là không cần phải cố nhét dữ liệu blob vào dạng bảng, và có thể tránh các bước xử lý phiền phức kéo theo quá trình đó. Thực tế cũng không cần chạy bước xử lý để lấy dữ liệu blob ra khỏi file Parquet; chỉ cần dùng lệnh như dvc pull để tải từng file về nguyên trạng. Sau khi sửa file cục bộ, có thể commit bằng khoảng ba lệnh, và cũng không cần pipeline ingest dữ liệu để cố nhét blob vào bảng. Vì hoàn toàn không có schema nên không phải lo về type, chỉ cần đưa vào repository rồi commit. Có thể rollback theo toàn bộ lịch sử commit, chứ không chỉ tới vacuum/checkpoint cuối cùng. Cố nhét dữ liệu blob vào định dạng dữ liệu dạng bảng gần như là công thức gây đau khổ; đưa blob vào một repository kiểu Git nhanh và dễ hơn nhiều. Điều này đặc biệt đúng nếu cần toàn bộ lịch sử phiên bản hoặc các branch cho các kết quả khác nhau; việc áp các bộ lọc ffmpeg khác nhau cho các file video 1080p dài theo từng branch rồi cho mọi người truy cập mọi kết quả và lịch sử sẽ là ác mộng trong Iceberg, nhưng lại dễ trong DVC. Rốt cuộc mọi thứ đều được quản lý phiên bản, nên có cảm giác như tạo ra một data lake không biến thành data swamp

  • Khi dùng với dataset gồm nhiều file jpg thì gặp rất nhiều vấn đề
    Mỗi lần dvc status, tác vụ lập chỉ mục kiểm tra tất cả file mất vài phút, và cache cũng không hoạt động. Tiếc là cuối cùng phải bỏ

    • Đúng vậy, hiệu năng khá tệ và cache có thể gây nhiều rắc rối
      Đặc biệt nếu dùng hệ thống file không hỗ trợ reflink. Với các dataset được shard lớn như WebDataset thì giải pháp khác sẽ tốt hơn, nhất là nếu pipeline machine learning có thể stream trực tiếp từ object storage

  • Cũng từng nghe về lakeFS như một công cụ quản lý phiên bản dữ liệu trên S3 object storage
    Tò mò liệu DVC có thể là đối thủ cạnh tranh trong lĩnh vực này không