转录组不求人系列(十三): GO、KEGG富集个性化作图

Python016

转录组不求人系列(十三): GO、KEGG富集个性化作图,第1张

当富集分析完成,拿到如下的分析结果后,就可以进行作图了。

富集分析结果的可视化无非就是柱状图和气泡图,但是公司默认出图实在是太丑,所以还是自己动手修改修改。

一、常规柱状图(ggplot2)

横轴为gene counts,或者用-logP也行,填充相应的用P值或者gene counts。ggplot画图的好处就是可以进行很多调整。

二、常规气泡图(ggplot2)

气泡图与柱状图如出一辙,只是在展示方式上出现了差别。一个用geom_bar()函数,气泡图类似于散点图用geom_point()函数。

三、上下调同时展示(ggplot2)

很多时候研究者拿到差异基因后,上下调基因是分别富集的,在展示上需要同时体现二者,我们之前提到metascape可以做到: 转录组不求人系列(十二): Cell文章最喜欢用的差异基因GO、KEGG富集分析工具 ,除此之外,之前讲过的气泡图也可以展现多组的结果: 复现《nature communications》图表(四):ggplot画多组富集气泡图 。这里我们继续提供一种bar图的展示方式。将down的数值调整为负,做一列分组,就可以展示了。

当然了,以上所说的可视化还是比较常规,在基础上可以自己做调整。也有一些文章总是标新立意,有很多奇特的展现方式,我们会在之后的系列中讲解。

可视化是监控的目标之一,没有一个好的展示,再多的数据我们也很难分析。这里主要对Grafana进行介绍,前面我们虽然也展示过Grafana数据可视化的界面,但是并没有深入介绍。

书本介绍了Prometheus自带的控制台界面,开启这个功能只需要在启动命令中添加相关的参数。但是,用这个方法作图的效率实在是太低了。实际使用中,都是通过配合Grafana一起使用的。关于console template的原文链接 点我

下面介绍Grafana。

Console Teamplet虽然能满足一定的可视化需求,但是也仅仅是对Prometheus的基本能力的补充。同时使用也会有许多问题,首先用户需要学习和了解Go Template模板语言,其它其支持的可视化图表类型也非常有限,最后其管理也有一定的成本。在第1章的“初识Prometheus”中我们已经尝试通过Grafana快速搭建过一个主机监控的Dashboard,在本章中将会带来读者学习如何使用Grafana创建更加精美的可视化报表。

首先Grafana是一个通用的可视化工具。‘通用’意味着Grafana不仅仅适用于展示Prometheus下的监控数据,也同样适用于一些其他的数据可视化需求。在开始使用Grafana之前,我们首先需要明确一些Grafana下的基本概念,以帮助用户能够快速理解Grafana。

对于Grafana而言,Prometheus这类为其提供数据的对象均称为数据源(Data Source)。目前,Grafana官方提供了对:Graphite, InfluxDB, OpenTSDB, Prometheus, Elasticsearch, CloudWatch的支持。对于Grafana管理员而言,只需要将这些对象以数据源的形式添加到Grafana中,Grafana便可以轻松的实现对这些数据的可视化工作。

通过数据源定义好可视化的数据来源之后,对于用户而言最重要的事情就是实现数据的可视化。在Grafana中,我们通过Dashboard来组织和管理我们的数据可视化图表:

如上所示,在一个Dashboard中一个最基本的可视化单元为一个 Panel(面板) ,Panel通过如趋势图,热力图的形式展示可视化数据。 并且在Dashboard中每一个Panel是一个完全独立的部分,通过Panel的 Query Editor(查询编辑器) 我们可以为每一个Panel自己查询的数据源以及数据查询方式,例如,如果以Prometheus作为数据源,那在Query Editor中,我们实际上使用的是PromQL,而Panel则会负责从特定的Prometheus中查询出相应的数据,并且将其可视化。由于每个Panel是完全独立的,因此在一个Dashboard中,往往可能会包含来自多个Data Source的数据。

Grafana通过插件的形式提供了多种Panel的实现,常用的如:Graph Panel,Heatmap Panel,SingleStat Panel以及Table Panel等。用户还可通过插件安装更多类型的Panel面板。

除了Panel以外,在Dashboard页面中,我们还可以定义一个 Row(行) ,来组织和管理一组相关的Panel。

除了Panel, Row这些对象以外,Grafana还允许用户为Dashboard定义 Templating variables(模板参数) ,从而实现可以与用户动态交互的Dashboard页面。同时Grafana通过JSON数据结构管理了整个Dasboard的定义,因此这些Dashboard也是非常方便进行共享的。Grafana还专门为Dashboard提供了一个共享服务: https://grafana.com/dashboards ,通过该服务用户可以轻松实现Dashboard的共享,同时我们也能快速的从中找到我们希望的Dashboard实现,并导入到自己的Grafana中。

作为一个通用可视化工具,Grafana除了提供灵活的可视化定制能力以外,还提供了面向企业的组织级管理能力。在Grafana中Dashboard是属于一个 Organization(组织) ,通过Organization,可以在更大规模上使用Grafana,例如对于一个企业而言,我们可以创建多个Organization,其中 User(用户) 可以属于一个或多个不同的Organization。 并且在不同的Organization下,可以为User赋予不同的权限。 从而可以有效的根据企业的组织架构定义整个管理模型。

对于Grafana而言,Prometheus就是一个用于存储监控样本数据的数据源(Data Source)通过使用PromQL查询特定Prometheus实例中的数据并且在Panel中实现可视化。

接下来,我们将带领读者了解如何通过Panel创建精美的可视化图表。

Panel是Grafana中最基本的可视化单元。每一种类型的面板都提供了相应的查询编辑器(Query Editor),让用户可以从不同的数据源(如Prometheus)中查询出相应的监控数据,并且以可视化的方式展现。

Grafana中所有的面板均以插件的形式进行使用,当前内置了11种类型的面板,常用的包括:Graph,Singlestat,Heatmap, Dashlist,Table以及Text等。

其中像Graph这样的面板允许用户可视化任意多个监控指标以及多条时间序列。而Siglestat则必须要求查询结果为单个样本。Dashlist和Text相对比较特殊,它们与特定的数据源无关。

通过Grafana UI用户可以在左边的菜单栏增加一个Dashboard,然后里面选择 Choose Visualization 即可看到下面这些的面板:

选择想要创建的面板类型即可。这里以Graph面板为例,选择Graph后我们看到有4个菜单的内容需要进行设置的。

最上面的那个是Queries,在这里要定义数据源以及查询的PromQL语句;第二个也就是上图看到的,这里可以定义图表显示的内容,比如x轴和y轴的设置;第三个是General,可以定义面板的名称以及注释等;最后一个是alert,配置告警信息(Grafana也可以做告警的)。

在通用设置中,除了一些Panel的基本信息以外,最主要的能力就是定义动态Panel的能力,这部分内容会在本章的“模板化Dashboard”小结中详细介绍。

这4个设置菜单里面,最重要是第一个菜单,也就是PromQL查询语言的编写,示例为我要显示CPU的使用率的情况,我这么设置:

公式为: avg(irate(node_cpu_seconds_total{mode!='idle'}[2m])) without (cpu)

在数据源的选择那里,有好几个选项。其中default是我们前面设定的默认数据源;Prometheus是我们添加的数据源;Grafana则用于需要查询Grafana自身状态时使用; Mixed用于需要从多个数据源中查询和渲染数据的场景;另外一个Dashboard不清楚了。这里我们选择Prometheus作为数据源。

选择好数据源之后,我们要配置查询的语句。Grafana提供了对PromQL的完整支持,在Query Editor中,可以添加任意个Query,并且使用PromQL表达式从Prometheus中查询相应的样本数据。

每个PromQL表达式都可能返回多条时间序列。**Legend **用于控制如何格式化每条时间序列的图例信息。Grafana支持通过模板的方式,根据时间序列的标签动态生成图例名称,例如:使用表示使用当前时间序列中的instance标签的值作为图例名称:

当查询到的样本数据量非常大时可以导致Grafana渲染图标时出现一些性能问题,通过 Min Step 可以控制Prometheus查询数据时的最小步长(Step),从而减少从Prometheus返回的数据量。

Resolution 选项,则可以控制Grafana自身渲染的数据量。例如,如果 Resolution 的值为 1/10 ,Grafana会将Prometeus返回的10个样本数据合并成一个点。因此 Resolution 越小(1小于10,也就是默认已经最小了)可视化的精确性越高,反之,可视化的精度越低。

Format 选项定义如何格式化Prometheus返回的样本数据。这里提供了3个选项:Table,Time Series和Heatmap,分别用于Tabel面板,Graph面板和Heatmap面板的数据可视化。

除此以外,Query Editor还提供了调试相关的功能,点击 Query Inspector 可以展开相关的调试面板:

在这里我们可以配置显示的样式,这里我只自定义了左边Y轴的数字格式,选择为百分比。

在这里我定义了面板的名称已经注释

这里我没有做定义,最后的图表如下:

Graph面板是最常用的一种可视化面板,其通过折线图或者柱状图的形式显示监控样本随时间而变化的趋势。我们继续用CPU的例子来做讲解:

查询公式为

上面的箭头指向, Add series override菜单,可以让我们自定义某一条折线的样式

继续往下,这里可以定义X、Y轴的情况,比如我把左边Y轴的单位改为百分数。

继续往下,这里可以定义图例的样式,也就是我们前面定义的 {{ instance }} 的样式,这里我选择用表格来显示,显示min、max和current的值。

继续往下,这里可以定义一个阈值,图表是告警的阈值。比如说我的CPU使用率超过50%,那就会显示不同的颜色,有一条阈值线。

这里和之前一样,只定义这个面板的名称和注释。

最后的图表是:

热力图这里不做介绍,这个用得稍微少点。可以看原文 点我

Singlem Panel侧重于展示系统的当前状态而非变化趋势。如下所示,在以下场景中特别适用于使用SingleStat:

如下所示,是使用SingleStat进行数据可视化的显示效果:

我们继续用CPU来说事,比如我这里定义CPU使用率低于50%就定义主机状态为健康,否则就是不健康。

对于SingleStat Panel而言,其只能处理一条时间序列,否则页面中会提示“Multiple Series Error”错误信息。这里使用上例一样的语句去查询:

首先我们新建一个singlestat面板,然后输入公式,这时候毫无疑问出现了错误提示:

为了能够正常显示,这里我们手动指定下单个实例,修改语句为:

这时候就有数据了,接下来我们要修改图表的样式。

默认情况下,当前面板显示的是平均值,我们实际要看的是当前的值.我们还要修改显示的颜色,这里我定义了两个值,小于0.5的时候显示绿色,大于0.8显示红色,中间显示橙色;然后设置显示折线图,并设置为绿色。

为了提高数字的可读性,我们把数字替换为文字。CPU使用率低于50%的时候显示为healthy,大于50%的时候显示为unhealthy。

配置面板名称及注释

最后的成品如下:

前面我们介绍的例子中,Grafana能够方便的将Prometheus返回的数据进行可视化展示。例如,在展示主机CPU使用率时,我们使用了如下表达式:

该表达式会返回当前Promthues中存储的所有时间序列,每一台主机都会有一条单独的曲线用于体现其CPU使用率的变化情况:

而当用户只想关注其中某些主机时,基于当前我们已经学习到的知识只有两种方式,要么每次手动修改Panel中的PromQL表达式,要么直接为这些主机创建单独的Panel。但是无论如何,这些硬编码方式都会直接导致Dashboard配置的频繁修改。在这一小节中我们将学习使用Dashboard变量的方式解决以上问题。

在Grafana中用户可以为Dashboard定义一组变量(Variables),变量一般包含一个到多个可选值。如下所示,Grafana通过将变量渲染为一个下拉框选项,从而使用户可以动态的改变变量的值:

例如,这里定义了一个名为node的变量,用户可以通过在PromQL表达式或者Panel的标题中通过以下形式使用该变量:

变量的值可以支持单选或者多选,当对接Prometheus时,Grafana会自动将$node的值格式化为如“ host1|host2|host3 ”的形式。配合使用PromQL的标签正则匹配“ =~ ”,通过动态改变PromQL从而实现基于标签快速对时间序列进行过滤。

通过Dashboard页面的Settings选项,可以进入Dashboard的配置页面并且选择Variables子菜单:

用户需要指定变量的名称,后续用户就可以通过$variable_name的形式引用该变量。Grafana目前支持7种不同的变量类型,而能和Prometheus一起工作的主要包含以下5种类型:

Label属性用于指定界面中变量的显示名称,Hide属性则用于指定在渲染界面时是否隐藏该变量的下拉框。

当Prometheus同时采集了多个主机节点的监控样本数据时,用户希望能够手动选择并查看其中特定主机的监控数据。这时我们需要使用Query类型的变量。

如上所示,这里我们为Dashboard创建了一个名为node的变量,并且指定其类型为Query。Query类型的变量,允许用户指定数据源以及查询表达式,并通过正则匹配(Regex)的方式对查询结果进行处理,从而动态生成变量的可选值。在这里指定了数据源为Prometheus,通过使用node_load1我们得到了两条时间序列:

通过指定正则匹配表达式为 /.*instance="([^"]*).*/ 从而匹配出标签instance的值作为node变量的所有可选项,即:

Selection Options 选项中可以指定该变量的下拉框是否支持多选,以及是否包含全选(All)选项。

保存变量后,用户可以在Panel的Queries中通过$node的方式使用该变量,如下所示:

这里需要注意的是,如果允许用户多选在PromQL表达式中应该使用标签的正则匹配模式,因为Grafana会自动将多个选项格式化为如“192.168.113.52:9100|192.168.113.70:9100”的形式。

使用Query类型的变量能够根据允许用户能够根据时间序列的特征维度对数据进行过滤。在定义Query类型变量时,除了使用PromQL查询时间序列以过滤标签的方式以外,Grafana还提供了几个有用的函数:

例如,当需要监控Prometheus所有采集任务的状态时,可以使用如下方式,获取当前所有采集任务的名称:

label_values(up, job)

例如,有时候我们想要动态修改变量查询结果。比如某一个节点绑定了多个ip,一个用于内网访问,一个用于外网访问,此时prometheus采集到的指标是内网的ip,但我们需要的是外网ip。这里我们想要能在Grafana中动态改变标签值,进行ip段的替换,而避免从prometheus或exporter中修改采集指标。

这时需要使用grafana的query_result函数

当在一个Panel中展示多条时间序列数据时,通过使用变量可以轻松实现对时间序列的过滤,提高用户交互性。除此以外,我们还可以使用变量自动生成Panel或者Row。 如下所示,当需要可视化当前系统中所有采集任务的监控任务运行状态时,由于Prometheus的采集任务配置可能随时发生变更,通过硬编码的形式实现,会导致Dashboard配置的频繁变更:

如下所示,这里为Dashboard定义了一遍名为job的变量:

通过使用label_values函数,获取到当前Promthues监控指标up中所有可选的job标签的值:

如果变量启用了Multi-value或者Include All Option选项的变量,那么在Panel的General选项的Repeat中可以选择自动迭代的变量,这里使用了Singlestat展示所有监控采集任务的状态:

Repeat选项设置完成后,Grafana会根据当前用户的选择,自动创建一个到多个Panel实例。 为了能够使Singlestat Panel能够展示正确的数据,如下所示,在Prometheus中,我们依然使用了 job 变量,不过此时的$job反应的是当前迭代的值:

最后的结果图如下,当我选择全部的时候,自动生成了6个Panel。

基本设计思路:

类型转换、类型断言、动态派发。iface,eface。

反射对象具有的方法:

编译优化:

内部实现:

实现 Context 接口有以下几个类型(空实现就忽略了):

互斥锁的控制逻辑:

设计思路:

(以上为写被读阻塞,下面是读被写阻塞)

总结,读写锁的设计还是非常巧妙的:

设计思路:

WaitGroup 有三个暴露的函数:

部件:

设计思路:

结构:

Once 只暴露了一个方法:

实现:

三个关键点:

细节:

让多协程任务的开始执行时间可控(按顺序或归一)。(Context 是控制结束时间)

设计思路: 通过一个锁和内置的 notifyList 队列实现,Wait() 会生成票据,并将等待协程信息加入链表中,等待控制协程中发送信号通知一个(Signal())或所有(Boardcast())等待者(内部实现是通过票据通知的)来控制协程解除阻塞。

暴露四个函数:

实现细节:

部件:

包: golang.org/x/sync/errgroup

作用:开启 func() error 函数签名的协程,在同 Group 下协程并发执行过程并收集首次 err 错误。通过 Context 的传入,还可以控制在首次 err 出现时就终止组内各协程。

设计思路:

结构:

暴露的方法:

实现细节:

注意问题:

包: "golang.org/x/sync/semaphore"

作用:排队借资源(如钱,有借有还)的一种场景。此包相当于对底层信号量的一种暴露。

设计思路:有一定数量的资源 Weight,每一个 waiter 携带一个 channel 和要借的数量 n。通过队列排队执行借贷。

结构:

暴露方法:

细节:

部件:

细节:

包: "golang.org/x/sync/singleflight"

作用:防击穿。瞬时的相同请求只调用一次,response 被所有相同请求共享。

设计思路:按请求的 key 分组(一个 *call 是一个组,用 map 映射存储组),每个组只进行一次访问,组内每个协程会获得对应结果的一个拷贝。

结构:

逻辑:

细节:

部件:

如有错误,请批评指正。