Conceitos de conector de banco de dados¶

Componentes do conector¶

Os conectores do banco de dados Snowflake consistem em um Native App Snowflake, instalado a partir do Marketplace em sua conta Snowflake, e um aplicativo Agente em execução dentro de sua infraestrutura, no local ou na nuvem.

• Agentes conectam-se diretamente aos seus bancos de dados de origem, rastreiam atualizações nas tabelas que você escolheu replicar e carregam alterações em sua conta Snowflake. Os Agents exigem configuração única para conexão ao Snowflake e às fontes de dados e, posteriormente, atualização somente quando novas versões são lançadas. Além disso, ele é totalmente controlado e configurado pelo Native App.

• Native Apps controlam o processo de replicação de dados. Eles instruem os agentes sobre quais tabelas rastrear, receber alterações e mesclá-las nos bancos de dados de destino. A maior parte da interação será com o Native App. Ele é atualizado automaticamente quando uma nova versão fica disponível.

Esse modelo em que um agente é executado localmente é necessário para que o conector possa acessar com segurança bancos de dados de origem em redes fechadas para conexões externas.

Uma instância do Agent sempre se conecta a uma única instância do Native App, e um Native App sempre funciona com um Agent. Se precisar executar várias instâncias do Agent, talvez para replicar bancos de dados de origem de redes desconectadas, você precisará instalar e configurar várias instâncias do Native App. Para obter assistência, entre em contato com o suporte Snowflake.

Internamente, o conector depende de uma troca de comandos assíncrona e orientada por eventos. O Native App também deve se comunicar e coordenar com o Agent. É por isso que você pode notar um atraso entre a execução de um comando e a visualização do efeito desse comando.

Fontes de dados, tabelas, diários e destinos¶

Ao falar sobre o fluxo de dados através do conector, distinguimos os seguintes estágios:

Fonte de dados

O banco de dados com as tabelas que o conector está replicando. Dependendo do mecanismo do banco de dados, isso pode ser todo o servidor de banco de dados ou um dos bancos de dados hospedados dentro do servidor.

Uma única instância do conector pode ser replicada de várias fontes de dados, desde que o Agent possa se conectar diretamente a todas elas.

Tabela de origem

Uma tabela específica no banco de dados de origem que é rastreada pelo conector em busca de alterações que são então replicadas no Snowflake. Cada fonte de dados pode conter várias tabelas de origem que são replicadas simultaneamente pela mesma instância do conector.

O pai imediato da tabela de origem na fonte de dados se torna o esquema da tabela de destino correspondente no Snowflake.

Diário

Uma tabela Snowflake, de propriedade do Native App do conector e gerenciada por ele, que recebe e armazena todas as alterações aplicadas à tabela de origem: inserções, atualizações e exclusões. É um registro de alterações de fato dos dados da tabela de origem, e sua estrutura reflete como os mecanismos de banco de dados normalmente transmitem alterações para suas réplicas.

Cada tabela de origem tem uma tabela de diário separada.

Tabela de destino

A tabela Snowflake em sua conta na qual o conector replica dados. Há uma tabela de destino separada para cada tabela de origem. Os nomes das colunas refletem os nomes na tabela de origem, e seus tipos são tipos Snowflake correspondentes às colunas de origem.

Cada tabela de destino também inclui colunas com informações de replicação: _SNOWFLAKE_INSERTED_AT, _SNOWFLAKE_UPDATED_AT e _SNOWFLAKE_DELETED, com os carimbos de data/hora da inserção original, última atualização e exclusão da linha fornecida, respectivamente.

A tabela de destino tem o rastreamento de alterações pré-ativado para permitir a criação de fluxos. O Native App do conector mantém a concessão OWNERSHIP na tabela.

Instantâneo e carregamento incremental¶

A replicação de dados de uma tabela recém-adicionada começa com um carregamento de instantâneo. O Agent executa uma única SELECT <instrução de coluna> na tabela de origem, depois transmite todos os registros para uma tabela provisória no Snowflake e os copia para a tabela de destino. Esta operação pode exigir muitos recursos do banco de dados de origem e normalmente levará muito tempo para tabelas grandes. Talvez seja necessário esperar até que os primeiros registros apareçam na tabela de destino.

Um carregamento de instantâneo também pode ser repetido, substituindo dados replicados anteriormente, para sincronizar a tabela de origem com a de destino, nos seguintes cenários:

• Quando a replicação da tabela falha permanentemente, devido a tipos de dados incompatíveis, tamanhos, bugs no conector ou outros problemas.

• Quando a replicação foi pausada e após ser retomada, o log de alterações do banco de dados de origem não contém mais entradas desde a última vez que a tabela foi replicada.

Após a conclusão do instantâneo inicial, a replicação da tabela muda para carregamento incremental. O Agent rastreia o registro de alterações do banco de dados de origem e transmite essas alterações para a tabela de diário correspondente, de onde são posteriormente mescladas na tabela de destino. Esse ciclo de leitura, transmissão e mesclagem pode ser executado continuamente ou conforme um cronograma. Para mais informações sobre esses modos, consulte Próximos passos e Próximos passos.

Ciclo de vida de replicação de tabela¶

O ciclo de replicação de uma tabela de origem recém-adicionada começa com a introspecção de esquema. É aqui que o conector descobre as colunas na tabela de origem, seus nomes, tipos e os valida em relação às limitações do Snowflake e do conector. Falhas de validação farão com que esse estágio falhe e o ciclo seja concluído. Após a conclusão bem-sucedida da introspecção de esquema, o conector cria uma tabela de destino vazia.

O segundo estágio é o carregamento de instantâneo, onde o conector copia todos os dados disponíveis da tabela de origem para a tabela de destino. A falha neste estágio também encerrará o ciclo e nenhum outro dado será replicado. Após a conclusão bem-sucedida, todo o conjunto de dados da tabela de origem estará disponível na tabela de destino.

Por fim, a tabela passa para carregamento incremental, onde o conector continua rastreando as alterações na tabela de origem e as copiando para a tabela de destino. Isso continua até que a tabela seja removida da replicação. Uma falha neste estágio interromperá permanentemente a replicação da tabela de origem, até que o problema seja resolvido.

Para obter instruções sobre como determinar em qual fase de replicação suas tabelas estão atualmente, consulte Monitoramento do Snowflake Connector for MySQL e Monitoramento do Snowflake Connector for PostgreSQL.

Fluxo de dados da origem ao destino¶

O conector move dados de forma diferente da tabela de origem para a de destino, dependendo se está executando um instantâneo ou carregamento incremental. Para obter mais informações, consulte Instantâneo e carregamento incremental.

Replicação contínua vs. agendada¶

O modo de replicação padrão para fontes de dados recém-adicionadas é contínuo. Neste modo, o conector tem como objetivo replicar as alterações de dados o mais rápido possível. É o modo ideal para fontes de dados que mudam com frequência, onde você precisa que os dados estejam disponíveis no Snowflake em latências baixas.

É possível alterar a fonte de dados para replicar no modo agendado, onde os dados são copiados da fonte para as tabelas de destino em lotes, em um cronograma fixo. Este é o modo ideal para fontes de dados que mudam com pouca frequência ou quando você pretende reduzir o consumo de crédito e não precisa que os dados estejam disponíveis no Snowflake em latências baixas.

Ao executar a replicação contínua, o carregamento incremental nunca será relatado como “concluído”. No modo agendado, o carregamento incremental é relatado como concluído após cada lote de dados ser mesclado na tabela de destino. Um “lote” no modo agendado consiste em todas as entradas do log de alterações entre a execução agendada anterior e o momento em que a próxima execução agendada é iniciada.

Tipos de warehouse¶

Os conectores requerem dois warehouses para operar:

• Um warehouse operacional, às vezes chamado de warehouse de operações, é usado para executar as operações de comando e controle do conector. Este warehouse é criado automaticamente pelo assistente de configuração e seu tamanho ideal é XS.

• Um warehouse de computação é usado para executar tarefas de mesclagem que movem dados de diários para tabelas de destino. Este warehouse pode ser criado pelo assistente de configuração ou manualmente. Seu tamanho e tipo ideais dependem da escala de sua replicação.

A distinção acima é necessária para garantir que as consultas operacionais sejam executadas em tempo hábil, sem serem enfileiradas junto com as consultas que movimentam grandes quantidades de dados. Isso também significa que warehouse operacional não pode ser reutilizado entre instâncias do conector e não deve ser compartilhado com outras cargas de trabalho na conta.

O warehouse de computação, por sua vez, pode ser compartilhado com outras instâncias de conector e cargas de trabalho. Mas tenha em mente que compartilhar esse warehouse pode causar atrasos na exibição de dados das tabelas de destino.