带你掌握数仓的作业级监控TopSQL

Posted 华为云开发者社区

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了带你掌握数仓的作业级监控TopSQL相关的知识，希望对你有一定的参考价值。

摘要：目前TopSQL功能被用户广泛使用，是性能定位、劣化分析、审计回溯等重要的基石，为用户提供覆盖内存、耗时、IO、网络、空间等多方面的监控能力。

本文分享自华为云社区《GaussDB(DWS)监控工具指南（一）作业级监控TopSQL》，作者：幕后小黑爪 。

1、引言：

监控系统是智能化管理和自动化运维的基石，可以为资源规划，故障排查，性能优化提供至关重要的数据支持。GaussDB(DWS)作为企业级数仓，为用户提供了一整套覆盖实例级、用户级、作业级的资源监控能力，其中，作业级监控（下文统称为TopSQL）主要是对运行作业的监控，包括了实时运行作业的相关信息，历史运行作业的相关信息等。它收集的数据来源于数据库内部，为用户提供了实时监控数据库的能力。

目前TopSQL功能被用户广泛使用，是性能定位、劣化分析、审计回溯等重要的基石，为用户提供覆盖内存、耗时、IO、网络、空间等多方面的监控能力。

本文以数仓813版本作为基线，对TopSQL进行介绍。

2、TopSQL功能介绍

对于用户而言，数据库是个黑盒，输入SQL语句，输出预期结果。在此过程中，用户关心两点：

  • 输出结果是否符合预期;
  • 语句要多久跑完。

关于第一个问题，用户需要关注下SQL语句写的是否合理。而对于第二个问题，普通用户可以通过explain等手段分析作业的执行计划，然而企业用户的SQL作业耗时久，影响较大，重跑代价较高，无法额外通过explain performance等手段进行分析，此时TopSQL可以帮助用户打开数据库黑盒，查看作业执行的实时情况和历史情况，便于用户分析数据库的情况。

TopSQL功能主要通过视图进行承载，如下表所示，本文以query级别的视图为例进行说明。

使用TopSQL功能需要sysadmin权限。此外，用户需先检查下TopSQL功能是否开启，涉及TopSQL的数据库GUC参数包括：

  • ENABLE_RESOURCE_TRACK (ON)

是否开启监控功能，实时TopSQL的总开关，关闭之后实时TopSQL将不再进行记录，更不会在历史TopSQL中出现。

  • RESOURCE_TRACK_COST(0)

设置对当前会话的语句进行资源监控的最小执行代价。

  • RESOURCE_TRACK_LEVEL(QUERY)

设置当前会话的资源监控的等级，默认为query级别。

  • RESOURCE_TRACK_DURATION(60S)

设置实时TopSQL中记录的语句执行结束后进行历史信息转存的最小执行时间。当执行完成的作业，其执行时间不小于此参数值时，作业信息会从实时视图（以STATISTICS为后缀的视图）转存到相应的历史视图

  • ENABLE_RESOURCE_RECORD(ON)

设置是否开启资源监控记录归档功能。开启时，对于执行结束的记录，会分别被归档到相应的INFO视图，CN和DN都需要设置上。

  • TOPSQL_RETENTION_TIME(30)

设置历史TopSQL中GS_WLM_SESSION_INFO和GS_WLM_OPERATOR_INFO表中数据的保存时间，单位为天。

参数正确设置后，TopSQL会记录用户的SQL语句执行过程中的相关信息，用户可以使用TopSQL的视图筛选出执行时间较长的作业，专注于慢SQL的分析。

TopSQL功能分为实时TopSQL和历史TopSQL，以query级别为例，当需要查看正在运行的作业时，用户可查看实时TopSQL视图GS_WLM_SESSION_STATISTICS和PGXC_WLM_SESSION_STATISTICS，若需要对已经执行完成的作业进行分析，可查询历史TopSQL视图GS_WLM_SESSION_ HISTORY和PGXC_WLM_SESSION_ HISTORY。其中GS_开头的可以查询当前CN节点上正在执行的作业信息，PGXC_开头的可查询所有CN节点上正在执行的作业信息。

实时TopSQL视图为用户记录了作业运行时的相关信息，比如作业下发来源、阻塞时间、执行时长、开始时间、内存消耗、作业下盘量、作业IO、网络、语句类型、语句的执行计划等信息。用户可先通过resource_pool、nodename、username、query等信息定位到自己需要分析的语句，再通过作业运行信息定位问题。又或者用户可通过对查询进行筛选，筛选出当前占用资源较多的作业。

历史TopSQL视图记录了作业运行结束时的资源使用情况(包括内存、下盘、CPU时间等)和运行状态信息(包括报错、终止、异常等)以及性能告警信息。用户可通过对历史语句运行数据的分析，筛选出执行时长较大的语句，看语句执行计划是否有优化的空间，是否需要对表做一些analyze或者vacuum之类的操作。又比如对于内存报错的情况，可分析内存占用高的语句是否合理，从执行计划上分析是否有优化空间。

文末附TopSQL实践：常见问题现象及对应原因。

3、TopSQL的原理解析

3.1 TopSQL原理简介：

TopSQL的数据来源于数据库内核，当语句执行时，TopSQL会实时记录语句执行的相关信息。实时TopSQL数据会保存在内存的临时表中，当语句执行结束后，数据会转存到对应实体表GS_WLM_SESSION_INFO中，在实际使用中，由于下发作业繁多，历史TopSQL记录的作业数也不断增长，这样会导致INFO表中的数据量逐渐庞大，为了确保数仓整体性能不受影响，支持通过TOPSQL_RETENTION_TIME来设置INFO表中数据的保存时间（单位为天）。当数据存留时长超过这个时限，会对实体表GS_WLM_SESSION_INFO进行数据老化删除处理。

图 3-1 TopSQL数据流通图

如图3-1所示，各项GUC参数决定了TopSQL生成的记录信息，具体的参数说明详见第2节使用TopSQL前的检验。

3.2 性能分析：

对于企业用户而言，性能问题是Top级问题，对于TopSQL功能，我们进行了性能压测，在4TB的场景下，进行TPCC基准性能测试，进行了2000的并发压测，TPMC下降了约有2%，属于可接受的范围。

3.3 相关指标

语句属性列说明：

语句的执行信息属性列,斜体代表可更换前缀/后缀式的指标，类似前缀后缀有（min_，max_，total_，average_，_skew_percent）

3.4 特殊情况说明：

TopSQL由于自身限制，存在一些记录异常的情况，此处对8.1.3版本的TopSQL语句记录情况进行说明：

  1. 不记录特殊数据定义语句，如：SET、RESET、SHOW、ALTER SESSION SET、SET CONSTRAINTS语句；
  2. 记录数据定义语句，例如：执行CREATE、ALTER、DROP、GRANT、REVOKE和VACUUM语句；
  3. 记录数据操作语句，例如：
    1. 执行SELECT、INSERT、UPDATE和DELETE语句。
    2. 执行explain analyze和explain performance场景。
    3. 执行查询query级别/perf级别视图
  4. ODBC下发作业，由于多语句原因，会记录事务的BEGIN和end语句；
  5. JDBC下发作业，随机性多记录一条JDBC的内部语句
  6. 解析错误和语法报错的异常不记录
  7. 用户手动CANCEL作业，显示的监控数据可能为0；
  8. 当子语句开关打开后，只会记录下发到DN上执行的子语句；
  9. 游标语句，当游标并非从缓存中读取数据，而确实触发语句下发到DN上执行的条件下，该游标语句会被记录，并且会进行语句、执行计划增强，但当游标从缓存中读取数据时，不进行记录；当游标语句在匿名块或者函数中使用时，当游标从DN上读取较多数据但不完全使用时，无法记录该游标在DN上的监控信息。
  10. JDBC执行的带占位符语句，通常会补齐参数内容，但如果参数和原语句合起来长度超过64KB，则不记录参数，或者如果是轻量化语句，直接下发到DN上执行，不记录参数。

4、TopSQL扩展及应用

TopSQL功能是GaussDB(DWS)支持性能问题定位、语句劣化分析、审计回溯等重要功能的基石。在此基础上，内核也拓展出了异常规则等一些高阶用法，在日常使用中，用户也对TopSQL提出了更高的要求，比如记录子语句、记录语句类型、提升算子级别语句监控准确性等诸多建议。为此，GaussDB（DWS）团队会在此基础上继续演进，更好的服务用户，提升用户满意度。

5、TopSQL实践：常见问题定位

总结一下：

  1. 因数据量变化，导致作业执行时间增加，可以分析A2/B1/D1/G1，进而确认作业查询的数据表是否有明显的数据量增加；
  2. 因其它并发作业抢占，导致作业排队，从而导致作业执行时间增加，可以分析A1/B1/D1，进而查看作业执行的同时期是否有大量并发作业在执行；
  3. 因其它作业而产生的CPU抢占，导致作业执行时间增加，可以分析A2/D1/E1，进而查看作业执行的同时期是否有大量并发作业在执行；
  4. 因其它作业而产生的IO抢占，导致作业执行时间增加，可以分析A2/F1，进而查看作业执行的同时期是否有大量并发作业在执行；
  5. I1中有结果情况，可通过提示的信息进行分析，或者进行SQL自适应诊断相关告警处理，SQL自适应诊断处理方法见：https://support.huaweicloud.com/performance-dws/dws_10_0013.html
  6. 对于enqueue异常排队的情况H1，用户可参考：GaussDB(DWS)资源管理排队原理与问题定位-云社区-华为云 (huaweicloud.com)，进行问题排查分析。

值得注意的是，发生资源争抢时，可能会出现并发症，即CPU、IO抢占，作业排队现象都会发生，针对并发症问题，可以逐步分析解决，比如：

第一步，调整作业执行顺序，减少并发作业数量，减少阻塞时间；

第二步，定位出同时段执行的典型计算密集型、存储密集型作业，先移动到其它时间段执行，减少对本作业的影响；

第三步，在无其他作业明显干预的情况下，做进一步分析，

6、参考文献：

  1. GaussDB for DWS 负载管理核心技术解密二： 白话历史资源监视-云社区-华为云 (huaweicloud.com)
  2. GaussDB(DWS)资源管理排队原理与问题定位-云社区-华为云 (huaweicloud.com)

 

点击关注，第一时间了解华为云新鲜技术~

从读写角度，带你了解数仓的IO基本框架

本文分享自华为云社区《GaussDB(DWS)基本IO框架》，作者： Naibaoofficial。

行存IO管理框架

存储结构

  • OID(Object identifiers):对象的唯一标识。
  • 每个表存在对应数据库的文件夹中，用relfilenode标识。

例如表row1，可以直接查询对应的文件

test=# select pg_relation_filepath('row1');
 pg_relation_filepath
----------------------
 base/16385/55984
(1 row)

  • 每个表的读取写入以页（文件块）为基本单位，页的大小是一个BLCKSZ，默认8KB，其结构如下：

  • Tuple保存了当前一行的数据，分为Header和Data两块，头部保存元组的相关信息（列数，事务信息，是否有Toast表等）。

  • 每个Tuple最大为2kb，若Data过大无法压缩至2KB，则采用额外的Toast表存储，此时Tuple内的Data保存Toast表的相关信息。

GaussDB 行存框架：

这里面涉及到几个比较大的内核机制：

  • 本地缓存：

    这里面的本地缓存介绍了三个比较常用的缓存结构，这里直接引用了官方的英文解释。

    temp_buffers: Sets the maximum number of temporary buffers used by each database session. These are session-local buffers used only for access to temporary tables.

    work_mem: Specifies the amount of memory to be used by internal sort operations and hash tables before writing to temporary disk files.

    maintenance_work_mem: Specifies the maximum amount of memory to be used by maintenance operations, such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY.

  • 共享内存：可由整个Gaussdb共享

    包括shared_buffer和wal_buffer, 分别用来存放Page和Clog，Wal Segment。

  • WalWriter，BgWriter：

    主要是将共享内存的内容落盘，WalWriter一般是在事务提交时就需要落盘，但是有时候可以放弃一定的事务一致性原则，从而让WalWriter异步落盘加快速度。BgWriter负责将shared_buffer中的内容落盘。

  • 外存管理：

    负责上层与外存之间的文件交互。

IO管理框架：读取

读取的过程相对简单，就是从物理文件先装到shared_buffer中，然后从shared_buffers返回相关的结果。

shared_buffers中就是以Page为单位进行存储的，因为每个Page的大小是固定的，所以shared_buffers能存放的page个数也就是确定的。这里面就需要考虑一个问题，因为这个资源是共享的，如果一个线程读取了大量的文件，这样势必会使得其他线程的缓存命中率下降。

GaussDB在这里引入了Ringbuffer的机制，可以限制一个线程所使用的shared_buffers的大小，从而解决掉这个问题。

IO管理框架：写入

  • 写入操作是增加的新的元组，Update操作相当于先Delete,再Insert。

  • INSERT

  • UPDATE

将旧元组标记为Dead，然后插入新的元组，由Vacuum负责清理。当然，这里面Data变为DELETE只是用来描述删除的是此Tuple，实际上Data当中的值是不变的。

  • 写入的整体逻辑：

GaussDB行存在写入时，将元组信息先写入到shared_buffers，然后用bgwriter刷入磁盘，这样在事务提交时就可以避免磁盘的IO开销，提升性能，为了保证一致性和恢复，使用wal日志和checkpoints可以实现日志先落盘（也可以异步）和redo等操作。

列存的IO管理框架

列存的存储单元

  • 列存的存储单元为CU（CStore Unit)
  • CU的大小为8k对齐
  • 适合大批量导入的场景
  • 同一列的CU存在一个新文件中，大于1GB时，切换到新文件中。
  • 列存用一个CUDesc的行存表描述CU的相关信息，可以理解成为一个Toast表。
  • CUDesc：行存表，记录CU的相关信息, 主要属性如下：
    1. col_id,cu_id: 第col_id列，第cu_id个CU
    2. min, max, row_count, size
    3. cu_mode: information mask(RLE,LZ4,Delta表等）
    4. cu_pointer:指向每一个CU,记录delete bitmap
    5. magic：和CU头部的magic相同，校验使用

CU结构

列存索引

这里介绍两个索引，C-Btree和Psort，这里不做过多介绍。
主要涉及的是IO相关的内容。

C-Btree

  • 索引结构和行存无差别，同样以行存形式存储
  • C-Btree可以提升点查效率
  • 存储key->ctid（cu_id, offset)
  • 过程：
    1. 根据B-tree索引找到ctid集合
    2. 对集合进行批量排序（减少IO开销）
    3. 在CUDesc找到对应的cu_id，根据offset找到数据
  • 举例，等值查询 n=49, 范围查询 23<n<64。

PSort

PSort是一个聚簇索引，对索引进行排序，然后将排序后的索引和行号存入一个新的表，用单独的列存表存储。
简单示意如下，图片来源：https://www.modb.pro/db/108155

IO管理框架：读取

  • 读取过程：

    1. 根据where条件，做MIN/MAX过滤的谓词条件
    2. 加载CUDesc
    3. MIN/MAX过滤
    4. 读取CU到CU Cache中
    5. 解析并填充

  • CacheMgr: 用来缓存CU到内存中，可以提高重复查询的性能。

  • CU的物理文件：
    1. CStore_1.0: 当前基本不怎么实用
    2. CStore_2.0: 重整了CU的文件结构，避免列数过多导致文件结构复杂。

IO管理框架：写入

列存的插入要分两种情况，少量的插入和大量的插入，列存主要是对大批量数据设计的，因此为了弥补小量插入的打包CU性能开销，设计了一个delta行存表，用来记录插入结果，可以减少膨胀和提升性能，最后定期的整理。

  • 写入框架如下

列存的删除比较简单，如果是delta表，先从delta表中删除满足谓词条件的记录，然后在CUDesc表中更新待删除CU的delete_bitmap。

点击关注，第一时间了解华为云新鲜技术~​

以上是关于带你掌握数仓的作业级监控TopSQL的主要内容，如果未能解决你的问题，请参考以下文章

带你认识数仓的增量备份核心设计

带你认识数仓的“规格变更”

从读写角度，带你了解数仓的IO基本框架

带你认识一下数仓的分区自动管理

微信 ClickHouse 实时数仓的最佳实践

从阿里核心场景看实时数仓的发展趋势