« Previous : 1 : 2 : 3 : 4 : 5 : Next »

GBrowse Hack 1탄

HapMap GBrowse
HapMap에서 사용하는 gbrowse에 내 데이터 살짝 얹어 보도록 하자. 직접 Genome Browser를 만들 수 없는 상황이라면 아주 유용하게 사용될 수 있을 것이다. 아래 그림은 chromosome 9의 0.7M 영역에서의 HapMap 프로젝트에서 Genotype한 SNP(붉은색 삼각형)들과 dbSNP의 SNP(파란색 삼각형)들을 GBrowse를 통해서 본 것이다.

그림 10
HapMap에서의 Genotyped SNP와 dbSNP SNPs 트랙

여기서 내가 Genotype한 것들이 있을 경우 HapMap, dbSNP들과 비교해 보길 원한다면 자신의 Genotype한 데이터를 GFF 형식으로 만들어서 gbrowse에 살짝 넣어주면 된다. 자 그럼 시작해 보자.

GBrowse Hack
여기서는 다음의 3가지 방식을 통해서 GBrowse에 자신의 데이터를 표현하는 방법에 대해서 살펴보도록 하겠다.
  • gff 형식을 이용하는 방법
  • gff 형식이 아닌 annotation 형식을 사용하는 방법
  • 직접 DB에 넣은 후 gbrowse의 conf에서 어떻게 보여줄지 지정하는 방법
GFF 형식을 사용하는 방법
우선 GFF3 포맷으로 SNP을 어떻게 표현할지 부터 알아보자. GFF는 다음과 같은 형식을 갖는 flat파일이다. 각각의 컬럼은 탭으로 구분되고 위의 형식에 따라 SNP를 표현하면 다음과 같다. GFF에 대한 상세한 Spec은 여기[1][2]를 참고 하면 된다.

seqid source type start end score strand phase attribute <-GFF3 형식
Chr1 dbsnp snp 200 200 . + . ID=SNP:rs1234;alleles:G/T <-GFF3 형식으로 SNP를 표현

Affymatirx에서 제공하는 500K SNP annotation 파일을 gff 형식으로 python 스크립트를 통해서 간단하게 변경한 후 gbrowse의 Add your own tracks에 gff 형식의 파일을 업로드한다.
add_own_tracks
gff 파일 업로드하기

gff_annotation
하단에 새롭게 생성된 500K SNP 트랙

Anotation 사용하기
위의 gff 형식을 이용하면 해당 위치에 막대기( | )만 생겨서 별로 볼품이 없을 뿐더러 위치외에 어떤 정보를 표현해주지 않는다. 따라서 아래와 같은 annotation 파일을 만들면 어느정도 사용자의 취향 대로 정보를 표현할 수 있다. 아래 그림은 TCF7L2_annotations.txtsnpedia의 두 annotation 파일을 위와 같이 upload your own data를 통해 업로드하여 HapMap 브라우저(GBrowse)상에서 확인한 모습이다. 좀 더 자세한 annotation 정보는 여기를 클릭

annotation1
Anotation 1

annotation2
Anotation 2

DB 사용하기
# nohup time ./script/load_gff --dsn dbi:mysql:hapmap_fin -gff_munge 500K_SNP.gff &

위의 명령어는 기존의 gbrowse 데이터베이스에 500K_SNP 정보를 새롭게 추가하는 load_gff 스크립트를 실행하는 명령어이다. gbrowse를 설치한 후 gff 파일들을 DB에 넣어주는 bulk_load_gff 명령어와 기존의 DB에 새로운 내용을 추가하는 load_gff 스크립트는 모두 Bio Perl 패키지에 들어있으며, HapMap 데이터의 경우에는 수정된 bulk_load_gff를 HapMap사이트에서 제공하고 있다. 참고로 기존의 HapMap 데이터가 들어있는 데이터베이스에 위의 명령어로 데이터를 추가하면 19시간이 걸렸다.(너무 오래 걸리네,,,)

withKorean
DB에 추가된 내용의 트랙(CGS SNPs)

HapMap 사이트에서 보면 bulk_load_gff 명령어로 gff 형식의 HapMap 데이터를 MySQL데이터베이스로 옮기는데 6~7시간, dbSNP 데이터를 로드하는데는 8~10시간이 걸린다고 한다.

bulk_load_gff : 6~7h(HapMap), 4h(테스트)
load_gff : 8~10h(HapMap), 7h(테스트)

Posted by hongiiv

2008/09/27 01:11 2008/09/27 01:11
, ,
Response
No Trackback , No Comment
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/467

개인용 Genome 브라우저

(맞춤형 개인 의료, 개인 Genome 서비스, Google Health, 23andMe) 논문에서나 볼 수 있는 내용들이 점점 나(개인)에게 실질적으로 다가오고 있다. 이런 상황에서 자신의 Genome 정보를 시각화하고 다른 정보와 결합해서 보여주는 Genome Browser 또한 개인(연구용이라기 보다 좀 아는 일반인)에게 맞추어져야 할것이다.

watson_genotype
제임스 왓슨 박사개인 Genome 브라우저 - 이런건 일반인에게 필요 없지,,,

만약 23andMe에서 Ensembl이나 UCSC Genome Browser에 개인의 정보를 추가해서 보여준다면 일반인들은 질색을 할 것이다.

그럼 개인의 입장에서 한번 살펴보자. 나는 나의 Genome 정보를 가지고 있다. 그럼 이것만 가지고는 그 어떤 정보도 찾을 수가 없다. 따라서 여러 분산된 생물학 데이테베이스에 접근해서 자신의 정보와 믹스하여 보기 쉬운 포맷으로 보고자 할 것이다.

  • 23andMe 데이터
  • 암호화된 파일 포맷
  • CSV 포맷
  • SNPedia의 SNP 데이터
  • SNPedia의 분석된 SNP 메타 데이터
  • 인종간의 정보
이러한 여러가지 정보와 개인의 정보(23andMe 정보가 되겠군^^)를 믹스한 개인용 Genome Explorer가 여기 (http://www.scheidecker.net/)있다.

pexplorer
Personal Genome Explorer 1.2 - 당뇨가 -.-;;; 조심해야하는거군..

SNPedia에서도 Promethease라는 프로그램을 통해 자신의 정보(23andMe, deCOCEme 등)를 입력하면 질병이나 약물에 대한 정보를 보여준다.

promethease_report
medicine, medical condition의 분류에 따라 리포팅을 해줌

hiv
HIV에 대해서 rs9264942 SNP에 대해서는 자신의 인종에서 50%가 자신과 같은 타입을 가지고 있으며, 위험도?는 2.1로 좀 조심해야 할 듯 ^^

어떠한가? 자신의 Genome 정보와 Trait을 보면서 건강 계획을 세워보는것은...

Posted by hongiiv

2008/09/19 10:56 2008/09/19 10:56
, , ,
Response
No Trackback , No Comment
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/462

Big Data 어제 오늘 이야기는 아니지만

The current issue of Nature has a special issue on big data which is full of stuff that might be of interest:
http://www.nature.com/nature/journal/v455/n7209/

In particular: Big data: The future of biocuration:
"To thrive, the field that links biologists and their data urgently needs structure, recognition and support."
http://www.nature.com/nature/journal/v4 ··· 47a.html

한번 읽어봐야지 ^^;;

Posted by hongiiv

2008/09/04 19:14 2008/09/04 19:14
, ,
Response
No Trackback , 4 Comments
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/456

유전자와 교육과정 개발

하버드 대학교의 W.E.B Du Bois 연구소-아프라카인과 아프리카계 미국인 연구(W. E. B. Du Bois Institute for African and African American Research)-의 헨리 루이스 게이츠 Jr. thwkddms 2000년 처음 유전자 검사를 받은후 유전자 검사를 통해 아프리카 혈통을 추적하기를 주장해왔다는군요( 헨리 소장의 사진을 보면 흑인인데, 유전자 검사 결과는 유럽 혈통이 발견되었다고 하네요 ^^).

뭐 이전에 23andMe에서도 자신의 혈통을 추척하는 서비스가 있기는 한데,,, 그는 단순히 이것으로 끝나는 것이 아니라, 흑인과 소수 민족 아이들에게 역사와 과학을 가르치는데 학생들이 그들의 유전자의 배경이 되는 지식을 공부하고 자신들의 계보를 재구성하는 교육과정을 개발하고 있다고 합니다. 그의 말에 따르면, 어느 누구에게나 궁극적인 주제는 자신이기 때문에, 효과가 있을거라는군요.

아이들에게 흥미롭게 접근할 수 있을 것 같기는 한데, 한민족 한핏줄을 강하게 인지하고 있는 우리나라에서는 어떨지 의문입니다만, 유전자 정보를 아이들의 교육과 연관 시키는 것 자체로는 아주 흥미롭습니다. ^^

덧붙이자면, 저희 연구소에서도 아시아 국제결혼 이주자 코호트(배우자 중 1명이 동남아 출신의 국제결혼 이주민으로 결혼 후 2년 이상 거주 혹은 1자녀 이상인 사람)를 통해 한국인의 유전적 배경이 된 동남아 이주민의 유전체 역학 코호트를 구축하고 연구하고 있는데,,, 그만큼 우리나라에서도 국제결혼이 많아지고 있고, 향후 이러한 접근의 교육도 가능할것 같네요 ^^;;

Posted by hongiiv

2008/08/25 17:40 2008/08/25 17:40
, ,
Response
No Trackback , No Comment
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/450

Genome-scale 서열 분석

Suffix tree는 생물학 서열 분석에 있어서 기본적인 데이터 구조 중 하나이다. 이전 블로그에서도 잠깐 언급했듯이 GPU를 이용해서 서열 매칭 작업을 병렬화 한다는 내용을 잠깐 언급한적이 있는데,,,, 이게 좀,,,

Fast Exact String Matching on the GPU와 High-throughput sequence alignment using Graphics Processing Units(MUMmerGPU)는 모두 Michael C. Schatz가 저자로써, 모두 생물학 서열에 있어서 GPU를 이용한(GPU를 사용하지 않는 MUMmer(Maximal Unique Matching)) Suffix tree 알고리즘을 병렬화하는 내용이다. 간단하게 보면, 우선 기준이 되는 Reference Sequence를 로드하고, 이에 대한 Suffix Tree를 생성한다. 그런 후에는 Query Sequence를 로드하고 이를 GPU로 옮긴 후 병렬로(GPU의 각 프로세서에서) 매칭되는 서열을 찾아내고 GPU에서 꺼내와 결과파일을 작성하게 된다.

GPU의 프로세서를 각각의 클러스터 노드로 생각하고 분산되어 서열 매칭 작업을 수행한다고 보면 되겠다. GPU에서는 메모리를 공유하기 때문에 생성된 Suffix Tree를 공유한다는 것이 다르겠지만,,, 코드상에서 심각하게 병렬화라는 단어에 지레 겁먹을 필요없이 작업만 분산된다고 생각하면 되기에 별도의 병렬화에 따른 코드 작성의 어려움은 없으리라 생각된다.

GPU를 이용한 서열 매칭에서의 제한을 잠깐 살펴보면, 논문에서도 성능 비교시 데이터를 보면 각각 Reference Sequence의 길이가 13, 3, 2Mbp로 아주 작은 길이의 서열을 사용하고 있다. 즉, GPU라는 특성상 어쩔 수 없이 Reference Sequence의 길이는 작고(메모리는 적게,,,) 많은 수(2백만개~ 2천6백만개)의 Query Sequence(분산,,,,)를 사용할 수 밖에 없는 영역에서는 뛰어난 능력을 보여 줄 수 있기 때문이다. 실제 서열 검색에 있어서 이러한 (짧은 서열 + 많은 수의 짧은 서열)에 대한것이 얼마나 많은 부분에서 유용할지는 모르겠으나,,, ^^

그럼 좀 더 실용적으로 생각해보면 Reference Sequence의 길이는 Genome-scale을 고려해야 할 것이다. 몇 십Mbp의 수준이 아니라 몇백~몇천Mbp를 염두에 둬야 할 것이다. 인간 염색체 2번을 통째로 올려놓고 몇백만개의 서열에 대해서 매칭 작업을 주욱~할 수 있을 정도로 말이다.

그렇다면 생각해봐야 할것이 어떻게 그렇게 큰 용량을 Suffix tree, 즉 메모리에 올릴 것이냐는 문제인데, 이는 디스크, 가상메모리의 활용 등을 생각할 수 있겠다.

Genome-scale Disk-based Suffix Tree Indexing - Benjarath Phoophakdee를 보면, TRELLIS라는 알고리즘을 통해서 이러한 문제들을 해결하고 있다.

trellis

Trellis: 서열을 나누고, 나눈 서열에 대해서 suffix tree를 생성해서 디스크에 쓰고, 합친 후 다시 디스크로, 그럼 큰 길이도 문제없이 suffix tree를 사용

TRELLIS외에도 TDD(Top Down Disk-based)라는 것이 있는데, 둘을 서로 비교한 자료는 다음과 같다. 이제 큰 용량도 문제없이 suffix tree를 이용할 수는 있지만, 문제는 시간이다. 1GB에 각각 372분, 103분이 걸리게 된다.

tddvstrellis

Posted by hongiiv

2008/07/22 22:10 2008/07/22 22:10
,
Response
No Trackback , No Comment
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/433

Agile development for Bioinformatics

이화여대 시스템생물학 연구소와 서울대 생명의약네트워크 연구정보센터의 주관으로 Agile을 통한 Bioinformatics 소프트웨어 개발의 생산성 향상에 관한 워크샵이 열립니다. 7월 28일 부터 8월 2일까지니까, 관심있는 분들은 많은 참여를 바랍니다. ^^

agile
Agile은 이미 BMC Bioinformatics의 "Agile methods in biomedical software development: a multi-site experience report"라는 논문으로도 나와 있죠 ^^;;

그리고 현재 구글 그룹스에 "Open Bioinformatics Korea"라는 그룹이 만들어져 있습니다. 제목만 봐도 어떤곳인지 솔깃하시죠 ^^;; 다음에 좀더 자세한 내용을 다루기로 하고, 오늘은 이정도만,,,(무조건 가입하는겁니다~~~ ^^)


Posted by hongiiv

2008/07/08 09:19 2008/07/08 09:19
, , ,
Response
No Trackback , 4 Comments
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/430

본 문서는 Grid Engine의 "Simple-Job-Array-Howto" 문서를 기반으로 만들어졌으며, 이전에 포스팅한 "스케줄러 - 기본으로 돌아가기"와 밀접한 관계가 있습니다. ^^

DRM에서의 Serial 프로그램 실행하기


많은 수의 job들을 실행하기 위해서는 어떻게 해야 할까? 1,000개의 데이터셋이 있고, 이것을 하나의 프로그램이 실행한다고 한다면, 모두 1,000개의 Shell 스크립트를 작성해서 queue에 넣어야 할것이다. 바로 이러한 자잘한? 문제를 해결하기 위해서 Grid Engine에서는 Array job이라는 해결책을 제시해 주고 있다.

-i 옵션의 인자를 입력으로 받고, -o 인자의 파일에 program의 수행결과를 쓰는 프로그램을 Grid Engine을 통해 제출한다고 하면 아래와 같은 형식의 job 제출 스크립트를 사용할 것이다.

#!sh
#$ -S /bin/bash
~/programs/program -i ~/data/input -o ~/results/output

그런데, 여기서 input1, input2, ... input.1000의 총 1,000개의 input이 존재한다면, 각각의 1,000개의 스크립트를 vi를 통해 작성하거나, 좀 배운 사람은 perl이나 python 스크립트를 통해 1,000 개의 별도의 스크립트를 자동으로 생성해주는 스크립트를 만들어 사용할 것이다. ^^

Array job을 이용한 Serial job 수행

그러나, Grid Engine의 Arry jobs를 이용하면 간단하게 한줄의 추가로 이러한 작업을 모두 해결해 줄 수 있다.

#!sh
#$ -S /bin/bash
#$ -t 1-1000
~/programs/program -i ~/data/input.$SGE_TASK_ID -o ~/results/output.$SGE_TASK_ID

Grid Engine의 -t start-end 옵션을 통해서 간단히 1,000개의 개별적인 job을 한번에 수행할 수가 있다. 별도의 작업 없이도 말이다. ^^ -t 를 통해 수행할 Array job의 갯수를 지정하면, 각각의 job은 -t에서 지정한 갯수로 나뉘면서 각 노드에 할당되고 각 노드는 현재 자신이 몇번째 작업을 수행하는지를 $SGE_TASK_ID 변수에 가지고 있어, 이를 통해 Grid Engine이 할당해 준 array를 수행하고 결과를 내게 된다.

이것만으로도 serial 한 job들을 손쉽게 수행할 수 있지만, 좀 더 응용해서 복잡한 문제들을 해결해 보도록 하자.

#!sh
#$ -S /bin/bash
#$ -t 1-1000
if [ ! -e ~/results/output.$SGE_TASK_ID ]
then
~/programs/program -i ~/data/input.$SGE_TASK_ID -o ~/results/output.$SGE_TASK_ID
fi

bash shell의 if를 통해서 job을 할당받은 노드는 결과 파일의 유무를 확인하고 program을 수행하게 된다. 이렇게 스크립트를 통해 해당 결과가 없을때 수행하게 한다면, 후에 하나의 노드를 통해 해당 program을 수행하거나 하는 경우나 실수로 엔터를 잘못 눌러 다시 수행될때( 있으려나 ^^)에 어느 정도 유연성을 줄 수가 있다.

이처럼 아주 간단한 -t 옵션과 $SGE_TASK_ID이지만, bash shell과 만나면서 더욱더 다양하게 응용될 수 있다. 이제 하나씩 살펴 보도록 하자.

각 프로그램마다 옵션을 달리하고자 하는 경우

위의 예제와는 달리 각 실행되는 프로그램마다 옵션을 달리해야 하는 일이 발생한다면 어떻게 해야 할까? cat과 head, tail이 그 문제의 해답이다. 먼저 각 옵션만을 별도의 파일로 작성한다. simulation이라는 프로그램이 있고, 여기서 -s 옵션의 인자를 각각 달리 해주고 싶다면,  SEEDFILE을 하나 만들어서 각각의 라인에는 옵션의 값들을 적어준다.

seeds 파일
=======================
45
90
.
.
.
1,000번째의 옵션값
=======================

#!/bin/sh
#$ -S /bin/bash -t 1-1000
SEEDFILE=~/data/seeds
SEED=$(sed -n -e "$SGE_TASK_ID p" $SEEDFILE)
~/programs/simulation -s $SEED -o ~/results/output.$SGE_TASK_ID

이렇게 되면 -s의 값으로는 45, 90...의 값들이 각각 들어가게 되어 하나의 프로그램이지만 인자가 서로 다른 프로그램들이 Grid Engine을 통해서 실행되게 된다.

파일의 순서가 1이 아닌 0부터 시작한다면, Array job 설정시 -t 0-999 이거~ 안된단다,, 0을 인식 못한단다. 그렇다고 기존에 0부터 매겨진 파일이름을 1부터 시작하도록 바꿔야 하는것인가?
아니다. 간단한 bash로 0부터 시작해 보자.

#!sh
#$ -S /bin/bash
#$ -t 1-1000
let i=$SGE_TASK_ID-1
if [ ! -e ~/results/output.$i ]
then
~/programs/program -i ~/data/input.$i -o ~/results/output.$i
fi


R과 같은 대화형 프로그램을 수행하고자 한다면

-1만 해주면 되는것을,,, ^^ 그럼 이제 마지막으로 좀 더 고급스럽게 array job을 사용해 보도록 하자. R과 같은 대화형? 프로그램을 사용하고자 하는 경우에는 어떻게 처리해야할까? 이런 경우 R을 실행한 후 "EOF", "/dev/null" 등을 사용해서 각 파일의 값을 R에서 읽고 결과 파일을 생성해 보자.

#!sh
#$ -S /bin/bash
#$ -t 1-10
WORKDIR=/Users/jl566/testing
INFILE=$WORKDIR/data.$SGE_TASK_ID
OUTFILE=$WORKDIR/data.$SGE_TASK_ID.out
# R 실행파일의 경로를 PATHTOR에 지정해준다.
PATHTOR=/common/bin
if [ -e $OUTFILE ]
then
rm -f $OUTFILE
fi
# "EOF" 사이에 원하는 R 커맨드를 입력하고 그 결과 파일을 OUTFILE에 쓴다.
$PATHTOR/R --quiet --no-save > /dev/null <<EOF
x<-read.table("$INFILE")
write(mean(x\$V1),"$OUTFILE")
EOF

여러가지 상황에 대해서 Grid Engine의 Array job을 이용해서 serial job을 간단하게 수행하여, 생산성을 높일 수가 있다. 비록 Grid Engine에 국한되어서 설명되어 있지만, 각각의 상황들은 손쉽게 다른 DRM(PBS, OpenPBS, Torque, LoadLeveler)들에 응용되어 사용될 수 있다.

잘 이해가 되지 않는다면, 참고한 원본 문서(http://wiki.gridengine.info/wiki/index.php/Simple-Job-Array-Howto)를 살펴 보기를 권한다. 다시 한번 말하지만, 여러가지 상황에 맞도록 적절한 스크립트와 DRM을 사용한다면, 대량의 분석작업이 간단하고 빠르게 수행할 수 있을뿐 아니라, 논문도 ^^;; 가능하다.



Posted by hongiiv

2008/07/07 12:29 2008/07/07 12:29
, , , ,
Response
No Trackback , a comment
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/428

Job Scheduler로 보는 맞춤형 의료 서비스

민간 우주 여행, 로봇의 달탐사, 10일 안에 100명의 Genome 염기서열 분석 모두 꿈 같은 이야기이지만, 그 꿈같은 이야기들이 X PRIZE 재단에 의해서 커다란 상금을 걸고 진행중이거나 이미 끝난 대회이다.

2006년 개인의 맞춤형 의료 서비스의 진입을 위하여 X PRIZE에서는 민간에서 10일 안에 100명의 Genome을 해석할 수 있다면, 그것도 Genome 당 $10,000 이상의 비용이 들어가지 않도록 해낸다면, $1,000만 우승 상금을 얻게 된다. 이것이 바로 Archon X PRIZE for Genomics 이다.

그럼 이러한 일을 가능하게 하는데 중요한 역할을 하는 것이 무엇일까? 바로 Grid 컴퓨팅이나 클러스터 컴퓨팅의 Job Scheduler, DRM(Distributed Resource Manger)이다. ^^;; 바로 이전 포스팅에서 언급했던, 생물학적인 원리를 바탕으로 대규모의 서열 데이터가 시퀸싱 기계에 의해서 쏟아져 나오면 초기 데이터로 부터 서열을 얻기까지는 바로 대량의 컴퓨팅 파워가 필요하고, 이때 대량의 컴퓨팅 리소스를 잘 분배, 관리하여 원활하게 대규모의 컴퓨터를 사용하기 위해 필요한 것이 바로 Job Scheduler, 흔히 DRM이라고 불리는 그것이다.

이러한 DRM의 하나인 Grid Engine의 블로그를 보면 Illumina의 시퀸싱 기계에서 서열을 얻는 과정에서 Grid Engine이 핵심적인 역할을 수행하고 있으며, 이를 위한 Google 그룹스 페이지도 소개하고 있다.(Google Groups: Grid Engine Life Science SIG)


Illumina는 아니지만, ABI의 shotgun sequencing을 위한 DNA Analyzer들 (출처:  Flickr )

User inserted image
Grid Engine이 장착된 Illumina의 genome analyzer ^^(출처: Grid Engine Blog)

이전에도 언급했지만, 이제 생물학 분야에서는 대용량의 데이터는 뗄래야 뗄수 없게 되었고, 그 중심에는 클러스터나 그리드와 같은 대용량의 컴퓨팅 파워는 필수적이 되었다. 또한 이러한 대용량 컴퓨터의 리소스를 효과적으로 활용하기 위한 DRM의 중요성 또한 다시 한번 생각해 보게 된다.

^^이게 다 금요일의 논문 덕택이군,,,


Posted by hongiiv

2008/07/07 02:12 2008/07/07 02:12
, , , , , , ,
Response
No Trackback , No Comment
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/427

천식과 관련된 protein interation 네트워크

네이버 뉴스를 기웃거리다가 생물정보학으로 천식 유발 후보 유전자 찾았다 라는 기사를 보고 이건 또 뭐야! 하면서 기사를 클릭했더니 요즘 꽤나 흥미를 가지고 있던 바로 질병 네트워크에 관한 논문의 기사였다. 뭐~~

A protein interaction network associated with asthma

more..


아직 논문을 보지 못했지만,, 지금까지 전체 네트워크에 대한 overview 논문에서 특정 질병을 target으로 했다는것,,, 이전 포스팅에서 asthma 이야기가 나왔었는데, 이런 유연의 일치가 ^^;; supplementary material이 작동을 하지 않는다. gene 전체 리스트와 분석한것이 들어있다는데,,,


Posted by hongiiv

2008/06/27 10:44 2008/06/27 10:44
,
Response
No Trackback , No Comment
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/422

질병 네트워크

final2

원은 하나의 질병을 나타내며, 원의 크기는 현재 질병과 다른 질병들과 관련되었음을 상대적으로 나타낸것으로 원의 크기가 클 수록 해당 질병이 다른 질병들과 연관이 많음을 나타낸다. (AIDS의 경우 4개의 서로 다른 질병과 연관이 있으며, Colon cancer의 경우 34개의 다른 질병들과 연관이 있다.)

원들 사이의 선은 서로 같은 유전자가 질병에 관여하면 질병간에 연결선이 생성된다. 선의 굵기가 굵을 수록 두 질병간에 연관된 유전자가 많음을 의미한다.(Diabetes mellitus와 MODY의 경우 총 5개의 유전자가 일치하기 때문에 굵은 선으로 연결되어 있다.)

Pajek 질병 네트워크 파일
(다운로드 하셔서 Pajek에서 열어서 보시면 위의 네트워크가 보입니다.)


추가 : 각 질병에 대해서 카테고리를 설정해서 원의 색상을 다르게 하려고 했지만, 논문(그냥 카테고리 만들었다고만 나옴 ㅜㅜ)이나 그 어디에서도 질병에 대한 카테고리 정보가 없어 그냥 오륀지 색으로 통일~~



Posted by hongiiv

2008/06/23 18:00 2008/06/23 18:00
,
Response
No Trackback , 7 Comments
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/421

BioBlogRSS에서는 - 2008년 6월 23일 #1

BioBlogRSS에 올라오는 블로그의 글들을 요약해서 남겨 놓기로 했다. 너무 많은 글들이 올라오고 있는(?? ^^) 상황에서 좀 정리한다는 의미와 함께 이렇게라도 조금이나마 남기다 보면 Bio::Blogs처럼 되지 않을까?? ^^ 완전 주관적인 나의 관심을 끈 내용을 위주로!!!

오늘은 그 첫번째로 4개를 선택해 봤습니다. 박사 논문을 준비중이신 분들에게 유용할 LaTeX관련 글과 함께 HTML 문서를 조금이나마 수월하게 만드는 방법이 준비되어 있습니다. 그 다음은 RSS를 이용해서 자신의 친구들의 Flickr, 블로그 등등 온갖 Social 웹사이트의 RSS를 불러와 감시??하는 FriendFeed와 태그 클라우드를 만들어주는 사이트입니다. 모든 글들은 BioBlogRSS에 있습니다. ^^

오늘의 팁
아직도 HTML 태그로 웹페이지를 만드시나요?? 좀더 세련된 방법으로 - 출처블로그
논문 준비중이신가요?? 멋드러진 LaTeX 로 박사 논문 준비를...- 출처블로그

오늘의 재미거리
친구들이 궁금하다고요?? FriendFeed로 친구들 감시하기 ^^ - 출처블로그
Wordle : 태그 클라우드를 만들어 보자. 자바애플릿을 만들어진 태그 구름 만들어주는 사이트 - 출처블로그


Posted by hongiiv

2008/06/23 09:47 2008/06/23 09:47
Response
No Trackback , No Comment
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/420

질병 네트워크 - 알츠하이머와 천식

알츠하이머천식이 관련이 있을까? 에이즈알츠하이머와의 관계는? 이러한 물음에 대한 접근을 보여주는 아주 재미있는 논문이다. 고려대학교의 고광일(물리학)교수의 논문이다. 처음에는 질병들간의 네트워크를 그리더니 이제는 약물과의 관계까지 ^^

The human disease network
Drug-target network
Mapping the Human 'Diseasome'

가장 기초적인 작업은 질병에 대한 정보를 제공하는 OMIM 데이터베이스에서 각 질병과 그 질병에 관여하는 유전자를 추출하고, 타 질병의 유전자와 일치하는 질병들간에 네트워크를 작성하는 것이다. 참 간단한 아이디어인데,,, 누구도 시도하지 않았다는것,,, ^^

박모박사님이 논문세미나 시간에 발표한 논문이었는데, 하나 그려 놓으면 재미있을것 같아서 데이터 파싱해서 일차적으로 Pajek을 이용해서 네트워크를 작성했다. 이제 질병의 카테고리별로 색상을 다르게 하고, 두 질병간의 공통된 유전자가 많을 수로 연결선을 굵기를 다르게 하는 것 정도만 추가하면,,, ^^ 암들은 서로 긴밀하게 엮여있군,,, 다음의 두 논문과 뉴욕 타임즈 기사를 기초로 작성하고 있고, 추후 작성 방법에 대해 포스팅 ^^;;

20
질병 네트워크(일부 ^^)

222
알츠하이머(Alzheimer disease)와  천식(Asthma)


Posted by hongiiv

2008/06/20 10:47 2008/06/20 10:47
, ,
Response
No Trackback , 8 Comments
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/418

어제 PubMed의 검색 결과로 나온 논문을 클릭하면 유사논문 찾기 서비스에 대해서 잠깐 언급했는데, 오늘은 PubMed의 검색결과를 impact factor 순으로 정렬해서 보여주는 것에 대해서 이야기 해보려고 한다.

BioBlogRSS에 자주 등장하는 YOKOFAKUN 블로그의 Pubmed, impact factors, sorting and FriendFeed 글에서 나온 이야기이다.

여기에서 우선 jar 파일을 다운로드한 후, PubMed의 검색결과를 XML 형태로 저장한다. Display 형태를 XML로 하고 File을 선택하면 XML 형태의 pubmed_result.txt 라는 검색결과 파일을 얻을 수 있다.

User inserted image

그럼 준비된 jar 파일을 PubMed검색결과 파일을 입력으로 주고 실행하면 sort된 결과 XML 파일을 얻을 수 있다. 뭐 그닥 유용할까??? 네이버 논문이 맨처음이네,,^^

User inserted image

그런데 중요한 것은 sort하는 프로그램을 만들었다는게 중요한게 아니다,, 간단한 자신의 생각을 twitter에 올리고 여러 사람들에게 정보를 얻어서 뚝딱 만들어지게 되는 그 과정이 참 재미있다.



Posted by hongiiv

2008/06/11 15:15 2008/06/11 15:15
,
Response
No Trackback , 2 Comments
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/416

Embarrassingly parallel and BLAST

Embarrassingly parallel: 완전하게 독립되어 각각의 프로세서에 나누어 실행될 수 있는 병렬화의 하나~ 각 sub task와의 커뮤니케이션이 필요없는,,, 아래 그림에서 coarse-grained parallelism이 여기에 속할 수 있겠다. Grid Computing의 응용의 하나인 SETI@home이나 MapReduce도 Embarrassingly parallel쪽의 병렬화라고 볼 수 있겠다. ^^


parallel
Coarse-Grain, Fine-Grain Parallel

Picture 7
embarrassingly parallel: disconnected computational

Picture 8
embarrassingly parallel: master-slave approach

요 몇일 Hadoop 예제를 돌려보면서, 이 예제들을 BLAST와 같은 서열 유사성 검색에 사용하면 꽤나 재미있을것 같다는 생각이 들었다. wikipedia에서 언급한 것과 같이 Embarrassingly의 예에  BLAST searches in Bioinformatics가 있는 것처럼 오래전부터 sequence search 부분에서는 이미 많은 병렬화에 관한 논문과 mpiBLAST와 같은 프로젝트들이 나와 있다. 이것저것 신경쓸거 없이 그냥 HDFS에 서열파일들을 몽땅 넣어고서는 MapReduce로 처리해 버리면 꽤나 심플?할것 같은데,,, ^^


Posted by hongiiv

2008/06/05 09:48 2008/06/05 09:48
,
Response
No Trackback , No Comment
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/411

인간 광우병과 한국인


요즘 쇠고기 수입과 맞물려 인간 광우병으로 불리는 변종 크로이츠펠트 야콥병(vCJD)이 한국인에게서 아주 취약하다는 말이 나오고, 한간에서는 쇠고기가 수입되면 미국인과는 달리 한국인은 모두 인간 광우병에 걸려 죽을거라고 걱정을 하고 있다. 뭐 많은 이야기야 BRIC에서도 한창 논의가 뜨겁게 이루어지고 있다.

유전적 변이(Genetic Variation)
여기서 말하고자 하는 것은 한국인이 다른 인종과 다르다는 것이다. 사람과 사람, 인종과 인종간의 차이는 분명 존재하고 그 차이로 인해 너/나, 한국인/영국인이라 불릴 수 있는 것이다.

사이언스가 선정한 유전적 변이 연구
2007년 마지막달 나온 사이언스지를 보면 "올해의 짱(breakthrough of the year)"에 인간의 유전적 변이(Human Genetic Variation)이 장식하고 있다. 장비의 발달과 기술의 발달로 인간의 DNA를 해독하는데 비용이나 시간적으로 많은 향상을 가져왔고, 이를 기반으로 사람과 사람과의 차이점을 알아내려는 연구가 진행중이다.

Human Genetic Variation

0.01% 차이점을 찾아라
초기 인간 지놈(Human Genome) 프로젝트에서 여자 3명 남자 2명의 DNA 샘플을 이용해서 분석 완료하고 32억 염기쌍(base pair)의 염기 순서를 밝혀냈지만, 신뢰하기 힘든 고작 5명의 샘플로 인해 그 신뢰도에 대한 문제가 발생하고 있다.

covermed
Science 표지 The Human Genome

위의 사이언스지에서 언급했듯이 이제는 그 규모가 5명이 아니라 점차 대형화되고 있다. 최근 영국, 미국, 중국 등이 참여한 HapMap 프로젝트는 아프리카, 미국, 중국, 유럽의 1,000명의 분석하여 유전적 변이를 찾아내고 있다. 또한 "Genome-wide association study of 14,000 case of seven common diseases and 3,000 shared controls"라는 논문을 시발점으로 천명이 훌쩍 넘는 사람들을 비교 분석하여 질병과의 연관성을 찾아내는 움직임이 활발하게 일어나고 있다.

도대체 뭐가 다른가?
인간의 DNA는 99.9%가 같으며 나머지 0.01%의 차이가 모발의 색에서 부터 질병에 대한 위험에 이르기까지 개개인의 특성을 결정하게 되고 이러한 개개인의 유전 형질 차이를 단일염기 다형성(SNP, Single Nucleotide Polymorphisoms)라고 한다. 엄밀하게 말하자면, 위에서 언급한 HapMap도 인간의 모든 염기서열을 분석한 것이 아니라, 이 SNP를 찾는 작업을 수행한 것이다. 이러한 SNP는 유전정보의 복사 오류에서 생기는 것으로 세포들의 막수분열시기에 원래의 세포가 두 개로 나뉘면서 원래 세포의 DNA를 복사하는 과정에서 오류로 인해 차이가 발생하게 된다.
이러한 SNP 정보 또한 물려 받기 때문에 형제나 친족같에 있어서 유사한 SNP를 가지게 되고 먼 친척일수록 닮은 부분은 적어질 것이다. 마찬가지로 더 나아가 인종간에도 그 인종 특유의 SNP를 가지고 있을 것이고 이것을 밝혀내고자 하는 것이다.

여기 한국인에게 특이한 것이 있다.
바로 요즘 떠들썩 논문이 바로 "한국인에 있어서 프리온 단백질 유전자(PRNP)의 다형성"이라는 논문이다.

prion protein gene(PRNP)

아래 그림에 빨간 박스에서 보듯이 PRNP라는 유전자가 아미노산으로 번역되었을 때 129번째 코돈에 있어서 British인의 경우 Met/met가 36.79%인데 비해 Korean은 94.33%나 된다. 바로 이 부분이 영국인과 한국인 집단간의 SNP 차이로 인해 아미노산의 번역에서도 이러한 두 집단간의 차이를 보이고 있는 것이다. 그런데 문제는 지금까지 발생한 인간광우병 환자는 거의 100%가 Met/met형이라는 점이다. 뭐 알아서 생각하시면 됩니다. ^^;;

K-20080507-473879
아미노산 약자(Methionine = Met = M, Glutamic acid = Glu = E, Valine = Val = V) 

PRNP 유전자를 찾아보면 다음 그림의 하단의 Protein Sequence부분에서 단백질로 번역된것을 볼 수 있다. 이중 129번째를 보면 "M" 즉 메티오닌으로 나타나는데, 이부분이 한국인의 94.33%라는 것이다. 그럼 누군지 몰라도 여기에 나와 있는 사람은 아시아인일 확률이,,, 그렇다면 이사람은,,, ^^;;

K-20080507-476251

그럼 여기를 보면, 129번째 코돈이 "M"이 아니라 "V" 즉 발린으로 나온다. 그럼 영국인의 50.94%를 차지하는 흔한 사람이지만, 한국에서는 5.48%만 있는 인간 광우병에 걸리지,,,, 따라서 이 데이터는 외국인, 서양인이 확률이 더 높을 수 있겠다. ^^;;

K-20080507-542498

좀더 편한게 비교 해 보시라고 두 Protein Sequence를 합쳐 봤습니다. 빨간 박스 부분이 바로 129번째 부분으로 각각 논문에서 언급한 부분이 되겠습니다.

K-20080507-546179

단지 한끝 차이일 뿐인데,,,
잠깐 언급하자면, DNA가 RNA로 전사되고 마지막으로 mRNA가 단백질로 번역되게 된다. mRNA가 단백질로 번역될 때 코돈(codon)을 통해 DNA 3개의 염기와 단백질 서열 안의 아미노산 암호가 짝을 이루게 된다. Val 아미노산의 경우에는 "GUU", "GUC", "GUA", "GUG" 3개가 번역된 결과인 것이다. 따라서 위에서 언급한 URL을 가보면 맨 하단에 full mRNA 서열이 들어 있다. 이것을 단백질로 번역하는 작업한 결과는 이미 나와 있지만, 혹시나 정말 맞게 번역된것인지 확인하는 차원에서 뭐 일일이 손으로 바꿔도 되지만, DNA to protein translation 서비스에 아래의 서열을 넣고 돌려보면 된다.

K-20080507-671664입력값으로 사용된 mRNA 서열(빨간 박스 부분의 GTG 즉 GUG(T는 U로 변신)가 129번째 발린(V)로 번역된다)

바로 저 빨간박스의 "GTG"가 "ATG"로 G->A로 만 되면, 발린(V)이 아니라, 메테오닌(Met)이 되는 것이다.

K-20080507-673821
DNA to protein translation 결과(빨간 박스 부분이 바로 129번째 코돈)

논문에서도 Brithish보다 Korean이 G보다 A일(V보다 Met일) 확률이 훨씬 높다고 나왔지만, 다시한번 확인해보는 차원에서 SNP 만을 모아 놓은 dbSNP를 가보면 아래와 같이 European보다 Asian이 훨씬 A일 확률이 높은것을 볼 수 있다.

덧붙이자면, 현재 dbSNP나 논문에서 언급된 내용은 한국인의 전체 집단을 대변하기에는 그 숫자에서 좀 부족한 면이 있다. 현재 유전체센터에는 한국인 만명에 대한 정보를 가지고 있기 때문에 PRNP 유전자에 대한 것을 덧붙이면 꽤 재미 있을것 같지만, 아직 데이터를 공개하지 못하기 때문에,, 여기서는 dbSNP로 마무리한다,,, ^^

K-20080507-698698

그럼 나는?
이제 그렇다면 나는 다른 사람 또는 다른 인종과 어떻게 다르고, 그 다름으로 인해서 나에게 어떠한 것들이 몰아 닥칠 수 있을것인지에 대해서 궁금해지게 마련이다. 간단하게 광우병에 있어서 안전한지,,, 당뇨에 걸릴 확률이 높은지, 이러한 것들이 바로 개인 맞춤 의학과 연관된 부분이다. 충분한 돈이 있다면 이러한 것들을 가능하게 해주는 서비스가 바로 23andMe이다.

23andMe와 구글
일전에 구글을 창립자 세르게이의 아내인 앤 보이치키가 설립한 신생 바이오 기업인 23andMe에 290만 달러를 투자했다는 뉴스를 본 적이 있다. 단순한 투자인가? 빅브라더의 출현인가? 여러가지 말이 많지만,,, 좀 다른 관점에서 살펴보고자 한다.

구글은 구글 플랫폼이라 불리는 대용량의 파일과 분산 시스템에 대한 노하우를 가지고 있다. 여기에서 이렇게 대량의(여기서는 데이터의 물리적인 용량이 많다는 의미가 아니다.) 유전 정보(앞서 살펴본 천명의 데이터에 대한 SNP 연구시 요즘 한번에 500K 즉 50만개의 SNP, 즉 변수가 생겨나게 된다. 그럼 천개/50만개라는 거대한 배열이 생성되고, 이 데이터를 전체적으로 보면서 어떠한 질병과 연관성이 있는지 다양하게 분석하게 된다.)를 분석할 수 있는 플랫폼이 구글로 부터 합쳐진다면, 그 시너지는 실로 어마어마하게 된다는 것이다.

지금까지의 바이오인포매틱스와 관련한 프로그램들은 아직 이러한 엄청난 데이터를 다루기에는 역부족일뿐만 아니라 기존의 Machine Learning 알고리즘을 통한 분류 및 예측 또한 이러한 거대 데이터를 다루기 위해서는 분산 플랫폼이 필수적이다.

현재 연구는 의미있게 최대한 현재의 컴퓨팅 파워로 소화할 수 있을 만큼 잘라서 연구를 수행하고 있는 상황인데, 전체를 보고 연구를 수행한다면(물론 전체를 봤다고 해서 좋은 결과, 새로운 결과가 꼭 나오라는 법은 없지만,,,) 뭔가 보지 못했던 지나쳤던 것들을 볼 수 도 있게 될 것이다. 바로 이부분에서 구글이 23andMe를 통해 다른 곳들과는 다른 뭔가를 구축해 나갈 것이다.

K-20080507-555936
23andMe 우리는 개인화로 간다~~



Posted by hongiiv

2008/05/07 15:30 2008/05/07 15:30
,
Response
No Trackback , a comment
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/394

Machine learning in bioinformatics

구글의 Map Reduce는 분산 파일과 분산 컴퓨팅을 위한 프로그래밍 모델로서 이를 오픈소스로 구현한 것이 Apache Hadoop이다. 원래 구글이 검색에 사용하기 위한 것으로 수많이 웹 페이지를 분류하고 인덱싱하기 위한 프로그래밍 모델이다. Hadoop 역시 Nutch라는 Lucene 공개 검색엔진의 Indexer와 Search로 구성된  자바로 구현한 오픈소스 검색엔진의 분산 파일 시스템으로 Map-Reduce 프로그래밍 모델을 통해서 구현되었다.

여기서 주목해야 할 점은 이러한 Map-Reduce를 여러가지 Machine Learning에 적용할 수 있다는 것이다. 따라서 엄청난 변수와 입력을 다룰 수 있게 된다는 것이다. Machine learning in bioinformatics를 보면,
  • 지도(교수, 감독?)분류(supervised classification)
  • 클러스터링(clustering)
  • 확률 그래프 모델(probabilistic graphical models)
로 나누어 각각이 bioinformatics에서 어떻게 사용되는지 볼 수 있다. 이러한 Machine Learning들을 클러스터는 아니지만, 요즘 나오는 멀티 코어 CPU에서 Map-Reduce를 이용할 수 있는지에 대해서는 Map-Reduce for Machine Learning on Multicore에서 엿볼 수 있다. 여기서는
  • locally weighted linear regression(LWLR)
  • k-means
  • logistic regression(LR)
  • naive Bayes(NB)
  • SVM
  • ICA
  • PCA
  • gaussian discriminant analysis(GDA)
  • EM
  • backpropagation(NN)
의 총 10개의 Machine Learning에 대해서 Map-Reduce를 적용해서 선형적인 속도 향상을 얻고 있다. Map-Reduce나 Hadoop에 대한 세미나 자료를 보면, 어떻게 활용되는가 하는 부분에 Machine Learning이 빠지지 않고 나오는데, 그에 대한 좋은 접근을 보여주고 있다고 할 수 있겠다. 그러나 여기서 멈추지 않고, 이를 실제 구현하는 움직임이 Apache Mahout 프로젝트에서 나타나고 있다.

이전 블로그에서 봤던 GPU를 이용한 프로그래밍이나, MPI와 같은 메세지패싱에 비해서 Map-Reduce는 파일 시스템에 대한 분산까지도 고려하고, 많은 부분에 적용 가능하기에 참 매력적이지 않을 수 없다.

Machine Learning을 통해서 데이터 분석시에 한번쯤 데이터가 커서 걱정된다면, 한번쯤 알아 두어도 좋을 듯 하다.


Posted by hongiiv

2008/05/06 09:30 2008/05/06 09:30
Response
No Trackback , 2 Comments
RSS :
http://socmaster.homelinux.org/~hongiiv/rss/response/393

« Previous : 1 : 2 : 3 : 4 : 5 : Next »


야후 블로그 벳지


Site Stats

Total hits:
291450
Today:
57
Yesterday:
166