過去数年間に生産されたゲノムデータの量は、主に高スループットシーケンシング（HTS）技術の向上とゲノムのシーケンシングコストの削減によって大幅に増加した。ヒトに対する単一のゲノムシーケンシング実験は、典型的には数億のショートリード（長さ100〜150bp）を生じる。これらはベースのゲノム配列と同じ配列のサブストリング（おそらく壊れている）である。このrawシーケンシングデータは、通常、FASTQフォーマットで保存される。FASTQフォーマットは、配列の信頼性を示すクオリティバリューとともに構成され、シーケンシングプロセスに関連するメタデータを含むリードの識別子をもつ。ほとんどの場合、リードはゲノムの短い断片からペアでシーケンシングされ、ペアエンドのFASTQファイルが作成される。ヒトゲノムシーケンシング実験の典型的なFASTQデータセットは、数百GBの記憶スペースを必要とする（典型的な30xシーケンシングの場合）。膨大なサイズのため、FASTQファイルの圧縮は、その保存と配布にとって最も重要である。
FASTQの圧縮については近年かなりの報告があり（Numanagic et al、2016）、SCALCE（Hach et al、2012）、Fqzcomp（Bonfield and Mahoney、2013）、DSRC 2（Roguski and Deorowicz、2014）、 FaStore（Roguski et al、2018）が含まれる。リードは、ゲノムの基礎をなす部分文字列であるため、圧縮のための冗長性は非常に大きい。リードに存在する構造を明示的に利用する特殊な圧縮器の場合、Gzip（Numanagic et al、2016）のような汎用的な圧縮器と比較して、10倍以上の圧縮率を達成できる。一方、クオリティバリューは構造が少なく、したがって圧縮ドメイン内の記憶空間のより多くの部分を占める可能性がある。最近の研究（Ochoa et al（2017）およびRoguski et al（2018））は、実際に最も広く使用されている下流アプリケーションの1つであるバリアントコールのパフォーマンスに悪影響を及ぼすことなく、クオリティバリューを非可逆圧縮（wiki）できることを示した。さらに、IlluminaのNovaseqなどの新しいテクノロジでは、以前の8または40レベルではなく4レベルの少ないクオリティバリューが使用されているため、バリアントコールパフォーマンスに影響を与えずにクオリティバリューの精度を低下させることができる。
これまでのFASTQ圧縮器の設計ではたくさんの仕事がなされてきたが、可変長リード（Roguski et al、2018）のサポート、高カバレッジデータセットへのスケーラビリティ、ペアを維持したままの圧縮（Roguski and Deorowicz、2014）、ロスレス圧縮（Hach et al、2012) など、1つ以上の決定的な特性のサポートに欠けている。 これらの要因の一部に起因して、圧縮率が悪化しても、Gzipは一般的なFASTQ圧縮機となっている（Numanagic et al、2016）。
ここでは、すべての重要な特性をサポートする次世代のコンプレッサーSPRINGを提示する。SPRINGは最先端のFASTQ圧縮器と比較して大幅に優れた圧縮を実現する。 SPRINGはメモリ/時間要件に関して著しく実用的であり、圧縮されたデータへの選択的アクセスをサポートする。
インストール
ubuntu16.04でテストした（docker使用。ホストOS: mac os10.12）。
依存
- On Linux with cmake installed and version at least 3.9 (check using ```cmake --version```):
#cmakeの３.9以上が必要だったが、apt-getでは古いバージョンしか入らなかったので、ダウンロードしてビルドし直した。
wget https://github.com/Kitware/CMake/releases/download/v3.13.1/cmake-3.13.1.tar.gz
tar -zxvf cmake-3.13.1.tar.gz
cd cmake-3.13.1/
./bootstrap
make
sudo make install
本体 GIthub
git clone https://github.com/shubhamchandak94/SPRING.git
cd SPRING
mkdir build
cd build
cmake ..
make
> spring -h
$ spring -h
Allowed options:
-h [ --help ] produce help message
-c [ --compress ] compress
-d [ --decompress ] decompress
--decompress-range arg --decompress-range start end
(optional) decompress only reads (or read
pairs for PE datasets) from start to end
(both inclusive) (1 <= start <= end <=
num_reads (or num_read_pairs for PE)). If -r
was specified during compression, the range
of reads does not correspond to the original
order of reads in the FASTQ file.
-i [ --input-file ] arg input file name (two files for paired end)
-o [ --output-file ] arg output file name (for paired end
decompression, if only one file is specified,
two output files will be created by suffixing
.1 and .2.)
-w [ --working-dir ] arg (=.) directory to create temporary files (default
current directory)
-t [ --num-threads ] arg (=8) number of threads (default 8)
-r [ --allow-read-reordering ] do not retain read order during compression
(paired reads still remain paired)
--no-quality do not retain quality values during
compression
--no-ids do not retain read identifiers during
compression
-q [ --quality-opts ] arg quality mode: possible modes are
1. -q lossless (default)
2. -q qvz qv_ratio (QVZ lossy compression,
parameter qv_ratio roughly corresponds to
bits used per quality value)
3. -q ill_bin (Illumina 8-level binning)
4. -q binary thr high low (binary (2-level)
thresholding, quality binned to high if >=
thr and to low if < thr)
-l [ --long ] Use for compression of arbitrarily long read
lengths. Can also provide better compression
for reads with significant number of indels.
-r disabled in this mode. For Illumina short
reads, compression is better without -l flag.
実行方法
ペアエンドのfastqを圧縮。 16スレッド使用。
spring -c -i pair1.fq pair2.fq -o output -t 16
- -c compress
- -i input file name (two files for paired end)
-
-o output file name (for paired end decompression.
outputができる(*1)。
シングルエンドのfastqを圧縮。 16スレッド使用。
spring -c -i single.fq -o output -t 16
ペアエンドの解凍（*2）
spring -d -i compressedfile -o pair_1.fq pair_2.fq
- -d decompress
元のファイルと全く同じかどうか確認する。
$ shasum R1.fastq pair_1.fq
02c47cb96949272757778a2ab9af09692bc85c6b R1.fastq
02c47cb96949272757778a2ab9af09692bc85c6b pair_1.fq
情報の損失、変更はない。
シングルエンドの解凍
spring -d -i compressedfile -o single.fq
- -d decompress
ペアエンドの解凍。400から1000まで。
spring -d -i compressedfile -o pair_1.fq pair_2.fq --decompress-range 400 1000
-
--decompress-range decompress only reads (or read pairs for PE datasets) from start to end (both inclusive) (1 <= start <= end <= num_reads (or num_read_pairs for PE)). If -r was specified during compression, the range of reads does not correspond to the original order of reads in the FASTQ file.
ペアエンドそれぞれ601リードだけ解凍される。
公式には他にも色々例が紹介されていますが、フラグをつけてlossyな条件で圧縮すると、後々トラブルを巻き起こす可能性もあります。非可逆圧縮を行う際は特に注意して下さい。
引用
SPRING: A next-generation compressor for FASTQ data
Shubham Chandak, Kedar Tatwawadi, Idoia Ochoa, Mikel Hernaez, Tsachy Weissman
Bioinformatics, bty1015, 07 December 2018
*1
11GBの非圧縮fastqの圧縮にかかる時間は、16スレッド使用で12分35秒ほどだった（SATA3 SSDで読み書き）。dokcerを使ったので、本来はもっと早く終わると思われる。ファイルサイズは、デフォルトの設定で9%ほどになった（GZIP圧縮では25%ほどにしかならない）。
*2
解凍については、スレッド数を4まで増やしても、ランタイムの変化は見られなかった。
