全部產品
Search
文件中心

Hologres:Hologres Dynamic Table營運重新整理任務

更新時間:Feb 05, 2026

當Dynamic Table的資料來源基表發生變化時,需要通過重新整理Dynamic Table來更新資料。Dynamic Table將根據設定的重新整理開始時間和重新整理間隔,自動在後台執行重新整理任務。本文將為您介紹如何查看和維護Dynamic Table的重新整理任務。

監控與警示

監控指標

自V4.0.8版本起,Dynamic Table提供以下監控指標,便於您營運重新整理任務:

執行個體層級動態表重新整理失敗QPS(count/s)

表示執行個體內所有Dynamic Table的重新整理失敗QPS,用於反映整體重新整理健康度。正常情況該指標應接近0;若持續非0或明顯抬升,通常表示存在持續失敗的重新整理任務,建議您前往HoloWeb控制台,在Dynamic Table介面查看失敗任務並儘快處理。

動態表資料延遲(s)

表示執行個體內每張Dynamic Table的資料相對上遊基表最新資料(或預期時間點)的延遲,單位:秒,用於反映資料即時性。建議您根據業務需求設定合理的延遲警示閾值。若延遲持續上升,可能原因包括:

  • 重新整理持續失敗或已暫停自動重新整理,請前往HoloWeb控制台的Dynamic Table管理介面排查。

  • 上遊發生巨量資料量變更,執行個體資源不足導致重新整理變慢,可結合Hologres監控與重新整理時間長度等指標綜合排查。

動態表正在啟動並執行重新整理持續時間長度(ms)

表示執行個體內每張Dynamic Table當前重新整理任務已持續啟動並執行時間,單位:毫秒,用於判斷重新整理周期是否變長。建議您按業務情境為不同表設定重新整理持續時間長度警示。若該指標突然升高或長期明顯高於歷史水平,可重點排查執行個體資源瓶頸、上遊資料量變化等因素。

動態表重新整理失敗QPM(count/m)

表示執行個體內每張Dynamic Table每分鐘的重新整理失敗次數(分鐘粒度),用於評估單表重新整理穩定性。正常情況該指標應為0。偶發失敗(如因系統壓力、執行個體升級等)且後續重新整理恢複成功時,一般可忽略;若某張表的該指標持續大於0,說明該表重新整理任務長期異常,請根據Dynamic Table失敗日誌中的錯誤資訊進行排查與處理。

警示

您可以通過CloudMonitor為Dynamic Table重新整理任務配置警示規則,以便及時發現異常。具體操作請參見CloudMonitor

查看重新整理任務

查看運行中的重新整理任務

通過hologres.hg_dynamic_table_refresh_activity查看

您可以通過hologres.hg_dynamic_table_refresh_activity查看正在運行中的重新整理任務(包括全量重新整理和增量重新整理),以及資源消耗等。hologres.hg_dynamic_table_refresh_activity系統資料表欄位介紹詳情,請參見hologres.hg_dynamic_table_refresh_activity系統資料表

說明

僅Hologres V3.0版本、V4.0.8及以上版本支援該系統資料表。

--查看當前正在啟動並執行重新整理任務
SELECT
    pid,
    query_id,
    refresh_mode,
    'RUNNING' as status,
    refresh_start,
    extract(epoch from duration) as duration, -- milliseconds
    serverless_queue_time_ms::bigint / 1000 AS serverless_queue_time_sec,
    serverless_resource_used_time_ms::bigint / 1000 AS serverless_resource_used_time_sec,
    serverless_allocated_cores
FROM
    hologres.hg_dynamic_table_refresh_activity
WHERE datname = '${database}'
  AND table_write = quote_ident('${schema}') || '.' || quote_ident('${tableName}')
ORDER BY refresh_start DESC
limit 2000;

通過hg_stat_activity查看

您可以通過hg_stat_activity系統檢視表查看正在運行中的重新整理任務,在hg_stat_activity中不同的重新整理模式顯示存在差異:

  • 全量重新整理:會展示INSERT語句。

  • 增量重新整理:會展示Refresh任務。

通過監控指標查看重新整理任務

您可以通過查看QPS、RPS、Latency等指標,確認Dynamic Table重新整理任務的執行情況,其中Command Type為refresh,即為Dynamic Table的重新整理任務。關於監控指標詳情,請參見Hologres管控台的監控指標

若Dynamic Table重新整理任務,在Serverless Computing資源中運行,您也可以Serverless Computing相關指標中進行查看。

說明

Dynamic Table重新整理任務支援通過CloudMonitor,建立警示規則,詳情請參見CloudMonitor

查看歷史重新整理任務

通過hologres.hg_dynamic_table_refresh_history查看

hologres.hg_dynamic_table_refresh_history系統資料表會記錄近一個月,所有Dynamic Table重新整理任務(包括全量重新整理、增量重新整理、手動重新整理)的歷史資訊。hologres.hg_dynamic_table_refresh_history系統資料表欄位介紹詳情,請參見hologres.hg_dynamic_table_refresh_history 系統資料表

說明
  • 資料預設保留近一個月的記錄,無法查詢一個月之前的資料。

  • 表Owner僅能查看自身的重新整理歷史,而Superuser則具備查看所有重新整理記錄的許可權。

  • 樣本1:查看增量重新整理過去一天的記錄。

    --樣本1:查看增量重新整理過去一天的記錄
    SELECT
        query_id,
        refresh_mode,
        status,
        refresh_start,
        duration,
        refresh_latency / 1000 AS refresh_latency_second,
        serverless_allocated_cores,
        queue_time_ms::bigint / 1000 AS queue_time_second,
        serverless_resource_used_time_ms::bigint / 1000 AS serverless_resource_used_time_second
    FROM
        hologres.hg_dynamic_table_refresh_history
    WHERE
        refresh_start >= CURRENT_DATE - INTERVAL '1 day'
        AND dynamic_table_name = '<dynamic_table>'
        AND refresh_mode = 'incremental'
    ORDER BY
        refresh_start DESC
    limit 100;
    
  • 樣本2:查看當前執行個體,過去1天所有的重新整理任務。

    --查看執行個體內過去1天所有的重新整理記錄
    SELECT 
    query_id,
        refresh_mode,
        status,
        refresh_start,
        duration,
        refresh_latency / 1000 AS refresh_latency_second,
        serverless_allocated_cores,
        queue_time_ms::bigint / 1000 AS queue_time_second,
        serverless_resource_used_time_ms::bigint / 1000 AS serverless_resource_used_time_second
    FROM hologres.hg_dynamic_table_refresh_history where refresh_start >= CURRENT_DATE - INTERVAL '1 day'
  • 樣本3:查看指定表過去一天的重新整理記錄。

    --查看某個表過去一天的重新整理記錄
    SELECT 
    query_id,
        refresh_mode,
        status,
        refresh_start,
        duration,
        refresh_latency / 1000 AS refresh_latency_second,
         serverless_allocated_cores,
        queue_time_ms::bigint / 1000 AS queue_time_second,
        serverless_resource_used_time_ms::bigint / 1000 AS serverless_resource_used_time_second
    FROM hologres.hg_dynamic_table_refresh_history where schema_name='<scehma_name>' and dynamic_table_name='<dynamic_table>' and  refresh_start >= CURRENT_DATE - INTERVAL '1 day'
說明

對於3.0舊文法建立的全量模式Dynamic Table,hologres.hg_dynamic_table_refresh_history可能無法反映重新整理的真實成功或失敗狀態,失敗的重新整理也可能展示為Success。可通過以下方式查詢某張3.0文法全量Dynamic Table的真實重新整理歷史狀態:

  1. hologres.hg_dynamic_table_properties擷取cron_job_name

  2. 使用cron_job_namehologres.hg_user_cron_tasks中查詢Cron任務執行記錄。

-- 擷取cron_job_name
SELECT property_value AS cron_job_name
FROM hologres.hg_dynamic_table_properties
WHERE dynamic_table_name = '<dt_name>' AND property_key = 'cron_job_name';

-- 通過cron_job_name查詢Cron任務執行記錄
SELECT *
FROM hologres.hg_user_cron_tasks
WHERE jobname = '<cron_job_name>'
ORDER BY start_time DESC;

通過慢Query日誌查看

您可以通過慢Query日誌查看Dynamic Table的重新整理任務,Command Type為refresh。通過慢Query日誌查看詳情,請參見慢Query日誌查看與分析

查看重新整理任務的執行計畫

與普通Query一致,支援通過EXPLAIN和EXPLAIN ANALYZE查看重新整理任務的執行計畫和運行資訊,以便於分析重新整理任務的效能瓶頸,協助業務進一步Query調優。樣本如下:

 explain refresh dynamic table hmtest.dt_order_lineitem;
                                                                                                  QUERY PLAN                                                 
                                                 
-------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------
 Gather  (cost=0.00..10.13 rows=1 width=16)
   ->  Insert  (cost=0.00..10.13 rows=1 width=16)
         ->  Redistribution  (cost=0.00..10.11 rows=1 width=16)
               ->  Final HashAggregate  (cost=0.00..10.11 rows=1 width=16)
                     Group Key: orders.o_orderpriority
                     ->  Redistribution  (cost=0.00..10.11 rows=10 width=16)
                           Hash Key: orders.o_orderpriority
                           ->  Partial HashAggregate  (cost=0.00..10.11 rows=10 width=16)
                                 Group Key: orders.o_orderpriority
                                 ->  Hash Left Semi Join  (cost=0.00..10.11 rows=1000 width=8)
                                       Hash Cond: (orders.o_orderkey = lineitem.l_orderkey)
                                       ->  Redistribution  (cost=0.00..5.03 rows=1000 width=16)
                                             Hash Key: orders.o_orderkey
                                             ->  Local Gather  (cost=0.00..5.01 rows=1000 width=16)
                                                   ->  Seq Scan on orders  (cost=0.00..5.01 rows=1000 width=16)
                                                         Filter: ((o_orderdate >= '1996-07-01 00:00:00+08'::timestamp with time zone) AND (o_orderdate < '199
6-10-01 00:00:00+08'::timestamp with time zone))
                                       ->  Hash  (cost=5.03..5.03 rows=1000 width=8)
                                             ->  Redistribution  (cost=0.00..5.03 rows=1000 width=8)
                                                   Hash Key: lineitem.l_orderkey
                                                   ->  Local Gather  (cost=0.00..5.03 rows=1000 width=8)
                                                         ->  Seq Scan on lineitem  (cost=0.00..5.03 rows=1000 width=8)
                                                               Filter: (l_commitdate < l_receiptdate)
 Optimizer: HQO version 2.1.0
(23 rows)

設定重新整理逾時時間長度

與普通Query一樣,Dynamic Table的重新整理任務也支援設定逾時時間長度。

表層級設定

建立Dynamic Table表時,設定重新整理任務逾時時間長度,對該表的所有重新整理任務都生效。以下SQL代碼以tpch_10g公用資料集為例,在執行之前,請確保已成功匯入tpch_10g公用資料集。具體操作,請參見建立公用資料集匯入任務

--建立表時設定重新整理任務逾時時間。
CREATE DYNAMIC TABLE tpch_q1_batch
  WITH (
    refresh_mode='full',
    auto_refresh_enable='true',
    full_auto_refresh_interval='1 hours',
    refresh_guc_statement_timeout='30 mins'--重新整理逾時時間為30 mins
       ) 
AS
  SELECT
        l_returnflag,
        l_linestatus,
        SUM(l_quantity) AS sum_qty,
        SUM(l_extendedprice) AS sum_base_price,
        SUM(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
        SUM(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
        AVG(l_quantity) AS avg_qty,
        AVG(l_extendedprice) AS avg_price,
        AVG(l_discount) AS avg_disc,
        COUNT(*) asAScount_order
FROM
        hologres_dataset_tpch_10.lineitem
WHERE
        l_shipdate <= DATE '1998-12-01' - INTERVAL '120' DAY
GROUP BY
        l_returnflag,
        l_linestatus;

Session層級設定

手動重新整理時,可通過Session級GUC設定逾時時間長度,SQL樣本如下。

SET statement_timeout = <time>;
refresh DYNAMIC TABLE <dynamic_schema_name.dynamic_table_name>;

關於更多設定詳情,請參見修改活躍Query逾時時間

通過 refresh with option 設定

手動重新整理時,也可通過refresh ... with (refresh_guc_statement_timeout = '...')為當次重新整理指定逾時時間。樣本如下。

REFRESH DYNAMIC TABLE <schema_name.table_name> WITH (
    refresh_guc_statement_timeout = '30 mins'
);

手動重新整理

支援對Dynamic Table執行手動重新整理,文法如下:

REFRESH DYNAMIC TABLE <schema_name.table_name>;
說明

若表屬性中已開啟自動重新整理,同時執行手動重新整理時,相當於與自動重新整理並存執行,兩者均可正常執行,系統最終保證僅有一份最新資料,不會產生多份資料。

取消重新整理任務

3.1新文法建立的Dynamic Table

取消正在啟動並執行重新整理任務

對於3.1新文法建立的Dynamic Table,可先通過hologres.hg_dynamic_table_refresh_log查詢正在啟動並執行重新整理任務的query_job_id,再通過hologres.hg_internal_cancel_query_job取消該重新整理任務。

-- 擷取query_job_id
SELECT query_job_id
FROM hologres.hg_dynamic_table_refresh_log('<dt_name>')
WHERE status = 'Running';

-- 根據query_job_id取消對應的重新整理任務
SELECT hologres.hg_internal_cancel_query_job('<query_job_id>');
說明

僅Superuser可以通過hologres.hg_internal_cancel_query_job取消重新整理任務。

取消表的所有重新整理任務

如果Dynamic Table已設定重新整理任務,可執行ALTER TABLE在表層級取消後續所有重新整理任務。若需重新開啟重新整理,請參見ALTER DYNAMIC TABLE

ALTER DYNAMIC TABLE [ IF EXISTS ] [<schema>.]<table_name> SET (auto_refresh_enable=false);
重要

請謹慎操作,否則可能導致後續資料無法更新。

3.0文法建立的Dynamic Table

取消正在啟動並執行重新整理任務

如果您發現重新整理任務長時間運行未結束或出現卡頓等問題,可通過pg_cancel_backend取消正在啟動並執行重新整理任務。

您可以通過如下命令,取消單個正在啟動並執行重新整理任務。

-- pid為重新整理任務ID,可通過查看重新整理任務擷取query_id
SELECT pg_cancel_backend(<pid>);

上述參數pid為重新整理任務ID,您可通過查看重新整理任務擷取重新整理任務ID(query_id),詳情請參見查看重新整理任務

說明

批量取消正在啟動並執行重新整理任務,同普通Query的方式相同,詳情請參見終止Query

取消表的所有重新整理任務

如果Dynamic Table已經設定了重新整理任務,您可以通過ALTER DYNAMIC TABLE命令,在表層級取消後續所有的重新整理任務。

ALTER DYNAMIC TABLE [IF EXISTS ] [<schema>.]<table_name> set (auto_refresh_enable=false);
重要

請謹慎操作,否則可能導致後續資料無法更新。