连续的物化视图

本文档简要介绍了持续物化视图及其常见用例。在阅读本页内容之前，您应该先熟悉 Bigtable 概览。

在 Bigtable 中，持续物化视图是持续、全托管式后台进程的结果。此过程会使用您提供的 SQL 查询来创建和维护一个预计算表，Bigtable 会随着源数据的变化以增量方式更新该表。SQL 查询可以包含对底层 Bigtable 表的聚合和转换。

持续具体化视图中的数据包括以下内容：

  • 从源表中的数据派生的汇总值或转换值
  • 定义分组键的未汇总值

借助连续的物化视图，您可以在注入数据时对其进行预汇总。 此外，连续的具体化视图架构与其源表不同，它使用针对不同查找模式的查询进行了优化的结构呈现源表数据，而不是针对在源表上使用的查询。

以下是 Bigtable 中连续物化视图的主要特征：

  • 零维护：连续的具体化视图会在后台预计算。对源表的数据更改（包括更新和删除）会在后台自动传播到持续具体化视图，无需用户执行任何操作。
  • SQL 开发模式：连续物化视图基于 GoogleSQL for Bigtable 查询，包括 SQL 函数、过滤条件和聚合。虽然这些函数默认具有确定性，但在有限的应用场景中，您可以选择启用一组精选的非确定性函数。
  • 与垃圾回收同步：持续具体化视图会与其源表的垃圾回收政策保持同步，并在表数据过期或被删除时自动更新。
  • 读写延迟时间不受影响：当实例的集群预配充足或使用自动扩缩时，持续具体化视图对源表的性能影响极小。
  • 最终一致：连续的物化视图在后台计算。对连续具体化视图的更新可能会延迟，但连续物化结果始终保持一致。

您用于定义连续具体化视图的行键、列限定符和列值会被视为服务数据。因此，请勿使用包含敏感信息的行键、列限定符或列值创建持续具体化视图。如需了解服务数据的处理方式，请参阅Google Cloud 隐私权声明。

您可以使用 Google Cloud CLI、 Google Cloud 控制台中的 Bigtable Studio 查询编辑器或适用于 Java 和 Go 的 Bigtable 客户端库创建持续具体化视图。

您可以使用以下命令从持续具体化视图中读取数据：

  • Bigtable Studio 查询编辑器
  • 支持 SQL 查询的 Bigtable 客户端库
  • 使用 Java 和 Go 版 Bigtable 客户端库进行 ReadRows API 调用

如需了解详情，请参阅从持续物化视图中读取数据。

何时使用连续的物化视图

借助持续的物化视图，您可以使用 SQL 定义 Bigtable 数据的新表示形式。创建后，持续物化视图会持续自动将源表中的数据重构为 SQL 查询定义的格式。然后，您可以查询持续具体化视图，而不是在读取数据后查询表并转换或汇总数据。

连续物化视图可以提高以下用例的查询性能：

  • 数据预聚合：您可以使用持续具体化视图来聚合各行中的传入数据。这样，您就可以快速检索汇总和聚合的数据，例如信息中心的指标。
  • Lambda 和 Kappa 架构的自动化：如果您的应用需要混合使用实时流处理流水线数据和包含历史数据的批量流水线数据，请使用持续物化视图。这些视图提供了所有数据源的视图，该视图会随时间更新以反映底层数据的变化，而无需额外的流处理工具或自定义 ETL 作业。
  • 次要访问模式：连续物化视图会创建数据的替代表示。此表示法可以针对不同查找模式的查询进行优化，而不是针对在源表上使用的查询。这使得连续物化视图成为一种强大的工具，可用于为数据创建有效的异步二级索引。如需详细了解这些模式，请参阅创建异步二级索引。

如需将连续物化视图与其他类型的 Bigtable 视图进行比较，请参阅表和视图。

何时使用计数器

预先聚合数据的另一种方法是使用聚合单元格创建分布式计数器。

对聚合单元格的写入可立即从写入到的集群中读取。持续物化视图会在数据写入后进行处理，并最终与源表保持一致。

在以下情况下，请使用计数器，而不是连续物化视图：

  • 不需要过滤条件且不需要跨行的汇总。
  • 如果您需要立即从写入到的集群中读取写入内容。

如果您想执行以下操作，请使用连续物化视图：

  • 为针对汇总数据的查询生成不同的密钥。
  • 查看基表中的更改在聚合中的反映。
  • 自动合并多行数据。

在以下使用场景中，您可以结合使用计数器和持续物化视图：

  • 在汇总单元格中捕获新指标，但保留这些指标的历史汇总。
  • 在连续的具体化视图中组合指标。

资源预配和性能

连续物化视图的持续处理会作为低优先级后台作业进行。因此，只要您的集群大小合适，它对应用性能以及源表的读写延迟时间的影响就会降到最低。

为确保持续具体化视图中的数据保持最新，最佳做法是为包含持续具体化视图的实例中的集群启用自动扩缩。自动扩缩功能会自动添加足够的节点来处理处理开销，然后在不再需要这些节点时将其移除。这有助于确保在执行持续运行的 SQL 查询期间有足够的计算容量。自动扩缩还可以确保您有足够的节点来处理持续物化视图的存储需求。

连续的物化视图会计入每个实例 1,000 个表的限制。

在现有表上创建连续的物化视图

为现有表创建持续具体化视图时，Bigtable 会启动一个一次性流程，使用现有表数据填充该视图。此过程称为初始填充。初始填充所需的时间取决于表的大小和查询的复杂性。默认情况下，您无法在初始填充期间查询视图。但是，如果您的应用场景可以容忍不完整的数据（例如在应用开发期间），则可以使用 allow_incomplete_view 查询提示在填充完成之前查询视图。在此期间，如果视图执行聚合，则返回的聚合可能仅反映部分数据。如需了解详情，请参阅在初始填充期间读取数据。

此初始填充作为低优先级后台作业运行，以最大限度地减少对集群性能的影响。对于大型表，您可以暂时向集群添加更多节点，以加快视图创建速度。

下图展示了创建持续物化视图的过程：

在 Bigtable 中创建连续物化视图的过程。
图 1. 在 Bigtable 中创建连续物化视图的过程（点击可放大）。

例如，假设您的源表包含具有遵循模式 advertiser_id#region#ad_id 的键的行，以及一个包含 spend_usd 列限定符（其中包含表示广告支出的数字数据）的列族 data：

行键 data:spend_usd
adv1#us-east#ad1 100
adv1#us-west#ad2 150
adv2#us-east#ad3 200

如果您使用以下查询来定义此表的持续具体化视图，则在 175 节点集群上，1 TB 数据的初始填充大约需要 3 小时。

SELECT
          SPLIT(_key, "#")[SAFE_OFFSET(0)] AS advertiser_id,
          count(*) AS count,
          sum(cast(cast(data['spend_usd'] as string) as int64)) as sum_spend
        FROM `$0`
        GROUP BY advertiser_id

由于 Bigtable 呈线性扩缩，因此一个 175 节点的集群大约需要 6 小时来处理 2 TB 的数据，大约需要 30 小时来处理 10 TB 的数据（假设数据具有类似的形状）。如需缩短初始填充所需的时间，您可以暂时向集群添加更多节点，或者如果您使用的是自动扩缩，则可以暂时增加节点数上限。

非确定性 SQL 函数

默认情况下，持续物化视图仅支持确定性函数，以确保实例中所有集群的结果一致。不过，您可以选择启用非确定性函数（例如 CLUSTER_ATTRIBUTE()），按处理数据的集群过滤数据。如需了解详情，请参阅非确定性查询。

如需使用这些函数，您必须在创建持续具体化视图时确认潜在的语义差异。如需了解详情，请参阅创建持续物化视图。

存储

对于每个连续具体化视图，Bigtable 都会存储以下内容：

  • 连续具体化视图中的数据
  • 中间存储

与任何 Bigtable 表一样，连续具体化视图存在于包含该视图的实例中的所有集群上。实例中的集群必须有足够的节点来存储源表以及基于该表的任何连续物化视图。借助自动扩缩功能，您的集群可以根据存储需求的变化进行扩容或缩容。

持续具体化视图必须在与源表相同的实例中创建，即使持续具体化视图的存储空间与源表不同。

连续具体化视图存储

持续的具体化视图包含持续的具体化视图所基于的 SQL 查询产生的数据。这意味着它包含由 SQL 查询中的聚合子句定义的聚合值，以及定义分组键的非聚合值。

中间存储

为了支持持续具体化视图与其源表的同步，Bigtable 使用中间存储来存储需要增量更新持续物化视图的数据副本。

中间存储空间中的数据量大致相当于在源表中扫描的数据量，这些数据用于生成定义持续具体化视图的 SQL 查询的结果。例如，如果您的查询汇总了整个表中的数据，Bigtable 会在中间存储空间中保留相当于整个表的数据。基于特定行键范围或列的查询的持续具体化视图仅将这些行或列保留在中间存储空间中。

中间存储空间会在持续具体化视图的生命周期内保留，以便高效支持对视图的增量更新，并将删除操作从源表传播到持续具体化视图。您无法读取中间存储空间中的数据。如需深入了解中间存储空间用量，请参阅具体化视图。

复制

在使用复制功能的实例中，持续物化视图不会像表那样进行复制。而是由实例中的每个集群使用自己的源表副本独立处理持续具体化视图。例如，这意味着写入集群 A 上源表的数据会复制到集群 B 上的表，然后复制到集群 B 上的持续具体化视图。

费用

使用连续物化视图不会产生每资源费用。不过，创建和同步连续物化视图需要进行处理和存储，您需要按标准费率付费。创建持续具体化视图后，您可能会看到以下各项有所增加：

  • 存储 - 您需要为在持续具体化视图中存储数据以及中间存储付费。如需了解详情，请参阅存储。
  • 计算 - 源表和持续具体化视图的持续同步需要 CPU 处理，并且您的集群可能需要更多节点来处理额外的后台工作。

同时，您可能会看到对源表的一些处理减少，例如，当您不再对数据进行范围扫描以执行重复计算和其他效率较低的查询时。您可能也不需要运行流水线作业（例如 Dataflow 或 Spark）来汇总源数据并将其写回 Bigtable。

如需详细了解价格，请参阅 Bigtable 价格。如需了解可帮助您监控持续具体化视图使用情况的指标，请参阅指标。

指标

连续的具体化视图会向 Cloud Logging 报告多个关键指标，您可以使用这些指标来监控连续的物化视图。

指标 说明
materialized_view/max_delay 连续具体化视图的处理延迟时间上限
materialized_view/storage 用于持续具体化视图存储空间的数据量（以字节为单位）
materialized_view/intermediate_storage 持续物化视图的中间处理所使用的数据量（以字节为单位）
table/materialized_view_intermediate_storage 为此表上定义的持续物化视图进行中间处理所使用的数据量
materialized_view/user_errors 用户数据中针对连续具体化视图的错误数量。 用户错误导致数据无法传播到视图。
materialized_view/system_errors 系统针对连续具体化视图的错误数

您还可以使用许多 Bigtable 表指标来监控持续具体化视图，只需使用持续具体化视图 ID 代替表 ID 即可。具体而言，CPU 指标的细分中包含持续物化视图，这有助于您了解其影响。当您使用 Data API 的 ReadRows 方法读取连续具体化视图时，系统会生成每秒请求数、延迟时间和吞吐量的 Bigtable 指标。如需了解详情，请参阅指标。

如需开始使用 Cloud Logging，请参阅查询和查看日志概览。

限制

  • 每个实例最多可以创建 50 个连续物化视图。
  • 每个表最多可以创建 5 个连续物化视图。如有必要，您可以联系 Cloud Customer Care 来申请提高此限制。
  • 如果您在创建视图时未指定 _key，则源表中的所选列不得为 NULL。如需了解详情，请参阅由 GROUP BY 或 ORDER BY 子句定义的行键。
  • 您无法修改用于定义持续物化视图的 SQL 查询。您必须删除该持续具体化视图，然后创建一个包含更改的新视图。
  • 您无法为其他连续具体化视图或逻辑视图创建连续具体化视图。
  • 定义持续具体化视图的查询不能使用 SELECT *。
  • 您无法为持续具体化视图配置垃圾回收政策。所有数据保留均受源表的垃圾回收政策约束，源表的垃圾回收会自动反映在持续具体化视图中。
  • 您无法在具有微秒级时间戳精度的表上创建连续物化视图。

后续步骤