Pitanje:
Kako verziju koda i podataka tijekom analize?
Iakov Davydov
2017-05-18 14:27:51 UTC
view on stackexchange narkive permalink

Trenutno tražim sustav koji će mi omogućiti verziju i koda i podataka u mojem istraživanju.

Mislim da moj način analiziranja podataka nije neobičan, a ovo će biti korisno za mnogi ljudi rade bioinformatiku i ciljaju na ponovljivost.

Evo sljedećih zahtjeva:

  • Analiza se provodi na više strojeva (lokalni, klaster, poslužitelj).
  • Sav kôd je transparentno sinkroniziran između strojeva.
  • Izrada verzija izvornog koda.
  • Izrada verzija generiranih podataka.
  • Podrška za veliki broj malih generiranih datoteka (> 10 000). Oni se također mogu izbrisati.
  • Podrška za velike datoteke (> 1Gb). U nekom trenutku stare generirane datoteke mogu se trajno izbrisati. Bilo bi suludo imati transparentnu sinkronizaciju onih, ali moći bi ih sinkronizirati na zahtjev.

Do sada koristim git + rsync / scp. Ali ima nekoliko nedostataka.

  • Sinkronizacija između više računala pomalo je zamorna, tj. Morate git pull prije nego što počnete raditi i git push nakon svakog ažuriranja. Mogu živjeti s tim.
  • Ne biste trebali spremati velike generirane podatkovne datoteke ili velik broj datoteka u svoje spremište.
  • Stoga moram ručno sinkronizirati podatkovne datoteke pomoću rsync, što je sklono pogreškama.

Postoji nešto što se zove git annex. Čini se stvarno blizu onoga što trebam. Ali:

  • Nešto više posla nego git, ali to je u redu.
  • Nažalost, čini se da ne radi dobro s velikim brojem datoteka. Često u svojoj analizi imam više od 10.000 malih datoteka. Postoje neki trikovi za poboljšanje indeksiranja, ali to ne rješava problem. Ono što mi treba je jedna simbolična veza koja predstavlja puni sadržaj direktorija.

Jedno potencijalno rješenje je uporaba Dropboxa ili nečeg sličnog (poput sinkronizacije) u kombinaciji s git-om. Ali loša strana je što neće postojati veza između verzije izvornog koda i podatkovne verzije.

Postoji li sustav za inačice koda i podataka koji udovoljavaju zahtjevima koje možete preporučiti?

Nije točno ono što tražite, niti je u poziciji da bih ga koristio stalno, ali već pišem softver pod nazivom `chitin`: https://github.com/SamStudio8/chitin /. Dizajniran je da prati kako su datoteke stvorene i što se s njima dogodilo. Nije dizajniran za pohranu promjena (poput gita) - ali zapravo smatram da su metapodaci korisniji od stvarnih promjena (osim koda, koji naravno živi u gitu).
@SamStudio8 izgleda zanimljivo. Još nisam potpuno uvjeren, ali IMHO vrijedi objaviti kao odgovor.
Uobičajeni pristup za to je imati jedan direktorij koji se izvozi na razne strojeve (lokalni, klaster, poslužitelj). Zašto biste duplicirali podatke na ovaj način, umjesto da samo koristite centralizirano spremište?
@terdon često nemate root pristup na klasteru, stoga tamo ne možete samo montirati mrežni datotečni sustav (a ako ima mnogo malih datoteka ili velikih datoteka koje zbog performansi ne želite). U drugom smislu, ovo je slično rješenju za sinkronizaciju / ispuštanje, kojem nedostaju ispravne verzije i korespondencija između izvornog koda i podataka.
Pa, ako trebate sinkronizirati GB podataka, onda to radite pogrešno. Ako trebate root pristup, zamolio bih vašeg sysadmina da postavi sustav na način koji vam omogućuje zajedničke diskove. Nikad nisam vidio nikoga da radi na način na koji opisujete, sva tri mjesta na kojima sam radio uvijek su imali zajedničke mrežne diskove. Alternativno, možete koristiti `sshfs` da biste ih sami montirali bez potrebe za root pristupom. Mrežno I / O opterećenje doista je faktor, ponekad bismo kopirali podatke na lokalni pogon i brisali ih nakon analize.
Više malih datoteka @terdon također je problem za većinu mrežnih datotečnih sustava. Slažem se da sinkronizacija gigabajta podataka nije uvijek dobra ideja, ali ponekad i neizbježno zlo (napomena, git annex to ne radi automatski; i to je u redu). Vidim da dosta bioinformatičkih skupina na mom sveučilištu ima vrlo slične probleme, pa barem to nije rijetkost. `sshfs` je opcija, ali opet je mrežni datotečni sustav. I na mnogim klasterima osigurač nije dostupan u jezgri (uključujući naš, koji je jedan od najvećih klastera samo s bioinformatikom kojega znam).
Moram se složiti s @terdon,, nema razloga da sinkronizirate brojne velike datoteke na više čvorova. Ako nemate root pristup za postavljanje umreženog diska za pohranu, trebate ga nabaviti. Sva će ta sinkronizacija datoteka začepiti mrežu, a vaši bi administratori to trebali izbjeći. Čuvanje više kopija datoteka recept je za katastrofu, to biste trebali izbjegavati pod svaku cijenu.
@woemler čini mi se da nisam bio dovoljno jasan. Ne želim transparentnu sinkronizaciju koncerata podataka. Samo želim da ovo bude verzija i dostupno. Ažurirao sam pitanje kako bi bilo jasnije. Također, čuvanje 100k sitnih datoteka na mreži fs je i recept za katastrofu. U svakom slučaju, problem s velikim datotekama lako je riješiti pomoću git annexa; male datoteke je složenije.
Sedam odgovori:
#1
+14
Michael Schubert
2017-05-18 21:57:58 UTC
view on stackexchange narkive permalink

Ovdje treba razmotriti nekoliko točaka, koje sam izložio u nastavku. Cilj bi ovdje trebao biti pronaći tijek rada koji je minimalno nametljiv povrh toga što već koristi git.

Za sada ne postoji idealan tijek rada koji pokriva sve slučajeve upotrebe, ali ono što sam u nastavku naveo je najbliže čemu sam mogao doći.

Ponovljivost nije samo čuvanje svih vaših podataka

Dobili ste neobrađene podatke s kojima započinjete svoj projekt.

Svi ostali podaci u vašem direktoriju projekta nikada ne bi trebali biti samo "tamo", već moraju imati određeni zapis o tome odakle dolaze. Skripte za obradu podataka izvrsne su za to, jer već dokumentiraju kako ste prešli sa sirovih na vaše analitičke podatke, a zatim i datoteke potrebne za vaše analize.

A te skripte mogu biti verzioniran, s odgovarajućom jedinstvenom ulaznom točkom obrade (npr. Makefile koja opisuje kako se pokreću vaše skripte).

Na ovaj je način definirano stanje svih vaših projektnih datoteka sirovim podacima i verzijom vaših skripti za obradu (i inačicama vanjskog softvera, ali to je sasvim druga vrsta problema).

Koji podaci / kod trebaju i ne smiju biti verzionirani

Baš kao što ne biste radili verzije generirane datoteke koda, ne biste trebali željeti i verzije 10k posredničkih podatkovnih datoteka koje ste stvorili tijekom izvođenja analiza. Podaci koje treba verzionirati su vaši sirovi podaci (na početku vašeg cjevovoda), a ne automatski generirane datoteke.

Možda biste željeli uzeti snimke direktorija vašeg projekta, ali ne čuvajte svaku verziju svake datoteke koja je ikad proizvedena. Ovo već smanjuje vaš problem poštenom marginom.

Pristup 1: Stvarna verzija podataka

Za vaše sirove ili analitičke podatke , Git LFS (i alternativno Git Annex, koji ste već spomenuli) osmišljen je da riješi upravo ovo problem: dodajte podatke o praćenju datoteka u vaše Git stablo, ali nemojte spremati sadržaj tih datoteka u spremište (jer bi u protivnom to dodalo veličinu datoteke koja se ne može mijenjati sa svakom promjenom koju napravite).

Za svoje srednje datoteke radite isto što biste učinili i s datotekama srednjeg koda: dodajte ih u svoj .gitignore i nemojte ih verzirati.

Ovo zahtijeva nekoliko razmatranja:

  • Git LFS je usluga koja se plaća od Githuba (besplatna razina ograničena je na 1 GB prostora za pohranu / propusnost mjesečno, što je vrlo malo), a skuplje je od ostalih usporedivih rješenja za pohranu u oblaku. Možete razmisliti o plaćanju prostora za pohranu na Githubu ili pokretanju vlastitog LFS poslužitelja (postoji referentna implementacija, ali pretpostavljam da bi to ipak bio značajan napor)
  • Git Annex je besplatan, ali datoteke zamjenjuje povezuje i time mijenja vremenske žigove, što je problem za npr GNU Izrada tijekova posla (glavni nedostatak za mene). Također, dohvaćanje datoteka mora se izvršiti ručno ili putem kuke za urezivanje

Pristup 2: Izrada verzije samo koda, sinkronizacija podataka

Ako vaši analitički podaci ostanu isti za većina vaših analiza, tako da stvarna potreba za verzijom (za razliku od sigurnosne kopije i dokumentiranja porijekla podataka, što je neophodno) može biti ograničena.

Ključ da se ovo postigne je staviti sve datoteke podataka u vašem .gitignore i zanemarite sve svoje datoteke koda u rsync , sa skriptom u korijenu vašeg projekta ( proširenja i direktoriji su samo primjer):

  #! / bin / bashcd $ (dirname $ 0) rsync -auvr \ --exclude "* .r" \ --include "* .RData "\ --exclude" dir s ogromnim datotekama koje vam nisu potrebne lokalno "\ yourhost: / your / project / path / *.  

Prednost je u tome što ne trebate pamtiti naredbu rsync koju izvodite. Sama skripta prelazi u kontrolu verzija.

To je posebno korisno ako svoju tešku obradu radite na računalnom klasteru, ali želite napraviti crteže iz datoteka rezultata na vašem lokalnom stroju. Tvrdim da vam općenito nije potrebna dvosmjerna sinkronizacija.

Usput možete koristiti hash datoteke umjesto vremenske oznake barem u biomakeu (doi: 10.1093 / bioinformatics / btx306).
@IakovDavydov Svjestan sam toga, ali zapravo nisam pokušao funkcionira li
+1 za sve izmjene neobrađenih podataka treba dokumentirati +1 za hash datoteke. I sam sam veliki ljubitelj pismenog programiranja i također sam iskoristio taj pristup kako bih dokumentirao verziju svojih alata / paketa koje sam koristio za analizu i raspršivanje sirovih podataka. Stoga, kad vidim rezultat ili zaplet, imam i svoj proizvodni kontekst.
#2
+9
Sam Nicholls
2017-05-18 14:51:52 UTC
view on stackexchange narkive permalink

Vaše je pitanje donekle otvoreno, ali mislim da bi moglo pokazati zanimljivu raspravu. Ne vjerujem da u mnogim slučajevima vrijedi pohranjivati ​​podatke koje ste stvorili u git . Kao što ste primijetili, nije dizajniran za velike datoteke (iako imamo git-lfs ) i definitivno nije dizajniran za binarne formate kao što je BAM .

Mišljenja sam da je ključno kako je stvorena datoteka i što je učinjeno s njom. Velike datoteke za čije je stvaranje potrebno puno truda trebale bi se negdje zrcaliti (ali ne nužno u sustavu za kontrolu verzija). Druge manje važne (ili ih je manje teško stvoriti) datoteke koje su izgubljene, izopačene ili na neki drugi način zaprljane mogu se obnoviti sve dok znate kako su nastale.

Koliko vrijedi, radio na dijelu softvera nazvanom hitin (koji se sam opisuje kao ljuska za neorganizirane bioinformatičare). Također sam napisao poduži blog na blogu o tome zašto sam smatrao da mi je ovo potreban projekt, ali glavni je razlog bio taj što sam, s vremenom, usprkos mojim pokušajima da organiziram svoj datotečni sustav i napravim dobre arhive svojih eksperimenata zaboravite što su značila moja skraćena imena direktorija ili točno koji je program generirao koje podatke.

chitin cilj je automatski zabilježiti promjene napravljene u datotečnom sustavu tijekom izvršavanja naredbe . Zna koje naredbe treba pokrenuti za ponovno stvaranje određene datoteke, koje su naredbe koristile tu datoteku i može vam reći kada je i zašto ta datoteka promijenjena (i tko je također;).

Nije gotova (nikad ništa nije), ali smatram da ste možda krenuli krivim putem želeći pohraniti sve svoje podatke i njihove verzije kad stvarno, mislim da većina ljudi samo želi znati naredbe koje su potaknule promjene. Ako je povijest podataka važna (a vaš kod ima dobru verziju), tada možete jednostavno provjeriti bilo koji predavanje i izvršiti svoju analizu kako biste ponovno generirali podatke.

Žao mi je, ali glasam protiv ovoga. Zanimljiva točka rasprave, ali ne i odgovor na pitanje OP-a.
#3
+6
Daniel Standage
2017-05-21 12:27:58 UTC
view on stackexchange narkive permalink

Prije svega, svaka vam čast što ste inačicu shvatili ozbiljno. Činjenica da ste svjesni ovog problema dobar je znak da želite provesti odgovorno istraživanje!

Za mnoge bioinformatičke projekte podatkovne datoteke su toliko velike da je izrada podataka izravno s alatom kao što je git nepraktičan. Ali vaše se pitanje zapravo odnosi na nekoliko različitih pitanja.

  • Kako mogu reproducirati svoje istraživanje i pokazati punu podrijetlo za svaku podatkovnu točku i rezultat koji proizvedem?
  • Kako mogu upravljati i sinkronizirati svoj istraživački rad na više strojeva?

Kratki odgovor :

  • Arhivirajte primarne podatke.
  • Stavite svoj tijek rada pod kontrolu verzija.
  • Kontrolne sume verzija velikih podatkovnih datoteka.
  • Upotrijebite GitHub za sinkronizaciju tijeka rada između strojeva.

Dugi odgovor :

Arhivirajte primarne podatke

Što se tiče ponovljivosti, najvažniji su primarni podaci: sirovi, neprerađeni podaci koje prikupljate s instrumenta. Ako analizirate podatke koje su drugi objavili, napišite skriptu koja će automatizirati zadatak preuzimanja podataka iz primarnog službenog izvora i stavite tu skriptu pod kontrolu verzije.

Ako vi ili laboratorijski kolega ili kolega proizveli su podatke, a oni još nisu objavljeni, tada biste već trebali imati planove za predaju u arhivu. Doista, većina časopisa i agencija za financiranje sada to zahtijevaju prije objavljivanja. Čak bih išao toliko daleko da bih rekao da podatke treba dostaviti čim se prikupe. Znanstvenici se puno brinu zbog krađe podataka i iskorištavanja ideja, ali statistički gledano, dobivanje dohvata mnogo je manje vjerojatno nego da ikad netko dodiruje vaše podatke ili čita vaš rad. Ali ako vi ili savjetnik inzistirate, većina arhiva podataka omogućuje vam da podatke držite privatnima dulje vrijeme dok se ne objavi prateći rukopis.

Stavljanje (na primjer) Fastq datoteka u git spremište loša je ideja iz puno razloga. Nijedna usluga hostinga neće podržavati tako velike datoteke, git će biti vrlo spor s datotekama koje su velike, ali što je najvažnije git / GitHub nije arhiviran! Upotrijebite odgovarajuću arhivu podataka!

Stavite svoj tijek rada pod kontrolu verzija

Tretirajte svoje sirove podatke samo za čitanje. Neobrađene podatke obrađujte samo pomoću skripti i držite ove skripte pod kontrolom verzija. Vince Buffalo to dobro opisuje u svojoj knjizi Bioinformatics Data Skills. Pogledajte!

Kontrolne sume verzija velikih podatkovnih datoteka

Ako postoje neke podatkovne datoteke koje želite pratiti, ali su prevelike da bi se mogle staviti pod kontrolu verzija, izračunajte kontrolne sume i stavite ove pod kontrolom verzija. Kontrolne su su vrlo male alfanumeričke žice koje su, u sve praktične svrhe, jedinstvene za svaku datoteku podataka. Dakle, umjesto da stavite onu skraćenu Fastq datoteku od 5 GB ili BAM datoteku od 7 GB pod kontrolu verzija, izračunajte njihove kontrolne sume i stavite kontrolne sume pod kontrolu verzije. Kontrolne sume neće vam reći sadržaj datoteka, ali mogu vam reći kada se sadržaj datoteke promijeni.

To bi trebalo pružiti potpuno otkrivanje i potpunu podrijetlo za svaku podatkovnu točku u vašoj analizi. Tok posla ima skripte / naredbe za preuzimanje primarnih podataka, skripte / naredbe za obradu podataka i kontrolne sume koje služe kao potpis za provjeru međufaznih i konačnih izlaznih datoteka. Ovim bi svatko mogao reproducirati vašu analizu!

Upotrijebite GitHub za sinkronizaciju vašeg tijeka rada između strojeva

Ako je vaš tijek rada već pod kontrolom verzija s gitom, trivijalno je gurnuti ovo na uslugu hostinga poput GitHub, GitLab ili BitBucket. Tada je stvar samo u korištenju git push i git pull da biste održavali svoj kôd ažurnim na raznim računalima.

#4
+5
H. Gourlé
2017-05-18 17:46:13 UTC
view on stackexchange narkive permalink

Open Science Framework koristi izradu verzija za sve datoteke i besplatan je za upotrebu: https://osf.io

Možete integrirati podatke ili kôd iz različitih izvora, poput github, dropbox, google drive, figshare ili amazon cloud

Datoteke možete pohraniti i na njihov poslužitelj pomoću OSF pohrane podataka, ali ne znam točno koje je ograničenje veličine datoteke.

#5
+4
Ian Sudbery
2017-05-19 14:33:59 UTC
view on stackexchange narkive permalink

Način na koji se nosimo s ovim je:

  • Sav posao obavlja se u jednom datotečnom sustavu montiranom na klasteru
  • Ovaj datotečni sustav montiran je na lokalne strojeve putem sshfs-a / samba (ovisno o mjestu trenutnog "lokalnog" stroja na mreži).
  • Kôd je izveden s git hub-om
  • Sva izračunavanja provode se laganim automatiziranim cjevovodima . Koristimo ruffus u kombinaciji s unutarnjim korisnim slojem. Sustav zapravo nije važan sve dok više nije potrebno dodati još jedan korak cjevovodu nego što bi bilo ručno izvršiti.
  • Sve sumnjive odluke o dizajnu kodirane su u konfiguracijskim datotekama. Te konfiguracijske datoteke, zajedno s vrlo detaljnim izlazom dnevnika putem cjevovoda (što je pokrenuto, što je git predavanje koda, koliki je vremenski žig datoteka na kojima je pokrenut, itd.) I početne ulazne datoteke su verzija kontrolirana.
  • Prednost je toga što je kod + konfiguracija + vrijeme = izlaz. Ne očekuje se da će se čitav cjevovod ponoviti svaki put kad se bilo što promijeni, ali cjevovod će vam reći je li nešto zastarjelo (može koristiti vremenske oznake ili hashove datoteka) i sve se može pokrenuti u jednom potezu prije objavljivanja.
  • Bilo koja druga analiza provodi se u prijenosnim bilježnicama. Njima se upravlja verzijom.

Da rezimiramo, ne sinkroniziramo se jer uvijek radimo samo s jednog diska, čak i ako koristimo više CPU lokacija. Mi kontroliramo verzije:

  • Kôd
  • Ulazi, konfiguracija, zapisnici
  • Juptyer bilježnice

Dnevnik bilježi git obveze koje se koriste za stvaranje trenutnih rezultata.

Zanimljivo Ian, ovo je vrsta dizajna kojem težim, ali zapravo ne slijedim praksu. Zaintrigirao me ovaj unutarnji sloj na vrhu ruffusa, što je to?
Trik je olakšati pisanje zadatka cjevovoda od skripte za predaju posla klastera. Komunalni sloj pruža CGATPipelines (www.github.com/CGATOxford/CGATPipelines)
#6
+3
woemler
2017-05-18 18:44:31 UTC
view on stackexchange narkive permalink

Korištenje Gita za kod za upravljanje verzijama dobra je praksa, ali nije dobro za izradu verzija velikih podatkovnih datoteka. Ručna sinkronizacija podataka na više čvorova traži probleme, želite da se tom sinkronizacijom automatski upravlja u upravljanom okruženju ili samo datoteke držite na jednom mrežnom uređaju za pohranu.

Jedan alat koji biste mogli koji želite pogledati je Arvados, koji je dizajniran za sinkronizaciju podataka o bioinformatici i tijekova rada na više strojeva. Sa web stranice projekta:

Arvados je platforma za spremanje, organiziranje, obradu i dijeljenje genomskih i drugih velikih podataka. Platforma je osmišljena kako bi znanstvenicima podataka olakšala razvoj analiza, programerima izradu genomskih web aplikacija i IT administratorima za upravljanje velikim računalnim i skladišnim genomskim izvorima. Platforma je dizajnirana za rad u oblaku ili na vašem vlastitom hardveru.

Arvados bih koristio samo ako bi stvarno postao puno bolji nego prije.
@nuin: Što konkretno mislite da je nedostajalo i / ili što bi učinilo neprikladnim kao rješenje problema OP-a?
@woemier Nisam to pokušao u posljednje vrijeme, i ako se dobro sjećam, to je bila PITA za postavljanje i pokretanje jednostavnih stvari. Ali kao što sam rekao, ne znam je li postalo bolje.
#7
+3
weiji14
2018-03-27 08:17:13 UTC
view on stackexchange narkive permalink

Ovaj će odgovor nekako pokrivati ​​samo dijelove velikih podataka, tj. stvari> 100 MB, i samo ako je vaš cjevovod za analizu povezan s ekosustavom Python. Trebat će malo učenja

Pokušajte upotrijebiti poplun koji je otprilike poput 'dockera za podatke' ( Github stranica).

  $ pip install quilt $ quilt install uciml / iris -x da2b6f5 #naznačite kratki heš $ python>>> iz quilt.data.uciml import iris # imate podatke  

Pros:

  • Čini se da ne postoji ograničenje veličine datoteka za javne pakete (to ipak niste testirali stresom)
  • Hashira vaše podatke kako bi se osigurala ponovljivost li>
  • Podrška za inačice verzija i oznake

Protiv:

  • Pohranjivanje privatnih podataka počinje od 7 USD po korisniku mjesečno do 1 TB podataka
  • Prilično Python samo u ovom trenutku, s nekom podrškom zajednice za R

Više informacija ovdje.



Ova pitanja su automatski prevedena s engleskog jezika.Izvorni sadržaj dostupan je na stackexchange-u, što zahvaljujemo na cc by-sa 3.0 licenci pod kojom se distribuira.
Loading...