롱리드 시퀀싱을 쓰지 않을 이유가 있는가?

이번 논문은 제가 참여한 논문입니다.. 흠흠..

이름하여 Two long read-based genome assembly and annotation of polyploidy woody plants, Hibiscus syriacus L. using PacBio and Nanopore platforms

DOI: 10.1038/s41597-023-02631-z

Hibiscus syriacus, 쉽게말해 무궁화 genome을 assembly하는데 어떤 데이터를 어떤 assembly 도구로하면 그래도 가성비가 좋은지에 대해서 확인한 논문 되겠습니다.

무궁화는 full genome은 이미 몇해전에 나와있는 상태고요, 아마 무궁화가 2배체가 아니라 4,6배체로 기억됩니다. 그래서 숏리드가지고 assembly가 만만치 않았는데 그 데이터를 바탕으로 이전에는 short리드로 어렵싸리 했었는데 이번에는 롱리드 시퀀싱으로 하면 어떻게 되는지 확인 해보자 입니다.

이전 무궁화 genome project 논문에서 핸들링하는 데이터 양을 정확히는 모르겠으나 어마무시했던것으로 알고 있습니다. 거기다가 숏리드라서 양쪽 로우 퀄리티 좀 정리해주고, scaffold용 mate-paired 데이터 정리작업하는데도 아마 꽤나 시간이 걸릴겁니다.

나노포어 데이터(ONT)와 PacBio data가 있었는데, 솔까말 ONT 데이터로만 해도... 사실 갠춘합니다.

그런데 여기서 중요한것은 ONT가 중요하기도 하지만 ONT의 장점을 십분 발휘할 수 있게 해주는 DNA 뽑는게 ART되겠습니다. ONT가 길게 읽을 수 있는거지 template가 짧으면 ONT도 길게 읽고 싶어도 못읽습니다.

결국 실험자의 손이 중요합니다. 손 똥손이면 ONT도 해결 못해줍니다.

그 똥손도 가능하게 해주는게 commercial prep kit이긴한데 현재 기준으로 그런 kit이 있는지는 저는 모르겠습니다. 

여튼 그래서 ONT 데이터를 앞뒤없이 다 때려박고 assembly하지 않았습니다.

cell 하나, cell 2개, 결과가 어떻게 달라지는지 확인해고, assembly tool마다 결과는 어떻게 나오는지 확인하면서 테스트 하였고, 이거쓰세요는 하지 못했지만 그럭적럭 요정도 생산해서 이 tool쓰면 평타 칩니다 라고 가이드는 해드릴 수 있는 논문되겠습니다.

다음에는 테스트하는 code를 간지나게 git에 올려놓고 논문에 url하나 올려둘 수 있도록 해봐야겠습니다. :)

그럼 또 쓸만한 논문을 찾아 돌아오도록 하겠습니다.

출처: @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