단맛만좋아요

프롬프트 변경하기

hongiiv — Thu, 19 Jun 2025 09:50:29 +0900

oh-my-zsh와 conda 사용시 프로프트의 맨 처음에 virtual environment에 대한 정보(base)가 2번 나온다. 하나는 oh-my-zsh 테마에서 설정한 것이지만, 맨처음 정보는 conda에서 붙여주는 것이다.

정보가 중복되니 하나는 삭제한다.

conda config --set changeps1 false

iTerm2의 경우 맨 처음 점()이 프롬프트에 나타나는데 이는 설정의 "Show mark indicators"를 해제하면 점이 사라진다.

끝,

아이폰 집중모드에서 위치 정보가 작동하지 않는 경우 사용하기

hongiiv — Tue, 12 Apr 2022 22:39:34 +0900

갑자기 4년여동안 아이폰8을 쓰다가 13으로 변경하면서 집중모드(focus)를 사용하기로 결정하고, 특정 지역, 구역에 진입하면 집중모드를 실행하도록 설정 하기로 했다.

예를 들면, 사무실에 도착하면 지정된 알림만 설정하여, 각종 앱에서의 push 알람을 무시하도록 하여 일에 집중(?)하도록 말이다. 여기서 잠깐, 지오펜스(Genofencing, Geography + Fence)는 실제 위치에 기반여 가상의 경계(fence)나 구역을 만드는 것으로 사용자가 울타리에 출입을 알려 주는 것으로 아이폰 집중모드의 위치기반 설정은 지오펜스를 통해 특정 위치에서의 앱 액세스를 허용 또는 제한하는 것이다.

하지만, 어쩐일인지 iOS15의 집중모드에서의 위치(location) 기반의 알림이 작동하지 않았다. 구글링을 통해 각종 iOS의 위치 관련 서비스를 enable 시켜도 여전히 해당 위치에서 집중모드는 활성화 되지 않는 경우, 화면 아래의 슬라이더를 움직여 앞서 말한 지오펜스로 가상의 경계의 크기를 조절한다. 슬라이더를 오른쪽으로 움직이면 가상의 경계가 확대가 되는데, 작은 경계에서 좀 더 큰 영역으로 경계를 확대하다 보면 집중모드가 활성화되는 것을 확인할 수 있다. (울타리의 크기를 변경해 봐라, 좋은 위치?라면 펜스가 작아져도 잘 작동할테지만, 어떤 이유에서든 펜스가 커져야만 될 수도 있다)

실내에 있거나 여러가지 해당 지역의 상황에 의해서 지오펜스를 너무 타이트하게 설정하게 되면 활성화가 되지 않으니 슬라이더를 천천히 움직여 가면서 해당 지역에 알맞는 지오펜스를 설정하기 바란다. 그래도 안된다면, 그냥 매뉴얼로 집중모드를 설정해 사용해라.

집중모드의 지오펜스를 활용한 자동화

iOS의 자동화에서 지오펜스를 이용하여 위치를 설정하는 경우, 실행 전에 묻기를 비활성화 할 수 없다. 즉, 자동화에서 위치정보를 사용하는 경우 항상 자동화 여부를 실행 전에 묻기 때문에 반자동화가 된다. 이때, 집중모드의 지오펜스를 사용하면 되는데, 자동화의 조건을 특정 집중모드가 켤 때(해당 집중모드는 특정 위치에 활성화 되도록 설정된) 실행하면 묻지도 따지지도 않고 해당 위치에 진입하면 자동화가 수행된다.

필자의 경우 집 근처 몇백미터 전에 진입하면 집중모드를 설정하고, 해당 집중모드가 실행되면 아내에게 "집 근처 도착했어요." 라는 문자 메세지를 보내도록 자동화를 설정해 놓았다. 아내는 메세지를 통해 내가 집에 거의 도착했다는 사실을 알고.... -.- 여기까지...

파이썬을 이용한 개인유전체 분석

hongiiv — Tue, 15 Dec 2020 20:55:08 +0900

몇년전 개인유전체 데이터가 보편화 되면 자신이 직접 자신의 유전체 데이터를 분석(해킹)할 수 있도록 가이드를 해줄 책을 하나 만들고자 했다. 옛날옛날부터 블로그에 끄적였던 내용들을 정리할겸,, 겸사겸사 이제 책 만들기에는 여러가지 상황상 힘들것 같고, 몇년동안 다른일들 때문에 돌보지 못했던 내용을 하나씩 풀어볼까 한다.

요즘에는 국내에서도 DTC(소비자직접거래) 방식의 유전자 검사를 통해 혈통분석이라는 이름으로 자신의 조상(ancestry)정보 등을 확인할 수 있는데, 오늘은 이와도 연관된 맛보기 챕터로 "인구 집단 비교" 부분을 공개한다.

Demo chapter3 from Hong ChangBum

그럼 이만, 뿅

정밀 종양학 텍스트마이닝(1) - 문헌에서 변이정보 추출하기

hongiiv — Tue, 15 Dec 2020 15:29:22 +0900

내가 특정 암(또는 질병)에 대한 변이를 모아 놓았다고 할때, 해당 변이가 언급된 논문을 항상 최신으로 업데이트 해주는 경우 해당 변이가 해당 질병에 어떠한 영향을 주는지에 대한 정보를 항상 지켜볼 수 있게 된다. 더 나아가 해당 논문에서 언급된 변이를 논문을 보고 manual curation을 거쳐 knowledge base화 하는데에도 도움을 줄 수 있다.

다음은 BRCA Exchange로 BRCA1/2 mutation의 pathogenicity 정보를 제공하는 데이터베이스로 mutation을 클릭하면 다양한 정보와 함께 해당 mutation이 언급된 논문(제목, 저자, PMID, 해당 mutation이 언급된 본문 내용) 정보를 함께 제공한다. 아래 변이는 BRCA1의 L1750P 변이로 ClinVar에 지금까지 submit된 내용은 P(athogenic) 3건, LP(likely pathogenic) 3건, VUS가 1건으로 나온다.

이러한 경우, 일반적으로 population frequency등 해당변이의 여러정보를 기반으로 ACMG 가이드의 룰에 따라 변이의 pathogenicity를 판단하지만, 위에서 언급한 문헌을 보면, 해당 변이가 언급된 논문들이 대부분 한국인(Korean)을 대상으로 하는 연구에서 해당 변이가 VUS가 아닌, pathogenic이라는 논문들이 꾸준히 언급되고 있다.

ACMG 가이드라인에도 'reputable source'라는 criteria가 존재하기 때문에 기존의 rule에 해당 criteria를 적용하는데 적어도 한국인을 대상으로한 검체에서 나온 변이라면 문제가 없다.

그럼, 실제 이러한 것을 어떻게 구현할 것인가에 대해서 알아보도록 하자. 우선 다음의 각 단계를 적절한 툴을 이용하여 진행한다.

1) 문헌 crawl 단계

모든 텍스트 마이닝이 마찬가지겠지만, mining할 대상을 수집하는 단계로, 여기서는 pubmed를 기반으로 crawling하게 되며, 직접 크로링할 수 있도록 구현해도 되지만, pubmed에서 검색하고 실제 PDF 형태의 논문과 excel 및 기타 여러 형식의 supplement를 각 논문별로 해당 논문 site에 가서 가져오는것을 일일이 구현하는건 만만치 않다. 이 생고생을 이미 구현한게 있으니 pubMuch (github.com/maximilianh/pubMunch)로 지가 알아서 각 논문 site에서 pdf 등을 다운로드 하고 이를 text로 변환까지 진행하여 crawling을 수행한다.

또 하나 눈여겨 보아야 할 project중 하나는 BioC 프로젝트(bioc.sourceforge.net/)로 biomedical text processing에서의 상호운용성을 위해 XML 형태로 문헌을 표현한다. 더 나아가 NCBI에서는 BioC API for PMC(www.ncbi.nlm.nih.gov/research/bionlp/APIs/BioC-PMC/)를 운영중인데, PubMed Central(PMC)에서 open access 가능한 문서를 아예 BioC 포맷으로 만들어서 제공하기도 한다. PubMed에서 문헌 검색을 하다보면, PMC full text free라는 딱지가 보이면서 논문을 free로 확인할 수 있는걸 자주 보았을 것이다.

2) Crawling 데이터를 text로 변환

앞서 이야기 했듯이 모아온 문헌 정보는 pdf, excel, word 등 다양한 포맷으로 제공되기 때문에 이들을 모두 text 포맷으로 변경해야 하며, 이때 앞서 언급한 pubMuch가 이 부분을 담당하고 있다. 물론 BioC 포맷으로 문헌 정보를 다운로드한 경우 이과정이 불필요하다.

3) Text에서 변이 문구 찾기

이제 여기서부터는 머리좀 굴려야 한다. text에서 변이를 표현하는 단어를 찾아야 한다. 일반적으로 ACMG 가이드라인에서는 HGVS nomenclature를 이용하여 변이를 표현하라고 하지만, 이는 어디까지나 clinical report에 한정된 이야기로 논문에서야 변이를 어떻게 표현하는지에 대한 명확한 표준(가이드)이 존재하지 않는다. 아래처럼 하나의 변이를 표현하는데 있어서 genomic position으로 표현하는지? 이것도 reference 37인지? 38인지? hgvs nucleotide? or Protein인지? protein change는 1-letter인지? 3-letter인지? rs번호를 사용하던지 지맘대로 논문에 표시할 수 있는것이기에.... 이 부분도 마찬가지로 정규표현식 등 다양한 방법으로 텍스트내 변이를 표현하는 부분을 찾는 것을 pubMuch가 해주고 있다.

4) 변이 표현 방식(hgvs) 맞추기

genomic position <->RefSeq(NM) <->Ensembl(ENST) 간의 변환이나 hgvs.p <-> hgvs.n 간의 변환 뿐 아니라 variant normalization(left or right align) 등을 고려하여 논문에서 언급된 변이를 최종적인 hgvs 형식으로 모두 깔맞춤해 놓는다.

5) 기존 db의 변이와 match하기

문헌의 변이를 hgvs로 맞추어 준비하고, 기존의 변이의 hgvs와 match 시켜 변이 db에서 변이를 검색하면 해당 변이가 언급된 문헌을 보여주어 최종 마무리한다.

참 쉽죠,,

덧) brca1/2 검색어로 한정지어 pubmed 검색결과를 crawling 돌려 놓으면 몇일에 걸쳐 해당 논문을 crawling하게 된다. 물론 crawling한 결과의 용량도 무시못한다. 따라서 이러한 crawing 작업은 여러 노드에 분산하여 실행하는 방법을 권하며, 주기적으로 crawling 작업을 수행하도록 하여 crawling 결과를 update하도록 한다.

도커 entrypoint 회피 및 스크립트 killed

hongiiv — Fri, 11 Dec 2020 17:17:53 +0900

도커 entrypoint로 지정된 스크립트(명령어)를 실행했는데도 한참 후 결과가 리턴되지 않는다면,

Killed,,, 프로세스를 강제로 kill했을 수 있다.

1) entry point를 실행하지 않고 bash로 접속한다. 도커 실행시 --entrypoint /bin/bash 옵션을 주고 도커 이미지로 진입한다.

2) 스크립트를 도커 이미지 안에서 실행해본다. 스크립트 실행되다가 Killed 가 나오면 해당 스크립트를 실행하면서 리소스를 너무 잡아 먹기 때문에 걍 linux에서 해당 process를 kill해버린 경우다.

3)그렇다면 도커 설정에서 CPUs, Memory, Swap을 올려라!

4) 다시 스크립트를 실행하면,, 끝

NGS 데이터 평가하기

hongiiv — Fri, 4 Dec 2020 22:58:54 +0900

얼마전 NIST에서는 RM(Reference Material) 8393을 발표했습니다. RA는 말 그대로 표준이 되는 물질이죠. 이 표준물질은 Human DNA인데요. 그냥 DNA가 아니라 Whole-Genome Variant를 평가할 수 있는 표준물질입니다. 즉 이 DNA의 vaiant들을 모두 정리해 놓았다는 것입니다. 따라서 NGS를 이용하는 여러 분야에서 다양하게 사용될 수 있습니다. 그럼 어떻게 사용될 수 있는지 한번 볼까요?

Variants 평가 시나리오

Variants의 평가는 서로 다른 장비간 또는 서로 다른 파이프라인간에 비교하는데 사용되거나 표준물질에서 이미 정의된 variants와 직접 장비/파이프라인 통해 생성된 데이터를 서로 비교할 수 있습니다.

Validate Pipeline

당신의 연구소나 업체에 NGS 장비가 있는 경우 우리 연구소에서 생산하는 NGS 데이터의 품질이 항상 일정하고 또한 좋다는 것을 입증해야 할 때 사용할 수 있습니다. 정기적으로 RM 8393으로 시퀀싱을 수행하여 당신의 연구소/업체의 서비스 품질을 정량적으로 체크 할 수 있게 됩니다. RM 8393는 우리가 흔히 알고 있는 NA12878이라고 불리는 미국 Utah의 European Ancestry의 가계(CEPH 1463)의 여자입니다. 아마 이 샘플은 여러 논문에서 언급되고 있으며, SRA에도 다양한 플랫폼으로 생산된 데이터가 존재합니다.

이미 많은 연구가 되었고 가계 데이터까지 존재하기 때문에 NGS에서 발생하는 에러 등을 확인할 수 있다는 여러 장점으로 인해 NIST에서는 이 샘플을 표준 물질로 선정하게 됩니다. 이 표준물질의 variant들은 현재 버전 2.19까지 나와 있으며 ftp://ftp-trace.ncbi.nih.gov/giab/ftp/release/NA12878_HG001/latest/ 사이트에서 직접 받으실 수 있습니다. Variants 정보를 포함하는 VCF 파일과 highly accurate genotype call 부위에 대한 BED 파일을 각각 제공하고 있습니다.

Variants Evaluation

연구소/업체는 처음 NGS 장비를 셋팅한 후 RM 8393으로 시퀀싱을 수행하고 난 후 위의 VCF 파일과 서로 비교를 통해 평가를 수행합니다. 동일한 샘플로부터 생산된 variants므로 precision이나 sensitivity가 높게 나와야겠죠. 우선 두 데이터(평가의 기준이되는 baseline 또는 benchmark set 데이터와 평가의 대상이 되는 test set)는 모두 동일한 reference location을 사용해야 합니다. 그런데 문제는 단순히 두 variants를 비교하는데에도 여러 문제가 발생한다는 것입니다. repeats, homopolymers, multiple-nucleotide polymorphisms 등등 고려해야 할 것들이 많다는 것이죠. 바로 이부분에서 이러한 문제들을 dynamic-programming 알고리즘을 사용하여 좀 더 객관적인 비교를 수행할 수 있는 툴로 RTG tools가 있습니다.

Pipeline Benchmark

Benchmark set과 Illumina 장비를 통해 생산된 fastq 파일의 Broad의 Haplotype Caller를 이용한 파이프라인으로 분석한 결과와의 비교입니다.

이번에는 Haplotype Caller 대신 성격이 유사한 freebayes를 이용한 파이프라인 분석 결과 입니다.

이번에는 아예 BWA 대신 novoalign과 HC를 이용한 결과입니다. novoaligner는 유료입니다. aligner 하나 바꿨을뿐인데, FP와 FN이 적당한게 무엇보다도 TP도 가장 많네요.

그럼 이번에는 novoalign과 freebayes의 조합을 보겠습니다. 엥?? bwa와 freebayes의 조합과 같은 결과입니다.

결론적으로 novoalign과 HC의 조합에서 좋은 성능을 보이지만, freebayes는 novoaling이건 bwa건 같은 성능을 보임니다. 즉 novoalign은 HC의 알고리즘 상에서 뭔가 좋은 성능을 보일뿐입니다. novoalign이 좋긴합니다만 freebayes에서는 그 좋은것이 뭔지는 모르겠지만 좋은 장점을 발휘하지 못합니다.

어떤가요? 이렇게 표준물질은 여러 파이프라인의 성능을 비교하는데 사용될 수 있다는 겁니다.

바이오마커와 정밀종양학(precision oncology)

hongiiv — Fri, 4 Dec 2020 22:53:52 +0900

문헌데이터의 중요성

생물학 문헌 데이터들은 유전자, 단백질(Protein), 화학 성분(Chemical compound) 등 질병 관련 연구에 있어서 중요한 내용을 포함하고 있만 데이터의 양이 방대 하고 산재되어 있어, 연구자들이 일일이 모든 문헌 데이터 를 확인하는 것은 거의 불가능하다. 정밀종양학에 한정하여 환자의 diagnostic, prognostic, predisposing, drug response marker와 gene, variant와의 관계로 한정하여 보면,

1) BRAF V600E와 관련된 논문은 pubmed에서 2004년 5건에서 2017년 454건으로 증가

2) Oncology trial(임상시험)에서 biomarker를 이용한 시험은 전체 시험대비 2000년 ~15%에서 2018년 ~55%로 증가

Oncology 관점에서 텍스트 마이닝이 해결해야 할 실용적인 문제들

1) 환자에 대한 맞춤치료를 통한 치료의 개선을 위해서는 진단, 예측, 소인 및 약물 반응 마커에 대한 지식이 필수적으로 몇몇 knowledgebase(Cancer Genome Interpreter, CIViC, JAX-CKB, MyCancer Genome 등)들이 존재한다. 이러한 KB들은 curator에 의해 대부분 유지 관리되고 있으며, 이들이 curation하는데 있어서 텍스트 마이닝을 통해 도움을 줄 수 있다. 아래 이미지는 텍스트마이닝을 통해 문헌에서 gene, drug, disease, mutation 등의 term을 자동으로 tagging해서 보여준다.

이러한 term의 entity를 추출하여 다음과 같이 정리된 형태로 제공이 가능하다.

2) 이러한 문제는 앞서 설명한 임상시험의 biomarker에도 적용가능한 문제로, 바이오마커 임상시험 데이터는 구조화되어 있지 않으며, 바이오마커에 대한 설명 및 표준화가 부족하다. 이러한 바이오마커 정보는 임상시험에 대한 설명(general trial descriptions), 임상시험 포함,제외 기준(inclusion/exclusion criteria), outcome measures 또는 다른 위치에서 바이오마커의 사용을 언급할 수 있으며, 동일한 바이오마커를 설명하기 위해 다른 이름이나 두문자어를 사용할 수 있기 때문에 더 복잡해진다. 아래 그림은 현재 recruiting중인 breast cancer의 HER2 Negative 마커에 대한 임상 시험 목록을 보여준다.

텍스트 마이닝과 머신러닝을 통한 해결

텍스트 마이닝은 문헌 데이터에 나타나는 단어들을 분석하여 필요한 지식을 추출하는 방법론으로 생물학적 문헌들로부터는 다음과 같은 것들을 추출할 수 있다.

1) 유전자명, 유전변이(gene variants, CNAs, expression alterations, functional events), 단백질명 등과 같은 생물학적 개체(entity)를 추출하는 방법

2) 이러한 개체들 사이에 존재하는 관계(relationship)를 추출하는 방법

3) 개체들 사이의 관계를 네트워크(network)로 구축하는 방법

그럼 다음시간에 실제 생물학 문헌 데이터로 부터 텍스트 마이닝을 통해 entity를 추출하는 방법에 대해서 알아보도록 한다.

Deep Genomics

hongiiv — Thu, 12 Jan 2017 07:53:02 +0900

누가 뭐래도 요즘 화두는 deep learning이 아닐까? 그렇다면 현재 genomics 또는 이와 관련하여 어떤 움직임들이 있는지 한번 알아보도록 한다.

유전질환 딥러닝 - Face2Gene

예전 칼 짐머의 "Game of Genomes"의 시즌1의 두번째 에피소드인 "깨어진 코드"편을 보면 이런 장면이 나온다. 칼 짐머가 자신의 염기서열을 시퀀싱 하기로 한후 보스턴의 브리검여성병원의 로버트 그린은 칼 짐머의 얼굴을 유심히 보는 장면이 나온다.

“전 지금 유전병에서 나타나는 얼굴의 특징을 찾고 있는 거에요” 브리검여성병원(Brgham and women’s hospital)의 로버트 그린이 말했다. “눈의 모양, 귀가 너무 낮게 있지는 않은지. 귀가 복잡하게 생기진 않았는지” 그린박사는 사무실을 앞뒤로 걸어보도록 했다. 나는 웨스트민스터 도그쇼의 테리어 같다는 느낌이 들었다. 몇몇 유전병은 걸음걸이에 숨겨져 있다고 그린이 설명했다.

유전병은 얼굴이나 걸음걸이 등에 숨겨져 있다는 것이다. 굳이 genome을 분석하지 않더라고 말이다. 바로 이부분을 실제 만든 서비스가 바로 "Face2Gene"이라는 앱으로 이들은 "smart phenotyping better genetics"라는 슬로건을 내걸고 있다.

사진을 올리면 딥러닝을 통해 눈꺼풀이 얼마나 좁은지? 귀는 얼굴에서 얼마나 낮은지? 등을 정량화하고 얼굴과 가장 가능성이 있는 증후군에 대해서 순위를 매겨 보여주는 한편 위의 그림처럼 히트맵을 오버레이 시켜 어떤 특징이 가장 일치 하는지를 보여 준다.

유전변이 발굴 딥러닝 - DeepVariant

얼마전 미 FDA에서는 NGS를 통해 생산된 데이터에서 얼마나 variant를 잘 찾는지에 대한 챌린지를 수행한적이 있다. SNP와 INDEL 두부분으로 나누어 미리 정답을 알고 있는 샘플의 FASTQ 파일을 제공하고 이를 참가자들을 알고리즘을 통해 분석된 결과와 얼마 일치하는지에 대해서 평가를 수행했는데 SNP 부분에서 1등을 차지한 곳이 베릴리 라이프 사이언스 (전 구글 라이프 사이언스로 구글의 지주회사인 알파벳의 계열사)가 1등을 먹었다.

바로 이 베릴리 사이언스가 variant를 찾는데 사용한 기법이 바로 딥 러닝 기법으로 기존의 GATK 같은 툴들이 베이지안 확률을 통해 찾는데에 비해 pileup 파일을 이미지화 하여 CNN(Convolutional Neural Network)를 이용하여 정확도를 높였다.

변이 해석 딥러닝 - Watson for Genomics

이미 왓슨은 국내에도 도입되어 운영되고 있는데 이는 Watson for Oncology로 NGS등을 통해 생산된 Somatic mutation (VCF 또는 MAF 파일) 이나 Copy number variation (log2 format)을 입력받는 genomics에 특화된 부분은 Watson for Genomics(Watson Genomics Advisor)로 현재 개발중에 있다.

최근 기사에서는 일루미나가 자사의 TruSight 170 패널을 통해 생산된 NGS 시퀀싱 데이터에 대한 해석을 Watson for Genomics를 통해 올해 안에 제공할 예정이라고 한다.

Watson for Genomics는 임상에 포커스된 결과들을 제공하게 된다.

List of Dysfunctional Proteins
IBM Developed Driver Score
Targeted Therapies

이외에도 Pathway Analysis, Drug Recommendation 정보를 제공한다.

결론

현재까지 genomics와 이와 관련된 부분에서 어떻게 딥러닝이 활용되고 있는지에 대해서 알아보았다. 이제는 환자의 유전체 데이터 생산전부터 딥러닝이 활용되기 시작하여 최종적으로 유전체 데이터를 분석하고 해석하는데에 딥러닝이 활용되기 시작되었다. 그렇다고 우리의 직업이 없어질 것인가? 이제는 좀 더 큰 시야를 가지고 이러한 딥러닝을 어는 부분에 적용할지와 함께 트레이닝 데이터에 대해서 어떤 종류의 데이터를 얼마나 어떻게 확보할지 그리고 어떻게 훈련 시킬지에 대해서 생각해봐야 할 것이다.

23andMe 재단장

hongiiv — Wed, 28 Oct 2015 21:25:50 +0900

국내 질병 예측성 유전자 검사 현황

지난 19일 "질병예측성 유전자 검사의 개선방안 공청회"가 진행되었다. 공청회의 질병관리본부의 질병예측성 유전자 검사의 관리에 관한 용역 결과에 대한 세션에서 의하면 유전자 검사를 6개의 카테고리로 나누어 관리하는 방안으로 카테고리 1~4까지는 기존의 유전자 검사에 해당하며 카테고리 5와 6의 경우는 다음과 같은 기준으로 나뉘어 관리하도록 하고 있다.

질병관리본부의 질병예측성 유전자 검사 관리 용역 결과 유전자 검사 분류

이에 유전체기업협의회의 경우 기존 검사와 더불어 질병예측성 유전자검사와 웰니스 유전자 검사의 카테고리로 나누어 관리하고자 하고 있다. 특히 웰니스 유전자 검사의 경우 DTC를 허용하는 것을 골자로 하고 있다.

유전체기업협의회의 유전자검사 분류 방안

미국의 질병 예측성 유전자 검사 현황

미국의 경우 2006년 23andMe가 질병 예측성 유전자 검사를 DTC를 통해 시작한 이후 13년 FDA의 판매중지 명령에 의해 수행되지 못하는 실정이다.

다만, 최근 15년 2월 FDA는 이중 상염색체열성유전질환(autosomal recessive disorders)의 유전자 검사에 대해서 의료기관을 거치지 않고 일반 임신진단키드와 같이 일반인이 직접 구매하여 사용할 수 있도록 DTC를 허용했다. 정확히 지난 14년 6월 bloom syndrome이라는 상염색체열성유전질환에 대해서 FDA에 승인(clear) 요청이 있었고 이를 올해 2월 승인 후 10월달에야 decision summary가 공개되었다.

FDA의 승인 내용은 해당 검사에 대해서 Class II로 분류하고 "Autosomal Recessive Carrier Screening Gene Mutation Detection System"이라는 기기타입(Device Type)과 PKB라는 상품코드(Product Code)를 부여하여 관리되는 한편 해당 승인과 더불어 상염색체열성유전질환은 의사를 거치지 않고도(DTC) PMA가 아닌 의견 수렴을 위한 30일간의 최소 부담의 규제만으로 제공이 가능하다는 것을 포함하고 있다.

지난2월 FDA의 승인 후 실제 서비스를 위한 decision summary가 이번달 릴리즈 되면서 23andMe는 발빠르게 웹페이지를 단장하고 새로운 서비스를 제공 준비를 하고 있다. 23andMe는 승인시 제출한 bloom syndrome외에도 36개의 상염색체열성유전질환(cystic fibrosis, sickle cell anemia, Tay-Sachs 등)에 대한 검사도 제공한다.

예측성이 아닌 유전질환의 보인정보

23andMe로서는 기존의 health라는 메뉴를 통해 질병예측성 정보를 제공하는 Health Risks와 Drug Response를 과감하게 현재로서는 포기 했지만, 기존의 health 메뉴중 하나였던 Inherited Conditions에 대해서는 FDA의 승인이라는 값진 선물을 받았다.

기본적으로 유전자 검사가 임상에 도입되기 위해서는 해당 검사를 이용함으로써 얻을 수 있는 이익과 위험도를 평가하는 임상적 유용성(clinical utility)이나 해당 질환을 정확하게 예측하고 검출하는 임상적 타당성(clinical validity)를 질병예측성유전자 검사가 만족할만한 수준이 아니기 때문에 우선 이를 만족할 수 있는 유전질환에 대한 승인을 시작했으나 점차 예측성 부분으로 승인을 확장할 것으로 보인다. 이번 승인은 23andMe로서는 어쩔 수 없이 유전질환이 타깃이었지만 어찌보면 기존의 분자진단 업체들의 밥그릇을 빼앗아 올 수 있는 기회가 된 것일 수도 있다. 뭐 이게 메인인 서비스들이 막강히 버티고 있고 어차피 23andMe는 보인자 정보가 메인은 아니니...

DTC로서의 Inherited Condition

이번 승인은 모든 유전질환이 아닌 자손에게 유전질환에 대한 risk를 물려 줄 수 있는지에 대한 검사로 현재 대부분은 한국인을 포함한 아시안에서는 그리 유용한 검사가 아니다. 따라서 국내에서 해당 서비스를 받는다 해도 그리 임상적 유용성을 만족할 만한 것은 아니지만( bloom syndrome만 보더라도 Ashkenazi Jewish에 대해서 107명 중 1명이 보인자로 0.93%며 Asian이나 African American에서는 0%) 다양한 인종이 존재하는 미국에서는 그 유용성이 클 수 있다고 할 수 있다. Anne Wojcicki도 부모중 한명이 Jewish로 그녀 또한 bloom syndrome에 대한 보인자라고 한다. 뭐 한때 부부사이였던 구글의 Sergey Brin도 부모가 Jewish로 유전질환에서 자유롭지 못했다. 아마도 이 서비스자체가 부부였던 둘의 자식에 대한 사랑은 아니었을까 한다. ㅋㅋㅋ

Bloom Syndrome

23andMe는 사업초기부터 Illumina의 chip을 사용(2008년 v1, 2011sus v3, 2014년 v4)하고 있으며 현재는 BeadChip v4 assay (Illumina HumanOmniExpress-23 format chip)을 사용하고 있다. 이 칩은 ~750,000 SNPs를 커버하고 있으며 약 200,000개의 custom markers를 추가(현재 할 수 있는 것으로 알려져 있다. 해당 칩에는 SNPs외에도 II와 DD, DI의 genotype을 가지는 deletion과 insertion 또한 확인이 가능하며 그 수는 대략 60여개에 달한다.

Bloom Syndrome은 BLM 유전자의 2281에서의 6-염기쌍결실/7-염기쌍 삽입 (rs113993962)의 BLM^Ash라고도 불리는 유전변이를 가지고 보인정보를 판단한다. 23andMe 형태의 genotype으로 보자면 "DI"인 경우는 보인자이며 "II"인 경우 bloom syndrome 환자 "DD"인 경우 정상이라고 할 수 있다.

Analytical performance 분석적 성능

FDA의 23andMe 서비스에 대한 decision summary에 따르면 23andMe는 FDA에 510(k) 드노보 프로세스를 진행하면서 6개의 셀라인을 가지고 analytical performance(찾고자하는 유전자형을 정확하고 믿을 만하게 검출하느냐)를 수행했다.

4 homozygous common (DD)

1 BLM^Ash heterozygous (DI)

1 BLM^Ash homozygous rare (II)

각 셀라인은 5일에 걸쳐 2곳(site1, site2)에서 각각 별도로 진행되었으며 이때 4개의 reagents와 3대의 별도의 Tecan, iScan 장비의 조함을 사용하여 진행하여 DD의 경우 360번 DI와 II의 경우 720번의 replicate를 수행했다.

각 site별 실험에 따른 정확성과 재현성(Precision/Reproducibility)

또한 이들은 Interference와 관련하여 Endogenous와 소고기가 포함된 음식 섭취, 소고기가 포함되지 않은 음식 섭취, 음료 섭취, 검씹기, 이빨닦기의 Exogenous Interference와 함께 흡연에 대한 Interference에 대해서도 analytical performance에 관한 내용을 제출했다.

이빨 좀 닦아 본 후(간섭에 의한) 재현성 - QC fail은 있어도 QC만 통과하면 정확함

Comparison Studies 비교 시험

타액을 통해 23andMe의 자체 Biobank로부터 genotyping된 총65샘플에 대해서 bi-directional sequencing을 통한 결과와 비교 시험 결과 DI(heteo)인 경우와 DD(homo)인 경우에 대해서 총5개 샘플은 QC에 fail되었으나 다시 시도해서 모두 genotyping과 동일한 결과를 얻었다.

Clinical Studies 임상적 시험

지금까지 본 바로 아무리 잘 잡아냈다고 하더라도 지금까지 봐온 BLM^Ash가 기존의 논문등의 근거가 부족하다면 이 검사에 대한 승인은 처음부터 재고려해보아야 할 것이다. 23andMe는 ACMG의 Ashkenazi Jewish decent에 대한 보인자 스크리닝 가이드라인과 Bloom Syndrome에서 BLM 유전자의 원인 변이라는 논문을 근거로 제시하고 있다.

Ashkenazi Jewish에서의 Bloom syndrome외의 다양한 유전질환에 대한 carrier frequency

결론

지금까지 살펴본 바와 같이 23andMe는 FDA의 승인을 받기 위해 기존의 의료기기들이 허가를 받기 위해 필요한 분석적 성능이나 임상적 성능 등 다양한 결과들을 제출하고 허가를 받았다. 비록 질병의 예측성 유전자 검사가 아닌 기존의 보인자 유전검사라는 틀에서 이루어지긴 했지만 이번 기회를 통해 23andMe는 FDA와 어떠한 관계를 가지고 어떻게 허가를 진행해야 할지에 대한 값진 교훈을 얻게 되었고 분명 이는 23andMe에게는 앞으로의 서비스 확장과 사업 진행에 있어서 큰 도움이 될 것이라고 생각한다.

23andMe는 질병 예측성 유전자 검사라는 카테고리(예전의 health 카테고리)를 잃었지만 아직도 Ancestry, wellness, traits의 정보와 함께 FDA의 승인된 보인정보(carrier status)를 얻었다.

국내에서도 카페인이나, 유당분해, 알콜분해 등의 웰니스에 관련한 유전자를 DTC로 풀어나가는 한편 체계화된 연구를 기반으로 규제기관과의 허가에 관한 이슈를 풀어나아갔으면 한다.

결함을 허용하는 의존성 있는 태스크의 관리

hongiiv — Tue, 13 Oct 2015 18:58:00 +0900

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

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

총 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

위 그림과 같이 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 등을 이용하면 쉽게 로그 파일을 처리할 수 있다.

BGZF (Blocked GNU Zip Format)

hongiiv — Wed, 1 Jul 2015 16:18:47 +0900

Random Access

BAM 파일의 경우에는 BGZF를 이용하기 때문에 원하는 곳으로 빠르게 access가 가능하다. 우리가 흔히 사용하는 GZIP (GNU ZIP) 보다는 압축효율 (압축했을때 용량)이 떨어지지만 random access가 가능하다는 잇점으로 인해 BAM 파일(BAM의 경우 재빠르게 자신이 원하는 position을 뷰잉하는데 많이 사용하기 때문)에서 사용하는 기술이다.

용량이 큰 텍스트 파일을 압축해 놓고 파일의 어느 부분이던지 랜덤하게 액세스 가능하기 때문에 그 활용도가 높은데 특히나 클러스터를 이용하는 경우 파일을 분할하는 등의 I/O 작업이 필요 없기 때문에 그 활용이 매우 높다고 할 수 있다. 여러 활용중 하나로 FASTQ 파일에 적용하여 사용하고 있다.

FASTQ 응용

일루미나는 Base Call을 수행한 후 기본적으로 GZIP을 이용하여 압축하게 되는데 이를 다음과 같은 명령으로 BGZF로 변환한다. 뭐 언뜻 보기에는 BGZF가 GZIP과 호환되기 때문에 이게 BGZF인지 확인해 봐야 한다. grabix 툴의 check를 이용하면 간단하게 알 수 있다.

# zcat TN1506L0327_2.fq.gz |bgzip /dev/stdin -c > TN1506L0327_2.fastq.gz
# /BIO/app/grabix/grabix check TN1506L0327_2.fastq.gz
yes
# /BIO/app/grabix/grabix index TN1506L0327_2.fastq.gz
# /BIO/app/grabix/grabix grab TN1506L0327_2.fastq.gz 1 10
@HWI-ST840:481:HVKTWADXX:1:1101:1213:1943 2:N:0:ATTGGCTC
GGTACCAGTACCATGCTGTTTTGGTTACTGTAGCCTTGTAGCACAGNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
+
BB@DFFFFFHHHHJJJJJIJJJJJIIJJJJIIJIJJJJJJJJIJJI#######################################################
@HWI-ST840:481:HVKTWADXX:1:1101:1986:1934 2:N:0:ATTGGCTC
ATATCTACACCACGCAAAGTGATGTGTAAGTGTGGGTGTTGCTCNCNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
+
@@CDDFFAHFFHHIIIIIIHHIHECDHIIEFHHHGI@DDGIIIG#########################################################
@HWI-ST840:481:HVKTWADXX:1:1101:1874:1947 2:N:0:ATTGGCTC
CCTAGGAATCCAACTTACAAGGGATGCGAAGGACCTCTTCAAGAAGNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

BWA 활용

이렇게 BGZF 포맷의 FASTQ 파일은 굳이 압축을 풀지 않아도 원하는 라인을 바로 확인이 가능하게 된다. 이렇게 되면 우리는 클러스터 노드에 다음과 같이 직접 파일을 분할 할 필요 없이 "grabix grab 파일명 start_line end_line"을 통해 다수의 노드에 BWA 매핑 작업을 분할하여 수행할 수 있다.

# bwa mem -M -t 7 -R '@RG\tID:1\tPL:illumina\tPU:1_2014-08-13_dream-syn3\tSM:syn3-normal' -v 1 GRCh37.fa <(grabix grab normal-1.fq.gz 20000001 40000000) <(grabix grab normal-2.fq.gz 20000001 40000000)

많은 생물학 데이터 FASTQ, FASTA, SAM, BED, XML, Tab 구분 파일 등등 모두 적용이 가능하며 다양하게 활용이 가능하다. 물론 여러개의 BGZF 파일을 압축해제 과정이 필요없이 하나의 BGZF로 묶어주는 방법 도 장혜식 박사의 블로그에 있으니 자신의 데이터에 적용해서 활용해 보기 바란다.

Python을 이용한 BGZF 헤더 다루기

RFC1952 문서에 정의된 GZIP에서 extra field를 활용하는 BGZF는 extra field의 두개의 subfield id에 각각 66, 67의 값을 가지며, EOF 마커로 "1f 8b 08 04 00 00 00 00 00 ff 06 00 42 43 02 00 1b 00 03 00 00 00 00 00 00 00 00 00"의 16진수를 가진다.

Python을 이용하여 파일을 읽고 BGZF 포맷이 맞는지 확인하는 코드를 작성해 보도록 하자. 대학원 시절 프로토콜 정의하고 구현하던게 갑자기 생각이 난다. 암튼 뭐 어쨌건간에 우선 파일의 첫번째 블록의 헤더 부분을 읽어오는데 기본 헤더와 함께 SI1,SI2의 extra subfield의 일부분을 읽는다. 읽어오는 부분은 총 14바이트 하나씩 출력해보면 위에 정의된 값들이 출력되는 것을 확인할 수 있으며, XLEN 부분은 총 6바이트가 extra subfield로 지정된 것을 확인 할 수 있다.

from struct import unpack

bgzf_file=open('TN1506L0327_1.fastq.gz')
header = bgzf_file.read(14)

id1, id2, cm, flg, time, xfl, os,extra_len, extra_id1, extra_id2 = unpack('<BBBBLBBHBB', header)

>>> from struct import unpack
>>>
>>> bgzf_file=open('TN1506L0327_1.fastq.gz')
>>> header = bgzf_file.read(14)
>>>
>>> id1, id2, cm, flg, time, xfl, os,extra_len, extra_id1, extra_id2 = unpack('<BBBBLBBHBB', header)
>>> id1
31
>>> id2
139
>>> cm
8
>>> flg
4
>>> extra_len
6
>>> extra_id1
66
>>> extra_id2
67

BGZF 파일의 EOF를 읽어들여 파일이 제대로 생성된 것인지를 확인해 본다. 이전에 언급했듯이 파일의 마지막 28바이트를 읽어들여 EOF 마커와 동일한지 확인한다. 왜 BGZF의 첫블록을 읽고 마지막 EOF를 확인하는지는 많은 데이터가 짤리는 경우가 많아서 확인 과정을 거친 후 진행하는게 건강에 좋아서랄까? ㅎ

>>> bgzf_file.seek(-28,2)
>>> eof=bgzf_file.read(28)
>> eof
'\x1f\x8b\x08\x04\x00\x00\x00\x00\x00\xff\x06\x00BC\x02\x00\x1b\x00\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00'

Split Reads

hongiiv — Fri, 26 Jun 2015 07:36:34 +0900

Split Read (SR)

Split Read(SR)는 하나의 read가 분리 (split)된 것으로, 여기서 분리는 read의 일부분이 reference에 align되고 나머지 일부분은 또 reference의 다른 부분에 align된 것으로 Chimeric Alignment라고도 한다. SR은 deletion, insertion, inversion, tandem duplication과 같은 structural variation을 찾는데 유용한 지표로 사용된다.

Identification of a deletion in an individual genome by split read analysis

SAM에서의 SR 흔적

SAM파일에서는 SR을 표시하는데 SA 태그를 사용한다. SA 태그는 Chimeric Alignment를 표시하는데 사용되며 앞서 말했듯이 하나의 read에서 일부는 "A" 위치에 align되고 일부는 "B" 위치에 align되는 경우에 사용된다. 이때 CIGAR String에는 H (hard clipping)나 S (soft clipping)과 같은 operation이 같이 나타나게 된다. Read ‘r003’이 각각 +/- strand로 reference genome 의 서로 다른 두 위치에 align된 경우 SAM 파일상에는 이를 각각 다음과 같이 표시한다.

r003 0 ref 9 30 5S6M * 0 0 GCCTAAGCTAA * SA:Z:ref,29,-,6H5M,17,0;
r003 2064 ref 29 17 6H5M * 0 0 TAGGC * SA:Z:ref,9,+,5S6M,30,1;

첫번째 라인에서 CIGAR string 5S6M은 5개 ‘gccta’는 5S, 나머지 ‘ AGCTAA’는 6M 으로 표시된다. 이때 S는 soft clipping (reference에 정확히 align되지 않은 부분으로 일반적인 D를 이용하여 deletion으로 표시하지 않는다. 왜나면 read의 일부가 또 다른 위치에 붙는 즉 clipping에 의해 split된 read이기 때문이다)이라고 하며 soft clipping된 sequence는 SEQ 상에 표시된다. 두번째 라인을 보면 똑같은 read이지만 ref genome의 다른 부분에 6H5M으로 align 된것을 확인할 수 있다. 6H는 6개의 sequence가 hard clipping 되었다는 것을 의미하며, 이미 같은 read가 한번 soft clipping되었기 때문에 그다음의 read는 hard clipping으로 처리되고 이때 SEQ 상에 clipping된 부분을 표시하지 않는다.

Non-overlapping base pair

Structural variation 분석에 있어서 이런 SR는 단순히 SA 태그를 지닌 read를 모두 사용하는 것이 아니다. 말그대로 read가 large deletion에 의해 둘로 split된 경우 split된 read는 서로 overlap이 되지 않고 정확히 sequence가 겹치지 않고 둘로 나뉘어져야 한다. 그러나 뭐 정확히 모든 read들이 그렇지 않을거고 암튼 그래서 SR만을 꺼내서 사용할 경우 SA 태그에 명시된 cigar와 서로 비교하여 두 chmeric read간에 overlap되 않는 non overlap이 일정 length 이상인 것만 추출하며 이때 기본적으로 20을 할당한다.

아래 그림은 36S54M (-)과 38M52S(-)로 서로 overlap되는 길이는 3bp이며, 첫번째 read 입장에서는 non-overlap length는 52bp, 두번째 read 입장에서는 36bp가 된다.

Max Split alignment count

위에서 살펴본 non-overlap length에 이어 SR을 찾는 옵션 중 하나는 하나의 read에서 얼마나 많은 split alignment (split-read mapping)을 허용할 것인가에 대한 것이다. 하나의 read가 split되어 여기저기 refrence에 덕지덕지 붙는다는 것은 말이 안되고 기본적으로 2군데 align되어야 이걸 SV의 흔적으로 생각할 수 있다. 따라서 기본값은 2로 지정된다. 최대 split 갯수를 확인하는 방법은 SA 태그에 split된 위치가 ';'으로 분리되어 보여지는데 이것을 가지고 read가 몇개로 split되었는지 알 수 있다.

if "SA:" in samTages:
if(len(samTages.split(";"))) <= 2:
print "Yes, split read"

Strand normalize for non-overlap base pair

서로 split read간의 overlap되는 base를 계산하기 위해서는 strand normalized 과정이 필요한데 strand normalized를 이해하기 위해서는 우선 paired-end 시퀀싱에서의 mapping에 대해서 알고 넘어가야 한다. 아래 그림처럼 SAM에서는 Reference 방향으로 모두 통일해서 SEQ를 표시하고 이것이 원래 FASTQ에서 reverse된 것인지는 flag에 0x10을 넣어 주어 이게 reverse된 것이라는 것을 알려준다.

Spirt Read가 SAM 파일에서 Read는 F(orward) strand로 매핑되고 SR은 SA 태그에 R(everse) strand ('-'라고 SA 태그에 표시됨)라고 표시되었다면 서로 겹치지 않은 부분(non-overlapping base pair)을 계산하기 위해서는 strand를 맞추어 준 후에 CIGAR string을 가지고 strand에 맞추어서 계산해야 한다.

Python을 이용한 구현

지금까지 우리는 Split Read라는 것의 정체를 알기 위해서 Soft/Hard Clipping, FASTQ 파일 포맷, F(orward)/R(everse) 등의 개념에 대해서 알아보았다. 이제는 우리는 이걸 코드로 표현해야 한다. 어려워말고 차근차근 따라와 주기 바란다. 여기서 사용할 코드는 python으로 진행하도록 한다.

우리의 구현할 프로그램의 목표는 SAM 파일을 입력받아 우리가 원하는 특정 Split Read만을 다시 SAM 포맷으로 출력하는 프로그램이다. 여기서 우리가 원하는것은 duplication reads는 뺀 나머지 read들 중 SA 태그가 존재하는 즉, split read에서 최대 split-read mapping이 2개이면서 서로 겹치지 않는 read가 20bp 이상인 것들만 출력한다.

Skeleton code

프로그램은 일반적으로 명령어를 실행하면 해당 명령의 help 페이지를 출력하고 이때 프로그램에서 사용할 수 있는 옵션을 보여주게 된다. 또한 명령어와 함께 사용되는 옵션에 대해서 처리할 수 있어야 한다.

#!/user/bin/env python
import ****

def 실제_수행할_메소드:
#split read 추출

class 데이터를_저장할_구조정의:
#실제_수행할_메소드에서 사용할 자료 구조 정의

def 부가적으로_필요한_메소드:
#실제_수행할_메소드와 별도의 부가적인 메소드 정의

def main():
#프로그램의 help 정보 표시
#프로그램의 옵션들(인자들) 처리
#실제 수행할 메소드 호출
실제_수행할_메소드(인자들)

if __name__ == "__main__":
sys.exit(main())

Command line options

처음으로 우리는 프로그램의 옵션과 도움말을 처리할 것인데, 이건 main() 메소드에서 처리한다. optparse의 OptionParser를 이용한다. 우선 usage에 프로그램의 설명, 간단한 사용법을 넣고 paser를 이용하여 옵션을 처리한 후 꼭 필요한 옵션이 누락된 경우 도움말을 출력하여 옵션을 설정하도록 권유한다. 필수 옵션이 있는 경우에는 실제_수행할_메소드를 호출하는 것으로 마무리한다.

아무런 옵션 없이 프로그램을 실행하면 다음과 같이 위에서 지정한 도움말과 프로램의 옵션이 출력된다. 여기서는 -i 를 필수 옵션으로 지정해서 해당 옵션 없이 프로그램이 실행되면 도움말을 출력하며, 옵션이 설정되어 있다면 메인 메소드인 extractSplitRead를 실행한다.

SAM 포맷 저장을 위한 SAM 클래스 정의

메인 메소드인 extractSplitRead를 정의 하기 전에 SAM 파일을 한줄한줄 읽어들여와 각 read의 정보를 저장할 SAM 클래스를 정의해 보자. 물론 한줄을 읽어 들여 split()을 이용하여 리스트에 넣어 사용해도 되지만 말이다. SAM 클래스는 SAM 파일을 한 줄 읽어 이를 탭으로 분리한 리스트 형태를 입력으로 받게 되며 SAM 포맷에 맞게 query, flag, ref, pos, mapq 등을 설정한다.

메인 메소드 작성

우리가 입력으로 받은 SAM 파일을 담을 SAM 클래스도 정의했다면, 이제 extractSplitRead라는 이프로그램의 메인이 되는 메소드를 정의하도록 하자. 이 메소드는 입력 파일, split 갯수, duplication 허락여부, 최소 오버랩길이를 인자로 받아 제일 처음 입력 파일을 한줄 읽어 다시 탭으로 구분한 리스트에 담아 이를 SAM 클래스에 넘겨준다.

이렇게 읽은 한줄이 duplicate read이지를 확인하고, SA 태그도 있는지를 확인하여 SA 태그가 존재한다면, split = 1 이라고 지정하여 split read임을 표시한다. duplication을 허용하지 않고 (includeDups==0), flag 값을 통해 "read is PCR or optical duplicate (1024)"가 표시된 read라면 해당 read는 skip (continue)한다. split read는 다시 SA 태그 부분을 좀 더 파싱하여 split read의 CIGAR string을 mateCigar 변수에 저장하고 strand 정보를 mateFlag 에 저장('-' strand는 16)한다.

Overlap 및 Non-overlap 길이 구하기

우리는 지금까지 SAM 파일을 읽어 해당 read가 split 된 read인지를 확인하고 해당 read를 SAM 클래스의 인스턴스로 만들고 split된 read의 CIGAR string과 strand 정보를 따로 보관하고 있다. 이제 마지막으로 하나의 read지만 split된 read가 서로 얼마나 overlap 되는지를 파악하는 것만 남았다. overlap되는 부분을 계산하기 위해 2개의 메소드 extractCigarOps, calcQueryPosFromCigar 메소드를 우선 정의한다.

extractCigarOps는 CIGAR string을 파싱하여 해당 read가 reverse strand (0x0010)인 경우 CIGAR string을 뒤짚어서 forward 형태로 만든 후 cigarOp라는 클래스의 인스턴스로 만든다. cigarOp는 CIGAR의 length와 operation을 가지게 된다. (ex, CIGAR string이 31S59M인 reverse strand의 경우 59M31S로 만들어 버린다) 이렇게 split된 read에 대해서 각각 readCigarOps와 mateCigarOps에 forward strand 형태의 CIGAR string의 정보가 담긴 cigarOp 인스턴스를 생성한다.

calcQueryPosFromCigar은 위에서 strand에 맞추어진 CIGAR를 입력 받아 각 read의 mapping된 start, end position과 전체 read의 length를 계산하여 queryPos의 인스턴스로 생성한다.

이제 위의 queryPos의 인스턴스를 가지고 두 read가 서로 overlap되는 곳의 length와 non-overlap되는 곳의 length를 구하고 non-overlap이 기본값인 20 이하인 경우만 해당 read를 split read로 인식한다.

결론

지금까지 split read가 NGS에서 어떠한 의미이고 어떻게 활용될 수 있는지 그리고 실제 프로그래밍으로 어떻게 구현하는지까지 모두 알아보았다. 기나긴 글을 끝까지 읽어 주어서 고맙고 항상 생각했던 것을 코드로 직접 옮기면서 문제를 해결해본다면 더 많은 것들을 얻을 수 있을 것이다.

참고문헌

위의 코드는 LUMP 소스 코드를 기반으로 작성되었습니다.

LUMPY: a Probabilistic Framework for Structural Variant Discovery.

Delly: structural variant discovery by integrated paired-end and split-read analysis

Genome structural variation discovery and genotyping (2011)

Computational methods for discovering structural variation with next-generation seuqncing (2009)

Animated gif from a video clip

hongiiv — Fri, 12 Jun 2015 15:14:31 +0900

짤방이라고 불리는 움직이는 gif를 만들기입니다. 동영상을 짤방으로 만들어주는 GIFBrewery라는 프로그램 구입하여 우선 iShowU 프로그램을 이용하여 화면을 동영상으로 캡처하고 이를 gif로 만들면 아래와 같이 프로그램의 특정 기능을 설명하는데 효과적으로 사용이 가능합니다.

Docker를 이용한 Bioinformatics 플랫폼

hongiiv — Wed, 29 Apr 2015 13:09:21 +0900

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

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이 있습니다.

Simple consensus approach improves somatic mutation prediction accuracy

hongiiv — Mon, 27 Apr 2015 16:27:41 +0900

지난 동계유전체학회 워크샵의 암유전체 분석을 위한 Somcatic Mutation Calling에 관한 내용입니다. "A simple consensus approach improves somatic mutation prediction accuray"라는 논문을 바탕으로 SomaticSniper, VarScan2, MuTect을 이용하여 각각 somatic call을 수행한 후 각 툴에 대해서 filter를 적용하고 consensus 데이터셋을 만들어 이를 실제 validation하는 과정에 대한 내용입니다. 물론 데이터는 TCGA Benchmark 데이터셋을 이용했습니다. 마지막, validation 부분을 업데이트할 부분이 좀 있는데 우선 공유합니다.

Detecting Somatic Mutation - Ensemble Approach from Hong ChangBum

Detecting Somatic Mutations in Impure Cancer Sample - Ensemble Approach from Hong ChangBum

중국의 유전체 데이터 분석을 위한 질주

hongiiv — Fri, 24 Apr 2015 08:47:58 +0900

아시다시피 중국은 BGI를 통해 시퀀싱 부분에서 타의 추종을 불허하고 있다. 더군다나 시퀀싱 장비면에서도 미국의 complete genomics를 인수까지 하게 되었다. 그나마 한편으로 데이터 분석 부분에서는 3년전 DNANexus와 Seven Bridge Genomics와 같은 클라우드 기반의 Easy Genomics 서비스를 내놓았지만 제대로 워킹하는 것을 본적이 없다. 이제 내공이 쌓였을까?

중국 WuXi PharmaTech의 거침없는 Bioinformatics를 향한 걸음

2000년 설립된 중국 우시(Wuxi AppTech)는 직원수 9,000명 매출 1조에 이르는 CRO(Contract Research Organization, 임상시험 대행 기관)로 단순한 CRO라기 보다는 헬스케어 연구 개발 전반에 이르는 토털 솔루션을 제공하고 있다. 이런 우시는 얼마전 NextCODE를 인수했는데 NextCODE는 이름에서 풍기듯이 deCODE genetics의 기술을 바탕으로 유전체 데이터를 빅데이터 관점에서 문제를 해결하는 솔루션을 제공하는 업체였다

WuxiNextCODE

이뿐만 아니라 몇일전 우시는 DNAnexus와의 제휴를 통해 NextCDOE의 유전체 데이터베이스 모델과 DNANexus의 클라우드 서비스를 통해 임상 및 연구 인터페이스를 하나의 플랫폼을 통해 전세계의 연구자들과 함께 저장하고 데이터를 분석할 수 있게 되었다. CRO의 입장에서 글로벌 제약, 바이오, 의료 기기 산업에서 원활하게 유전체 데이터를 사용할 수 있는 단일 플랫폼을 제공할 수 있게 된 것이다. 현재 유전체는 동반진단에서 약물발견에 개발에 이르기까지 다양하게 활용되고 있다. 이에 CLIA 수준에서 클라우드를 통해 모두를 연결함으로서 유전체를 사용하는 임상의, 기관 및 생명과학 회사들이 환자들에게 이익을 줄 수 있도록 유전체 정보를 사용할 수 있게 된 것이다.

BGI의 지난 3년간의 결실? BGI Online 클라우드

몇년전 BGI는 EasyGenomics라는 클라우드 기반의 유전체 분석 서비스를 내놓았지만, 어떤 이유에서인지 제대로 운영하질 않았다. 그런데 오늘 바로 BGI Online이라는 서비스를 다시 내놓았으니 홍콩의 L3 Bioinforatmics와 함께 ELSA가 포함되어 있다. 50X의 whole genome을 4시간 200X의 whole exome을 10분안에 완료하는 성능을 가졌다고 한다. 뿐만 아니라 L3의 database.bio와 complete genomics의 GenomeVoyager와 호환된다고 한다. 그동안 BGI는 홍콩의 L3나 Complete Genomics 등의 외부? 파트너와의 진짜 서비스를 내놓기 위해 뜸을 들였나 보다.

BGI의 클라우드기반 분석 서비스 BGI Online

그동안 genome 분석은 reserch 시장에서 머물렀지만, 이제 제약이나 바이오의 다양한 분야로 확장되면서 다시 한번 클라우드 기반의 유전체 분석이 주목을 받기 시작하는 것은 아닐까라는 생각을 해본다.

추가, Broad의 GATK에 대한 Appistry와의 라이센스 종료

그동안 GATK의 라잉센스가 Appistry에서 관리되었는데 이제 올해 4월 15일 계약이 만료되면서 라이센스가 다시 Broad 연구소로 전환되었다. 학업 및 비영리인 경우 기존 그대로 이지만 상업적인 라이센스의 경우 이제 Broad가 직접 관리하게 된다. 그동안 Appistry가 관리하면서 이런저런 불만이 많았었는데 이제 직접 라이센스를 관리하면서 라이센스 및 가격에 관한 투명성을 확보하는 한편 연구자들이 GATK를 이용한 파이프라인을 개발하고 이를 연구자들에게 제공하는(예를 들어 도커 이미지와 같은) 것에 대해서도 문을 열어놓는 분위기다. 그동안 Galaxy등에서는 GATK Lite 버전이나 혹은 사용자가 직접 GATK라이센스를 획득하여 직접 설치하도록 하는 방법이었는데 이제 그런면에서도 어느정도 문을 열어 놓았으니 한번 GATK의 행보를 지켜볼 만하겠다.

유전체와 클라우드 관련 기사

hongiiv — Mon, 23 Mar 2015 17:22:27 +0900

의료-헬스케어 산업의 패러다임을 바꾸는 클라우드

얼마전 국내에서 정부와 공공기관이 민간 클라우드 서비스를 사용할 수 있도록 규정한 클라우드 컴퓨팅 발전 및 이용자 보호에 관한 법률안 (클라우드 발전법)이 제정돼 오는 9월 시행을 앞두고 있습니다. 클라우드 발전법은 정부 부처와 지방자치단체, 공공기관은 앞으로 정보화 사업이나 예산을 편성할 때 먼저 클라우드 도입을 고려해야 합니다. 즉 클라우드가 우선 고려대상이라는 말입니다.

하지만, 공공에서 클라우드를 도입할 경우 도입 업무의 범위나 개인정보보호, 품질 및 안정성에 대한 내용들은 충분한 논의와 합의가 필요한 부분입니다. 클라우드의 도입은 의료나 헬스케어의 경우에는 특히나 원격의료, 환자 데이터 공유 등 서비스 수준이 향상될 것으로 기대되지만 역시 의료법이나 개인정보보호 등의 문제들이 선결되어야 합니다.

현재 이러한 대안으로 질의응답 기반 개방형 클라우드 서비스가 거론되고 있는데요. 의료기관이 직접 의료정보를 퍼블릭 클라우드상에서 사용할 수 없기 때문에 건강보험심사평가원이나 질병관리본부, 국민건강보험공단 등의 의료공공기관이 보유한 데이터를 기반으로 의료기관에게 역으로 클라우드 서비스를 제공한다는 것입니다. 이것은 대한의료정보학회의 "2014 스마트의료기술세미나"에서 발표된 내용으로 합법적으로 의료 데이터를 수집할 수 있는 기관 (심평원, 질본, 건보 등)이 private cloud 형태로 빅데이터 기반의 추론 기술(IBM 왓슨과 같은)을 의료기관에 제공한다는 것입니다. 뭐 의료기관으로서는 클라우드고 뭐고 기존에 전송만 하던것에서 제대로 데이터를 수신하는 정보공개 질의 서비스를 활용하겠다는 것입니다.

실리콘밸리의 관심

2012년 창업한 인비태(INVITAE)는 최근 1억2천만 달러의 투자에 성공한 실리콘밸리의 스타트업으로 Myriad Genetics나 Ambry와 같은 유전자 검사를 수행해준다. 여기서 유전자 검사는 23andMe와 같은 검사가 아닌 실제 의사가 진단에 활용하는 유전자 검사 즉, 분자진단에 속한다.

인비태는 genetic information이 의료에 루틴하게 쓰여지는것을 목표로 하고 있는데 NGS를 기반으로 하고 있다. 기존의 industry-standard로 알려진 PCR, Sanger, FISH, IHC 등의 검사 방법을 NGS로 수행한다는 것이다.

미국의 경우에는 LDT가 허용된 국가이기 때문에 NGS 기술을 LDT로 사용하는데에는 무리가 없기 때문에 인비태 역시 CLIA와 CAP 인증을 통해 LDT 방식으로 유전자 검사를 수행하고 있다. 현재 가능한 검사는 cadiology, hereditary cancers, neurology, pediatric geneteics, hematology에 관한 panels을 통해 검사를 수행하고 있으며, 원한다면 custom design을 통해 주로 유전자의 deletion과 duplication 테스트를 수행한다.

현재 모든 유전자와 질병과 관련된 panel은 그 수에 상관없이 모두 동일한 가격으로 책정되고 있는데 이는 필요한 정보만을 전달하겠다는 의미로 해석할 수 있다. 실제 panel상에는 모든 유전자에 대한 정보를 넣어놨더라도 의사가 원하는 질병이나 유전자에 대한 정보만 전달한다는 것으로 추측(재요청이 있는 경우 90일 이내에 추가 유전자에 대한 검사가 free)된다.

기존의 분자진단의 경우 원하는 검사를 1개씩?만 수행이 가능했고 의사들은 이러한 시스템에 적응되어 있기 때문에 인비태의 이런 전략은 아마도 의사들이 NGS라는 기술을 좀 더 쉽게 다가갈 수 있도록 열어둘 뿐만 아니라 사업적으로도 다양한 패널을 준비함으로서 투자자들에게 있어 보이는 효과를 보이지 않을까한다.

그외에도 인비태는 Family History Tool을 통해 환자의 pedgree를 기록할 수 있도록 하여 의사들이 활용할 수 있도록 하거나 Clinvate를 통해 임상적으로 유용한 genetic varinats를 public sources로 부터 모아 데이터베이스를 제공하기도 한다.

아직 국내에서는 NGS가 의료기기로 등록되지 않았을 뿐만 아니라 아직 제도적으로 NGS를 진단에 사용하기 어려운 상황이지만 인비태의 사례를 통해 기존의 이원의료재단, 녹십자 씨젠의료재단(구 네오딘), SCL, 삼광등의 검사기관들 사이에서 NGS를 이용한 분자진단에 진입을 위해 좋은 reference가 될 수 있을 것이다.

Structural Variation

hongiiv — Thu, 19 Mar 2015 07:28:59 +0900

NGS Short Reads를 이용하여 Strucural Variation을 찾는데에 있어서 depth of coverage (DOC), paried-end mapping (PEM, PE), split read (SR) 정보를 이용하게 된다. SV를 찾는데에 있어서 reference에 reads를 매핑하고 reference에 정확히 일치하는 않는 (not exact match to reference) read들을 SV를 찾는데 사용한다.

아래와 같이 60과 37이라는 부분은 reference에서 174 bases의 간격을 두고 있으며, 우리는 이 60과 37부분외에도 54 부분을 각각 서로 다른 말단에 가진 두개의 read를 가지고 있다고 하자.

이 reads를 BWA를 이용하여 매핑한 경우 첫번째 read인 60, 37,54 에 대해서 reference에 60 부분만 매핑하고 나머지 37,54 부분은 soft clip으로 처리해 버린다. 두번째 read인 54,60,37 대해서도 중간의 60부분만을 매핑하고 54와 37부분에 대해서는 모두 soft clip으로 처리해 버린다. secondary alignments의 경우에는 앞서 soft clip을 처리하는 대신 hard clip으로 처리되는데 37(빨간색) 부분에 대해서 align되고 hard clip된 것을 확인할 수 있다.

같은 데이터에 대해서 GENALICE MAP은 좀 다른 전략을 취하는데 read에 deletion이 존재한다고 가정하고 read를 split하여 매핑한다면 60과 37이 아래와 같이 각각 reference에 매핑되게 된다. 본 예에서는 2개의 read만이 이러한 deletion을 지원하지만 이러한 read들이 충분히 많이 cluster를 이룰수 있을만큼 존재한다면 이부분은 deletion일 가능성이 크게 된다.

위의 서로 다른 aligner를 보았지만, 이렇게 SV가 존재하는 부분에서는 clipping이 많이 관찰된다. 아래 그림과 같이 deletion 부분에 대해서 paired read 정보를 이용하는 경우 확연히 deletion을 확인할 수 있으며, 이러한 부분에는 soft clip이 다수 존재하는데 바로 soft clip이 이러한 deletion을 support하는 요인의 하나가 된다.

현재까지의 SV 검출은 BWA를 이용한 후 그 뒤부터 SV 툴들이 진행하는데 aligner가 어느정도 받쳐준다면 훨씬 SV 검출에 있어서 수월하게 진행할 수 있게 된다. 또다른 aligner인 Spiral Genetics의 Anchored Assembly (이하 AA)를 보면 SV를 위한 노력의 흔적을 더 잘 볼 수 있다. AA는 4단계로 진행된다.

첫번째는 reference에 align전에 reference의 정보없이 read에 대해서 correction을 수행한다. 우선 read들에 대해서 k-merize를 수행하여 각 k-mer에 대한 read quality를 계산한다. 이때 low count k-mers는 에러로 간주하여 버려진다. 이것은 간단히 read trimming과도 유사한 것으로 대략 quality가 낮은 read의 뒷부분들의 일정 k-mer들이 N으로 표시되거나 하겠다. 다음의 두 단계는 reference와 match되는 read들은 제외하고, 나머지 read들만을 가지고 overlap graph를 생성한다. 이때에는 context보다는 kmer를 기반으로 de Brujin graph를 생성한다. 마지막으로 anchoring을 수행하는데 reference와 일치하는 그래프의 끝 단말을 각각 찾아내는데 이를 anchor라고 부르며 이는 SV의 breakpoint가 된다.

지금까지 aligner들이 SV를 찾는데에 어떠한 역활을 하는지에 대해서 간단히 알아보았다. 이제는 각 SV 툴들이 어떠한 전략으로 SV를 찾는지 다음에 알아보도록 하겠다.

Bioinformatics (genomics) 트렌드 - 지금 필요한건 스피두

hongiiv — Mon, 16 Mar 2015 13:39:55 +0900

요즘 논문이나 기사를 보면서 Bioinformatics/Genomics 분야의 트렌드를 개인적으로 정리한 글로 본인의 무지에 의해 잘못된 정보를 전달할 수도 있음을 주의하시기 바란다. ㅋㅋㅋ

넘어가야할 허들 - 속도

지금까지는 속도 보다는 클라우드를 이용한 scale-up이 주된 테마였다면 이제는 기존의 파이프라인을 개선하는 방향의 speed-up이 주요 이슈가 되었다. 표준 파이프라인이라고 할 수 있는 BWA, GATK, SAMtools, Picard를 사용하는 경우 50X의 Human genome의 경우 variant call까지 16 코어 서버를 사용하는 경우 68-94시간이 소요된다. 물론 소프트웨어의 버전이나 병렬화를 어디까지 수행하는냐에 따라 이 시간은 달라질 수 있지만 말이다. 여기에 도전장을 내민것이 바로SpeedSeq으로 SAMBLASTER를 이용하여 메모리 상에서 바로 duplication을 마킹하고 Sambamba를 이용하여 멀티쓰레드를 이용한 sorting과 indexing을 수행함으로 기존의 Picard와 SAMtools 대비 비약적인 속도 향상을 노리고 있다.

다른 하나는 GATK를 병렬화를 통한 속도 향상을 꾀하는 ClusterK라는 스타트업이다. GATK SWE를 이용하여 2가지 부분에서의 GATK 파이프라인의 병렬화를 제공하고 있다. alignment 단계 (BWA-MEM)에서 500MB의 chunk들로 나누어 align을 수행(chunk당 15-20분 소요)한다. 각 chunk 단위의 align은 염색체별로 bam 파일로 combine을 수행한다.

염색체 단위의 alignment 파일은 30MB 단위로 split하여 각각 variant calling 작업을 수행한다. 이때 고려해야할 것이 바로 안전하게 30MB 단위로 split해야하는데 즉, indel등의 variant를 고려해서 안전하게 split을 수행해야 한다는 것이다. 잘못 잘랐다(아무런 옵션없이 even하게 자른다거나)가는 indel을 놓칠 수 있기 때문이다. Heng Li에 따르면 low complex regions (LCRs)를 고려하거나 pontial misassembly regions를 고려하여 safe split을 수행한다. 위에서 살펴본 2가지의 병렬화를 기반으로 GATK 파이프라인을 수행할 수 있도록 스케줄링을 하는 프레임워크를 제공한다면 GATK 파이프라인의 속도 향상을 노릴 수 있다.

일찍이 fastq 파일을 chunk로 분할하는 방법에 대해서는 많이들 사용하는데, 이게 BWA 알고리즘상 best hit 등에 문제가 발생할 수도 있으나 이따위쯤이야 무시해도 될만한 것이고 BAM 파일을 split하는 것 또한 기존에 염색체별로 나눈다 정도 였다면 safe split을 통해 안전하게 병렬화가 가능하다. 뭐 어쨌건간에 아직 human reference genome의 한계로 인해 이걸 우회할 수 위의 방법들이 유용하지만, 오늘 기사에 따르면 Seven Bridge Genomics에서 Graph Reference Genome과 Graph Aligner 등을 커머셜하게 만드는 펀드를 받았다고 하니 이것두 활용할 날이 얼마 남지 않았나 하는 생각도 들긴하다.

그림1. LCRs와 PMRs 사이트에 존재하는 soft clip reads

Graph Reference와 이를 지원하는 Aligner라고 하면 레퍼런스 게놈이 참 게놈스럽기 때문에 애초부터 염색체 1번부터 MT, X, Y까지... 1 bp 부터 주욱 일렬로 늘어선 레퍼런스는 우선 phasing 정보나 repeat 정보 등등을 표현하기는 태초부터 포기한지라 이를 그래프로 Ref를 만들고 이를 지원한다면야 clinical쪽으로 한발 앞서갈 수 있게 되는지라 이를 백만년 걸리지 않고 지금정도의 분석시간 수준으로만 해결한다면 굿 되겠다.

두 시퀀싱 센터의 걸림돌 제거 전략

위의 SpeedSeq이나 GATK SWE의 경우에는 기본적으로 BWA-MEM을 기반으로 하고 있다면 이번에는 아예 alignment 단계에서부터 속도 향상과 디스크 사용률을 낮추는 상용 소프웨어로 덴마크의 Genalice에서 만든 Genalice Map은 BAM 포맷대신 GAR 포맷을 사용하며, 처리속도나 용량이 GATK 파이프라인에 비해 월등히 우수하다. 이러한 속도와 중간/최종 결과물의 file size의 잇점으로 최근 마크로젠에서 해당 프로그램을 사용하기로 결정했다는 기사가 나오기도 했다.

그림 2. Genalice에서 제공하는 GATK 파이프라인과의 분석시간/File Size 비교

아마도 X10 데이터를 처리하기 위해서는 어쩔 수 없는 선택이었을 것 같기도 하다. 또 하나의 X10을 도입한 Garvan Institute는 AllSeq과 DNANexus 플랫폼을 도입해서 X10 데이터를 처리하는데, 공개된 HiSeq X Ten 데이터를 public하게 사용할 수 있다. HiSeq X Ten을 도입한 두 시퀀싱 센터의 경우 각각 클라우드 또는 상용 알고리즘으로 데이터 처리에 대한 걸림돌을 헤쳐나가는 모습을 볼 수 있다.

Genalice Map과 SpeedSeq 분석 좀 자세히 보기

코드설명: BWA 실행시 -R 옵션을 통해서 BAM 파일의 RG 헤드 필드와 태그를 추가하도록 한다. BWA를 수행하면 STDOUT으로 SAM 포맷이 출력되며 samblaster는 기본적으로 STDIN으로 SAM을 입력받아 STDOUT으로 Duplication이 마킹된(SAM FLAG 0x400) SAM 파일을 보낸다. 이제 SAMBAMBA를 이용하여 멀티쓰레드를 이용하여 sort를 수행한다.

자 그럼 split을 통한 병렬화와 결합한 완벽한 파이프라인은 좀만 기다리면 만들어 보여주겠다. 기다려라.

23andMe Research Portal - 유전체데이터베이스 팔기

hongiiv — Mon, 26 Jan 2015 13:06:39 +0900

23andMe 유전체 데이터베이스 판매

지난 일주일 간격으로 23andMe는 화이자 (Pfizer), 지넨테크 (Genetech)와 유전체 데이터 사용에 관한 파트너십을 체결했다. 지넨테크는 암치료제인 아바스틴 (Avastin)과 허셉틴 (Herceptin)을 생산하는 회사로 로슈 (Roche)에 속해 있다. 이 두 회사외에도 23andMe는 총 14개의 private companies 및 대학들과 파트너십을 체결했다고 전했다. 이로서 파트너십을 체결한 Big Pharma와 Biotech 회사들은 23andMe가 이미 모아 놓은 데이터를 곧바로 활용할 수 있게 된 것이다.

유전체 데이터 규모

23andMe는 자신들의 데이터베이스를 "23andMe's Research Portal"이라고 부르는데, 현재까지 75만명이상의 유전체 데이터 (genotyped individuals)를 확보하고 있으며 이중 65만명 이상의 데이터가 자신들의 데이터를 연구에 활용하도록 동의를 한 데이터라고 한다.

23andMe의 고객에게 자신의 데이터를 연구에 활용하도록 동의 여부를 묻는 화면

물론 해당 유전체 데이터는 200만개의 형질데이터(phenotypic data)를 포함하고 있으며, 이중 1천개가 curated된 데이터라고 한다. 즉, 65만명에 대한 유전체 데이터와 1천개의 임상변수를 사용할 수 있는 것이다. (Conditions/Diagnoses, Medication Usage, Response to Medication, Family History of Disease, Health Behaviors, Personality Traits, Environmental Exposures, Geographic Location)

암 및 자가면역 코호트

위의 데이터들은 다양한 코호트를 포함하고 있는데 암, 자가면역, 파킨슨, 알츠하이머 코호트 등이 존재한다.암 관련 코호트의 경우 6,000명의 유방암 환자(confirmed control 198,000명)와 5,000명의 전립선암(confirmed control 221,000명), 1,700명의 대장암 (confirmed control 431,000명) 코호트가 존재한다.1,500명의 루프스 환자와 이에 대응하는 367,000명의 contorls, 류머티스, IBD, celiac 등의 코호트를 가지고 있다.

APOE e4/파킨슨 코호트

APOE e4와 관련한 120,000명 이상의 데이터와 파킨슨 관련 10,000명의 데이터를 보유하고 있다. 이러한 데이터의 경우 23andMe는 일반고객과는 별도로 비교적 저렴한 가격 또는 무료로 참여자를 모집함으로써 해당 데이터들을 수집할 수 있었다.

Research Portal

23andMe는 해당 데이터를 손쉽게 검색하고 자신의 연구 테마에 맞도록 샘플이나 변수를 설정하고 해당 결과까지 확인할 수 있는 Research Portal을 제공함으로써 샘플이나 데이터를 모을 필요없이 실시간(real time)으로 GWAS, PheWAS 연구를 수행할 수 있도록 해준다.

23andMe의 Research Portal: 원하는 유전체 데이터를 손쉽게 검색 가능한 인터페이스

국내 유전체 데이터 포털

지금까지 23andMe의 유전체 데이터 포털에 대해서 살펴보았는데 국내에서도 이러한 데이터 포털이 존재한다. 물론 연구자에게 국한되어 있으며 국가가 관리하고 있다. 질병관리본부의 한국인체자원은행사업을 통해 생산된 데이터로 코호트 기반과 질병기반의 인체자원을 분양하고 있는데 바로 여기에 유전체 데이터가 일부 포함되어 있다.

그럼 어떠한 유전체 데이터와 그와 연관된 데이터들이 존재하는지를 확인하기 위해서는 인체자원은행 분양데스크 홈페이지를 통해 검색이 가능하다. 인체자원검색 메뉴에서 역학기반검색을 선택하면 선택 가능한 자원 중 "유전체자료"가 포함된 데이터를 검색이 가능하다.

갑상선 과거력을 가진 유전체 데이터 검색

아래예는 농촌코호트 (522명) 중에서 갑상선질환을 앓았던 사람중 유전체 데이터를 포함하는 샘플 (총 45명)을 검색한 화면이다. 바로 이 데이터를 분양 신청하면 심사를 거쳐 해당 데이터를 이용할 수 가 있게 된다.

유전체 데이터 검색 결과

국내에서 유전체데이터를 검색하고 사용할 수 있는 시스템이 존재하지만 데이터 중 유전체 데이터를 가진 데이터는 일부에 불과하다. 하지만 잘 활용한다면 충분히 흥미로운 데이터임에는 분명하다.

시사점

미 FDA는 23andMe는 그동안 축적한 데이터를 기반으로 자체적으로 다양한 연구를 수행하는 한편 연구에 활용할 수 있는 잘 관리된 데이터베이스를 구축하고 이를 Research Portal이라는 이름으로 내놓고 여러 제약 및 Biotech와 파트너십을 통해 그 영향력을 점점 확대하고 있다.샘플을 모은 과정은 자사의 일반 고객과 연구기관과의 협력을 통해 자사 고객과는 다른 특정 질환의 샘플을 모으는 프젝트를 통해 저렴한 가격에 손쉽게 구하기 힘든 샘플을 손쉽게 구하는 전략을 펼쳤다. 이렇게 모은 샘플들이 알츠하이머나 파킨슨병에 대한 샘플들로 이번 지넨테크와 협력을 하는 부분이 바로 파킨슨병에 대한 것이다. 이러한 사실을 본다면 첫번째 시사점은 바로 참여자에게 부담없는 비용의 유전체 검사와 그에 따르는 샘플 수집과 연구에 활용이다. 여러 질환관련 학회나 각 질환관련 환우회 또는 질환연합회를 적극 활용하는 것 또한 좋은 포인트라고 할 수 있겠다.

23andMe Demographics

이러한 사실을 보면 유전체 데이터와 이를 통한 사업은 꽤나 관심이 갈 만한 사업이다. 그렇다면 후발 또는 국내에서 이러한 사업을 한다면 가능할까? 우선은 23andMe의 데이터는 77%가 European의 데이터라는 것이다. 이중 라틴이나 아프리카를 제외한다면 East/South 아시안은 채 10%도 되지 않는다는 것이다. 이러한 사실은 이미 일본의 도시바나 소니의 경우에도 그 중요성을 알고 아시아인의 유전체 데이터베이스 구축을 그들의 헬스케어 전략에 포함하고 있다. 그렇다 두번째 시사점은 아직은 아시안 유전체 데이터베이스는 속된 말로 돈 될 수 있다는 것이다.

소니의 유전체 데이터베이스 사업

세번째 시사점은 단순히 데이터를 모으는 것이 아니라 자체적인 R&D가 가능해야 한다는 것이다. 23andMe는 자체 연구를 통해 이미 상당한 수의 논문을 발표했으며, 이를 기반으로 자사의 서비스에 자사의 연구결과를 포함/검증하는데에 사용하고 있다는 것이다. 바로 이러한 자체적인 R&D가 가능했기에 그들을 연구를 위해 최적화된 Research Portal의 구축이 가능했던 것이고 바로 잘 정제 (curated)된 데이터는 Big Pharma들에게 매력적일 수 밖에 없었을 것이다.

참고

23andMe Research Portal Platform 문서

23andMe Research Portal 홈페이지

Research Portal 사용예

23andMe 연구 목록

Detecting Somatic Mutations - Ensemble Approach

hongiiv — Wed, 14 Jan 2015 13:50:52 +0900

예전에도 두어번 블로그글을 통해 variant calling에 있어서 Ensemble approach에 대해서 언급했었더랬습니다. comparison of variant detection methods, somatic caller는 뭘 사용해야 하나요? 를 참고하세요. 오늘은 그 끝판왕으로 준비했습니다. 왜냐구요? 잠시 광고 하나 하고 넘어가려고 합니다. 한국유전체학회 동계 심포지엄이 2월 4일부터 진행되는데 올해는 이틀간에 걸쳐 "Somatic Calling 알고리즘 소개 및 실습" 워크샵이 준비되어 있습니다. 현재 저조한 등록을 보이고 있다고 합니다. 오늘은 그래서 워크샵에서 진행할 내용을 미리 소개하는 시간을 가져 보려고 끝판왕으로 준비했습니다. ;-) 더 안오실지도 모르겠군요.

아! 그리고 저번 포스팅에서 구글애드센스 광고를 달았다고 말씀드렸는데요. 구글에서 광고수익을 지불 방법을 확인하는 우편도 도착했구요. 현재 무려 $15의 수익을 올리고 있습니다. 이자리를 빌어 이글을 보시는 모든분들께 감사하다는 말씀을 전합니다. ㅋㅋㅋ

Somatic Mutation Calling Tools

그럼 본론으로 들어가 보도록 하겠습니다. 뭐 요즘 핫한 분야는 바로 somatic mutation 찾기 아닐까 합니다. 암 샘플의 heterogeneous하고 normal cell과의 dilute 등등 그만큼 챌린저블한 분야이며, 무엇보다도 실제 clinical에 응용될 수 있는 부분이라 그런것 아닐까 생각이 듭니다.Ding 아주머니 (워싱턴 대학에서 SomaticSniper와 VarScan을 만드신)의 최근 리뷰 논문에 따르면 아래와 같이 수많은 cancer genome 분석 툴들이 존재합니다. (중간에 잘린 표입니다.)

이미 잘알려진 JointSNVMix, MuTect, SomaticSniper, Strelka, VasrScan 등이 우선 눈에 들어오고 최근 Dream Challenge의 S omatic Mutation Calling Challenge의 주인공들이 만든 툴들이 보이네요.

ICGC-TCGA DREAM Somatic Mutation Calling Challenge의 주인공들

역시 Broad-너네가 다해 먹어랏, Ding 아주머니도 보임

각각의 툴들에 대한 알고리즘이나 특징은 해당 논문을 찾아보시거나 여러툴들을 비교한 논문들이 꽤 존재합니다. 따라서 툴 소개는 이것으로 마무리하려고 했지만... Wang의 "Detecting somatic point mutation in cancer genome sequencing data: a comparison of mutation caller"를 잠깐 보면 다음과 같이 각 툴들을 소개하고 있습니다. 끝

하나로는 부족해 우리 합치자!

비단 bioinformatics 분야뿐만 아니라 다른 곳에서도 같은 목적을 위해 여러 툴들이 합쳐 각각의 단점은 상쇄시키고 장점을 부각하는 일명 ensemble 방법 (또는 consensus, combining)이 많이 사용되고 있다. 그런데 문제는 이 ensemble이라는 방법이 걍 사용한다고 해서 좋은 것 아니라는 것입니다. 좀 세련되게 각 툴의 결과와 feature들을 뽑아서 training을 시키거나 암튼 consensus를 구하는데에도 갖가지 어려운 수식이 오가면서 ensemble을 적용하는 것 또한 만만치 않다는 것입니다. 그래서 기름기를 쫙 뺀 바로 저 멀리 남반구 호주 멜버른의 Goode가 A simple consensus approach improves somatic mutation prediction accuracy"라는 제목부터 simple을 달고 나온 방법을 소개해보려고 합니다.

Data Sets

27 ovrian tumor와 그와 매칭하는 germline 샘플을 HiSeq 2000 으로 whole exome sequencing을 평균 102~225x로 100bp paired-end로 뽑아냅니다. 그리고 나서 JointSNVMix2, MuTect, SomaticSniper를 돌리죠. 왜 저 3개의 툴을 사용했냐? 메이저 tumor 논문에서 사용한 툴들이니까요 :-) 그리고 나서 총 9,226개의 somatic SNV를 prediction합니다. 평균 샘플당 321개이며, 툴별로 보면 S와 J는 샘플당 170개 정도 M의 경우 좀 더 보수적으로 115개의 SNV를 찾아내게 됩니다.

중요 포인트는 Non-reference allele frequency

그런데 somatic이라고 뽑은 mutation들의 해당 read가 reference와 같은 allele인지 아닌지를 한번 더 살펴보게 되며 germline에서 보면 J와 S에서 높게 나타나는 행패를 부립니다. 즉 somatic이라고 뽑은 놈이 germline mutation이게 되는 것입니다. 즉 이 놈들은 False Positive인 놈들인거죠. (그림의 빨간색 박스 참고) 반면 M은 somatic을 잘 뽑아낸것 처럼 보입니다. 여기서 그럼 somatic이라고 뽑은 놈들이 germline mutation 즉 germline에서 non-reference인 것들을 filterout 시킨다면 좀 더 True Positive에 가깝게 되겠지요. 이건 다음 filtering 부분에서 다시 보겠습니다.

이제 tumor에서 non-refernece allele frequency를 보면 M,J,S와 JS, MJ의 경우 낮게 보이는데요. 요것 또한 somatic이라고 뽑은 놈들이라면 tumor에서 높은 non-reference allle를 보여야 한다는 거죠.

즉, 3개의 툴이 공통으로 찾은 somatic mutation에 대해서 위에서 언급한 non-reference allele에 대한 필터를 거친다면 더욱 True Positive에 가까운 mutation을 찾을 수 있게 되겠죠. 그래서 이들은 찾은 mutation에 대해 sanger sequencing을 수행해서 validation set을 가지고 consensus call과 몇몇 filtering 과정을 거쳐 성능이 향상되는지를 확인하게 됩니다.

Additional filtering 왜? consensus의 specificity를 높이려구

앞서 언급했듯이 non-refence allele 부분과 관련한 부분을 해결코자 tumor/normal 샘플(.bam)에 대해서 GATK Unified Genotyper를 이용하여 tumor와 germline에 대한 SNV를 calling 합니다. 이걸가지고 consensus call에 대해서 우선 GATK UG의 germline SNV를 제거합니다. 그리고 나선 GATK UG가 tumor에서 찾은 SNV와 겹치는 것만 남기게 되죠. 이렇게 하면 아래 처럼 183개중 50개만 맞췄던 결과가 113개중 48를 맞추게 됩니다. 그에 더불어 mate-rescued된 read를 통해 필터를 더 추가시키게 되면 결과는 87개중에 48를 맞추게 됩니다. 결국 2개의 true positive를 잃게 되지만, 183개에서 87개로 확 줄어둔 즉 specificity를 확 증가시키게 되는 결과를 보입니다.

결론

결론적으로 간단한 consensus와 필터링만으로 validation rate를 높이고 sensitivity를 증대 시킬 수 있게 되었다는 것입니다. 하지만 그에 따라 다양한 툴들을 돌려야 한다는 즉 computation 리소스는 부담으로 남게 되며 multiple 툴을 병렬로 빠르게 돌리는 것에 대한 논의가 또 있어야 하겠죠.

뭐 어찌되었던간에 광고로 돌아가서 2월달 워크샵에서는 TCGA 데이터를 가지고 위의 consensus 메소드를 실제로 구현하고 검증하는 과정과 더불어 ranking을 통해 좀 더 연구자에게 보기 좋은 결과물을 얻는것이 실습으로 진행되니 관심있는 분들의 많은 참여를 바랍니다.

안녕, ;-)

NGS가 열어가는 진단 multi-gene/many drugs

hongiiv — Wed, 31 Dec 2014 09:12:04 +0900

미국에서는 2013년 10여개의 Clinical Lab(CLIA88(Clinical Laboratory Improvement Act88)에 따라College of American pathologists에서 인증하는 검사실 품질 요건을 받은 lab)에 한해 검사실 자체 개발 검사(LDT, Laboratory Developed Test)를 수행할 수 있다. 현재 10여개의 lab에서 NGS를 사용하는 50개의 LDTs를 수행하고 있다. 미국에서 NGS가 임상검사에 사용될 수 있는 이유는 LDT를 통해 FDA의 허가 없이도 장비 또는 시약을 임상검사로 사용할 수 있기 때문이다.

정밀의학(Precision Medicine)은 적정한 환자에게 적정한 약을 적정한 용량으로 적정한 시간에 사용하는 것이다. 진단기기 (Dx device)의 역할은 바로 적정한 환자를 구별해내는 것이고 이것이 적정한 치료로 이어지기 위해서는 약물에 대한 안정하고 효과적인 사용이 이루어져야 한다. 바로 이때부터는 사용되는 진단기기(Dx)를 동반진단기기(CDx device)라고 불린다.현재의 정밀의학의 추세는"one-durg/one-gene Dx"로 요약할 수 있다.

문제는 진단의 경우에는 LDT에 의해 NGS 장비가 사용될 수 있지만 동반진단의 경우에는 체외진단기기(in vitro diagnostics, IVD)의 규제를 받게 된다. 동반진단(companion diagnostics)은 치료제와 동시에 출시되거나 병행 개발되어 해당 치료제의 투약 여부와 투여량을 결정하는 진단제이다.

NGS를 이용하는 동반진단은 아니지만, 몇일전 FDA는 아스트 라제네티카의 ovarian cancer 항암제인 Olaparib(AZD-2281, 현재는 Lynparza라는 상품명)에 대해서 germline BRCA mutation에 대해 동반진단을 승인했다. 아스트라제네티카라는 제약사와 안젤레나졸리로 더 유명해진 미리어드사의 BRCAAnalysis CDx의 동반진단기기를 승인한 것이다. 이로서 앞으로 Lynparza를 투여하기 위해서는 미리어드사의 BRCAAnaysis CDx의 진단을 통해 투여여부나 투여량을 결정하게 된다.

2005년 아스트라제네티카는 영국의 kuDOS Pharmaceuticals를 인수하여 DNA repair pathway에 관여하는 poly ADP-ribose polymerase (PARP) inhibitor에 대한 기술을 가지고 2008년부터 2012년 임상을 진행한다. 아스트라제네티카는 임상이 시작되기전인 2007년부터 미리어드와 파트너십을 통해 Olaparib에 대한 동반진단을 수행한 결과이다. 미리어드는아스트라제네티카의 olaparib(ovarian cancer)외에도 Biomarin(BMN-673, breast cancer), AbbVie(veliparib, breast cancer), Tesaro(niraparib, ovarian cancer)등의 제약사와 함께 임상을 진행중에 있다. (현재 진행중인 제약사들의 oncology drug 파이프라인 참고

요약하자면, 정밀의학의 추세는 "one-drug/one-gene Dx"로 이는 동반진단(CDx)이라는 형태 진행되고 있다는 것이다. 여기에 NGS라는 기술이 통해 "multi-gene/many drugs"라는 패러다임으로 변해가고 있다. 바로 2014년 초에 일루미나는 Amgen과 함께 Vectibix에 대해 NGS 기반의 동반진단에 협력하기로 한것이다. Vectibix는 환자의 KRAS 유전자의 mutation을 검사하는 것인데 이미 2012년 Qiagen은 therascreen KRAS RGQ PCR Kit을 통해 Erbitux의 사용에 있어 대장암 동반진단으로 FDA의 승인을 받았다. 암젠은 큐아젠과 함께 KRAS mutation에 있어서 PCR-기반의 동반진단에 대해서도 진행중에 있다.

일루미나는 RAS family 유전자에 대해서 미국과 유럽의 NGS 기반의 동반진단을 목표로하고 있으며, 이미 MiSeq Dx NGS 장비로 두개의 cystic fiborosis(낭포성 섬유증) 테스트에 대해서 FDA의 승인을 받은바가 있다. 일루미나는 이렇게 내외부 협력을 통해 MiSeq Dx NGS 장비로 동반진단에 대한 허가를 받고 또한 제약사와의 파트너십을 통해 신약개발에 있어서 보다 많은 협력을 하려고하고 있다. 앞으로 multigene NGS panels은 각각의 암환자에게 보다 정확한 암 유전자에 대한 정보를 주고 치료에 있어서 좀 더 많은 정보를 줄 것으로 기대하고 있다.

NGS를 이용한 진단 개발에 있어서 전체적인 미국내에서의 규제는 앞서 설명한 대로 LDT의 경우 CLIA를 따라야하며 전통적인 FDA의 규제를 받는(동반진단 포함) 경우는 risk에 따라 510(k)라는 사전허가를 받아야 하며 기존의 동일한 기기가 있는 경우는 동질성 테스트를 득하거나 새로운 경우 De novo 510(k)를 득해야 한다. 마지막으로 High risk는 PMA(Pre-market approval)라는 시판전 허가를 득해야 한다.

지금까지 NGS에 있어서 진단기기로 활용에 대한 내용을 규제와 현재까지 사례를 통해서 알아보았다. 하지만, 이외에도 이제 NGS 분석에 있어서 bioinformatics 요소나 표준, clinical report 등의 요소에 대해서도 다음기회에 알아보도록 하겠다. 즐~

참고

De novo request for evaluation of automatic class III designation for the Illumina MiSeqDx Platform

Illumina MiSeq Dx Cystic Fibrosis Clinical Sequencing Assay

Life Technologies Clinical Services Lab

15 Breast Cancer Drugs in the Pipeline Right Now

구글 지노믹스를 이용한 Picard와 GATK

hongiiv — Wed, 17 Dec 2014 15:31:04 +0900

이미 여러번 소개 했듯이 구글은 구글 지노믹스라는 서비스를 통해 유전체 데이터를 저장하고 분석할 수 있는 환경을 제공하고 있습니다.최근에는 우리가 흔히 사용하는 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 표준에 대해서는 유전체학회 소식지의 "대용량 유전체 데이터 표준화 최신동향"을 참고하시기 바랍니다.

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

Samtools를 이용한 genotype likelihoods 구하기

hongiiv — Fri, 31 Oct 2014 13:32:45 +0900

samtools가 버전 0.1.19를 마지막으로 major 번호가 올라갔습니다. 바로 1.0 버전대가 탄생한것이죠. 홈페이지도 이제는 www.htslib.org를 사용합니다. 흔히 우리가 말하는 Samtools는 Samtools, BCFtools, HTSlib 3개로 구성되어 있습니다.

Samtools는 SAM/BAM/CRAM 포맷의 파일을 읽고/쓰고/편집하고/인덱싱하고/볼 수 있는 툴입니다. BCFtools는 BCF2/VCF/gVCF 포맷의 파일을 읽고/쓸 수 있으며 SNP나 short indel의 sequence variants를 calling/filtering/summarising 할 수 있는 툴입니다. 그리고 그 기반은 high-throughput sequencing 데이터를 다루는 바로 C로 작성된 HTSlib이라는 라이브러리를 기반으로 하고 있습니다. Samtools를 이용한 Variant Calling에서도 다음과 같은 명령으로 변경되었습니다.

samtools mpileup -ugf ref.fa sample1.bam sample2.bam sample3.bam | bcftools call -vmO z -o study.vcf.gz

잠깐 살펴보면 예전에는 bcftools의 view가 call이라는 명령어로 변경된 것을 확인 할 수 있을 겁니다. 그럼 간단하게 Samtools를 이용한 variants를 identifying하는 방법에 대해서 알아보도록 하겠습니다. mpipleup 명령은 aligned read 즉 BAM 포맷의 파일로 부터 genotype likelihood를 계산하는 명령입니다. 해당 샘플의 모든 site에 대해서 genotype likelihood를 계산하게 됩니다.

The Variant Call Format (VCF) Version 4.1 Specification을 보면 INFO 필드의 몇몇 키워드에 대한 설명이 나오는데요. GL 필드와 이와 관련한 PL, GP 필드에 대해서 우선 알아보겠습니다. GL 필드는 앞선 genotype likelihood에 대한 정보를 담고 있는 필드 (Floats)로 genotype likelihoods comprised of comma separated floating point log_10-scaled likelihood for all possible genotypes given the set of alleles defined in the REF and ALT fields.

예를 들어 아래와 같이 reference allele가 T라고 할때 alternative allele가 C와 G 두 개가 있다고 합시다 (T=0, C=1, G=2) . 그리고 PL 필드를 보면 콤마(,)로 구분된 총 6개의 값이 보입니다. diploid인 경우 AA, AB, BB, AC, BC, CC 6개의 genotype에 대해서 likelihood 값을 계산하게 됩니다. REF는 0 , ALT는 1,2로 표현되는 경우 (0,0), (0,1), (1,1), (0,2), (1,2), (2,2)로 표시할 수 있겠습니다. 그럼 여기서 TG genotype은 몇 번째에 있는 값인가요?라고 물어보면 F(j,k) = (k*(k+1)/2)+j 즉, F(0, 2) = 3 이므로 'TG'는 genotype likelihood는 4번째에 존재하는 99가 genotype likelihood 값이 됩니다.

chr1 12887054 . T C,G 194 . DP=253;VDB=0.423501;SGB=-0.693147;RPB=2.7979e-06;MQB=2.50009e-15;MQSB=3.79278e-05;BQB=0.860152;MQ0F=0.41502;AC=1,1;AN=2;DP4=60,0,147,20;MQ=15 GT:PL 1/2: 255,100,99,213,0,231

Genotype	Phread Scaled Score	Likelihood p-value
AA, (0,0), TT	255
AB, (0,1), TC	100
BB, (1,1), CC	99
AC, (0,2), TG	213
BC, (1,2), CG	0
CC, (2,2), GG	231

glf 포맷,,, glfsingle, samtools-hybrid,,, 등등등 추가해야함,,, 우선 skip 추후에 지속 업데이트하기로 한다.

아이고 의미없다.

유전체 분석 플랫폼 관련 과제 현황

hongiiv — Tue, 21 Oct 2014 13:37:50 +0900

우리나라의 NGS 분석 플랫폼 (H/W & S/W) 관련한 사업 리스트입니다. 이번 다부처 유전체 사업으로 진행되는 과제들 포함 종료 또는 이제 시작하려는 것들입니다. 대부분이 국가과제로 국민의 세금으로 진행되는 만큼 잘 진행되어으면 합니다.

차세대 생명정보 분석을 위한 생물정보학 플랫폼 개발

2011년 시작하여 2014년 종료된 산자부 과제로 테라젠이 주사업자로 진행되었던 과제입니다. 다부처유전체사업이 진행되기 이전에 산자부에서 진행되었던 과제로 미래부의 이번 다부처 유전체사업의 내용과 비슷한 내용을 진행했던 과제입니다.

유전체 산업비즈니스 클러스터 구축

2014년 다부처유전체사업으로 산자부에서 진행하는 과제로 35억원 규모로 500 TB 디스크와 150~200 core 규모의 서버팜과 EMR과 연동하기 위한 유전체 DB 템플릿 개발로서 임사의사결정시스템 구축을 목표로 하는 사업입니다.

유전체정보 개방형분석 서비스 환경 구축

2014년 다부처유전체사업으로 미래부에서 진행하는 과제로 총규모 17억원 규모입니다. 통합지원과제의 경우 150 core, 5 PB 규모의 서버팜을 구축하며 이는 KOBIC에서 수행하게 됩니다. 연구지원과제는 유전체, 전사체, 네트워크, 후성, 메타 지놈의 5개의 과제로 각 과제는 해당 파이프라인을 구축하고 이는 통합지원과제와 연동하게 됩니다. 각 연구지원 과제는 KOBIC, 이화여대(이상혁), 포항공대(노태형) 등이 수행하게 됩니다.

유전체정보분석 기술개발

2014년 다부처유전체사업으로 미래부에서 진행하는 8억원 규모의 과제로 유전체 분석을 위한 알고리즘과 파이프라인 각 10종을 개발하게 되는 과제입니다.

IGCG/TCGA Pan-Cancer Analysis Project

국제암유전체컨소시엄에 ETRI의 마하 슈퍼컴퓨터를 포함한 전세계 6개의 슈퍼컴퓨터가 2000명의 암유전체 데이터 분석 수행

Web Collections: NGS 관련 포스팅 모음

hongiiv — Tue, 21 Oct 2014 10:49:38 +0900

Web Collection: 그동안 산발적으로 이루어졌던 NGS 관련한 포스팅을 한번에 볼 수 있도록 모아봤습니다. RNA-Seq에서 De novo Mutation 발굴까지 다양한 영역을 커버하고 있습니다만, 깊이는 없습니다. 곧 ChIP-Seq과 De novo RNA-Seq에 대한 부분까지 업데이트 예정입니다.

NGS 데이터 포맷 및 Alignment

NGS 데이터의 Raw Data인 FASTQ Format에 관한 글
Short Read Alignment에 관한 글

Variant Call

일반적인 Resequencing 데이터에서 Genotype and SNP Call
Variant call software에 대한 글

Somatic Mutation

Somatic caller 소프트웨어에 대한 글
Low-allelic-fraction에서 Somatic Call에 관한 글
De novo mutation에 관한 글

RNA-Seq

전반적인 RNA-Seq Application에 관한 글

분석 파이프라인

유전체 분석 파이프라인 비교에 관한 글

구글 Genomics API를 이용한 De Novo Variant Call

hongiiv — Fri, 17 Oct 2014 15:31:47 +0900

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 10⁸bp)
시퀀싱 에러: 이건 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 데이터를 아래와 같이 베이지안 네트워크를 통해 표현할 수 있겠다. 앞서 말했듯이 방향성이 있으면서 비순환적인 그래프가 완성되었다. G_F, G_M, G_C는 각각 아빠, 엄마, 자식의 genotype을 의미하며 각 genotype은 총 10개 (AA,AC,AT,AG,CC,CT,CG,GG,GT,TT)를 가질 수 있으며, trio의 genotype은 10³개가 가능하다. 부모의 genotype은 자식의 genotype에 방향을 가지고 있다. D_F, D_M, D_C는 관찰변수로 해당 genotype 부분의 read 정보 즉 base 정보를 나타낸다. 따라서 G_F는 D_F와 대응한다.

그래서, 베이지안 네트워크를 이용하여 최종적으로 모든 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 페이지를 참고하여 작성되었습니다.

구글 클라우드 플랫폼을 이용한 유전체 분석 경진대회

hongiiv — Fri, 17 Oct 2014 13:43:23 +0900

예전에 글 중에서 유전체 데이터를 이용하는 경진대회에 대한 이야기를 한적이 있다. 각설하고 여기 미국에서 어떻게 경진대회를 하는지 한번 보기 바란다. 누누히 했던 이야기이지만 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"를 참고하기 바란다.

자 모두 준비되셨으면, 챌린지에 도전하세요.

클라우드 유전체 분석 뜬구름 다 잡았다.

hongiiv — Fri, 17 Oct 2014 10:27:31 +0900

혹자는 유전체 연구에 있어서 클라우드 컴퓨팅을 뜬구름이라 했다. 혹자는 클라우드를 네어버 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와 이제 막 유전체 분야에 뛰어드는 구글의 행보가 기대된다. 이제 국내도 이런 움직임이 있으려나? 아직 멀었다. 그저 클라우드건 뭐건 이번 다부처유전체사업이 잘 되기만을 바란다.

클라우드로 만드는 슈퍼컴퓨터

hongiiv — Thu, 16 Oct 2014 14:18:08 +0900

대규모의 계산이 필요하다. 단돈 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는 확실한 솔루션을 가지고 있다는 것 또한 알아두심 되겠음.