通過hologres.hg_worker_info查看傾斜關係 - Hologres

當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管理主控台的執行個體詳情頁查看當前執行個體版本，若執行個體版本較低，請您使用自助升級或加入HologresDingTalk交流群反饋，詳情請參見如何擷取更多的線上支援？。
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負載不均會有多種原因導致，可以通過系統檢視表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個數的倍數。