Hologres推出了声明式数据处理架构Dynamic Table，该架构可以自动处理并存储一个或者多个基表（Base Table）对象的数据聚合结果，内置不同的数据刷新策略，业务可以根据需求设置不同的数据刷新策略，实现数据从基表对象到Dynamic Table的自动流转，满足业务统一开发、数据自动流转、处理时效性等诉求。
业务背景
在实时数仓场景中，通常会涉及到复杂的业务处理，例如多表关联查询，大表聚合查询等，其数据一般都是大数据量（TB级甚至PB级），同时业务又有不同时效性的诉求，在数据加工上通常会有以下几个痛点：
Lambda架构过于冗余：为了满足业务资源成本、开发效率、业务时效性等需求，业界早期通常使用Lambda架构，但是该架构上产品组合众多，面向不同的业务场景，导致架构冗余、存储冗余，开发和运维不便捷、数据口径不一致等一系列问题。
离线ETL重复性调度，时效性差：使用离线计算引擎（例如Hive）ETL是常见的数据加工手段，这种方案通常适用于高吞吐的大数据量加工，计算数据量大，缺乏实时计算的能力，如果要提高加工效率，通常是将数据通过周期性调度的方式，重复计算，势必会造成大量的资源浪费，同时时效性也不能完全满足业务需求。
实时计算成本过高：为了提升数据处理的时效性，使用实时计算引擎实时加工成为新的技术演进趋势，但数仓场景中，并不是所有的业务都需要实时计算，更多的是准实时分钟级加工场景（例如BI报表查询），这种方案会导致资源成本过高。
基于上述数据加工的痛点，Hologres重磅推出DynamicTable，支持全量计算、增量计算2种计算模式，既能支持离线大数据量的全量加工，又能使用增量计算提升数据计算时效性，且成本相比实时计算更低。Dynamic Table可以做到数据自动计算，结果更新，实现更高效、更低成本的数据自动流动与数仓分层，再结合Hologres本身特性，能够统一存储层，统一计算层、统一数据加工层、统一数据服务层，满足开发效率、时效性等需求。
Dynamic Table的优势
简化数仓架构
Dynamic Table支持全量计算和增量计算2种刷新模式，可实现离线数据加工（全量计算）和准实时数据加工（增量计算），满足业务不同时效性的查询诉求，再基于Hologres的统一存储（存储实时数据、离线数据），直接赋能业务OLAP查询、在线服务、AI与大模型等多个应用场景的查询诉求，一套引擎，一份计算，一份SQL多种计算模式，可以完美替换Lambda架构，简化数仓架构，节约开发、运维等成本。
自动数仓分层
Dynamic Tanle可以根据基表数据的新鲜度，自动触发刷新（refresh），实现数据从ODS>DWD>DWS>ADS的自动数据流转，提升数仓分层开发体验。
提升数据处理（ETL）效率
Dynamic Table的增量刷新计算，每一次刷新都只会处理基表的新增数据，可以有效减少每次ETL计算的数据量，显著提升数据处理效率，同时资源也无需像流计算一样常驻，根据数据新鲜度自动触发刷新，可以有效的降低成本。
降低开发运维成本
Dynamic Table的刷新模式都使用统一的SQL接口，自动管理刷新任务、自动管理数据之间的层级和依赖关系，简化繁琐的开发运维，提升开发效率。
基本概念
基表（Base Table）
Dynamic Table中数据来源的基表，可以是一张表（内部表或外部表），也可以是多个表关联。不同的刷新模式，支持的基表类型不同。详情请参见Dynamic Table支持范围和限制。
Query
创建Dynamic Table时指定的Query，是指对基表数据的处理Query，相当于ETL过程。不同的刷新模式支持的Query类型不同，详情请参见Dynamic Table支持范围和限制。
刷新（Refresh）
当基表中的数据发生变化时，需要通过刷新（Refresh）Dynamic Table以更新数据的变动。Dynamic Table会根据设置的刷新开始时间和刷新间隔，自动在后台运行刷新任务，对刷新任务的观测和运维详情请参见运维Dynamic Table刷新任务。
技术原理
基表中的数据根据Dynamic Table中Query定义的数据处理流程，通过刷新的方式写入Dynamic Table。以下将从刷新模式、计算资源、数据存储及表索引四个方面介绍Dynamic Table的部分技术原理。
刷新模式
当前Dynamic Table支持两种刷新模式，即全量刷新（Full）和增量刷新（Incremental），根据设置的刷新模式不同，Dynamic Table的技术原理也有所差异。
全量刷新（Full）
全量刷新是指每次执行刷新时，都以全量的方式进行数据处理，并将基表的聚合结果物化写入Dynamic Table，其技术原理类似于INSERT OVERWRITE的相关原理。
增量刷新（Incremental）
增量刷新模式下，每次刷新时只会读取基表中新增的数据，根据中间聚合状态和增量数据计算最终结果并更新到Dynamic Table中。相比全量刷新，增量刷新每次处理的数据量更少，效率更高，从而可以非常有效地提升刷新任务的时效性，同时降低计算资源的使用。
技术原理
创建了增量刷新的Dynamic Table，并通过Stream或Binlog的方式读取基表的增量数据后，系统会在底层创建一个列存的状态表（State表），用于存储Query的中间聚合状态，引擎在编码、存储等方面对中间聚合状态进行了优化，可以加快对中间聚合状态的读取和更新。增量数据会以微批次方式做内存态的聚合，再与状态表中的数据进行合并，然后以BulkLoad的方式将最新聚合结果高效地写入Dynamic Table。微批次的增量处理方式减少了单次刷新的数据处理量，显著提升了计算的时效性。
Stream和Binlog方式读取基表增量数据的对比
读取基表增量数据的方式
原理
读取性能
特点
注意事项
Stream（推荐）
从文件级别识别数据的变化记录，计算基表的增量数据。
比Binlog方式高10倍以上。
使用更简单。
不单独记录增量变化，因此无额外的存储开销，也无需管理Binlog的存储生命周期。
不支持以行存表作为基表。
Binlog
Binlog会记录基表的DML变化，并在底层存储成二进制日志，增量消费基表时通过读取Binlog日志识别增量数据的变化。
较低。
因记录DML的变化，产生额外的存储开销。
需要管理Binlog的存储生命周期（TTL），否则随着数据的变更或增长，存储会持续增加。
无。
注意事项
增量刷新模式支持的基表存在一定的限制，详情请参见Dynamic Table支持范围和限制。
增量刷新内置的状态表会占用一定的存储，系统会设置TTL定期清理数据，您可以使用函数查看状态表的存储大小，详情请参见状态表（State）管理。
计算资源
执行刷新任务的计算资源可以是本实例的资源或者Serverless资源：
Serverless资源（默认）：从V3.1版本开始，新建表默认使用Serverless方式执行刷新，如果Query比较复杂，处理的数据量较多，通过Serverless方式可以有效提升刷新任务的稳定性，避免本实例内多任务间的资源争抢，同时也可以对单个刷新任务修改计算资源，以便更合理地使用Serverless资源。
本实例资源：刷新任务将会使用本实例的资源运行，与实例中的其他任务共享资源，高峰期可能会出现资源争抢现象。
数据存储
Dynamic Table在数据存储方面与普通表一致，默认使用热存储模式。为了减少存储成本，也可以将查询频率较低的数据设置为冷存储，有效降低成本。
表索引
业务在查询时，可以直接查询Dynamic Table，相当于直接查询聚合结果，这样可以显著提升查询性能。同时，Dynamic Table也如同普通表，支持设置表索引，如行存/列存、Distribution Key、Clustering Key等，通常情况下，引擎会根据Dynamic Table的Query推导出合适的索引，如业务有进一步的调优需求，可以重新为其设置合适的索引，以进一步提升查询性能。
与物化视图对比
Dynamic Table VS Hologres实时物化视图
Hologres在V1.3版本推出了SQL管理物化视图，但是支持的能力相对较弱，与Dynamic Table的差异如下：
功能分类 | Hologres Dynamic Table | Hologres实时物化视图 |
基表类型 |
| 单内表 |
基表操作 |
| 仅支持append写入 |
刷新原理 | 异步刷新（全量刷新、增量刷新） | 同步刷新 |
刷新时效性 |
| 实时 |
Query类型 |
说明 不同的刷新模式，支持的Query类型不同，详情请参见Dynamic Table支持范围和限制。 | 有限算子支持（AGG、RB函数等） |
查询模式 | 直接查Dynamic Table |
|
Dynamic Table VS 异步物化视图
当前市面上，与Dynamic Table功能类似的有OLAP产品的异步物化视图、Snowflake的Dynamic Table等，其差别如下：
功能分类 | Hologres Dynamic Table | OLAP产品异步物化视图 | Snowflake Dynamic Table |
基表类型 |
说明 不同的刷新模式，支持的Query类型不同，详情请参见Dynamic Table支持范围和限制。 |
|
|
刷新模式 |
|
|
|
刷新时效性 |
| 小时级 |
|
Query类型 |
说明 不同的刷新模式，支持的Query类型不同，详情请参见Dynamic Table支持范围和限制。 |
|
|
查询模式 | 直接查Dynamic Table |
| 直接查Dynamic Table |
观测/运维 |
| 丰富的监控指标 | 可视化界面 |
典型应用场景
Dynamic Table可以自动完成数据加工和存储，通过Dynamic Table，可以加速数据查询，提升业务时效性，推荐的使用场景如下：
Lambda架构升级
为了满足业务数据的不同时效性处理需求，Lambda架构会使用不同的产品组件来完成。这就会导致架构容与、数据口径不一致、系统维护难，存储冗余等一系列问题。通过Hologres Dynamic Table，可以很好地支撑批量数据加工，近实时加工等场景，结合Holo的统一存储，统一数据服务（支持OLAP查询、KV在线点查）等能力，可以在一个产品支持多种应用场景，简化架构，降低开发难度，学习成本，存储成本等。
近实时数据加工
如果基表中有大量数据，需要进行复杂的ETL处理来满足业务的时效性需求，常见的做法就是数仓分层。对于实时数仓，业界在数仓分层上的方案较多，例如使用物化视图、周期性调度等，但这些方案虽然能解决一部分问题，但是也都存在数据时效性、开发不便捷等问题。而Hologres Dynamic Table本身就具备数据自动处理的能力，因此可以通过Dynamic Table很方便的实现数仓分层。
推荐做法如下：
可以在Hologres中通过Dynamic Table构建数仓分层DWD>DWS>ADS层：
每一层之间的数据同步使用增量刷新模式，这样可以保证每一层处理的数据少，减少不必要的重复计算，提升同步速度。也可以根据业务情况，将刷新任务提交到Serverless Computing执行，进一步提升刷新的时效性和稳定性。
如果要对每一层的数据进行回刷，可以使用全量刷新执行一次刷新，以此来保证每一层数据口径的一致性。同样也可以根据业务情况，将刷新任务提交到Serverless Computing执行，进一步提升刷新的时效性和稳定性。
每一层都在Hologres中构建，数仓分层明确，每一层都可以根据业务情况提供查询，保证数据的可见性、复用性。
通过Hologres Dynamic Table方案就能完成数据加工+应用的场景，显著提升数仓开发、运维效率。
湖仓加速
Dynamic Table的基表数据可以来源于Hologres表，也可以来源于数据仓库，例如MaxCompute、数据湖OSS、Paimon等，通过对基表数据的全量/增量刷新，满足不同时效性的数据查询探索需求。推荐的使用场景包括：
定期报表查询
对于周期性观测的相关场景，例如周期性报表等，如果数据量较少或者Query不复杂，可以使用全量刷新或者增量刷新的模式，周期性地将湖仓数据的聚合分析结果刷新至Dynamic Table，应用侧直接查询Dynamic Table获取分析结果，加速报表查询。
实时大屏/报表
对于实时大屏和实时报表等场景，数据的时效性要求更高，推荐使用增量刷新的模式，将湖Paimon或者实时数据的聚合分析结果刷新至Dynamic Table，以此来加速对实时数据的处理，应用侧直接查询Dynamic Table获取数据分析结果，达到近实时分析的目的。
替换离线周期性重复调度
典型的离线加工场景中，数据量大，计算周期长，为了提升计算时效性，通常的做法是周期性调度方案：
从DWD-DWS-ADS，T+H周期性（例如30min调度一次）处理最近几天的数据，为了保证数据的准确性，同样也会单独起一个离线链路，T+1每天处理最近几天的数据，相当于是对数据回刷，导致有一大部分数据是重复计算的，资源浪费，数据也有冗余，同时，系统也不能保证每次调度都能完成计算，导致后续的调度任务阻塞，业务延迟计算时效性得不到保障。
通过Hologres，从DWD-DWS-ADS每一层都采用T+H的增量刷新，原作业合并到一个增量计算的作业，不用关心具体的数据查询范围，只负责刷新，SQL更简化，DynamicTable自动调度，无需维护外部调度作业。每次只计算增量的数据，避免重复计算，计算提速，无任务的堆积，计算资源也大幅降低。
