Fork me on GitHub 단맛만좋아요 :: Clinical NGS Seqeuncing에서의 중요 체크 포인트

NGS techologies기반의 WES, WGS는 비록 국내에서는 아니지만, clinical diagnosis, genetic risk prediction, patient management에서 루틴하게 사용되는 주목할만한 패러다임으로 자리잡았다.[각주:1]이러한 clinical genetics에서 bottleneck은 더이상 DNA sequence production이 아니라 DNA sequence analysis로 옮겨간 것은 누구나다 인지하고 있는 사실이며, large-scale comparative genomics는 일관성 있는 재생산성, 협력 연구자와의 안전한 공유 등 많은 허들이 존재한다. raw sequencing read를 생산하고 실제 clinical interpretation하기까지 clinician들에게 검증된 데이터 processing pipeline을 제공하여 sequencing 장비와 실제 응용간의 기술적인 격차를 줄여주는것이 필요하다. 결론부터 말하자면, 이러한 대량의 clinical 적용을 위한 루틴한 작업은 잘 짜여진(여기에는 많은 의미가 포함됨) pipeline과 cloud가 궁합이 중요하다고 할 수 있다.

robust한 분석 framework를 구현하는데 있어서 heterogeneous한 software의 input/output 및 software의 예기한/혹은 예기치 못한 문제들에 대한 적절한 오류 검사 및 로그 분석 등을 위한 장치가 마련되어야 한다.  뭐 이부분에 대해서는 다음번에 좀 더 자세하게 이야기 해보도록 하고, 좀 더 근본적인 문제에 대해서 우선 짚어 보도록 하자.
  • 클라우드로 데이터를 올리는데 너무 많은 시간과 노력이 든다. 이건 사용자가 부담해야 하는 문제인가?
  • 모든 분석을 마쳤고 데이터의 장기 저장에 따른 비용은 어떻게 해결되어야 하는 것인가?
이것들이 우선적으로 해결되어야 대량의 루틴한 작업이 주인 clinical에서의 cloud 활용에 대해서 이야기 할 수 있지 않겠는가? 자 다시 한번 이야기 하지만, 이건 해외처럼 NGS 기술이 clincal에 적용되는 시점의 이야기로 reseach와는 성격이 다르다는 것을 다시 한번 숙지하기 바란다.

Sequencing instrument의 특성을 고려한 효율적인 데이터 업로드

얼마전 streaming data in/out에 대해서 잠시 언급했는데, 좀 더 자세하게 이야기해보면 앞으로 NGS technology가 지금의 SBS(Sequencing by Synthesis) 방식이 아닌 single molecule sequencing인 경우 바로바로 읽어낸 seqeunce를 streaming으로 cloud에 upload한다면 분명 지금의 internet동영상 streaming처럼 비교적 낮은 bitrate로  전송이 가능해진다. 하지만 아직까지는 그렇지 못한 사정이며, 이를 해결하기 위한 몇가지 방안이 존재한다.

첫번째 방법은 고전적인 방법으로 Fedex를 이용하는 것으로 이것은 이미 BGI가 하고 있는 모델이나 연구자가 도서산간 지역(제주도)에 있는 경우 배달이 지연될 수 있다는 단점이 있다. 두번째로는 TCP(Transport Control Protoclo)를 뜯어 고치는 방법이다. 바로 Aspera가 그것중의 하나로 얼마전 IBM에 먹혔다. BGI는 지난 2012년 Bio-IT World Conference & Expo에서 EasyGenomics라는 서비스를 내놓으면서 Aspera를 사용하는 것을 시연했는데, 그 자리에 있어봐서 아는데... 암튼... 국내에는 Samasung SDS의 Rapidant가 Aspera like하며 국립농업생명공학정보센터 (NABIC)에서 활용되고 있다. 세번째 방법은 AWS의 S3라는 스토리지 시스템 사용시 multi-part uplaod를 사용하는 것인데, 이는 S3서비스가 일반 볼륨이 아닌 object storage이기 때문에 데이터를 쪼개서 동시에 parallel하게 upload가 가능하기 때문에 속도 향상에 도움을 준다. 실제로 AWS의 S3를 사용하는 DNAnexus의 경우 100 Mbps의 연결시 실제 업로드는 ~14 MB/sec로 parallelize upload시 ~90 MB/sec의 속도를 보였으며, 이는 WES 150X의 coverage를 갖는 압축된 (bzip2) FASTQ파일 약 3 GB를 로컬에서 cloud로 업로드하는데에 5분만에 가능하게 하는 속도이다. 참고로 GenomeCloud도 Aspera와 multipart upload를 혼합한 방식의 GTP라는 툴을 사용한다.

마지막으로는 시퀀싱 장비의 특성을 고려한 방법으로 일반적으로 illumina의 경우 RTA (Real Time Analysis)가 seqeucning images를 생성->image analysis를 수행->bcl 포맷의 base calling을 수행하고 나면 그 다음은 CASAVA에 의해 FASTQ generation(bcltofastq)이 수행된다. bcl 파일은 illumina sequencing run후에 생성되는 결과로 100bp의 single read인 경우 4base(AGCT), 12 tiles, 100 cycles로 생성된 데이터인 경우 4x12x100=4,800 bcl files가 생성되게 된다. 일반적으로 flowcell의 lane당 총 60개의 tiles로 구성되는 이미지 처리를 위한 최소 단위가 된다. 현재로서는 이 bcl 파일을 cloud로 전송하고 cloud내에서 fastq 파일을 generation하는 것이 네트워크의 bandwidth를 효율적으로 사용하는 방법이 될 수 있다. 또한 bcl 파일을 cloud에서 처리함으로서 얻을 수 있는 잇점은 여러가지 있다. DNAnexus나  galaxy의 경우 모두 이 방법을 사용하며, RTA 디렉토리 구조에서 bcl파일 생성이 완료되면 생성되는 "RTAComplete.txt" 파일을 통해 cloud로의 upload 시점을 확인하게 된다.

Reference-based 압축을 이용한 storage 효율화

최종 결과물을 얻기 위한 중간 산물이지만, 이 중간산물을 얻기까지 너무 많은  컴퓨팅 자원이 필요하며, 또한 추후 분석에 있어서 재활용의 가능성이 가장 높은 파일이라 선뜻 지우기 난해한 aligne된 DNA sequence인 BAM파일은 대부분 장기간 저장될 필요성이 있다. 그래서 나온것이 여러가지 압축 방법인데, 크게 압축은 2가지 방향으로 흘러가고 있다.
  • 분석시 오버헤드를 줄이기 위한 압축방법으로 GATK의 readuced read
  • 저장시 데이터량을 줄이기 위한 압축방법
엄밀하게 이야기 하자면, 첫번째의 경우에는 압축이라고 하기엔 무리가 있다. 일반적으로 압축이라고 한다면 다시 uncompress한 경우 그 정보가 다 보존되어야 하지만, Reduced Read의 경우 정보가 손실되기 때문이다. 즉 bam파일을 이용한 분석에 있어서는 파일용량이 작아짐으로서 다 샘플의 동시 분석이 가능해지며 분석 속도의 향상을 보이지만, 장기간 저장하기에는 정보 손실로 인해 그 효용성이 떨어진다. 따라서 압축/압축해제 후 모두 동일한 정보를 유지하는 형태의 압축이어야한다. 다시 말하지만, 압축이라는 개념은 분석/저장을 따로 구분해야 한다. 

3대 Nucleotide 저장소 중 하나인 ENA (European Nucleotide Archive)는 모든 정보를 유지한채로 reference를 기반으로 압축하는 방법인 CRAM format을 만들고 compress/decompress 툴킷을 공개했다. 역시 Ewan Birney가...  http://www.ebi.ac.uk/ena/about/cram_toolkit 

다음은 Exome 데이터를 실제 GATK readuced reads와 CRAM을 통해 각각 압축한 것으로 압축효율이 original bam 파일 대비 42배의 효율을 보이고 있다. 따라서 장기간 데이터에 액세스하지 않는 경우 reference-based compression과 archiving(tape 백업)을 사용하는 경우-물론 요즘 tape을 일반 파일시스템처럼 사용하는 LTFS (Linear Tape File System)가 있기도 하다.- 엄청난 저장에 따른 비용절감을 실현할 수 있다. 참고로 GenomeCloud도 장기간 데이터 보관을 위한 Tabpe기반의 archive를 GB당 엄청나게 저렴한 비용으로 준비하고 있으니 기대하기 바란다.

Original BAM: 19 GB
Reduced Reads: 2.6 GB (7.3배)
Reference based compress: 453 MB (42배)

추가) DNA sequence data를 아카이빙할때 흔히들 아카이빙 비용과 데이터 재생산에 따른 비용이 높을때 유효하다고 할 수 있다. 하지만, 단지 이것은 아카이빙 비용과 데이터 재생산 비용만이 고려되어야 하는가? 물론 두가지 비용에 대해서 알고 있는 것은 중요하다.[각주:2] 각설하고 아무리 데이터 재생산 비용이 하락하더라도 비용으로는 계산할 수 없는 시간이나 실험의 재현성에 따른 여러 문제등등이 존재하는 거고 디스크 가격의 하락과 데이터 압축의 효율화 및 on/offline을 통한 데이터 전달에 있어서 데이터의 압축/아카이빙은 절대적이라고 할 수 있다.

지금까지 간단하게 나마 clinical sequencing에 있어서 cloud를 사용하기 위한 넘어야 할 산 2가지에 대한 내용을 알아보았다. 국내에서도 다부처유전체사업이 시작되고 clinical 쪽으로의 다양한 유전체데이터 활용에 포커싱된 사업들이 시작할텐데 부디 기초부터 차근차근 쌓아 사업의 목표를 달성하지 못하더라도 부가적인 많은 tehcnologies가 만들어지고 이를 통한 유전체 분야의 활성화가 이루어지기를 바랄뿐이다. 사업을 하고 나서도 아무것도 남지 않는 (설마 시퀀싱한 데이터만 구석의 하드디스크에 먼지 쌓여 남는건 아니겠지.. 하드디스크 오래 상온에 두면 데이터 이상 생기기도 하니까 그냥 쌓아 두지 마라!!) 그런 사업이 되지 않길...

  1. JAMA. 2014 Mar 12;311(10):1035-45. doi: 10.1001/jama.2014.1717. [본문으로]
  2. The furutre of DNA sequence archiving [본문으로]
저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 컬럼 at 2014.03.18 17:51
Currently 댓글이 없습니다. comments want to say something now?

티스토리 툴바