Sobre Openflow Connector for Google BigQuery¶

Casos de uso¶

O conector oferece suporte aos seguintes casos de uso:

• Replicação para o Snowflake: espelhar continuamente conjuntos de dados do BigQuery no Snowflake para análise e modelagem downstream. As alterações incrementais são feitas seguindo um cronograma, com uma janela de atraso de 10 minutos.

• Replicação seletiva: definir quais regiões, conjuntos de dados, tabelas e exibições incluir usando nomes ou filtros regex para ampla cobertura com controle.

• Migração e captura de alterações: realizar um carregamento de instantâneo único para migrações e, em seguida, executar sincronizações incrementais usando o histórico de alterações do BigQuery para manter as tabelas sincronizadas.

• Replicação de exibições: replicar exibições padrão e materializadas do BigQuery para o Snowflake usando uma estratégia de truncamento e carregamento com base em um cronograma configurável.

O ciclo de vida de replicação de tabela¶

O ciclo de replicação de uma tabela começa com a descoberta do esquema e o carregamento de instantâneo inicial dos dados. O ciclo passa para a sincronização incremental depois que os dados são ingeridos no Snowflake.

1. Introspecção do esquema: o conector descobre o esquema da tabela de origem, valida seus tipos de dados e cria um esquema e uma tabela de destino correspondentes no Snowflake.

2. Carregamento de instantâneo: depois de criar o esquema e a tabela, o conector executa uma cópia completa de todos os dados existentes da tabela do BigQuery para o Snowflake. Esse processo é executado sequencialmente para cada tabela na configuração.

3. Sincronização incremental: após a conclusão do carregamento inicial, a tabela entra no modo de sincronização incremental agendado. Em cada execução, o conector usa a função CHANGES do BigQuery para ler o diário de alterações no nível da linha (inserções, atualizações, exclusões) ocorridas desde a última sincronização. Depois disso, as alterações são buscadas e mescladas na tabela de destino no Snowflake.

Requisitos do Openflow¶

O tamanho mínimo do tempo de execução deve ser Medium. Use um tempo de execução maior e uma configuração do Openflow de vários nós se estiver replicando grandes volumes de dados.

Limitações¶

• O BigQuery garante que os fluxos de dados usados para buscar os dados de origem permaneçam válidos por pelo menos 6 horas. Como resultado, o processo de leitura da tabela de origem deve ser concluído em menos de 6 horas para impedir que os fluxos de dados expirem. Você deve usar um tempo de execução maior e de vários nós ao ingerir tabelas com volumes de dados com mais de 100GB.

• O tipo BIGNUMERIC do BigQuery oferece suporte a uma precisão maior (até 76 dígitos) do que o tipo NUMBER do Snowflake (38 dígitos). O conector não pode ingerir valores de colunas BIGNUMERIC que excedem o limite do Snowflake.

• O conector não oferece suporte à replicação de tabelas externas.

• A replicação de exibições usa apenas uma estratégia de truncamento e carregamento. A sincronização incremental (CDC) não é compatível com as exibições.

• As sincronizações incrementais exigem uma chave primária para processar corretamente as atualizações e exclusões. Para tabelas sem uma chave primária, o conector não oferece suporte a exclusões e trata as atualizações como novas inserções.

  Nota

  Você deve garantir que as restrições de chave primária sejam atendidas. Se o campo marcado como chave primária não for exclusivo, poderá ocorrer uma inconsistência de dados durante o modo incremental.

• O conector usa a função CHANGES do BigQuery para atualizações incrementais. Como essa função não pode consultar os últimos dez minutos do histórico da tabela, os dados replicados no modo incremental têm um atraso mínimo de 10 minutos em relação à origem.

• O processo de sincronização incremental é limitado a uma janela de dados máxima de 24 horas devido à função CHANGES do BigQuery. Se o atraso da replicação de uma tabela exceder esse período, o conector truncará a janela de alteração para 24 horas para prosseguir com a sincronização. Esse truncamento pode resultar em perda de dados.

• O conector herda todas as outras limitações da função CHANGES do BigQuery. Para obter mais informações, consulte a documentação sobre a função CHANGES do BigQuery.

Replicação de exibições¶

O conector oferece suporte à replicação de exibições padrão e materializadas do BigQuery para o Snowflake. Ao contrário da replicação de tabelas, as exibições não oferecem suporte à sincronização incremental (CDC). Em vez disso, o conector usa uma estratégia de truncamento e carregamento: em cada ciclo de sincronização, o conector substitui totalmente os dados na tabela de destino do Snowflake pelo conteúdo atual da exibição de origem.

A frequência de sincronização da exibição é configurada separadamente da frequência de sincronização incremental da tabela usando o parâmetro View Sync Frequency. As execuções não se sobrepõem. Se um ciclo levar mais tempo do que o intervalo configurado, a próxima execução aguardará o término da execução anterior.

É possível filtrar quais exibições replicar usando os parâmetros Included View Names e Included View Names Regex. Esses filtros são aplicados a todos os conjuntos de dados selecionados para replicação.

O conector cria tabelas temporárias no BigQuery durante a ingestão das exibições. Use o parâmetro Temporary Table Dataset para especificar um conjunto de dados dedicado para as tabelas temporárias. A Snowflake recomenda usar um conjunto de dados separado para tabelas temporárias, e não o conjunto de dados ingerido para essa finalidade.

Mapeamentos de tipos de dados¶

O conector mapeia os tipos de dados do BigQuery para os tipos de dados correspondentes do Snowflake.

Rastrear as alterações de dados no Google BigQuery¶

A funcionalidade de sincronização incremental do conector foi desenvolvida com base na função CHANGES nativa do BigQuery. Quando você habilita o histórico de alterações em uma tabela de origem, o BigQuery mantém um diário interno de todas as modificações no nível da linha (inserções, atualizações e exclusões).

O conector consulta esse diário conforme um cronograma de frequência de sincronização incremental configurado para recuperar um feed de alterações. O conector materializa as alterações em uma tabela de diário no mesmo conjunto de dados do BigQuery. Essa tabela de diário segue uma convenção de nomenclatura consistente: <sourceTableName>_<incremental_number>_<hash>_journal

As tabelas de diário são gerenciadas inteiramente pelo conector durante o processo de replicação e usadas para mesclar os dados na tabela de destino final no Snowflake.

A operação de mesclagem processa as alterações de forma diferente para tabelas com e sem uma chave primária (Primary Key, PK).

Evolução de esquema¶

O conector oferece suporte a várias alterações de esquema comuns na tabela de origem do BigQuery. As seguintes alterações no esquema são detectadas e propagadas para a tabela de destino do Snowflake:

Adição de colunas:

Novas colunas adicionadas ao BigQuery são automaticamente adicionadas à tabela correspondente do Snowflake.

Exclusão de colunas (exclusão lógica):

Quando uma coluna é descartada no BigQuery, o conector realiza uma «exclusão lógica» no Snowflake. A coluna não é descartada da tabela de destino. Em vez disso, ela é renomeada adicionando o sufixo _SNOWFLAKE_DELETED ao fim do nome da coluna. Por exemplo, my_column passa a ser my_column_SNOWFLAKE_DELETED. Isso preserva os dados históricos no Snowflake.

Renomeação de colunas:

Uma operação de renomeação de coluna é um processo de duas etapas:

1. A coluna original é «excluída logicamente» e renomeada com o sufixo _SNOWFLAKE_DELETED adicionado.

2. Outra coluna com o novo nome é adicionada à tabela do Snowflake.

Modificação da chave primária:

É permitido adicionar, remover e alterar chaves primárias.

Mudanças de tipos de dados:

Somente as alterações que ampliam o tipo existente são toleradas. Qualquer alteração que restrinja o tipo de uma coluna ou o converta em um tipo incompatível não é compatível e causará falha na replicação da tabela.

Próximos passos¶

Para obter informações sobre como configurar o conector, consulte o seguinte tópico:

• Configurando o Openflow Connector for Google BigQuery