Jak radzić sobie z kontrolą wersji dużych ilości (binarnych) danych

Jestem doktorantem geofizyki i pracuję z dużą ilością danych obrazu (setki GB, dziesiątki tysięcy plików). Znam svni gitdość dobrze i doceniać historię projektu, w połączeniu ze zdolnością do łatwo pracować razem i mieć ochronę przed uszkodzeniem dysku. Uważam gitrównież za bardzo pomocny w utrzymywaniu spójnych kopii zapasowych, ale wiem, że git nie może efektywnie obsługiwać dużych ilości danych binarnych.

W ramach studiów magisterskich pracowałem nad zestawami danych o podobnej wielkości (także obrazach) i miałem wiele problemów ze śledzeniem różnych wersji na różnych serwerach / urządzeniach. Różnicowanie 100 GB przez sieć naprawdę nie jest fajne i kosztowało mnie dużo czasu i wysiłku.

Wiem, że inni w nauce mają podobne problemy, ale nie mogłem znaleźć dobrego rozwiązania.

Chcę korzystać z urządzeń pamięci masowej mojego instytutu, więc potrzebuję czegoś, co może wykorzystać „głupi” serwer. Chciałbym również mieć dodatkową kopię zapasową na przenośnym dysku twardym, ponieważ w miarę możliwości chciałbym unikać przesyłania setek GB przez sieć. Potrzebuję więc narzędzia, które może obsłużyć więcej niż jedną zdalną lokalizację.

Wreszcie naprawdę potrzebuję czegoś, z czego mógłby skorzystać inny badacz, więc nie musi to być bardzo proste, ale powinno być możliwe do nauczenia się za kilka godzin.

Oceniłem wiele różnych rozwiązań, ale żadne nie wydaje się pasować do rachunku:

• svn jest nieco nieefektywny i wymaga inteligentnego serwera
• hg bigfile / largefile może używać tylko jednego pilota
• git bigfile / media może również używać tylko jednego pilota, ale również nie jest bardzo wydajny
• strych nie wydaje się mieć dziennika ani innych możliwości
• bup wygląda naprawdę dobrze, ale do działania potrzebuje „inteligentnego” serwera

Próbowałem git-annex, co robi wszystko, czego potrzebuję (i wiele więcej), ale jest bardzo trudny w użyciu i nie jest dobrze udokumentowany. Używałem go od kilku dni i nie mogłem go obejść, więc wątpię, czy jakikolwiek inny współpracownik byłby zainteresowany.

Jak badacze radzą sobie z dużymi zbiorami danych i z czego korzystają inne grupy badawcze?

Dla jasności interesuje mnie przede wszystkim sposób, w jaki inni badacze radzą sobie z tą sytuacją, a nie tylko ten konkretny zestaw danych. Wydaje mi się, że prawie każdy powinien mieć ten problem, ale nie znam nikogo, kto go rozwiązał. Czy powinienem po prostu zachować kopię zapasową oryginalnych danych i zapomnieć o tych wszystkich kontrolach wersji? Czy to właśnie robią wszyscy inni?

Skończyło się to rodzajem rozwiązania hybrydowego:

• kopia zapasowa surowych danych
• Git przepływu pracy
• manualne migawki przepływu pracy + przetwarzane dane, które są istotne, np .:
  • standardowe przetwarzanie wstępne
  • naprawdę czasochłonne
  • do publikacji

Uważam, że rzadko sensowne jest posiadanie pełnej historii zmian dużej ilości danych binarnych, ponieważ czas potrzebny na sprawdzenie zmian ostatecznie będzie tak przytłaczający, że na dłuższą metę się nie opłaci. Może przydałaby się półautomatyczna procedura tworzenia migawek (aby ostatecznie zaoszczędzić trochę miejsca na dysku, nie powielając niezmienionych danych w różnych migawkach).

Miałem do czynienia z podobnymi problemami z bardzo dużymi zestawami danych z biologii syntetycznej, w których mamy wiele GB danych z cytometrii przepływowej rozproszonych w wielu, wielu tysiącach plików i muszę je konsekwentnie utrzymywać między współpracującymi grupami w (wielu) różnych instytucjach.

Typowa kontrola wersji, jak svn i git, nie jest praktyczna w takich okolicznościach, ponieważ po prostu nie jest zaprojektowana dla tego typu zestawu danych. Zamiast tego zaczęliśmy używać rozwiązań do przechowywania danych w chmurze, w szczególności DropBox i Bittorrent Sync. DropBox ma tę zaletę, że wykonuje co najmniej pewne prymitywne rejestrowanie i kontrolę wersji oraz zarządza serwerami dla Ciebie, ale wadą jest to, że jest to usługa komercyjna, musisz zapłacić za dużą przestrzeń dyskową i umieszczasz swoje niepublikowane dane na przechowywanie komercyjne; nie musisz jednak dużo płacić, więc jest to opłacalna opcja. Bittorrent Sync ma bardzo podobny interfejs, ale uruchamiasz go sam na własnych serwerach pamięci i nie ma żadnej kontroli wersji. Oba zraniły moją duszę programisty, ale są to najlepsze rozwiązania, które dotychczas współpracowali z moimi współpracownikami.

Użyłem wersjonowania na segmentach Amazon S3 do zarządzania 10-100 GB w 10-100 plikach. Transfer może być powolny, więc pomógł kompresować i przesyłać równolegle lub po prostu uruchomić obliczenia na EC2. Boto biblioteki zapewnia ładny interfejs Pythona.

Spróbuj spojrzeć na Git Large File Storage (LFS) . Jest nowy, ale może być wart uwagi.

Jak widzę, dyskusja w Hacker News wymienia kilka innych sposobów radzenia sobie z dużymi plikami:

• git-Annex (i np. używając go z Amazon S3 )
• Rozszerzenie Mercurual Largefiles

Nie kontrolujemy wersji rzeczywistych plików danych. Nie chcielibyśmy nawet, gdybyśmy przechowywali go jako CSV zamiast w formie binarnej. Jak powiedział Riccardo M. , nie będziemy spędzać czasu na analizowaniu zmian rząd po rzędzie w zestawie danych rzędu 10 milionów.

Zamiast tego, wraz z kodem przetwarzania, kontroluję wersję metadanych:

• Data modyfikacji
• Rozmiar pliku
• Liczba wierszy
• Nazwy kolumn

Daje mi to wystarczającą ilość informacji, aby wiedzieć, czy plik danych się zmienił, oraz pojęcie, co się zmieniło (np. Wiersze dodane / usunięte, nowe / zmienione nazwy kolumn), bez stresowania VCS.

To dość powszechny problem. Miałem ten ból, kiedy prowadziłem projekty badawcze dla uniwersytetu, a teraz - w projektach dotyczących danych przemysłowych.

Stworzyłem i niedawno wypuściłem narzędzie typu open source, aby rozwiązać ten problem - DVC .

Zasadniczo łączy kod w Git i dane na lokalnym dysku lub chmurach (pamięć S3 i GCP). DVC śledzi zależność między danymi a kodem i buduje wykres zależności (DAG). Pomaga w odtwarzaniu projektu.

Projekt DVC można łatwo udostępnić - zsynchronizuj dane z chmurą (polecenie synchronizacji dvc), udostępnij repozytorium Git i zapewnij dostęp do zasobnika danych w chmurze.

„można się nauczyć za kilka godzin” - to dobry punkt. Jeśli znasz Git, nie powinieneś mieć żadnych problemów z DVC. Naprawdę musisz nauczyć się tylko trzech poleceń:

1. dvc init- jak git init. Należy to zrobić w istniejącym repozytorium Git.
2. dvc import- importuj swoje pliki danych (źródła). Lokalny plik lub adres URL.
3. dvc run- kroki twojego przepływu pracy jak dvc run python mycode.py data/input.jpg data/output.csv. DVC automatycznie określa zależność między twoimi krokami, buduje DAG i utrzymuje go w Git.
4. dvc repro- odtworzyć plik danych. Przykład: vi mycode.py- zmień kod, a następnie dvc repro data/output.csvodtworzy plik (i wszystkie zależności).

Musisz nauczyć się jeszcze kilku poleceń DVC, aby udostępniać dane w chmurze i podstawowe umiejętności S3 lub GCP.

Samouczek DVC jest najlepszym punktem wyjścia - „Kontrola wersji danych: iteracyjne uczenie maszynowe”

Nie korzystałem z nich, ale podobna dyskusja odbyła się w grupie finansowej

sugestie oprogramowania repozytorium danych scidb , zfs, http://www.urbackup.org/

Możesz rzucić okiem na mój projekt o nazwie DOT: Menedżer repozytorium Distrubuted Object Tracker.
Jest to bardzo prosty VCS dla plików binarnych do użytku osobistego (bez współpracy).
Wykorzystuje SHA1 do sumowania kontrolnego i deduplikacji bloków. Pełna synchronizacja P2P.
Jedna unikalna cecha: jednorazowy serwer TCP adhoc do ściągania / wypychania.
Może także wykorzystywać SSH do transportu.

Nie został jeszcze wydany, ale może być dobrym punktem wyjścia.
http://borg.uu3.net/cgit/cgit.cgi/dot/about/

Możesz spróbować użyć hangaru . Jest to stosunkowo nowy odtwarzacz w świecie kontroli wersji danych, ale wykonuje naprawdę dobrą robotę, zmieniając tensory zamiast wersjonując obiekt blob. Dokumentacja musi być najlepszym miejscem na rozpoczęcie. Ponieważ dane są przechowywane jako tensory, powinieneś być w stanie używać ich bezpośrednio w kodzie ML (plus hangar ma teraz moduły ładujące dane dla PyTorch i Tensorflow). Dzięki hangarowi możesz czerpać wszystkie korzyści z git, takie jak rozgałęzianie, łączenie, podróż w czasie przez historię za zero kosztów. Jedną z fajnych cech klonowania w hangarze jest możliwość częściowego klonowania . Co oznacza, że ​​jeśli masz 10 TB danych na pilocie i potrzebujesz tylko 100 MB do prototypowania swojego modelu, możesz pobrać tylko 100 MB poprzez częściowe klonowanie zamiast pełnego klonowania.