马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?立即注册
x
目录
1 数据库智能化发展史
2 自治运维技能
2.1 智能监测
2.2 趋势猜测
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代表混合猜测模式,算法步调为:
1. 首先获取练习数据,算法会判断数据的线性相关系数是否大于指定的阈值(系统默认0.9),如果大于阈值,则会选择线性猜测模型(linear regressor),否则会选择循环神经网络猜测模型(RNN)。
2. 如果用户选择decompose猜测模式,系统会调用是时序分解算法将序列分解成周期项、趋势项、残差项,然后调用模型对趋势项举行练习,得到趋势的猜测结果。对于周期不必要猜测,可以根据周期性递推得到将来周期项。对于残差,系统基于统计学原理,取25%和75%分位作为残差项的上下限。最终猜测结果为趋势项、周期项和残差项的和。
3. 如果用户选择ensemble猜测模式,系统会直接对数据举行练习,然后举行猜测,得到猜测结果和模型评分。
4. 如果用户选择的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_disk_write_bytes
| 实例节点磁盘每秒写入字节数
| node_disk_write_time
| 实例节点磁盘写入时间占比
| node_cpu_usage
| 实例节点cpu利用率
| node_system_cpu_usage
| 实例节点系统cpu利用率
| node_user_cpu_usage
| 实例节点用户cpu利用率
| node_memory_usage
| 实例节点内存利用率
| node_network_receive_bytes
| 实例节点每秒接收网络字节数
| node_filesystem_files_free
| 实例节点文件句柄剩余数量
| Gaussdb_qps
| 数据库每秒实验查询数量
| GaussDB exporter
| shared_memory_total
| 数据库共享内存用量
| shared_memory_freed
| 数据库共享内存剩余
| session_memory_total
| 数据库会话内存用量
| session_memory_freed
| 数据库会话内存剩余
| index_blocks_hit_cnt
| 数据库内存索引块掷中率
| index_blocks_read_cnt
| 数据库索引块读取数量
| index_tuples_fetch_cnt
| 数据库索引键获取数量
| locks_cnt
| 数据库持有锁数量
| locks_time
| 数据库锁等待时间
| replication_slots_delay
| 副本复制延迟(槽数量)
| max_elapse_time
| 当前实验sql最大时延
| requested_checkpoint_cnt
| 数据库哀求的检查点次数
| checkpoint_sync_time
| 数据库检查点刷脏时间
| bgwriter_buffers_backend
| 后台历程刷脏时间
| disk_blocks_read_cnt
| 数据库磁盘块读取数量
| disk_blocks_hit_ratio
| 数据库磁盘块掷中率
| cancel_because_deadlock
| 数据库由于死锁取消的事务数量
| cancel_because_locktimeout
| 数据库由于锁超时取消的事务数量
| tempfile_bytes
| 数据库暂时文件大小(字节)
| n_tup_deleted
| 数据库已删除数据行数
| n_tup_fetched
| 数据库已获取数据行数
| n_tup_retured
| 数据库返回结果数据行数
| n_tup_inserted
| 数据库插入数据行数
| n_tup_updated
| 数据库更新数据行数
| auto_analyze_cnt
| 数据库自动分析次数
| auto_vacuum_cnt
| 数据库自动数据整理次数
| dead_tup_cnt
| 数据库标记删除行数
| connections_used_ratio
| 数据库连接占用率
| wal_write_wait
| 数据库写前日志写盘等待时间
| wal_read_wait
| 数据库写前日志读取等待时间
| (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的自治运维技能,敬请等待!
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。 |