Dynamic Table快速入门
内容介绍
1. Hologres Dynamic Table介绍
2. Dynamic Table的使用方法和实操
3. Dynamic Table的使用建议
01. Hologres Dynamic Table介绍
首先进入第一个部分。先来探讨一下实时数仓的典型应用场景，总结起来大致有以下四类。比如BI报表分析类，这包括常见的实时大屏、BI报表数据中台等；第二类是人群运营类应用；第三类是日志分析与检索类应用，如行为分析、流量分析等；第四类则是实时监控类应用，例如实时风控、直播监控等。这些实时数仓的场景广泛应用于广告、游戏、电商、互联网等多个行业。其实并非所有实时数仓的场景都要求达到秒级或毫秒级的低延迟。更多的实时场景，如报表分析、人群运营类应用，其实更多地属于准实时场景，即分钟级延迟。
为了支撑实时数仓，包括离线、实时以及准实时等场景，这些场景背后的数仓技术是如何实现的。常见的数仓架构如下图所示，首先在存储层会包含多个存储组件，比如离线存储和实时存储。为了满足实时数仓中不同的查询需求，以及离线场景的计算需求，通常会采用不同的计算引擎。对于离线场景可能会使用像MaxCompute或Spark这样的离线计算引擎来处理数据。通过这些引擎以批处理的方式计算离线数据，并将结果写入到服务层，比如实时数仓Progress Store中，最终对接到应用端。
为了满足实时或准实时场景的需求，通常依赖于实时计算引擎，比如Flink，来提供支持。Flink这类实时计算引擎能够对数据进行实时处理，并将处理结果写入实时数仓或数据湖中，最终为在线服务提供支持。这套架构其实是一个典型的Lambda架构。然而该架构也存在许多痛点。例如，架构中涉及的组件众多，既有离线计算引擎，也有实时计算引擎，这无疑增加了开发和运维的复杂性和不便性。
第二个问题是，由于需要支持不同的场景，如离线场景、实时场景和准实时场景，而这套架构采用了不同的组件。在存储层，离线场景和实时场景各自拥有独立的存储系统，这导致了数据的冗余。在计算层，既有离线计算引擎，也有实时计算引擎，这意味着需要维护两套代码，这可能导致实时和离线的数据口径不一致，进而引发数据不一致的问题。此外如前所述，实时数仓的场景不仅包含实时计算，还包含准实时计算。然而这套架构在支持准实时计算场景时存在不足。如果采用离线计算引擎来支持准实时场景，那么延迟会非常高，无法满足分钟级延迟的需求。而如果采用实时计算引擎来支持准实时场景，虽然可以满足延迟要求，但实时计算的成本却很高，这使得在实际应用中难以权衡。
是否有一款产品能够同时支持多种计算模式，统一数据存储，并且更好地满足准实时计算场景的需求。经过技术调研发现增量计算技术非常适合用于支持准实时计算场景。因此，在Hologres的3.0版本中，重点引入了Dynamic Table这一新型表类型，也称作动态表。它能够自动地将查询处理结果物化。同时Dynamic Table提供了两种计算模式：增量计算模式和全量计算模式。这两种模式能够满足不同场景下的计算需求。
顾名思义，增量计算即每次刷新时仅处理新增的数据，也被称为增量刷新。与传统的全量数据计算相比，通过增量计算可以显著减少数据的处理量，从而提升Query的处理速度，并降低计算成本。这种计算方式非常适用于满足准实时计算场景的需求。
而全量刷新是指每次处理查询时，都会通过全量的方式来更新数据。这种方式通常建议用于周期性调度、数据回溯等场景。虽然全量刷新的成本在某些情况下可能会比增量刷新更低，但Hologres本身支持实时和离线存储。通过结合Hologres和Dynamic Table，可以实现一份数据同时支持多种计算模式，从而在性能和成本之间达到完美平衡，满足业务对于不同刷新延迟的多样化需求。
02. Dynamic Table的使用方法和实操
1.1 Dynamic Table的使用方法
刚刚介绍了Dynamic Table，它是一种特殊的表类型。在创建Dynamic Table时，过程与创建普通表相似，但需要注意的是有三个关键参数需要设置。首先，创建Dynamic Table时，需要指定刷新模式，根据业务的具体需求选择增量刷新或全量刷新模式。其次，需要设置好刷新间隔，通过设定的刷新间隔，Dynamic Table会周期性地更新数据。最后，需要指定处理的Query，而Dynamic Table会通过Query自动执行该查询并存储查询结果。在查询时，只需查询这张Dynamic Table，即可获得经过聚合处理的查询结果。
Dynamic Table在使用上带来了诸多优势，总结起来主要有以下几点。首先是声明式的数据处理，它实现了自动化的数据处理。以往，对于一段数据的ETL加工逻辑，需要额外编写任务调度脚本来处理相应的Query 。而现在，只需为Dynamic Table设置刷新模式和刷新间隔，它就会自动刷新数据，并自动管理刷新任务，无需再启动其他调度脚本。这使得开发方式从命令式转变为声明式，无需再额外关注每次任务的运维情况，只需关注最终数据结果的一致性，从而大大提高了运维的便捷性。
第二个优势是，Dynamic Table能够提供极低延迟的数据更新。正如之前提到的，可以通过设置数据刷新间隔来提升数据的新鲜度。增量刷新模式在理论上可以做到最低每分钟刷新一次，这能够很好地满足准实时场景中分钟级延迟的需求。
第三个优势是，Dynamic Table的开发完全基于标准的SQL，因此非常容易上手。只要熟悉标准的SQL语法，就可以像使用其他SQL工具一样使用Dynamic Table，无需额外的学习成本。此外，Dynamic Table在业务定义的查询中支持多种常见的SQL表达式，如JOIN、GROUP BY、窗口函数等，功能强大且灵活。因此可以像使用普通的SQL查询一样轻松地使用Dynamic Table，其上手成本非常低。
最后一个优势是Dynamic Table能够实现多模式的统一计算。这是如何做到的呢？正如之前提到的，Dynamic Table支持多种刷新模式，包括增量刷新和全量刷新。这两种刷新模式在使用上并无差异，只需通过修改Refresh Mode参数，即可轻松地将增量刷新切换为全量刷新。
在过去传统的开发模式中，实时计算和离线计算往往需要分别编写两套代码。然而通过Dynamic Table，无需修改任何刷新逻辑，只需调整一次Refresh Mode参数，即可轻松地将增量刷新转换为全量刷新，实现刷新模式的无缝切换，从而达成多模式的统一计算。这种方式能够很好地满足业务场景中多样化的刷新需求。
同时Dynamic Table可以与Service结合使用。无论是增量刷新还是全量刷新，都可以提交到Serverless集群上执行。好处为一方面可以隔离刷新任务。例如，如果有较大的刷新任务可能会对本实例中的其他生产任务或查询造成影响，通过将刷新任务提交到Serverless集群上执行，可以有效隔离这些任务，避免相互影响。另一方面，这样做还带来了资源弹性使用的好处。比如，在业务高峰期，可以根据需要对单个Dynamic Table的刷新任务或单个刷新任务增加或减少计算资源，而无需对整个实例进行扩容，从而实现了资源的灵活调配和成本的进一步降低。
综上所述，Dynamic Table能够支持众多典型的应用场景。首先，通过Dynamic Table可以实现数仓的自动分层。以往数仓分层更多地依赖于外部组件，如编写调度脚本或Flink任务等。而现在，利用Dynamic Table可以自动地实现数仓的分层，无需额外的外部组件或任务。
而从DWD层到ADS层，强烈推荐每一层之间采用增量刷新模式来执行。这样做既可以减少每一层的数据刷新计算量，同时也可以提高数据计算的时效性。例如，如果某一层的数据有新增或对历史数据有修改，可以很方便地通过Dynamic Table将增量刷新模式切换为全量刷新模式。并且当与Serverless服务结合使用时，可以进一步提升每一层数据之间历史数据回刷的稳定性和便捷性。
通过Dynamic Table可以非常方便地实现一份代码支持多种计算模式。这样极大地简化了数据加工流程，无需引入其他外部调度组件，就能自动管理各层之间的刷新任务。同时，这也提升了数据刷新的灵活性，满足了准实时数仓开发的需求。
第二个典型场景是数据湖与数据仓的融合。Dynamic Table的基表，即查询中的基础表，可以来源于OSS 、Parquet 、以及MaxCompute等数据源。一个常见的应用是，Dynamic Table通过增量方式读取Parquet文件中的增量日志。由于Parquet支持高效的列式存储和读取，可以利用Dynamic Table的增量刷新功能，高效地消费Parquet中的日志数据，实现数据的增量处理。另一个例子是，对于MaxCompute中的数据，可以通过全量刷新的方式将其写入Dynamic Table。这种方式结合了增量与全量的数据处理方式，极大地简化了数据导入和ETL过程，并自动加速了数据湖与数据仓之间的数据流动，实现了两者之间的数据融合与加速。
1.2 演示如何使用Dynamic Table
本次演示将分为三个场景进行介绍。首先，进入第一个场景，即端到端地创建一张全量刷新的Dynamic Table。在此之前已经准备好了相关的基表，这些基表的数据来源于Danny Table，具体来自于TBCH100G数据集。现在，有一个TBCH的Q9查询示例，它涉及到了六张表的连接操作。接下来，将这个查询转换为一个全量刷新的Dynamic Table。
而Hall web现已支持通过可视化方式创建Dynamic Table，因此，这次将尝试利用这一可视化功能来创建Dynamic Table。首先，在Hello Web的原数据管理区域找到Dynamic Table功能，接着创建一个单位Table。在此过程中，需要选择好表的Schema，并输入为Table设定的表名。完成这些步骤后，将需要处理的Query输入到数据生成SQL的编辑器中。
需要对这段Query进行预编译处理。预编译的主要目的是验证这段Query的语法是否正确，同时观察该Circle支持创建哪种模式的Dynamic Table。通过预编译结果，可以看到该Circle支持创建全量的Dynamic Table。此外，预编译过程还能由引擎自动推导出这张Dynamic Table的相关字段。接下来，可以查看这些字段的详细信息。与普通表类似，并且可以为Dynamic Table设置存储模式以及表数据的Ttl等属性。同时，对于推导出来的字段，还可以设置一些相关的索引，如分布列、分段列等，以提升查询性能。
最为关键的是，需要为这张表设定一个数据刷新策略。鉴于已经确认该Circle支持全量刷新模式，因此，将数据刷新模式设定为全量刷新。为了确保数据能够自动更新，需要启用数据的自动刷新功能。在选择开始时间时，可以选择立即启动，或者指定一个具体的开始时间点。同时，还需要设置好刷新频率。由于本次采用的是全量刷新模式，因此设定的刷新频率为每1个小时一次。也可根据业务的实际需求，也可以灵活调整数据刷新频率，无论是以分钟还是小时为单位都是可行的。
接下来的一步是选择计算刷新资源。这些资源既可以是本实例内的资源，也可以是Serverless资源。本次演示，将选择使用Serverless资源。如果选择使用Serverless资源，还需要指定计算资源的相关信息，具体选择可以根据业务的实际需求来确定。
接下来是设置高级参数的部分，比如你可以在数据刷新时配置一些GOC，以及设置超时时间等，这些设置将对整个表生效。然后，可以回顾一下这个表的相关字段，如果需要对字段名进行别名处理，也是可以在这里进行的。但需要注意的是，像字段类型等其他的资源属性，目前是不支持手动编辑的，它们都是通过引擎自动推导得出的。此外还可以选择是否将这张表设置为分区表。完成所有设置后，就可以点击提交按钮了。
现在已经成功创建了这张表，并且可以查看该表生成的Ddl语句。它与普通表相似，这张表拥有对应的Schema以及一些相关属性，包括其Query的具体内容都可以在这里查看到。由于在创建表时选择了立即刷新，因此可以检查一下这张表的刷新任务，查看其Refresh的执行状态。随后，可以跳转到动态表管理界面，来确认这张表是否已经执行过刷新操作。
由于之前设置了立即刷新，因此在这里可以看到一个运行历史记录，显示刷新任务已经成功完成。可以清晰地看到运行时长以及所使用的计算资源规格。如果想要更深入地了解这一刷新记录的具体信息，可以点击“运行诊断”按钮。点击运行诊断后，会进入到一个详尽的监控界面，在这里可以查看刷新任务的详细运行信息，包括Query的内容、资源的消耗情况，以及对应的SQL语句和SQL执行计划等。如果刷新任务失败了，同样可以在这个界面下方查看到失败的详细信息。
回到动态表管理页面，针对这张Dynamic Table ，如果还想查看它的上下游数据源信息，可以前往血缘信息管理页面。在这里，可以清晰地看到这张Dynamic Table的上游数据源分别来自哪些表，以及这些表的类型。当然，通过单击这些表名，还可以进一步查看这些表的详细信息。例如，如果你单击了名为“Lime Table”的表，你可以看到它的刷新模式以及刷新间隔等关键信息。而血缘信息管理页面为提供了一个非常便捷的途径，来探索这张Dynamic Table对应的血缘关系。
如果希望对这张Dynamic Table进行更精细化的管理，比如编辑表的信息，可以返回到原数据管理页面进行操作。另外，如果想对与Dynamic Table相关的任务进行监控和告警设置，可以前往监控页面。在监控页面中，可以看到相关的Refresh记录，包括QPS、RPS以及Latency等性能指标。根据业务需求，还可以设置相应的告警阈值。此外，如果后续不希望该表的刷新任务继续运行，可以点击“暂停刷新”按钮。点击后，该表相关的所有后续刷新任务都将被暂停。以上就是一个全流程的全量刷新Dynamic Table的创建过程。
接下来将演示如何基于Parquet外表进行增量刷新来更新表格。在此之前，我已经预先创建了一张Parquet外表，并且这张表中已经包含了一些数据。可以查看一下这张表的数据以及它的存储位置。从存储位置可以看到，这张表的数据是来源于Parquet服务器的，因此可以确认这是一张Parquet外表。而关于如何将Parquet外表导入到Hologres中，这里我不再详细赘述。在后续的公开课中，将会有相关的讲解，大家也可以持续关注课程以了解更多关于cable增量模式的内容。
由于Parquet支持日志记录，可以基于Parquet的日志，以增量的方式读取Parquet的数据。接下来，将创建一张增量的Dynamic Table ，用于消费Parquet的数据。可以看到，我这一步骤要处理的核心任务，是对这张Parquet外表执行一些聚合查询操作。例如，可能会进行上卷聚合等操作，以提取所需的数据汇总。
现在，将创建一个增量刷新的表，为了简便起见，我将采用Circle来创建。当然，大家也可以选择使用Hologres提供的可视化界面进行创建。接下来运行一下创建命令。运行成功！而关于消费Parquet数据的原理，它首先会全量消费Parquet中的数据，随后再基于Parquet的日志进行增量消费，以确保数据的实时性和准确性。
现在可以来查看一下这张增量的Dynamic Table中的数据。可以看到，这张表中已经包含了数据，可以核对一下这些数据是否与Parquet基表中的数据一致。经过核对，发现Dynamic Table中的数据与Parquet基表中的数据是完全相同的。其原理是，在初次创建时，Dynamic Table会先全量消费Parquet中的数据。之后它会基于Parquet的日志进行增量消费，以确保数据的实时更新。如何模拟这种增量消费的过程呢？可以在Hologres中向Parquet的外表插入一条新的数据，以此来模拟增量数据的产生。当然，在实际应用中，增量数据也可以通过Flink等实时计算框架写入到Parquet中，然后Dynamic Table会自动地检测到这些新增的数据并进行增量消费。
现在我已经将数据成功插入到了Parquet外表中。由于我设置的是一分钟调度一次，所以在调度任务执行之前，数据可能还没有发生变化。但我可以先回到当前的Dynamic Table管理界面，查看刚刚创建的这张增量表。经过一分钟的等待，刷新记录已经显示成功。此时，我再次查看这张增量表，发现数据已经相比于之前发生了变化，这就是增量数据消费的一个流程。通过这种方式，既可以减少数据的计算量，又可以降低计算资源的使用，非常便捷地实现了数据端到端的计算。
第三个场景是增量和全量混合使用的场景。通常原表的数据量可能非常大，动辄几亿、几十亿条记录，因此经常需要进行分区操作。在业务上，往往需要对当天的分区数据进行实时查询，而对于历史分区的数据，则可能需要进行离线查询或离线修正。而为了满足这样的需求，可以通过Dynamic Table来实现。
首先，我会准备一张订单事实表，这是一张分区表。接着会创建一张分区子表，并为这张子表开启Binlog。因为当使用增量的方式来消费数据时，原表必须开启Binlog。所以，我已经提前为这张子表开启了Binlog。同时，我也会为原表创建一张对应的子表，用于存储最新的数据。
另外，在实际应用场景中，经常会遇到事实表与维表进行Join或多流连接的情况。为此准备了一张维表，用于存储用户的属性信息，并已向其中插入了数据。首先在创建Dynamic Table之前，如果将事实表与维表进行连接，是能够得到数据的。接下来将创建一张分区的Dynamic Table。具体而言，会先创建一张分区的子表，并指定其分区字段与事实表的分区字段相同，即按照“Ds”字段进行分区。然后会定义好这张Dynamic Table要处理的查询语句，也就是事实表与维表的连接操作。需要注意的是，在进行维表连接时，必须使用标准的维表连接语法。目前增量刷新模式仅支持维表连接作业。对于多流连接作业，目前正在开发中，预计不久的将来就会发布。
接下来继续进行Dynamic Table的创建。在创建附表时，首先明确了附表的分区字段以及需要处理的查询语句。成功创建附表后，紧接着创建了一张最新的分区子表，并指定其刷新模式为增量模式。这意味着该分区子表将会以增量的方式进行数据刷新，且刷新间隔为一分钟。在实际业务场景中，会将实时数据写入到事实表的子表中。这可以通过多种方式实现，例如使用Flink或MySQL等工具，将数据实时地写入到这张事实表的子表中。
现在来模拟一下向这张表插入数据的过程。插入数据后，如果直接查询原始的SQL表，可以发现数据已经成功写入。但是，当查询Dynamic Table时，却发现还没有数据，这是因为设置的刷新时间间隔为一分钟，而目前还没有到达下一个刷新时间点。接下来可以回到动态表管理的页面，确认刚刚创建的Dynamic Table已经成功创建。然后查看任务管理，可以发现已经执行过一次刷新任务了。
执行完刷新任务后，再次回到这个页面来查询这张表，现在数据已经通过增量的方式被成功刷新进来了。可以再返回这个页面看一下，现在的任务管理通过增量的方式已经刷新到这张表中了。另外指出在业务场景中，这张表不可能一直进行实时写入。例如，到了第二天，新的分区表会开始实时写入数据，而昨天的分区表则不再需要实时写入。这时，可以通过ALTER DATA命令将这张表从增量刷新模式转换为全量刷新模式。转换后，这张表将不再以增量的方式刷新数据，而新的分区表则会继续以增量的方式进行数据刷新。
将增量刷新模式切换成全量刷新模式其实非常简单，只需要执行一次ALTER TABLE命令，并将Refreshmode设置为Full即可。完成这个操作后，现在可以回到原数据管理界面中，可以看到一张动态表，并找到对应的分区值表。通过观察，可以发现这张分区值表的刷新策略已经更改为全量刷新。而在业务场景中，有时历史数据也会发生变更。例如，当前这张Dynamic Table处理的是事实表与维表的连接逻辑。如果维表中的数据发生变更，需要对此进行模拟。现在，我将对维表执行一次更新操作。更新完成后，通过查询原始的事实表与维表的连接结果，可以发现数据已经发生了相应的变化。
但是，当查询Dynamic Table时，发现其数据尚未更新。这时，需要对历史数据进行一次全量回刷操作。由于这张表已经作为历史指标表处理，并且其刷新模式已更改为全量刷新，因此可以使用Refresh Dynamic Table命令来执行这次全量回刷。然后现在来执行一下，等回收完成后，再次查询这张纸表，你会发现数据已经成功刷新。同时，可以进入任务管理界面，刷新一下页面，这里有一点延迟，稍后再回来查看这张纸表的刷新记录。
然后可以清晰地看到整个流程：通过采用动态分区表的方式，可以让最新的分区采用增量刷新的模式，而历史的分区则使用全量回刷、全量更新的方式。既能够实现最新分区实时或近实时的数据刷新，又能够满足历史数据回刷的需求，构建了一个混合的应用场景。而且，在整个流程中无需进行任何代码修改，只需调整表的属性，就能实现整个业务逻辑。与之前的架构相比，实时处理需要一套代码，离线处理又需要另一套代码，现在的方案无疑更加便捷。回顾一下，可能是因为刷新任务执行的时间较短，没有超过100毫秒，所以暂时查询不到更新后的数据。不过这点影响不大，但可以确认的是，这张表已经成功完成了刷新。
03. Dynamic table的使用建议
Demo完成后，接下来来看一下关于Dynamic Table的使用建议。
第一个是要明确何时选择增量刷新，何时选择全量刷新。我的建议是，在可能的情况下，都尽量使用增量刷新。因为增量刷新每次处理的Query数据量较少，所以处理速度会更快，同时消耗的计算资源也会更低。然而目前增量刷新有一些使用上的限制，需要参考文档来了解这些限制。此外使用增量刷新还需要为Base表开启Blog，这会产生一定的存储开销。另外需要注意目前增量刷新主要支持维表，而双流的支持正在开发中，大家可以等待一段时间，未来就可以使用上双流的功能了。
第二个是关于如何观测增量刷新的延迟问题。由于增量刷新是通过周期性间隔来执行的，如果上游数据写入频繁，且每次刷新时效性要求较高、延迟间隔较短，那么可能会出现动态表与原表数据不一致的情况。该如何观测这种不一致呢？
Hologres 提供了一个名为 Dynamic_Table_Refresh_History 的系统表，可以查看到每一次刷新的记录。在这张系统表中，有一个字段叫做 Refresh_Latency ，通过这个字段，可以查询到动态表中的数据与基表数据之间的延迟时间。基于这个延迟时间就可以判断增量刷新的延迟情况了。
但是每次通过周期性的增量刷新，虽然可能在某次刷新中存在延迟，但这一延迟通常会在下一次刷新时被弥补，确保数据的最终一致性。尽管短期内可能存在延迟，但最终延迟会趋向于零。
第三是在使用Dynamic Table时，推荐尽量采用分区表的形式。以刚刚演示的Demo为例，如果一张表既需要满足实时写入的需求，又存在历史数据回刷和订正的场景，那么使用Dynamic Table的分区表将是一个非常好的选择。在这种情况下，推荐对最新的分区采用增量刷新模式，而对历史的分区则使用全量刷新模式。这样一来通过一套代码就可以实现不同的刷新策略。
在刚才的演示中分区表的使用场景确实相对复杂。由于目前Dynamic Table还未支持动态刷新功能，那么该如何应对这一挑战呢？让再次回到之前的界面。大家可以看到，目前的分区都是手动创建的，而且增量刷新也需要手动转换为全量刷新，这在Circle上的操作并不便捷。不过可以通过Dataworks这一新版的数据开发平台来提供支持。Dataworks的新版数据开发同样支持动态表。例如，我这里已经有一个创建好的动态表实例展示，在这个实例中，所有动态表的创建和配置都已经完成，大大简化了操作流程。
而在构建分区表时，一旦确定了分区字段，右侧的配置选项将能够自动进行相应设置。例如可以预设分区创建的提前时间，以实现动态分区的效果。具体来说是可以设定分区创建的提前量，以及分区的具体创建时间点。此外还可以设定分区刷新的启动时机，以及何时自动将分区从增量刷新模式切换为全量刷新模式。通过DataWorks这一平台能够轻松实现动态分区的目的。欢迎大家积极尝试并使用这一功能。
另外正在开发新版的动态分区表，届时Dynamic Table的使用将会变得更加简便，无需用户关心分区的创建以及刷新模式的切换。系统会自动处理模式的转换，并自动创建所需的分区索引，极大地简化了操作流程。这一功能预计将在3.1版本中推出，欢迎大家届时体验。回到PPT的界面，关于分区表的应用场景。通过Hologres的分区表功能，可以总结得出仅通过一套代码，就能实现增量和全量两种刷新计算模式，既高效又便捷。
第四是关于计算资源的选择，即在本地实例和Serverless之间如何做出抉择。如果刷新任务相对较小，使用本地实例的资源通常是没有问题的。然而当每次刷新，特别是涉及到历史数据的全量回刷时，强烈建议使用Serverless资源。这样做不仅可以提高任务的稳定性，还能有效避免对其他任务可能产生的干扰和影响。
第五是关于刷新任务的监控、告警及观测。外部系统可以管理整个刷新任务及其血缘关系。同时在监控指标中，也可以查看到与Refresh相关任务的运行情况，例如QPS、RPS以及失败情况等。大家还可以通过云监控等方式，设置相应的监控项和报警规则。以上是关于dynamic table使用的一些建议。
此外，分享一下Dynamic Table与其他产品的对比情况，这里主要对比的是DIS的异步物化视图和Snowflake的Dynamic Tables。总结来说，目前Hologres的Dynamic Table功能已经基本上与Snowflake的Dynamic Tables相当。两者都支持批量刷新，同时也都支持分钟级的增量刷新。在查询类型上，它们都支持单表聚合、多表关联以及维度表关联等。在观测性方面，Hologres也如同Snowflake一样，提供了可视化界面以及监控告警等功能。另外，在与Doris的异步物化视图进行对比时，可以发现Doris的异步物化视图主要依赖于批量刷新机制。尽管它能够针对指定的分区或数据范围进行刷新，但本质上仍是批量处理。相比之下，Hologres的优势在于支持增量刷新。这意味着在每次处理时，系统仅需处理增量的数据，从而显著减少了数据计算量，降低了资源消耗。这一特性使得Hologres能够轻松应对分钟级延迟的准实时场景。
然而，异步物化视图也具备一个显著优势，即支持查询的透明改写。目前，若要使用Hologres的Dynamic Table进行查询，用户仅能查询与Dynamic Table相关的数据。但值得注意的是，后续也将支持这一功能，以进一步提升用户体验。
