系統視圖hologres.hg_worker_info主要包含字段信息如下。

使用如下命令查詢hologres.hg_worker_info，查看每個Shard在Worker上的分布情況。

select * from hologres.hg_worker_info;

查詢結果示例如下：

 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
                    

在Hologres中數據分片（Shard）決定了數據的分布情況，一個Worker在計算時可能會訪問一個或者多個Shard的數據。同一個實例中一個Shard同一時間只能被一個Worker訪問，不能同時被多個Worker訪問。如果實例中每個Worker訪問的Shard總數不同，那么就有可能出現Worker資源負載不均的情況，主要表現為Worker節點CPU使用率監控指標中某個或者某幾個Worker的CPU使用率較低，如下圖所示。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_info與hologres.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_info與hologres.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個數的倍數。