Sistem Manajemen Versi Data

 (dvc.org)
2 poin oleh GN⁺ 2024-10-21 | 1 komentar | Bagikan ke WhatsApp
  • Data Version Control adalah rangkaian alat dengan model mirip Git untuk mengelola data seperti kode, yang memungkinkan tim data, AI/ML, dan ilmu data menerapkan praktik rekayasa perangkat lunak
  • Untuk infrastruktur AI/ML dan data skala besar, lakeFS menjadi solusi, dengan fokus pada pengelolaan object storage multimodal dan data lake berskala petabyte dalam operasi AI yang kompleks serta lingkungan big data
  • Untuk proyek ilmu data skala kecil, ekstensi Git DVC lebih sesuai, sehingga ilmuwan data individu dapat memasukkan manajemen versi data ke dalam alur kerja dengan overhead rendah
  • DVC tersedia gratis sebagai open source, juga memiliki ekstensi DVC for VS Code, dan repositori GitHub-nya menampilkan 15.713 bintang
  • Saat komunitas DVC bergabung dengan keluarga lakeFS, pembagian peran antara lakeFS dan DVC serta FAQ terkait dapat dilihat secara terpisah

Peran yang Ditangani oleh Data Version Control

  • Data Version Control mengusung tujuan “mengelola data dengan cara yang sama seperti mengelola kode”
  • Melalui model yang mirip Git, ini membantu tim data, AI/ML, dan ilmu data memanfaatkan praktik terbaik rekayasa perangkat lunak
  • Kasus penggunaannya secara umum terbagi menjadi dua jalur
    • Tim AI/ML dan infrastruktur data
    • Alur kerja lokal dan proyek ilmu data skala kecil

Target Produk dan Jalur Memulai

  • lakeFS adalah infrastruktur manajemen versi data untuk tim enterprise AI dan rekayasa data
    • Ditujukan untuk operasi AI yang kompleks dan lingkungan big data
    • Menangani object storage multimodal dan data lake berskala petabyte
    • Tersedia tautan awal Get started with lakeFS dan Book a Demo
  • DVC adalah ekstensi Git untuk ilmuwan data individu
    • Menargetkan manajemen versi data yang mudah untuk proyek ilmu data skala kecil
    • Dapat diterapkan ke alur kerja ilmu data dengan overhead minimal
    • Tautan awalnya adalah Get started with DVC
  • Melalui ekstensi DVC for VS Code, alat ini juga dapat digunakan di VS Code
  • Komunitas DVC telah bergabung dengan keluarga lakeFS, dan panduan terkait terhubung ke lakeFS and DVC dan FAQs
  • Repositori GitHub DVC adalah treeverse/dvc, dan pada halamannya ditampilkan 15.713 bintang

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-21
Pendapat Hacker News

  • Selama 5 tahun terakhir saya memakai DVC di sebagian besar proyek, dan kelebihannya adalah ia bekerja seperti Git
    Jika para ilmuwan memahami branch, commit, dan diff, mereka juga bisa memahami DVC. Kekurangannya juga bahwa ia bekerja seperti Git, karena dalam praktiknya para ilmuwan sering kali tidak benar-benar memahami atau memakai branch, commit, dan diff. Hal terbaiknya adalah ia pada dasarnya memaksa kita mengikuti Ten Simple Rules for Reproducible Computational Research. Di tim-tim tempat saya bekerja, reproducibility adalah tantangan besar

    • Saya juga merasakan hal serupa, dan resistensi untuk belajar Git cukup besar serta sampai batas tertentu bisa dimengerti
      Para peneliti tahu apa itu Git dan bahwa Git bernilai, tetapi mereka merasa mempelajarinya memakan waktu terlalu lama dan ingin bergerak cepat. Untuk peneliti seperti ini, saya mulai membuat alat bernama Calkit(https://github.com/calkit/calkit) untuk menyederhanakan dan mengintegrasikan Git dan DVC. Saya ingin meyakinkan mereka bahwa bekerja secara reproducible akan lebih cepat dalam jangka panjang, dan pada akhirnya membuat pekerjaan mereka bisa dipakai lebih langsung untuk mempercepat kemajuan seluruh bidang

  • Saya maintainer sekaligus penulis DVC, senang melihat DVC muncul di halaman depan
    Saya bisa menjawab pertanyaan tentang DVC dan proyek saudaranya, DataChain https://github.com/iterative/datachain. DataChain adalah alat versioning data dengan asumsi yang sedikit berbeda, tanpa menyalin file dan dengan transformasi data bawaan

    • Kalau semua file datanya berupa file teks, saya penasaran apa bedanya DVC dan Git murni
    • Saya terutama berkonsultasi sebagai data engineer dan bukan spesialis MLOps, tetapi tertarik pada bagian ini
      Kami punya file Parquet untuk 10 tahun dari lebih dari 300 topic Kafka, dan saat ini sedang bermigrasi ke Apache Iceberg. Kami akan melakukan backfill hanya jika diperlukan, dan akan bagus kalau proses itu bisa dilacak dengan Git. Saya penasaran apakah ini cocok untuk penggunaan seperti itu. Kemungkinan lain adalah melacak perubahan skema dengan cara yang lebih baik daripada sekarang. Saya sudah lebih dari 20 tahun di bidang ini dan melihat anything-as-code cocok dengan data

  • Senang melihat DVC dibahas di sini
    Sebagai alat, DVC banyak menyederhanakan versioning data dan model, dan menjadi titik balik besar bagi banyak orang di ranah MLOps. Khususnya, ini adalah cara cerdas untuk menyimpan file besar di object storage mana pun dengan menghubungkannya langsung ke repositori Git, tanpa application server terpisah seperti git-lfs atau penulisan ulang Git. Di DagsHub https://dagshub.com, kami sudah lama berintegrasi langsung dengan DVC, sehingga tim dapat melakukan visualisasi dan pelabelan dataset, manajemen model, menjalankan eksperimen kolaboratif, serta melacak kode·data·model di satu tempat. Jika Anda sudah memakai atau sedang mempertimbangkan DVC, ada juga opsi untuk memakainya sebagai komponen dalam toolchain yang lebih mendekati end-to-end

  • Penasaran bagaimana perbandingannya dengan Oxen
    https://github.com/Oxen-AI/Oxen

    • Saya maintainer Oxen, dan alasan awal membuat Oxen adalah karena DVC cukup lambat dan punya banyak fitur yang tidak diperlukan
      Secara internal kami mengoptimalkan struktur Merkle tree, algoritma hash, protokol jaringan, dan sebagainya agar cepat bahkan untuk dataset besar. Di https://oxen.ai juga ada frontend yang cukup bagus untuk melihat dan meng-query data
    • Kalau ini bisa dipakai bersama GitHub, rasanya saya akan langsung pindah dari DVC
    • Saya baru pertama kali mendengar Oxen, tetapi tampaknya alternatif yang sangat menarik, dan saya ingin mendengar dari orang yang pernah memakai keduanya
      Kesan pertama saya, DVC dibuat untuk dipakai bersama Git dengan cara DVC mengelola folder arbitrer di dalam repositori Git, sedangkan Oxen lebih tampak seperti alternatif repositori data terpisah. Selain itu, Oxen punya banyak integrasi dengan dataframe, data tabular, serta data pelatihan·inferensi AI, sehingga tampaknya mengisi bagian yang tidak ada di DVC. Sebaliknya, DVC memiliki DAG pipeline engine lengkap, impor·ekspor, dan backend yang bisa diganti-ganti secara terintegrasi

  • Saya belum begitu menangkap bagaimana ini berinteraksi dengan data
    Jika kami menyimpan Delta table di ADLS dan tidak bisa mengambil data produksi ke lokal, saya penasaran apakah ini tetap bisa dipakai. Jika untuk berpindah ke versi lama cukup melihat Delta log, saya juga bertanya-tanya apakah ada alasan memakai DVC

    • Berdasarkan cara saya memakainya, DVC lebih mirip git LFS yang mendukung beberapa backend, dan bisa juga dilihat sebagai git-annex yang lebih sederhana
      Di atas itu ada fitur-fitur yang lebih khusus untuk MLOps. Ini nyaman saat melakukan versioning untuk pelatihan model dengan data di S3 yang berubah-ubah

  • Kami juga pernah mengevaluasi DVC, tetapi untuk use case tertentu paradigma Git tidak terlalu berguna
    Kasusnya adalah file video sangat besar yang hampir tidak berubah, dan kami membutuhkan satu salinan data di sisi sumber serta satu salinan lagi di tiap sistem yang menjalankan pelatihan. Pada akhirnya kami memakai file dan folder di NAS, dan itu bekerja cukup baik. Pendekatan hibrida yang hanya mengelola metadata dataset dengan DVC lalu melakukan versioning atasnya tampaknya memungkinkan. Namun itu terjadi beberapa tahun lalu, dan saya penasaran apakah sekarang ada lebih banyak solusi versioning data on-premises. Terakhir kali saya mencari, sebagian besar tampak berorientasi cloud

  • Penasaran apa keunggulan DVC dibandingkan Apache Iceberg
    Kalau ada yang pernah memakai keduanya, saya ingin mendengar pandangannya

    • Kalau penasaran soal ini, Icechunk yang dijadikan open source minggu ini juga perlu dilihat
      Mirip Apache Iceberg, tetapi merupakan alat untuk data multidimensi seperti Zarr. https://earthmover.io/blog/icechunk dan https://news.ycombinator.com/item?id=41850352
    • Keunggulan yang jelas tidak terlalu terlihat, rasanya seperti memakai alat yang sudah dikenal di tempat yang kurang cocok
      Iceberg mungkin memang lebih disesuaikan untuk model yang perubahannya lebih lambat daripada pendekatan ini
    • Pikiran saya belum terlalu tertata, tapi kalau dicoba dijelaskan, contoh bagus dari data blob yang dimaksud di sini adalah sekumpulan file video 1080p yang sangat panjang
      Singkatnya, data blob tak terstruktur cocok dimasukkan ke DVC, sedangkan data terstruktur cocok dimasukkan ke Iceberg. Kelebihan DVC dibanding Iceberg adalah data blob tidak perlu dipaksa masuk ke format tabel, dan bisa menghindari tahapan pemrosesan merepotkan yang menyertainya. Pada dasarnya tidak perlu menjalankan tahap pemrosesan untuk mengeluarkan data blob dari file Parquet; cukup unduh setiap file apa adanya dengan perintah seperti dvc pull. Setelah mengubah file secara lokal, Anda bisa melakukan commit dengan kira-kira tiga perintah, dan tidak perlu pipeline ingest data untuk memaksa data blob masuk ke tabel. Karena benar-benar tanpa skema, cukup masukkan ke repositori dan commit tanpa khawatir soal tipe. Rollback bisa mengikuti seluruh riwayat commit, bukan hanya sampai vacuum/checkpoint terakhir. Memaksa data blob masuk ke format data tabular hampir seperti resep penderitaan, dan memasukkan blob ke repositori ala Git jauh lebih cepat dan mudah. Ini terutama berlaku jika Anda membutuhkan seluruh riwayat versi atau branch untuk hasil yang berbeda; menerapkan filter ffmpeg yang berbeda per branch pada file-file video 1080p panjang, lalu membuat orang dapat mengakses semua hasil dan riwayatnya, akan seperti mimpi buruk di Iceberg tetapi mudah di DVC. Pada akhirnya, karena semuanya dikelola versinya, rasanya seperti membuat data lake yang tidak berubah menjadi data swamp

  • Saat dipakai untuk dataset yang terdiri dari banyak file jpg, ada banyak masalah
    Setiap dvc status, proses pengindeksan yang memeriksa semua file memakan waktu beberapa menit, dan caching juga tidak bekerja. Sayangnya akhirnya harus menyerah

    • Benar, performanya cukup buruk dan caching bisa menimbulkan banyak sakit kepala
      Apalagi jika memakai sistem berkas yang tidak mendukung reflink. Untuk dataset besar yang di-shard seperti WebDataset, solusi lain lebih baik, terutama jika pipeline machine learning bisa melakukan streaming langsung dari object storage

  • Saya juga pernah mendengar lakeFS sebagai alat versioning data di atas object storage S3
    Penasaran apakah DVC bisa menjadi pesaing di area ini