Büyük miktarlarda (ikili) verilerin sürüm kontrolü ile nasıl baş edilir

Ben Jeofizik doktora öğrencisiyim ve çok fazla resim verisiyle çalışıyorum (yüzlerce GB, on binlerce dosya). Biliyorum svnve gitoldukça iyi ve birlikte kolayca işe yeteneği ile kombine bir proje öyküsü, değer ve disk yolsuzluğa karşı korumaya sahip geliyorlar. gitTutarlı yedeklemeler için de son derece yararlı buluyorum ancak Git'in büyük miktarlarda ikili verileri verimli bir şekilde idare edemediğini biliyorum.

Yüksek lisans çalışmalarımda, benzer boyuttaki veri kümelerinde (aynı zamanda resimlerde) çalıştım ve farklı sunucularda / cihazlarda farklı sürümleri takip etmede sorun yaşadım. Ağ üzerinden 100 GB dağıtmak gerçekten eğlenceli değil ve bana çok zaman ve emek harcadı.

Bilimdeki diğerlerinin de benzer problemleri olduğunu biliyorum ama yine de iyi bir çözüm bulamadım.

Enstitümün depolama olanaklarını kullanmak istiyorum, bu yüzden "aptal" bir sunucu kullanabilecek bir şeye ihtiyacım var. Ayrıca taşınabilir bir sabit diskte ek bir yedekleme yapmak istiyorum, çünkü mümkün olan her yerde ağ üzerinden yüzlerce GB aktarımı yapmak istemiyorum. Bu yüzden, birden fazla uzak konumu işleyebilecek bir araca ihtiyacım var.

Son olarak, diğer araştırmacıların kullanabileceği bir şeye ihtiyacım var, bu yüzden süper basit olması gerekmez, ancak birkaç saat içinde öğrenilebilir olması gerekir.

Birçok farklı çözümü değerlendirdim, ancak hiçbiri tasarıya uygun görünmüyor:

• svn biraz verimsiz ve akıllı bir sunucuya ihtiyaç duyuyor
• hg bigfile / largefile sadece bir uzaktan kumanda kullanabilir
• git bigfile / media yalnızca bir uzaktan kumanda kullanabilir, ancak çok verimli değil
• çatı bir günlük veya farklı yeteneklere sahip gibi görünmüyor
• bup gerçekten iyi görünüyor, ancak çalışması için "akıllı" bir sunucuya ihtiyacı var

Yapmam gereken git-annexher şeyi yapan denedim (ve çok daha fazlası), ancak kullanımı çok zor ve iyi belgelenmiş değil. Birkaç gün kullandım ve kafamı dolaştıramadı, bu yüzden başka bir iş arkadaşının ilgisini çekeceğinden şüpheliyim.

Araştırmacılar büyük veri kümeleriyle nasıl başa çıkmaktadır ve diğer araştırma grupları neler kullanıyor?

Açıkçası, öncelikle sadece bu spesifik veri setiyle değil, diğer araştırmacıların bu durumla nasıl başa çıktıklarıyla ilgileniyorum. Bana öyle geliyor ki neredeyse herkesin bu problemi olması gerekiyor, ama bunu çözen birini tanımıyorum. Orijinal verilerin bir yedeğini almalı mıyım ve tüm bu sürüm kontrol malzemelerini mi unutmalıyım? Herkesin yaptığı bu mu?

Kullanmaya son verdiğim şey bir çeşit hibrit çözüm.

• Ham verilerin yedeklenmesi
• iş akışının gitmesi
• İş akışının + işlenmiş verinin manuel anlık görüntüleri, örneğin:
  • standart ön işleme
  • gerçekten zaman alıcı
  • yayın için

Çok fazla miktarda ikili veri için tam bir revizyon geçmişine sahip olmanın nadiren mantıklı olduğuna inanıyorum, çünkü değişiklikleri gözden geçirmek için gereken zaman sonunda uzun vadede ödeme yapamayacağı kadar büyük olacaktır. Belki de yarı otomatik bir anlık görüntü prosedürü (nihayetinde, farklı anlık görüntüler arasında değişmemiş verileri çoğaltarak disk alanından tasarruf etmek için) yardımcı olabilir.

Çok , çok sayıda binlerce dosyaya yayılmış çok sayıda, çok sayıda GB akış sitometri verisine sahip olduğumuz ve bunları (çok) farklı kurumdaki işbirliği yapan gruplar arasında tutarlı bir şekilde sürdürmemiz gereken çok büyük sentetik biyoloji veri setleri ile benzer problemleri çözdüm .

Svn ve git gibi tipik sürüm kontrolü bu durum için pratik değildir, çünkü bu veri seti için tasarlanmamıştır. Bunun yerine, "bulut depolama" çözümlerini, özellikle DropBox ve Bittorrent Senk.. DropBox, en azından bazı ilkel günlüğe kaydetme ve sürüm kontrolü yapma ve sizin için sunucuları yönetme avantajına sahiptir, ancak dezavantajı ticari bir hizmettir, büyük depolama için ödemeniz gerekir ve yayınlanmamış verilerinizi bir ticari depolama; Çok fazla para ödemek zorunda değilsiniz, bu yüzden uygulanabilir bir seçenek. Bittorrent Sync'in çok benzer bir arayüzü var, ancak kendiniz de kendi depolama sunucularınız üzerinde çalıştırıyorsunuz ve sürüm kontrolü yok. Her ikisi de programcı ruhumun canını yakıyor, fakat ortak çalışanlarım ve şimdiye kadar bulduğum en iyi çözümler.

10-100 dosyada 10-100 GB'lık yönetmek için Amazon S3 kovalarındaki Versioning'i kullandım . Transfer yavaş olabilir, bu nedenle paralel olarak sıkıştırılmaya ve aktarılmaya ya da EC2'de hesaplamaları çalıştırmaya yardımcı olmuştur. Boto kütüphanesi güzel bir piton arayüz sağlar.

Git Large Dosya Deposu'na (LFS) bakmayı deneyin . Yeni, ama bakmaya değer bir şey olabilir.

Gördüğüm gibi , Hacker News’le ilgili bir tartışma, büyük dosyalarla başa çıkabilmek için birkaç yöntemden bahseder:

• git-annex (ve örneğin Amazon S3 ile kullanma )
• Mercurual Largefiles uzantısı

Gerçek veri dosyalarını sürüm olarak kontrol etmiyoruz. İkili bir form yerine CSV olarak saklasak bile istemeyiz. As Riccardo M. söyledi, bir 10M satır veri setinde bizim zaman inceleme satır-by-satır değişiklikleri geçirmek için gitmiyoruz.

Bunun yerine, işlem koduyla birlikte, meta verileri kontrol ediyorum:

• Düzenleme tarihi
• Dosya boyutu
• Satır sayısı
• Sütun adları

Bu bana bilecek kadar bilgi verir , eğer bir veri dosyası değişti ve bir fikri nedir VCS zorlamadan, (örneğin, satırlar eklendiğinde / silinmiş, yeni / yeniden adlandırılmış sütunlar) değişti.

Bu oldukça yaygın bir sorundur. Endüstriyel veri bilimi projelerinde, bir üniversite için araştırma projeleri yaptığımda ve şu anda bu acıyı yaşadım.

DVC - Ben bu sorunu çözmek için açık kaynak kodlu bir araç yarattım .

Temelde Git kodunu ve yerel diskinizdeki veya bulutlardaki verileri (S3 ve GCP depolama alanı) birleştirir. DVC, veri ve kod arasındaki bağımlılığı izler ve bağımlılık grafiğini (DAG) oluşturur. Projenizi tekrarlanabilir hale getirmenize yardımcı olur.

DVC projesi kolayca paylaşılabilir - verilerinizi bir bulutla senkronize edin (dvc sync komutu), Git havuzunuzu paylaşın ve buluttaki veri kovasınıza erişim sağlayın.

"birkaç saat içinde öğrenilebilir" - iyi bir nokta. Git ile ilgili bilginiz varsa DVC ile ilgili herhangi bir sorununuz olmamalıdır. Gerçekten sadece üç komutu öğrenmeniz gerekir:

1. dvc init- gibi git init. Mevcut bir Git deposunda yapılmalıdır.
2. dvc import- veri dosyalarınızı (kaynaklar) alın. Yerel dosya veya URL.
3. dvc run- iş akışınızın adımları gibi dvc run python mycode.py data/input.jpg data/output.csv. DVC, adımlarınız arasındaki bağımlılığı otomatik olarak türetir, DAG'yi oluşturur ve Git'te tutar.
4. dvc repro- veri dosyanızı yeniden oluşturun. Örnek: vi mycode.py- kodu değiştirdikten sonra dvc repro data/output.csvdosyayı (ve tüm bağımlılıkları yeniden üretir).

Bulut ve temel S3 veya GCP becerileri yoluyla veri paylaşmak için birkaç DVC komutu daha öğrenmeniz gerekir.

DVC eğitimi, en iyi başlangıç ​​noktasıdır - "Veri Sürümü Kontrolü: yinelemeli makine öğrenmesi"

Onları kullanmadım ama bir finans grubunda da benzer bir tartışma oldu.

veri havuzu yazılım önerileri scidb , zfs, http://www.urbackup.org/

DOT: Distrubuted Object Tracker depo yöneticisi adlı projeme bakabilirsiniz.
Kişisel kullanım için ikili dosyalar için çok basit bir VCS (işbirliği yok).
Sağlama toplamı ve blok tekilleştirme için SHA1 kullanır. Tam P2P senkronizasyonu.
Benzersiz bir özellik: çekme / basma için bir defalık TCP sunucusunu adhoc.
Taşıma için SSH'yi de kullanabilir.

Henüz yayınlanmadı, ancak iyi bir başlangıç ​​noktası olabilir.
http://borg.uu3.net/cgit/cgit.cgi/dot/about/

Hangarı kullanmayı deneyebilirsin . Veri sürümü kontrol dünyasına nispeten yeni bir oyuncu ama blob'u değiştirmek yerine tensörleri modelleyerek gerçekten çok güzel bir iş çıkarıyor. Belgelendirme başlamak için en iyi yer olmalıdır. Veriler tensör olarak saklandığından, bunu doğrudan ML kodunuzda kullanabilmelisiniz (artı hangarda PyTorch ve Tensorflow için veri yükleyicileri vardır). Hangarla birlikte, sıfır maliyetli dallanma, birleşme, tarih boyunca zaman yolculuğu gibi git'in tüm avantajlarından yararlanabilirsiniz. Hangarda klonlama ile ilgili güzel bir özellik, kısmi klonlama yapabilmenizdir . Yani, uzaktan kumandanızda 10 TB veri varsa ve modelinizi prototip yapmak için sadece 100 MB'a ihtiyacınız varsa, tam klon yerine kısmi klonlama yoluyla sadece 100 MB alabilirsiniz.