NGS reads去重知多少

Posted 2023-04-22

参考技术A

在生信分析学习的初期，我们只需要跑通数据分析的整个流程即可，对于数据的质控和相应的参数没有深入探讨，但随着深入的学习，一些细节问题必须要注意（可能对结果造成非常大影响）。比如说，对于比对后BAM文件中 reads 的Duplicates是否需要去重？

原则 ：

理论上来讲，不同的序列在进行PCR扩增时，扩增的倍数应该是相同的。但是由于聚合酶的偏好性，PCR扩增次数过多的情况下，会导致一些序列持续扩增，而另一些序列扩增到一定程度后便不再进行，也就是我们常说的PCR偏好性。
这种情况对于定量分析（如ChIP-seq），会造成严重的影响。此外，PCR扩增循环数过多，会出现一些扩增偏差，进而影响一些突变识别（比如call SNP)的置信度。

对于大多数随机建库的数据均需要去重，但是对于研究特定区域的变化一般不去重，PCR建库的作用是对该区域的信号进行放大，reads的序列信息都是 一样的，主要目的是增加测序的reads数，加大测序量，也就是常规的实验理念， 增加样本量，减少系统误差 ，这样的结果更接近于真实情况。

测序所得到的reads是由于超声或者酶切断裂得到的，因此这些reads比对到基因组上的位置是完全随机的。那么两个reads比对到相同位置的概率是非常低的。如果两个reads比对情况相同或者极其相似，则很有可能是由于PCR重复所导致的。而我们常用的去重工具主要也是遵循这一思想。

该方法对于以下两种情况，有很好的去除效果：

该方法的缺点：由于samtools去重只考虑reads比对上的起始终止位置，不考虑比对情况，这种去重有时会导致测序信息的丢失。

该工具的另一个不同之处在于它不仅考虑reads的比对位置，还会考虑其中的插入错配等情况（即会利用sam/bam文件中的CIGAR值），甚至reads的tail，lane以及flowcell。Picard主要考虑reads的5\'端的比对位置，一个每个reads比对上的方向。

因此我们可以从一定程度上认为，5\'端的位置，方向，以及碱基比对情况相同，Picard就将这些reads中碱基比对值Q>15的看作是best pair而其他的reads则当作是duplicate reads。甚至当reads的长度不同时，Picard依然利用上述原理进行去重。

对Picard来说，reads的5\'端信息更为重要.若duplicates是PCR重复，那么它们的序列不一定完全相同。但是由于PCR扩增时，酶的前进方向是5\'->3\'方向，PCR重复序列中5\'端的部分相似的可能性更高。

PCR 扩增重复去除冗余首推 Picard

当然到底要不要去除重复，我们可以通过第一步数据质控进行判断，FASTQC计算了200，000 reads的质量以及分布比例，通过质量检测报告可以判断这些常规要去重的数据最后要不要进行后期的除重工作，暴力的方法就是：根据实验建库的方式，若去除的都去重（ChIP/ATAC al et)，靶向的，酶切的建库均不去重（RRBS, Target-BS）但消耗计算资源和运行时间。

参考：

C# - 执行 SslStream.Read 后如何知道 TcpClient 中剩余多少字节

【中文标题】C# - 执行 SslStream.Read 后如何知道 TcpClient 中剩余多少字节

【英文标题】：C# - How to know how many bytes are left in TcpClient after perform SslStream.Read

【发布时间】：2022-01-12 15:51:24

【问题描述】：

我正在做一个客户端-服务器应用程序，服务器将检查何时有数据可用 (TcpClient.Available > 0) 可供读取，但是当它运行 SslStream.Read 时，即使我知道我需要多少字节读取时，它仍然将 TcpClient.Available 设置回 0 并保留已读取的字节......我的代码未读取，因为条件 (TcpClient.Available > 0) 将是错误的，因此服务器不会对附加内容执行任何操作字节，直到客户端发送更多字节，这是不想要的，服务器应尽快处理客户端发送的所有字节。 这是一些代码：

static void main()

    TcpClient tcpClient = listener.AcceptTcpClient();
    SslStream s = new SslStream(tcpClient.GetStream(), false);
    //authenticate etc ...
    while (true)
    
        if (tcpClient.Available > 0) // now this condition is false until
                                     // the client send more bytes
                                     // which is not wanted
            work(tcpClient);
    

    
static void work(TcpClient c)

    //client sent 50 bytes
    byte[] data = new byte[10];
    s.Read(data, 0, 10); // I know this is not guaranteed to read 10 bytes 
    //so I have a while loop to read until it receives all the byes, this line is just for example
    
    // do something with the 10 bytes I read, back to the while loop
 
  

我的“工作”实际上创建了一个新线程来完成工作并锁定该客户端直到工作完成，以便该客户端在工作完成之前不会调用工作

因为我知道运行“工作”需要多少字节，所以我只读取该字节数并解锁客户端，以便客户端可以再次“工作”

当然还有其他客户端也需要工作，这里我只是展示一个来演示问题

【问题讨论】：

读到Read读到0字节。

SSL 层在收到完整的 SSL 记录并验证其完整性之前不会返回任何明文。

您在这里所做的，在循环中检查可用，是一件非常糟糕的事情。这称为轮询。它要么消耗 CPU 资源，要么导致可怕的响应时间。试图平衡这两个问题是毫无意义的练习。 @HaroldMorgan 解释了你应该做什么。

@Llama “读取直到读取 0 个字节”，不正确。如果读取 0 个字节，则表示套接字已关闭。

@Jeroen 取决于流，没有办法知道下一次调用Read 是否会返回 0，所以你不能停止阅读 before 它返回0 如果您希望确保阅读所有内容。因此，您必须阅读 直到 它返回 0，表明流已按您所说的那样关闭。

【参考方案1】：

您通常不知道从流中读取还剩多少字节。

但是您可以“在读取时”从流中读取，因为SslStream.Read 返回读取的字节数！

所以你的代码变成了简单的

while (s.Read(data, 0, 10) > 0)

    // do something with the bytes you've read

这是人们使用流的一般方式 - 在读取时按块读取它们。

您可以在我之前链接的文档的示例中看到它（还有更多！您应该明确地检查一下）

【讨论】：

您的示例不完整。因为您需要s.Read(..) 的结果才能知道您实际收到了多少字节。

你是对的，我链接的文档中的示例可以更好地解释整个过程，我只是试图表达“你应该如何使用流”的一般概念和提供了进一步研究问题的途径