Hologres Dynamic Table技术解析：如何支撑淘天电商价格力的实时数据挑战

淘天集团的价格力团队是平台价格治理的核心部门，负责管理淘宝天猫全平台商品的价格信息，每日处理的商品原价、券后价等增量数据规模达到亿级。尤其在618、双11等大促期间，价格变动频率会呈现数倍增长，这些海量数据不仅体量大，更具有高时效性、强关联性和复杂变化的特征。

在大促常态化的背景下，业务运营急需高时效性的数据看板以便及时发现问题，并且需要商品维度、店铺维度等多维数据圈选能力，以便快速圈选出符合特定要求的数据进行处理或分析。传统的离线数据处理模式难以满足分钟级乃至秒级的响应需求。在这一背景下，Hologres 的 Dynamic Table 技术成为了解决这一系列挑战的关键。

从视图到物化视图，再到Dynamic Table

在理解 Dynamic Table 之前，可以先回顾一下视图（View）和物化视图（Materialized View）的概念。视图是一种基于表的虚拟表，它本身不存储数据，只存储查询逻辑。每次访问视图时，数据库都会动态执行其背后的 SQL 语句，返回最新的查询结果，主要用于简化复杂查询。

例如，对于以下统计已完成订单销售额的查询：

SELECT region, SUM(amount) as total_sales
FROM orders
WHERE status = ‘completed’;

我们可以创建一个视图来封装这个逻辑：

-- 创建视图
CREATE VIEW sales_summary AS
SELECT region, SUM(amount) as total_sales
FROM orders
WHERE status = ‘completed’;

-- 查询视图
SELECT * FROM sales_summary;

视图帮助我们管理了 SQL 定义，简化了使用。然而，对于复杂逻辑的 SQL，每次查询都动态执行可能会非常耗时。将视图的查询结果实际保存下来，就形成了物化视图。物化视图需要定期更新以保证数据的新鲜度，其核心是 预定义 SQL + 物化结果 + 周期更新。

Hologres Dynamic Table 在概念上与物化视图类似，但在架构和能力上进行了增强。它主要包含计算和存储两部分，并提供了全量刷新与增量刷新两种核心刷新模式。

其数据处理流程可以描述如下：在计算侧，系统利用 Serverless 计算资源执行刷新任务。刷新分为两种路径：

1. 全量刷新：在刷新周期到达时，对整个基表（Base Table）的数据进行一次完整的重新计算和覆盖，其效果类似于执行 INSERT OVERWRITE。
2. 增量刷新：并非处理全量数据，而是持续处理来自基表的增量数据变更。其核心原理是在底层维护一个列存状态表，用于存储聚合等计算的中间状态。增量数据会先以微批次（Micro-batch）的方式在内存中进行聚合计算，计算结果再与状态表中保存的历史状态进行合并与更新，最终通过高效的 BulkLoad 方式写入到 Dynamic Table 中。

在存储侧，Dynamic Table 的数据最终物化存储在 Hologres 的存储层中，该层支持热存储和冷存储等多种存储模式，以优化成本和性能。

Hologres V3.1 中Dynamic Table的核心能力

在 Hologres V3.1 版本中，Dynamic Table 提供了丰富且强大的功能，同时也存在一些使用上的限制。其核心能力对比如下：

特性	增量刷新	全量刷新
刷新模式	Auto模式自动选择，支持增量则增量，否则退化为全量	支持
技术实现	微批次增量处理	INSERT OVERWRITE
触发方式	定时或手动触发	定时或手动触发
最小刷新间隔	1分钟	1分钟
增量机制	Binlog（处理CDC数据）或 Stream（文件级增量，读取性能更高）	无
支持的基表类型	内表、其他动态表、Paimon外表	内表、动态表、Paimon/ODPS/DLF等多种外表
Join支持	支持完整Join	支持完整Join
聚合函数	支持	支持
窗口函数	不支持	支持
IN子查询	不支持	支持
查询改写	不支持	不支持
分区支持	支持物理/逻辑分区	支持物理/逻辑分区
分区刷新	支持配置范围刷新	支持配置范围刷新
历史分区回刷	支持手动回刷	支持手动回刷
计算资源	Local或Serverless资源（最大4096core）	Local或Serverless资源（最大4096core）
资源隔离	实例资源或Serverless隔离	实例资源或Serverless隔离
Schema变更	支持新增列、修改计算逻辑	支持新增列、修改计算逻辑

主要限制与注意事项：

• 增量刷新的查询限制：并非所有查询都支持增量刷新。目前明确不支持的场景包括使用了窗口函数、IN子查询、EXISTS或NOT EXISTS子查询、EXCEPT或INTERSECT集合操作、ORDER BY排序、LIMIT或OFFSET分页的查询。
• Stream模式限制：若采用Stream增量模式，基表必须是列存表。
• 分区表消费：如果上游基表是分区表，目前无法同时消费其多个分区。
• 刷新模式切换：仅支持将刷新模式从“增量”改为“全量”，不支持反向操作。
• 全量刷新缺点：全量刷新通常消耗的计算和I/O资源较大。

业务实践一：灵活高效的数据圈选系统

1. 业务背景

价格力团队需要为商品价格回滚、全网比价等多个业务场景提供灵活的数据圈选能力。业务方期望能通过可视化方式，动态配置各种指标组合和复杂的筛选条件。创建的圈选结果集需要能够随着底层商品价格数据的实时变动而自动更新，并且不同业务场景对数据新鲜度的要求也不尽相同。

2. 解决方案：基于Dynamic Table构建

Dynamic Table 的特性完美契合了上述需求。工程技术团队设计了一套系统，其工作流程如下：

1. 指标系统：维护实体指标（映射到表字段）和业务指标（提供级联、聚合、计算等高级能力）。
2. 筛选规则配置：提供通用的可视化筛选组件，根据不同的业务场景展示相应的可配置指标。
3. 场景默认配置：通过配置中心（如Diamond）管理不同业务场景的默认参数，包括刷新周期、刷新模式、默认的召回条件、关联条件等。
4. 动态DDL生成与提交：系统将用户在前端配置的筛选条件，与场景默认条件相结合，通过一套DSL（领域特定语言）翻译引擎，生成最终的 Hologres Dynamic Table DDL 语句并提交执行。
5. 状态监控：实现周期性的状态检查任务，监控动态表的刷新状态，并能区分“刷新任务未完成”和“刷新后结果集为空”等不同情况。
6. 数据供给：动态表首次刷新完成后，系统提供两种数据供给方式：分页查询供前端直接调用；或启动一个 Flink 任务，实时读取动态表的变更日志（Binlog），通常将数据变更作为消息发送给下游的消息队列（如MetaQ），供其他系统消费。

整个系统的架构可以概括为：指标供给和筛选规则配置驱动动态DDL的生成与提交，创建出Holo状态表和Dynamic Table，并通过Flink或分页查询向上层应用供数，整个过程由周期性的状态检查任务和基于配置中心的场景配置来协调管理。

3. 应用效果

该方案实现了秒级从亿级数据的基表中完成Dynamic Table的创建及首次数据刷新。以下是一个创建动态表的DDL示例，其中设置了自动刷新、使用Serverless资源、数据新鲜度为30分钟等参数：

CREATE DYNAMIC TABLE public.table_name_***(
    column_1,
    column_2,
    column_3,
    column_4
) WITH (
    orientation = ‘column’,
    storage_format = ‘orc’,
    binlog_level = ‘replica’,
    binlog_ttl = ‘2592000’,
    table_group = ‘*_*_tg_default’,
    table_storage_mode = ‘hot’,
    time_to_live_in_seconds = ‘3153600000’,
    auto_refresh_enable=‘true’,
    auto_refresh_mode=‘auto’,
    base_table_cdc_format=‘binlog’,
    computing_resource=‘serverless’,
    freshness=‘30 minutes’
) AS
SELECT DISTINCT
    source_table.column_1,
    source_table.column_2,
    source_table.column_3,
    source_table.column_4
FROM public.source_table
WHERE (
        ( (‘***’ = source_table.column_3) AND (‘***’ = source_table.column_4) )
        AND (source_table.metric_column < ‘0.75’)
    )
    AND (‘********’ = source_table.column_2)
    AND (‘***’ = source_table.channel_column);

在实际管理界面中，可以查看批量创建的动态表及其配置，例如：	Schema	Dynamic Table	计算组ID	计算组名称	数据刷新模式	数据新鲜度
public	compete_consistent_pr...	1	init_warehouse	自动模式（Auto）	30 minutes
public	price_rollback_rollback...	1	init_warehouse	自动模式（Auto）	30 minutes
...	...	...	...	...	...

系统运行稳定高效，从运行历史监控可见，刷新任务执行时长通常在数秒内，数据消费延迟控制在分钟级以内，成功率为100%：	刷新开始时间	运行时长	Query 状态	数据消费延迟	计算资源规格
2026-01-07 20:58:12.357+08	2.71秒	SUCCESS	50.00秒	294
2026-01-07 20:28:15.309+08	4.88秒	SUCCESS	28.00秒	209
2026-01-07 19:58:17.219+08	3.01秒	SUCCESS	31.00秒	295

该方案已在价格力团队多个核心业务场景中部署，显著提升了数据圈选的灵活性和时效性。

业务实践二：构建近实时数据仓库与报表

1. 业务背景

数据看板的时效性直接关系到运营决策的速度。价格力团队部分场景的报表原先通过ODPS进行T+1的离线调度生成，但运营侧希望能看到分钟级更新的近实时数据，以便更快速地发现问题并调整策略。

2. 解决方案：分层建模与增量刷新

我们利用 Hologres Dynamic Table 对原有的 数据仓库 分层模型进行了近实时化改造。

1. 分层构建：构建了从数据源（Source/Paimon）通过Flink或外表接入Hologres ODS层，再依次通过Dynamic Table构建DWD（明细数据层）、DWS（汇总数据层），最终到ADS（应用数据层）和前端报表的完整流水线。DataWorks用于调度互补的周期同步任务。
2. 增量刷新策略：在各层Dynamic Table的构建中，广泛采用增量刷新模式，并设置分钟级的刷新间隔（如1分钟），实现数据的近实时流动与更新。同时，这种机制也天然实现了历史数据的分钟级快照留存。
3. 资源隔离保障：为这些实时刷新的Dynamic Table启用 Hologres 的 Serverless 计算资源，将其计算任务与实例上其他在线查询任务隔离开，减少资源竞争，保障刷新任务的稳定性和时效性。

3. 应用效果

该方案成功将关键数据看板的数据处理时延从小时级降低至分钟级。在底表数据量达亿级、输入RPS（每秒请求数）约1万的情况下，系统表现稳定。

监控显示，多个汇总层动态表（如 mv_dws_compete_metrics, mv_price_business_metrics 等）的分钟级刷新任务运行平稳，执行时间均在数秒内，数据延迟控制在30秒左右：	刷新开始时间	运行时长	Query 状态	数据消费延迟	计算资源规格
2026-01-07 20:49:16.711+08	2.65秒	SUCCESS	28.00秒	734
2026-01-07 20:48:17.268+08	1.91秒	SUCCESS	30.00秒	715

得益于分钟级的数据更新能力，运营人员可以在看板上灵活对比任意分钟粒度的数据，例如对比当前时刻（202601071748）与昨天相同时刻（202601061748）的各项指标变化率（如-25.5%， +25.2%等），从而及时发现异常趋势。在双十一等大促期间，这套近实时数据体系为运营团队提供了及时、可靠的数据决策支撑。

总结

Hologres Dynamic Table 以其独特的增量计算、Serverless资源隔离、灵活可配等特性，在淘天价格力团队应对海量、实时、复杂的数据处理挑战中发挥了关键作用。它不仅是传统物化视图的增强版，更成为连接实时计算与 OLAP 分析、支撑灵活数据服务的新型基石。通过“数据圈选”和“近实时报表”两个典型实践可以看出，Dynamic Table 能够有效简化实时数据链路的复杂度，显著提升数据时效性和业务灵活性，是构建现代企业级 数据仓库 和数据分析平台的重要组件。

参考资料

[1] Hologres Dynamic Table在淘天价格力的业务实践, 微信公众号：mp.weixin.qq.com/s/9MgiPd941NjnvrPOxAaDMw

版权声明：本文由 云栈社区 整理发布，版权归原作者所有。