富集分析第二弹

Posted 2023-04-08

参考技术A

富集分析，来自于Enrichment这个词语

F or example, given a set of genes that are up-regulated under certain conditions, an enrichment analysis will find which Ontology terms are over-represented (or under-represented) using annotations for that gene set.

通俗来说：富集分析是基于一个先验的知识图谱将输入内容进行聚类分析，得到聚类后结果。

上句话中逐个概念解析：

<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">GO 富集结果（柱状图）</figcaption>

结果解析：我们可以基于柱状图，清楚的看出，每一个聚类后结果（横轴下方的字段），以及每一个分类所对应的基因/基因产物数量（此图中为蛋白质数量）

上图是气泡图形式，由于GO有三个互不交集的ontology本体，所以要单独分区展示。气泡图比柱状图可以多展现1个维度，在上图中，体现了4个维度信息：

（1）气泡表示分类条目

（2）气泡大小表示基因/基因产物数量。

（3）增加了p-value的展示。p值的负对数分配给y轴（越高就越重要），统计学基础是超几何分布。（ 从总的N个基因中挑出n个基因，作为分母（这是背景基因），分子则是M个基因（我们的差异基因，这是前景基因），有k个落在了某通路里，有n-k个不落在了某通路里，然后使用超几何分布来对它们进行计算，即前景基因落在某通路的比例是否高于背景基因在这一通路的比例 ）

（4）表达量的上下调。横轴zscore表示是表达量是高了还是低了（一般应用于RNA和蛋白中，基因一般不涉及）。 [图片上传失败...(image-efb449-1611106941603)]

<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">点击一个分类，可以查看其所对应的局部知识图谱</figcaption>

得到目标对象（基因或者基因产物）的富集结果（词条）后，通过查看网站对词条的注释声明，来验证或判断目标对象作为生物标志物的合理性。

<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">方法论示例</figcaption>

示例1：《 与胰腺癌相关的重要基因本体论术语和生物学途径分析 》IF: 2.197

示例 2： 《 使用基因本体论术语和KEGG途径进行化学毒性作用分析 》 IF: 3.681

GO 功能富集分析、KEGG pathway富集分析、 GSEA 功能富集分析、 reactome 通路富集分析

（1） David ——The D atabase for A nnotation, V isualization and I ntegrated D iscovery ，支持在线进行GO功能富集分析。 工作组 很多华人（从名字上看）

（2） GOrilla ——GeneOntology enRIchment anaLysis and visuaLizAtion tool，支持在线进行GO功能富集分析。

（3） KOBAS ——KEGG Orthology Based Annotation System，支持在线进行pathways通路分析 (KEGG PATHWAY, Reactome, Biocyc, Panther), 关联疾病分析diseases (KEGG DISEASE, OMIM, NHGRI GWAS Catalog), 和GO 功能富集。北大团队做的。

（4） clusterProfiler : universal enrichment tool for functional and comparative study。推荐一个R分析工作包，是生信分析领域大牛 Y叔 写的，几乎能支持市面上常见的各类功能、通路、关联疾病分析，受science大力推荐（反正Y叔公众号上他自己是这么说的，有没有忽悠成分咱就不管了哈，但是吃过的都说香）。

以 KOBAS 为例，演示两个流程：

（1） GO分析

step i ：选择“基于基因列表进行富集分析”

step ii：在计算页面等一会，查看分析结果

step iii：查看GO的DAG图

<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">GO:3A004408</figcaption>

也有这样的：

<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">GO:0045893</figcaption>

（2）KEGG pathway分析

step i: 参数选择KEGG

step ii: 查看计算结果

step iii: 查看通路图

有些情况下KEGG会报错：

解决方法：注意将url的末尾添加一个/符号，即可正常展示。

Object Oriented个人总结第二弹

一、  分析和总结自己三次作业来的设计策略及其变化

a)       第一次作业

比较幸运第一次接触多线程的时候就可以遇到最后的方案，这次作业我运用的是synchronized+notified的策略，通过电梯线程和scheduler线程互相唤起来实现多线程的运行，而在线程不进行计算的时候就让现场wait。这样将线程的工作时间和强度降到最低，同时也保证了绝对的安全。

b)       第二次作业

由于要求限制，不得不放弃安全好用的线程互相唤醒的机制，使用不断循环扫描实现，通过每隔一定时间扫描一次进行一次快照，记录当前监控对象的状态，这种机制面临很多问题，比如如何保证一次扫描之间不会进行两次操作，好在最后对此进行了限制。

c)        第三次作业

单纯的synchronized，这次使用的县城方法比较简单，为了防止100个线程对系统资源利用过多，产生不可预料的后果，我将100辆车合并到了同一个线程，用轮询进行车的移动，车移动完之后在进行派单，虽然方法略显粗暴，但是效果奇好。再辅助以假时间的方法，可以解决非常多的问题。

二、 基于度量来分析自己的程序结构

a)       第一次作业

UML图

 类图

 

有一些方法由于刚开始的时候没有考虑清楚，写的太过臃肿，这种现象主要是集中于带有大量条件判定的方法。关于条件判定的方法比如电梯选择，可稍待判断等可以继续优化。

优点：整体设计比较清晰

缺点：条件判定想得不够清楚带来冗余。

设计原则不足：存在GOD类

b)       第二次作业

UML图

 类图

 

与上次相比较略好一些，但是对于不同的触发器操作写到了一起。导致了方法的臃肿。

缺点：针对不同情况的操作写到了一个类。

设计原则不足：Dependency Inversion Principle，责任均衡分配原则

c)        第三次作业

UML图

 

类图

 

比之前的好了很多，分派方法嵌套太深。

优点：责任分派相对均衡。

缺点：方法调用深度过深。

设计原则不足：重用原则，有功能重复的类。

三、 分析自己程序的bug

a)       第一次作业

所交版本为调试版本，所有同质请求，未按照格式输出。

b)       第二次作业

无bug

c)       第三次作业

输出格式错误扣一分

将3000毫秒误计算为14个200ms的周期逻辑错误。

d)       基本都挺脑残的。。。没啥可分析的。

四、 分析自己发现别人程序bug所采用的策略

a)       第一次作业

基本输出错误格式错误。

逻辑错误

仅靠前两项已经扣的有点多了，心软没有继续查下去

b)       第二次作业

边界测试，测出程序不能监控识别文件夹的最后一个文件

c)        第三次作业

对方由于版本问题，没有考虑gui带来的延迟导致了一系列错误。

同时依靠边界数据测出一个逻辑bug

d)       没有发现线程不安全的问题，拿到的基本上写的都不错，但是相比前三次作业而言，从中可学习的东西不是特别多，也可能我自己进步了。

五、 心得体会

a)       毫无疑问notify+synchronized是现阶段最好的方法，即可以保证的线程的安全，又能降低线程的CPU占用。也更符合现实中的情况。

b)       第六次作业全局锁真的是反人类的东西，可还不得不用，杨帅提出的对象全局共享很有意思，被我改造用到了第七次作业。

c)        增强for循环还是个好东西，方便简单。学会使用@override等注解小技巧可以提高效率。

d)       第七次作业明显简单一些，可以花时间考虑设计，这个时候难度降低有一定科学性。

e)       千万不要临结束前一分钟提交，难保出不出意外。

f)         由于之后的自由度大大提高，需要适应新的互测形势。

g)       设计原则还需磨练。