04 Reconstrução do pipeline dbt

Material de apoio ao instrutor para a aula do participante 04 Reconstrução do pipeline dbt.

Duração

Cerca de 30 minutos. O único trecho realmente ocioso é o segundo dbt run da etapa 1 (aproximadamente 8 a 12 minutos para processar 50 milhões de linhas nos modelos incrementais): curto demais para normalmente justificar um intervalo próprio, mas longo o bastante para ser explicado em vez de observado em silêncio. A etapa 2 (o dicionário de zonas) e as consultas de verificação são rápidas e interativas.

Roteiro

• Apresente este módulo como uma prova do pipeline, não dos dados: o módulo 03 demonstrou que o ClickHouse comporta 50 milhões de linhas; este demonstra que o mesmo formato de pipeline Medallion do módulo 01 — views de preparação, tabela de fatos incremental, recargas de dimensões e testes — funciona no ClickHouse sem mudar de formato.
• Vale a pena fazer uma pausa em um mecanismo do dbt: delete_insert substitui MERGE INTO (o ClickHouse não tem instrução MERGE), e ReplacingMergeTree é a rede de segurança por baixo dele, não seu substituto. Se delete_insert terminar normalmente, não há nada para o RMT limpar; ele só importa quando uma execução é interrompida no meio.
• Destaque mv_live_trip_feed pelo nome: não há equivalente algum no Snowflake. Uma view materializada padrão só vê as linhas do lote que a acionou; uma view materializada REFRESHABLE executa novamente toda a consulta em um agendamento, podendo manter um agregado de toda a vida útil. Esta é uma nova capacidade acrescentada pela migração, não uma simples transposição.
• Diga isto antes que alguém pergunte: agg_hourly_zone_trips estará vazia após o dbt run da etapa 1, e isso está correto, não é um bug. Seu filtro incremental é WHERE pickup_at >= now() - INTERVAL 2 HOUR, que só corresponde a linhas gravadas por um produtor em tempo real; todas as linhas recém-migradas são históricas. Ela permanece vazia até que o módulo 05 inicie o produtor do ClickHouse na virada. Os parceiros costumam concluir que o pipeline está quebrado; antecipe-se à pergunta.

Falhas comuns

• agg_hourly_zone_trips retorna 0 linhas após a etapa 1 e um parceiro relata um bug. Não é um bug; consulte o roteiro acima. Confirme que dim_taxi_zones (265 linhas) e fact_trips (aproximadamente 50 milhões de linhas) foram preenchidas conforme o esperado antes de investir tempo em agg_hourly_zone_trips. Se as duas estiverem corretas, a tabela de agregados vazia está funcionando exatamente como projetado. Esta é a principal “falha” do módulo; espere ouvir a pergunta em todas as turmas.
• O dbt run da etapa 1 falha ou não consegue se conectar. Este módulo depende do perfil dbt do ClickHouse que o módulo 03 já deveria ter criado (~/.dbt/profiles.yml, nyc_taxi_ch). Se o perfil estiver ausente — consulte “Configure o perfil dbt”, na etapa 2 de 03 Provisionamento e migração —, a etapa 1 falhará aqui, um módulo depois da causa raiz.
• PENDENTE: a seção ## dbt no ClickHouse da página de Solução de problemas do site não contém uma entrada específica para uma falha que só aparece nesta etapa. Registre aqui qualquer particularidade encontrada no ensaio.

Etapas de redefinição

• Execute dbt run novamente sem receio: ele é incremental e seguro para repetição; nada aqui exige desmontagem.
• Depois de alterar um modelo ou esquema dbt, force uma reconstrução completa dos modelos incrementais: dbt run --full-refresh (em workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/dbt/nyc_taxi_dbt_ch).
• Se o dicionário de zonas parecer incorreto ou desatualizado, basta executar novamente scripts/04_create_dictionary.sql: trata-se de CREATE OR REPLACE DICTIONARY, que pode ser repetido com segurança sem remover nada antes.
• Nenhuma redefinição no nível do ambiente se aplica aqui. A desmontagem deste módulo é o mesmo workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/teardown.sh abordado no módulo 03; não o execute no meio do módulo.