本文是老白在1月16日PG中国大会上的演讲内容，全文有4500多字，阅读时间可能超过10分钟，请慎重阅读。

各位PG Funs下午好，我是老白。在疫情下2021 PG大会能够顺利进行十分不易。看到第二天下午的四点多钟，会场的上座率这么高，看得出PGer的热情十分高涨。可能认识老白的人会觉得奇怪，你不是混Oracle圈子的吗？怎么到PG大会来演讲了。这也充分说明了PG社区的红火，越来越多的Oracle DBA开始参与PG社区了。开源社区中对MYSQL和PostgreSQL到底谁更好的讨论一直存在，甚至对二者的开源协议也多有议论。Mysql的支持者认为GPL开源更注重代码贡献者的权益，并在约束用开源代码去卖钱，而BSD开源协议往往会让大企业从开源社区吸血。实际上也不尽然，BSD开源协议有着更宽松的限制，虽然大企业可以从开源社区吸血，对于小企业和用户来说，也是有利的。

现在用PG的用户越来越多，不过PG数据库的运维就面临了很大的困难，今天老白和大家分享的题目就是“基于知识图谱的PostgreSQL数据库深度分析”，希望通过我们团队的一些工作成果，给大家一些PG运维工作上的新启示。

首先我们来分析一下PG数据库运维的难点有哪些。首先是和Oracle等传统商用数据库相比，甚至和目前流行度排名与Oracle几乎相当的MYSQL数据库相比，PG数据库的运维人员比较少，高水平的DBA更是缺乏，因此一旦企业内的PG数据库出问题，想要花钱找人来帮助解决都比较困难；其次是，PG数据库和其他开源数据库一样，在技术上依靠社区的力量，没有传统商用数据库的原厂支持，第三方的服务团队也相对较少；第三个方面是PG数据库自身的问题，PG数据库自身可用于监控、分析的指标数据也比Oracle等较为成熟的数据少，运维监控工具也相对比较简单，仅能监控一些简单的运行状态，真正系统出现问题，用于定位问题的分析手段也十分有限；第四是目前PG数据库的网上资源十分缺乏，无论是中文资料还是英文资料都十分缺乏，反倒是日文的资料相对丰富一些，这和PG数据库在日本大企业有较为广泛的应用有关；最后是，对于大多数实用PG数据库的企业来说，运维经验的积累几乎为0，大家都才从0开始积累自己的运维团队，运维能力与运维工具。

因为我今天要和大家探讨的就是一种构建PG运维经验，并利用运维经验的积累来实现运维能力提升的方法，我们把这个称之为“运维知识自动化”，这个运维知识自动化不同于“运维自动化”，运维自动化是实现运维中各种操作的自动化，比如部署自动化，变更自动化，迁移自动化，采集自动化，备份自动化等。这是一种“知识自动化”的应用模式，把各种知识，包括专家知识，AI能力等变成制动化的工具，用于日常的运维工作。

那么利用知识自动化的技术如何来做故障定位呢？我们用基于知识库的智能分析与传统的故障定位来做一个比较，不仅仅是针对PG数据库，针对Oracle等传统商用数据库也是如此的。传统的故障定位是依靠专家的经验，专家通过对日志，采集的各种报告与指标数据，并以某些运维工具作为辅助，进行人工分析；分析的结果与专家的水平有关，有时候好像分析出问题了，也不一定是正确的，特别是对于一些亚健康问题，表现出来的时间很短，等到专家到现场的时候，这个现象已经无法重现了，用于分析的指标，日志等也很少，往往会不了了之。甚至是一些数据库宕机等的严重故障，也往往缺少足够的数据，只能做一些猜测。有过MOS开SR经验的Oracle DBA都有过这样的经验，大多数的SR都因为故障无法重现，缺少分析所需要的资料，最终都属于SUSPEND状态了。

如果我们能够汇聚各类专家的经验形成一个知识库，并且在这个知识库的基础上构建一个自动化分析的工具，这样我们就不需要有专家到现场，就可以利用这些积累下来的经验进行深度分析了。而且随着时间的推移，这个知识库会积累的越来越完善，自动化诊断分析的能力也会越来越强。

我们怎么来构建这个运维知识自动化的体系呢，上图是一张逻辑架构图。“运维知识自动化系统”是基于专家模型和人工智能模型双引擎为核心研发的运维自动化工具。 核心价值源于打了专家与现场运维经验积累与弱监督学习形成的四大核心模型：健康模型、负载模型、性能模型、故障模型。

首先通过专家的知识积累与运维经验的犨县，实现了全量指标与日志等运行状态相关的数据采集，利用“智能知识库”发现系统中存在的异常场景，并在“智能算法库”中选取适当的算法对指标进行异常检测。对于发现的隐患，进入智能案例库，并自动启用智能数据分析算法对该案例进行全面分析诊断，最终由三线专家对该案例进行标注。标注结果用于进一步改进“智能知识库”和“智能算法库”。并利用智能知识库与智能算法库在今后的运维工作中用于亚健康状态的自动发现与故障溯源分析定位。

实际上任何运维自动化工具离开了人都无法发挥最大的作用，因此在这个体系中运维人员与三线专家团队也具有十分重要的作用。运维人员是运维知识自动化生态体系中的一线工作人员，他们是数据收集、运维案例收集、一线诊断分析的主力，而三线专家团队可以是一个虚拟团队，由各个领域的专家组成，负责对疑难案例的分析，故障场景的抽象、知识抽象、数据标注等工作。

智能化分析最为核心的支撑技术是高效的“智能异常检测”，通过智能异常检测发现系统存在的隐患，并进行问题溯源，最终定位隐患点，进行消缺。智能异常检测基于“智能知识库”、“智能算法库”和“智能案例库”三大智能数据基础库。而这一切的基础是标准化的指标体系。对于Oracle数据库这样的传统商用数据库，已经形成了一套行业内公共语言，就是标准化的指标体系，我们提到单块读，多块读，日志同步等术语，无论是天南海北的人都能听得懂，大家可以用一种统一的语言去沟通。在PG数据库运维中，我们也需要构建这样一套大家都听得懂的指标体系，这有助于PG社区的技术交流与技术共享。而这个标准化的指标体系也是构建智能化分析的基础。

在这些年的PG数据库应用与运维工作中，我们已经积累了一些针对PG数据库运维分析具有一定意义的指标体系，今后我们团队也会把这个指标体系作为一种开源资源贡献给PG社区。

“智能知识库”是历史经验、专家与运维团队知识积累的结晶，该知识库可以被用来做故障提前感知、故障深度分析、问题溯源分析等方面。这个知识库的来源包括专家的知识输出、运维案例的梳理、技术文档与资料的整理等，最终把这些成果通过图数据库的方式构建出来。

目前我们团队实用neo4j构建了一个PG数据库的知识库，这个数据库经过了三年的积累，目前只是初步具备了一些诊断分析的能力。我们目前也在逐步的扩大这个知识库。

“智能算法库”包含模型中心和算法中心两个中心。算法中心是平台中收集的，能够用于智能化运维的算法。模型中心是通过算法已经形成的可用于智能分析或者支撑日常运维工作的各类模型，包括健康模型、性能模型、负载模型、容量模型、故障模型等。

“智能案例库”不仅仅是一个案例的汇总库，智能案例库有多个数据来源，包括：历史运维故障案例库、自动预警库、状态巡检库、专家发现库等。智能案例库是发现新的运维知识和算法的十分重要的数据支撑库，运维专家通过对案例库进行分析与标注，然后再通过智能模型进行分析，可以更新和提升“智能知识库”和“智能算法库”。

智能异常检测有别于通过专家提供的基线规则进行检测的传统异常检测。传统异常检测由于在不同的运行环境中很难科学的设置基线模板而从实际应用上的效果不佳，并且严重依赖于专家的能力，很难普遍应用。完全基于大数据分析建模的异常检测又因为缺乏发专业知识而很难令人相信，应用效果也不佳。智能异常检测结合了大数据分析与专家经验二者的优点，补充了二者的不足，可以获得较好的效果。

下面我们首先来看一个利用这个智能知识库进行PG故障诊断的案例。选取的数据库是我们D-SMART实用的PG数据库。

我们看到pg88这个PG数据库的健康分只有74分，明显是存在一些问题的。

通过健康模型我们也发现在最近这个时段出现了健康分的下降，从雷达图也可以看到操纵系统，数据库IO、数据库命中率等方面存在一些问题。

通过数据库故障模型报警上面我们看到有一个IO延时超长的报警，实用“智能指标分析”进行诊断。

这个工具就是利用图数据库的知识进行推理，找出相关的指标进行分析，并把发现的问题总结出来。红色字的部分就是这个工具给出的分析结论。同时这个工具会根据分析结果推荐出几条诊断路径来。运维人员通过点击诊断路径就可以进行故障溯源了。

通过服务器IO分析工具，我们发现了PG相关的磁盘存在IO延时过大的问题，从最近一小时的IO吞吐量来看是一种上升的趋势，不过总量还不算太大。不过这个存储系统的后端延时较大。从这个分析结论上看，工具推荐检查后端存储的性能是不是存在问题。

从另外一条推荐的诊断路径上，我们发现了几条TOP SQL，通过对这些SQL的诊断分析，我们可以通过减少IO吞吐量的方式来缓解对后端存储的压力，从而从另外一个方面来优化这个问题。

另外一个案例是我们通过一个关键指标入手，去分析系统中可能存在的问题。比如我们从每秒事务数这个指标入手去做分析。

可以看到每秒事务数的波动基本上还是规律的，不过偶尔会出现一些波动。通过智能指标分析工具，我们可以看看AI专家能给我们推荐什么诊断工具。

最终利用知识图谱的推理，针对每秒事务数这个指标，推荐了13个诊断工具，我们仔细分析了一下，推荐出来的工具虽然有点多，不过总体上还是靠谱的。甚至有些工具，哪怕是一些PG运维的专家也不一定能第一时间想到。如果仔细想一下，好像这些工具都还是有些道理的，和这个指标异常都还是能够挂上边的。这就是智能化分析工具超过人类专家的能力。

通过上面的案例我们了解了利用知识图谱进行PG深度分析的基本方法。最后有两个问题我们再进一步探讨一下。

第一个问题是知识库如何构建的问题。目前我们构建知识库有三个渠道，第一个是专家梳理，是专家采用包括专家自有知识的输出，官方文档梳理，技术资料抽取和以往历史案例的梳理等方式构建知识库。第二个是智能发现，这个是靠我们在日常运维中，利用智能化的分析工具在进行人工辅助分析的时候发现新的知识或者诊断路径。第三种是通过外部协作的方式包括社区协助，外部购买的方式获得知识。

知识库的构建是一个十分艰苦与缓慢的过程。目前我们团队通过2年时间的积累，也不过积累了不到1000个顶点，几千条边的PG知识库。相对Oracle数千个顶点，数万条边的知识库，还是少了许多。如何更加快速的构建PG知识库，仅仅依靠一个团队的力量是不够的，需要广泛的社区合作。因此我们团队也计划在2021年把PG的知识图谱开源出来，和PG社区合作，构建一个开源的PG知识图谱开源项目，利用广大的PG社区的资源共同发展这个知识库，让所有参与者共享成果。具体的开源方式与开源协议，后续我们会和PG中国社区的朋友一起商讨。

第二个问题是异常检测中实用的异常标注问题。如下图所示，异常标注是构建异常分析模型的十分关键的工作步骤。

目前这个工作也遇到了一些问题，首先是数据样本不足的问题，如果没有足够的高质量的数据样本，就无法构建一个准确率达到实用标准的模型。第二个是这些数据需要专家标注。目前仅仅依靠基石数据的专家来进行数据标注是远远不够的，需要有更多的专家参与进来，才能标注更多的数据，也才能更准确的标注数据。这个工作也需要社区的力量参与。构建一个开源的样本集与标注数据集，也是下一步我们准备与PG中国社区合作的一个项目。

最后老白提出一个全面生态合作的倡议，发扬开源精神，建立共同的PG技术联盟，共享运维经验，共享实战案例，共同构建知识库，共同进行数据标注，共同为PG的AI运维赋能。