Carregando dados no Redshift com DBT

• O Yelp revisou recentemente como carregar dados no Redshift de forma mais eficiente, à medida que a demanda dos consumidores por dados aumentou
• Este artigo examina como o DBT funciona de forma integrada com o Redshift Spectrum para ler dados do Data Lake para o Redshift, reduzindo significativamente o tempo de execução, resolvendo problemas de qualidade de dados e melhorando a produtividade dos desenvolvedores

Ponto de partida

• O método de carregar dados em lote no Redshift foi eficaz por anos, mas a equipe continuou buscando melhorias
• Em geral, usavam jobs do Spark para ler dados do S3 e publicá-los em um pipeline de dados interno baseado em Kafka, levando os dados tanto para o Data Lake quanto para o Redshift
• No entanto, começaram a enfrentar alguns problemas:
  • Desempenho: conjuntos de dados grandes (mais de 1 milhão de linhas por dia) começaram a sofrer atrasos. Isso ocorria principalmente por causa de varreduras de tabela para garantir que não houvesse duplicação de chaves primárias durante o upsert
  • Alterações de esquema: a maioria das tabelas era composta por esquemas Avro. Mudanças de esquema às vezes eram complexas, porque exigiam um processo de várias etapas para gerar e registrar um novo esquema Avro
  • Backfill: o suporte a backfill para correções de dados era fraco, porque não havia uma forma simples de modificar linhas in-place. Muitas vezes, os dados eram excluídos manualmente antes de gravar os dados corrigidos para uma partição inteira
  • Qualidade de dados: escrever em paralelo no Data Lake e no Redshift criava risco de divergências, como diferenças de tipo de dados entre os dois armazenamentos

Melhorando a carga no Redshift com DBT

• Ao considerar formas de mover dados com mais eficiência, a equipe escolheu usar o AWS Redshift Spectrum, uma ferramenta criada especificamente para permitir que o Redshift consulte dados do Data Lake
• Como as tabelas do Data Lake normalmente tinham o esquema mais atualizado, decidiram usar o Data Lake como fonte de dados para os lotes do Redshift, em vez do S3. Isso ajudou não só a reduzir divergências de dados, como também se alinhou à prática recomendada da equipe de tratar o Data Lake como fonte única da verdade
• Para a implementação, o Spectrum exige um esquema definido, que já existia no Glue para as tabelas do Data Lake. A única configuração adicional necessária foi adicionar as tabelas do Data Lake como tabelas externas, para que pudessem ser acessadas no Redshift com consultas SQL simples
• A equipe já vinha adotando o DBT para outros conjuntos de dados, e ele também pareceu um candidato perfeito para capturar consultas do Redshift Spectrum no pipeline. O DBT é excelente para transformação de dados e ajuda a aplicar a escrita de SQL modular e versionado
• Em vez de jobs do Spark lendo do S3 para o Redshift, passaram a usar o DBT para copiar dados diretamente do Data Lake para o Redshift. Além de oferecer benefícios característicos como reprodutibilidade, flexibilidade e linhagem de dados, o DBT também ajudou a resolver alguns dos problemas mencionados acima

Alterações de esquema simplificadas

• Para simplificar mudanças de esquema, a equipe aproveitou o argumento de configuração on_schema_change do DBT. Ao defini-lo como append_new_columns, garantiram que colunas não fossem removidas quando ausentes nos dados de entrada
• Também usaram contratos do DBT como uma segunda camada de proteção para verificar se os dados gravados correspondiam à configuração do modelo

Backfill menos manual

• O backfill também ficou muito mais fácil com o DBT. Com o argumento de configuração pre_hook, é possível especificar uma consulta que será executada imediatamente antes do modelo
• Isso permitiu excluir de forma mais automática os dados das partições que seriam gravadas
• Agora, a equipe consegue garantir idempotência e fazer backfill sem se preocupar com dados antigos que não foram removidos

Remoção de duplicatas de dados

• Para resolver linhas duplicadas, a equipe adicionou uma camada de deduplicação no SQL e fez a validação com testes do DBT
• O DBT tem um teste nativo de unicidade de coluna, mas ele exige uma varredura da tabela inteira, o que o torna inviável para tabelas grandes
• Em vez disso, usaram a função expect_column_values_to_be_unique do pacote dbt_expectations. Isso permite especificar uma condição de linha para varrer apenas as linhas gravadas recentemente

Ganhos de desempenho

• O resultado mais visível foi a melhora de desempenho, especialmente no conjunto de dados do Redshift com mais problemas:
  • As gravações levavam cerca de 2 horas, mas agora normalmente são concluídas em apenas 10 minutos
  • Antes havia atrasos de até 6 horas por mês, mas agora eles não acontecem mais. Isso reduz bastante a carga do esforço de resposta a incidentes de plantão
  • As atualizações de esquema antes exigiam um processo mais longo e com várias etapas. Agora, isso foi reduzido para um processo de 3 etapas que leva apenas algumas horas

Melhor consistência de dados

• Ao eliminar a bifurcação no fluxo de dados, aumentou a confiança de que os dados não divergirãoum entre diferentes armazenamentos
• Como todos os dados que entram no Redshift agora precisam passar primeiro pelo Data Lake, ficou mais garantido que o Data Lake permaneça como a única fonte da verdade

Conclusão

• Com o sucesso da migração, a equipe aplicou essas mudanças a cerca de 12 outros conjuntos de dados e observou benefícios semelhantes de forma geral
• Ao aproveitar ferramentas como AWS Redshift Spectrum e DBT, a equipe adaptou a infraestrutura às necessidades de dados em evolução, entregando mais valor para usuários e partes interessadas