目录
[1 数据库智能化发展史](#1 数据库智能化发展史)
[2 自治运维技术](#2 自治运维技术)
[2.1 智能监测](#2.1 智能监测)
[2.2 趋势预测](#2.2 趋势预测)
[2.3 异常检测](#2.3 异常检测)
1 数据库智能化发展史
云原生为迎接智能化提供了基础条件，智能化是GaussDB的新的牵引方向，两者相辅相成，互相促进。在智能化出现之前，数据库的运维管理主要依赖分层解耦、化繁为简方式来治理，通过人工服务对单点的业务进行管理。但在云化环境中，一个Region纳管上万实例，仅靠人工很难满足业务诉求，这就促成智能与数据库在云原生的架构和应用中释放的新的研发方向。
GaussDB基于智能化（AI）技术，打造AI4DB和DB4AI两大技术高地，重构数据库内核核心组件，提升数据库管理和优化技术，满足数据库科学家对普惠AI的诉求。AI4DB技术利用机器学习，基于海量运行期数据及负载数据，形成智能解决方案，自动化处理各项任务，加速运维和诊断优化效率提升。DB4AI通过数据库使能AI，满足数据科学家在数据治理方面的诉求，仅通过简易SQL调用，即刻完成机器学习算法的训练和推荐，实现人人会AI，人人用AI的普惠应用。
如上图所示，GaussDB AI4DB领域包含两个方面的核心子系统：自治运维系统及智能优化器（ABO）。其中自治运维系统提供用户和DBA进行数据库系统的智能化运维管理能力，包括自监控、自诊断、自调优等方面端到端的运维管理能力，主要目标是提升系统的运维诊断效率，让数据库系统更高效和可靠。智能优化器是将AI技术嵌入到数据库内核优化器引擎，实现智能基数估计、智能计划管理和智能代价模型等功能，提升查询语句生成计划的准确性和提供查询语句的执行效率。
GaussDB DB4AI领域指在数据库内实现机器学习引擎，即库内AI引擎。通过在数据库内置常用机器学习算法，把AI算法作为执行器中的执行算子在语句执行中实现，对外提供训练和推理的简易SQL语法方便用户调用。同时，在数据库内置模型管理能力，用户训练好的模型可以存储在系统表中，方便快速推理调用。在训练数据准备阶段，通过数据集管理能力，分为多个版本来保证数据训练的一致性，便于训练算法的调优。
2 自治运维技术
在数据库自治运维技术领域，主要分为两条技术路线。其一是以Oracle为主的老牌数据库厂商，构建运维及生命周期管理统一逃课，实现大规模的数据库智能化管理能力；对用户通过运维工具指导业务快速升级和排障，对业务通过内置的优化诊断套件和多维度报表，快速定位性能瓶颈问题和实现SQL的快速优化。这种方案在单一集群或小规模集群是高效的，通过DBA能力复制，可快速完成运维技术的应用。另一种是以新兴云厂商为主，构建基于云化设施和环境的自治运维技术。尽管各家的技术不近统一，主体思路是一致的，即尽可能通过一套运维管理系统，纳管云化多套环境，通过机器学习技术和海量数据，训练高效诊断和优化模型，形成标准化运维套路。
GaussDB基于机器学习技术和云上海量数据信息，构建领先的自治运维管理系统，通过成熟算法实现负载感知、环境感知和数据感知，为数据库提供自监控、自诊断、自调优、自安全的能力，为客户和DBA提供极佳的运维管理体验。
上图为GaussDB的自治运维系统整体框图。数据采集层实现多维指标的数据采集，采集频率根据内容不同可分为秒级采集和分钟级采集。其中秒级采集包括操作系统资源信息采集和数据库实例信息采集，例如操作系统层面CPU、内存、IO读写、网络资源信息采集，数据库实例状态、数据库内关键指标（内存、连接数、TPS、QPS、读写频率等）；分钟级采集包括审计日志采集、数据库日志采集和全量SQL流水采集等。
自治运维平台提供采集程序（Agent进程），可部署在数据库服务侧或者远端，连接数据库实例或所在服务器，采集上述指标；若客户系统配置普罗米修斯进行信息采集，可实现相应的exporter，在其中内置数据库多维度指标采集方法以及数据清理方案，实现与普罗米修斯平台对接。
数据库采集端程序需要部署在同数据库进程所在物理节点时，若数据库为多节点集群环境，每个物理节点可部署一个Agent进程采集端（或者普罗米修斯采集端）。数据库采集端程序通常占用资源很少，通过配置文件可以制定不同指标采集频率，以免占用资源影响数据库业务正常运行。
数据计算层提供数据存储、数据分析及元数据管理能力。其中数据存储用于接收来自数据采集层发生来的数据，存储数据源可以是多种维度或者类型，包括普罗米修斯、时序数据库（OpenTSDB等）、MongoDB、SQLite等，自治运维服务内置对接接口，每个自治服务模块与存储数据源的交互，获取数据并进行分析处理。在企业实际应用时，可根据需要选择不同的存储组件和大数据处理组件，例如普罗米修斯+时序数据库，或者kafka+时序数据库等方案。
在数据计算层除了时序存储数据库外，还可以设计其他存储单元，例如算法模型库和故障规则库。其中算法模型库存储自治管理服务生成的AI模型，例如参数推荐训练模型；在算法模型库中，可以存储传统机器学习（例如监督学习）模型、强化学习模型。故障规则库是记录数据库常见故障案例，将这些案例通过拆解和分析，生成规则引擎。
自治服务层在用户维度，可以分为SQL诊断和调优、自治安全、数据库运维。其中SQL诊断和调优提供多种SQL治理和调优能力，包括慢SQL诊断、SQL表现评估、智能索引推荐、智能查询重写等服务。自治安全通过AI技术实现敏感信息发觉、SQL注入检测和异常行为分析。数据库运维能力实现在数据库系统、OS系统和数据库集群层面的运维和调优，其中数据库系统服务包括数据库参数智能推荐、智能巡检、数据库分布键推荐和智能业务调度；在操作系统层面，实现慢盘检测和恢复、网络丢包检测；在数据库集群层面，基于故障或者负载需求，提供自动扩缩容、异常节点修复服务。
自治运维服务最终需要通过管控网页界面形式对外呈现，方便用户直观感受运维管理带来的效果。在展示界面方面，多指标结合AI趋势预测，可给出后续时段的数据走向。同时为方便用户系统观察集群状态，提供健康指数报告和详细综合报告。健康指数报告给出当前系统的健康评分等级，默认80分以上属于运行健康状况，小于60分则存在严重隐患，急需修复。综合报告详细描述系统各维度信息，包括集群状态、负载运行情况、常见数据库指标项信息。
2.1 智能监测
GaussDB提供500+指标的智能监测，通过对数据库指标、操作系统指标和运行日志的采集，拉取采集数据至时序数据库存储，便于后续进行异常侦测和问题定位。为了快速支撑各粒度的多维度指标采集，部署多个采集程序，例如数据库指标采集程序openGauss-exporter、操作系统指标采集程序node-exporter、本地执行采集程序cmd_exporter以及数据二次处理程序reprocessing-exporter等。
GaussDB智能监测程序采取服务化方式部署，通过RPC通道（默认Https协议，且校验数据库用户名密码，不存在空密码访问情况）实现，可以获取数据库的即时信息，也可以向数据库下发执行动作（需要用户提供的用户具备执行权限，具体数据库用户由用户指定）。时序数据处理支持多种时序库存，例如普罗米修斯、Influxdb等，尽管对接接口协议不同，但实现方式类似。后面以普罗米修斯时序库和采集程序进行举例，说明智能监控的方法和实现方案。下图为智能监测方案的执行时序图。
数据采集的实现过程：
（1）Exporter 的数据采集原理如上图所示，采集过程是pull的形式，即由Prometheus 主动发起数据刮取（scrape）请求，而后exporter再想被监控服务（可以是数据库服务、Linux等）发起查询请求，由其通过http(s) 协议展示给Prometheus；
（2）通过Prometheus 框架，按照Prometheus协议即可实现对应的exporter，该实现过程类似一个插件，通过Prometheus 提供的SDK（如prometheus-client库）即可完成开发过程；
（3）所采集的指标项通过用户给定的配置文件解析获得，不需要在exporter中固化；
（4）实现的exporter主要有两个，一个是openGauss-exporter，用于监控数据库实例，从其上面抓取数据；另一个是reprocessing-exporter, 用于对Prometheus已经采集到的数据进行二次加工。两个exporter是各自独立的进程。
（5）openGauss-exporter 是需要输入待监控数据库的登录密码的，该密码通过shell命令的配置参数输入。其中，在命令行中通过内存覆盖的技术擦除了命令行中的密码，避免了通过 ps --ux 等泄漏密码的可能。
（6）为进一步保障采集数据的安全性，exporter采集的数据源由用户手动配置，默认配置文件不涉及敏感数据，仅采集数据库性能相关指标；在网络协议方面，默认支持采用https协议，用户显性给定证书文件路径，并在Prometheus-server侧进行配置exporter采集工具和用户不涉及交互，所有SQL执行都有程序本身实现，不涉及SQL注入问题。
数据采集存储在时序数据库后，将进入趋势预测和异常检测模块，便于客户提前发现潜在问题或者实时发现系统中的异常问题。
2.2 趋势预测
趋势预测功能模块主要实现基于历史时序数据预测未来时序变化趋势。该模块框架解耦，可以实现不同预测算法的灵活替换，并且该模块功能可以实现不同特征时序的算法自动选择，支持线性特征时序预测LR回归算法和非线性特征预测ARIMA算法。目前该模块可以覆盖线性时序、非线性时序和周期时序的准确预测。
时序预测模块和异常检测模块作为自监控的两个核心组件，通过采集程序获取数据后，在检测器阶段进行时序预测及异常检测，数据流转的流程如下：
数据获取和数据分析是一个相对于数据库环境独立的工具组件，包括Agent、检测器等子模块。其中Agent是部署在数据库主机环境上的，用于采集数据库中的性能指标，并通过网络，将其传送给远端检测器模块，远端检测器模块负责对采集到的性能指标数据进行收集、存储与检测。
Agent模块分为三个子模块，分别是Source、Channel以及Sink，各个组件之间可插拔、可扩展。其中数据收集端Source，用于直接监控数据库系统，并从数据库系统中采集信息；数据缓存器Channel，可以理解为缓存区，用来保存Source处捕获的数据，是一个FIFO的队列。Source捕获的数据会Push到Channel中，而后Sink组件消费由Source产生的数据。Channel缓存在内存中，为了防止OOM，具有容量上限，当超过容量上限时，过多的元素会被禁止放入队列。数据处理及外发Sink，负责从Channel消费数据，然后将数据从Channel中清除，以指定数据格式进行外发，将数据存储到外部存储系统。在数据从Channel端到Sink端的过程中，加入了JSON wrapper 和flow controller两个中间件，分别对应了JSON格式封装、流量控制功能。其中，由于Agent架构对限流功能天然友好，Channel充当缓存功能，实现漏桶算法进行限流。Sink上支持类似这种pipeline模式，以便后续对上传过程进行控制，提供可扩展能力。
从Agent发送到检测器的网络通信协议默认为https，默认证书在部署时由部署脚本生成。
检测器主要包括三个部分，分别是存储模块、时序预测模块、异常检测模块。本章节重点描述时序预测模块，异常检测模块在后续单独描述。
时序预测模块的执行流程如下：
时序预测模块提供了两种基本的预测模型，分别是线性模型和深度学习模型。另外系统给用户指定了三种预测模式，分别是decompose、ensemble、hybrid。Decompose代表分解预测模式，ensemble代表整体预测模式，hybrid代表混合预测模式，算法步骤为：
-
首先获取训练数据，算法会判断数据的线性相关系数是否大于指定的阈值（系统默认0.9），如果大于阈值，则会选择线性预测模型（linear regressor），否则会选择循环神经网络预测模型（RNN）。
-
如果用户选择decompose预测模式，系统会调用是时序分解算法将序列分解成周期项、趋势项、残差项，然后调用模型对趋势项进行训练，得到趋势的预测结果。对于周期不需要预测，可以根据周期性递推得到未来周期项。对于残差，系统基于统计学原理，取25%和75%分位作为残差项的上下限。最终预测结果为趋势项、周期项和残差项的和。
-
如果用户选择ensemble预测模式，系统会直接对数据进行训练，然后进行预测，得到预测结果和模型评分。
-
如果用户选择的hybrid模式，系统会串行的执行decompose和ensemble两种预测模式流程，同时根据它们最终模型评分的高低选择最优的预测结果。如果用户真实采集到的信息与时序预测的结果出现较大偏差（大于预设阈值），则认为当前情况出现异常，执行报警逻辑。
2.3 异常检测
异常检测模块主要基于统计方法来实现时序数据来发现数据中存在的可能的异常情况。该模块框架解耦，可以实现不同异常检测算法的灵活替换，而且该模块功能可以根据时序数据的不同特征来自动选择算法，支持异常值检测、阈值检测、箱型图检测、梯度检测、增长率检测、波动率检测和状态转换检测。
异常检测模块实现的流程图如下：
在异常检测模块执行过程中，主要包括以下步骤：
（1）获取异常根因以及对应异常指标配置
从配置中读取需要诊断的根因名称以及每种根因对应的指标名称；下表列出部分根因对应的指标信息。
|----------|-------------------|-----------------|
| 根因类型 | 参数名称 | 参数解释 |
| 磁盘读写竞争 | IO_count | 磁盘读写次数 |
| 磁盘读写竞争 | IO_bytes | 磁盘读写字节数量 |
| 磁盘读写竞争 | Rows_scan | 数据库表读取行数 |
| 磁盘读写竞争 | Rows_update | 数据库表更新行数 |
| 磁盘读写竞争 | Rows_insert | 数据库表插入行数 |
| 磁盘读写竞争 | Index_blocks_read | 索引块读取数量 |
| 计算资源竞争 | Cpu usage | 系统cpu使用率 |
| 计算资源竞争 | User cpu usage | 用户cpu使用率 |
| 计算资源竞争 | Sql cpu usage | SQL执行占用的cpu资源 |
| 数据库锁竞争 | Lock count | 数据库当前锁数量 |
| 数据库锁竞争 | Lock wait time | SQL锁等待时间 |
| 数据库锁竞争 | Sql canceled | 由于锁超时导致的sql执行取消 |
（2）获取异常根因特征库配置
系统利用实验环境模拟以及DBA专家经验为每个根因指定一个特征向量集合V={v1,v2,...,vi}，其中vi是一个二进制独热（one-hot）编码向量，1表示该根因会导致特定指标出现某种异常，0则表示不会导致该异常。
（3）获取异常时刻
有两种方式触发异常根因诊断，一种是数据监控平台会定时搜索查找关键性能指标（KPI，包括QPS，TPS，查询时延等）异常的时间段，监控平台会综合利用不同的序列异常检测算法，通过对于不同异常类型的分析得出是否是异常的结论；另一种是用户手动设置诊断时间触发诊断。
（4）生成异常特征向量
对于异常时刻T，系统抽取[T-3600s,T+200s]区间范围内的所有指标序列；通过调用监控层的异常检测算法检测出异常类型，并转换成独热编码（one-hot），每一位表示一个特定的指标异常。
（5）查找Top-K根因
针对生成的特征向量，系统从异常特征库中获取近似包含的所有特征向量，并且根据相似度返回最有可能的K个特征向量对应的异常根因。
（6）输出根因和置信度
系统将TopK的根因的相似度使用Softmax函数进行归一化，归一化之后给出每个根因的概率作为置信度进行输出。
异常检测的系统详细设计如下：
（1）关键指标获取
针对异常场景，系统从系统监控层分别拉取如下指标：
|----------------------------|-----------------|------------------|
| 指标名称 | 指标描述 | 指标来源 |
| node_disk_read_bytes | 实例节点磁盘每秒读字节数 | Node exporter |
| node_disk_read_time | 实例节点磁盘读取时间占比 | Node exporter |
| node_disk_write_bytes | 实例节点磁盘每秒写入字节数 | Node exporter |
| node_disk_write_time | 实例节点磁盘写入时间占比 | Node exporter |
| node_cpu_usage | 实例节点cpu使用率 | Node exporter |
| node_system_cpu_usage | 实例节点系统cpu使用率 | Node exporter |
| node_user_cpu_usage | 实例节点用户cpu使用率 | Node exporter |
| node_memory_usage | 实例节点内存使用率 | Node exporter |
| node_network_receive_bytes | 实例节点每秒接收网络字节数 | Node exporter |
| node_filesystem_files_free | 实例节点文件句柄剩余数量 | Node exporter |
| Gaussdb_qps | 数据库每秒执行查询数量 | GaussDB exporter |
| shared_memory_total | 数据库共享内存用量 | GaussDB exporter |
| shared_memory_freed | 数据库共享内存剩余 | GaussDB exporter |
| session_memory_total | 数据库会话内存用量 | GaussDB exporter |
| session_memory_freed | 数据库会话内存剩余 | GaussDB exporter |
| index_blocks_hit_cnt | 数据库内存索引块命中率 | GaussDB exporter |
| index_blocks_read_cnt | 数据库索引块读取数量 | GaussDB exporter |
| index_tuples_fetch_cnt | 数据库索引键获取数量 | GaussDB exporter |
| locks_cnt | 数据库持有锁数量 | GaussDB exporter |
| locks_time | 数据库锁等待时间 | GaussDB exporter |
| replication_slots_delay | 副本复制延迟（槽数量） | GaussDB exporter |
| max_elapse_time | 当前执行sql最大时延 | GaussDB exporter |
| requested_checkpoint_cnt | 数据库请求的检查点次数 | GaussDB exporter |
| checkpoint_sync_time | 数据库检查点刷脏时间 | GaussDB exporter |
| bgwriter_buffers_backend | 后台进程刷脏时间 | GaussDB exporter |
| disk_blocks_read_cnt | 数据库磁盘块读取数量 | GaussDB exporter |
| disk_blocks_hit_ratio | 数据库磁盘块命中率 | GaussDB exporter |
| cancel_because_deadlock | 数据库由于死锁取消的事务数量 | GaussDB exporter |
| cancel_because_locktimeout | 数据库由于锁超时取消的事务数量 | GaussDB exporter |
| tempfile_bytes | 数据库临时文件大小（字节） | GaussDB exporter |
| n_tup_deleted | 数据库已删除数据行数 | GaussDB exporter |
| n_tup_fetched | 数据库已获取数据行数 | GaussDB exporter |
| n_tup_retured | 数据库返回结果数据行数 | GaussDB exporter |
| n_tup_inserted | 数据库插入数据行数 | GaussDB exporter |
| n_tup_updated | 数据库更新数据行数 | GaussDB exporter |
| auto_analyze_cnt | 数据库自动分析次数 | GaussDB exporter |
| auto_vacuum_cnt | 数据库自动数据整理次数 | GaussDB exporter |
| dead_tup_cnt | 数据库标记删除行数 | GaussDB exporter |
| connections_used_ratio | 数据库连接占用率 | GaussDB exporter |
| wal_write_wait | 数据库写前日志写盘等待时间 | GaussDB exporter |
| wal_read_wait | 数据库写前日志读取等待时间 | GaussDB exporter |
（2）特征向量抽取
特征向量是一个独热编码向量，其中每一位表示一个指标序列的一个异常，异常特征类型考虑如下：
|--------------------------|---------------------------|
| 异常类型 | 描述 |
| Spike (尖刺) | 指标突然升高（下降）之后又立刻突然下降（升高） |
| Level Shift(漂移) | 指标突然升高（下降）之后一段时间维持在高位（低位） |
| Volatility Shift(抖动) | 指标抖动突然加剧（或减小） |
| Seasonal Violation(周期破坏) | 指标出现不符合周期性预测的值 |
（3）近似包含匹配
向量v近似包含
定义为
，
是一个在(0,1]区间内的阈值。在异常特征库中，每个异常根因包含若干特征向量，只要和其中一个存在近似包含关系，那么就可以认为存在该根因。
比如对于数据库锁竞争，一共考虑三种指标，假设每种指标有4种异常类型，那么向量v一共有12位。通过实验我们发现数据库锁竞争会导致锁数量突然上升（spike up），锁等待时间剧烈抖动（volatility shift），由于锁超时导致的执行取消的数量也增加（level shift）。所以特征库中针对锁竞争的特征向量集合可以表示为[(1,0,0,0,0,0,1,0,0,1,0,0)]。当生产环境中这三个指标出现类似的异常（1,0,0,1,0,0,1,0,0,1,0,0）,那么由于
近似包含（近似度为1），可以判断存在锁竞争异常。
（4）通过相似度计算置信度
置信度表示每种异常根因的后验概率，这种概率要满足三个条件，（1）系统返回的K个根因的总概率之和要为1；（2）每个根因的概率取值范围是[0,1]；（3）每种根因的置信度要求具有区分度。因此，我们采用softmax对置信度进行归一化计算，假设返回的K个相似度分别是
, 计算公式如下：
计算之后返回概率最高的若干根因机器置信度。
异常检测返回的根因种类如下所示：
|----------|---------------------------|-------------------|
| 根因类型 | 根因名称 | 根因描述 |
| 系统资源竞争 | working_io_contention | 业务负载IO竞争 |
| 系统资源竞争 | nonworking_io_contention | 非业务负载IO竞争 |
| 系统资源竞争 | working_cpu_contention | 业务负载CPU竞争 |
| 系统资源竞争 | nonworking_cpu_contention | 非业务负载CPU竞争 |
| 系统资源竞争 | working_mem_contention | 业务负载内存竞争 |
| 系统资源竞争 | nonworking_mem_contention | 非业务负载内存竞争 |
| 系统资源竞争 | lock_contention | 读写锁竞争 |
| 数据库配置 | small_shared_buffer | Shared_buffer设置过小 |
| 数据库更新 | table_expansion | 数据膨胀 |
| 数据库后台进程 | analyze | 自动/手动后台数据统计 |
| 数据库后台进程 | WALwriter | 自动WAL日志刷写 |
| 数据库后台进程 | vacuum | 自动数据整理 |
| 数据库后台进程 | bgwriter_checkpoint | 后台检查点刷脏 |
| 系统资源减少 | full_connections | 连接池满 |
| 系统资源减少 | low_network_bandwidth | 网络带宽拥挤 |
| 系统资源减少 | low_io_bandwidth | 磁盘带宽拥挤 |
| 系统资源减少 | low_cpu_idle | 空闲CPU少 |
以上内容介绍了GaussDB数据库智能化发展史，并从智能检测、趋势预测、异常检测等三方面对GaussDB的自治运维技术进行了解读，下篇将从**日志分析、慢SQL发现、**慢SQL诊断、集群故障根因诊断等****方面继续介绍GaussDB的自治运维技术，敬请期待！