Esta página descreve as práticas recomendadas para exemplos de utilização em que:
- Os utilizadores têm uma tabela existente no BigQuery e precisam de replicar os respetivos dados através da captura de dados de alterações (CDC) na mesma tabela do BigQuery.
- Os utilizadores têm de copiar dados para uma tabela do BigQuery existente sem usar a capacidade de preenchimento de dados do fluxo de dados, quer devido ao tempo que demoraria, quer devido a limitações do produto.
Problema
Uma tabela do BigQuery preenchida através da API BigQuery Storage Write não permite operações regulares de linguagem de manipulação de dados (DML). Isto significa que, assim que um fluxo de CDC começar a escrever numa tabela do BigQuery, não é possível adicionar dados do histórico que ainda não tenham sido pré-preenchidos na tabela.
Considere o seguinte cenário:
- TIMESTAMP 1: a operação de cópia da tabela é iniciada.
- TIMESTAMP 2: enquanto a tabela está a ser copiada, as operações DML na origem resultam em alterações aos dados (são adicionadas, atualizadas ou removidas linhas).
- TIMESTAMP 3: o CDC é iniciado, as alterações ocorridas em TIMESTAMP 2 não são capturadas, o que resulta numa discrepância de dados.
Solução
Para garantir a integridade dos dados, o processo de CDC tem de captar todas as alterações na origem que ocorreram a partir do momento imediatamente após a última atualização feita que foi copiada para a tabela do BigQuery.
A solução que se segue permite-lhe garantir que o processo de CDC capta todas as alterações a partir de TIMESTAMP 2, sem bloquear a operação de cópia de escrita de dados na tabela do BigQuery.
Pré-requisitos
- A tabela de destino no BigQuery tem de ter exatamente o mesmo esquema e configuração como se tivesse sido criada pelo Datastream. Pode usar o Datastream BigQuery Migration Toolkit para o fazer.
- Para origens MySQL e Oracle, o utilizador tem de conseguir identificar a posição do registo no momento em que a operação de cópia é iniciada.
- A base de dados tem de ter armazenamento suficiente e uma política de retenção de registos para permitir a conclusão do processo de cópia da tabela.
Origens do MySQL e Oracle
- Crie, mas não inicie a stream que pretende usar para a replicação de CDC contínua. A stream tem de estar no estado CREATED.
- Quando tiver tudo pronto para iniciar a operação de cópia da tabela, identifique a posição atual do registo da base de dados:
- Para o MySQL, consulte a documentação do MySQL para saber como obter as coordenadas do registo binário de replicação. Depois de identificar a posição do registo, feche a sessão para libertar todos os bloqueios na base de dados.
- Para o Oracle, execute a seguinte consulta:
SELECT current_scn FROM V$DATABASE
- Copie a tabela da base de dados de origem para o BigQuery.
- Assim que a operação de cópia estiver concluída, siga os passos descritos na página Gerir streams para iniciar a stream a partir da posição do registo que identificou anteriormente.
Origens do PostgreSQL
- Quando estiver tudo a postos para começar a copiar a tabela, crie o espaço de replicação. Para mais informações, consulte o artigo Configure uma base de dados PostgreSQL de origem.
- Copie a tabela da base de dados de origem para o BigQuery.
- Quando a operação de cópia estiver concluída, crie e inicie a stream.