03 Provisionamento e migração
Guia de facilitação para o módulo de provisionamento e migração do ClickHouse — a transferência autônoma de 40 a 50 minutos e o perfil dbt ausente.
Material de apoio ao instrutor para a aula do participante 03 Provisionamento e migração.
Duração
Cerca de 60 minutos no total, sendo que a distribuição do tempo importa mais do que o
total: aproximadamente 10 a 15 minutos de trabalho prático (a etapa 1 provisiona o serviço
ClickHouse Cloud com Terraform, em cerca de 2 a 3 minutos; a etapa 2 cria trips_raw,
carrega os dados de referência das zonas e executa o primeiro dbt run vazio, em mais
alguns minutos), seguidos de 40 a 50 minutos de transferência autônoma dos dados (o script
de migração da etapa 3 move 50 milhões de linhas a aproximadamente 20 mil linhas/s).
Este é o fato de cronograma mais importante de todo o workshop: depois que a etapa 3
começa, a turma não tem nada a fazer durante boa parte de uma hora. Inicie-a e faça o
intervalo aqui, use a espera para o roteiro do módulo 02 que a turma não teve tempo de
ver ou faça uma sessão de perguntas e respostas ao vivo sobre as decisões registradas no
migration-plan.md dos parceiros. Não planeje um intervalo em nenhum outro ponto deste
módulo; faça-o aqui, de propósito.
Roteiro
- Explique o motivo apresentado pelo próprio módulo para mover os dados com um script Python, e não com um conector nativo: o Snowflake não é uma origem aceita pelo ClickPipes (Kafka, S3, Kinesis e CDC de Postgres/MySQL são; Snowflake não), e todas as alternativas (exportação para S3 ou Snowflake -> Kafka -> ClickHouse) trocam uma configuração na escala do laboratório por uma infraestrutura que nada tem a ver com a migração em si — um bucket S3, uma função do IAM ou um cluster Kafka.
- Destaque os verdadeiros benefícios do script Python: dispensa uma conta AWS, é autocontido
(os dois novos pacotes ficam no mesmo ambiente virtual do dbt), pode ser retomado com
--resumea partir de uma marca d'águamax(pickup_at)e é transparente o bastante para que um parceiro leia o mapeamento de colunas em vez de percorrer um assistente na interface. - Apresente com honestidade a alternativa de produção: acima de aproximadamente 500 milhões de linhas, ou quando o custo de um warehouse que analisa a tabela inteira for relevante, exportar para S3 é a melhor escolha — exportação paralela e carga paralela. O script Python é adequado à escala do laboratório, não uma recomendação universal.
- Antecipe agora a lacuna da migração, embora ela só seja fechada no módulo 05: o produtor do Snowflake continua gravando durante toda a etapa 3, portanto o ClickHouse fica atrás do Snowflake por aproximadamente o tempo da transferência. Essa lacuna é esperada aqui e é exatamente o que a virada do módulo 05 foi projetada para fechar e medir. Explique isso antes que alguém pergunte se a espera de 40 a 50 minutos está “perdendo” dados.
Falhas comuns
- O primeiro
dbt runda etapa 2 falha comCould not find profile named 'nyc_taxi_ch'. Nada no laboratório cria automaticamente o perfil dbtnyc_taxi_chdo ClickHouse, emboradbt_project.ymlo exija. A aula do participante 03 Provisionamento e migração aborda o problema: em “Configure o perfil dbt”, na etapa 2, o parceiro adiciona um bloconyc_taxi_ch:ao~/.dbt/profiles.ymlexistente antes da execução destedbt run. Se ele ignorou ou copiou incorretamente essa etapa, encaminhe-o de volta a ela em vez de explicar novamente a solução aqui. - A autenticação do Terraform falha com
401 Unauthorized. VerifiqueCLICKHOUSE_TOKEN_KEYeCLICKHOUSE_TOKEN_SECRET: ambos ficam na interface do ClickHouse Cloud, em Settings -> API keys, e devem ter escopo Admin. - O script de migração falha no meio da execução. Execute-o novamente com
--resume; ele usa como marca d'água omax(pickup_at)já presente no ClickHouse e ignora as linhas carregadas, portanto um reinício nunca gera uma carga parcial impossível de recuperar. - O script de migração não consegue se conectar. Confirme que todas as variáveis de
ambiente do Snowflake e do ClickHouse estão definidas (
echo $SNOWFLAKE_ORG $SNOWFLAKE_ACCOUNT $SNOWFLAKE_USER $SNOWFLAKE_PASSWORDeecho $CLICKHOUSE_HOST $CLICKHOUSE_PASSWORD), executesource .env && source .clickhouse_statee tente novamente. dbt runfalha comConnection refusedouUnknown host.CLICKHOUSE_HOSTnão está definido no shell atual. Executesource .clickhouse_stateemworkshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/e tente novamente.
Etapas de redefinição
- Script de migração interrompido:
python scripts/02_migrate_trips.py --resumecontinua a partir da marca d'água, sem reiniciar toda a transferência de 50 milhões de linhas. - Se o serviço ClickHouse Cloud precisar de uma reconstrução limpa: execute
source .env && ./teardown.shemworkshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/(isso destrói o serviço e o contêiner do produtor do ClickHouse, caso a virada já tenha ocorrido) e depois execute./setup.shnovamente. Isso não afeta o lado Snowflake do módulo 01, que tem seu próprioteardown.shemworkshop_public/snowflake_migration_lab/01-setup-snowflake/. - Uma redefinição completa é cara aqui: uma nova migração repete toda a transferência de 40
a 50 minutos. Prefira
--resumeou uma correção pontual à desmontagem completa sempre que o próprio serviço ClickHouse continuar íntegro.
02 Planejamento e projeto
Guia de facilitação para o módulo de planejamento — por que ignorá-lo compromete tudo o que vem depois e como manter um bloco de 90 minutos de planilhas dentro do cronograma.
04 Reconstrução do pipeline dbt
Guia de facilitação para reconstruir o pipeline dbt no ClickHouse — por que a tabela de agregados vazia não é um bug.