Como Migrar do Redshift para o BigQuery: Guia Completo

Migrar um data warehouse do Amazon Redshift para o Google BigQuery são, na prática, três trabalhos separados: copiar os dados, traduzir o SQL e reconstruir os pipelines que alimentam o warehouse. Nenhuma ferramenta sozinha resolve bem as três coisas, então a resposta honesta para "qual ferramenta usar" depende de qual desses trabalhos você está olhando. Este guia cobre as opções documentadas para cada um, com requisitos de configuração, limites e preços.

Qual ferramenta devemos usar para migrar do Redshift para o BigQuery?

O BigQuery Data Transfer Service do Google cuida da movimentação em si. Ele copia schema e dados de um cluster Redshift direto para o BigQuery, e o Google não cobra nada por isso. Uma ferramenta de replicação como o Airbyte ajuda quando você precisa manter Redshift e BigQuery atualizados em paralelo durante um período de dual-run.

Isso resolve a parte dos dados. Para o SQL, o BigQuery Migration Service inclui tradutores em batch e interativos que convertem SQL do Redshift para GoogleSQL, também sem custo.

O terceiro trabalho é fácil de esquecer: todo pipeline que carregava dados no Redshift precisa de um novo destino. Uma plataforma ELT como a Erathos move dados das suas fontes para o BigQuery com pipelines em batch, incremental por cursor ou change data capture (CDC), permitindo reconstruir a ingestão sem escrever código de pipeline novo.

Como funciona o serviço de transferência do Redshift do Google?

O BigQuery Data Transfer Service roda agentes de migração que disparam um unload do seu cluster Redshift para um bucket de staging no Amazon S3, e depois carregam esses dados em staging no BigQuery. Você fornece o bucket S3, uma connection string JDBC, credenciais do banco e chaves de acesso AWS com permissão de leitura no bucket.

Seu cluster Redshift também precisa aceitar conexões do Google. Para um cluster público, isso significa liberar os ranges de IP de migração do Google na porta do cluster, que por padrão é 5439. Para um cluster privado, o Google tem uma rota via VPC: você conecta suas redes do Google Cloud e da AWS com uma VPN, reserva um range de IP com mais de 10 endereços, e o Google faz peering de um projeto tenant na sua rede. O caminho via VPC permite no máximo 5 execuções de transferência simultâneas, e uma rede Shared VPC não funciona.

Dois limites importam para warehouses grandes. O BigQuery carrega no máximo 15 TB por job de carga, por tabela, então uma tabela mais larga precisa ser dividida. E por causa de como o S3 lista objetos, alguns arquivos em staging podem ficar de fora de uma transferência, então comparar a contagem de linhas depois de cada execução ajuda a detectar dados faltando. O Google também sugere uma regra de ciclo de vida de 24 horas no bucket de staging, para que arquivos remanescentes sejam apagados automaticamente.

Qual ferramenta serve melhor para uma migração única, um dual-run ou o stack de longo prazo?

Uma migração única encaixa bem no Data Transfer Service. Um dual-run precisa de uma ferramenta de replicação com uma fonte Redshift documentada, e o Airbyte é a que detalha isso na documentação. O stack de ingestão de longo prazo é uma decisão separada, e é aí que as plataformas ELT gerenciadas competem entre si.

A fonte Redshift do Airbyte roda sincronizações incrementais ordenando por uma coluna de cursor que você define, como um timestamp updated_at. Linhas excluídas no Redshift permanecem no BigQuery, então um dual-run que precisa considerar exclusões exige full refreshes ou uma coluna de soft-delete do lado do Redshift.

O que não migra automaticamente do Redshift para o BigQuery?

O Data Transfer Service move tabelas. Queries, views, stored procedures, funções definidas pelo usuário e o design físico das tabelas precisam de trabalho de tradução, e parte dele é manual.

A maioria dos tipos de dado mapeia um para um, mas dois mapeamentos de timestamp mudam o significado do tipo:

Diferenças de SQL quebram silenciosamente. No Redshift, o operador significa exponenciação; no BigQuery, significa xor bit a bit, então uma query pode retornar números errados sem nenhum erro aparecer. Ordenações ascendentes colocam valores NULL por último no Redshift e primeiro no BigQuery, o que inverte a linha do topo em muitos relatórios. A maioria das conversões de tipo implícitas que o Redshift aceita precisa virar cast explícito. E o BigQuery não tem comando SQL COPY, então qualquer script de carga baseado em COPY precisa virar load jobs.

Funções escritas em SQL se traduzem bem. O Redshift também suporta funções definidas pelo usuário em Python, enquanto o BigQuery suporta em JavaScript, e o tradutor em batch só traduz UDFs em SQL. UDFs em Python precisam ser reescritas manualmente. Constraints de tabela como PRIMARY KEY e FOREIGN KEY não existem como constraints aplicadas no BigQuery, e as distribution keys somem completamente, porque o BigQuery distribui os dados durante a execução da query. Sort keys compostas geralmente viram clustering.

Como validar e fazer o cutover?

Um cutover em etapas funciona bem, com o relatório de tradução de SQL servindo como o portão entre cada etapa. O tradutor de SQL em batch pega seus arquivos SQL do Redshift no Cloud Storage e devolve os arquivos traduzidos, mais um resumo em CSV listando todos os avisos e erros — assim você sabe exatamente quanto trabalho manual de reescrita falta antes de fechar uma data.

Um plano em etapas seguindo a ferramentaria documentada:

1. Delimite a primeira transferência usando os padrões de nome de tabela do Data Transfer Service, começando por um único schema.
2. Rode a transferência e compare a contagem de linhas entre Redshift e BigQuery.
3. Traduza em batch suas queries, views e UDFs em SQL, e depois passe pelo resumo em CSV.
4. Rode as queries traduzidas contra os dados migrados e compare os resultados com o Redshift, prestando atenção à ordenação de NULLs e às colunas de timestamp.
5. Rode os dois warehouses em paralelo (dual-run) enquanto dashboards e jobs downstream vão migrando, usando execuções de transferência agendadas ou uma ferramenta de replicação para manter o BigQuery atualizado.
6. Aponte os pipelines de ingestão para o BigQuery e só então desligue o cluster Redshift.

Quanto custa uma migração de Redshift para BigQuery?

A ferramentaria de migração em si é gratuita: o Google não cobra nada pela migração da API, pelos tradutores de SQL ou pelas execuções do Data Transfer Service a partir do Redshift. O que você paga é tudo ao redor disso: manter o cluster Redshift no ar durante o dual-run, armazenamento e requisições no S3 para o bucket de staging, Cloud Storage para os arquivos de entrada e saída da tradução, e armazenamento no BigQuery assim que os dados chegam lá.

Custos de terceiros só entram em cena se você adicionar uma ponte de replicação ou uma plataforma ELT gerenciada. O Fivetran cobra por monthly active rows, com uma cobrança-base de US$ 5 em conexões pequenas, e não cobra pela carga inicial em massa. A Erathos cobra por linhas escritas no data warehouse por mês, com um plano gratuito até 1M linhas e CDC a partir do plano Pro, de US$ 250/mês.

Os cards de planos do Fivetran, precificados por monthly active rows

Planos de preço da Erathos, cobrados por linhas escritas no data warehouse por mês

O que alimenta o BigQuery depois da migração?

O transfer service leva o seu histórico para o BigQuery uma única vez. A partir daí, toda fonte que carregava dados no Redshift precisa de um pipeline próprio para o BigQuery, e é nessa camada contínua que uma plataforma ELT gerenciada faz sentido.

A Erathos tem mais de 100 conectores. Ela coloca os dados extraídos em staging num cloud storage temporário, depois carrega no data warehouse e apaga os arquivos temporários. Os planos são preços mensais fixos por volume de linhas, então você sabe o custo do novo stack de ingestão antes mesmo de começar a migração, e a integração com o BigQuery é gratuita para testar por 14 dias.

Reconstrua sua camada de ingestão sem escrever pipelines novos

O transfer service e os tradutores de SQL só rodam uma vez. A Erathos é o que substitui os pipelines que antes alimentavam o Redshift — mais de 100 conectores, batch ou CDC, preço mensal fixo por volume de linhas, e grátis até 1 milhão de linhas por mês. Teste a Erathos grátis por 14 dias.