Long read는 Long read alignment로....

간만에 글 투척합니다.

오늘은 Long read align관련된 내용 투척 하도록 하겠습니다.

시퀀싱 기술이 좋아져서 PacBio와 함께 nanopore가 (최근 covid도 있었고) 함께 많이 이용되고 있는데 질좋은 long read를 생산하셨다면 bwa/bowtie와 같은 short read alignment보다는 long read에 최적화된 long read alignment인 minimap2같은 tool를 사용하시는게 정신건강에 좋을 것 같습니다.

최근 제가 별생각없이 long read서열을 human genome에 aling할때 bwa mem의 -x ont2d옵션을 사용하여 진행했었는데...

통수를 후려 갈기는... (원래 통수는 후려 갈기는 맛이 좋다능)

bwa mem -x ont2d를 사용하는 경우 원래 생산된 read(raw read 개수)보다 더 많은 read 들이 aligned되는 것 처럼 보인다는... (?? 생산된게 100개 read인데 align된 read는 200개라고?)

근데 minimap2를 사용하였을 때에는 reference에 align된 read의 개수와 생산된 read 개수(raw 리드 개수)가 유사한(aka 생산된 read 개수보다 적은) read 개수를 확인 할 수 있었습니다.

개발자도 같고(Heng Li), 같은 align하는 tool인데 왜 이렇게 차이가 나느냐 

음... bwa와 minimap2를 자세히 까보지는 않았지만(못하지만) bwa의 경우 mem -x ont2d를 사용한다고 하더라도 태생부터가 short read를 위해서 만들어진 alginment이고 nanopore의 경우 마음먹고 시퀀싱이 된다면 수십 kb의 길이가 나오는 관계로 bwa mem에서 seed를 기준으로  align할때 mismatch나 error에 대해서 관대하게 조건을 잡으면서 확장을 한다로 하더라도 수십 kb까지 확장하지 못하는 경우가 발생 하고 그 경우 split이 되어 다른 reference에 align되는 경우가 발생하는것으로 보였습니다.

대신 minimap2의 경우 long read를 고려해서 만들다 보니 확장이 비상식적으로 read가 길더라도 확장을 하지 split하지 않아서 bwa의 경우와 같이 생산된 read보다 많은 read가 align된 것 처럼 보이는 이상한 문제는 발생하지 않는 것 처럼 보였습니다.

결론은 내 데이터에 맞는 mapper를 사용해서 분석하자 되겠습니다. ㅠ.ㅜ

추신: 2018년도 이런 글(Minimap2 and the future of BWA)도 있었군요;; 

출처: @ye._.vely618

Benchmarking of long-read assemblers for prokaryote whole genome sequencing

나노포어는 현존하는 시퀀서중에 가장 긴 서열을 뽑아내는 시퀀서임에는 그 누구도 부인하지 못할것입니다. 근데.. 생산된 리드의 각 base의 phred score를 보자면.. 왜 갑자기 눈에서 물이나오는 이유는 왜때문일까요?
(그렇지만 저는 de-novo할때 보수적인 그룹이 아니라면 나노포어를 권장하는건 비밀..)

여하튼.. 현재 나노포어 어셈블리 용으로 이런저런 어셈블러가 판치고 있는 난세에 누가누가 좋은지 확인하는 작업을 해서 투고하신분이 나타나셨습니다.
제목도 정직합니다. 단, prokaryote대상입니다.
Benchmarking of long-read assemblers for prokaryote whole genome sequencing

prokaryote에서도 개판이면 굳이 사용할 이유가 있겠느냐? 주의 되겠습니다.
일단 가장 좋은것은 모르겠지만 최악은 걸러내야 해야 시간 낭비, 전기 낭비 하지 않지 않겠습니까?

현재(aka 당시에) 돌려볼 수 있는 7개 어셈블러 (Canu, Flye, Miniasm/Minipolish, NECAT, Raven, Redbean, Shasta)의 성능을 비교 평가 했습니다.
어셈블리의 정확성은 당연하고, prokarypte다 보니 circularisation도 중요하고, 계산시 사용되는 리소스와 분석 시간등을 평가했다고 합니다.

아름다운 figure는 상단에 링크된 논문에서 감상하시면 되고,
canu는 그나마 볼만한 서열들을 제공해줬고
flye는 canu다음으로 괜찮은 서열로 어셈블리 했다고 합니다.
redbean(wtdbg2) 과 shasta는 계산 리소스와 분석 시간에서는 효율적이었지만 결과는 그다지 효율적이지 않았고 하네요.

그래서 종합해서 논문에서 결론을 냈는데
모.. de-novo aseeembly 해보신분이라면 알고계시다 싶이.. 다들 장단점이 있었고, 원탑인 어셈블러는 없었지만 그 중에서 Flye, Miniasm / Minipolish와 raven이지 않나 싶다고 하네요

Flye는 믿을만한 서열을 제공했고(low depth에서도 나름..)
Miniasm / Minipolish는 circularisation이 좋았고
raven은 identity가 낮은 read set들에서 tolerant가 있었다고 합니다.

역시 최적의 어셈블리를 위한 정도는 당신이 사용 가능한 리소스를 동원해서 다양하게 돌려보고 비교한 게 킹왕짱이지 남의말 믿고 쓰면 너만 바보 되고
개발자님들인 이런 상황이니 개발좀 굽신굽신 :)

출처: @sana_twice.09