파일이 fastq 파일이고 따라서 레코드 크기가 4 라인이라고 가정합시다.
GNU Parallel에 -L 4
으로 알려주십시오.
fastq 파일에서 순서는 중요하지 않으므로 n * 4 줄의 블록을 하위 항목으로 전달하려고합니다.
그 효율적으로 압축 파일을 작동하지 않습니다
--pipe-part
제외
--pipe-part
를 사용하고
-L
작동하지 않습니다 이렇게하려면, 그래서 당신은
--pipe
에 만족해야한다.
zcat file1.fastq.gz | parallel -j16 --pipe -L 4 --joblog split_log.txt --resume-failed "gzip > ${input_file}_child_{#}.gz"
이
16 개 어린이 및 기록 경계 (즉, 4 개 라인)에서 잘게 1 MB, 행 블록 기본값 블록을 전달한다. 각 블록에 대해 작업을 실행합니다. 하지만 실제로 원하는 것은 총 16 개의 작업으로만 입력을 전달하는 것입니다. 그러면 해당 라운드 로빈을 수행 할 수 있습니다. 불행하게도
--round-robin
의 임의성의 요소는, 그래서
--resume-failed
이 작동하지 않습니다 :
zcat file1.fastq.gz | parallel -j16 --pipe -L 4 --joblog split_log.txt --round-robin "gzip > ${input_file}_child_{#}.gz"
parallel
가 16 GZip으로 압축하여 계속 고군분투 될 것입니다,하지만 당신은 100~200메가바이트/S를 압축 할 수 있어야한다.
지금 경우 당신은 우리가 더 빨리 그것을 할 수있는 미 압축 fastq 파일을했지만, 우리는 약간의 속임수해야합니다 :
@EAS54_6_R1_2_1_413_324
CCCTTCTTGTCTTCAGCGTTTCTCC
+
;;3;;;;;;;;;;;;7;;;;;;;88
@EAS54_6_R1_2_1_540_792
TTGGCAGGCCAAGGCCGATGGATCA
+
;;;;;;;;;;;7;;;;;-;;;3;83
@EAS54_6_R1_2_1_443_348
GTTGCTTCTGGCGTGGGTGGGGGGG
+EAS54_6_R1_2_1_443_348
;;;;;;;;;;;9;7;;.7;393333
: 종종 fastq 파일에서 동일한 문자열을 시작하는 sqlName를있을 것이다
여기에 @EAS54_6_R
입니다. 아쉽게도 이것은 품질 회선의 유효한 문자열입니다 (은 실제로). 실제로는 @EAS54_6_R
으로 시작하는 품질 회선을 보는 데 매우 놀랐습니다. 그것은 단지 일어나지 않습니다.
\n
다음에 @EAS54_6_R
을 레코드 구분 기호로 사용할 수 있으므로 --pipe-part
을 사용할 수 있으므로 이점을 활용할 수 있습니다. 추가 혜택은 주문이 동일하게 유지된다는 것입니다. 여기 file1-fastq
의 크기의 1/16에 블록 크기를 제공 할 것입니다 :
parallel -a file1.fastq --block <<1/16th of the size of file1.fastq>> -j16 --pipe-part --recend '\n' --recstart '@EAS54_6_R' --joblog split_log.txt "gzip > ${input_file}_child_{#}.gz"
을 당신이 당신을 위해 계산을 할 수있는 GNU 병렬 20161222 다음 GNU 병렬를 사용하는 경우. --block -1
의미 : 블록 크기를 선택하여 16 개의 작업 슬롯 각각에 하나의 블록을 제공 할 수 있습니다.
parallel -a file1.fastq --block -1 -j16 --pipe-part --recend '\n' --recstart '@EAS54_6_R' --joblog split_log.txt "gzip > ${input_file}_child_{#}.gz"
여기 GNU Parallel은 20 GB/s를 쉽게 전송할 수 있습니다.
그것은 recstart 값이되어야 하는지를 확인하기 위해 파일을 열 필요 성가신, 그래서 이것은 대부분의 경우에 작동합니다 : 여기
parallel -a file1.fastq --pipe-part --block -1 -j16
--regexp --recend '\n' --recstart '@.*\n[A-Za-z\n\.~]'
my_command
우리는 선이 다음과 같이 시작한다고 가정
@
[A-Za-z\n\.~]
anything
anything
'@'로 시작하는 몇 줄의 품질 줄이있는 경우에도 품질 줄에 항상 [A-Za-z \ n. ~]로 시작하는 줄이 따라 오지 않습니다. seqname 행은 @로 시작합니다.
당신은 또한 압축되지 않은 파일의 1/16에 해당 너무 큰 블록 크기를 가질 수 있지만, 나쁜 생각 될 것이다 :
- 당신은 유지할 수있을 것 RAM의 전체 압축되지 않은 파일
- 마지막
gzip
은 마지막 바이트를 읽은 후에 만 시작됩니다. (첫 번째 gzip
은 아마도 그 때까지 수행됩니다).104,214,420에 레코드의 수를 설정하여
은 (-N 사용) 당신이 무엇을하고 있는지 기본적으로, 당신의 서버는 아마 RAM의 그것 36기가바이트에 압축되지 않은 데이터의 150 GB의 유지에 어려움을 겪고있다.
입력 파일을 잘 모르겠습니다. 16 개의 CPU를 가지고 있기 때문에 파일 당 1 억 4 백만 라인이 필요하다면 입력 파일에 16 억 개의 라인이 있다고 추론합니다. 그런 다음 레코드가 각각 3GB라고 가정하면 3GB의 16 억 레코드가 39GB 파일로 압축됩니다. 나는 압축 알고리즘을 원한다고 생각하고있다 :-) 내가 잘못 이해 한 부분을 조언 해주기 바란다. –
@MarkSetchell : file1.fastq.gz (39GB)에는 1,667,430,708 행이 포함되어 있습니다. 자녀는 많아야 각각 104,214,420 줄을 포함해야합니다. 솔직히, 나는 가장 큰 라인/레코드의 크기를 모른다. 나는 --block-size 3000000000에 Parallel이 크기를 1MB (기본값)에서 2GB 이상으로 늘렸다는 사실을 알게되었다. 나는 3GB가 안전하다고 생각했다. 제발 깨달으십시오 :) –
죄송합니다, 계몽 할 수 없습니다 - 나는 깨닫지 못합니다 :-(이해하려고 노력하고 있습니다. 우리가 올레가 우리 모두에게 계몽을 기다려야한다고 생각합니다 :-) –