作者：赵红梅 Hologres PD
摘要：在这次分享中，将向大家展示如何利用一系列诊断与调优工具，实现对 SQL 和数据库异常的全方位诊断，从而提升实例稳定性。
Hologres诊断与优化实践总结
我的介绍将分为五个部分：首先，在事前阶段，讲解如何利用监控指标实现实时监控和预防措施。其次，事中探讨团队如何通过活跃日志发现运行中的问题，并及时采取措施止损，以避免业务问题的恶化。接下来，在事后阶段介绍如何通过深入分析和结合可视化工具来诊断当前的性能瓶颈。此外展示如何通过表管理工具实现成本治理，以及如何利用特定的诊断工具来提升系统的稳定性。 内容大纲如下：
- Hologres 诊断与优化的实践
- 事前：通过监控指标实时监控实例异常
- 事中：通过活跃 SQL 日志快速定位长 SQL
- 事后：通过慢 Query 日志+Query 洞察诊断慢 Query
- 事后：通过慢 Query 日志+Query 洞察治理错 Query
- 稳定治理：SQL 诊断报告长期治理 SQL
- 稳定性治理：表 Meta 诊断报告治理 Meta 问题
- 成本治理
事前：实例实时监控
了解监控指标
首先事前团队需要预先审视业务，目的是提前发现并解决潜在问题，以防止问题在生产环境中恶化。建议采用监控指标并设置相应的告警机制来执行这一操作。Hologres 提供丰富的监控指标来帮助业务及时发现实例异常。访问管控台，选择相应的实例，进入监控信息页面，您将看到 Hologres 提供的大约五类监控指标，每一类都对应不同的业务属性。关于监控指标的详细使用见文档。
资源和Query类监控
资源与 Query 运行状况监控指标主要用于监控团队在实际操作中资源的利用率以及运行状况。包含CPU使用率、内存使用率等，可以实时监测到实例资源的使用。
- CPU监控：以实例的CPU使用率为例，它反映了实例中 CPU 的整体使用情况。如果 CPU 使用率随着 Query 波动，这通常意味着 CPU 运行状况良好。然而，如果 CPU 使用率持续处于满载状态，这表明资源可能已经不足，此时需要团队及时优化实例中的 SQL 或对资源进行扩容。接下来是 Worker 节点的 CPU 使用率监控，它旨在报告每个 Worker 节点的 CPU 使用情况。从图表中可以看到，如果每个 Worker 的 CPU 使用率相对均匀，这通常表明运行状况是健康的。但是，如果某个 Worker 的 CPU 使用率达到 100%，而其他 Worker 的使用率很低，或者大部分 Worker 的 CPU 使用率都很高，唯独某个 Worker 的使用率偏低，这说明资源利用并不均衡。在这种情况下，团队需要检查是否存在数据倾斜问题，或者 Worker 节点的分布是否均匀。
- 内存监控：在内存相关的监控指标上，可以看到实例整体的内存使用情况，也能看到不同模块的内存使用，例如Query使用内存、meta内存等，方便业务对内存水位持续性监控和治理。
- QPS和RPS指标：可以综合的反映实例的读写情况，但需要注意的是，实例能支撑的QPS和RPS与实例规格、Query复杂度等因素有关，建议根据实际情况进行压测
- Query延迟：包括Query在每个阶段的延迟（Optimization 阶段、Start Query 阶段、Get next 阶段）可以根据阶段的耗时来评估Query的运行情况，并针对性优化。同时也提供Query的整体延迟和P99延迟，以综合反映实例中所有Query运行的延迟。但需要重点关注“本实例正在运行中 Query 最长的时长”，可以反映实例中是否出现运行时间较长的Query，及时结合holoweb-活跃Query找到该Query，并做治理，防止实例中资源长期打满，影响其他的任务运行。
- 失败Query：它主要监控实例在过去一段时间或实时中是否有失败的 Query。如果在某段时间内失败的 Query 数量增加，这可能表明实例出现异常，团队需要及时介入处理
I/O和存储类监控
- IO：反映Query在运行过程中与底层存储的IO交互情况，不涉及网络的I/O，通过IO的吞吐情况，判断数据的处理。
- 存储：反映实例中真实的数据存储
流量和Framework
流量和Framework主要会反映Query运行过程中与网络等的交互情况。
- Endpoint 流量：反映了不同网络的流量情况情况，包括公网、VBC 网以及经典网等，它记录了数据流入和流出的状况，流量的使用可以反馈带宽是否到达极限，从而影响数据写入或读取的速度。
- Framework：反映shard多副本、以及实例副本的延迟，一般来说延迟在毫秒级都是正常，如果延迟较高，说明实例异常需要及时处理。请重点关注“FE replay 延迟(milliseconds)”指标，延迟已经累积到小时级别，表示实例中worker有卡住的情况，需要及时处理
- Gateway：Gateway，作为计算组中的一个特殊组件，其主要职责是进行 SQL 分发和路由控制。因此，监控 Gateway 的 CPU、内存以及网络流量的使用情况，可以反映 Query 处理速度和规模，团队应定期检查这些资源的使用情况，以判断是否需要扩容。
Serverless和资源弹性
- Serverless Computing：实时观测在serverless中运行的Query延迟、排队情况等，及时治理
- Computing Resource：监控分时弹性的使用情况
Binlog和Analyze
- Auto Analyze：反映实例中每个DB内表的统计信息缺失情况，以判断auto analyze的准确率，及时手动更新表的统计信息
- Binlog：主要是监控Binlog的使用情况，包括吞吐和wal sender连接数，从而判断消费Binlog是否出现瓶颈
监控告警最佳实践
如果要对监控指标告警，可以点击报警-报警设置，根据业务情况设置阈值告警。Holo推荐常用的监控指标告警如下：
监控CPU使用率：监控实例的CPU使用率和Worker节点CPU使用率，如果 CPU 使用率长时间保持在 100%，则表明资源严重不足，此时需要考虑扩容或优化团队运行的业务。其次，关注 Worker 节点的 CPU 使用率，这有助于观察资源是否被均匀利用。
监控Query延迟：通过监控Query延迟，可以实时监控是否有延迟上涨，以此判断实例负载情况
监控失败Query：通过失败Query可以监控到当前实例中任务运行情况，如果连续失败，可能存在实例异常，需要及时处理
监控“本实例/Serverless最长的Query运行时长”：可以了解当前是否有运行时间较长的Query，如果长时间运行，会导致资源占用，影响其他Query
事中：活跃 SQL 日志快速定位长 SQL
可以以通过活跃SQL日志快速定位运行中的长SQL。通过Holoweb>诊断与优化>活跃Query，查看到当前实例中正在运行的SQL，详细的信息包括运行时长、执行引擎等，如果CPU已经有长时间运行且不符合业务预期的，需要结合监控页面，看CPU是否已经被打满，然后在活跃Query界面点击取消，将该Query取消，以避免长期占用资源，同时CPU也会下降，说明问题止血成功。更多操作详情见文档
事后：慢Query日志诊断Query
优化慢Query
如果要对Query持续性的治理和优化，可以使用慢Query日志结合Query洞察功能：
- 第一步：前往holoweb>诊断优化>慢query日志查询当前实例的慢SQL列表，重点关注duration、engine type、cpu_time字段
- 第二步：对于运行时间较长、资源消耗较多的SQL，单击前往Query洞察分析，分析单个SQL性能，重点关注enginetype、readrows、readbytes
- 第三步：查看Query执行计划，重点关注算子：partitionselected、filter、time、rows，如下示例的plan，东从下往上看，Read Rows 已经处理了数亿量级的数据，从 274 个分区中扫描了60 个分区，比较多，同时也是读取的MC外表，因此建议优化方向是减少分区扫描或者将外表导入到内表，以提升性能
治理错Query
如果实例中监控到 Failed Query较多，可以通过慢Query日志结合Query洞察治理。方法如下：
- 第一步：监控指标观察FailedQueryQPS，观察到时间Query对应的时间段
- 第二步：前往holoweb>诊断优化>慢Query日志，图维度选择”失败Query“，并选择对应的时间段，查找错误的SQL
- 第三步：点击前往“query洞察分析”>错误信息，Query洞察会展示出详细报错，同时也会结合AI，给出详细的报错原因和解决方案，可以根据建议对SQL进行治理，提升实例的稳定性。
稳定性治理：SQL诊断长期治理
Hologres 在Holoweb提供一个 SQL 诊断报告，可以查看昨天以及过去的详细SQL运行，例如耗时占比、错误占比等，通过长期治理SQL，来提升实例稳定性。详细使用见文档。重点关注如下几个治理项：
- 错SQL治理：关注失败Query明细，可以查看某天的失败次数，典型失败Query，根据Query洞察中的错误信息和改进建议，治理错SQL，提升实例的成功率
- 长SQL治理：关注Query耗时占比趋势，可以分析出Query的耗时占比，重点关注耗时较长（超过10min）的query耗时占比，并通过Query洞察查看明细，治理慢SQL
- 应用治理：关注Query应用来源占比，可以分析出发起Query的应用来源，当出现异常时可以及时找到对应的应用。同时建议，尽量给每个应用都配置上应用来源application_name，不建议所有的Query都用统一的应用名，无法进一步排查问题
- 执行引擎治理：关注执行引擎的Query趋势，Hologres中有多个执行引擎（HQE、PQE、SQE等），其中HQE为自研引擎更高效，所以需要重点关注执行引擎为SQE、PQE的Query趋势，尽量减少PQE的Query，以此提升Query性能
稳定性治理：表Meta诊断Meta问题
meta诊断：当Hologres数据库中的元数据管理器（Storage Master）和FE节点保存的表元数据不一致时，会导致DDL操作报错或影响费用等。表Meta诊断功能，以检测当前实例中表元数据的一致性，并每周更新一次诊断结果，可以根据对应元数据问题的解决方案进行修复，以提高实例的可用性和稳定性。
Meta诊断是自动推送的异常问题，如果页面显示空白，则说明实例无meta问题，不需要治理。如果出现Meta异常，Hologres也提供一键修复的能力，单击一键修复，在业务低峰期执行修复SQL，以便修复meta问题，提升实例问题性，详细使用见文档。
成本治理：表索引诊断报告长期治理表
随着业务的持续迭代，团队实例中的表数量可能会迅速增加，导致管理困难，或者不清楚删除哪些不必要的表，以及表的索引使用情况等，为此，我们提供了一个标准的表索引诊断报告，以评估当前实例中表的使用情况。表索引诊断报告的项目较多，详细使用可以参考文档，Hologres比较建议对如下几项内容进行治理：
- 存储治理：
- 分区子表数和存储量：查看分区表的存储量，治理存储为0的表
- 存储为0的表：及时治理存储为0的表，防止占用meta内存
- 行存表治理：
- 没有设置主键：无法用上索引的能力，需要重新建表并设置主键
- Distributionkey和clusteringkey不一致的行存表：不适用行存表点查场景，改成列存/行列共存
- 表字段数治理：
- 超过300列的列存表：列太多，性能开销大
- 超过300列的行列共存表：列太多，性能开销大
- 索引治理：
- 超过3列的clustering/segment/distributionkey：索引设置超过3列，会导致使用场景受限，无法很好的利用索引的能力
- Binlog表治理：
- 开启Binlog的表：不建议列存表开启binlog，性能开销大
- BinlogTTL大于7天：Binlog太多会导致占用过多的存储，关注表存储量，及时治理
通过表属性诊断，有助于深入分析团队实例中的表、索引以及字段数量，甚至包括表属性等情况，以便进一步优化管理表，以实现长期的成本治理目标。
13个专题6万字详解，Hologres一体化实时湖仓实践手册发布
Hologres 3.0 全新升级为一体化实时湖仓平台，通过统一数据平台实现湖仓存储一体、多模式计算一体、分析服务一体、Data+Al 一体，实现一份数据、一份计算、一份服务，极大提高数据开发及应用效率。立即下载>>https://developer.aliyun.com/ebook/8436电子书亮点：
ꔷ 结合Deepseek+PAI 构建RAG检索增强系统
ꔷ 结合Flink、Paimon、MaxCompute等构建一体化实时湖仓平台
ꔷ Serverless系列功能快速入门，降价46%并保障资源隔离与稳定
ꔷ Dynamic Table、运维诊断优化、流量分析函数等3.0最新功能实践
