Use a ETL reversa para carregar dados do BigQuery no gráfico do Spanner

Este documento descreve como usar pipelines de extração, transformação e carregamento (ETL) reversos para mover e sincronizar continuamente dados de gráficos do BigQuery para o Spanner Graph. Ele aborda os seguintes aspectos principais:

Para usar a ETL reversa e exportar dados do BigQuery para o Spanner, consulte Exportar dados para o Spanner.

O BigQuery realiza manipulação de dados complexa em grande escala como uma plataforma de processamento analítico, enquanto o Spanner é otimizado para casos de uso que exigem QPS alto e baixa latência de serviço. O Spanner Graph e o BigQuery se integram de maneira eficaz para preparar dados de gráficos em pipelines de análise do BigQuery, permitindo que o Spanner faça travessias de gráficos de baixa latência.

Antes de começar

  1. Crie uma instância do Spanner com um banco de dados que contenha dados de gráfico. Para mais informações, consulte Configurar e consultar o Spanner Graph.

  2. No BigQuery, crie uma reserva de slot do nível Enterprise ou Enterprise Plus. É possível reduzir os custos de computação do BigQuery ao executar exportações para o Spanner Graph. Para fazer isso, defina uma capacidade de slot de referência de zero e ative o escalonamento automático.

  3. Atribua papéis do Identity and Access Management (IAM) que concedam aos usuários as permissões necessárias para realizar cada tarefa deste documento.

Funções exigidas

Para conseguir as permissões necessárias para exportar dados de gráficos do BigQuery para o Spanner Graph, peça ao administrador para conceder a você os seguintes papéis do IAM no seu projeto:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

Casos de uso de ETL reverso

Confira alguns exemplos de casos de uso. Depois de analisar e processar dados no BigQuery, é possível movê-los para o Spanner Graph usando a ETL reversa.

Agregação e resumo de dados: use o BigQuery para calcular agregações em dados granulares e torná-los mais adequados para casos de uso operacionais.

Transformação e enriquecimento de dados: use o BigQuery para limpar e padronizar dados recebidos de diferentes fontes.

Filtragem e seleção de dados: use o BigQuery para filtrar um grande conjunto de dados para fins analíticos. Por exemplo, é possível filtrar dados que não são necessários para aplicativos em tempo real.

Pré-processamento e engenharia de atributos: no BigQuery, use a função ML.TRANSFORM para transformar dados ou a função ML.FEATURE_CROSS para criar cruzamentos de atributos de atributos de entrada. Em seguida, use o ETL reverso para mover os dados resultantes para o Spanner Graph.

Entender o pipeline de ETL reverso

Os dados são movidos do BigQuery para o Spanner Graph em um pipeline de ETL reverso em duas etapas:

  1. O BigQuery usa slots atribuídos ao job de pipeline para extrair e transformar dados de origem.

  2. O pipeline de ETL reverso do BigQuery usa APIs do Spanner para carregar dados em uma instância provisionada do Spanner.

O diagrama a seguir mostra as etapas em um pipeline de ETL reverso:

Um diagrama que mostra as três principais etapas quando os dados são movidos do BigQuery para o Spanner Graph em um pipeline de ETL reverso.

Figura 1. Processo de pipeline de ETL reverso do BigQuery

Gerenciar mudanças nos dados de gráficos

É possível usar o ETL reverso para:

  • Carregar um conjunto de dados de gráficos do BigQuery para o Spanner Graph.

  • Sincronize os dados do gráfico do Spanner com atualizações contínuas de um conjunto de dados no BigQuery.

Você configura um pipeline de ETL reverso com uma consulta SQL para especificar os dados de origem e a transformação a ser aplicada. O pipeline carrega todos os dados que atendem à cláusula WHERE da instrução SELECT no Spanner usando uma operação de upsert. Uma operação de upsert é equivalente a instruções INSERT OR UPDATE. Ele insere novas linhas e atualiza as linhas existentes em tabelas que armazenam dados de gráficos. O pipeline baseia linhas novas e atualizadas em uma chave primária de tabela do Spanner.

Inserir e atualizar dados para tabelas com dependências de ordem de carga

As práticas recomendadas de design de esquema do Spanner Graph recomendam o uso de tabelas intercaladas e chaves estrangeiras. Se você usar tabelas intercaladas ou chaves estrangeiras forçadas, carregue os dados de nós e arestas em uma ordem específica. Isso garante que as linhas referenciadas existam antes da criação da linha de referência. Para mais informações, consulte Criar tabelas intercaladas.

O exemplo a seguir de esquema de tabela de entrada de gráfico usa uma tabela intercalada e uma restrição de chave externa para modelar a relação entre uma pessoa e as contas dela:

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
  );

Neste exemplo de esquema, PersonOwnAccount é uma tabela intercalada em Person. Carregue elementos na tabela Person antes dos elementos na tabela PersonOwnAccount. Além disso, a restrição de chave externa em PersonOwnAccount garante que uma linha correspondente exista em Account, o destino da relação de aresta. Portanto, carregue a tabela Account antes da PersonOwnAccount. A lista a seguir resume as dependências de ordem de carregamento desse esquema:

Siga estas etapas para carregar os dados:

  1. Carregue Person antes de PersonOwnAccount.
  2. Carregue Account antes de PersonOwnAccount.

O Spanner aplica as restrições de integridade referencial no esquema de exemplo. Se o pipeline tentar criar uma linha na tabela PersonOwnAccount sem uma linha correspondente na tabela Person ou Account, o Spanner vai retornar um erro. Em seguida, o pipeline falha.

Este exemplo de pipeline de ETL reverso usa instruções EXPORTDATA no BigQuery para exportar dados das tabelas Person, Account e PersonOwnAccount em um conjunto de dados para atender às dependências de ordem de carregamento:

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;

Sincronizar dados

Para sincronizar o BigQuery com o Spanner Graph, use pipelines de ETL reversos. É possível configurar um pipeline para fazer o seguinte:

  • Aplique todas as inserções e atualizações da origem do BigQuery à tabela de destino do gráfico do Spanner. É possível adicionar elementos de esquema às tabelas de destino para comunicar exclusões de forma lógica e remover linhas de tabela de destino de acordo com uma programação.

  • Use uma função de série temporal que aplique operações de inserção e atualização e identifique operações de exclusão.

Restrições de integridade referencial

Ao contrário do Spanner, o BigQuery não impõe restrições de chave primária e estrangeira. Se os dados do BigQuery não obedecerem às restrições criadas nas tabelas do Spanner, o pipeline de ETL reverso poderá falhar ao carregar esses dados.

A ETL reversa agrupa automaticamente os dados em lotes que não excedem o limite máximo de mutação por confirmação e aplica atomicamente os lotes a uma tabela do Spanner em uma ordem arbitrária. Se um lote tiver dados que não passam em uma verificação de integridade referencial, o Spanner não vai carregar esse lote. Exemplos dessas falhas incluem uma linha filha intercalada sem uma linha mãe ou uma coluna de chave externa obrigatória sem um valor correspondente na coluna referenciada. Se um lote falhar em uma verificação, o pipeline vai falhar com um erro e parar de carregar lotes.

Entender erros de restrição de integridade referencial

Confira a seguir exemplos de erros de restrição de integridade referencial que você pode encontrar:

Resolver erros de restrição de chave externa

  • Erro: "A restrição de chave externa FK_Account foi violada na tabela PersonOwnAccount. Não foi possível encontrar os valores referenciados em Account(id)"

  • Causa: a inserção de uma linha na tabela PersonOwnAccount falhou porque uma linha correspondente na tabela Account, que a chave externa FK_Account exige, está faltando.

Resolver erros de linha principal ausente

  • Erro: "A linha principal da linha [15,1] na tabela PersonOwnAccount está ausente"

  • Causa: uma inserção de linha em PersonOwnAccount (id: 15 e account_id: 1) falhou porque uma linha principal na tabela Person (id: 15) está ausente.

Para reduzir o risco de erros de integridade referencial, considere as seguintes opções. Cada opção tem vantagens e desvantagens.

  • Reduza as restrições para permitir que o gráfico do Spanner carregue dados.
  • Adicione lógica ao pipeline para omitir linhas que violam restrições de integridade referencial.

Relaxar a integridade referencial

Uma opção para evitar erros de integridade referencial ao carregar dados é relaxar as restrições para que o Spanner não aplique a integridade referencial.

  • É possível criar tabelas intercaladas com a cláusula INTERLEAVE IN para usar as mesmas características de intercalação de linhas físicas. Se você usar INTERLEAVE IN em vez de INTERLEAVE IN PARENT, o Spanner não vai aplicar a integridade referencial, mas as consultas se beneficiarão da colocalização de tabelas relacionadas.

  • É possível criar chaves estrangeiras informativas usando a opção NOT ENFORCED. A opção NOT ENFORCED oferece benefícios de otimização de consultas. No entanto, o Spanner não impõe a integridade referencial.

Por exemplo, para criar a tabela de entrada de arestas sem verificações de integridade referencial, use esta 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;

Respeitar a integridade referencial em pipelines de ETL reverso

Para garantir que o pipeline carregue apenas as linhas que atendem às verificações de integridade referencial, inclua apenas as linhas PersonOwnAccount que têm linhas correspondentes nas tabelas Person e Account. Em seguida, preserve a ordem de carregamento para que o Spanner carregue as linhas Person e Account antes das linhas PersonOwnAccount que se referem a elas.

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;

Excluir elementos do gráfico

Os pipelines de ETL reverso usam operações de upsert. Como as operações de upsert são equivalentes a instruções INSERT OR UPDATE, um pipeline só pode sincronizar linhas que existem nos dados de origem no tempo de execução. Isso significa que o pipeline exclui as linhas excluídas. Se você excluir dados do BigQuery, um pipeline de ETL reverso não poderá remover diretamente os mesmos dados do Spanner Graph.

Use uma das seguintes opções para processar exclusões das tabelas de origem do BigQuery:

Fazer uma exclusão lógica ou reversível na origem

Para marcar logicamente as linhas para exclusão, use uma flag de exclusão no BigQuery. Em seguida, crie uma coluna na tabela de destino do Spanner para propagar a flag. Quando a ETL reversa aplica as atualizações do pipeline, exclua as linhas que têm essa flag no Spanner. É possível encontrar e excluir essas linhas explicitamente usando a DML particionada. Outra opção é excluir linhas implicitamente configurando uma coluna TTL (time to live) com uma data que depende da coluna de flag de exclusão. Escreva consultas do Spanner para excluir essas linhas excluídas logicamente. Isso garante que o Spanner exclua essas linhas dos resultados antes da exclusão programada. Depois que o pipeline de ETL reverso é executado até a conclusão, o Spanner reflete as exclusões lógicas nas linhas. Em seguida, é possível excluir linhas do BigQuery.

Este exemplo adiciona uma coluna is_deleted à tabela PersonOwnAccount no Spanner. Em seguida, ele adiciona uma coluna expired_ts_generated que depende do valor is_deleted. A política de TTL programa a exclusão das linhas afetadas porque a data na coluna gerada é anterior ao limite DELETION POLICY.

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));

Usar o histórico de alterações do BigQuery para INSERT, UPDATE e exclusões lógicas

É possível rastrear as mudanças em uma tabela do BigQuery usando o histórico de alterações dela. Use a função CHANGES do GoogleSQL para encontrar linhas que mudaram em um intervalo de tempo específico. Em seguida, use as informações da linha excluída com um pipeline de ETL reverso. É possível configurar o pipeline para definir um indicador, como uma flag de exclusão ou uma data de validade, na tabela do Spanner. Esse indicador marca as linhas para exclusão nas tabelas do Spanner.

Use os resultados da função de série temporal CHANGES para decidir quais linhas da tabela de origem incluir na carga do pipeline de ETL reverso.

O pipeline inclui linhas com _CHANGE_TYPE como INSERT ou UPDATE como upserts se a linha existir na tabela de origem. A linha atual da tabela de origem fornece os dados mais recentes.

Use linhas com _CHANGE_TYPE como DELETE que não têm linhas na tabela de origem para definir um indicador na tabela do Spanner, como uma flag de exclusão ou uma data de validade da linha.

A consulta de exportação precisa considerar a ordem das inserções e exclusões no BigQuery. Por exemplo, considere uma linha excluída no momento T1 e uma nova linha inserida em um momento posterior T2. Se ambos forem mapeados para a mesma linha da tabela do Spanner, a exportação precisará preservar os efeitos desses eventos na ordem original.

Se definido, o indicador delete marca as linhas para exclusão nas tabelas do Spanner.

Por exemplo, é possível adicionar uma coluna a uma tabela de entrada do Spanner para armazenar a data de validade de cada linha. Em seguida, crie uma política de exclusão que use essas datas de validade.

O exemplo a seguir mostra como adicionar uma coluna para armazenar as datas de validade das linhas da tabela.

ALTER TABLE PersonOwnAccount ADD COLUMN expired_ts TIMESTAMP;

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

Para usar a função CHANGES em uma tabela no BigQuery, defina a opção enable_change_history como TRUE:

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

O exemplo a seguir mostra como usar a ETL reversa para atualizar linhas novas ou alteradas e definir a data de validade das linhas marcadas para exclusão. Uma junção à esquerda com a tabela PersonOwnAccount fornece à consulta informações sobre o status atual de cada linha.

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 );

A consulta de exemplo usa um LEFT JOIN com a tabela de origem para preservar a ordem. Essa junção garante que os registros de mudança DELETE sejam ignorados para linhas excluídas e recriadas no intervalo do histórico de mudanças da consulta. O pipeline preserva a linha válida e nova.

Quando você exclui linhas, o pipeline preenche a coluna expired_ts na linha correspondente do gráfico do Spanner usando o carimbo de data/hora DELETE da coluna _CHANGE_TIMESTAMP. Uma política de exclusão de linha (política de TTL) no Spanner exclui qualquer linha em que o valor expired_ts seja mais de um dia no passado.

Para garantir a confiabilidade do sistema, coordene a programação do pipeline, a janela de retorno da mudança e a política de TTL do Spanner. Programe o pipeline para ser executado diariamente. A política de TTL do Spanner precisa ter uma duração maior que esse intervalo de execução. Isso impede que o pipeline reprocesse um evento DELETE anterior de uma linha já removida pela política de TTL do Spanner.

Este exemplo mostra o intervalo start_timestamp e end_timestamp para consultas diárias que capturam todas as mudanças na tabela do BigQuery do dia anterior em UTC. Como essa é uma consulta em lote e a função CHANGES tem limitações, o end_timestamp precisa ser pelo menos 10 minutos antes da hora atual. Portanto, agende essa consulta para ser executada pelo menos 10 minutos após a meia-noite UTC. Para mais detalhes, consulte a documentação CHANGES.

Usar colunas de TTL com o carimbo de data/hora da última vez que o dispositivo foi visto

Um pipeline de ETL reverso define uma coluna last_seen_ts com o carimbo de data/hora atual para cada linha na tabela do Spanner. Quando você exclui linhas do BigQuery, o Spanner não atualiza as linhas correspondentes, e a coluna last_seen_ts não muda. Em seguida, o Spanner remove as linhas com um last_seen_ts desatualizado usando uma política de TTL ou DML particionada, com base em um limite definido. Antes da exclusão programada, as consultas do Spanner podem filtrar linhas com um last_seen_ts mais antigo que esse limite. Essa abordagem funciona bem quando os dados do gráfico são atualizados rotineiramente e as atualizações ausentes indicam dados desatualizados para exclusão.

Fazer uma atualização completa

Antes de carregar do BigQuery, é possível excluir tabelas do Spanner para refletir as exclusões nas tabelas de origem. Isso impede que o pipeline carregue no Spanner as linhas excluídas das tabelas de origem do BigQuery durante a próxima execução do pipeline. Essa pode ser a opção mais fácil de implementar. No entanto, considere o tempo necessário para recarregar totalmente os dados do gráfico.

Manter um pipeline de ETL reverso em lote programado

Depois da execução inicial do pipeline de ETL reverso, que carrega dados em massa do BigQuery para o Spanner Graph, os dados do mundo real continuam mudando. Os conjuntos de dados mudam, e o pipeline adiciona ou remove elementos do gráfico ao longo do tempo. O pipeline descobre novos nós e adiciona novas relações de aresta, ou a inferência de IA os gera.

Para garantir que o banco de dados de gráficos do Spanner permaneça atualizado, programe e sequencie a orquestração de pipelines do BigQuery usando uma das seguintes opções:

Com os pipelines do BigQuery, é possível desenvolver, testar, controlar versões e implantar fluxos de trabalho complexos de transformação de dados SQL no BigQuery. Ele processa dependências de ordem de forma nativa, permitindo que você defina relações entre as consultas no pipeline. O Dataform cria uma árvore de dependências e executa suas consultas na ordem correta. Isso garante que as dependências upstream sejam concluídas antes do início das tarefas downstream.

Os Workflows invocados pelo Cloud Scheduler oferecem uma solução útil e flexível para orquestrar sequências de serviços doGoogle Cloud , incluindo consultas do BigQuery. Defina um fluxo de trabalho como uma série de etapas que executam um job do BigQuery. Use o Cloud Scheduler para invocar esses fluxos de trabalho em uma programação definida. Gerencie dependências usando a definição do fluxo de trabalho para especificar a ordem de execução, implementar lógica condicional, processar erros e transmitir saídas de uma consulta para outra.

Com as consultas programadas, também conhecidas como jobs de transferência do BigQuery, é possível executar instruções SQL de forma recorrente. As consultas programadas não oferecem tratamento de erros robusto nem gerenciamento dinâmico de dependências.

ETL reverso com consultas contínuas do BigQuery

Com o recurso consultas contínuas do BigQuery, é possível executar operações do BigQuery quase em tempo real. A combinação de EXPORT DATA com consultas contínuas oferece um método alternativo para executar pipelines de ETL reverso que evita jobs em lote programados.

Uma consulta contínua é uma consulta de longa duração que monitora uma tabela de origem do BigQuery em busca de novas linhas. Quando o BigQuery detecta novas linhas anexadas à tabela, ele transmite os resultados da consulta para a operação EXPORT DATA.

Essa abordagem oferece as seguintes vantagens:

  • Sincronização de dados quase em tempo real: novas linhas no BigQuery são refletidas no Spanner com atraso mínimo.

  • Redução da sobrecarga de processamento em lote: uma consulta contínua elimina a necessidade de jobs em lote periódicos, o que reduz a sobrecarga computacional.

  • Atualizações orientadas por eventos: os dados do Spanner são atualizados em resposta a mudanças reais no BigQuery.

Um pipeline de consulta contínua requer uma atribuição de reserva de slot com o job_type de CONTINUOUS. Atribua isso no nível do projeto ou da pasta ou no nível da organização.

Criar uma consulta contínua com ETL reverso do BigQuery para o Spanner

Configure o parâmetro start_timestamp da função APPENDS para iniciar o processamento de dados de onde a carga em lote parou. Essa função captura todas as linhas criadas no período específico. No exemplo a seguir, o pipeline define arbitrariamente o ponto de partida como 10 minutos antes do CURRENT_TIME. Esse carimbo de data/hora precisa estar dentro da janela de viagem no tempo do BigQuery.

Há vários métodos para iniciar um pipeline de consultas contínuas, incluindo:

  1. No BigQuery Studio, selecione Mais e escolha Consulta contínua em Escolher modo de consulta.

  2. Use a CLI bq e forneça a opção --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 )

A ordem de carregamento não é garantida

Os dados do gráfico do Spanner consistem em várias tabelas de entrada. É preciso seguir uma ordem de carregamento estrita quando as tabelas têm restrições de integridade referencial. No entanto, as consultas contínuas simultâneas não podem controlar a ordem em que o Spanner adiciona linhas. Como resultado, o carregamento de dados do Spanner Graph usando consultas contínuas é apenas para esquemas de gráficos com restrições de integridade referencial flexíveis.

Integrar com pipelines atuais

A consulta contínua complementa os jobs em lote programados atuais. Por exemplo, use consultas contínuas para atualizações quase em tempo real e jobs programados para sincronização ou conciliação completa de dados.

Use a consulta contínua do BigQuery para criar pipelines de ETL reverso responsivos e atualizados para sincronizar dados entre o BigQuery e o Spanner Graph.

Considerações sobre consultas contínuas

  • Custo: as consultas contínuas geram custos para execução contínua de consultas e streaming de dados.

  • Tratamento de erros: um pipeline de consulta contínua é cancelado se encontrar erros de banco de dados, como uma chave primária duplicada ou uma violação de integridade referencial. Se um pipeline falhar, corrija manualmente os dados na tabela de origem do BigQuery antes de reiniciar a consulta.

  • Exclusões e atualizações não processadas: a função APPENDS captura apenas inserções. Ele não captura exclusões ou atualizações.

Siga as práticas recomendadas de ETL reverso

Para ter os melhores resultados, faça o seguinte:

  • Escolha uma estratégia para evitar erros de integridade referencial ao carregar dados de edge.

  • Projete seu pipeline de dados geral para evitar arestas soltas. A integridade da estrutura do gráfico e a eficiência da consulta do Spanner Graph podem ser comprometidas por arestas pendentes. Para mais informações, consulte evitar bordas soltas.

  • Siga as recomendações de otimização de exportação do Spanner.

  • Se você estiver carregando uma grande quantidade de dados, divida o pipeline em vários pipelines menores para evitar atingir a cota padrão de seis horas de tempo de execução de consultas do BigQuery. Para mais informações, consulte Limites de jobs de consulta do BigQuery.

  • Para grandes cargas de dados, adicione índices e restrições de chave estrangeira depois que o carregamento inicial de dados em massa for concluído. Essa prática melhora o desempenho do carregamento de dados porque as restrições de chave externa exigem leituras extras para validação, e os índices exigem gravações adicionais. Essas operações aumentam o número de participantes da transação, o que pode retardar o processo de carregamento de dados.

  • Ative o escalonamento automático no Spanner para acelerar os tempos de carregamento de dados em uma instância. Em seguida, configure o parâmetro priority do Spanner na seção spanner_options do comando EXPORT DATA do BigQuery como HIGH. Para mais informações, consulte Visão geral do escalonamento automático do Spanner, Configurar exportações com a opção spanner_options e RequestOptions.priority.

  • Para grandes cargas de dados, crie pontos de divisão para pré-dividir seu banco de dados. Isso prepara o Spanner para um aumento na taxa de transferência.

  • Configure a prioridade de solicitação do Spanner para o carregamento de dados na definição do pipeline.

A seguir