Saya seorang mahasiswa PhD Geofisika dan bekerja dengan sejumlah besar data gambar (ratusan GB, puluhan ribu file). Saya tahu svn
dan git
cukup baik dan datang untuk menghargai sejarah proyek, dikombinasikan dengan kemampuan untuk mudah bekerja sama dan memiliki perlindungan terhadap kerusakan disk. Saya menemukan git
juga sangat membantu untuk memiliki cadangan yang konsisten tetapi saya tahu bahwa git tidak dapat menangani sejumlah besar data biner secara efisien.
Dalam studi master saya, saya bekerja pada kumpulan data dengan ukuran yang sama (juga gambar) dan memiliki banyak masalah melacak versi yang berbeda pada server / perangkat yang berbeda. Menyebarkan 100GB melalui jaringan benar-benar tidak menyenangkan, dan menghabiskan banyak waktu dan upaya saya.
Saya tahu bahwa orang lain dalam sains tampaknya memiliki masalah yang sama, namun saya tidak dapat menemukan solusi yang baik.
Saya ingin menggunakan fasilitas penyimpanan di institut saya, jadi saya perlu sesuatu yang bisa menggunakan server "bodoh". Saya juga ingin memiliki cadangan tambahan pada hard disk portabel, karena saya ingin menghindari mentransfer ratusan GB melalui jaringan sedapat mungkin. Jadi, saya memerlukan alat yang dapat menangani lebih dari satu lokasi terpencil.
Terakhir, saya benar-benar membutuhkan sesuatu yang bisa digunakan peneliti lain, jadi tidak perlu super sederhana, tetapi harus dipelajari dalam beberapa jam.
Saya telah mengevaluasi banyak solusi yang berbeda, tetapi tampaknya tidak ada yang sesuai dengan tagihan:
- svn agak tidak efisien dan membutuhkan server pintar
- hg bigfile / largefile hanya dapat menggunakan satu remote
- git bigfile / media juga dapat menggunakan hanya satu remote, tetapi juga tidak terlalu efisien
- loteng tampaknya tidak memiliki log, atau kemampuan yang berbeda
- bup terlihat sangat bagus, tetapi membutuhkan server "pintar" untuk bekerja
Saya sudah mencoba git-annex
, yang melakukan semua yang saya butuhkan (dan masih banyak lagi), tetapi sangat sulit digunakan dan tidak didokumentasikan dengan baik. Saya sudah menggunakannya selama beberapa hari dan tidak bisa memahaminya, jadi saya ragu rekan kerja lain akan tertarik.
Bagaimana peneliti menangani set data besar, dan apa yang digunakan kelompok riset lain?
Untuk lebih jelasnya, saya terutama tertarik pada bagaimana peneliti lain menangani situasi ini, bukan hanya dataset khusus ini. Tampaknya bagi saya bahwa hampir semua orang seharusnya memiliki masalah ini, namun saya tidak tahu siapa yang telah menyelesaikannya. Haruskah saya menyimpan cadangan data asli dan melupakan semua hal ini versi kontrol? Itukah yang dilakukan orang lain?
sumber
Jawaban:
Apa yang akhirnya saya gunakan adalah semacam solusi hybrid:
Saya percaya itu jarang masuk akal untuk memiliki sejarah revisi penuh dari sejumlah besar data biner, karena waktu yang dibutuhkan untuk meninjau perubahan pada akhirnya akan sangat luar biasa sehingga tidak akan terbayar dalam jangka panjang. Mungkin prosedur snapshot semi-otomatis (akhirnya untuk menghemat ruang disk, dengan tidak mereplikasi data yang tidak berubah di berbagai snapshot) akan membantu.
sumber
find . -type f -print0 | xargs -0 md5sum > checksums.md5
untuk menghitung checksum danmd5sum -c checksums.md5
checksum, dan versi mengontrol checksum. Itu membantu untuk memeriksa data di lokasi yang berbeda / pada mesin yang berbeda. Tampaknya menjadi yang terbaik yang bisa kita lakukan saat ini,rsync
pada (salinan) data asli. Satu kemungkinan lain yang umum dalam ilmu saraf (walaupun saya tidak begitu menyukainya karena kadang-kadang tidak terdokumentasi sebagaimana mestinya), adalah menggunakan paket nipype python, yang dapat dilihat sebagai alur kerja (semacam) manajer dan mengelola cache data biner dari langkah perantara analisis secara otomatis.Saya telah berurusan dengan masalah yang sama dengan set data biologi sintetik yang sangat besar, di mana kami memiliki banyak, banyak GB data aliran cytometry yang tersebar di banyak, ribuan file, dan perlu mempertahankannya secara konsisten di antara kelompok-kelompok yang berkolaborasi di (beberapa) lembaga yang berbeda.
Kontrol versi umum seperti svn dan git tidak praktis untuk keadaan ini, karena itu hanya tidak dirancang untuk jenis dataset ini. Sebagai gantinya, kami telah jatuh ke menggunakan solusi "penyimpanan cloud", terutama DropBox dan Bittorrent Sync. DropBox memiliki keuntungan bahwa ia melakukan setidaknya beberapa penebangan primitif dan kontrol versi dan mengelola server untuk Anda, tetapi kelemahannya adalah layanan komersial, Anda harus membayar untuk penyimpanan besar, dan Anda meletakkan data yang tidak dipublikasikan pada sebuah penyimpanan komersial; Anda tidak perlu membayar banyak, jadi itu pilihan yang layak. Bittorrent Sync memiliki antarmuka yang sangat mirip, tetapi Anda menjalankannya sendiri di server penyimpanan Anda sendiri dan tidak memiliki kontrol versi. Keduanya menyakiti jiwa programmer saya, tetapi mereka adalah solusi terbaik yang saya dan kolaborator temukan sejauh ini.
sumber
Saya telah menggunakan Versioning on Amazon S3 bucket untuk mengelola 10-100GB dalam 10-100 file. Transfer bisa lambat, sehingga telah membantu untuk mengompresi dan mentransfer secara paralel, atau hanya menjalankan perhitungan pada EC2. The boto perpustakaan menyediakan antarmuka python bagus.
sumber
Coba cari di Git Large File Storage (LFS) . Ini baru, tetapi mungkin hal yang pantas untuk dilihat.
Seperti yang saya lihat, diskusi tentang Hacker News menyebutkan beberapa cara lain untuk menangani file besar:
sumber
Kami tidak mengontrol versi file data aktual. Kami tidak ingin bahkan jika kami menyimpannya sebagai CSV alih-alih dalam bentuk biner. Seperti yang dikatakan Riccardo M. , kita tidak akan menghabiskan waktu untuk meninjau perubahan baris-demi-baris pada set data 10 juta baris.
Sebagai gantinya, bersama dengan kode pemrosesan, saya mengontrol versi metadata:
Ini memberi saya informasi yang cukup untuk mengetahui apakah file data telah berubah dan gagasan tentang apa yang telah berubah (misalnya, baris yang ditambahkan / dihapus, kolom baru / yang diganti nama), tanpa menekankan VCS.
sumber
Ini adalah masalah yang cukup umum. Saya merasakan sakit ini ketika saya melakukan proyek penelitian untuk sebuah universitas dan sekarang - dalam proyek ilmu data industri.
Saya telah membuat dan baru-baru ini merilis alat sumber terbuka untuk mengatasi masalah ini - DVC .
Ini pada dasarnya menggabungkan kode Anda di Git dan data di disk atau cloud lokal Anda (penyimpanan S3 dan GCP). DVC melacak ketergantungan antara data dan kode dan membangun grafik dependensi (DAG). Ini membantu Anda membuat proyek Anda dapat direproduksi.
Proyek DVC dapat dengan mudah dibagikan - sinkronkan data Anda ke cloud (perintah dvc sync), bagikan repositori Git Anda dan berikan akses ke keranjang data Anda di cloud.
"bisa dipelajari dalam beberapa jam" - adalah poin yang bagus. Anda seharusnya tidak memiliki masalah dengan DVC jika Anda terbiasa dengan Git. Anda benar-benar perlu mempelajari hanya tiga perintah:
dvc init
- sepertigit init
. Harus dilakukan di repositori Git yang ada.dvc import
- Impor file data Anda (sumber). File atau URL lokal.dvc run
- langkah-langkah alur kerja Anda sepertidvc run python mycode.py data/input.jpg data/output.csv
. DVC mendapatkan ketergantungan antara langkah-langkah Anda secara otomatis, membangun DAG dan menyimpannya di Git.dvc repro
- mereproduksi file data Anda. Contoh:vi mycode.py
- ubah kode, dan kemudiandvc repro data/output.csv
akan mereproduksi file (dan semua dependensi.Anda perlu mempelajari beberapa perintah DVC lain untuk berbagi data melalui cloud dan keterampilan dasar S3 atau GCP.
DVC tutorial adalah titik awal terbaik - "Kontrol Versi Data: pembelajaran mesin iteratif"
sumber
Saya belum menggunakannya tetapi ada diskusi serupa di kelompok keuangan
saran perangkat lunak penyimpanan data scidb , zfs, http://www.urbackup.org/
sumber
Anda dapat melihat proyek saya yang disebut DOT: Manajer repositori Pelacak Objek Distrubuted.
Ini adalah VCS yang sangat sederhana untuk file biner untuk penggunaan pribadi (tanpa kolaborasi).
Ini menggunakan SHA1 untuk checksuming dan memblokir deduplikasi. Sinkronisasi P2P penuh.
Satu fitur unik: adhoc one time TCP server untuk menarik / mendorong.
Itu juga dapat menggunakan SSH untuk transportasi.
Ini belum dirilis, tetapi mungkin merupakan titik awal yang baik.
http://borg.uu3.net/cgit/cgit.cgi/dot/about/
sumber
Anda dapat mencoba menggunakan hanggar . Ini adalah pemain yang relatif baru di dunia kontrol versi data tetapi melakukan pekerjaan yang sangat bagus dengan memvariasikan tensor alih-alih membuat versi gumpalan. Dokumentasi harus menjadi tempat terbaik untuk memulai. Karena data disimpan sebagai tensor, Anda harus dapat menggunakannya langsung di dalam kode ML Anda (ditambah hanggar sekarang memiliki pemuat data untuk PyTorch dan Tensorflow). Dengan hanggar, Anda bisa mendapatkan semua manfaat dari git seperti percabangan, penggabungan, perjalanan waktu tanpa biaya melalui sejarah. Salah satu fitur bagus tentang kloning di hanggar adalah Anda bisa melakukan kloning parsial . Yang berarti, jika Anda memiliki 10 TB data di remote Anda dan hanya perlu 100 MB untuk membuat prototipe model Anda, Anda bisa mengambil hanya 100 MB melalui kloning parsial alih-alih klon penuh.
sumber