使用反向 ETL 将数据从 BigQuery 加载到 Spanner 图中

本文档介绍了如何使用反向提取、转换和加载 (ETL) 流水线将图数据从 BigQuery 迁移到 Spanner Graph 并持续同步。它涵盖以下关键方面:

如需使用反向 ETL 将数据从 BigQuery 导出到 Spanner,请参阅将数据导出到 Spanner

BigQuery 是一款分析处理平台,可大规模执行复杂的数据操作,而 Spanner 针对需要高 QPS 和低服务延迟时间的用例进行了优化。Spanner Graph和 BigQuery 可有效集成,在 BigQuery 分析流水线中准备图数据,使 Spanner 能够提供低延迟的图遍历。

准备工作

  1. 创建一个包含图表数据的数据库,并使用该数据库创建 Spanner 实例。如需了解详情,请参阅设置和查询 Spanner Graph

  2. 在 BigQuery 中,创建企业版或企业 Plus 版层级的 slot 预留。 如果您运行导出到 Spanner Graph的作业,可以降低 BigQuery 计算费用。为此,请将基准槽容量设置为零,并启用自动扩缩

  3. 授予为用户提供执行本文档中的每个任务所需权限的 Identity and Access Management (IAM) 角色

所需的角色

如需获得将 BigQuery 图表数据导出到 Spanner Graph 所需的权限,请让管理员向您授予项目的以下 IAM 角色:

如需详细了解如何授予角色,请参阅管理对项目、文件夹和组织的访问权限

您也可以通过自定义角色或其他预定义角色来获取所需的权限。

反向 ETL 使用场景

以下是示例用例。在 BigQuery 中分析和处理数据后,您可以使用反向 ETL 将数据移至 Spanner Graph。

数据汇总和总结 - 使用 BigQuery 计算细粒度数据的汇总,使其更适合运营用例。

数据转换和扩充 - 使用 BigQuery 清理和标准化从不同数据源接收的数据。

数据过滤和选择 - 使用 BigQuery 过滤大型数据集以进行分析。例如,您可以过滤掉实时应用不需要的数据。

特征预处理和工程 - 在 BigQuery 中,使用 ML.TRANSFORM 函数转换数据,或使用 ML.FEATURE_CROSS 函数创建输入特征的特征组合。然后,使用反向 ETL 将生成的数据移入 Spanner Graph。

了解反向 ETL 流水线

在反向 ETL 流水线中,数据会分两步从 BigQuery 移至 Spanner Graph:

  1. BigQuery 使用分配给流水线作业的来提取和转换源数据。

  2. BigQuery 反向 ETL 流水线使用 Spanner API 将数据加载到已预配的 Spanner 实例中。

下图显示了反向 ETL 流水线中的各个步骤:

一张图表,显示了在反向 ETL 流水线中,数据从 BigQuery 移至 Spanner Graph时的三个主要步骤。

图 1. BigQuery 反向 ETL 流水线流程

管理图数据更改

您可以使用反向 ETL 执行以下操作:

  • 将图数据集从 BigQuery 加载到 Spanner Graph。

  • 将 Spanner Graph数据与 BigQuery 中数据集的持续更新同步。

您可以使用 SQL 查询配置反向 ETL 流水线,以指定源数据和要应用的数据转换。流水线使用 upsert 操作将满足 SELECT 语句的 WHERE 子句的所有数据加载到 Spanner 中。upsert 操作等同于 INSERT OR UPDATE 语句。它会在存储图数据的表中插入新行并更新现有行。流水线会根据 Spanner 表主键处理新行和更新后的行。

为具有加载顺序依赖关系的表插入和更新数据

Spanner Graph 架构设计最佳实践建议使用交错表和外键。如果您使用交错表或强制执行的外键,则必须按特定顺序加载节点和边数据。这样可确保在创建引用行之前,被引用的行已存在。如需了解详情,请参阅创建交织表

以下示例图输入表架构使用交错表和外键约束来为人员与其账号之间的关系建模:

CREATE TABLE Person (
  id    INT64 NOT NULL,
  name  STRING(MAX)
) PRIMARY KEY (id);

CREATE TABLE Account (
  id           INT64 NOT NULL,
  create_time  TIMESTAMP,
  is_blocked   BOOL,
  type        STRING(MAX)
) PRIMARY KEY (id);

CREATE TABLE PersonOwnAccount (
  id           INT64 NOT NULL,
  account_id   INT64 NOT NULL,
  create_time  TIMESTAMP,
  CONSTRAINT FK_Account FOREIGN KEY (account_id) REFERENCES Account (id)
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

CREATE PROPERTY GRAPH FinGraph
  NODE TABLES (
    Person,
    Account
  )
  EDGE TABLES (
    PersonOwnAccount
      SOURCE KEY (id) REFERENCES Person
      DESTINATION KEY (account_id) REFERENCES Account
      LABEL Owns
  );

在此示例架构中,PersonOwnAccountPerson 中的一个交错表。在加载 PersonOwnAccount 表中的元素之前,先加载 Person 表中的元素。此外,PersonOwnAccount 上的外键限制条件可确保 Account(即边关系目标)中存在匹配的行。因此,请先加载 Account 表,然后再加载 PersonOwnAccount 表。以下列表总结了此架构的加载顺序依赖项:

请按照以下步骤加载数据:

  1. PersonOwnAccount 之前加载 Person
  2. PersonOwnAccount 之前加载 Account

Spanner 会强制执行示例架构中的参照完整性限制条件。如果流水线尝试在 PersonOwnAccount 表中创建一行,但在 Person 表或 Account 表中没有匹配的行,则 Spanner 会返回错误。然后,流水线会失败。

此反向 ETL 流水线示例使用 BigQuery 中的 EXPORTDATA 语句从数据集中的 PersonAccountPersonOwnAccount 表导出数据,以满足加载顺序依赖关系:

BEGIN
EXPORT DATA OPTIONS (
    uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
    format='CLOUD_SPANNER',
    spanner_options="""{
      "table": "Person",
      "priority": "HIGH",
      "tag" : "graph_data_load_person"
    }"""
  ) AS
  SELECT
    id,
    name
  FROM
    DATASET_NAME.Person;

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format='CLOUD_SPANNER',
  spanner_options="""{
    "table": "Account",
    "priority": "HIGH",
    "tag" : "graph_data_load_account"
  }"""
) AS
SELECT
  id,
  create_time,
  is_blocked,
  type
FROM
  DATASET_NAME.Account;

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format='CLOUD_SPANNER',
  spanner_options="""{
    "table": "PersonOwnAccount",
    "priority": "HIGH",
    "tag" : "graph_data_load_person_own_account"
  }"""
) AS
SELECT
  id,
  account_id,
  create_time
FROM
  DATASET_NAME.PersonOwnAccount;
END;

同步数据

如需将 BigQuery 与 Spanner Graph同步,请使用反向 ETL 流水线。您可以配置流水线以执行以下操作之一:

  • 将 BigQuery 源中的所有插入和更新操作应用到 Spanner Graph目标表。您可以向目标表添加架构元素,以在逻辑上表示删除操作,并按计划移除目标表行。

  • 使用可应用插入和更新操作并识别删除操作的时间序列函数。

参照完整性约束

与 Spanner 不同,BigQuery 不强制执行主键和外键限制条件。如果您的 BigQuery 数据不符合您在 Spanner 表中创建的限制条件,反向 ETL 流水线在加载该数据时可能会失败。

反向 ETL 会自动将数据分组为不超过每次提交的突变次数上限的批次,并以任意顺序将这些批次原子性地应用到 Spanner 表中。如果批次包含未能通过参照完整性检查的数据,Spanner 将不会加载该批次。此类失败的示例包括:交织的子行缺少父行,或者强制执行的外键列在被引用的列中没有匹配的值。如果某个批次未能通过检查,流水线会因错误而失败,并停止加载批次。

了解参照完整性限制错误

以下示例展示了您可能会遇到的参照完整性限制条件错误:

解决外键限制条件错误
  • 错误:“表 PersonOwnAccount 上违反了外键限制条件 FK_Account。在 Account(id) 中找不到引用的值

  • 原因:向 PersonOwnAccount 表插入行的操作失败,原因是缺少 FK_Account 外键所需的 Account 表中的匹配行。

解决“缺少父行”错误
  • 错误:“表格 PersonOwnAccount 中 [15,1] 行的父行缺失”

  • 原因:向 PersonOwnAccountid: 15account_id: 1)插入行的操作失败,原因是 Person 表 (id: 15) 中缺少父行。

如需降低出现参照完整性错误的风险,请考虑以下选项。每种方案各有利弊。

  • 放宽限制,以允许 Spanner Graph 加载数据。
  • 向流水线添加逻辑,以省略违反参照完整性限制的行。

放宽参照完整性

避免在加载数据时出现参照完整性错误的一种方法是放宽限制,以便 Spanner 不强制执行参照完整性。

  • 您可以使用 INTERLEAVE IN 子句创建交错表,以使用相同的物理行交错特征。如果您使用 INTERLEAVE IN 而不是 INTERLEAVE IN PARENT,Spanner 不会强制执行引用完整性,但查询会受益于相关表的共存。

  • 您可以使用 NOT ENFORCED 选项创建信息性外键NOT ENFORCED 选项可提供查询优化优势。不过,Spanner 不会强制执行参照完整性。

例如,如需创建不进行参照完整性检查的边输入表,您可以使用以下 DDL:

CREATE TABLE PersonOwnAccount (
  id          INT64 NOT NULL,
  account_id  INT64 NOT NULL,
  create_time TIMESTAMP,
  CONSTRAINT FK_Account FOREIGN KEY (account_id) REFERENCES Account (id) NOT ENFORCED
) PRIMARY KEY (id, account_id),
INTERLEAVE IN Person;

在反向 ETL 流水线中保持参照完整性

为确保流水线仅加载满足参照完整性检查的行,请仅包含在 PersonAccount 表中具有匹配行的 PersonOwnAccount 行。然后,保留加载顺序,以便 Spanner 在加载引用 PersonAccount 行的 PersonOwnAccount 行之前加载这些行。

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format='CLOUD_SPANNER',
    spanner_options="""{
      "table": "PersonOwnAccount",
      "priority": "HIGH",
      "tag" : "graph_data_load_person_own_account"
    }"""
  ) AS
  SELECT
    poa.id,
    poa.account_id,
    poa.create_time
  FROM `PROJECT_ID.DATASET_NAME.PersonOwnAccount` poa
    JOIN `PROJECT_ID.DATASET_NAME.Person` p ON (poa.id = p.id)
    JOIN `PROJECT_ID.DATASET_NAME.Account` a ON (poa.account_id = a.id)
  WHERE poa.id = p.id
    AND poa.account_id = a.id;

删除图表元素

反向 ETL 流水线使用 upsert 操作。由于 upsert 操作等同于 INSERT OR UPDATE 语句,因此流水线只能同步在运行时存在于源数据中的行。这意味着流水线会排除已删除的行。如果您从 BigQuery 中删除数据,反向 ETL 流水线无法直接从 Spanner Graph 中移除相同的数据。

您可以使用以下任一选项来处理 BigQuery 源表中的删除操作:

在来源中执行逻辑删除或软删除

如需在 BigQuery 中以逻辑方式标记要删除的行,请使用删除标志。然后,在目标 Spanner 表中创建一个列,以便将标志传播到该列。当反向 ETL 应用流水线更新时,删除 Spanner 中具有此标志的行。您可以使用分区 DML 显式查找并删除此类行。或者,通过配置一个 TTL(存留时间)列(其日期取决于删除标志列)来隐式删除行。编写 Spanner 查询以排除这些逻辑删除的行。这样可确保 Spanner 在预定删除时间之前从结果中排除这些行。反向 ETL 流水线运行完毕后,Spanner 会在其行中反映逻辑删除。然后,您可以从 BigQuery 中删除相应行。

此示例向 Spanner 中的 PersonOwnAccount 表添加了 is_deleted 列。然后,它会添加一个依赖于 is_deleted 值的 expired_ts_generated 列。由于生成列中的日期早于 DELETION POLICY 阈值,因此 TTL 政策会安排删除受影响的行。

ALTER TABLE PersonOwnAccount
  ADD COLUMN is_deleted BOOL DEFAULT (FALSE);

ALTER TABLE PersonOwnAccount ADD COLUMN
  expired_ts_generated TIMESTAMP AS (IF(is_deleted,
    TIMESTAMP("1970-01-01 00:00:00+00"),
    TIMESTAMP("9999-01-01 00:00:00+00"))) STORED HIDDEN;

ALTER TABLE PersonOwnAccount
  ADD ROW DELETION POLICY (OLDER_THAN(expired_ts_generated, INTERVAL 0 DAY));

将 BigQuery 更改历史记录用于 INSERT、UPDATE 和逻辑删除

您可以使用 BigQuery 表的更改历史记录来跟踪对该表的更改。使用 GoogleSQL CHANGES 函数查找在特定时间间隔内发生更改的行。然后,将已删除的行信息与反向 ETL 流水线搭配使用。您可以设置流水线,以便在 Spanner 表中设置指示器(例如删除标志或到期日期)。此指示器用于标记 Spanner 表中要删除的行。

使用 CHANGES 时间序列函数的结果来决定将源表中的哪些行纳入反向 ETL 流水线的加载中。

如果源表中存在相应行,则流水线会包含 _CHANGE_TYPEINSERTUPDATE 的行作为 upsert。源表中的当前行提供的是最新数据。

使用 _CHANGE_TYPEDELETE 的行(这些行在源表中没有现有行)在 Spanner 表中设置指示器,例如删除标志或行过期日期。

您的导出查询必须考虑 BigQuery 中的插入和删除顺序。例如,假设在时间 T1 删除了一行,并在稍后的时间 T2 插入了一行新行。如果两者都映射到同一 Spanner 表行,则导出必须按原始顺序保留这些事件的效果。

如果设置了该参数,删除指示器会标记 Spanner 表中要删除的行。

例如,您可以向 Spanner 输入表中添加一列,用于存储每行的过期日期。然后,创建使用这些失效日期的删除政策。

以下示例展示了如何添加一个列来存储表行的过期日期。

ALTER TABLE PersonOwnAccount ADD COLUMN expired_ts TIMESTAMP;

ALTER TABLE PersonOwnAccount
  ADD ROW DELETION POLICY (OLDER_THAN(expired_ts, INTERVAL 1 DAY));

如需在 BigQuery 中对表使用 CHANGES 函数,请将表的 enable_change_history 选项设置为 TRUE

ALTER TABLE `PROJECT_ID.DATASET_NAME.PersonOwnAccount`
  SET OPTIONS (enable_change_history=TRUE);

以下示例展示了如何使用反向 ETL 更新新行或更改的行,以及如何为标记为删除的行设置过期日期。与 PersonOwnAccount 表进行左联接可让查询获得有关每行当前状态的信息。

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
    format='CLOUD_SPANNER',
    spanner_options="""{
      "table": "PersonOwnAccount",
      "priority": "HIGH",
      "tag" : "graph_data_delete_via_reverse_etl"
    }"""
  ) AS
SELECT
  DISTINCT
   IF (changes._CHANGE_TYPE = 'DELETE', changes.id, poa.id) AS id,
   IF (changes._CHANGE_TYPE = 'DELETE', changes.account_id, poa.account_id) AS account_id,
   IF (changes._CHANGE_TYPE = 'DELETE', changes.create_time, poa.create_time) AS create_time,
   IF (changes._CHANGE_TYPE = 'DELETE', changes._CHANGE_TIMESTAMP, NULL) AS expired_ts
FROM
  CHANGES(TABLE `PROJECT_ID.DATASET_NAME.PersonOwnAccount`,
    TIMESTAMP_TRUNC(TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY), DAY),
    TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), DAY)) changes
LEFT JOIN `PROJECT_ID.DATASET_NAME.PersonOwnAccount` poa
  ON (poa.id = changes.id
  AND poa.account_id = changes.account_id)
WHERE (changes._CHANGE_TYPE = 'DELETE'
   AND poa.id IS NULL)
   OR (changes._CHANGE_TYPE IN ( 'UPDATE', 'INSERT')
   AND poa.id IS NOT NULL );

示例查询使用 LEFT JOIN 和源表来保留顺序。此联接可确保忽略在查询更改历史记录时间间隔内删除然后重新创建的行的 DELETE 更改记录。流水线会保留有效的新行。

删除行时,流水线会使用 _CHANGE_TIMESTAMP 列中的 DELETE 时间戳填充相应 Spanner Graph 行中的 expired_ts 列。Spanner 中的行删除政策 (TTL 政策) 会删除 expired_ts 值超过一天前的任何行。

为确保系统可靠性,请协调流水线的调度、更改回溯窗口和 Spanner TTL 政策。安排流水线每天运行一次。Spanner TTL 政策的持续时间必须长于此运行间隔。这样可以防止流水线重新处理 Spanner TTL 政策已移除的行的先前 DELETE 事件。

此示例显示了 start_timestampend_timestamp 区间,用于捕获上一个 UTC 日期以来所有 BigQuery 表更改的每日查询。由于这是批处理查询,并且 CHANGES 函数存在限制,因此 end_timestamp 必须至少比当前时间早 10 分钟。因此,请将此查询安排在世界协调时间 (UTC) 午夜后至少 10 分钟运行。如需了解详情,请参阅 CHANGES 文档

使用包含上次查看时间戳的 TTL 列

反向 ETL 流水线会将 Spanner 表中每行的 last_seen_ts 列设置为当前时间戳。删除 BigQuery 行时,Spanner 不会更新相应的行,并且 last_seen_ts 列不会发生变化。然后,Spanner 会根据定义的阈值,使用 TTL 政策或分区 DML 移除具有过时 last_seen_ts 的行。在预定删除时间之前,Spanner 查询可以过滤掉 last_seen_ts 早于此阈值的行。如果图表数据经常更新,并且缺少更新表示数据已过时,可以删除,那么此方法非常有效。

执行完全刷新

在从 BigQuery 加载之前,您可以删除 Spanner 表,以反映源表中的删除操作。这样可防止流水线在下次运行时将从源 BigQuery 表中删除的行加载到 Spanner 中。这可能是最容易实现的选项。不过,请考虑完全重新加载图表数据所需的时间。

维护预定的批量反向 ETL 流水线

在反向 ETL 流水线的初始运行将数据从 BigQuery 批量加载到 Spanner Graph后,真实世界的数据会不断变化。数据集会发生变化,流水线会随着时间的推移添加或移除图元素。流水线会发现新节点并添加新的边关系,或者 AI 推理会生成这些节点和关系。

为确保 Spanner Graph数据库保持最新状态,请使用以下任一选项安排和按顺序执行 BigQuery 流水线编排:

借助 BigQuery 流水线,您可以在 BigQuery 中开发、测试、版本控制和部署复杂的 SQL 数据转换工作流。它通过允许您定义流水线中查询之间的关系来原生处理顺序依赖关系。Dataform 会构建依赖关系树,并按正确的顺序运行查询。这样可确保上游依赖项在下游任务开始之前完成。

Cloud Scheduler 调用的 Workflows 提供了一种实用且灵活的解决方案,用于编排一系列Google Cloud 服务(包括 BigQuery 查询)。将工作流定义为一系列步骤,每个步骤都运行一个 BigQuery 作业。您可以使用 Cloud Scheduler 按定义的时间表调用这些工作流。使用工作流定义管理依赖项,以指定执行顺序、实现条件逻辑、处理错误以及将一个查询的输出传递给另一个查询。

安排的查询(也称为 BigQuery 转移作业)可让您在 BigQuery 中定期运行 SQL 语句。预定查询不提供强大的错误处理或动态依赖项管理功能。

使用 BigQuery 持续查询进行反向 ETL

借助 BigQuery 持续查询功能,您可以近乎实时地运行 BigQuery 操作。将 EXPORT DATA 与持续查询相结合,可提供一种替代方法来运行反向 ETL 流水线,从而避免使用预定的批处理作业。

持续查询是一种长时间运行的查询,用于监控源 BigQuery 表中的新行。当 BigQuery 检测到有新行附加到表中时,会将查询结果流式传输到 EXPORT DATA 操作。

此方法具有以下优势。

  • 近乎实时的数据同步:BigQuery 中的新行会以极低的延迟反映在 Spanner 中。

  • 减少了批处理开销:持续查询无需定期运行批处理作业,从而减少了计算开销。

  • 事件驱动型更新:根据 BigQuery 中的实际变化更新 Spanner 数据。

持续查询流水线需要具有 job_typeCONTINUOUS 的槽预留分配。在项目或文件夹级层或组织级层分配此角色。

创建从 BigQuery 到 Spanner 的反向 ETL 持续查询

配置 APPENDS 函数的 start_timestamp 参数,以从批量加载停止的位置开始处理数据。此函数会捕获在特定时间窗口内创建的所有行。在以下示例中,流水线任意将起点设置为 CURRENT_TIME 之前的 10 分钟。 此时间戳必须在 BigQuery 时间旅行窗口内。

您可以通过多种方法启动持续查询流水线,包括:

  1. 在 BigQuery Studio 中,选择更多,然后在选择查询模式下选择持续查询

  2. 使用 bq CLI 并提供选项 --continuous=true

EXPORT DATA OPTIONS ( uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format="CLOUD_SPANNER",
  spanner_options="""{
      "table": "PersonOwnAccount",
      "priority": "HIGH",
      "tag": "reverse-etl-continuous",
      "change_timestamp_column": "create_time"
   }"""
)
AS SELECT id, account_id, _CHANGE_TIMESTAMP as create_time
  FROM
APPENDS(TABLE `PROJECT_ID.DATASET_NAME.PersonOwnAccount`,
  CURRENT_TIMESTAMP() - INTERVAL 10 MINUTE )

无法保证加载顺序

Spanner Graph 数据由多个输入表组成。如果表具有引用完整性限制,您必须严格遵守加载顺序。不过,并发的持续查询无法控制 Spanner 添加行的顺序。因此,使用持续查询加载 Spanner Graph 数据仅适用于具有宽松的引用完整性约束的图表架构。

与现有流水线集成

持续查询可与现有的计划批量作业相辅相成。例如,使用持续查询进行近乎实时的更新,并使用预定作业进行完整的数据同步或对账。

使用 BigQuery 持续查询构建响应迅速且最新的反向 ETL 流水线,以在 BigQuery 和 Spanner Graph之间同步数据。

持续查询注意事项

  • 费用:持续查询会产生持续查询执行和数据流式传输的费用。

  • 错误处理:如果持续查询流水线遇到任何数据库错误(例如主键重复或违反参照完整性),系统会取消该流水线。如果流水线失败,您必须先手动更正源 BigQuery 表中的数据,然后才能重新启动查询。

  • 未处理的删除和更新APPENDS 函数仅捕获插入操作。它不会捕获删除或更新。

遵循反向 ETL 最佳实践

为获得最佳效果,请执行以下操作。

  • 选择一种策略,以防止在加载边数据时出现引用完整性错误。

  • 设计整体数据流水线以防止出现悬空边。悬空边可能会影响 Spanner Graph 查询效率和图表结构完整性。如需了解详情,请参阅防止出现悬空边

  • 遵循 Spanner 导出优化建议。

  • 如果您要加载大量数据,请考虑将流水线划分为多个较小的流水线,以避免达到默认的 6 小时 BigQuery 查询执行时间配额。如需了解详情,请参阅 BigQuery 查询作业限制

  • 对于大型数据加载,请在初始批量数据加载完成后添加索引和外键约束条件。此做法可提高数据加载性能,因为外键限制条件需要额外的读取操作才能进行验证,而索引需要额外的写入操作。这些操作会增加事务参与者的数量,从而减慢数据加载过程。

  • 在 Spanner 中启用自动扩缩功能,以缩短将数据加载到实例中的时间。然后,在 BigQuery EXPORT DATA 命令的 spanner_options 部分中,将 Spanner priority 参数配置为 HIGH。如需了解详情,请参阅 Spanner 自动扩缩概览使用 spanner_options 选项配置导出RequestOptions.priority

  • 对于大型数据加载,请创建分块点以预先拆分数据库。这会为提高吞吐量做好 Spanner 准备。

  • 在流水线定义中,为数据加载配置 Spanner 请求优先级

后续步骤