目前我们主要分析的数据还是二代测序的数据,也就是大家经常挂在嘴边的 NGS,而这其中最大的赢家应该算是 illumina
测序公司了,其经典的边合成边测序(sequencing by synthesis,SBS)巧妙地利用带不同荧光的dNTP来让碱基组成可视化,本身还是很有意思的。但随之而来的就有一些问题,比如以RNA-seq为例,如果你是一个经典的从表达矩阵开始的数据分析选手,那其实建库细节对你来说好像也没那么重要;而如果你是一个从原始fastq下机数据(甚至建库实验)开始的数据分析选手,此时建库的细节就可能显得尤为重要,需要你做到知根知底。或许你经常遇到一些名词,其中有一些可能让你感到迷惑:
桥式PCR
链特异性RNA测序
sample index
adapter
簇生成
- ……
现在我们就以illumina经典的 TruSeq Stranded mRNA 建库测序为例来走一遍整个illumina测序的流程,为什么会选择这个建库策略呢?首先,RNA-seq是目前我们触手可及、应用最广的基因表达量检测技术;其次,相较之于链非特异性测序,链特异性测序对大多数人来说更复杂,更难以理解。关于链特异性测序我之前已经有一个长篇大论谈到了这个问题:一文阐述链特异性测序——stranded? reverse-stranded? un-stranded?,阅读量还不错,反馈也还可以,有兴趣的可以去看看,在这里就只以 TruSeq Stranded mRNA 为例了。
An overview of TruSeq Stranded mRNA sequencing
老规矩,我还是以图辅以文字的方式来先整体介绍一下 TruSeq Stranded mRNA :
对着流程看,提前说一下,红色始终代表sense strand的信息,天蓝色代表antisense strand的信息:
- 首先,我们需要利用成熟mRNA带polyA尾的特点,通过oligo dT来富集出mRNA;
- 接下来我们使用超声来对mRNA进行片段化,然后再使用随机引物进行反转录,这个过程就是第一条链的合成;
- 接下来我们使用诸如RNaseH的酶来消化降解掉杂合链中的RNA,然后再进行第二链的合成,不过这里我们不使用dTTP,而是使用dUTP。
- 使用Klenow酶来给3'末端添加一个突出的A;
- 连接adapter,注意这里的adapter结构哦;
- 然后再进行PCR,由于DNA聚合酶不能以dUTP为模板,所以以sense strand为模板的链没有办法参与到PCR中,因此最终的双链DNA都是右下角那样的。
我们最终可以看到,Read1测到的是antisense strand的信息,Read2测到的是sense strand的信息,这和我们之前的理解是一样的哈。
illumina测序细节
注意了,我们现在回到这个结构,开始走上机测序的流程:
首先illumina测序用的东西叫:flowcell,这个结构的底部有很多的多核苷酸链,这些多核苷酸链是与我们的p5和p7接头互补的。
我们以一条DNA单链为例,首先它的P5接头序列会和flowcell上面的P5接头互补序列结合,然后会发生DNA的合成,注意合成完了之后,由于flowcell上面的接头互补序列是和flowcell共价连接的(已经用黄色圆圈标识出),所以很稳定,我们使用碱性溶液冲洗flowcell时,靠共价键连接在flowcell上的链并不会被冲洗掉,反之另一条链就被洗掉了,最后就成了最右边的那种情况。
接下来,发生了第一个名词的过程:
桥式PCR
:
它为什么叫
桥式PCR
,其实很简单,就是因为中间进行PCR的时候像一个拱桥一样。同样的DNA合成后用碱性溶液就能使DNA双链解链,但是由于P7是共价连接在flowcell上的,所以不会被洗掉哦,如此重复进行桥式PCR
,最终就会形成一个簇,第二个名词出来了,那就是簇生成
。你会发现这一簇单链DNA其实都是来自于一条起始DNA单链,也就是说,这一簇DNA实际上表征的生物学信息是一样的。有人会问,为什么要这么麻烦桥式PCR呢?回答这个问题就会提到边合成边测序了,单个碱基的荧光终究是比较弱的,但是很多个碱基的荧光聚在一起就会很明显了,就足够我们去准确判断碱基类型了。这就是为什么我们要进行桥式PCR的原因。下面开始测序,你就知道桥式PCR妙在哪里了:
我们先把连接在P5上面的链洗掉,就成了上图左边的情况,然后我们让read1的primer结合上去,边合成边测序,记住,这里一簇DNA有很多这样的链,所以你看到的荧光信号会很强,如果没有桥式PCR,你就不可能实现这样的效果。需要注意的是,我在这里把sample index也标出来了,为什么会有这个东西,因为实际上有时候一个flowcell的测序容量还是很大的,为了不造成浪费,很多时候我们会把来自不同样品的文库混在一起测,那我们在建库时就加上不同的sample index,但时候我们就能够根据这个sample index序列区分reads不同的样品来源了,一般如果有这个序列会以类似于I1.fq.gz的形式返给你,但实际上我们很少收到这个结果,就是因为测序公司下机后就会根据这个sample index把reads分好,所以你就只会拿到你的序列。
下一个名词:
双端测序
,为什么会有这个双端测序
,实际上很简单,如果一条DNA序列很长,我们可能没办法通过一条reads把它全部测完,但同时我们又要精确定位其在基因组上的位置,这时双端测序就派上用场了,当我们把这个DNA的两端都测了之后,就知道这个DNA的两端分别在基因组的什么位置上了,这样即使中间还有一段我没测到也没关系,两端的位置已经决定了这个DNA片段在基因组上的位置了。这就是我们常说的Read1和Read2了,这里就简单说一下Read2是怎样产生的了:接着上面的图,同样的我们再进行一次桥式PCR,这时候flowcell上的P5接头也会“长出”一些序列,然后我们这次洗掉连接在P7上的序列,上下的就只有P5连接的序列了,再把Read2的测序引物加进去就能测得Read2了。
文库结构——到底什么是adapter?测序引物结构又是怎样的?
做过fastq文件比对的人都知道,这个过程中非常重要的,大家挂在嘴边的就是去接头,第三个名词出来了:adapter
。那么到底什么是接头?fastqc这样的软件又是怎样检测到的?cutadapt、fastp、trimmomatic、trim_galore这些软件又是怎么去接头的?似乎这些都是灰色地带,下面是我的理解:
首先还是看文库结构:
首先声明一个事实:
一般来说,我们不管是read1还是read2从哪里开始测,哪里就是我们想要的真实生物学序列了;
这实际上很好理解,我们没有人去adapter是从fastq文件中每条read的开头去的。那么什么是adapter呢?你可以简单理解为,在一个文库中,非生物学序列的其余序列都属于adapter,包括P5、P7、测序引物结合位点。那么fastqc是怎么检测adapter的呢?你去看看fastqc的GitHub,会发现它有这样的几个序列:
Illumina Universal Adapter AGATCGGAAGAG
Illumina Small RNA Adapter ATGGAATTCTCG
Nextera Transposase Sequence CTGTCTCTTATA
SOLID Small RNA Adapter CGCCTTGGCCGT
你可能会觉得很神奇,其实fastqc判断你的序列有没有adapter就是在和这几个序列做简单的匹配罢了。接踵而来的问题就是:
-
为什么这几个序列就能帮我们判断adapter的有无,按照我们的理解来说不应该adapter序列会很多样吗?
-
这几个序列到底在文库的哪里?
首先给答案:
-
这几个序列在测序引物的3’端;
-
由于基本上所有的引物3'端都是这些序列,所以我们可以通过这几个序列判断adapter。
听起来很离谱,画个图就清楚了:
上面这个图展示了read1产生的全过程,显然红色部分都是我们想要的生物学序列信息,直到绿色部分就不是了,因为绿色部分实际上测的是read2的测序引物结合位点序列了。收到这样的启发,灵感来了:
那我们判断一下一个read里面有没有测序引物结合位点就知道这个序列是不是有adapter了。
实际上就是这样的。不信我们就来验证一下:
这份文库结构的注释来自于近岸蛋白的CUT&Tag试剂盒:
按理来说我们的测序引物结合位点应该在图中的黄色位置,按照我上面的理论,我们可以通过
CTGTCTCTTATA
来判断我们读到adapter了,实际上呢?回顾一下fastqc的那几个adapter的序列:
Nextera Transposase Sequence CTGTCTCTTATA
果然,不能说完全相同,只能说一模一样,也就是说,现在市场上所有的Tn5转座酶都必须将这段序列连接到DNA的两端,这样才能让我们检测到adapter。
你可能还是不信,好吧,那再来一个其它的例子吧:
这份文档来自于illumina官方,我们看看这两个测序引物的3'端是不是可以作为我们检测adapter的标准哈,把read1的测序引物碱基互补配对一下(为什么就不赘述了……):
5'-AGATCGGAAGAG-3'
,然后看一下我们的fastqc中的这个adapter:
Illumina Universal Adapter AGATCGGAAGAG
这不能说完全相同,只能说一模一样吧……总该信了?
结束了上面的测试,你或许会发现一个问题:那按这么说,是不是read1和read2的测序引物的3'端总是会有部分是一样的啊?一样的部分就是作为判断adapter是否存在的那条序列?你自己看看上面的那个图,不就知道了,事实上就是这样。
最后,为了让你更信,我还把trim_galore的adapter序列也粘贴在这里,这不和fastqc的一模一样?原来纷繁复杂的illumina测序竟然这么统一!