A szekvenált adatok tárolása nehéz feladat. Lehetne beszélni a növekvő költségekről, a környezeti terhelésről és használhatnánk egyéb marketing szagú kifejezéseket, de frappánsan megfogalmazva ez mind annyit jelent, hogy sosem elég a tárhely.
Az egyik megoldás, hogy a szekvenciákat tömörítjük. Rengeteg tömörítési eljárás van, ami nem veszi figyelembe a tömörítendő adat felépítését, de ha FASTQ fájlokról van szó, akkor érdemes kiaknázni a rögzített struktúra adta lehetőségeket.
A témával kapcsolatban sok cikk megjelent. Közös jellemzőjük, hogy fognak egy humán szekvenciát, betömörítik, és megmutatják, hogy az ő megoldásuk a legjobb. Röviden szólva, az egyszerű esetekre koncentrálnak. A humán referencia genom az egyik legjobb minőségű, a tesztekhez felhasznált szekvenciák közel tökéletesek (vagyis a minőségi mérőszámok is magasak). Nincs semmi kontamináció vagy bármi, amivel komolyan meg kellene birkózni.
Ezért ebben a tesztben Arabidopsis mikroRNS-eket fogok tömöríteni. Eredetileg egy olyan növényt akartam, amiből csak scaffoldok vannak, de sajnos a laptopomon futó virtuális Linux tárhelye limitált. Azért a mikroRNS-ek így is 100% adaptor szennyezettek, ami reményeim szerint alaposan megizzasztja az algoritmusokat.
A felhasznált szekvenciát innen töltöttem le. A referencia a TAIR 10 volt. Tömörítési időket nem mértem, mert azt nem érzem akkora problémának, mint a tárolást, ráadásul egy virtuális gépen mért időnek nem sok relevanciája van.
A nyers szekvencia 1597952192 bájt.
GZIP
gzip SRR2135656.fastq
A jó öreg gzip a szegény ember szekvencia tömörítője. Előnye, hogy azonnal tömöríthető, zcat-al azonnal kitömöríthető és csővezetéken küldhető a feldolgozandó programoknak. A legrosszabb tömörítési aránnyal bírt: 411159400 bájt lett az eredmény.
Brotli
bro --quality 11 --input SRR2135656.fastq --output SRR2135656.fastq.bro
A Google új tömörítője volt a leglassabb. Bár nem mértem, de kétszer is hibernáltam a gépet, mielőtt eredményt kaptam volna. Igaz, a legjobb tömörítési arányt választottam, de így is 317665851 bájt lett a végeredmény.
BZIP2
bzip2 -9 SRR2135656.fastq
A bzip2 sem mai darab, de még így is jobb eredményt produkált, mint a Brotli. A futási idő pedig messze jobb volt a Google szupersztárjánál. 306455232 bájtjával az általános célú telepítők között ez volt a legjobb. Még nem lesz nyugdíjazva egy ideig.
BAM
bwa mem ref/tair10.fasta SRR2135656.fastq | samtools view -b - >tmp.bam
és
samtools sort -o SRR2135656.bam -T tmp -O bam -l 9 tmp.bam
A BAM elsődleges célja nem a szekvencia tömörítés, de a végeredmény viszonylag jó és több információt tartalmaz. Itt a Sangerben is ez volt az elsődleges tárolási formátum. Az illesztőprogram által kiadott BAM 346133963 bájtot, míg koordináták szerint rendezve 341639813 bájt helyet foglalt a merevlemezen.
CRAM
samtools sort -o SRR2135656.cram -T conv.tmp -O cram -l 9 --reference ref/tair10.fasta tmp.bam
A CRAM a BAM-ot hivatott leváltani. Még nem tekinthető teljes értékűnek, noha egyre több eszköz támogatja. A specifikáció is változik, de szerencsére a samtools elég jól követi ezt. A Sangerben az újabban szekvenált eredmények már CRAM-ban is elérhetőek, de volt már olyan, hogy hexeditorral nyomoztam, miért nem tudom használni a fájlokat. Kalandoroknak kötelező, de még nem ipari szabvány. 264964747 bájt a V3 verzióval.
Referee
Ezen poszt megjelenése emiatt a program miatt csúszott. A cikk csupa jót zeng róla, de kétlem, hogy valódi referee látta volna. A letölthető kód alapból nem fordul le, a Makefile szerkesztése után sikerült valahogy lefordítanom, de rögtön segmentation fault-al elszállt. Nem nyomoztam tovább, mi lehetett a baj. A szerző nem sokat dolgozott a kódon az utóbbi időben. Nem tartom valószínűnek, hogy épkézláb program lesz belőle. Virtuális fekete pont jár neki és annak is, aki bírálta.
Leon
leon -c -file SRR2135656.fastq -lossless
vagy
leon -c -file SRR2135656.fastq -seq-only
A Leon igazi profi. A de-novo összeszerelők logikáját használja. Képes veszteség mentes tömörítésre, de ha tudjuk, hogy bizonyos elemekre nincs szükségünk (például az eredeti szekvencia azonosítókra), akkor tovább gyömöszöli a fájlokat. Veszteségmentes módban 84766251 bájt bináris és egy 193442831 bájtos fájl a minőségi mutatóknak. Ha viszont "vesszen a férgese" módban futtatjuk (nincs azonosító, nincs minőségi mutató), akkor 59751380 bájt a végeredmény.
