常用指标含义

  • Scan time：表示查询计划在进行扫描操作消耗的总时间，包括等待IO以及实际扫描数据所花费的时间。该指标衡量了查询的整体执行效率。
  • Scan wait time：表示查询计划在等待IO操作（例如读磁盘）的总时间。该指标反映了IO速度的影响。
  • Scan cpu time：表示查询计划在CPU处理相关操作的时间。例如，算术运算、常量表达式或者条件判断等。该指标反映了服务器负载以及查询在执行过程中的计算复杂度。
  • Fragment cpu time：表示查询计划在所有Fragments（即分区）间分配的处理器时间。Doris通常使用Fragment来存储和处理数据集的一个子集，而每个Fragment可能由多个不同的节点共享。该指标反映了不同片段间数据交换的开销、子查询和其他操作的效率等。
  • Scan worker wait time：等待scan线程调度的时间
  • Shuffle rows：代表了这个操作节点需要进行的Shuffle行数。比如在一次JOIN操作中将两表join在一起可能会有一个Shuffle 阶段
    • shuffle说明：
      • 在上述Doris的Profile中，没有特别明显的指标显示Shuffle rows。但是我们可以通过查询计划的节点名称来推断哪些节点具有Shuffle效果，并了解该节点所需Shuffle的行数。
      • 例如，在上面给出的示例中，EXCHANGE＿NODE 节点的BytesReceived的值为5.38 MB，而AGGREGATION＿NODE 节点处理了288行数据。这表明 AGGREGATION＿NODE 节点从 EXCHANGE＿NODE 节点收到了5.38MB／288≈18KB的平均数据量，这可能是通过Shuffle操作来完成的。
      • 因此，我们可以大致推断AGGREGATION＿NODE 这个节点存在Shuffle效果，并且需要打乱和重新组合288行数据。但是需要注意的是，这个推断并不准确，真正的Shuffle操作量以执行计划中标记的为准，如果遇到性能问题或瓶颈建议根据具体情况进行进一步分析。
    • 会导致的问题：
      • 1．性能下降：shuffle行数越多，则节点间传输数据量也就越大，会增加网络带宽和I0压力，消耗的计算和存储资源更多，极易导致执行时间延长甚至超出系统容忍范围。
      • 2．节点负载不均衡：当Shuffle Rows 不均衡时，一些节点可能会承担过多的数据传输和处理任务，导致部分节点负载不均衡，处理速度较慢，容易成为整个系统的性能瓶颈。
      • 3．内存溢出或产生临时文件：当Shuffle Rows较大时，如果没有正确配置内存或物理空间大小，有可能会导致内存溢出的异常情况发生。也可能需要将数据持久化到临时磁盘上，这样会增加IO开销，导致系统更加缓慢。
      • 4．容错性降低：当存在数据倾斜或者某一个节点异常难以处理其对应的shuffle数据分布时，整个系统的容错性会降低。因为要处理的数据量太大，一些节点很可能无法支撑承受，从而导致系统出现异常，进而影响数据计算和分析的准确性。
        减少 Shuffle Rows的个数和量是提高Doris查询性能和稳定性的重要策略之一。可以通过数据分区、数据倾斜解决方案和合理的Doris配置等方式来有效减少Shuffle Rows的数量并提高系统性能。


其他问题

1、scan time 和 scan cpu time的区别

在Doris查询分析中，scan time和 scan cpu time 通常是指两个不同的概念。

  • Scan time 主要指通过扫描表（即执行 Scan 操作）查询所花费的时间。它包括了所有执行Scan动作时所需的时间开销，从读取磁盘数据到对数据进行过滤和处理等全部流程，通常包括包括网络传输延迟时间、IO操作时间以及CPU计算时间。因此，Scan Time是全面衡量查询效率的主要指标之一。
  • Scan CPU time 则更侧重于测算进行 Scan过程中所消耗的CPU时间。这个指标通常可以反映Scan操作是否计算密集型，从而帮助优化和调整各个阶段SQL语句的执行的方向。例如，与Cache 相关的命中／未命中值就比较适合拿来计算 Scan CPU time。
    总体来说，Scan CPU Time 和 Scan Time 在某些情况下可能存在相关性，但并不是直接的因果关系。Scan CPU Time 用于衡量查询当中具有计算需求的部分，而Scan Time则考虑到整个扫描过程中的所有因素，因此更具全面性。

2、scan time和scan cpu time这两个值几乎一样的原因

查询计划中发现 scan time 和 scan cpu time的值基本一样，大概率是因为查询计划没有遇到需要等待I0操作的瓶颈。这意味着，数据已经存储在内存或缓存中（例如，使用了MemTable），所以查询可以快速扫描数据，而无需等待从磁盘或其他介质读取数据。
在这种情况下，scan cpu time 可能会稍微高于 scan time，因为一些额外的计算和数据处理操作可能也产生了一些CPU开销。但需要注意的是，如果查询涉及到大量的磁盘IO操作，那么 scan time与 scan cpu time 的差异可能比较明显，因为 scan wait time 会拉大二者之间的差距。
综上，当scan time和 scan cpu time 相近时，表示查询性能比较好；而当scan time 明显高于 scan cpu time 时，则很可能存在瓶颈，需要进一步排查查询中可能存在的性能瓶颈。


3、scan cpu time和fragment cpu time

不是同一个概念，fragment cpu time与对查询结果进行计算处理相关，而scan cpu time仅与表扫描相关，针对不同查询场景所涉及到的操作不同。

  • fragment cpu time指的是查询过程中分片处理数据所消耗的CPU时间，也就是所有分区计算执行所花费的时间总和。这个时间通常也被称为“计算时间”或“运算时间”。
  • 而scan cpu time则指的是扫描表时消耗的CPU时间，它只包括查询中表扫描操作涉及到的CPU时间，例如对于某些索引类型的查询，虽然涉及到表扫描，但通过特殊的索引结构可以减少需要计算的数据量，从而降低了scan cpu time的值。


    4、scan wait time和scan worker wait time的区别

Scan Wait Time（扫描等待时间）：
指的是在查询执行过程中，扫描操作等待的总时间。它包括了多个因素的等待时间，如：

  • 磁盘读取等待时间：当查询需要从磁盘读取数据时，如果磁盘繁忙或者数据量较大，需要等待磁盘完成读取操作，这部分时间就算作扫描等待时间。
  • 网络传输等待时间：如果查询需要从其他节点获取数据，而网络传输较慢或者网络拥塞，那么查询需要等待数据传输完成，这部分时间也算作扫描等待时间。
  • 数据分片等待时间：如果查询需要等待数据分片的加载或者分片的数据准备完成，那么这部分等待时间也算作扫描等待时间。
    所以，Scan Wait Time 是整个查询过程中扫描操作等待的总时间，它反映了整个查询过程中扫描操作等待的各种因素。

Scan Worker Wait Time（扫描工作进程等待时间）：
指的是查询执行过程中，扫描工作进程等待的时间。在Doris中，查询会被划分为多个任务，并由不同的工作进程去执行。而在某些情况下，工作进程可能需要等待其他资源或者等待其他任务完成。例如：

  • CPU 资源：如果工作进程需要等待CPU资源才能执行下一步操作，那么这部分等待时间就算作扫描工作进程等待时间。
  • 内存资源：如果工作进程需要等待内存资源才能继续执行查询操作，那么这部分等待时间也算作扫描工作进程等待时间。
  • 任务调度等待时间：如果工作进程需要等待调度系统分配任务，或者等待其他任务完成，那么这部分等待时间也计入扫描工作进程等待时间。

所以，Scan Worker Wait Time 反映了工作进程在执行查询时等待的时间，这些等待时间可能是由于其他资源或任务的限制而产生的。
总结来说，Scan Wait Time是整个查询过程中扫描操作等待的总时间，而Scan Worker Wait Time是工作进程在执行查询时等待其他资源或者任务完成的时间。这两个指标都是用来分析查询性能和了解查询过程中的等待情况，从而优化查询执行效率。
:::success
scan wait time在profile中叫WaitScanTime
scan worker wait time在profile中叫ScannerWorkerWaitTime

:::