Hologres Dynamic Table 快速入门

作者：赵红梅 Hologres PD

本次分享的主题是 Dynamic Table 快速入门，由 Hologres PD 赵红梅分享。今天的分享分为三个部分。首先，第一部分介绍 Dynamic Table；第二部分进行 Dynamic Table 的实操；第三部分为一些使用 DynamicTable 的建议和最佳实践。

1. Hologres Dynamic Table 介绍

2. Dynamic Table 的使用方法和实操

3. Dynamic Table 的使用建议

一、Hologres Dynamic Table 介绍

首先进入第一个部分。先来探讨一下实时数仓的典型应用场景，总结起来大致有以下四类。

比如 BI 报表分析类，这包括常见的实时大屏、BI 报表数据中台等；

第二类是人群运营类；

第三类是日志分析与检索类，如行为分析、流量分析等；

第四类则是实时监控类，例如实时风控、直播监控等。

这些实时数仓的场景广泛应用于广告、游戏、电商、互联网等多个行业。但是并非这些实时数仓的场景都要求达到秒级或毫秒级的低延迟，更多的场景，如报表分析、人群运营类应用，其实更多地属于准实时场景，即分钟级延迟。

为了支撑实时数仓，包括离线、实时以及准实时等场景，我们来看看这些场景背后的数仓技术是如何实现的。

常见的数仓架构如下图所示，首先在存储层会包含多个存储组件，比如离线存储和实时存储。为了满足实时数仓中不同的查询需求，以及离线场景的计算需求，通常会采用不同的计算引擎。离线场景可能会使用像 MaxCompute 或 Spark 这样的离线计算引擎来处理数据。通过这些引擎以批处理的方式计算离线数据，并将结果写入到服务层，比如实时数仓 Hologres、Starrocks 等中，最终对接到应用端。

为了满足实时或准实时场景的需求，通常依赖于实时计算引擎，比如 Flink 来提供支持。Flink 这类实时计算引擎能够对数据进行实时处理，并将处理结果写入实时数仓或数据湖中，最终为在线服务提供支持。这套架构其实是一个典型的 Lambda 架构，然而该架构也存在许多痛点：

• 例如，架构中涉及的组件众多，既有离线计算引擎，也有实时计算引擎，这无疑增加了开发和运维的复杂性和不便性。

• 第二个问题是，由于需要支持不同的场景，如离线场景、实时场景和准实时场景，而这套架构采用了不同的组件。在存储层，离线场景和实时场景各自拥有独立的存储系统，这导致了数据的冗余。在计算层，既有离线计算引擎，也有实时计算引擎，这意味着需要维护两套代码，这可能导致实时和离线的数据口径不一致，进而引发数据不一致的问题。

• 此外如前所述，实时数仓的场景不仅包含实时计算，还包含准实时计算。然而这套架构在支持准实时计算场景时存在不足。如果采用离线计算引擎来支持准实时场景，那么延迟会非常高，无法满足分钟级延迟的需求。而如果采用实时计算引擎来支持准实时场景，虽然可以满足延迟要求，但实时计算的成本却很高，这使得在实际应用中难以权衡。

是否有一款产品能够同时支持多种计算模式，统一数据存储，并且更好地满足准实时计算场景的需求呢？

经过技术调研，我们发现增量计算技术非常适合用于支持准实时计算场景。因此，在 Hologres 的 3.0 版本中，重点引入了 Dynamic Table 这一新型表类型，也称作动态表。它能够自动地将查询结果物化。同时 Dynamic Table 提供了两种计算模式：增量计算模式和全量计算模式，来满足不同场景的计算需求。

顾名思义，增量计算即每次刷新时仅处理新增的数据，也被称为增量刷新。与传统的全量数据计算相比，通过增量计算可以显著减少数据的处理量，从而提升 Query 的处理速度，并降低计算成本。这种计算方式非常适用于准实时计算场景的需求。

而全量刷新是指每次处理查询时，都会通过全量的方式来更新数据。这种方式通常建议用于周期性调度、数据回刷等场景。虽然全量刷新的成本在某些情况下可能会比增量刷新更低，但 Hologres 本身支持实时和离线存储。通过结合 Hologres 和 Dynamic Table，可以实现一份数据同时支持多种计算模式，从而在性能和成本之间达到完美平衡，满足业务对于不同刷新延迟的多样化需求。

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 可以与 Serverless 结合使用。无论是增量刷新还是全量刷新，都可以提交到 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 过程，并自动加速了数据湖与数据仓之间的数据流动，实现了两者之间的数据融合与加速。

二、Dynamic Table 实操 demo

本次演示将分为三个场景进行介绍。

2.1 创建全量刷新的 Dynamic Table

第一个场景，即端到端地创建一张全量刷新的 Dynamic Table。

2.2 创建增量量刷新的 Dynamic Table

如何基于 Parquet 外表进行增量刷新来更新表格。

2.3 创建全量和增量融合的 Dynamic Table

第三个场景是增量和全量混合使用的场景。

通常原表的数据量可能非常大，动辄几亿、几十亿条记录，因此经常需要进行分区操作。在业务上，往往需要对当天的分区数据进行实时查询，而对于历史分区的数据，则可能需要进行离线查询或离线修正。而为了满足这样的需求，可以通过 Dynamic Table 来实现。

具体操作 Demo 视频请参考：

https://cloud.video.taobao.com/vod/0xrZGXTojnmEI53NUIPNITzuJhG_TUXAmYBYxmDvJ1I.mp4

三、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 相关的数据。但值得注意的是，后续也将支持这一功能，以进一步提升用户体验。