Fork me on GitHub 단맛만좋아요 :: '빅데이터분석' 카테고리의 글 목록

빅데이터분석

  1. 결함을 허용하는 의존성 있는 태스크의 관리 - published: 2015.10.13
  2. Docker를 이용한 Bioinformatics 플랫폼 - published: 2015.04.29
  3. 구글 지노믹스를 이용한 Picard와 GATK - published: 2014.12.17
  4. 구글 Genomics API를 이용한 De Novo Variant Call - published: 2014.10.17
  5. 구글 클라우드 플랫폼을 이용한 유전체 분석 경진대회 - published: 2014.10.17
  6. 클라우드 유전체 분석 뜬구름 다 잡았다. - published: 2014.10.17
  7. 클라우드로 만드는 슈퍼컴퓨터 - published: 2014.10.16
  8. Cloud Computing in Genomic Reserach - vagrant와 chef를 이용한 - published: 2014.09.26
  9. 고속 유전체 데이터 접근 - 1000 Genomes Project 사례 중심 - published: 2014.08.26
  10. Colummar Storage in Genomics - published: 2014.07.22
  11. Google Genomic data BigQuery (3) - 1000 Genomes, PGP를 R과 함께 - published: 2014.05.16
  12. Google Genomic data BigQuery (2) - 연구 재현, Literate Programming - published: 2014.05.08
  13. Google Genomic data BigQuery (1) - published: 2014.05.08
  14. NGS 데이터 분석을 위한 미들웨어 시스템 설계 - published: 2014.02.21
  15. 대규모 과학계산(유전체 연구)에 있어서 클라우드 사용하기 - published: 2014.01.25
  16. 나누면 2배 이상 - 클라우드를 이용한 데이터 분석 - published: 2013.10.29

그래프를 이용한 태스크 표현

흔히 바이오인포매틱스 분석이라고 하는 경우 스크립트나 모듈을 작성하여 일련의 분석을 수행하곤 한다. 그러나 단순한 형태의 일이 아니라 더욱 고난이도의 일을 처리하다가 보면 (물론 대부분이 그렇지만) 태스크의 의존성을 고려해야 하는 경우가 많다. 그래프를 이용하여 이를 표현해 보면서 어떻게 의존성과 결함을 고려한 스케줄러를 만들 수 있는지 생각해 보도록 하자.



총 4개의 노드 (Task1, Task2, Task3, Task4)와 엣지로 구성된 그래프로 각각의 엣지는 다음과 같은 의존성을 가진다.


Task1=>[Task2, Task3]

Task2=>[Task4]

Task3=>[Task4]

Task4=>[]


즉, Task1이 끝나야 Task2,3이 수행되고 Task4는 Task2,3가 끝나야 수행된다. 이렇게 각각의 노드(태스크)는 의존성(엣지)을 가지고 최종적으로 위의 그래프는 Task1-Task2, Task1-Task3, Task2-Task4, Task3-Task4로 표현될 수 있다.

워크플로우 상호 의존 태스크 관리

SGE를 비롯한 대부분의 스케줄러는 workflow interdependence (워크플로우 상호의존) 개념을 가지고 있으며 다음과 같이 표현될 수 있다.

qsub -N Task1
qsub -N Task2 -hold_jid Task1
qsub -N Task3 -hold_jid Task1
qsub -N Task4 -hold_jid Task2, Task3


어때유 간단하쥬,

결함을 허용하는 워크플로우 만들기

그런데 문제는 어떻게 결함을 허용하게 하느냐는 것이다. 여러가지 방법이 있겠지만, 필자는 각 Task의 결과 파일과 결과 파일의 MD5 체크섬을 이용하는 방안에 대해서 이야기 해 볼 것이다.


각 Task는 Task의 결과로 생성되(어야하)는 ouput file이 존재한다. 따라서 Task의 실행전에 해당 output file이 존재하는 또한 저장된 ouput file의 MD5 값이 outputfile을 실제 MD5를 실행해서 얻은 값과 동일한지(결과값이 변경되었는지를 확인하기 위해) 를 확인한다. 만약 두 조건을 만족한다면 해당 Task는 이미 정상적으로 실행되었던 것이기에  skip하고 그렇지 않은 경우에는 해당 Task가 처음 수행되거나 또는 비정상적으로 종료된 것이기 때문에 Task 고유의 action을 수행한다.


if [[ -f $OUTFILE && -f $MD5FILE && `md5sum ${OUTFILE} | cut -f1 -d" "` = `cat ${MD5FILE} | cut -f1 -d" "` ]]; then

   skip

else

   do task action

   task_md5=`md5sum $OUTPUTFILE > $MD5FILE

fi


위 그림과 같이 Task3이 어떤 이유에서든 실패했다면, 실패의 원인을 찾아 해결한 후 다시 모든 Task job을 resubmit하면 Task1은 skip이 되고 (이미 정상적으로 수행되었기때문) Task3부터는 재실행하게 되어 결국 자원낭비 없이 모든 Task들이 수행된다.

Job Array를 이용한 반복 태스크 관리

한가지 더 이쪽 분야의 일을 하다가 보면 특정한 일을 여러번 반복해야하는 경우가 생긴다. 가령 염색체별로 23번을 반복해야한다거나 샘플별로 동일한 작업을 여러번 해야 한다거나 말이다. Task2, Task3...TaskN의 작업은 변수1개만 다를뿐 동일한 경우에는 Job Array를 이용한다.


qsub -N Task2toN -t 1-100 


-t 옵션을 주어 1부터 100까지 100번의 job을 차례로 submit한다. 그럼 나는  job 스크립트에 다음과 같이 array별로 변수를 바꾸어 할당하여 job을 수행하도록 하면 된다.


sample=awk "NR==${SGE_TASK_ID}" samplelist.txt

java -jar GATK.jar -T GenotypeGvcf -I ${sample}.bam -O ${sample}.vcf


samplelist.txt에는 sample 이름 100개가 담겨져 있고 스크립트는 samplelist.txt 파일을 한줄한줄 읽어 두번째  모든 샘플에 대해 GATK 작업을 100번 수행한다. 100번을 job을 submit하지 않고도 100번을 job을 수행할 수 있는 것이다. 이렇게 간단하게 embarrassingly parallel를 손쉽게 구현이 가능하다.


간단하게 바이오인포매틱스 워크플로우에서 SGE 스케줄러를 이용하여 의존성 있는 Task들에 대해서 결함을 허용하는 한편 간단히 array job을 수행하는 방법에 대해서 알아보았다.


실제로는 NoFlo 등을 이용하여 프론트엔드단을 구현하고 그안에 SGE 스케줄러와 위에 설명한 방법들을 결합하여 워크플로우를 작성하여 실행하도록 하면 끝.

Job 모니터링과 fail job 복구

마지막으로 스케줄러를 사용하다보면 간혹 shared storage가 네트워크의 과부하 등으로 제대로 작동되지 않는 경우 SGE는 job의 상태를 Eqw로 빠드리고 에러를 확인해 보면 "can't chdir to directory: No such file or directory"라고 shared storage에 접근하지 못한다는 에러를 확인 할 수 있다. 이때는 아까도 말했듯이 간헐적인 네트워크 과부하 등의 원인으로 shared staroge 접근에 임시적으로 문제가 생길 수 있으니 이때는 job을 다시 실행하도록 하는데 qmod의 -cj 옵션으로 에러를 해결(clear)했으니 다시 시도하라는 것이다.


간단히 다음의 bash 스크립트로 job 상태를 xml 형태로 받아 파싱하여 queue의 상태를 모니터링하도록 하자.


로그 관리

분석을 수행하면서 생기는 로그는 다음의 3가지로 나누어 볼 수 있다. 스케줄러에서 생성되는 Job별 STDOUT, STDERR과 전체 워크플로우에 사용자가 넣은 로그로 각 로그는 웹 상에서 자동으로 갱신되어 보여지도록 한다. 이때는 js-logtail 등을 이용하면 쉽게 로그 파일을 처리할 수 있다.





저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2015.10.13 18:58
Currently 2 comments want to say something now?
Docker를 이용한 Bioinformatics 플랫폼
2015.04.29 13:09 | 빅데이터분석

한때? 학회세션이나 기타 개인적인 요청 등으로 유전체 데이터에 대해서 빅데이터의 관점에서 어떻게 클라우드를 활용하느냐?에 대한 이야기를 하고 돌아다니기도 했습니다. 뭐 여러 측면에서 클라우드라는 장점이 있을 수 있겠습니다만 여기서는 가상화 또는 컨테이너 기술을 기반으로 어떻게 활용될 수 있을지에 대해서 알아보겠습니다. 도커라는 컨테이너 기술을 이용한 유전체 데이터 분석에 관한 내용입니다.


Flow-based programming (FBP)

구글의 Polymer나 React, KLay Layered, NeoFlow의 기술을 이용한 the-graph를 이용하면 어플리케이션에서 프로세스를 블랙박스화하여 아래처럼 일련의 과정을 정의할 수 있습니다. 이미 이분야에서는 이를 파이프라인이라는 이름으로 부르며 데이터 분석을 위해 이러한 파이프라인을 이용합니다. 우리가 잘 알고 있는 GATK Best Practices도 하나의 파이프라인으로 표현이 가능하죠.



컨테이너를 이용한 모듈의 블랙박스화

그럼 FBP에서의 프로세스(위 그림의 네모칸에 해당)를 어떻게 구현하느냐에 대해서는 좀 복잡합니다. 일반적인 어플리케이션의 경우 표준화된 (가령 스프링 프레임워크라든지) 환경에서 작성되고 운영되지만 이쪽 분야의 경우 각가의 프로세스가 운영되는 환경이 제각각이라는 겁니다. BWA가 도는 환경 GATK가 도는 환경, GATK라도 Java의 버전에 따라 영향을 받는다던가. 암튼 하나의 컴퓨터에서 단일 환경으로 돌리기엔 무리라는 겁니다. 


그러면 각각의 네모를 네모만의 환경을 구축해주는 것입니다. 만약 BWA를 돌리는 네모라면 BWA만을 돌릴 수 있는 환경인 A를 만들어주고 GATK 2.x를 돌리는 네모라면 GATK 2.x를 최적으로 구동할 수 있는 환경 B를 만들어 주면 됩니다. 여기에 각 네모의 이름, input, output과 함께 네모를 구동할때 필요한 파라메터를 정의해 주게 됩니다.


Docker를 이용한 모듈 실행 환경 만들어주기

우선 표준 도커 이미지를 이용하여 컨테이너를 하나 만들고 이 컨테이너 안에 samtools를 설치합니다. apt-get install samtools 정도면 되겠습니다. 이제 samtools를 돌리기 위한 wrapping 작업을 수행합니다. wrapping시 필요한 input, output, 파라메터를 정의합니다. Inputs() 클래스는 tool(samtools)의 입력을 정의하는 것으로 각각 input은 define.input을 사용하며 name, descrition, required, list의 인자를 가질 수 있습니다. execute는 실제 실행 부분으로 Proces를 이용하여 실행할 명령을 입력합니다. 'test_'로 시작되는 test_sam_to_bam은 테스트를 위한 것으로 input으로 /sbgenomics/test-data/mock.sam을 이용하여 samtools wrapper를 테스트합니다.


뭐 중요한 것은 Bioinformatics를 이용한 분석 플랫폼을 구축하는데에 도커만큼 유용한 것도 없습니다. 현재 도커를 이용한 플랫폼에는 SevenBridges Genomics, BGI의 BGI Online이 있습니다.

 

저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2015.04.29 13:09
Currently 댓글이 없습니다. comments want to say something now?
구글 지노믹스를 이용한 Picard와 GATK
2014.12.17 15:31 | 빅데이터분석

이미 여러번 소개 했듯이 구글은 구글 지노믹스라는 서비스를 통해 유전체 데이터를 저장하고 분석할 수 있는 환경을 제공하고 있습니다.최근에는 우리가 흔히 사용하는  Picard나 GATK에서도 구글 지노믹스 서비스를 사용하는 방법을 내놓았습니다. 원리는 간단합니다. 구글 지노믹스 서비스에 저장된  SAM/BAM  파일을 Picard의 INPUT으로 지정할 수 있는 간단한 wrapper를 만든것입니다.


구글 지노믹스의 git 페이지에 gatk-tools-java라는 이름으로 "Tools for using Picard and GATK with Genomics API"라고 설명되어 있습니다. 아래와 같이 INPUT을 구글지노믹스 서비스의 SAM 파일을 지정해주면 wrapper는 Picard는 해당 INPUT을 STDIN으로 처리해도록 해주게 됩니다.


이렇게 된다면 이제는 굳이 로컬에 파일이 없더라도 기존의 알고리즘이나 툴들을 손쉽게 사용할 수 있게 된다는 장점이 있습니다. 물론 로컬이 아닌 네트워크를 통해 가져오는 것이기 때문에 구글 서비스와의 연결이 중요한데 몇번 테스트 해보니 자꾸 소켓 타임 아웃이나 기타 뭐 자잘한 에러가 발생하긴 합니다만, 구글 컴퓨트엔진을 이용한다면 이러한 에러는 없어지지 않을까 합니다. 이제 클라우드 환경에서 유전체 데이터를 다루는데 있어서 이러한 흐름이 현재 시점에서 쓸만한가에 대한 벤치마크를 해볼 예정입니다. 기대해 주시기 바랍니다.

java -cp .:gatk-tools-java-1.0.jar:genomics-tools-client-java-v1beta2.jar:htsjdk-1.121.jar com/google/cloud/genomics/gatk/picard/runner/GA4GHPicardRunner --client_secrets_filename=client_secrets.json -path=~/picard-tools-1.127 -tool=picard.jar ValidateSamFile INPUT=ga4gh://www.googleapis.com/genomics/v1beta2/readgroupsets/CMvnhpKTFhD04eLE-q2yxnU/1/

암튼 제 생각에는 이제부터 나오는 NGS 관련 툴들은 모두 input으로 받는 파일이 로컬과 구글지노믹스를 둘다 지원하는 형태로 나올 것 같다는 생각이 듭니다. 뭐 정확하게 말하자면 구글지노믹스를 지원하는 것이 표준인  GA4GH의 URL을 지원하게 되는 것이니 이 표준만 지원하도록 만들어 놓으면 구글이 되었던 어디가 되었던 다 가능하게 되는 겁니다. GA4GH 표준에 대해서는 유전체학회 소식지의 "대용량 유전체 데이터 표준화 최신동향"을 참고하시기 바랍니다.


참, 구글 애드센스를 블로그에 장착?했습니다. 많이 클릭해 주시면 뭐 좋지 않을까요? ㅇㅎㅎ

저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2014.12.17 15:31
Currently 댓글이 없습니다. comments want to say something now?
구글 Genomics API를 이용한 De Novo Variant Call
2014.10.17 15:31 | 빅데이터분석

De novo mutation (DNM)

De novo mutation은 부모에게서는 나타나지 않지만 자식에게서는 나타나는 rare genetic mutation이다. 이러한 mutataion은 Autism이나 Schizophrenia의 영향을 준다는 Whole-genome sequencing in autism identifies hot spots for de novo germline mutation. 논문이 있다. 지금까지 다훈증후군과 같이 21번 염색체가 3개인 삼염색체성(trisomy21)와 같은 유전질환은 어머니의 나이와 연관이 있다고 알려졌는데 Rate of de novo mutations and the importance of father’s age to disease risk 에 의하면 질병과 관련이 있는 de novo mutation이 아버지의 나이와 연관이 있다고 한다. 일찍 애 낳을 걸... 암튼 이러한 mutation들은 whole genome sequencing을 통해 exonic이나 interonic 영역 전반에서 발굴되고 있다.

DNM 발굴의 어려움

이러한 De novo mutation은 발굴하는데에는 여러 고려해야 할 사항들이 존재한다.
  • Rare event: DNM은 아주 드물게 발견된다. (~1 in 108bp)
  • 시퀀싱 에러: 이건 DNM이건 일반적인 variant call에서도 고려해야 하는 것으로 100 bp에 1개 꼴로 나타난다. 자칫 DNM이 아니라 시퀀싱 에러를 발견하는 꼴이 될지도 모른다.
  • Read Depth: read라는게 특정 위치에 매핑되면서 DNM이 해당 위치에서 불충분한 커버리지로 존재한다면 찾기 어려워진다.
  • Misalignment: 유전변이를 찾는 파이프라인은 read가 높은 quality로 alignment되었다는 걸 가정으로 한다. alignment가 잘 되지 않은 곳에서는 variant를 찾는데 어려움이 있다.
  • Expensive Validation: 검증을 위해 최소한 엄마, 아빠, 나 셋을 해야하니 sanger sequencing등을 이용한다면 검증 비용이 비싸진다.
  • Structural Variation: insertion, deletion, inversion, copy number variations, translocation 등과 같은 SV로 인해 DNM을 발굴하는데 어려워진다.

DNM 발굴 S/W 알고리즘

위기는 기회라고 했던가, 아직까지 DNM쪽에서는 이렇다할 killer S/W가 존재하지 않는다. 그나마 DenovGear라는게 DeNovoGear: de novo indel and point mutation discovery and phasing 논문을 통해 알려졌으며, A Likelihood-Based Framework for Variant Calling and De Novo Mutation Detection in Families 를 통해 PolyMutt 정도가 존재한다.

베이지안 네트워크를 이용한 DNM 발굴

베이지안을 이용할것이며 이것은 위의 PolyMutt 논문에 나온 알고리즘에 기반한다. 여러가지가 있겠지만 이 calling된 trio 각각의 varint file (vcf file)과 aligment(bam file)을 이용한다. 또한 예제 데이터는 무수히 많은 sequencing이 이루어진 유명한 three-generation CEPH/Utah family인 CEPH 1463 샘플이며 일루미나가 공개한 Platium Genomes 데이터 (HiSeq 2000 system 50X average depth using 2x100 bp liraries of ~350 bp insert size)를 이용한다. 

우리는 알고리즘을 구현하는데에 있어서 Google Genomics API를 사용할 것이기 때문에 우선 Google Genomics API로 접근 가능하도록 해당 데이터셋을 준비해야 하지만, 친절하게도 구글에는 공개 데이터셋으로 Illumina의 Platium Genomes 데이터를 제공하고 있다. 물론 이전 포스팅에서 언급한 DREAM Somatic Mutation Calling Challenge 데이터셋과 1000 Genomes  데이터셋도 제공하고 있다.

구글 Genomics API로 호출한 사용 가능한 공개 데이터셋

손하나 까딱하지 않고도 데이터셋이 준비되었다. 우선 Variant를 API로 호출하여 부모에게서는 존재하지 않았던 Variant만을 1차적으로 찾아낸다. 가령 아래와 같이 자식의 VCF 파일엔 AG라고 call된 변이를 부모것을 보면 GG로 부모에게서 call되지 않았던 A allele가 보였다면 우선 이 부위는 1차적으로 DNM 후보로 놓는다.

chr10,23366053,[23366053,{CHILD=AG, MOM=GG, DAD=GG}]

chr10,23662773,[23662773,{CHILD=AG, MOM=AA, DAD=AA}]

chr10,24051000,[24051000,{CHILD=AC, MOM=AA, DAD=AA}]

chr10,24443525,[24443525,{CHILD=AG, MOM=GG, DAD=GG}]

자. 여기에서 멈춘다면 아주 심플하지만, 위의 DNM은  후보 DNM에 불과하다. 각각 부모자식을 별개로 call한 결과이기 때문에 실제 DNM을 찾기 위해서는 3명을 동시에 보아야 한다는게 함정이다. 어찌보면 join variant call 개념이 들어가야 한다. 여기서는 베이지안 네트워크를 이용하도록 한다. 베이지안 네트워크라는게 방향성이 있는 비순환 그래픽 모델 (directed acyclic graphical model)을 이용하는 것으로 쉽게 노드와 선으로 해당 모델을 그래프 형태로 알기쉽게 표현이 가능하다. 아래 그림은 비와 스프링쿨러 그리고 잔디가 젖는가에 대한 것을 베이지안 네트워크로 표현한 것으로 자세한 내용은 생략하기로 한다. -.-;;


마찬가지로 우리도 trio 데이터를 아래와 같이 베이지안 네트워크를 통해 표현할 수 있겠다. 앞서 말했듯이 방향성이 있으면서 비순환적인 그래프가 완성되었다. GF, GM, GC는 각각 아빠, 엄마, 자식의 genotype을 의미하며 각  genotype은 총 10개 (AA,AC,AT,AG,CC,CT,CG,GG,GT,TT)를 가질 수 있으며, trio의 genotype은 103개가 가능하다. 부모의 genotype은 자식의 genotype에 방향을 가지고 있다. DF, DM, DC는 관찰변수로 해당 genotype 부분의 read 정보 즉 base 정보를 나타낸다. 따라서 GF는 DF와 대응한다. 


그래서, 베이지안 네트워크를 이용하여 최종적으로 모든 de novo와 mendelian inheritance의 경우에 대한 likelihoods를 계산 가능하게 된다. 아 멀미나 @.@ 이제 아까 DNM 후보들은 하나씩 해당 부분의 Reads 정보를 읽어와서 베이지안 네트워크를 통해 진짜 DNM을 가리게 된다. 어때요 참 쉽죠.




Genomics API

이제 데이터도 준비되었고, 알고리즘도 준비되었으니 실제 구현을 해보아요! 데이터를 읽어오는 방법에 대해서 알아본다. 물론 Genomics API를 이용한다. 우선 위에서도 확인 가능하지만 Illumina의 공개된 3대에 이르는 대가족의 dataset id는 "3049512673186936334"이다.

Variant set과 Variants

이 데이터셋에 존재하는 NA12878 샘플에 대한 callset id는 "3049512673186936334-14"이다. 그렇다면 이 샘플에 대한 실제 variant는 callset id와 variantset id ,reference name, start, end position을 입력하여 찾는다. 구글 Genomics API는 다음의 URI를 이용하여 호출하며 key 값은 자신이 구글 개발자 콘솔을 통해서 발급한 key를 이용하면 된다. API는 프로그램을 작성하거나 간단히 chrom 플러그인 (Advanced Rest Client App)이나 genomics 홈페이지에서도 호출이 가능하다. variants의 search API는 https://www.googleapis.com/genomics/v1beta/variants/search?key=xxx 를 통해서 아래의 정보를 포함하여 호출하면 된다. 위의 API를 호출하여 trio에 대한  genotype을 비교하여 후보 DNM을 찾아낸다.
{
   "variantSetIds": [
      "3049512673186936334"
   ],
   "callSetIds": [
      "3049512673186936334-14"
   ],
   "referenceName": "chr10",
   "start": 23366052,
   "end": 23366053
}

Read Set과 Reads

이제 각 후보 DNM에 해당하는 reads들을 읽어 베이지안 네트워크를 이용하여 DNM을 찾게 된다. NA12878 샘플의 Read Set id는 "CMvnhpKTFhCoyJTFk73Eyq0B"로 후보 DNM에 대한 reads  정보를 얻기 위해  Reads API를 호출한다. https://www.googleapis.com/genomics/v1beta/reads/search?key=xxx
{
   "readsetIds": [ "CMvnhpKTFhCoyJTFk73Eyq0B"],
   "sequenceName": "chr1",
   "sequenceStart": "10000",
   "sequenceEnd": "10001"
}
 이렇게 찾은 DNM은 Variation in genome-wide mutation rates within and between human families 논문의 데이터를 가지고 검증한 결과 좋은 성능을 보이지만, 사용된 샘플들이 blood가 아닌 cell line이기 때문에 정확한 검증을 위해서는 blood로 해봐야 한다. 아래는 false de novo mutation candidate를 보여주는데, 위의 두개의 트랙은 부모(NA 12891, NA 12892)이며 아래 트랙은 자식(NA12878)을 보여준다. variants API를 통해 보면 아빠 AA, 엄마 AA, 자식은 AG로 DNM이라고 찾았지만, reads를 통해 확인해보면 충분한 증거(아빠 엄마 모두 갈색이 있다.)가 없기 때문에 베이지안 결과 해당 DNM은 무시된다. (G base는 갈색으로 표시)


본 포스팅은 Google Genomics  GitHub 페이지를 참고하여 작성되었습니다.
저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2014.10.17 15:31
Currently 댓글이 없습니다. comments want to say something now?
예전에 글 중에서 유전체 데이터를 이용하는 경진대회에 대한 이야기를 한적이 있다. 각설하고 여기 미국에서 어떻게 경진대회를 하는지 한번 보기 바란다. 누누히 했던 이야기이지만 NGS 시퀀싱 데이터를 이용한 임상으로의 적용은 유전변이를 검출을 최적화하고 표준화하는데에 있다.

바로 암 데이터를 이용한 이러한 최적화, 표준화를 위한 일환으로 암샘플에서 SNV와 SV를 검출할 수 있는 최적화 알고리즘에 대해 ICGC와 TCGA는 "DREAM Somatic Mutation Calling Challenge"를 수행하고 있다. 

최근 Global Alliance for Genomics and Health에도 가입한 구글은 DREAM challenge의 참가자들에게 Google Cloud Platform을 제공한다. 참여자들은 로컬의 클러스터 컴퓨터가 없이도 contest data에 접근할 수 있도록 구글의 Google Compute Engine의 virtual machine을 사용할 수 있는 무료 크레딧을 발급 받을 수 있다. 이를 통해 데이터에 대한 오픈 액세스, 연구자간의 협력 촉진을 통해 연구의 민주화를 달성하기를 기대하고 있다. 
출처:https://www.synapse.org/#!Synapse:syn312572/wiki/61863

구글은 $2,000 (2백만원)에 해당하는 credits과 contest data에 자유롭게 액서스 가능한 Google Cloud Storage를 제공한다. 챌린지와 관련한 자세한 구글 클라우드 사용법은 "Using Google Cloud"를 참고하기 바란다.

자 모두 준비되셨으면, 챌린지에 도전하세요.
저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2014.10.17 13:43
Currently 댓글이 없습니다. comments want to say something now?
클라우드 유전체 분석 뜬구름 다 잡았다.
2014.10.17 10:27 | 빅데이터분석
혹자는 유전체 연구에 있어서 클라우드 컴퓨팅을 뜬구름이라 했다. 혹자는 클라우드를 네어버 N 드라이브쯤으로 알고 있다. 뭐 어쨌듯 간에... 일찍이 미국이나 한국에서 클라우드 기반의 유전체 분석 사업자들이 3년전 세상에 나타났고 다행인지 불행인지 몇몇 업체들은 소리 소문없이 생겼다가 사라지는가를 반복했다. 그나마 지금까지 그 명맥을 유지하고 있는 몇몇 업체들의 그동안 막힌 숨통이 터지는 소식이 얼마전부터 속속 나오기 시작했다. NCI와 Genomics England를 시작으로...

Cancer Genomics Cloud

NIH의 NCI (National Cancer Insitute)에서 올해초 Cancer Genomics Cloud라는 사업에 대한 공모를 했고 그 결과가 이제 나온것이다. Cancer Genomics Cloud Pilot이라 불리는 이번 과제는 Broad Institute, Institute for System Biology (ISB)와 Seven Bridges Genomics (SBG)가 수행한다. ISB는 Google과 SRA International과 함께 그룹을 만들어 진행한다. 

Google & ISB

마더를 서는 ISB는 이번 과제로 인해 2년동안 $650만 (약 70억)을 클라우드 기반의 oncology 데이터를 저장하고 분석할 수 있는 플랫폼을 구글과 함께 만들게 되었다. 이로써 엄청낭 The Cancer Genome Atlas (TCGA)의 유전체 데이터는 이제 구글 플랫폼으로 들어가게 되며 암연구자들은 대형 로컬 컴퓨팅 클러스터에 액세스가 필요없이 유전체 데이터를 탐색할 수 있게 되면서 클라우드 환경에서 공통 데이터 셋을 가지고 프로젝트를 수행하면서 공동연구를 활성화하는 계기가 된다. 

Seven Bridge Genomics

총 $2천만 (210억원) 규모로 진행되는 사업으로 ISB가 70억규모이니 나머지 Broad와 SBG 또한 비슷한 70억 규모로 해당 과제를 진행할 것으로 예상된다. SBG는 홈페이지에 별도의 메뉴를 만들어서 해당 사업을 홍보하고 있다. 

Eagele Genomcis와  Genomics England

SBG는 또한 Eagle Genomics와 함께 Genomics England의 데이터를 분석하는데에도 참여하게 된다. Eagle Genomics는 160만 파운드 (27억) 규모의 과제를 수행하며 추후 second phase의 800만 파운드 (136억)에도 참여가 가능하게 된다. 본 과제는 인간 유전체 데이터 분석 및 해석을 지원하기 위한 새로운 생명정보학 도구의 개발을 지원하게 된다.

SBG는 일찍이 미국의 Cambridge와 영국의 London에 각각 사무소가 존재하는데 아마도 이번 NCI와 영국의 과제에 모두 참여하는것이 가능하게 한 원동력?이라고 할 수 있다. 물론 클라우드는 영국이던 미국이던  아마존을 사용한다. 물론 아마존도 세계 각국에 데이터센터가 존재한다.

클라우드로 향하는 유전체 사업

미국과 영국의 대형 유전체 관련 프로젝트는 그동안 로컬 컴퓨팅을 통한 연구에서 이제 그 한계를 벗어나 클라우드로 이동하고 있다. 아울러 그동안 죽지않고 이시장을 노려온 SBG와 이제 막 유전체 분야에 뛰어드는 구글의 행보가 기대된다. 이제 국내도 이런 움직임이 있으려나? 아직 멀었다. 그저 클라우드건 뭐건 이번 다부처유전체사업이 잘 되기만을 바란다.

 
저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2014.10.17 10:27
Currently 댓글이 없습니다. comments want to say something now?
클라우드로 만드는 슈퍼컴퓨터
2014.10.16 14:18 | 빅데이터분석
대규모의 계산이 필요하다. 단돈 418 달러 즉 40만원대로 클라우드를 이용하여 슈퍼컴퓨터를 사용할 수 있다. 물론 당신은 손하나 까딱하지 않아도 된다. 물론 클러스터 슈퍼컴퓨터를 손수 설정한다고하면 이는 더 싸질 수도 있지만, 당신은 아마도 실패할 확률이 더 높다. 본 글의 내용은 Cycle Computing의 "Lessons learned building a 4096-core Cloud HPC Supercomputer for $418/hr"이라는 글을 참고하여 작성하였다. 

4096 코어의 클러스터 컴퓨터

4096코어 8코어짜리 서버로 계산한다면 512대의 서버가 필요하다. 이를 클라우드를 통해 만들 수 있을까? 만들수 있다면 어떠한 것들이 고려되어야 할 것인가? 물론 이는 내가 직접 수행한 것은 아니고 위에 언급한 Cycle Computing이 삽질한 내용이다.

고려해야하는 것들

  • 4096개의 코어가 과연 아마존의 EC2내에서 단일 사용자에게 가능한가?
  • 클러스터 구성을 위한 소프트웨어를 유지할 수 있을 것인가?
  • 스케줄러는 충분히 그 역할을 할것인가?
  • 그렇다면 가격은 어떨까?

가용 가능한 서버는 존재하는가?

앞서 말했듯이 4096 코어는 아마존의 c1.xlarge (8코어) instance 512개가 필요하다. 이것들은 또한 같은 region안에 존재해야 클러스터링이 가능하다. 기본적으로  클라우드는 region이 존재하며 각 region 마다 가용 가능한 클라우드 컴퓨팅등 여러가지로 서로 다른 클라우드라고 봐도 된다. 따라서 아마존 전체가 아닌 해당 region내 512개의 instance를 만들 수 있어야 한다. 일반 사용자들은 자신의 계정에서 생성할 수 있는 instance의 갯수에 제한을 받으며, 물론 가용 가능한 갯수도 해당 region이 busy하다면 그것마저 사용이 불가능할 수도 있다. 그러면 이 문제는 어떻게 해결하는가? 한마디로 아마존과 긴밀한 협력관계를 유지하고 있는 곳이 아니라면 좀 복잡해진다. GenomeCloud의 경우도 클라우드 부서와의 긴밀한 협력하에서 이러한 문제들에 대해서 비교적 자유롭다. 첨언을 하자면 GenomeCloud는 평균 1000코어 이상을 사용하고 있다. 

Instance 생성 실패와 성공

Cycle의 경우에는 us-east region의 a, b, c, d 총 4개의 zone을 돌아가면서 instance를 생성한다. 그들은 자체적 fail-over 알고리즘으로 각 zone을 round-robin 형태로 돌아가면서 instance를 생성한다. 이때 10분 간격으로 64개의 instance를 동시에 순차적으로  모든 512개의 instacne에 대해 약 1시간 동안 생성한다.

결론적으로  0.75-1.00% instance failure rate로 모든 instance를 생성한다. fail을 종류별로 보면 instance가 시작되면서 바로 종료되는 에러 (aws-terminated), instance는 생성되었으나 원하는 instance가 아닌 경우로 이는 instance에 접속이 불가능하여 해당 instance를 에러로 처리하는 경우 발생한다. 마지막으로는 instance는 생성되었으나 기본 disk를 생성하는 시점에서 에러가 발생하는 경우(disk failure)이다. 이러한 에러들로 인해 100대중 1대꼴로 instance 생성에 실패한다. 그럼 KT의 클라우드의 failure rate는 어떨까? 그리고 어떠한 이유로 인해 fail이 발생할까? 비밀.

클러스터 구성 관리 소프트웨어

instance가 생성되었으면 이제 각 instance들을 하나의 컴퓨터처럼 묶어야 한다. 즉 클러스터링을 구성해야 한다. 이러한 작업은 이전 블로그 포스팅에도 언급되었던 Chef와 같은 것을 이용한다. Cycle도 마찬가지로 Chef를 이용하여 클러스터에서 소프트웨어를 설치하고 구성을 자동화한다. Chef는 매 10분마다 생성되는 64개의 instance를 효율적으로 처리한다. 뭐 이제는 노하우가 쌓여 한번에 256대를 동시에 Chef로 핸들링이 가능해졌다고 합니다. 

스케줄러는 버텨줄것인가?

이제 job을 처리해줄 스케줄러에 대한 부분이다. 이번에는 Torque를 이용해달라고 했다는데 Torque의 경우 예전의 PBS나 OpenPBS를 기반으로 하는 것으로 알고 있는데, 암튼 문제는 스케줄러를 튜닝해야 한다는 것이다. 물론 source를 고치거나 하는건 아니고 설정을 몇몇 바꾸어주어야 한다고 한다. pbs_sched를 위한 alarm 파라메터, job_stat_rate 등을 default 설정으로 하는 경우 4096 test job을 제출한 경우 대부분이 job이 running 되지 않고 scheduled되고 실행되지 않았다고 한다. 결론은 Torque보다는 Condor를 사용하라고 권장. 참고로 우린 SGE를 사용합니다.

가격

마지막으로 가격은 c1.xlarge instance 512개를 사용한 경우 아마존의 공식가격 + 자사의 서비스 비용을 합쳐 시간단 $417.79 원래 c1.xlarge 가격에 약 40%정도의 가격을 더 받네요.

이제까지 Cycle Computing이라는 회사가 약 4000개의 코어를 엮은 HPC 클러스터 컴퓨터를 아마존의 클라우드를 이용하여 구축할때 고려해야 할것들과 가능한지에 대한 내용을 봤다. KT 클라우드도 GenomeCloud의 서비스를 이용하여 이러한 HPC를 구축하는것이 가능하다. 물론 여기서는 제대로 다루지 않았지만 genome 데이터를 위한 스토리지를 구축하는 것 또한 고려되어야 하는데 이부분에서도 역시 GenomeCloud는 확실한 솔루션을 가지고 있다는 것 또한 알아두심 되겠음.
저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2014.10.16 14:18
Currently 댓글이 하나 달렸습니다 comments want to say something now?
유전체학회 정기학술대회에 "Cloud Computing in Genomic Research"란 제목으로 발표를 했었는데 워낙 시간도 짧고 준비도 제대로 하지 못했던터라 이자리를 빌어 재탕 들어갑니다.

소프트웨어 전성시대 그러나 사실상

BGI의 경우 157대의 시퀀싱 장비가 가동중이며, 매일 6 TB의 유전체데이터를 생산하고 있습니다. 매일 전송되는 데이터는 1 TB에 이른다고 합니다. (출처: The Big Challenges of Big Data, 2013, Nature) 또한 시퀀싱 장비의 가격하락으로 그동안 시퀀싱센터라고 불리는 몇몇 대형 연구소에서나 생산되었던 데이터량보다는 이제는 작은 아카데믹 랩들이 생산하는 데이터가 늘어나고 있습니다.

하지만 컴퓨팅 파워와 소프트웨어/알고리즘의 부족은 유전체데이터를 활용하는데에 걸림돌이 되고있습니다. 여기서 클라우드가 이를 어떻게 해결할까에 대한 부분이 바로 이야기하고자 하는 부분입니다.  

우선 소프트웨어/알고리즘의 부족은 두가지로 해석할 수 있습니다. 첫째는 말그대로 시퀀싱장비에서나오는 데이터를 분석할 100% 만족할 만한 소프트웨어/알고리즘이 없다는 의미와 둘째로 많은 소프트웨어가 나오지만 사용할 줄 모른다는 것입니다.

일례로 Nature Protocol의 2007년부터 나온 논문들의 70%가 소스코드를 포함하고 있으며, abstract에 소스코드라는 단어가 포함된 논문은 2003년 60편에서 2013년 299편에 달하고 있습니다. 즉 많은 소프트웨어가 나오지만 옥석을 가려내거나 제대로된 설치 및 활용에 어려움이 따르고 있다는 것입니다.

클라우드로 S/W설치를 손쉽게 하자.

그렇다면 어떻게 S/W를 손쉽게 설치/활용할 수 있을까?라는 부분에 맞추어 클라우드가 어떻게 활용될 수 있는지 보도록 하겠습니다. 제가 내놓은 솔루션은 바로 Vagrant + Chef(cookbook) + 클라우드의 조합입니다. 

Vagrant는 Box라는게 있습니다. 바로 운영체제입니다. 사용자는 가상의 환경 (Vmware나 VirtualBox와 같은 로컬의 가상환경 또는 아마존, KT와 같은 클라우드 컴퓨팅)에 원하는 운영체제를 바로 구동이 가능합니다. 이렇게 구동된 운영체제에 Chef를 이용하여 원하는 일련의 S/W 설치에 관한 정보(cookbook)를 수행하면 바로 분석에 사용가능한 컴퓨팅 환경이 만들어지게 됩니다.

cookbook에는 bwa, bowtie, picard, gatk, tophat, samtools 등의 소프트웨어 설치/설정에 관한 recipes를 만들어 놓고 이를 묶어 nextgenseq라는 cookbook을 만들어 놓습니다. 그러면 이 cookbook만 실행하면 되는 거죠.

# Cookbook Name:: nextgenseq

# Recipe:: prereq


case node['platform']

when "ubuntu", "debian"

include_recipe "apt"

end


[node[:nextgenseq][:system_dir], node[:nextgenseq][:binary_dir]].each do |d|

directory d do

owner "root"

group "root"

mode  "0755"

action :create

end

end

위의 코드는 prereq라는 레시피입니다. 즉 nextgenseq이라는 쿡북에서 가장 먼저 해야할 일을 정의한것입니다. 프로그램은 어떤 사용자로 설치되어야하며, 어떠한 환경에서 실행되는지를 정의해 놓은 것이죠.

# Cookbook Name:: nextgenseq

# Recipe:: bwa


include_recipe "nextgenseq::prereq"

include_recipe "build-essential"


nextgenseq_package "bwa" do

source "http://downloads.sourceforge.net/project/bio-bwa/bwa-#{node[:nextgenseq][:bwa][:version]}.tar.bz2"

binaries %w{ bwa solid2fastq.pl qualfa2fq.pl }

action :install

provider :nextgenseq_make_and_copy

end

위의 코드는 bwa라는 레시피입니다. 간단히 sourceforge에서 지정한 버전의 bwa를 다운로드하고 설치하는 과정이 적혀 있는 것이죠. 이렇듯이 하나의 쿡북안에 분석에 필요한 S/W에 대한 일련의 과정을 정의해 놓으면 되는 것입니다. 

그렇다면 이런 쿡북은 자신이 직접 만들어야 할까요? 아니죠. 이런건 저와 같은 사람들이 만들어 놓으면 되는 것입니다. 분석할 데이터에 따라, 버전별로 이러한 쿡북들을 만들어 놓으면 사용자는 간단히 명령어 2~3줄로 자신이 원하는 컴퓨팅 사양에 자신이 원하는 툴들이 설정 완료되게 되는 거죠. 아래의 동영상으로 간단히 NGS 분석 환경을 만드는 것을 확인하세요.

조마간 분석 툴들을 다양한 NGS 응용(WGS, Somatic Call, RNA-Seq, De novo RNA-Seq, ChIP-Seq, SV Detection등) cookbook으로 다시 만나뵙겠습니다.



저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2014.09.26 18:39
Currently 댓글이 없습니다. comments want to say something now?
유전정보를 담고 있는 유전체 데이터는 DNA 시퀀싱 기술이 발전함으로 유전체 연구 분야에 많은 변화가 일어나고 있다. 유전체 연구에 있어서 이를 분석할 수 있는 컴퓨팅 리소스에 대한 문제로 인해 자칫 유전체정보를 활용할 수 있는 다양한 기회를 놓쳐 버릴 수도 있는 상황이다.

유전체 연구에 있어서 가장 첫번째 걸림돌은 시퀀서에서 생산되는 데이터를 포함한 연구에 사용되는 데이터 볼륨이 크다는 것이다. 오늘은 바로 연구에 활용할 데이터에 어떻게 액세스 할것인가에 대한 내용이다.

인간의 유전변이에 대한 카다로그를 작성하기 위한 1000 Genomes Project는 현재까지 2편의 논문이 발표되었으며 cited된 논문만 하더라도 2,000여편에 이른다. initial phase(called pilot project)를 비롯하여 phase 3까지 진행하면 데이터를 생산해 냈으며, 현재 공개된 데이터만 200 TB에 달한다. 아마 유전체 연구를 진행한다면 이 프로젝트의 데이터를 이용하지 않는 사람이 없을 것이다. (일례로 GATK에서 reference로도 사용된다.)

이렇게 연구적으로 중요한 데이터인 만큼 다양한 방법으로 해당 데이터에 액세스 할 수 있다. 현재까지 필자가 파악한 방법은 아래의 4가지 방법으로 각각의 방법에 대해서 알아보도록 하자.
  • NCBI와 EBI의 ftp 서버를 이용하여 접근하는 방법
  • NCBI와 EBI의 Aspera를 이용하여 접근하는 방법
  • 아마존 클라우드의 S3를 이용하여 접근하는 방법
  • Globus Online을 이용하여 접근하는 방법

Globus Online - 오랜 그리드 컴퓨팅에서 묻어나오는 편리성

가장 최근에 나온 접근 방법으로 Globus라는 서비스를 이용하는 것이다. Globus는 원래 그리드 컴퓨팅 시절부터 시작된 방법으로 이를 클라우드까지 확장한것이라고 할 수 있다. Globus에는 Endpoint라는 개념이 있는데 Endpoint끼리 서로 데이터를 주고 받을 수 있다. 바로 Globus에서는 1000 Genome 데이터를 저장하고 있는 endpoint를 제공(ebi#1000genomes)하고 있으며, 자신이 다운로드 하고자 하는 곳에 globus 관련 s/w를 설치하여 그곳을 endpoint로 만들어 두면 손쉽게 언제어디서나 globus 홈페이지에서 두 endpoint간 데이터를 웹브라우저를 이용하여 전송할 수 있다.

아래는 데이터를 받고자 하는 리눅스 컴퓨터에 endpoint(hongiiv#linux)를 설정하고 ebi#1000genomes로 부터 파일을 클릭하여 다운로드가 가능하다. 이처럼 endpoint만 설정해 놓으면 직접 다운로드 하고자하는 곳에 접속하거나 별도의 프로그램 없이 웹상에서 손쉽게 다운로드가 가능하다.

필자는 pilot project의 trio 샘플중 하나인 NA12878 데이터중 염색체 22번 데이터를 다운로드 해 보았으며, 총 3.8 GB로 2.4 Mb/s의 속도를 보였다. (약 3시간 23분 소요)

결론적으로 고속의 데이터 전송에 특화된 솔루션이었지만, 제 기능을 발휘하지 못했다. 소프트웨어적인 문제인지 뭔지 암튼 실망스러운 결과이다.


 
장점
별도의 프로그램 구동이나 다운로드하고자 하는 컴퓨터에 접속하지 않고도 데이터를 웹상에서 언제어디서나 편리하게 다운로드 가능하다.
단점
endpoint의 설정에 다소 어려움을 느낄 수도 있으며, 테스트상에서 속도는 실망스러웠다.
총평
   

Aspera - 기술력으로 인정받아 IBM에 인수되다.

Aspera는 고속의 대용량 데이터 전송에 특화된 fasp 프로토콜을 이용한 데이터 전송 소프트웨어 전문회사로 얼마전에 IBM에 인수되기도 하였다. 특히 wan 환경 (국가대 구가)에서 탁월한 성능을 보여준다. EBI와 NCBI 모두 Aspra를 이용하여 데이터를 다운로드 할 수 있도록 하고 있으며, 사용자는 별도의 클라이언트 툴을 이용하면 된다. NCBI의 SRA 등 바이오 분야에서는 오래전부터 사용되었던 터라 거부감없이 사용할 수 있다.

필자는 EBI를 통해 동일한 3.8 GB의 trio 데이터를 다운로드 해본 결과 96 Mb/s의 속도로 5분안에 다운로드가 가능하다. @.@

리눅스 커맨드라인상에서 다운로드 명령예,
/root/.aspera/connect/bin/ascp -i /root/.aspera/connect/etc/asperaweb_id_dsa.openssh -Tr -Q -l 100M -L- fasp-g1k@fasp.1000genomes.ebi.ac.uk:vol1/ftp/technical/pilot2_high_cov_GRCh37_bams/dat a/NA12878/alignment/NA12878.chrom21.ILLUMINA.bwa.CEU.high_coverage.20100311.bam ./ 
장점
생물학자들에게 널리 알려진 방법으로 1000 genome외에 NCBI의 데이터 등에 적용되어 있으며, 특히 해외구간에서 안정적으로 고속다운로드가 가능하다.
놀라운 전송속도에 반함.
총평

 

아마존 S3 - 분석 컴퓨팅까지 원한다면 최고의 솔루션

아마존에서는 자사의 클라우드 컴퓨팅의 스토리지 서비스인 S3에 1000 Genomes 데이터를 제공하고 있다. 위에서 살펴본바와 같이 S3용 클라이언트 툴을 이용하여 다운로드 할 수 있을 뿐만 아니라, 컴퓨터까지 아마존에서 사용한다면 같은 환경이기에 엄청난 속도로 다운로드 및 바로 마운트하여 사용이 가능하다. 마찬가지로 국내로 다운로드해본 결과 6 Mb/s의 속도로 83분이 소요되었다.

여기서 그럼 같은 아마존 서비스내의 EC2를 이용하여 서버를 생성한 후 다운로드를 수행해 보았다. 아마존의 m3.medium 인스턴스 (1 vCPUs, 3.75 GiB의 Moderate Network Performance)를 us-east-1a (버지니아) 지역에 생성하여 다운로드 한 결과 289 Mb/s의 속도로 105초 소요 되었다. 역시 S3의 1000 genomes 데이터는 같은 아마존 클라우드 내에서 사용할 때 그 진가를 발휘한다.



참고로 아마존의 경우 일찍이 유전체분야에 다양한 응용사례를 내놓고 있으며, 한글페이지 또한 존재하니 참고하기 바란다. 유전체학에서의 AWS활용(한글), 유전체학을 위한 서비스(한글), 1000 게놈 프로젝트와 AWS(한글)

리눅스 커맨드라인상에서 다운로드 명령예,
s3cmd get s3://1000genomes/technical/pilot2_high_cov_GRCh37_bams/data/NA12878/alignment/NA12878.chrom22.ILLUMINA.bwa.CEU.high_coverage.20100311.bam
장점
아마존의 클라우드 서비스들과 연동하여 사용하고자 하는 경우 최선의 선택일 수 있다.
단점
아마존이 아닌 곳으로 다운로드하거나 하는 경우 속도 이슈가 발생한다.
총평

 

FTP - 이것저것 설정하는 거 다 귀찮다

마지막으로는 ftp를 이용한 방법이다. 누구나 다 손쉽게 다운로드가 가능한 방법으로 EBI, NCBI 모두 ftp를 제공한다. 손쉬운 사용대신 느린 속도는 사용자의 몫

리눅스 커맨드라인상에서 다운로드 명령예,
wget ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/technical/pilot2_high_cov_GRCh37_bams/data/NA12878/alignment/NA12878.chrom22.ILLUMINA.bwa.CEU.high_coverage.20100311.bam
장점
대부분의 사용자에게 익숙하게 활용이 가능하며 평이한 수준의 속도는 장점이자 단점이다.
단점
평이한 수준의 속도
총평

 

그밖의 국내외 전송 솔루션

1000 genomes 데이터가 다양한 방법으로 access를 제공하고 있으나, 이밖에도 국내에서는 삼성SDS에서 개발한 고속전송솔루션 래피던트가 존재한다. 래피던드는 농진청의 NABIC에서 적용되어 SRA 데이터 다운로드 등에 사용되고 있다. 이외에도 UCSC의 The Cancer Genome Hub(CGub)에서는 TCGA의 데이터 다운로드에 GeneTorrent를 사용하고 있으며, 국내에서도 ETRI가 Cancer 데이터를 다운로드하는데 사용되었으며 국내로 다운로드 속도가 50 Mb/s 정도라고 한다.

물론 KT의 GenomeCloud에서는 g-Storage라는 서비스를 통해 gtp라는 프로토콜을 이용하여 고속의 전송과 데이터 sharing 기능을 제공하고 있으며 g-Storage는 디엔에이링크에서 고객의 데이터의 고속 전송에 사용되고 있다.

맺음말

지금까지 1000 genomes 프로젝트 데이터에 액세스하는 다양한 방법과 그외 다양한 고속전송솔루션에 대해서 알아보았다. 무엇보다도 유전체 연구에서의 데이터전송과 공유는 중요하며 이는 연구의 가장 기초가 되는 것이다. 안타까운것은 국내연구로 생산된 데이터는 제대로 공개된 것이 없는 것으로 아예 다운로드 기술에 대해서 언급할 수 조차 없다는 것이다.

아마존이나 Globus가 공익?을 위해 1000 genomes 데이터를 제공하는 것처럼 국내에서도 이런 사례가 있으면 한다. 그럼 여기서 왜 이 업체들이 1000 genomes 데이터를 무료로 제공할까?라는 것이다. 바로 이들 업체는 유전체 데이터를 분석할 수 있는 환경을 유료로 제공하고 있다는 것이다.

따라서 1000 genomes 데이터는 자사의 고객에 대한 서비스 차원 및 고객을 유치하기 위한 하나의 수단일 수 있다는 것이다. 두번째는 왜 한국에서는 업체들이 이러한 것을 하지 않느냐는 것이다. 첫째로 아마존이나 Globus와 같이 돈을 내고 유전체분석을 제공하는 업체는 거의 KT가 유일하다는 것과 그나마 고객들이 별로 없다는 것이다. @.@

200 TB의 데이터를 저장하고 제공(저장료+전송료)하는 것에 비해 업체가 얻는 이익은 마이너스라는 것이다. 따라서 국내에서 업체의 참여는 기대하지 않는게 좋을 것이다. 국내에서 이러한 데이터 미러링 서비스는 업체가 아닌 다부처 사업등의 국가 차원에서의 지원이 있어야 가능할 것이다. (근데 제공해도 국내에서 저 데이터를 활용하여 연구하는 사람이 몇이나 될까요? ㅋㅋㅋ)

그마나 올해부터 다부처 유전체 사업에 대해서 이러한 부분들에 대한 여러가지 사업이 진행중이니 연구자들이여 본격적인 연구를 위해 수련에 힘쓰기 바란다. 끝.

덧, 위에서 측정한 속도는 국내의 KT의 클라우드 컴퓨팅환경에서 다운로드한 결과이며, 최소2회이상 다운로드한 결과에 대한 평균입니다. 다운로드 속도는 다운로드하는 클라이언트의 환경에 따라 달라질 수 있습니다.

1000 genomes 3.8 GB 데이터를 국내에서 다운로드 하는 경우 속도 비교
   소요시간 전송속도 (Mb/s) 
 Globus Online 203분  2.4 Mb/s 
 Aspera 5분  96 Mb/s 
 아마존 S3 (국내)  83분 6 Mb/s 
 아마존 S3 (아마존내) 105초  289 Mb/s 
 ftp  30분 16 Mb/s 

저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2014.08.26 18:26
Currently 댓글이 없습니다. comments want to say something now?
Colummar Storage in Genomics
2014.07.22 14:55 | 빅데이터분석
요즘 화두는 Big Data 기술을 어떻게 genomics에 접목하는 것이냐에 대한 것이다. 구글의 Google Genomics, UC Berkeley의 ADAM 등이 Genomics에 Big Data 기술을 적용하고 있다.

다양한 Big Data 기술들이 genomics에 적용될 수 있겠지만, 오늘은 colummar storage 기술을 이용하여 BAM 파일등의 genomics 데이터를 다루는 방법에 대한 이야기를 하고자 한다.

왠 colummar storage? colummar storage 기술을 사용하면 대용량의 데이터에 대한 액세스를 빠르게 수행할 수 있기 때문이다. genomics 데이터를 다루기 힘든 이유와 왜 빠른 액세스가 필요한지 등등의 구구절절한 why에 대한 대답은 굳이 하지 않겠다. 뭐 간단히 지난 그들에서 google의 bigquery를 사용하는 방법에 대해서 언급한 적이 있는데 바로 bigquery도 colummar storage 기술을 이용하고 있다. 그 정도로 해두겠다.

python을 통해 파일을 처리한다고 해보자. 우선 파일의 내용을 읽어들야 한다. 이때 readline()을 이용하여 line 단위로 처리할 것이다. 흔히 MySQL과 같은 데이터베이스도 레코드 단위로 데이터를 저장하고 읽어들이게 된다. 지금까지 우리가 알고 있는 데이터는 record-oriented하게 저장되어 있다. 근데 요놈을 90도 돌려서 column-oriented하게 저장하는 것이 바로 columnar storage이다. 이렇게 되면 아래 그림에서 보는 것과 같이 컬럼 별로 데이터를 각기 다른 storage volume에 저장이 가능하게 된다. columnar storage를 사용하게 됨으로서 다음과 같은 잇점을 얻게 된다.

Traffic minimization 쿼리에 사용된 컬럼의 값만 스캔하여 쿼리를 실행하고 데이터를 이동시키면 된다는 것이다. 예를 들어 "SELECT top(title) FROM foo"의 경우 전체 데이터에 대해서 뒤지는게 아니라 단지 title 컬럼이 저장된 곳만 뒤지면 되기 때문에 트랙픽을 최소화할 수 있게 된다. BigQuery에서는 쿼리를 날린 데이터의 양에 대해서 과금이 책정되는 이유가 바로 이것이며, 1000 genomes의 variants가 3.5 TB에 달하지만 매번 쿼리에 따라 3.5 TB의 모든 데이터를 사용하지는 않게 되며 따라서 빠르게 scan이 가능하다.

Higher compression ratio 한 연구에 따르면 row-based storage가 일반적으로 1:3인것에 비해  columnar storage의 경우 압축률이 1:10으로 훨씬 효율적인데 이는 컬럼내에 유사한 값들이 존재하고 이는 컬럼내의 값들의 variation이 적은 경우 특히 낮다. 따라서 BAM 포맷의 파일의 경우 5~25% 정도의 압축률을 보인다고 한다.

그러나 단점도 존재하는 법! 바로 기존의 데이터에 대한 update가 있는 경우 효율적으로 작동하지 않는다는 것인데, 이는 genomics 데이터의 특성상 update가 거의 발생하지 않는다는 점에서 genomics 데이터를 column storage 기술을 사용하는데에 있어서 최적이라고 할 수 있다.

바로 이러한 column storage의 기술을 구현한 것이 Dremel로 구글 내부에서 사용하다가 google bigquery라는 이름의 서비스로 내놓았다. open source 진영에서도 Parquet가 존재한다.


BAM/SAM 파일을 예를 들어보면, row 기반으로 헤더정보와 read 정보를 컬럼 단위로 포맷을 변환한다. 이렇게 포맷변환을 수행하면 column storage에 저장이 가능한 형태가 되며 여러 장비에 컬럼 단위로 분산되어 저장이 가능하게 된다. 앞선 higher compression ratio의 경우 특히  quality score에서 효율성이 좋아지며 약 0.75x archive의 효율성을 지닌다. traffic minimization 부분은 filter나 read의 quality를 체크하는 것등과 같은 구현에서 좋은 성능을 보인다.

 
BQSR (Base Quality Score Recalibration)
alignment 이후에는 BQSR 과정을 거쳐 data normalization을 수행하는데 이부분이 pipeline에서 많은 시간이 소요되는 부분이다. 이 과정은 후에  variant call의 accuracy에 상당한 영향을 미치기 때문에 bioinformatics pipeline에서 중요한 부분중 하나이다. 

GATK에서 BQSR이 구현되어 있지만 완벽하게 map reduce 프레임웍을 지원하지 않고 있지만 embarrassingly paralleizable (완전하게 독립되어 각각의 프로세서에 나누어 실행될 수 있는 병렬화의 하나) 하기 때문에 
colummar storage를 통해 구현됨으로서 성능향상을 꽤할 수 있다.  BQSR의 알고리즘은 Introduction to Base Quality Score Recalibration (BQSR)을 참고하면 되며, 간단하게 설명하면 다음과 같다. 
 
DNA sequencing 장비로부터 생산된 read의 각 base (A, C, T, G)는 estimate된 quality를 가지고 있다. estimated quality score는 Phred score를 통해 표현되며 이는 에러 확률이다. Phred score가 10이라면 이는 90%의 accuracy를 의미하며, 20은 99%, 30은 99.9%를 의미한다. Phred scores는 quality score 또는 Q scores라고도 한다.

BQSR은 바로 이 Phred quality score를 보정(adjusting)하는 과정으로 이미 알려진 SNPs를 입력으로 받는다. BQSR 알고리즘은 당신의 파일에서 reference와 다른 SNP이 dbSNP에 존재하지 않는 경우라면 이를 error로 간주한다. 통계적으로 개인에서 dbSNP에 존재하지 않는 SNP은 약 1,000개를 넘지 않는다는 가정을 기반으로 한다.

reported phred와 dbSNP의 정보를 가지고 계산된 empirical phread score를 통해 recalibration을 수행한다. 다음과 같이 3개의  read group(RG1, RG2, RG3)가 존재하고 각각은 error갯수/관찰된 SNP갯수로 RG1의 경우 총 3개의 read중 첫번째의 경우 1/105로 empirical phred score는 -10log10(error probability) = -10log10(1/105) = Q20인데, Yate's correction에 의해 -10*log10((errors+1) / (observations+2) = Q17이 된다. Reported quality score는 Q16으로 이 두개의 값을 통해 read의 각각 base에 대해서 recalibration을 수행하면 된다.

뭐 당연한 거지만, BQSR 과정에서는 read의 뒷쪽으로 갈수록 즉 machine cycle이 진행될수록 quality가 낮아지는 SBS(
Sequencing by Synthesis) 방식의 경우 covariates으로 base position을 사용하여 BQSR을 수행한다.


암튼 요렇게 분산처리 가능 quality score 컬럼만 사용하여 계산하면 무지 빨라진다. 뭐 그런거임. 대충 BQSR을 구현하게 되면 아래 수식,,, 자세한건 생략


GATK와 비교하면 accuracy나 performance측면에서 뛰어나고 Picard와 비교만 해서 BQSR의 경우 Performance 그래프는 생략,,, 암튼 GATK와 99% 동일한 결과,,, 이거 내가 한거 아님 아래 참고문헌의 ADAM 만든 사람이 한거임...



정말 끝.

참고문헌

https://github.com/googlegenomics
https://cloud.google.com/files/BigQueryTechnicalWP.pdf
http://www.eecs.berkeley.edu/Pubs/TechRpts/2013/EECS-2013-207.html
https://github.com/bigdatagenomics/adam
https://spark.apache.org/
http://www.genomeweb.com/informatics/uc-berkeley-team-develops-new-open-source-schema-apis-tools-fast-scalable-genomi 
http://zenfractal.com/2014/01/25/bqsr/
http://www.open-bio.org/bosc2014/BOSC2014-Genome-01-ADAM-Nothaft.pdf
저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2014.07.22 14:55
Currently 댓글이 없습니다. comments want to say something now?
본 문서는 PDF 형태로 제공합니다. PDF 문서의 내용은 다음과 같습니다.  문서 다운로드 바로 하기
 

 
저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2014.05.16 11:32
Currently 2 comments want to say something now?
BigQuery를 이용하여 genome 데이터를 주무르기 전에 얼마전까지 뜨거운 감자였던 연구의 재현성에 관한 이야기를 하려고 한다. 여기서는 R을 중심으로 클라우드와 literate programing (문학프로그래밍) 을 이용하여 어떻게 연구의 재현성을 확보하는지에 대해서 알아보려고 한다.

클라우드를 이용한 R 분석 환경 구축 및 공유/활용

글제목은 거창하지만, 그냥 내가 어떻게 R을 사용하는지에 대한 것이니 너무 기대하지 않기 바란다.  아래의 일련의 과정을 통해 R환경이 구축된 클라우드 이미지를 확보한다.

  • 클라우드 컴퓨터에서 2가지 이상 버전의 R을 설치 (하나는 2.x 대 다른 하나는 3.x대의 R을 각각 설치)
  • 기본적인 패키지 설치 (이건 개인별로 차이가 있으니 알아서 설치하시오)
  • R 통합 IDE 환경인 RStudio의 Server 버전을 설치 (웹을 통해 RStudio 접근 가능)
  • 요기까지 설정한 내용을 이미지화 (나중에 원하는 서버사양으로 원하는 때에 바로 사용 가능하도록)
  • 서버 삭제,,, 이제 남은건 R환경이 구축된 이미지 

RStudio Server 및 기본 패키지 설정하기

시커먼 콘솔상에서 그동안 R 코드를 작성하고 실행했다면, 이제 통합개발환경을 고려해보기 바란다. 그중에서도 RStudio를 추천한다. 로컬에 설치해서 수행이 가능한데, 그보다는 서버에 R을 설치하고 원격에서도 웹접속으로 RStudio를 사용할 수 있는 RStudio Server를 추천한다. 아래와 같이 웹 브라우저를 통해 접속하면 바로 어느 컴퓨터가 되었던지 R을 사용할 준비가 된다.


이미지 생성하기

위에서 RStudio Server가 설치된 서버에 대해서 이미지 생성 버튼을 클릭하여 이미지화한다.

서버를 생성한후 설정을 마치고 나면 해당 OS와 R이 설정된 내용을 그대로 보존하면서 이미지를 만들 수 있다.

이미지를 통한 서버 생성하기

이제 기존의 서버는 삭제하고 다음과 같이 "나의 이미지"에 R이 설정된 이미지가 만들어진다. 이제 원하는 때에 바로 이미지를 통해서 "서버 신청" 버튼을 통해 새로운 서버를 생성 가능하다.


RStudio 활용하기

이제 R이 필요한 경우 이미지로부터 서버를 생성하여 웹으로 접속하면 바로 웹 접속을 통해 R환경이 수분내에 갖추어진다. 이제 어떻게 활용할지 재현성은 어떻게 확보하는지 RStudio를 통해 알아보도록 하자.

데이터를 분석할 때마다 수많은 휘발성? 코드를 작성하고 잊곤한다. 또는 메모장에 복사하든지 좀 더 세련된 사람들은 EverNote나 OneNote 등을 활용해 R스크립트를 적어 놓곤 하는데,, 이게 다른 사람에게 주면 환경이 서로 맞지 않거나 해서 실행이 안되기 일쑤다. 

R Markdown을 이용 코드 작성하면서 문서 작성을 한방에

HTML이 웹을 위한 마크업 언어라면, Markdown은 그냥 일반적인 문서를 위한 마크업 언어다. HTML 보다 훨씬 작성하기 쉽다. 뭐 이정도,,,, 예를 들어 제목을 쓴다고 할 경우 "#난 제목이요." 라고 해주면 자동으로 글씨 크기와 정렬을 해준다. 코드를 삽입하는 경우도 ```와 ``` 사이에 코드를 넣어주면, 알아서 박스 처리도 해준다. 

마크다운 문법으로 작성된 문서 (위)를 변환하면 아래 그림처럼 변신

그렇다, RStudio는 IDE환경에서 Markdwon을 작성할 수 있도록 해준다. 즉 R 명령을 죽 치면서 분석을 진행하면서 동시에 Mardown을 이용해서 해당 코드에 대한 내용과 코드를 삽입한 Markdwon을 작성한다. 물론 이때 History를 보면서 내가 작성한 코드를 Markdown에 손쉽게 추가가 가능하다.


이렇게 생성된 Markdown 문서는 Knit HTML을 이용해서 HTML 문서로도 변환이 가능하며, 이때 코드의 실행 결과는 자동으로 Markdown 문서에 삽입된다. 코드중 '''{r}이라고 되어 있는 부분은 실제 실행하고 그 결과를 첨부하라는 의미이다.


위와 같이 작성된 마크다운은 실제 summary와 plot이 실행되어,  요렇게 plot까지 삽입되게 된다.


자, 이제 결론을 내자.

자신의 분석 데이터와 분석환경을 클라우드 이미지로 만들고, 마크다운 문서를 공유하면 끝. 누구든지 손쉽게 내가했던 분석을 재현 가능 뭐 이래라 저래라 주저리 말할 필요없이 끝.

추가적으로 이러한 마크다운만을 별도로 공유하는 사이트가 있으며,
필자(나)는 분석환경은 클라우드 이미지 공유하고 분석 데이터 및 markdown 문서는  github을 통해 제공,,, 끝.

저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2014.05.08 11:13
Currently 댓글이 없습니다. comments want to say something now?
Google Genomic data BigQuery (1)
2014.05.08 07:51 | 빅데이터분석
저번 포스팅에 구글의 Genomics API와 그들의 전략에 대해서 간단히 살펴보았다. 현재 진행중인 Google의 gonomics API는 하루가 멀다하고 새로운 기능들을 올라오고 있다. 오늘은 저번 포스팅에 있어서 추가할 내용들에 대해서 기술하도록 하겠다. 결론은 이제 genomics 연구자들은 google의 플랫폼에 대해서도 배워야 할 때가 다가왔다는 것이다. 

Dataset import 기능 - google storage로 부터 import는 아직 준비중,,,

genomics 데이터를 사용하기 위해서는 Datasets를 만들어야 한다. 이 datasets은 크게 Google storage, NCBI 그리고 Local 에 저장된 file을 각각 사용할 수 있다. Google의 storage를 활용하는 경우 google  storage에 데이터를 업로드 한 후 datasets과 readsets을 각각 만들어야 하는데 아직 dataset에 대한 API의 기능들이 워킹하지 않는다. 따라서 google이 sample로 넣어 놓은 datasets만을 사용이 가능하다. 

Google의 public dataset과 datasets ID



BigQuery와 만난 유전체 데이터

몇일전 구글은 BigQuery 관련 예제도 함께 올려 놓았다. 1000 genomes 데이터를  올려 놓아서 사용자는 이에 대해서 bigqyery를 수행할 수 있을 뿐만 아니라 다양한 예제를 통해 어떻게 genomics 데이터를 bigquery와 함께 사용해야 할지에 대한 힌트를 주고 있다. BIgQuery가 나온건 벌써 몇 해가 지났지만, genomics 분야에서 구체적으로 어떻게 BigQuery를 사용하는지에 대한 사례를 적어도 내가 알기에는 없었는데, 이번에 구글이 직접 그 예를 google API와 함께 내놓았다.

우선 BigQuery가 무엇인지에 대해서 알아보자

BigQuery는 Big Data를 실시간으로 분석할 수 있는 플랫폼으로 CSV  파일을 이용해 손쉽게 Data를 Import/Export할 수 있다. BigQuery는 MySQL과 같은 Relational DB가 아니며, 저용량의 수많은 테이블의 필드간의 관계에 의해 처리는 되는 데이터가 아닌 대용량의 Table 수가 소수인 Data에 적합하다. 또한 Update, Delete 의 데이터에 대한 처리가 지원되지 않고 Data의 분석만 가능하다.

BigQuery를 사용하기 위한 준비

앞선 Genomics API와 마찬가지로 BigQuery를 사용하기 위해서는 Google APIs Console을 사용하여 접근하여야 한다. 물론 Google 계정은 기본으로 가지고 있어야 함은 물론이다. 기본적으로 비활성화된 BigQuery API를 활성화(status on)하여야 한다. BigQuery를 사용하는 방법은 웹브라우저를 통한 BigQuery Browser Tool을 이용하거나 REST API, bq Command Line Tool 등을 이용하는 방법이 있으며 여기서는 "BigQuery Browser Tool"을 사용한다.

기본적으로 샘플 데이터셋 (publicdata:samples)을 몇개 제공하며 이중 미국인의 1969~2008년까지의 출생 데이터 (publicdata:samples.natality)를 이용해 보도록 하자. 아래와 같이 New Query를 통해 출생아의 인종이 한국인 (child_race=28)은 모두 17,225명임을 확인 할 수 있다. (CDC Birth Vital 통계정보 페이지로 바로가기)

 
또한 전체 데이터는 다음의 쿼리를 통해 약 1억건이 넘는 Big Data임을 확인 할 수 있다.



미국내 최고령의 산모는 54세이며, 아빠의 나이는 99세로 되어 있는데 이는 아마 몰름을 99로 처리한듯 하다. 99세인 아빠들이 너무 많음...


이제 Genetic Data를 살펴보아요.

현재 google이 제공하는 BIgQuery 데이터는 1000genomes와 PGP 데이터 입니다. Project Name은 google.com:biggene이구요. PGP는 아직 준비중입니다. 지금 당장 Query를 날릴 수는 없습니다. 조만간 공개한다고 합니다. 하지만, 예제 코드들과 실행 결과는 올려 놓았으니 살펴 보도록 하죠.

앞서서 BIgQeury를 사용하는 방법은 신생아 데이터로 살펴보았구요. 참 가격은 우선 데이터를 저장하는데에 $0.026 (per GB/month)입니다.
1000genome data가 대략 1 TB정도 된다는 군요.  그럼 한달에 1,000 GB*$0.026 = $26입니다. 와 저장하는데 엄청 저렴합니다. 그런데 문제는 저장이 아니라 query를 날려야 합니다. 이때 GB당 $0.005입니다. 즉 1000genome data에다가 대고 query를 한번 날릴때 마다 1,000 GB * $0.005=$5 되겠습니다. 그럼 1000genome 데이터를 처음 업로드하고 query를 100번 정도 날렸다고 합시다. 그럼 가격은 $25 + $5 * 100 = $525 한화로 58만원 정도 나오게 됩니다. 음 계산하고 보니까 만만치 않은 비용이네요. 넵 저장 비용은 싸지만,, 거의 무료나 다름 없지만, query마다 용량에 따른 과금이 책정되니 주의하셔야 합니다요. 자! 그럼 여기서의 교훈은 무엇일까요? 넵 한번 쿼리를 날릴때 잘 만들어서 날려야 한다는 거죠. 

Schema

1000genome data의 스키마는 볼 수 없습니다. 넵, 아직 일반인들에게 공개가 안되어있다고 이야기했기 때문에 table의 구조가 어떻게 되었는지 모릅니다.

Provenance

google genomics에 올라온 예제는 단순히 1000genomes 데이터만 있는게 아닙니다. 어떠한 데이터로 이루어져 있냐면 다음과 같이 3가지 type의 데이터로 이루어져 있습니다.

Variant Data
Phenotypic Data
  • 데이터 정보: 1000genomes data에 대한 Ethnicity, gender, family relationship에 대한 정보
  • 출처: http://ftp.1000genomes.ebi.ac.uk/vol1/ftp/technical/working/20130606_sample_info/20130606_sample_info.txt
  • 출처: http://ftp.1000genomes.ebi.ac.uk/vol1/ftp/20131219.populations.tsv
  • 출처: http://ftp.1000genomes.ebi.ac.uk/vol1/ftp/20131219.superpopulations.tsv
  • 출처: http://ftp.1000genomes.ebi.ac.uk/vol1/ftp/technical/working/20130606_sample_info/20130606_g1k.ped 
Annotation Data
다음 포스팅에서 실제 1000 genomes 데이터를 가지고 BIgQuery를 이용하여 의미있는 데이터를 가져 오는 예를 살펴보도록 하겠다.



 
저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2014.05.08 07:51
Currently 댓글이 없습니다. comments want to say something now?
무슨 논문제목 같기는 하네. 간단히 말해서 NGS Big Data 분석을 위해서 컴퓨터 hardware (Cluster, Cloud)와 software(BWA, GATK 등) 사이에서 이들을 효율적으로 연결시켜주는 것이 필요하다는 것이다. 지금까지 써왔던 Resource Managent를 위한 Job Scheduler인 OpenPBS, SGE, OGE (SLURM, Torqueue는 써보지 못했음) 를 사용하는데에 실제 데이터 분석을 하는데에 있어 컴퓨터 자원을 효율적으로 사용하지 못한다는 단점이 존재한다.

일반적으로 컴퓨터의 레벨 (levels of computing)은 Core, Machine, Cluster로 나뉘어진다. 하나의 Machine은 메모리를 공유하는 여러 Core가 존재하며 각 Machine들은 여러개 서로 묶여 Cluster를 구성한다. 요즘은 CPU내에 여러개의 Core개 존재하는 형태가 일반적이다. Parallelism(병렬화)란 이러한 각 레벨의 자원을 서로 어떻게 효율적으로 사용하는냐라는 문제를 다룬다. Core 레벨에서는 multi-threading, Machine 레벨의 클러스터에서는 scatter-gather (요즘 유행하는 Map/Reduce method)를 사용하게 된다.

병렬화는 여러 레벨의 자원을 다루기 때문에 이들을 손쉽게 관리하기 위한 Job Scheduler가 필요하며, 이러한 Job Scheduler의 임무중 하나는 Big Data 분석을 위해 구축된 infrasturcture를 사용을 최대화하는데에 있다. 흔히 Grid Engine이라고도 불리는 Job Scheduler는 분석을 위한 일정한 단위의 job을 할당 받아 해당 job을 수행하게 된다.

예를 들어 4단계로 구성된 job이(NGS의 경우 mapping, calling, annotation, merge) 있다고 하자. 1단계를 위해서는 3개의 worker(Core)가 필요하고, 2단계에는 2개, 3단계에서는 3개가 필요하며, 마지막 4단계에서는 1개가 필요하다. 여기서 각 단계는 이전 단계가 모두 finish되어야 다음 단계에 진입할 수 있다. 당신은 총8개의 노드(1 core/8 machine, 4 core/2machine 등등 구성은 다양할 수 있다)가 있다고 한다면 job을 끝내기 위해서 자원을 어떻게 활용하는지 한번 살펴 보도록 하자.


총 12라는 시간동안 4단계로 이루어진 1개의 complete job을 6개를 수행했고 이때 idle 상태로 42가 존재한다. 즉 총 96 unit(12x8)중 50%가 idle이며 총 working amount는 6된다. NGS로 이야기 한다면 총 12시간 동안 6개의 샘플이 분석 완료 된 것이다. 이것이 현재 NGS Big Data 분석시 job scheduler가 동작하는 방식이다.

이제 아래 그림처럼 일하는 방식의 smart/intelligent하게 변경해서 각 job들이 다음 단계에 빈 node를 찾아서 들어가게 되면 9시간내에 6개의 샘플을 분석 완료 할 수 있다. 뿐만 아니라 위와 같이 12시간 동안 일을 하게 된다면 기존 6샘플 보다 2개 더 많은 8 샘플을 분석 가능하게 되며, 시간이 흘러 가면 갈수록 분석할 수 있는 샘플 수는 늘어나게 된다.



이번에는 약간 주제를 바꾸어 보도록 하겠다. 그러면 어떻게 NGS 데이터를 분석시에 어떻게 parallism을 구성하는냐이다. 기본적으로 S/W상에서 multi-thread를 지원하도록 하는 방법과 Map/Reduce 방식(human의 경우 chromosome이 23개 이므로 23으로 scatter하고 1개의 결과로 gather하기에 너무 좋다. Map/Reduce가 어떻게 데이터를 나눌지에 대한 답이 bed파일에 명시되어 있지 않은가!!)을 사용하는 것이다.

예를 들어 bwa와 같은 경우 reference에 fastq를 split하여 map/reduce를 구현하면 된다. snp calling의 경우도 염색체별로 또는 exome의 경우 bed파일을 적당히 나누어 map/reduce를 구현하면 된다. 즉 일반적인 job을 제출하면 중간에 wrapper가 어떠한 방식으로 유전체 데이터를 split할 지를 정의하고 단순히 foreach를 통해 job을 split하여 처리하고 이를 merge하면 된다.

지금까지 2가지 방법에 대해서 NGS 데이터 분석하는데에 자원을 효율적으로 사용할 수 있는 방법에 대해서 살펴봤다. 이러한 미들웨어가 구축되어 한정된 자원을 효율적으로 사용할 수 있도록 하는 것이 이제 절실히 필요한 시점이다.

참고문헌
Ayrris Intelligent Scheduling: Getting the Most from Your Infrastructurehttp://bit.ly/MGjLdI
Extending the Galaxy protal with parallel and distributed execution capability http://bit.ly/1cw7ke1
A primer on parallelism with the GATK http://bit.ly/1mxozCc
저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2014.02.21 10:33
Currently 댓글이 없습니다. comments want to say something now?
제목은 "과학계산"이라고 했으나 여기서는 "유전체 관련"이라고 한정지어 이야기를 하겠다. 왜냐고 그건 내 마음이니까. 요즘 국내에서도 많은 사람들이 자신의 연구에 클라우드를 사용하기 시작했다. 클라우드를 사용하기를 원하는 사람들 중 다음의 상황이 가장 많다.

빠른 시간내에 분석 결과를 내고 싶다.
대부분의 사람들은 샘플을 수집하고 이를 시퀀서와 같은 장비를 통해 데이터를 생산해 낸다. 즉, 분석할 데이터셋트가 만들어진다. 여기서 문제가 발생한다. 각종 연구에 있어서 논문으로의 출판까지 비교적 여유롭지 못하다는 것이다. 여기에는 많은 이유가 있을 수 있다. 가령 주어진 과제비에 대한 산출물(즉, 논문)을 내야하는 시기가 정해져 있다는 것이다.  어쩔 수 없는 이유들로 인해 데이터 생산까지의 시간을 일정내에 처리하지 못한 경우 이제 마지막 남은 카드는 분석을 최대한 빨리 진행하는 것이다.

"자. 내 데이터가 100만큼 있소, 1주일내에 가능하겠소." 물론 나의 대답은 "yes"이다. 물론 "yes"라는 대답은 단순히 클라우드 자원이 있어서가 아니다.  단순히 클라우드 자원은 AWS나 MS의 애저, 그리고 HP의 클라우드 등 많은 public cloud들이 존재하며 이를 사용하면 된다?? 문제는 이러한 클라우드는 단순히 IaaS(즉, 하드웨어만 제공)라는 것이다. 클라우드를 이용한 계산(분석)을 위해서는 고려할 것들이 많이 있다.

클라우드 자원 생성하기 (레고 블럭 준비하기)
우선 클라우드내 각각의 자원을 생성해야 한다. 아래 그림처럼 서버(어떠한 OS를 사용할 것이며, CPU와 Memory 사양, 서버의 이름 등등), 디스크(용량은 얼마짜리), 네트워크 및 요금은 시간제/월정액 등의 사항들을 일일히 선택하고 자원을 준비해야 한다.


100대를 저기에 들어가서 클릭하다가 보면 손목이 아파서 죽을 수도 있다. 바로 이러한 것들을 프로그래밍으로 손쉽게 할 수 있도록 API 형태로 제공하는데, GenomeCloud는 이 API를 이용하여 해당 자원을 생성하게 된다.

설정 자동화 (레고 블럭 쌓기)
두번째로는 위에서 각각 생성된 자원들을  결합해야 비로소 연구에 클라우드 컴퓨팅을 사용 가능하다. 만약 100대의 서버를 사용한다면 100대의 사양을 선택하고 일일히 startup시킨후 서버에 disk를 장착하고 접속할 수 있는 ip를 제공하고 방화벽이나 포트포워딩 룰등을 적용해야 한다. 이런 설정하다보면 하루는 족히 걸리게 된다. 어디 그뿐인가?  분석에 필요한 기반 시스템소프트웨어(가령 스케줄러) 소프트웨어(가령 BWA) 및 reference data(가령 human ref.)를 각 서버에 설정해야 한다. 

이러한 것들을 서버 자동화 툴(Server Configuration Management)들이 존재하고 이는 클라우드라는 새로운 환경에 맞추어 설정 되어야 한다. 이러한 툴중에 chef라는 것이 있는데 이를 이용하면 클라우드내 수많은 자원들을 설치, 배포, 관리가 가능하다. 또한 클라우드를 제공하는 서비스 provider들도 이러한 것들을 손쉽게 하기 위한 서비스(가령 ucloud biz의 packaging) 또한 활용이 가능하다.

GenoeCloud도 고객의 요구사항에 따라 적절하게 컴퓨팅을 생성하는데 이러한 기술들을 사용한다. 100대의  바로 분석할 준비가 된 서버도 몇 분 안에 제공이 가능하다.  아래 그림은 서버(클러스터)를 생성할때 해주어야 하는 것들을 정의한 것이다. 각 기어모양의 박스는 step들이고 해당 step들을 마쳐야 비로서 ready된 분석환경이 만들어진다. 

 
아래 그림은 위의 step중 하나의 세부 정의를 보여준다. 간단히 디스크를 추가하고 사용할 수 있도록 설정하는 부분이다. 각종 에러 처리 및 명령어들이 복잡하게 설정되어 있는 것을 확인 할 수 있다. 저것들을 일일히 사람이 직접 몇 백대를 하다가는 죽을 수도 있다.


그들만의 노하우(커스텀 레고)
레고의 장점은 서로 다른 모델들을 조합해서 전해 새로운 모델을 만들 수 있다는 것이다. -hongiiv-

그냥 컴퓨터를 자동으로 만들고 엮어 놓아도 분석은 할 수 있다. 하지만, 단순히 그렇다고 한다면 굳이 우리(GenomeCloud) 유전체 연구자들에게 내세울 강점이 없다. 바로 연구자들이 AWS나 MS가 아닌 GenomeCloud를 사용해야만 하는 이유가 여기에 있다. "GenomeCloud의 강점은 세세한 기능과 유전체 분야 고객의 요구사항에 대한 많은 노하우를 가지고 있으며, 이를 기반으로 클라우드 컴퓨터를 제공한다는 것이다." 똑같은 100코어 800GB 메모리를 가진 클라우드 자원이라도 우리의 손을 거친 클라우드는 다르다는 것이다.

세세한 모든 노하우를 나열하지는 못하지만 간단히 다음과 같은 것들이 있을 수 있다. KT의 ucloud의 성능에 대한 근거 데이터를 가지고 있다는 것이다. 각 분석 작업에 알맞는 최적화된 클라우드 벤치마크 데이터가 그것이다. 당연히 좋은 사양의 클라우드 자원이 좋다. 하지만, 좋은 사양일 수록 가격 또한 올라가기에 이에 대한 적절한 절충안을 찾아야 한다는 것이다. 두번째로 유전체 데이터 분석에서 있어서 각 알고리즘에 따른 적절한 클라우드 자원의 구성이다. reference data의 경우 분석시 메모리에 적재되어 활용되고 또한 이들을 파일 사이즈를 무시하지 못한다. 따라서 이러한 ref data만 따로 모아 제공하여 스토리지 자원을 절약하고 분석 결과를 temporary 디스크를 사용하는 경우 로컬 디스크를 사용하게하는 한편 OS의 temp를 사용하는 경우 자칫 용량문제로 소프트웨어가 정지하는 일이 발생하는데 이를 미연에 방지한다. 이러한 특징을 분석하여 총 4계층의 스토리지를 구축한다. ref data, temporary result, final result, 장기저장의 용도에 따른 스토리지를 구성하고 이를 적용하는 것이다. 이외에도 많은 것들이 고려되어야 시간과 비용면에서 유리하도록 할 수가 있다.

결론
클라우드를 이용한 과학계산에 있어서 단순히 클라우드 서비스를 이용한다는 것외에도 고려할 사항들이 많다. 사용자와 클라우드제공자와의 간격을 좁혀주기 위해서 해외에서는 cycle computing과 같이 이들을 서로 연결해주는 회사도 있다. 몇백에서 몇천대를 한꺼번에 사용하는데에 있어서 자칫 실수라도 한다면 엄청난 비용을 물어야 하기 때문이다. 저 분석 잘못했으니 클라우드 사용비용 안낼거에요. 라고 하고 싶겠지만, 당신은 이미 분석결과를 냈던 안냈던 클라우드 자원을 사용한 후이고 그에 대한 비용을 지불해야 하기 때문이다.

물론 클라우드에 대한 많은 지식과 경험이 있다면 필요가 없는 것이겠지만, 그런것들은 우리에게 맡겨두고 당신은 연구에만 몰두하면 된다.

저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2014.01.25 14:53
Currently 댓글이 없습니다. comments want to say something now?
기쁨은 나누면 배가 된다는 옛말이 있습니다. Bioinformatics 분야에도 이말이 적용되는데요. 바로 그 나눔의 핵심에는 클라우드 컴퓨팅이 있습니다. 무슨 말이냐구요.

DNANexus와 Baylor의 클라우드 기반 분석 
DNANexus라는 클라우드 기반의 NGS 분석 업체와 Baylor 의대 (BCM)의 이야기입니다. 바로 ASHG에서  DNANexus와 BCM의  Human Genome Seuqencing Center (HGSC)는 14,000명의 WGS와 WES를 통해 심장질환과 노화에 대한 유전적 영향을 연구를 위한 클라우드 기반의 협력 분석 시스템 프로젝트를 공유했습니다.

텍사즈주 휴스턴의 BCM

Cohorts for Heart and Aging Research in Genomic Epidemilogy (CHARGE) 컨소시엄 중 하나인 BCM은 프로젝트에 참여하는 300여명의 연구자들이 440 TB에 달하는 결과데이터와 파이프라인을 클라우드를 이용하여 공유하는데 DNANexus와 Amazon을 사용한 것입니다.

언젠가 논문에 나오는 상당수의 Bioinformatics software와 database가 제대로 유지되지 않고 사라져간다는 이야기를 들은적 있습니다. 한번 생각해 보면 대학원시절 만든 소프트웨어가 그 당시 연구를 위해 사용되고 이제는 더 이상 소스코드조차 찾을 수 없는 상황인것을 경험한 적이 있을 겁니다.

Mercury & CSSANDRA NGS Pipeline
BCM은 Mercury라는 오픈소스 소프트웨어 툴들인 BWA, GATK, SAMTools, Picard등으로 구성된 파이프라인과 Casandra라는 annotation시스템을 구축하고 이를 DNANexus와 함께 클라우드에 통합하는 작업을 수행합니다. 그결과 CHARGE 컨소시엄에 참여하는 연구자들은 신속하게 클라우드 상에서 10,000 이상의 엑솜과 3,700개 이상의 WGS를 분석에 사용했고, 분석을 위해  시간으로 따지면 총 2.4 million의 코어를 사용하고, 분석 기간중 최대 사용량은 자그마치 20,000이상의 코어를 사용했다고 합니다. 물론 그 결과를 즉시  연구자들과 공유하는 것은  기본이구요.

DNANeuxs에 공개된 HGSC의 Mercury 엑솜 분석 파이프라인
나같은 사람도 어렵지 않게 잘 다듬어진 최신의 파이프라인을 사용가능해지는 시대 

현재 HGSC의 Mercury와 CASSANDRA는 BMC Bioinformatics에 투고 예정이며, 얼마전 NEJM의 "Clinical Whole-Exome Sequencing for the Diagnosis of Mendelian Disorders"라는 논문에서 엑솜시퀀싱을 이용한 clinical diagnosis에 사용되기도 했습니다.
 
CSSANDR의 Annotation/filter에 사용되는 데이베이스 목록

Bioinformatics 산학협력 모델
DNANexus는 지속적으로 BCM과 함께 클라우드 상에서 Mercury를 유지하고 발전하는데  서로 협력하고 또한 일반 고객들에게 무료로 Mercury  파이프라인을 제공할 수 있게 된 것이죠. 

BCM이 속한 CHARGE 컨소시엄 연구자들은 방대한 데이터를 분석/공유할 수 있는 지속가능한 클라우드 기반의  인프라를 얻고,
DNANexus는 자사의 고객에게 최신의 NGS 분석 파이프라인을 제공
DNANexus의 고객들은 이런저런 설치나 설정없이 파이프라인을 사용 가능

가끔 연구하시는 분들을 보면  파이프라인의 무슨 자기들만의 노하우나 무슨 보물인듯 생각하시는 분들이 있습니다. 속을 들여다 보면 99%는 여기저기 오픈된 툴들의 조합인데, 어디서 배워왔네. 이건 어쩌구 저쩌구 솔까말 내눈에 걍 암것두 아니거등요. 요즘 오픈소스로 운영되던 툴들이 자꾸 상업화되고 점점 이쪽이 상업화되는 상황에서 베일러의대와 DNANexus의 행보는 진정한 연구와 서로 윈윈하는 산학협력이 뭔지를 보여주는 좋은 예라고 할 수 있겠습니다.


능력있는 연구자들이 기본뼈대를 내놓고 회사는 이를 대량으로 분석할 수 있도록 변형하고 또한 이것이 지속적으로 운영되도록 유지보수하고, 단순히 공적인 자금이 투여되는 것보다는 회사가 끼어들어야 어느정도 더 잘 발전하고 또한 그것이 시대의 흐름이라고 생각되어집니다.

연구자 여러분 GenomeCloud의 문은 활짝 열려 있다는 것!!! ㅋㅋㅋ 기억해 두세요.
저작자 표시 비영리 동일 조건 변경 허락
신고
Software enginner of GenomeCloud. Covers bioinformatics, computational biology, and life science informatics.
Posted in : 빅데이터분석 at 2013.10.29 01:47
Currently 댓글이 없습니다. comments want to say something now?

티스토리 툴바