健康报告_开源大数据平台 E-MapReduce(EMR)-阿里云帮助中心

本文介绍EMR Serverless StarRocks提供的健康报告内容，并通过示例阐明其潜在的应用场景。该健康报告提供了前一天（T+1）的数据，并包括SQL查询、表分析、导入任务和缓存分析部分。

查看健康报告

进入EMR Serverless StarRocks实例列表页面。
1. 登录E-MapReduce控制台。
2. 在左侧导航栏，选择EMR Serverless > StarRocks。
3. 在顶部菜单栏处，根据实际情况选择地域。
单击目标实例ID。
单击健康诊断页签。
单击健康报告页签。
在健康报告页面，您可以查看SQL查询、表分析、导入任务及缓存分析报告。

SQL查询

该页面展示了查询耗时、DB Lock、SQL查询分析和参数化SQL分析部分内容。您可以通过选择特定的日期、SQL类型和数据库目录，来查看TOP SQL指标。

支持以下SQL类型：

DML：用于数据的查询和变更操作。例如，SELECT、UPDATE、DELETE等语句。
DDL：用于定义和修改数据结构的语句。例如，CREATE、ALTER等。
其他：包括非DML和DDL类的SQL命令。例如，SHOW等辅助命令语句。

查询耗时

查询耗时数据是基于每日审计数据进行统计分析。

以P99查询耗时（Query Latency P99）为例，这是性能监控中的一个重要指标，用于衡量系统响应时间的分布情况。具体而言，P99表示99%的请求能够在该时间内得到响应。此指标对于评估服务质量和用户体验至关重要。

通过监控P99耗时，可以深入了解大多数用户实际体验到的服务响应速度。如果发现P99耗时过高，则可能需要增加计算资源或优化查询逻辑，以提升处理效率。

通过展示最近七天的查询耗时数据，能够提前识别实例潜在的性能风险，从而避免对服务造成重大影响。

DB Lock

DB Lock功能用于监控和分析数据库访问过程中出现的锁竞争状况，特别是在多个事务尝试同时访问或修改同一数据资源时。为了确保数据的一致性和完整性，数据库会采用锁机制来控制对特定数据行或表的并发访问。如果某事务长时间等待获取锁，则会影响整体系统的响应速度和服务质量。通过DB Lock数据，可以辅助分析性能问题。

SQL查询分析

该部分内容是对StarRocks执行的SQL语句的查询时间、CPU消耗以及内存消耗等维度进行排序，从而获取TOP SQL并展现相应的执行指标。您可以基于这些指标对潜在的性能问题进行优化。例如，可以从慢SQL Top10中查看指定日期执行时间最长的10条SQL语句。然后，根据Profile查询分析提供的详细信息来优化这些慢执行的SQL语句，Profile分析详情请参见Query Profile介绍。

报表主要字段说明如下。

字段名称	说明
查询ID	StarRocks中每次SQL执行产生的唯一标识符。每一次SQL执行都会生成新的ID。
用户	执行SQL的StarRocks数据库用户。
查询时间	SQL执行过程中消耗的时间。单位：ms。
CPU执行时间	SQL执行过程中消耗的CPU时间，是所有参与执行的CPU核数的CPU时间汇总。单位：ns。
内存占用	SQL执行过程中消耗的内存。单位：bytes。
扫描字节数	SQL执行过程中访问的数据量大小。单位：bytes。
扫描行数	SQL执行过程中访问的数据行数。
返回行数	SQL执行后返回的结果行数。
SQL文本	被执行的具体SQL语句文本。

参数化SQL分析

参数化SQL是指将SQL语句中的常量替换成?参数，同时保留原有语法结构，并删除注释、调整空格，生成新的SQL语句。参数化SQL将原始SQL的语法结构映射成相同的参数化SQL语句，有助于对同类型的SQL进行综合分析。

例如，对于以下两个SQL语句，当它们经过参数化处理后，它们属于同一类SQL。

原始SQL

SELECT * FROM orders WHERE customer_id=10 AND quantity>20

SELECT * FROM orders WHERE customer_id=20 AND quantity>100

参数化后SQL

SELECT * FROM orders WHERE customer_id=? AND quantity>?

参数化SQL分析从SQL执行频次、SQL执行总耗时、SQL耗时离散度、SQL CPU资源总消耗、SQL内存资源总消耗、SQL执行失败频次等维度进行排序，获取相应的TOP SQL并展现相关指标。

通过参数化SQL分析，您可以：

获取StarRocks数据库整体的SQL执行情况。
通过优化执行次数较多、执行时间较长以及CPU和内存消耗较多的SQL，以获取更大的优化收益。

通过查询时间变异系数来衡量SQL执行的时间稳定性，可以发现潜在的性能问题。例如，同类SQL执行时间变长可能是由于数据倾斜、资源不足导致的pending等原因。

涉及字段说明如下。

字段	说明
参数化SQL ID	参数化SQL的哈希值，用于标记参数化SQL。
查询时间变异系数	SQL查询执行时间标准差与其平均值的比值。通常变异系数越大，代表同类SQL每次执行的时间差别越大。
执行次数	参数化SQL的总执行次数。
参数化SQL文本	参数化后的SQL文本语句。

通过执行失败次数查找对应的SQL失败原因，来发现潜在的问题。

涉及字段说明如下。

字段	说明
参数化SQL ID	参数化SQL的哈希值，用于标记参数化SQL。
执行失败次数	参数化SQL执行失败的次数。
执行次数	参数化SQL的执行总次数。
参数化SQL文本	参数化后的SQL文本语句。

表分析

该页面展示数据表的查询热度、查询SQL类型、数据分布均衡度等相关的指标，为优化数据表提供判断依据。主要指标如下表所示。

指标	说明
SQL执行次数	是指包含这张表的SQL的总执行次数。通常表的执行次数越多，越需要对表设计进行精心的优化，以改善Starrocks实例的使用。
关联的参数化SQL个数	这里指的是这张表关联了几个参数化SQL。您可以分析表的查询SQL类型模式来优化表的设计。更进一步的，您可以从不同的查询类型中识别共性，看是否需要创建物化视图来加速对这张表中数据的查询。
Tablet数据大小变异系数	是指同一个分区内的tablet数据大小变异系数，代表了一个表的数据的tablet分布均衡程度。计算方式为：同一个分区内tablet数据大小的标准差除以平均值。一般来说，变异系数越大，这个分区越有可能存在数据倾斜的情况。

导入任务

该页面展示导入任务的统计信息，并从多个角度对导入任务进行分析。

说明

目前系统仅能支持统计和分析存算一体实例下的导入任务情况。

Too many versions场景

导入频率过高的数据是基于“too many versions”日志的统计分析得出的。当Compaction Score超过1000时，系统将会报告错误，StarRocks会提示“Too many versions”。为了解决此问题，您可以降低导入的并发量和频率。

Top分析

Top导入热表潜在小文件分析

针对表级别的数据导入情况，系统将会对每个表的所有导入任务生成的数据文件进行深入分析，以评估其潜在的小文件问题严重程度，并据此计算出一个影响得分。根据该得分从高至低排序，选出Top 20个受小文件问题影响最大的表。小文件问题的存在可能导致查询性能下降以及Compaction操作效率降低。针对此问题，建议您：

结合表的实际数据规模，科学合理地选择分区与分桶的数量，以有效避免小文件问题的发生。
通过适度增大批量处理的规模，可以在提高整体数据处理吞吐量的同时，有效减少对象存储中的小文件数量。
虽然Compaction能够整合数据文件、提升系统性能，但其运行过程中会占用一定的系统资源。因此，在资源较为紧张的情况下，建议适当调整Compaction频率以平衡资源使用效率。

以下是用于评估小文件影响得分的具体算法：

主键表：计算公式为写入文件总数÷写入文件的平均大小。若平均文件大小较小，同时文件数量较多，则表明此类表的小文件问题潜在影响也越大。
非主键表：计算公式改为写入文件总数平均÷写入单个文件所需时间。当平均写入文件耗时较短，同时文件数量较大时，此类表的小文件问题潜在影响也越大。

通过上述算法，我们可以量化表的小文件问题，从而有针对性地对Top 20的表进行优化处理，以改善整体集群性能。

主要字段说明如下。

字段	说明
表集合	记录导入任务可能同时写入的所有相关表信息，表现为一个包含多个表的集合。
表类型	用于区分不同类型的表，主要分为主键表和非主键表两类。非主键表包括明细表、聚合表和更新表。
小文件影响得分	通过算法评估潜在小文件问题的影响得分，评分值越高代表潜在的小文件问题越严重。
更新的数据分桶数	统计在导入任务过程中涉及到的需要更新的Tablet的总量。
写入文件数	写入的Segment文件的总数量。
平均写文件大小	总写入数据大小除以写入文件总数，用以表示每个文件的平均写入数据量。
平均写文件耗时	文件写入总耗时除以文件总数，反映了每次文件写入操作的平均所需时间。

Top导入热表分析

按表粒度对导入任务数量进行排序并选取Top 20的表，这些表的导入任务执行最为频繁且涉及的数据导入事务最多。

导入热节点分析

可以通过对各节点的统计数据进行导入，来分析数据的均衡度。例如，您可以从写入总大小指标分析各个broker的写入是否均衡。

缓存分析

该页面展示了存算分离版实例缓存相关指标的统计信息，并从表维度、参数化SQL维度和单SQL维度对缓存进行分析，按照天来查看不同维度下的TOP指标。

说明

该功能暂不适用于存算一体版实例。

使用说明

提高实例的缓存命中率有助于提升查询性能。该页面根据Query Profile数据对实例的缓存情况进行分析，Query Profile记录了查询中涉及的所有算子的执行信息，可以从中获取一条查询从本地缓存读取的数据量和从远程读取的数据量等指标，便于对缓存使用情况进行深入分析。

在Query Profile中，对表、视图或物化视图的每一次扫描均对应一个CONNECTOR_SCAN算子。Query Profile提供了该算子的各项指标，其中一些与缓存相关的指标如下表所示。

指标	含义	内表	外表
缓存命中量	从缓存读取的字节数。	CompressedBytesReadLocalDisk	dataCacheReadBytes
缓存miss量	从远程读取的字节数。	CompressedBytesReadRemote	FSIOBytesRead
本地IO次数	从缓存读取的IO次数。	IOCountLocalDisk	dataCacheReadCounter
远程IO次数	从远程读取的IO次数。	IOCountRemote	FSIOCounter
本地IO时间	从缓存读取耗时。	IOTimeLocalDisk	dataCacheReadTimer
远程IO时间	从远程读取耗时。	IOTimeRemote	FSIOTime

根据上述指标，可以进一步计算出以下三个缓存相关的指标：

缓存命中率 = 缓存命中量 /（缓存命中量 + 缓存miss量）
本地IO时间占比 = 本地IO时间 /（本地IO时间 + 远程IO时间）
本地IO次数占比 = 本地IO次数 /（本地IO次数 + 远程IO次数）

从一天的Query Profile记录中提取出所有SQL的CONNECTOR_SCAN算子的上述指标，并按照以下三个维度进行分组，计算出每个分组的平均缓存命中量、缓存命中率等指标，有助于从不同维度对缓存情况进行分析。各个维度的使用场景示例如下表所示。

维度	应用场景
表维度	找出访问频率高、缓存命中率低、缓存miss量高的表。通过缓存预热等手段优化其缓存情况，有助于提升查询性能。
参数化SQL维度	分析包含CONNECTOR_SCAN算子数量最多或平均查询时间最长的参数化SQL的缓存命中情况，可以优先对这些SQL进行优化，或者针对其访问的表实施缓存预热，从而有效提升查询性能。
单SQL维度	针对查询时间较长、缓存命中率低或缓存miss数量较高的SQL进行深入分析，通过优化SQL语句或对其访问的表进行缓存预热，有助于提高查询性能。

表维度

该部分内容展示数据表的访问次数、缓存命中率、缓存命中量、缓存miss量等指标，并根据这些指标对表进行排序。通过从表的维度进行分析，可以获取与缓存相关的以下信息：

查看访问次数排名靠前的表的缓存命中情况。例如，下图中访问次数最高（6411次）的表，其缓存命中率仅为24.2%。提高该表的缓存命中率将有助于提升查询效率。可以通过对这类访问频率高且缓存命中率低的表进行缓存预热，以优化缓存的使用。
查看缓存命中率低或缓存miss量高的表，采用缓存预热的方法以改善其缓存状况，从而提升相应查询的性能。

在实际使用过程中，通常需要综合多个指标来判断是否对该表进行缓存预热。例如，如果一张表同时出现在“访问频率 Top20”、“缓存命中率低 Top20”和“平均缓存miss量 Top20”这三个表中，说明该表的访问频率较高、查询数据量大且缓存命中率低，因此应优先对其进行预热处理。

涉及主要字段说明如下表所示。

字段	说明
访问次数	扫描该表的CONNECTOR_SCAN算子的数量。
缓存命中率	通过`缓存命中总量 / （缓存命中总量 + 缓存miss总量）`计算，反映从本地缓存中成功读取数据的比例。其中，缓存命中总量为所有CONNECTOR_SCAN算子从本地缓存中读取的数据总量，缓存miss总量为所有CONNECTOR_SCAN算子从远程存储中读取的数据总量。
本地IO时间占比	通过`本地IO总时间 / （本地IO总时间 + 远程IO总时间）`计算，反映读取本地缓存的IO耗时占总体的比例。其中，本地IO总时间为所有CONNECTOR_SCAN算子读取本地缓存的IO耗时之和，远程IO总时间为所有CONNECTOR_SCAN算子读取远程存储的IO耗时之和。
本地IO次数占比	通过`本地IO总次数 / （本地IO总次数 + 远程IO总次数）`计算，反映读取本地缓存的IO次数占总体的比例。其中，本地IO总次数为所有CONNECTOR_SCAN算子读取本地缓存的IO次数之和，远程IO总次数为所有CONNECTOR_SCAN算子读取远程存储的IO次数之和。
平均缓存命中量	通过`缓存命中总量 / 执行次数` 计算，反映平均每次执行时从缓存中读取的数据量。
平均缓存miss量	通过`缓存miss总量 / 执行次数`计算，反映平均每次执行时未命中缓存并从远程存储中读取的数据量。

参数化SQL维度

参数化SQL分析对扫描次数、缓存命中率、缓存命中量、缓存miss量等指标进行排序，以获取相应的TOP参数化SQL并展示相关指标。

通过参数化SQL分析，您可以获取以下信息：

查看扫描次数排名靠前的参数化SQL的缓存命中情况。例如，下图中排名第七的参数化SQL扫描次数为1086，且平均查询时间较长（42.5秒），然而其缓存命中率仅为6.5%。通过对这些SQL进行优化，或对其扫描的表进行预热，可以更有效地利用缓存，从而提升查询性能。
查看平均查询时间排名靠前的参数化SQL的缓存命中情况。例如，下图所示，排名第一的参数化SQL平均查询时间为201秒，但其扫描次数仅为4次，说明该参数化SQL对应冷查询，是否需要进行优化可依据实际业务需求进行判断；而排名第七的参数化SQL平均查询时间为42.5秒，扫描次数却达到了1086次，相比之下，该参数化SQL更值得关注。
查看缓存命中率较低、缓存miss量较高的参数化SQL，并结合这些SQL的扫描次数、平均查询时间等指标决定是否对其进行优化。

涉及主要字段说明如下表所示。

字段	说明
参数化SQL ID	参数化SQL的哈希值，用于标记参数化SQL。
扫描次数	一条参数化SQL对应的所有SQL的CONNECTOR_SCAN算子数量之和。
缓存命中率	通过`缓存命中总量 / （缓存命中总量 + 缓存miss总量）`计算。其中，缓存命中总量为所有CONNECTOR_SCAN算子从本地缓存中读取的数据总量，缓存miss总量为所有CONNECTOR_SCAN算子从远程存储中读取的数据总量。
本地IO时间占比	通过`本地IO总时间 / （本地IO总时间 + 远程IO总时间）`计算。其中，本地IO总时间为所有CONNECTOR_SCAN算子读取本地缓存的IO耗时之和，远程IO总时间为所有CONNECTOR_SCAN算子读取远程存储的IO耗时之和。
本地IO次数占比	通过`本地IO总次数 / （本地IO总次数 + 远程IO总次数）`计算。其中，本地IO总次数为所有CONNECTOR_SCAN算子读取本地缓存的IO次数之和，远程IO总次数为所有CONNECTOR_SCAN算子读取远程存储的IO次数之和。
平均缓存命中量	通过`缓存命中总量 / 执行次数` 计算，反映平均每次执行时从缓存中读取的数据量。
平均缓存miss量	通过`缓存miss总量 / 执行次数`计算，反映平均每次执行时未命中缓存并从远程存储中读取的数据量。
参数化SQL语句	经过参数化处理的SQL文本语句。

SQL维度

该部分内容是对StarRocks执行的SQL语句按照查询时间、缓存命中率、缓存命中量、缓存miss量等指标进行排序，从而获取TOP SQL并展现相应的指标。

您可以基于这些指标对缓存进行深入分析，例如查看执行时间较长、缓存命中率较低以及缓存未命中数量较高的SQL语句。通过对这些SQL语句进行优化或对其访问的表实施缓存预热等方法，可以有效改善缓存命中情况。

涉及主要字段说明如下表所示。

字段	说明
查询ID	StarRocks中每次SQL执行产生的唯一标识符。每次SQL执行均会产生一个新的ID。
查询时间	SQL执行过程中所消耗的时间，单位为秒（s）。
缓存命中率	通过`缓存命中总量 / （缓存命中总量 + 缓存miss总量）`计算。其中，缓存命中总量为所有CONNECTOR_SCAN算子从本地缓存中读取的数据总量，缓存miss总量为所有CONNECTOR_SCAN算子从远程存储中读取的数据总量。
本地IO时间占比	通过`本地IO总时间 / （本地IO总时间 + 远程IO总时间）`计算。其中，本地IO总时间为所有CONNECTOR_SCAN算子读取本地缓存的IO耗时之和，远程IO总时间为所有CONNECTOR_SCAN算子读取远程存储的IO耗时之和。
本地IO次数占比	通过`本地IO总次数 / （本地IO总次数 + 远程IO总次数）`计算。其中，本地IO总次数为所有CONNECTOR_SCAN算子读取本地缓存的IO次数之和，远程IO总次数为所有CONNECTOR_SCAN算子读取远程存储的IO次数之和。
数据表	SQL语句查询所有表、视图及物化视图。
用户名	执行SQL的StarRocks数据库用户。
sumSegmentInit	SQL查询中所有CONNECTOR_SCAN算子的Segment初始化时间之和。
SQL语句	具体执行SQL语句文本。