- bed 파일에 2억 줄 짜리 데이터가 들어있다.
- 대충 파이썬으로 계산할 걸 만들어보니 1번 염색체 처리에만 싱글 프로세스로 하루 정도 걸렸다.
- 이런 데이터가 하나만 있는게 아니라 계속 나온다.
자 이런 상황이 있으면 예전 같으면 “C로 잘 짠다”라던지 “파일을 나눠서 클러스터에 넣는다.” 정도가 답이다. GNU parallel 같은 것 써보려고 노력을 해 볼 수도 있고.
전에도 블로그에서 소개한 적이 있는데, 이런 일에 tabix를 쓰면 웬만한 문제는 단번에 풀린다! 오오 위대하신 Heng Li 느님… 텍스트를 압축해 놓고 중간부터 랜덤 액세스가 가능해져서 파일을 나눌 필요가 없다보니, 파일을 나누거나 parallel을 쓸 때 엄청나게 낭비되는 I/O 시간이 절약된다. 물론 결과도 tabix에서 쓰는 bgzf로 미리 압축해서 저장하면, 그냥 이어붙이기만 하면 아무 문제 없이 다시 다음 과정도 또 분산해서 처리가 가능해진다. 포맷도 bed만 되는게 아니라 탭으로 구분된 데이터를 정렬하기만 하면 된다.
그런데 이게 이론적으로는 그냥 이어붙이기만 하면 잘 돼야하지만, 의외로 잘 안 된다. 어떻게 이어 붙여도 첫 번째 파일만 인식하고 나머지는 무시한다. 그래서 압축을 풀었다가 다시 압축을 하는 방법으로 구질구질하게 해 봤지만, 멀티쓰레드 지원하는 pbgzip은 랜덤한 버퍼 에러가 수시로 난다. (고치려고 해봤지만 실패 orz)
그래서 이리 저리 고민을 해 보다가, tabix를 패치하자니 EOF블럭이 중간에 들어있는 파일은 좀 변태같기도 하고 나이가 드니까 패치하고 올리고 하기도 귀찮고 해서 그냥 EOF 블럭을 빼고 파일을 합치는 툴을 하나 만들었다.
여기 –> bgzf-merge.py
요걸로 bgzf 합치면 짠! 하고 깔끔하게 tabix나 기타 bgzf 입력 받는 툴들이 제대로 돈다. 물론 속도는 풀었다가 다시 합치는 것하고는 비교가 안 된다. ㅋㅋ
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
% ./bgzf-merge.py --output spots-merged.txt.gz spots-{1101,1102,1103}.txt.gz spots-1101.txt.gz spots-1102.txt.gz spots-1103.txt.gz % tabix -0 -s 1 -b 2 -e 2 spots-merged.txt.gz % tabix -0 spots-merged.txt.gz 1101|head -2 1101 1 50 1101 7 33 % tabix -0 spots-merged.txt.gz 1102|head -2 1102 10 172 1102 17 10 % tabix -0 spots-merged.txt.gz 1103|head -2 1103 71 9 1103 139 71 |
요렇게~
아. 이것은 어디까지나 평소에 놀고 있는 클러스터가 옆에 있을 때 얘기다. 없으면…… 그냥 C로 고고 -ㅇ-;;