弹性资源池
DWS存算分离版本（DWS 3.0）存在两个核心逻辑概念：固定资源池和弹性资源池。
固定资源池：根据业务需要，部署多个固定VW（Virtual Warehouse），又称主VW。不同业务绑定不同的VW，并提供业务间的负载隔离。主VW的大小在MPP架构下决定了单SQL的上限以及所能处理的QPS的极限。主VW适合承接负载稳定以及低时延的作业。DWS提供分VW的水平扩展能力，通过扩展更多节点资源来满足业务扩张的需要。管理员需要根据长期的负载推演变化趋势来提前规划主VW的规格大小。
弹性资源池：适用于细粒度时间范围的负载波动场景，存在一个或多个弹性VW。弹性VW在存储上实现了以OBS为基础储存的shared storage架构，而在计算上则是shared nothing架构。这就决定了计算和存储充分解耦，计算和存储可以实现分层扩展。计算节点扩容无需数据重分布，存储资源按需扩容，实现无限容量存储。弹性VW与主VW之间实时数据共享以解决元数据实时同步问题，避免元数据的滞后刷新，使得弹性VW能够实时利用最新的元数据进行作业执行。本篇文章主要介绍DWS手动弹性VW方案。
数据库弹性扩缩容降本增效
随着公司业务的蓬勃发展，为了满足公司业务的扩张，数据库扩容是业界通用的解决方案。业务负载在长时间维度上推演，定量扩容是一个很好的解决方案，能够支撑更多的业务并发。
但是在细粒度的时间维度上，例如具体到每周甚至每日，传统的扩容模式仍然以资源超配的方式对抗业务负载波动。考虑图2中的场景，公司的数据中台团队，在每天的凌晨12点到凌晨6点执行ETL，完成大数据量的数据离线导入；业务团队每天作业负载呈现出无规律的负载波动。传统扩容的资源超配将会浪费大量资源，使用成本高。
理想情况下，如果数据库能够根据负载波动主动地实现扩容和缩容，按需实现资源的调整能够极大地降低成本，减少资源浪费。为了更灵活、更低成本地实现数据库的扩缩容，数据库系统提供较小资源规格，以满足基础作业负载，又能在业务负载高峰期间快速扩容，保障业务的稳定性。DWS的存算分离版本中，实现了上诉的按需弹性，解决细粒度时间维度上的负载波动，主动地按需扩容弹性资源，以保障负载短期爆发的业务稳定性。
sql_hsah信息
根据作业的sql_hsah信息确定作业的历史执行情况，借助历史TopSQL的资源信息和query_plan字段分析作业性能劣化原因。
找到对应的快慢语句后，对比其执行计划query_plan，发现执行计划跳变严重。
对相应的表做analyze后，恢复合理计划，语句性能恢复。
统计信息不准，导致计划跳变，是十分常见语句变慢原因，analyze不影响读写，遇见语句变慢可预先做analyze。
作业长时间运行不结束
在作业无排队无死锁正常运行期间，发现作业长时间不结束，此时可查看算子级别的实时TopSQL监控，能够看出哪个算子执行时间长，通过算子执行时间和已处理行数等信息，确定是否需要查杀SQL。
开启实时算子监控：set resource_track_level = ‘operator_realtime’;
当发现作业内存整体使用较高，query级别的TopSQL无法记录算子的实际资源信息，此时可以设置TopSQL的监控级别为perf，query级别与perf级别的TopSQL差异主要在query_plan，perf级记录更详细执行信息，较query级性能损耗5%以内，perf级别的TopSQL的query_plan字段可显示算子的时间actual_time，memory，rows和buffer等信息。
TopSQL原理介绍
作业下发执行后，内核通过打桩记录作业的各项资源信息，如内存、CPU、下盘、IO和网络信息等，作业执行完成后该资源信息后先存在无锁队列中，资源管理后台辅助线程将该数据信息定期转储到dbms_om.gs_wlm_session_info系统表中，后续通过topsql_retention_time定期老化数据。
通常情况下，TopSQL记录的信息较多， 查询时可使用start_time做条件，避免全表查询，且使用limit对结果集大小限制，防止结果集过大导致客户端OOM。
通过TopSQL历史视图查询到有10+业务SQL存在stream数超过100，判断为CPU高的原因。
因为topsql记录了一些语句的执行情况和资源消耗情况，在定位性能问题的时候非常有帮助，比如周期执行的sql，突然有一天变慢了，我们可以通过分析语句的执行时间和阻塞时间判断是语句被阻塞了（排队等）还是执行的慢了，通过记录的执行计划分析语句为什么慢了，是不是当时的统计信息统计不准，还是没有对表做analyze，也可以看下盘量大小分析是不是下盘量大造成的性能变慢。
通过pgxc_wlm_session_info视图确认历史的SQL信息（注：历史topsql视图按天分区，查询时尽量带start_time条件）。
TopSQL与其他视图交互
不同视图从不同维度统计业务在数据库中的运行状态，因为或多或少都包含部分同类字段，可用于后续关联分析，此处给出历史TopSQL视图常交互的其他视图：
使用示例：如果某个语句在历史TopSQL 历史pgxc_wlm_session_info视图中显示以往该作业很快就能正常运行完成，但是此时查杀pgxc_stat_activity发现该语句运行很长时间没有结束，则此时可能有异常，可利用以下步骤进行定位。
查询pgxc_stat_activity活跃视图，找出长时间运行不结束的异常作业。
根据步骤1得到的query信息，查询历史TopSQL视图，比较以往和现在的运行情况，如果以前运行时间很快，但当前语句运行时间很长未结束，则可考虑该语句已发生异常（历史topsql视图按天分区，查询时尽量带start_time条件）。
根据步骤1得到的query_id查询等待视图pgxc_thread_wait_status，得到作业线程号lwtid，并打出作业堆栈进行分析。
query_plan原理
operator_realtime级别TopSQL运行时监控对于CN轻量化和存储过程的情况，暂时不支持。另由于算子执行速度较快的原因，对于算子信息的显示会有一定滞后性。
query级别的作业监控和operator的算子监控中的spill_size字段，由于统计维度不同，会有一定差异，query级别监控监控的语句实际下盘文件大小，算子监控的是具体算子在逻辑层IO读写的数据量。
当GUC参数enable_stream_operator设置为off状态时，算子执行信息存在显示不准的情况。在813版本中，除初始用户外，enable_gtm_free开启且关联队列不管控情况下，用户作业不进入资源管控。此时实时与历史TopSQL均不记录该用户下发的作业。
现网中有概率出现某一个SQL原先执行比较快，后来发现该语句执行时间变长，此时就需要利用TopSQL中的query_plan以及其他资源信息进行分析定位，毋庸置疑，query_plan中的信息越详细，越接近于explain performance，定位过程就更容易。query级别与perf级别的TopSQL差异主要在query_plan，perf级记录更详细执行信息，较query级性能损耗5%以内，perf级别的TopSQL的query_plan字段可显示算子的时间actual_time，memory，rows和buffer等信息。
operator_realtime级别TopSQL运行监控
关于存储过程中子语句的监控功能即enable_track_record_subsql，8.1.3集群版本中建议不要全面开启，由于没有按时间过滤子语句的功能，全面开启可能会记录过多子语句，导致归档的监控表占用大量磁盘空间；8.1.3集群版本建议仅用于查询实时监控信息，或对个别存储过程业务做定位分析时，仅开启对应会话中的参数。8.2.1版本新增GUC参数resource_track_subsql_duration（默认值为180秒），可以通过执行时间过滤需要归档的子语句，用户可以按需调整该值大小。
由于规格限制，对于未下盘的主语句，TopSQL历史表中的记录会有延时，等待下次作业下发时才会显示在TopSQL历史表中。
从8.2.1.200集群版本开始，新增operator_realtime级别TopSQL运行时监控，提供算子级实时监控的能力，开启此级别的监控可以查询语句的执行计划以及具体执行信息，查询TopSQL算子级实时监控视图时，默认会显示所有正在执行的语句。但是对于存储过程和游标场景，暂时不支持显示算子级实时监控信息。另由于查询所有语句的信息对于CN内存压力较大，为了不影响作业性能，为用户提供查询单个语句的函数pg_stat_get_wlm_realtime_operator_info(queryid)，可以通过该函数查询指定语句的算子执行信息。
JDBC执行的带占位符语句
重分布过程中的作业不统计。
JDBC执行的带占位符语句，通常会补齐参数内容，但如果参数和原语句合起来长度超过64KB，则不记录参数，或者如果是轻量化语句，直接下发到DN上执行，不记录参数。如果普通语句语句超过64KB，在TopSQL的query字段记录中将被截断。
从8.1.3集群版本开始，query、perf级别TopSQL运行时监控功能已完全不影响查询性能，对当前会话的语句进行资源监控的GUC参数resource_track_cost默认值已修改为0，查询TopSQL实时监控视图时，默认会显示所有正在执行的语句。
从8.1.3集群版本开始，对于存储过程中的子语句监控功能，如果在查询TopSQL实时监控视图的会话中，开启控制子语句记录归档功能的GUC参数enable_track_record_subsql，不论业务语句中是否开启子语句监控开关，查询TopSQL实时监控视图的结果都能看到执行语句的子语句运行信息。
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/tech/bigdata/316840.html