文档

查看Worker倾斜关系

更新时间:

当Hologres响应速度变慢且您Hologres实例监控指标中某个或者某几个Worker的CPU使用率相比其他Worker的低时,此时可能出现了计算资源倾斜,Hologres建立了新的系统视图hologres.hg_worker_info,通过此视图可以查询当前数据库Worker、Table Group和Shard之间的关系,便于您判断资源倾斜等关系,解决资源负载不均问题,提高资源利用率。本文为您介绍如何通过hologres.hg_worker_info查看倾斜关系。

背景信息

Hologres中Worker、Table Group和Shard的概念及关系请参见产品架构基本概念。Shard Count与Worker个数存在一定的分配关系。如果Worker个数与Shard数分配不均,那么很容易出现Worker资源倾斜,导致负载不均,资源得不到高效利用。同时管理控制台监控指标已经透出Worker概念,为了便于判断资源倾斜等关系,Hologres从 V1.3版本开始提供系统视图hologres.hg_worker_info,方便您查询当前数据库的Worker、Table Group和Shard之间的关系。

使用限制

  • 仅Hologres V1.3.23及以上版本支持使用系统视图hologres.hg_worker_info,请在Hologres管理控制台的实例详情页查看当前实例版本,若实例版本较低,请您使用自助升级或加入Hologres钉钉交流群反馈,详情请参见如何获取更多的在线支持?

  • hologres.hg_worker_info展示的是实时Worker与Shard的关系,不支持展示历史关系。

  • 新建的Table Group需要一些时延才能获取worker_id的信息,一般时延在10-20s左右,如果新建Table Group后立即查找该系统视图,可能会出现worker_id为空的情况。

  • Table Group中没有表,那么Worker就会无法分配资源,查询结果中worker_id会展示为id/0。Hologres从 V2.1版本开始,如果Worker没有分配Shard,也会展示worker_id,结果为空,代表该Worker在该数据库未分配Shard。

  • 仅支持查询当前数据库的Worker、Table Group和Shard信息,不支持跨数据库查询。

使用说明

系统视图hologres.hg_worker_info主要包含字段信息如下。

字段

类型

说明

worker_id

TEXT

当前数据库所属Worker的ID。

table_group_name

TEXT

当前数据库包含Table Group的名称。

shard_id

BIGINT

Table Group下Shard的ID。

使用如下命令查询hologres.hg_worker_info,查看每个Shard在Worker上的分布情况。

select * from hologres.hg_worker_info;

查询结果示例如下:

说明

查询结果中xx_tg_internal为实例的内置Table Group,用于管理元数据等信息,无需特别关注。

 worker_id  | table_group_name | shard_id
------------+------------------+----------
 bca90a00ef | tg1              |        0
 ea405b4a9c | tg1              |        1
 bca90a00ef | tg1              |        2
 ea405b4a9c | tg1              |        3
 bca90a00ef | db2_tg_default   |        0
 ea405b4a9c | db2_tg_default   |        1
 bca90a00ef | db2_tg_default   |        2
 ea405b4a9c | db2_tg_default   |        3
 ea405b4a9c | db2_tg_internal  |        3
                    

最佳实践:解决计算资源倾斜(Worker负载不均)问题

在Hologres中数据分片(Shard)决定了数据的分布情况,一个Worker在计算时可能会访问一个或者多个Shard的数据。同一个实例中一个Shard同一时间只能被一个Worker访问,不能同时被多个Worker访问。如果实例中每个Worker访问的Shard总数不同,那么就有可能出现Worker资源负载不均的情况,主要表现为Worker节点CPU使用率监控指标中某个或者某几个Worker的CPU使用率较低,如下图所示。worker负载不均Worker负载不均会有多种原因导致,可以通过系统视图hologres.hg_worker_info做进一步分析。一般情况下原因和排查手段如下:

  • 原因1:有Worker Failover后导致Shard分配不均。

    基本概念所述,当有Worker因为OOM等原因而出现Failover时,为了能快速恢复Worker的查询,系统会将该Worker对应的Shard,快速迁移至其他Worker。当被终止的Worker恢复,系统会再分配部分Shard给它,从而出现Worker间Shard分配不均的现象。通过hologres.hg_worker_info可以查看当前数据库下每个Worker上分配的Shard数,从而判断计算资源是否有分配倾斜的情况,但需要注意的是:hologres.hg_worker_info查询的是当前数据库下Shard与Worker的关系,而计算Worker是实例共享的,因此需要查看倾斜关系时,需要查询每个数据库中Shard与Worker的关系,得出实例维度每个Worker对应的总Shard数,以此综合判断倾斜情况。

    • 命令示例:

      select worker_id, count(1) as shard_count from hologres.hg_worker_info group by worker_id;
    • 查询结果示例:

      --假设实例只有1个数据库,示例查询结果如下
       worker_id  | shard_count
      ------------+-------------
       bca90a     |      4
       ea405b     |      4
       tkn4vc     |      4
       bqw5cq     |      3
       mbbrf6     |      3
       hsx66f     |      1
      (6 rows)
    • 结果解读:

      实例只有6个Worker,但是6个Worker上分配的Shard数并不相同,查看管控台监控指标,发现较少Shard数的Worker对应的CPU使用率明显低于其他Worker,说明实例的计算资源分配不均。

    • 解决方法:

      重启实例,让计算Worker重新分配Shard,保证各个Shard在Worker上能够尽量均匀的分配。如果不重启实例,当另外的Worker出现Failover时,较空闲的Worker就会分配到更多的资源。

  • 原因2:数据倾斜导致计算资源倾斜。

    如果业务数据存在严重的倾斜,就会导致数据会分布在某些Shard,在查询时Worker负载就会访问固定的Shard,导致出现CPU负载不均的情况。可以通过hologres.hg_worker_infohologres.hg_table_properties两个系统视图结合查询,根据表倾斜的数据对应的worker id,从而判断是否是因为数据倾斜导致的计算资源倾斜,步骤如下。

    1. 查看数据倾斜情况。

      通过以下SQL查看表是否存在数据倾斜的情况,如果某个Shard的数据与其他Shard的数据相差较大,则说明这个表的数据存在倾斜。

      select hg_shard_id,count(1) from <table_name> group by hg_shard_id order by 2;
      
      --示例结果:shard 39的count值较大,存在倾斜
      hg_shard_id | count
      -------------+--------
                53 |  29130
                65 |  28628
                66 |  26970
                70 |  28767
                77 |  28753
                24 |  30310
                15 |  29550
                39 | 164983
    2. 通过数据倾斜的hg_shard_id查询对应的worker_id

      上一步骤得出哪个Shard数据存在倾斜,可以通过hg_shard_id结合hologres.hg_worker_infohologres.hg_table_properties两个系统视图,查询出倾斜的Shard对应的worker_id,命令示例如下 。

      SELECT distinct b.table_name, a.worker_id, a.table_group_name,a.shard_id from
      hologres.hg_worker_info a
      join (SELECT property_value, table_name
      FROM hologres.hg_table_properties
      WHERE property_key = 'table_group') b
      on a.table_group_name = b.property_value and b.table_name = '<tablename>' and shard_id=<shard_id>;
      
      --查询结果示例
      table_name  | worker_id  | table_group_name  | shard_id
      ------------+------------+-------------------+------------------
       table03    | bca90a00ef | db2_tg_default    | 39

      通过结果中的worker_id,结合Worker节点CPU使用率监控指标,如果该Worker的负载情况明显高于其他Worker,则说明是数据倾斜导致的资源倾斜。

    解决方法:

    1. 设置合适的Distribution Key,让数据尽可能的在Shard间分布均匀,详情请参见优化内部表的性能

    2. 如果是业务的数据倾斜比较严重,例如直播订单表的商品交易总额(GMV),可能存在不同主播数据有明显的差异,可以考虑拆分成多个表来实现。

  • 原因3:Shard数设置不合理

    建议Shard数尽量与Worker的个数存在一定的倍数关系,这样才能使得Worker间的负载尽量均衡,如果Shard数设置不够合理,会导致Worker负载可能出现不均的情况。可以通过hologres.hg_worker_info查看当前数据库下TableGroup设置的Shard数是否合理。

    • 命令示例

      select table_group_name, worker_id, 
      count(1) as shard_count from hologres.hg_worker_info 
      group by table_group_name, worker_id order by table_group_name desc;
    • 示例结果

       table_group_name | worker_id  | shard_count
      ------------------+------------+-------------
       tg2              | ea405b4a9c |           1
       tg2              | bca90a00ef |           2
       tg1              | ea405b4a9c |           5
       tg1              | bca90a00ef |           6
       db2_tg_default   | bca90a00ef |           4
       db2_tg_default   | ea405b4a9c |           4
       db2_tg_internal  | bca90a00ef |           1
      (7 rows)
    • 结果解读(假设实例只有2个Worker)

      • tg2设置了3个Shard,其中一个Worker会少分配一个Shard,如果性能不满足预期,建议优化Shard数或者扩容。

      • tg1设置了11个Shard,其中一个Worker会少分配一个Shard,如果性能不满足预期,建议优化Shard数或者扩容。

      • 默认Table Groupdb2_tg_default设置了8个Shard,Worker分配的Shard较均匀。

    • 解决方法

      如果是Shard数设置不合理导致Worker资源倾斜,可以根据业务情况综合评估Shard数的设置,建议设置成Worker个数的倍数。