Vraag:
Hoe de code en de gegevens tijdens de analyse te versieren?
Iakov Davydov
2017-05-18 14:27:51 UTC
view on stackexchange narkive permalink

Ik ben momenteel op zoek naar een systeem waarmee ik zowel de code als de gegevens in mijn onderzoek kan versieren.

Ik denk dat mijn manier om gegevens te analyseren niet ongebruikelijk is, en dit zal nuttig zijn voor veel mensen die bio-informatica doen en streven naar reproduceerbaarheid.

Hier zijn de vereisten:

  • Analyse wordt uitgevoerd op meerdere machines (lokaal, cluster, server).
  • Alle code wordt transparant gesynchroniseerd tussen de machines.
  • Broncodeversie.
  • Gegenereerde gegevensversies.
  • Ondersteuning voor een groot aantal kleine gegenereerde bestanden (> 10k). Deze kunnen ook worden verwijderd.
  • Ondersteuning voor grote bestanden (> 1 Gb). Op een gegeven moment kunnen oude gegenereerde bestanden definitief worden verwijderd. Het zou krankzinnig zijn om transparante synchronisatie hiervan te hebben, maar het zou fijn zijn om ze op aanvraag te kunnen synchroniseren.

Tot nu toe gebruik ik git + rsync / scp. Maar er zijn verschillende nadelen aan verbonden.

  • Synchronisatie tussen meerdere machines is een beetje vervelend, d.w.z. je moet git pull voordat je begint te werken en git push na elke update. Daar kan ik mee leven.
  • Het is niet de bedoeling dat je grote gegenereerde databestanden of een groot aantal bestanden in je repository opslaat.
  • Daarom moet ik databestanden handmatig synchroniseren met rsync, wat foutgevoelig is.

Er is iets genaamd git annex. Het lijkt heel dicht bij wat ik nodig heb. Maar:

  • Iets meer werk dan git, maar dat is oké.
  • Helaas lijkt het niet goed te werken met het grote aantal bestanden. Vaak heb ik meer dan 10.000 kleine bestanden in mijn analyse. Er zijn enkele trucs om het indexeren te verbeteren, maar dit lost het probleem niet op. Wat ik nodig heb is een symlink die de volledige inhoud van de directory weergeeft.

Een mogelijke oplossing is om Dropbox of iets dergelijks (zoals synchroniseren) te gebruiken in combinatie met git. Maar het nadeel is dat er geen verband zal zijn tussen de broncodeversie en de gegevensversie.

Is er een versiebeheersysteem voor de code en de gegevens die voldoen aan de vereisten die u kunt aanbevelen?

Het is niet precies wat je zoekt, en het is ook niet in een positie waarin ik het fulltime zou gebruiken, maar ik heb een stukje software geschreven genaamd `chitin`: https://github.com/SamStudio8/chitin /. Het is ontworpen om bij te houden hoe bestanden zijn gemaakt en wat ermee is gebeurd. Het is niet ontworpen om de wijzigingen op te slaan (zoals git) - maar eigenlijk vind ik de metadata veel nuttiger dan de daadwerkelijke wijzigingen (afgezien van code, die natuurlijk in git leeft).
@SamStudio8 ziet er interessant uit. Ik ben nog niet helemaal overtuigd, maar IMHO is het waard om als antwoord te posten.
De normale benadering hiervoor is om een ​​enkele directory te hebben die wordt geëxporteerd naar de verschillende machines (lokaal, cluster, server). Waarom zou u de gegevens op deze manier dupliceren in plaats van alleen een gecentraliseerde opslagplaats te gebruiken?
@terdon heb je vaak geen root-toegang op een cluster, daarom kun je daar niet zomaar een netwerkbestandssysteem aankoppelen (en als er veel kleine bestanden of grote bestanden zijn wil je dat niet vanwege de prestaties). In andere opzichten is dit vergelijkbaar met een synchronisatie- / dropbox-oplossing, waarbij de juiste versiebeheer en correspondentie tussen de broncode en de gegevens ontbreekt.
Als u GB aan gegevens moet synchroniseren, doet u het verkeerd. Als je root-toegang nodig hebt, zou ik je sysadmin willen vragen om het systeem zo in te stellen dat je gedeelde schijven hebt. Ik heb nog nooit iemand zien werken zoals je beschrijft, alle drie de plaatsen waar ik heb gewerkt, hadden altijd gedeelde netwerkschijven. Als alternatief zou je `sshfs` kunnen gebruiken om ze zelf te mounten zonder root-toegang nodig te hebben. De netwerk-I / O-belasting is inderdaad een factor, we kopieerden soms gegevens naar een lokale schijf en verwijderden deze na de analyse.
@terdon meerdere kleine bestanden is ook een probleem voor de meeste netwerkbestandssystemen. Ik ben het ermee eens dat het synchroniseren van gigabytes aan gegevens niet altijd een goed idee is, maar soms een onvermijdelijk kwaad (let op, git annex doet het niet automatisch; en dat is prima). Ik zie heel veel bioinformatica-groepen op mijn universiteit met vergelijkbare problemen, dus het is in ieder geval niet ongewoon. `sshfs` is een optie, maar het is weer een netwerkbestandssysteem. En op veel clusters is fuse niet beschikbaar in de kernel (inclusief onze, die een van de grootste bioinformatica-only clusters is waarvan ik op de hoogte ben).
Ik ben het eens met @terdon, dat er geen reden is dat je talloze grote bestanden over meerdere knooppunten zou moeten synchroniseren. Als je geen root-toegang hebt om een ​​netwerkopslagstation te koppelen, moet je het downloaden. Al die bestandssynchronisatie zal het netwerk verstoppen, en uw beheerders zouden dit moeten willen vermijden. Het bewaren van meerdere kopieën van bestanden is een recept voor een ramp, u moet dit koste wat het kost vermijden.
@woemler het lijkt erop dat ik niet duidelijk genoeg was. Ik wil geen transparante synchronisatie van gegevensoptredens. Ik wil alleen dat dit versiebeheer heeft en kan worden opgehaald. Ik heb de vraag bijgewerkt om het duidelijker te maken. 100k kleine bestanden op netwerk fs houden is ook een recept voor een ramp. Hoe dan ook, het probleem met grote bestanden is gemakkelijk op te lossen met git annex; kleine bestanden is ingewikkelder.
Zeven antwoorden:
#1
+14
Michael Schubert
2017-05-18 21:57:58 UTC
view on stackexchange narkive permalink

Er zijn een paar punten waarmee u rekening moet houden, die ik hieronder uiteenzet. Het doel hier zou moeten zijn om een ​​workflow te vinden die minimaal opdringerig is, naast het al gebruiken van git.

Tot nu toe is er geen ideale workflow die alle gebruiksscenario's dekt, maar wat ik hieronder schets, komt het dichtst in de buurt.

Reproduceerbaarheid is niet alleen het bewaren van al je gegevens

Je hebt je onbewerkte gegevens waarmee je je project start.

Alle andere gegevens in je projectdirectory zouden nooit zomaar "daar moeten zijn", maar moeten een record hebben van waar ze vandaan komen. Gegevensverwerkingsscripts zijn hier geweldig voor, omdat ze al documenteren hoe je van je ruwe naar je analytische gegevens ging, en vervolgens de bestanden die nodig zijn voor je analyses.

En die scripts kunnen worden voorzien van versiebeheer, met een geschikt enkel ingangspunt voor verwerking (bijv. een Makefile die beschrijft hoe u uw scripts moet uitvoeren).

Op deze manier wordt de staat van al uw projectbestanden gedefinieerd door de onbewerkte gegevens en de versie van uw verwerkingsscripts (en versies van externe software, maar dat is een heel ander soort probleem).

Welke gegevens / code moet wel en niet worden versiebeheer

Net zoals u geen versie-gegenereerde codebestanden zou hebben, zou u geen versie 10k intermediaire gegevensbestanden moeten hebben die u bij het uitvoeren van uw analyses heeft aangemaakt. De gegevens die moeten worden geversioneerd zijn uw onbewerkte gegevens (aan het begin van uw pijplijn), niet automatisch gegenereerde bestanden.

Misschien wilt u snapshots van uw projectdirectory, maar bewaar niet elke versie van elk bestand dat ooit is gemaakt. Dit vermindert uw probleem al met een redelijke marge.

Aanpak 1: feitelijk versiebeheer van gegevens

Voor uw onbewerkte of analytische gegevens is Git LFS (en als alternatief Git Annex, die u al noemt) ontworpen om precies dit op te lossen probleem: voeg trackinginformatie toe van bestanden in je Git-tree, maar sla de inhoud van die bestanden niet op in de repository (omdat het anders de grootte van een niet-diffeerbaar bestand zou toevoegen bij elke wijziging die je aanbrengt).

Voor uw tussenliggende bestanden doet u hetzelfde als u zou doen met tussenliggende codebestanden: voeg ze toe aan uw .gitignore en geef geen versie aan.

Dit roept een aantal overwegingen op:

  • Git LFS is een betaalde service van Github (de gratis laag is beperkt tot 1 GB opslag / bandbreedte per maand, wat erg weinig is), en het is duurder dan andere vergelijkbare cloudopslagoplossingen. Je zou kunnen overwegen om te betalen voor de opslag bij Github of om je eigen LFS-server te draaien (er is een referentie-implementatie, maar ik neem aan dat dit nog steeds een aanzienlijke inspanning zou zijn)
  • Git Annex is gratis, maar het vervangt bestanden door koppelingen en daarmee tijdstempels veranderen, wat een probleem is voor bv Op GNU Make gebaseerde workflows (groot nadeel voor mij). Het ophalen van bestanden moet ook handmatig worden gedaan of via een vastleghaak.

Benadering 2: alleen versiecode, gegevens synchroniseren

Als uw analytische gegevens hetzelfde blijven voor de meeste van uw analyses, dus de feitelijke noodzaak om er een versie van te maken (in tegenstelling tot het maken van back-ups en het documenteren van de herkomst van gegevens, wat essentieel is), kan beperkt zijn.

De sleutel om dit te laten werken, is door alle databestanden in uw .gitignore en negeer al uw codebestanden in rsync , met een script in uw projectroot ( extensies en mappen zijn slechts een voorbeeld):

  #! / bin / bashcd $ (dirname $ 0) rsync -auvr \ --exclude "* .r" \ --include "* .RData "\ --exclude" map met grote bestanden die je lokaal niet nodig hebt "\ yourhost: / jouw / project / pad / *.  

Het voordeel hiervan is dat u het rsync -commando dat u gebruikt niet hoeft te onthouden. Het script zelf gaat naar versiebeheer.

Dit is vooral handig als u uw zware bewerkingen uitvoert op een computercluster, maar plots wilt maken van uw resultaatbestanden op uw lokale computer. Ik beweer dat je over het algemeen geen bidirectionele synchronisatie nodig hebt.

Trouwens, je kunt file hash gebruiken in plaats van timestamp, tenminste in biomake (doi: 10.1093 / bioinformatics / btx306).
@IakovDavydov Ik ben me hiervan bewust, maar ik heb niet echt geprobeerd of het werkt
+1 voor alle wijzigingen aan de onbewerkte gegevens moet worden gedocumenteerd +1 voor de bestandshash. Ik ben zelf een grote fan van geletterd programmeren en ik heb ook van die benadering gebruik gemaakt om de versie van mijn tools / pakketten die ik heb gebruikt voor de analyse en de hash van de onbewerkte gegevens te documenteren. Dus als ik een resultaat of een plot zie, heb ik ook de context van de productie.
#2
+9
Sam Nicholls
2017-05-18 14:51:52 UTC
view on stackexchange narkive permalink

Uw vraag is enigszins open, maar ik denk dat het een interessante discussie kan zijn. Ik geloof niet dat het in veel gevallen de moeite waard is om de gegevens die je hebt gemaakt op te slaan in git . Zoals je hebt opgemerkt, is het niet ontworpen voor grote bestanden (hoewel we git-lfs hebben) en het is zeker niet ontworpen voor binaire formaten zoals BAM .

Ik ben van mening dat hoe een bestand is gemaakt en wat ermee is gedaan sinds is de sleutel. Grote bestanden die veel moeite kosten om te maken, moeten ergens worden gespiegeld (maar niet noodzakelijk in een versiebeheersysteem). Andere, minder belangrijke (of minder moeilijk te maken) bestanden die verloren zijn gegaan, kapot zijn gegaan of anderszins zijn aangetast, kunnen opnieuw worden gegenereerd zolang u weet hoe ze zijn ontstaan.

Voor wat het waard is, heb ik gewerkt aan een stuk software genaamd chitine (zelf beschreven als een schil voor ongeorganiseerde bio-informatici). Ik schreef ook een lange blogpost over waarom ik dacht dat dit een noodzakelijk project voor mij was, maar de belangrijkste reden was dat ondanks mijn pogingen om mijn bestandssysteem te organiseren en goede archieven van mijn experimenten te maken, ik na verloop van tijd vergeet wat mijn steno directory-namen betekenden, of precies welk programma welke gegevens genereerde.

chitin 's doel is om automatisch wijzigingen vast te leggen die in het bestandssysteem zijn aangebracht tijdens het uitvoeren van een commando . Het weet welke commando's moeten worden uitgevoerd om een ​​bepaald bestand opnieuw te maken, welke commando's dat bestand hebben gebruikt en kan u vertellen wanneer en waarom dat bestand is gewijzigd (en ook door wie;)).

Het is niet af (niets ooit), maar ik heb het gevoel dat je misschien de verkeerde weg inslaat door al je gegevens en de versies ervan te willen opslaan, terwijl ik denk dat de meeste mensen gewoon de commando's willen weten die veranderingen hebben veroorzaakt. Als de datageschiedenis belangrijk is (en je code een goede versie heeft), dan kun je elke commit bekijken en je analyse uitvoeren om data opnieuw te genereren.

Het spijt me, maar ik stem dit af. Interessant discussiepunt, maar geen antwoord op de vraag van het OP.
#3
+6
Daniel Standage
2017-05-21 12:27:58 UTC
view on stackexchange narkive permalink

Allereerst een pluim voor u dat u versiebeheer serieus neemt. Het feit dat je je bewust bent van dit probleem is een goed teken dat je verantwoord onderzoek wilt doen!

Voor veel bioinformatica-projecten zijn databestanden zo groot dat versiebeheer van de data direct met een tool als git onpraktisch. Maar je vraag gaat eigenlijk over een aantal verschillende kwesties.

  • Hoe voer ik mijn onderzoek reproduceerbaar uit en laat ik de volledige herkomst zien voor elk datapunt en resultaat dat ik produceer?
  • Hoe beheer en synchroniseer ik mijn onderzoekswerk over meerdere machines?

Het korte antwoord :

  • Archiveer de primaire gegevens.
  • Plaats uw workflow onder versiebeheer.
  • Versiecontrolesommen van grote gegevensbestanden.
  • Gebruik GitHub om uw workflow tussen machines te synchroniseren.

Het lange antwoord :

Archiveer de primaire gegevens

Wat reproduceerbaarheid betreft, gaat het vooral om de primaire data: de onbewerkte, onbewerkte data die je uit het instrument verzamelt. Als u gegevens analyseert die door anderen zijn gepubliceerd, schrijf dan een script dat de taak van het downloaden van de gegevens van de primaire officiële bron automatiseert, en plaats dat script onder versiebeheer.

Als u of een labmate of een collega heeft de gegevens geproduceerd en is nog niet gepubliceerd, dan zou je al plannen moeten hebben om ze in een archief te plaatsen. Inderdaad, de meeste tijdschriften en financieringsinstanties eisen dit nu voorafgaand aan publicatie. Ik zou zelfs zo ver gaan om te zeggen dat de gegevens moeten worden ingediend zodra ze zijn verzameld. Wetenschappers maken zich veel zorgen over het feit dat hun gegevens worden gestolen en dat hun ideeën worden overgehaald, maar statistisch gezien is het veel minder waarschijnlijk dat iemand uw gegevens aanraakt of uw paper leest. Maar als u of een adviseur erop staat, kunt u met de meeste gegevensarchieven gegevens gedurende een langere periode privé houden totdat een ondersteunend manuscript is gepubliceerd.

Het plaatsen van (bijvoorbeeld) Fastq-bestanden in een git-repository is om veel redenen een slecht idee. Geen enkele hostingservice ondersteunt bestanden die zo groot zijn, git zal erg traag zijn met bestanden die zo groot zijn, maar het belangrijkste is dat git / GitHub niet archiveert! Gebruik een goed gegevensarchief!

Plaats uw workflow onder versiebeheer

Behandel uw onbewerkte gegevens als alleen-lezen. Verwerk de onbewerkte gegevens alleen met behulp van scripts en houd deze scripts onder versiebeheer. Vince Buffalo beschrijft dit goed in zijn boek Bioinformatics Data Skills. Bekijk het eens!

Versiecontrolesommen van grote gegevensbestanden

Als er gegevensbestanden zijn die u wilt volgen, maar die te groot zijn om onder versiebeheer te plaatsen, bereken dan controlesommen en plaats deze onder versiebeheer. Checksums zijn zeer kleine alfanumerieke tekenreeksen die voor alle praktische doeleinden uniek zijn voor elk gegevensbestand. Dus in plaats van dat 5GB bijgesneden Fastq-bestand of het 7GB BAM-bestand onder versiebeheer te zetten, berekent u hun checksums en zet u de checksums onder versiebeheer. De checksums zullen u niet de inhoud van uw bestanden vertellen, maar ze kunnen u wel vertellen wanneer de inhoud van het bestand verandert.

Dit zou volledige openheid en volledige herkomst moeten geven voor elk gegevenspunt in uw analyse. De workflow heeft een scripts / commando voor het downloaden van de primaire data, scripts / commando's voor het verwerken van de data, en checksums die dienen als een handtekening om tussenliggende en uiteindelijke outputbestanden te valideren. Hiermee zou iedereen je analyse moeten kunnen reproduceren!

Gebruik GitHub om je workflow tussen machines te synchroniseren

Als je workflow al onder versiebeheer staat met git, is het triviaal om dit te pushen naar een hostingservice zoals GitHub, GitLab of BitBucket. Dan is het gewoon een kwestie van git push en git pull gebruiken om je code up-to-date te houden op je verschillende machines.

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

Het Open Science Framework gebruikt versiebeheer voor alle bestanden en is gratis te gebruiken: https://osf.io

U kunt gegevens of code uit verschillende bronnen integreren, zoals github, dropbox, google drive, figshare of amazon cloud

Je kunt ook bestanden op hun server opslaan met behulp van OSF-gegevensopslag, maar ik weet niet precies wat de maximale bestandsgrootte is.

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

De manier waarop we hiermee omgaan is:

  • Al het werk wordt gedaan in een enkel bestandssysteem dat op het cluster is aangekoppeld
  • Dit bestandssysteem wordt via sshfs op lokale machines gemount / samba (afhankelijk van de locatie van de huidige "lokale" machine op het netwerk).
  • Code is voorzien van een versie met git hub
  • Alle berekeningen worden uitgevoerd via lichtgewicht geautomatiseerde pijplijnen . We gebruiken ruffus in combinatie met een in-house utiliteitslaag. Het systeem doet er eigenlijk niet toe, zolang het maar geen werk meer is om nog een stap aan de pijplijn toe te voegen dan om het handmatig uit te voeren.
  • Alle twijfelachtige ontwerpbeslissingen worden gecodeerd in configuratiebestanden. Deze configuratiebestanden, samen met een zeer gedetailleerde loguitvoer door de pijplijn (wat werd er uitgevoerd, wat was de git commit van de code-run, wat was het tijdstempel van de bestanden waarop het werd uitgevoerd, enz.) En de initiële invoerbestanden zijn versie gecontroleerd.
  • Het voordeel hiervan is dat code + configuratie + tijd = uitvoer. Het is niet te verwachten dat de hele pijplijn telkens opnieuw wordt uitgevoerd als er iets wordt gewijzigd, maar de pijplijn zal u vertellen of iets verouderd is (het kan tijdstempels of bestandshashes gebruiken), en het kan allemaal in één keer worden uitgevoerd voordat er wordt gepubliceerd.
  • Elke andere analyse wordt uitgevoerd in jupty notitieboekjes. Deze zijn versiegestuurd.

Samenvattend synchroniseren we niet omdat we alleen vanaf één schijflocatie werken, zelfs als we meerdere CPU-locaties gebruiken. We versiebeheer:

  • Code
  • Invoer, configuratie, logboeken
  • Juptyer notebooks

Log registreert de git commits die worden gebruikt om de huidige uitvoer te produceren.

Interessant Ian, dit is het soort ontwerp waar ik naar streef, maar dat ik niet echt in de praktijk volg. Ik ben geïntrigeerd door deze in-house laag bovenop ruffus, wat is het?
De truc is om het schrijven van een pijplijntaak gemakkelijker te maken dan het indienen van een clustertaak. De gebruikslaag wordt geleverd door CGATPipelines (www.github.com/CGATOxford/CGATPipelines)
#6
+3
woemler
2017-05-18 18:44:31 UTC
view on stackexchange narkive permalink

Git gebruiken voor versiebeheercode is een goede gewoonte, maar het leent zich niet goed voor versiebeheer van grote databestanden. Het handmatig synchroniseren van gegevens over meerdere knooppunten vraagt ​​om problemen. U wilt dat deze synchronisatie ofwel automatisch wordt afgehandeld in een beheerde omgeving, of dat u de bestanden gewoon op één netwerkopslagapparaat bewaart.

Eén tool die u misschien kunt gebruiken willen onderzoeken is Arvados, dat is ontworpen voor het synchroniseren van bio-informatica-gegevens en workflows over meerdere machines. Van de projectwebsite:

Arvados is een platform voor het opslaan, organiseren, verwerken en delen van genomische en andere big data. Het platform is ontworpen om het voor datawetenschappers gemakkelijker te maken om analyses te ontwikkelen, ontwikkelaars om genomische webapplicaties te maken en IT-beheerders om grootschalige genomische reken- en opslagbronnen te beheren. Het platform is ontworpen om in de cloud of op uw eigen hardware te draaien.

Ik zou Arvados alleen gebruiken als het echt veel beter werd dan voorheen.
@nuin: Wat denkt u specifiek dat er ontbrak en / of zou het niet geschikt maken als oplossing voor het probleem van OP?
@woemier Ik heb het de laatste tijd niet geprobeerd, en als ik het me goed herinner, was het een PITA om eenvoudige dingen op te zetten en uit te voeren. Maar zoals ik al zei, weet niet of het beter is geworden.
#7
+3
weiji14
2018-03-27 08:17:13 UTC
view on stackexchange narkive permalink

Dit antwoord dekt min of meer alleen de big data-onderdelen, d.w.z. dingen> 100 MB, en alleen als je analysepijplijn aansluit op het Python-ecosysteem. Het vereist een beetje leren

Probeer quilt te gebruiken, een soort van 'docker for data' ( Github-pagina).

  $ pip install quilt $ quilt install uciml / iris -x da2b6f5 #note de korte hash $ python>>> van quilt.data.uciml import iris # je hebt gegevens  

Voordelen:

  • Er lijkt geen limiet voor bestandsgrootte te zijn voor openbare pakketten (heb dit echter niet aan een stresstest onderworpen)
  • Hasht uw gegevens om reproduceerbaarheid te garanderen
  • Ondersteuning voor versiebeheer en tags

Nadelen:

hier meer informatie.



Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...