Hologres：Liquid Table

什麼是Liquid Table

Liquid Table是Hologres提供的一種新型表格儲存體模式，其最核心的能力是：

這一能力解決了傳統數倉在資料量變化後無法低成本調整分區粒度的痛點：

核心能力一覽

• 線上Resharding：通過ALTER TABLE線上調整分區數，業務無感。

• 多儲存格式：支援列存（column）、行存（row）、行列共存（row,column）。

• 資料重分布可控：可選自動後台重分布，或跳過重分布換取更快的中繼資料切換。

• 分區視窗控制：僅對最近N天/月的分區做重分布，降低IO開銷。

• 跨功能相容：可與Dynamic Table、GSI、全文索引、向量索引（HGraph）、Time Travel（MVCC）、Binlog、邏輯分區表等組合使用。

典型適用情境

1. 業務初期Shard數估算保守，後期資料量增長快：初期16 shard，半年後擴容到64 shard。

2. 大促/活動前的臨時擴容：活動前擴容Shard提升查詢並發，活動後縮容回收資源。

3. 冷熱表統一管理：歷史冷分區縮容、活躍熱分區擴容。

4. AI向量檢索+彈性擴縮容：向量表隨召回量增長動態擴容，索引自動保持可用。

建立Liquid Table

只需在建表語句中增加WITH (liquid_table = 'true')即可：

-- 列存（預設，OLAP情境）
CREATE TABLE my_table (
    id   INT NOT NULL,
    name TEXT,
    ts   TIMESTAMPTZ,
    PRIMARY KEY(id)
) WITH (liquid_table = 'true');

-- 行存（點查/高頻更新情境）
CREATE TABLE my_row_table (
    id   INT NOT NULL,
    name TEXT,
    PRIMARY KEY(id)
) WITH (liquid_table = 'true', orientation = 'row');

-- 行列共存（點查+OLAP混合情境）
CREATE TABLE my_hybrid_table (
    id   INT NOT NULL,
    name TEXT,
    PRIMARY KEY(id)
) WITH (liquid_table = 'true', orientation = 'row,column');

修改Shard數（Resharding）

通過修改表所在的Table Group完成Shard數變更：

-- 準備一個目標Table Group（如還沒有）
CALL hg_create_table_group('tg_64', 64);

-- 一鍵擴容（同步生效）
ALTER TABLE my_table SET (table_group = 'tg_64');

-- 一鍵縮容
ALTER TABLE my_table SET (table_group = 'tg_16');

驗證當前Shard配置

-- 查看錶當前所屬Table Group與Shard數
SELECT property_key, property_value
FROM hologres.hg_table_properties
WHERE table_name = 'my_table'
AND property_key = 'table_group';

-- 查看Table Group元資訊
SELECT * FROM hologres.hg_table_group_properties
WHERE tablegroup_name = 'tg_64';

建表屬性

liquid_table_enable_data_reorganization取值建議

分區視窗樣本

-- 僅對最近30天分區做重分布（要求分區鍵為時間類型）
ALTER TABLE order_log SET (
    table_group = 'tg_64',
    liquid_table_reorganization_partition_window = '30 day'
);

適用情境：超長保留的日誌/事實表，歷史冷分區不再訪問，僅擴容當前熱分區即可。

相容矩陣（V4.2.0）

索引共存樣本

-- 全文索引
CREATE INDEX ft_idx ON my_table USING FULLTEXT (content)
    WITH (tokenizer = 'jieba');

-- GSI（全域二級索引）
CREATE GLOBAL INDEX gsi_name ON my_table(name) INCLUDE (ts);

-- 向量索引（通過vectors屬性）
ALTER TABLE my_table SET (vectors = '{
    "embedding": {
        "algorithm": "HGraph",
        "distance_method": "Cosine"
    }
}');

上述索引在Liquid Table上建立後，可直接執行ALTER TABLE ... SET (table_group = '...')進行Resharding，索引在新Shard上自動保持可用。

總體影響概覽

對寫入的影響

1）請求預期不會失敗，但應做好用戶端重試。Resharding期間寫入請求預期被正常接收和處理。在中繼資料切換的瞬間，少量並發請求可能出現瞬時錯誤（例如連線逾時），用戶端/Connector應配置好自動重試。不會出現表持續不可寫等長時間異常。

2）寫入延遲會出現可觀測的抖動，並非"無感"。中繼資料切換的瞬間，正在執行的寫入需要等待新拓撲生效，延遲會明顯上升。抖動量級通常在毫秒到秒級，但在以下情況下可能更長：

• 表上有未結束的長事務。

• 執行個體IO水位較高。

• 擴縮容跨度較大（例如從8 shard直接擴到128 shard）。

3）資料重分布階段寫入雖不被阻塞，但延遲可能輕微上浮。

• 後台資料搬遷會消耗執行個體IO，可能與前台寫入爭搶資源。

• 在IO水位較緊的執行個體上，寫入延遲在重分布期間會較穩態略高，吞吐也可能略有下降。

• 建議在重分布期間持續觀察執行個體IO與寫入RT監控。

4）COPY/大量匯入情境：大大量匯入強烈建議在Resharding完全結束後再啟動。在Resharding進行中匯入大量資料，會顯著延長後台重分布的實際完成時間，並放大寫入延遲波動。

對查詢的影響

1）查詢請求預期不會失敗、不會被阻塞。

• 中繼資料切換期間，新到達的查詢會基於新拓撲執行。

• 已經在執行的查詢會正常完成。

• 極端情況下，切換瞬間發起的查詢可能因路徑重路由而少量逾時，需依賴用戶端重試。

2）讀延遲在切換瞬間通常較小，但不能視為"零影響"。

• 與寫入相比，讀路徑受切換的影響通常較小。

• 切換瞬間命中的查詢會經歷路徑重路由，對延遲敏感的即時介面仍可能感知到毫秒級抖動。

• 高QPS線上點查情境，建議視為"會有短暫抖動"來規划上遊逾時配置。

3）老資料的查詢效能在資料重分布完成前可能顯著下降：

4）新寫入資料的查詢效能基本不受影響。

• 新資料按新Shard拓撲寫入，查詢效能與穩態一致。

• 但若查詢同時跨新老資料（例如時間範圍掃描），整體RT仍受老資料下降的拖累。

5）索引（GSI/全文/向量）查詢基本可用，但不能假設效能穩定。索引在Resharding後保持可用，但索引檢索的物理IO仍可能與後台資料重分布爭搶資源，RT在重分布期間可能高於穩態。大P99/長尾查詢情境應密切監控。

對延遲敏感型業務的特別提醒

如果你的業務屬於以下任意一種，請將Resharding視為一次有風險的變更，按變更管理流程處理：

影響時間長度預估（保守口徑）

一句話總結

預設行為

開啟Binlog的Liquid Table預設不允許Resharding，直接執行ALTER TABLE ... SET (table_group = ...)會報錯。

強制Resharding步驟

-- 第1步：開啟實驗性GUC（僅當前session生效）
SET hg_experimental_enable_liquid_resharding_for_table_with_binlog = on;

-- 第2步：執行Resharding
ALTER TABLE my_binlog_table SET (table_group = 'tg_64');

-- 第3步：清理舊Shard上的delta資料
CALL hg_liquid_resharding_drop_non_current_delta('my_binlog_table');

對Binlog消費任務的影響

方式一：通過REBUILD轉換（推薦）

從Hologres V4.2版本起，支援通過ASYNC REBUILD TABLE將普通表原地非同步重建為Liquid Table，無需建立表和手動遷移資料，表名保持不變。REBUILD的詳細用法請參見REBUILD。

-- 將普通表原地轉換為Liquid Table（表名保持不變）
ASYNC REBUILD TABLE my_table
SET (
    liquid_table = 'true'
);

方式二：建立表遷移

建立一張Liquid Table，將老表資料移轉後，通過事務原子性重新命名完成切換。

-- 1. 建立一個Liquid Table（保持與老表結構一致）
CREATE TABLE my_table_new (
    id   INT NOT NULL,
    name TEXT,
    ts   TIMESTAMPTZ,
    PRIMARY KEY(id)
) WITH (liquid_table = 'true');

-- 2. 資料移轉
INSERT INTO my_table_new SELECT * FROM my_table_old;

-- 3. 重建索引（如有）
CREATE INDEX ... ON my_table_new ...;

-- 4. 切換：使用事務原子性重新命名
BEGIN;
ALTER TABLE my_table_old RENAME TO my_table_bak;
ALTER TABLE my_table_new RENAME TO my_table;
COMMIT;

-- 5. 驗證後刪除備份
DROP TABLE my_table_bak;

何時啟用Liquid Table

強烈建議啟用：

• 資料量預期在生命週期內會發生顯著變化（增長5倍以上）。

• 業務有大促/秒殺/季節性流量波動，需彈性Shard。

• 即時數倉的核心明細表/寬表。

• AI向量檢索表。

可暫緩啟用：

• 資料量穩定的小維表。

• 強依賴物理分區表的情境。

• 強依賴MaxCompute直讀的情境。

Shard數規劃經驗

Resharding執行建議

1. 避開高峰期：選擇業務低峰視窗執行ALTER。

2. 避開大DML：先確認無大批量INSERT/UPDATE/DELETE在跑。

3. 整數倍擴縮容優先：例如16→32→64，比16→50效能更平滑。

4. 大表用分區視窗：對超長生命週期分區表使用liquid_table_reorganization_partition_window限制重分布範圍。

5. Binlog表全鏈路演練：先在測試環境完整演練Resharding+下遊重啟。

監控建議

• 重分布完成前：定期對比新老Shard上的查詢RT，確認重分布進度。

• 執行個體資源水位：Resharding期間會有額外的IO開銷，建議關注CPU/IO使用率。

• Binlog Cursor：對開啟Binlog的表，關注下遊消費lag。