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。