Replicação do banco de dados usando a captura de dados alterados

Last reviewed 2020-10-20 UTC

Este documento descreve várias abordagens sobre o uso da captura de dados de alterações (CDC, na sigla em inglês) para integrar várias fontes de dados ao BigQuery. Neste documento, fornecemos uma análise das compensações entre a consistência de dados, a facilidade de uso e os custos para cada uma das abordagens. Com este documento, você entenderá as soluções existentes, aprenderá sobre diferentes abordagens para consumir dados replicados pelo CDC e poderá criar uma análise custo-benefício das abordagens.

Este documento destina-se a ajudar arquitetos de dados, engenheiros de dados e analistas de negócios a desenvolver uma abordagem ideal para acessar dados replicados no BigQuery. O documento pressupõe que você esteja familiarizado com o BigQuery, o SQL e as ferramentas de linha de comando.

Visão geral da replicação de dados do CDC

Bancos de dados como MySQL, Oracle e SAP são as fontes de dados CDC mais discutidas. No entanto, qualquer sistema poderá ser considerado uma fonte de dados se capturar e fornecer alterações em elementos de dados identificados por chaves primárias. Caso um sistema não forneça um processo de CDC integrado, como um registro de transação, é possível implantar um leitor de lote incremental para conseguir alterações.

Este documento discute processos CDC que atendem aos seguintes critérios:

1. A replicação de dados captura as alterações para cada tabela separadamente.
2. Toda tabela tem uma chave primária ou uma chave primária composta.
3. Cada evento CDC emitido recebe um código de mudança monotonicamente crescente, geralmente um valor numérico, como um código de transação ou um carimbo de data/hora.
4. Cada evento de CDC contém o estado completo da linha que mudou.

No diagrama a seguir, mostramos uma arquitetura genérica usando CDC para replicar fontes de dados no BigQuery:

No diagrama anterior, uma tabela principal e uma tabela delta são criadas no BigQuery para cada tabela de dados de origem. A tabela principal contém todas as colunas da tabela de origem, além de uma coluna para o valor mais recente do código de alteração. Você pode considerar o valor do código da alteração mais recente como o código da versão da entidade identificada pela chave primária do registro e usá-lo para encontrar a versão mais recente.

A tabela delta contém todas as colunas da tabela de origem, além de uma coluna de tipo de operação (uma de atualização, inserção ou exclusão) e o valor do código da mudança.

Veja a seguir o processo geral para replicar dados no BigQuery usando o CDC:

1. Extrai-se um despejo de dados inicial de uma tabela de origem.
2. Os dados extraídos são, opcionalmente, transformados e carregados na tabela principal correspondente. Se a tabela não tiver uma coluna que possa ser usada como um código de alteração, como um carimbo de data/hora da última atualização, o código de alteração será definido com o menor valor possível para o tipo de dados da coluna. Dessa forma, o processamento subsequente identifica os registros da tabela principal que foram atualizados após o despejo de dados inicial.
3. As linhas que mudam após o despejo inicial de dados são capturadas pelo processo de captura do CDC.
4. Se necessário, a transformação de dados é realizada pela camada de processamento do CDC. Por exemplo, a camada de processamento de CDC pode reformatar o carimbo de data/hora para ser usado pelo BigQuery, dividir colunas verticalmente ou remover colunas.
5. Os dados são inseridos na tabela delta correspondente no BigQuery, usando inserções em microlote ou inserções de streaming.

Se forem realizadas mais transformações antes da inserção dos dados no BigQuery, o número e o tipo de colunas poderão ser diferentes da tabela de origem. No entanto, o mesmo conjunto de colunas existe nas tabelas principal e delta.

As tabelas delta contêm todos os eventos de alteração de uma tabela específica desde o carregamento inicial. Ter todos os eventos de mudança disponíveis pode ser valioso para identificar tendências, o estado das entidades que uma tabela representa em um momento específico ou a frequência de alteração.

Para ver o estado atual de uma entidade representada por uma chave primária específica, consulte a tabela principal e a tabela delta do registro que tem o código de alteração mais recente. Essa consulta pode ser onerosa porque pode ser necessário executar uma junção entre as tabelas principal e delta e concluir uma verificação completa de uma ou ambas para encontrar a entrada mais recente de uma determinada chave primária. para criar um anexo da VLAN de monitoramento. É possível evitar a verificação completa da tabela por meio do clustering ou particionamento das tabelas com base na chave primária, mas não é sempre possível.

Este documento compara as seguintes abordagens genéricas que podem ajudar você a saber o estado atual de uma entidade quando não é possível particionar ou agrupar as tabelas:

• Abordagem de consistência imediata: as consultas refletem o estado atual dos dados replicados. A consistência imediata requer uma consulta que une a tabela principal e a tabela delta e seleciona a linha mais recente para cada chave primária.
• Abordagem otimizada para custos: consultas mais rápidas e mais baratas são executadas à custa de alguns atrasos na disponibilidade de dados. É possível mesclar os dados periodicamente na tabela principal.
• Abordagem híbrida: você usa a abordagem de consistência imediata ou a abordagem de custo otimizado, dependendo dos seus requisitos e do orçamento.

Neste documento, discutimos outras maneiras de melhorar o desempenho, além dessas abordagens.

Antes de começar

Neste documento, você saberá como usar a ferramenta de linha de comando bq e as instruções SQL para visualizar e consultar dados do BigQuery. Layouts de tabela e consultas de exemplo são mostrados mais adiante neste documento. Se você quiser testar dados de amostra, conclua a seguinte configuração:

1. Selecione um projeto ou crie um projeto e ative o faturamento dele.
   • Se você criar um projeto, o BigQuery será ativado automaticamente.
   • Se você selecionar um projeto existente, ative a API do BigQuery.
2. No Console do Google Cloud, abra o Cloud Shell.

3. Para atualizar seu arquivo de configuração do BigQuery, abra o arquivo ~/.bigqueryrc em um editor de texto e adicione ou atualize as seguintes linhas em qualquer lugar no arquivo:

   [query]
   --use_legacy_sql=false
   
   [mk]
   --use_legacy_sql=false
   

4. Clone o repositório do GitHub que contém os scripts para configurar o ambiente do BigQuery:

   git clone https://github.com/GoogleCloudPlatform/bq-mirroring-cdc.git
   

5. Crie as tabelas de conjunto de dados, principal e delta:

   cd bq-mirroring-cdc/tutorial
   chmod +x *.sh
   ./create-tables.sh
   

Para evitar possíveis cobranças quando terminar os testes, encerre o projeto ou exclua o conjunto de dados.

Configurar dados do BigQuery

Para demonstrar diferentes soluções de replicação de dados CDC para o BigQuery, use um par de tabelas principais e delta que são preenchidas com dados de amostra, como as simples tabelas de exemplo.

Para trabalhar com uma configuração mais sofisticada do que o descrito neste documento, use a demonstração de integração do CDC do BigQuery. A demonstração automatiza o processo de preenchimento de tabelas e inclui scripts para monitorar o processo de replicação. Se você quiser executar a demonstração, siga as instruções no arquivo README que está na raiz do repositório do GitHub que você clonou na seção Antes de começar deste documento.

Os dados de exemplo usam um modelo de dados simples: uma sessão da Web que contém um código de sessão obrigatório gerado pelo sistema e um nome de usuário opcional. Quando a sessão é iniciada, o nome do usuário é nulo. Depois que o usuário fizer login, o nome de usuário será preenchido.

Para carregar dados na tabela principal dos scripts do ambiente do BigQuery, execute um comando como este:

bq load cdc_tutorial.session_main init.csv

Para ver o conteúdo da tabela principal, execute uma consulta como esta:

bq query "select * from cdc_tutorial.session_main limit 1000"

A saída será assim:

+-----+----------+-----------+
| id  | username | change_id |
+-----+----------+-----------+
| 100 | NULL     |         1 |
| 101 | Sam      |         2 |
| 102 | Jamie    |         3 |
+-----+----------+-----------+

Em seguida, carregue o primeiro lote de alterações da CDC na tabela delta. Para carregar o primeiro lote de alterações de CDC na tabela delta dos scripts de ambiente do BigQuery, execute um comando como este:

bq load cdc_tutorial.session_delta first-batch.csv

Para ver o conteúdo da tabela delta, é possível executar uma consulta como a seguinte:

bq query "select * from cdc_tutorial.session_delta limit 1000"

A saída será assim:

+-----+----------+-----------+-------------+
| id  | username | change_id | change_type |
+-----+----------+-----------+-------------+
| 100 | Cory     |         4 | U           |
| 101 | Sam      |         5 | D           |
| 103 | NULL     |         6 | I           |
| 104 | Jamie    |         7 | I           |
+-----+----------+-----------+-------------+

Na saída anterior, o valor de change_id é o código exclusivo de uma alteração de linha da tabela. Os valores na coluna change_type representam o seguinte:

• U: operações de atualização
• D: excluir operações
• I: inserir operações

A tabela principal contém informações sobre as sessões 100, 101 e 102. A tabela delta tem as seguintes alterações:

• A sessão 100 é atualizada com o nome de usuário "Cory".
• A sessão 101 foi excluída.
• Novas sessões 103 e 104 são criadas.

O estado atual das sessões no sistema de origem é o seguinte:

+-----+----------+
| id  | username |
+-----+----------+
| 100 | Cory     |
| 102 | Jamie    |
| 103 | NULL     |
| 104 | Jamie    |
+-----+----------+

Embora o estado atual seja exibido como uma tabela, esta tabela não existe em formato materializada. Essa tabela é a combinação da tabela principal com a delta.

Consultar dados

Há várias abordagens que podem ser usadas para determinar o estado geral das sessões. As vantagens e desvantagens de cada abordagem são descritas nas seções a seguir.

Abordagem de consistência imediata

Se a consistência imediata de dados for seu objetivo principal e os dados de origem forem alterados com frequência, você poderá usar uma única consulta que una as tabelas principal e delta e selecionar a linha mais recente (a linha com o carimbo de data/hora mais recente ou maior valor numérico).

Para criar uma visualização do BigQuery que mescle as tabelas principal e delta e encontre a linha mais recente, execute um comando da ferramenta bq como o seguinte:

bq mk --view \
"SELECT * EXCEPT(change_type, row_num)
FROM (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY change_id DESC) AS row_num
  FROM (
    SELECT * EXCEPT(change_type), change_type
    FROM \`$(gcloud config get-value project).cdc_tutorial.session_delta\` UNION ALL
    SELECT *, 'I'
    FROM \`$(gcloud config get-value project).cdc_tutorial.session_main\`))
WHERE
  row_num = 1
  AND change_type <> 'D'" \
 cdc_tutorial.session_latest_v

A instrução SQL na visualização anterior do BigQuery tem as seguintes funções:

• A UNION ALL mais interna produz as linhas das tabelas principal e delta:
  • SELECT * EXCEPT(change_type), change_type FROM session_delta força a coluna change_type a ser a última coluna na lista.
  • SELECT *, 'I' FROM session_main seleciona a linha da tabela principal como se ela fosse uma linha de inserção.
  • Usar o operador * simplifica o exemplo. Se houver colunas adicionais ou uma ordem de coluna diferente, substitua o atalho por listas de colunas explícitas.
• SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY change_id DESC) AS row_num usa uma função analítica no BigQuery para atribuir números de linha sequenciais que começam com 1 para cada um dos grupos de linhas que têm o mesmo valor de id, definido por PARTITION BY. As linhas são ordenadas por change_id em ordem decrescente dentro desse grupo. Como change_id tem a garantia de aumentar, a alteração mais recente tem uma coluna row_num com valor 1.
• WHERE row_num = 1 AND change_type <> 'D' seleciona apenas a linha mais recente de cada grupo. Essa é uma técnica comum de eliminação de duplicação no BigQuery. Essa cláusula também removerá a linha do resultado se o tipo de alteração for excluído.
• A SELECT * EXCEPT(change_type, row_num) superior remove as colunas extras que foram introduzidas no processamento e que não são relevantes de outra forma.

O exemplo anterior não usa os tipos de alteração insert e update na visualização porque referenciar o valor change_id mais alto seleciona a inserção original ou a atualização mais recente. Nesse caso, cada linha contém os dados completos de todas as colunas.

Depois de criar a visualização, execute consultas nela. Para ver as alterações mais recentes, execute uma consulta como a seguinte:

bq query 'select * from cdc_tutorial.session_latest_v order by id limit 10'

A saída será assim:

+-----+----------+-----------+
| id  | username | change_id |
+-----+----------+-----------+
| 100 | Cory     |         4 |
| 102 | Jamie    |         3 |
| 103 | NULL     |         6 |
| 104 | Jamie    |         7 |
+-----+----------+-----------+

Ao consultar a visualização, os dados na tabela delta ficam imediatamente visíveis se você os tiver atualizado na tabela delta usando uma instrução de linguagem de manipulação de dados (DML) ou quase imediatamente se você transmitiu dados.

Abordagem otimizada para custos

A abordagem de consistência imediata é simples, mas pode ser ineficiente, pois exige que o BigQuery leia todos os registros históricos, classifique por chave primária e processe as outras operações na consulta para implementar a visualização. Se você consulta com frequência o estado da sessão, a abordagem de consistência imediata pode diminuir o desempenho e aumentar os custos de armazenamento e processamento de dados no BigQuery.

Para minimizar os custos, você pode mesclar as alterações da tabela delta na tabela principal e limpar periodicamente as linhas mescladas da tabela delta. Há custo adicional para mesclagem e limpeza, mas se você consultar com frequência a tabela principal, o custo será insignificante em comparação com o custo de encontrar continuamente o registro mais recente de uma chave na tabela delta.

Para mesclar dados da tabela delta na tabela principal, é possível executar uma instrução MERGE como a seguinte:

bq query \
'MERGE `cdc_tutorial.session_main` m
USING
  (
  SELECT * EXCEPT(row_num)
  FROM (
    SELECT *, ROW_NUMBER() OVER(PARTITION BY delta.id ORDER BY delta.change_id DESC) AS row_num
    FROM `cdc_tutorial.session_delta` delta )
  WHERE row_num = 1) d
ON  m.id = d.id
  WHEN NOT MATCHED
AND change_type IN ("I", "U") THEN
INSERT (id, username, change_id)
VALUES (d.id, d.username, d.change_id)
  WHEN MATCHED
  AND d.change_type = "D" THEN
DELETE
  WHEN MATCHED
  AND d.change_type = "U"
  AND (m.change_id < d.change_id) THEN
UPDATE
SET username = d.username, change_id = d.change_id'

A instrução MERGE anterior afetou quatro linhas e a tabela principal tem o estado atual das sessões. Para consultar a tabela principal nessa visualização, é possível executar uma consulta como a seguinte:

  bq query 'select * from cdc_tutorial.session_main order by id limit 10'

A saída será assim:

+-----+----------+-----------+
| id  | username | change_id |
+-----+----------+-----------+
| 100 | Cory     |         4 |
| 102 | Jamie    |         3 |
| 103 | NULL     |         6 |
| 104 | Jamie    |         7 |
+-----+----------+-----------+

Os dados na tabela principal refletem os estados das sessões mais recentes.

A melhor maneira de mesclar dados com frequência e consistência é usar uma instrução MERGE, que permite combinar várias instruções INSERT, UPDATE e DELETE em uma única operação atômica. Veja a seguir algumas das nuances da instrução MERGE anterior:

• A tabela session_main é mesclada com a fonte de dados especificada na cláusula USING, uma subconsulta neste caso.
• A subconsulta usa a mesma técnica da visualização na abordagem de consistência imediata: seleciona a linha mais recente no grupo de registros que tem o mesmo valor id: uma combinação de ROW_NUMBER() OVER(PARTITION BY id ORDER BY change_id DESC) row_num e WHERE row_num = 1.
• A mesclagem é realizada nas colunas id das duas tabelas, que é a chave primária.
• A cláusula WHEN NOT MATCHED verifica se há correspondência. Se não houver correspondência, a consulta verificará se o registro mais recente é inserir ou atualizar e, em seguida, insere o registro.
  • Quando o registro é correspondido e o tipo de alteração é excluído, o registro é excluído na tabela principal.
  • Quando o registro é correspondido, o tipo de alteração é atualizado e o valor change_id da tabela delta é maior que o valor de change_id do registro principal, os dados são atualizados, incluindo o mais recente change_id.

A instrução MERGE anterior funciona corretamente para qualquer combinação das seguintes alterações:

• Várias linhas de atualização para a mesma chave primária: somente a atualização mais recente será aplicada.

• Atualizações sem correspondência na tabela principal: se a tabela principal não tiver o registro na chave primária, um novo registro será inserido.

  Essa abordagem ignora a extração da tabela principal e começa com a tabela delta. A tabela principal é preenchida automaticamente.

• Inserir e atualizar linhas no lote delta não processado. A linha de atualização mais recente é usada e um novo registro é inserido na tabela principal.

• Insira e exclua linhas no lote não processado. O registro não é inserido.

A instrução MERGE anterior é idempotente: executá-la várias vezes resulta no mesmo estado da tabela principal e não causa efeitos colaterais. Se você executar novamente a instrução MERGE sem adicionar novas linhas à tabela delta, a saída será semelhante a esta:

Number of affected rows: 0

É possível executar a instrução MERGE em um intervalo regular para atualizar a tabela principal após cada mesclagem. A atualidade dos dados na tabela principal depende da frequência das mesclagens. Para informações sobre como executar a instrução MERGE automaticamente, consulte a seção "Como programar mesclagens" no arquivo de demonstração README salvo anteriormente.

Abordagem híbrida.

A abordagem de consistência imediata e a abordagem com otimização de custos não são mutuamente exclusivas. Se você executar consultas na visualização session_latest_v e na tabela session_main, ela retornará os mesmos resultados. É possível selecionar a abordagem a ser usada dependendo dos seus requisitos e do seu orçamento: maior custo e quase consistência imediata ou menor custo, mas dados possivelmente desatualizados. As seções a seguir discutem como comparar abordagens e possíveis alternativas.

Comparar abordagens

Nesta seção, descrevemos como comparar abordagens considerando o custo e o desempenho de cada solução, além do equilíbrio da latência de dados aceitável e o custo da execução de mesclagens.

Custo das consultas

Para avaliar o custo e o desempenho de cada solução, o exemplo a seguir fornece uma análise de aproximadamente 500.000 sessões geradas pela demonstração de integração do BigQuery do CDC. O modelo da sessão na demonstração é um pouco mais complexo que o modelo introduzido anteriormente neste documento e é implantado em um conjunto de dados diferente, ainda que os conceitos sejam os mesmos.

Para comparar o custo das consultas, use uma consulta de agregação simples. O exemplo de consulta a seguir testa a abordagem de consistência imediata em relação à visualização que combina os dados delta com a tabela principal:

SELECT status, count(*) FROM `cdc_demo.session_latest_v`
GROUP BY status ORDER BY status

A consulta resultará no seguinte custo:

Slot time consumed: 15.115 sec, Bytes shuffled 80.66 MB

A consulta de exemplo a seguir testa a abordagem de custo otimizado em relação à tabela principal:

SELECT status, count(*) FROM `cdc_demo.session_main`
GROUP BY status ORDER BY status

A consulta resultará no custo mais baixo a seguir:

Slot time consumed: 1.118 sec, Bytes shuffled 609 B

O consumo de tempo de slot pode variar quando você executa as mesmas consultas várias vezes, mas as médias são bastante consistentes. O valor de Bytes shuffled é consistente entre diferentes execuções.

Os resultados do teste de desempenho variam de acordo com os tipos de consultas e o layout da tabela. A demonstração anterior não usa clustering ou particionamento de dados.

Latência de dados

Quando você usa a abordagem otimizada para custos, a latência dos dados é a soma dos seguintes itens:

• Atraso do gatilho de replicação de dados. Esse é o período entre o momento em que os dados são mantidos durante o evento de origem e o momento em que o sistema de replicação aciona o processo de replicação.
• Tempo para inserir os dados no BigQuery (varia de acordo com a solução de replicação).
• Tempo para que os dados do buffer de streaming do BigQuery apareçam na tabela delta. Se você usa inserções de streaming, isso geralmente é de alguns segundos.
• Atraso entre as execuções de mesclagem
• Tempo para executar a mesclagem.

Quando você usa a abordagem de consistência imediata, a latência dos dados é a soma dos seguintes itens:

• Atraso do gatilho de replicação de dados.
• Tempo para inserir os dados no BigQuery.
• Tempo para que os dados do buffer de streaming bigQuery apareçam na tabela delta.

É possível configurar o atraso entre as execuções de mesclagem, dependendo da compensação entre os custos de mesclagem e a necessidade de consistência dos dados. Se necessário, use um esquema mais complexo, como mesclagens frequentes que são realizadas durante o horário comercial e mesclagens por hora durante as horas fora do horário comercial.

Alternativas a considerar

A abordagem de consistência imediata e a abordagem com otimização de custos são as opções de CDC mais genéricas para integrar várias fontes de dados com o BigQuery. Nesta seção, descrevemos as opções de integração de dados mais simples e mais baratas.

Tabela delta como fonte única da verdade

Se a tabela delta tiver o histórico completo das alterações, será possível criar uma visualização apenas para a tabela delta e não usar a tabela principal. Usar uma tabela delta como a única fonte da verdade é um exemplo de um banco de dados de eventos. Essa abordagem oferece consistência instantânea a baixo custo e pouco impacto no desempenho. Considere essa abordagem se você tem uma tabela de dimensões que muda lentamente com um número pequeno de registros.

Despejo total de dados sem CDC

Se você tiver tabelas de tamanho gerenciável (por exemplo, menos de 1 GB), talvez seja mais fácil realizar uma captura de dados completa na seguinte sequência:

1. Importe o despejo de dados inicial para uma tabela com um nome exclusivo.
2. Crie uma visualização que só faça referência à nova tabela.
3. Execute consultas na visualização, não na tabela subjacente.
4. Importe o próximo despejo de dados para outra tabela.
5. Recrie a visualização para apontar para os dados recém-enviados.
6. Opcionalmente, exclua a tabela original.
7. Repita as etapas anteriores para importar, recriar e excluir regularmente.

Preservação do histórico de alterações na tabela principal

Na abordagem otimizada para custos, o histórico de alterações não é preservado, e a alteração mais recente substitui os dados anteriores. Caso precise manter o histórico, armazene-o usando uma matriz de alterações, empregando o cuidado para não exceder o limite máximo de tamanho da linha. Quando você preserva o histórico de alterações na tabela principal, a DML de mesclagem é mais complexa, porque uma única operação MERGE pode mesclar várias linhas da tabela delta em uma única linha na tabela principal.

Usar fontes de dados federadas

Em alguns casos, é possível replicar para uma fonte de dados diferente do BigQuery e, em seguida, expor essa fonte usando uma consulta federada. O BigQuery é compatível com várias fontes de dados externas. Por exemplo, se você replicar um esquema semelhante a uma estrela de um banco de dados MySQL, poderá replicar as dimensões que mudam lentamente para uma versão somente leitura do MySQL usando a replicação MySQL nativa. Ao usar esse método, você apenas replica a tabela de fatos que muda com frequência no BigQuery. Se você quiser usar origens de dados federadas, observe que há várias limitações para consultar fontes federadas.

Melhorar ainda mais o desempenho

Nesta seção, discutimos como melhorar ainda mais o desempenho ao agrupar e particionar as tabelas e remover os dados mesclados.

Agrupar e particionar tabelas do BigQuery

Se você tiver um conjunto de dados consultado com frequência, analise o uso de cada tabela e ajuste o design da tabela usando clustering e particionamento. O clustering de uma ou ambas as tabelas principal e delta por chave primária pode resultar em um melhor desempenho em comparação com outras abordagens. Para verificar o desempenho, teste as consultas em um conjunto de dados com pelo menos 10 GB.

Remover dados mesclados

A tabela delta cresce com o tempo, e cada solicitação de mesclagem desperdiça recursos lendo um número de linhas que você não precisa para o resultado final. Se você usar apenas os dados da tabela delta para calcular o estado mais recente, a remoção de registros mesclados poderá reduzir o custo da mesclagem e diminuir o custo geral, reduzindo a quantidade de dados armazenados no BigQuery.

É possível remover dados mesclados das seguintes maneiras:

• Consulte periodicamente a tabela principal para ver o valor máximo change_id e exclua todos os registros delta que tenham um valor change_id menor que esse máximo. Se você estiver fazendo streaming de inserções na tabela delta, elas não serão excluídas por algum período.
• Use o particionamento baseado em ingestão das tabelas delta e execute um script diário para descartar as partições que já foram processadas. Quando o particionamento do BigQuery mais granular estiver disponível, será possível aumentar a frequência de limpeza. Para informações sobre a implementação, consulte a seção "Como limpar dados processados" no arquivo de demonstração README que você fez o download anteriormente.

Conclusões

Para selecionar a abordagem certa, ou várias abordagens, considere os casos de uso que você está tentando resolver. É possível resolver as necessidades de replicação de dados usando as tecnologias de migração de banco de dados existentes. Em caso de necessidades complexas, por exemplo, se precisar resolver um caso de uso de dados quase em tempo real e otimizar custos do restante do padrão de acesso a dados, talvez seja necessário configurar uma frequência de migração do banco de dados personalizada com base em outros produtos ou soluções de código aberto. As abordagens e técnicas descritas neste documento podem ajudar na implementação dessa solução.

A seguir

• Consulte Migrar pipelines de dados.
• Leia sobre Como projetar a arquitetura de ETL para um data warehouse nativo da nuvem no Google Cloud.
• Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.