Amazon Redshift DBT Best Practices - Paper

Machine Translated by Google
Melhores práticas para alavancar

Amazon Redshift e dbt™
Avisos
Os clientes são responsáveis por fazer a sua própria avaliação independente das informações contidas neste
documento. Este documento: (a) é apenas para fins informativos, (b) representa as ofertas e práticas atuais de produtos
da AWS, que estão sujeitas a alterações sem aviso prévio, e (c) não cria quaisquer compromissos ou garantias da
AWS e suas afiliadas, fornecedores ou licenciantes. Os produtos ou serviços da AWS são fornecidos “no estado em que se
encontram”, sem garantias, representações ou condições de qualquer tipo, expressas ou implícitas. As responsabilidades e
obrigações da AWS para com seus clientes são controladas pelos contratos da AWS, e este documento não faz parte nem
modifica qualquer acordo entre a AWS e seus clientes.
© 2023 Amazon Web Services, Inc. ou suas afiliadas. Todos os direitos reservados.
Conteúdo
Introdução
Opções de implantação do Amazon Redshift
Redshift sem servidor
Clusters provisionados
Casos de uso do Amazon Redshift
Fluxo típico de data warehouse para Amazon Redshift
Conceitos-chave para compreender o dbt™
Arquitetura e benefícios do dbt
Nuvem DBT
Documentação e tratamento de dependências
Tornando o código modular usando macros
Iniciando o desenvolvimento do dbt com pacotes
Documentação enquanto você codifica com dbt
Recursos para aprender mais
Otimizando uma arquitetura Amazon Redshift com dbt
Conectando dbt ao Amazon Redshift
Práticas recomendadas de dbt + Redshift
Escolha um cluster Redshift ou endpoint sem servidor
Plano para garantia de qualidade
Configure seu ambiente de data warehouse (vários clusters Redshift)
Configure seu ambiente de data warehouse (cluster Redshift único ou endpoint)
Defina seus ambientes como alvos no dbt
Configure controles de acesso baseados em funções (RBAC), se necessário
Use as visualizações de ligação tardia do Redshift para consolidação downstream
Ajuste de desempenho do seu dbt - Amazon Redshift Environment
Usando chaves de classificação e distribuição
Armazenando dados com eficiência
Configurar o gerenciamento de carga de trabalho do Amazon Redshift (WLM)
Escolhendo materializações de modelo apropriadas

Visualizações materializadas no Redshift
Limitando os dados usados no desenvolvimento
Usando pacotes dbt para manter projetos DRY
Aproveitando o Redshift Spectrum e tabelas externas
Otimização de código baseada em dados em dbt™ e Amazon Redshift
Analisando metadados dbt
Usando EXPLAIN e resumo de consulta do Redshift
Conclusão
Apêndice: Recomendações para definir permissões e controles de acesso no Redshift
Configurando permissões de grupo
Métodos de autenticação
Autenticação de nome de usuário e senha
Autenticação com IAM
Conexão do túnel SSH
Protegendo PII: Mascaramento Dinâmico de Dados com dbt
Revisões de documentos
Abstrato
Os dados se tornaram uma parte essencial de todos os negócios e seu volume, velocidade e variedade continuam a aumentar.
Cada vez mais organizações consideram um desafio atender às suas necessidades com soluções tradicionais de análise de
dados locais e estão buscando modernizar sua infraestrutura de dados e análise migrando para a nuvem.
Para aproveitar melhor o seu investimento numa infraestrutura de dados na nuvem, as empresas precisam de trabalhar de uma
forma que permita a colaboração com utilizadores empresariais e a automatização dos principais fluxos de trabalho. Por esse
motivo, muitas equipes de dados usam o dbt™ para gerenciar transformações de dados no Amazon Redshift. Isso permite que as
equipes criem pipelines de dados confiáveis que são controlados por versão, testados e documentados, aumentando assim a
confiança das partes interessadas e removendo barreiras técnicas comuns que limitam o tempo de produção. Este whitepaper
descreve os benefícios e as práticas recomendadas do uso da escala do data warehouse do Amazon Redshift e da agilidade do
dbt™ para criar pipelines de dados confiáveis.
Amazon Web Services Melhores práticas para aproveitar o Amazon Redshift e o dbt™
Introdução
Amazon Web Services (AWS) é a plataforma em nuvem mais abrangente e amplamente adotada do mundo, oferecendo mais
de 200 serviços completos de data centers em todo o mundo. Milhões de clientes, incluindo as startups de crescimento mais rápido,
as maiores empresas e as principais agências governamentais, confiam na AWS para potencializar sua infraestrutura,
melhorar sua agilidade e reduzir seus custos.
Redshift da Amazon é um data warehouse em nuvem rápido, fácil e amplamente utilizado que torna simples e econômico
a análise eficiente de dados usando ferramentas de business intelligence existentes. Ele é otimizado para conjuntos de dados
que variam de algumas centenas de gigabytes a petabytes ou mais e foi projetado para custar menos do que outras soluções
de armazenamento de dados.
DBT ajuda a gerenciar a transformação de dados na plataforma de dados, permitindo que as equipes implantem código
analítico seguindo as melhores práticas de engenharia de software, como modularidade, integração e implantação
contínuas (CI/CD) e documentação incorporada. dbt é completamente pushdown, utilizando os recursos de computação do
mecanismo de banco de dados para execução. Mais especificamente, o dbt permite que as equipes de dados implementem
lógica de negócios em SQL em modelos de dados dbt, criem e automatizem testes baseados em código e controlem a versão
de seu código. Em sua essência, o dbt irá:
• Compile o código do seu projeto em instruções SQL DML e DDL do Amazon Redshift
• Inferir dependências para executar transformações (na forma de modelos dbt) na ordem correta e
gerar um projeto DAG (Directed Acíclico Graph) automaticamente
• Facilite o código reutilizável com macros e instruções ref.
Para começar a usar o dbt e o Amazon Redshift, siga o guia de conceitos básicos. O dbt Labs também oferece uma variedade
de cursos de treinamento sob demanda para ajudar as equipes de dados a compreender o poder e a funcionalidade do dbt.
Opções de implantação do Amazon Redshift

O Amazon Redshift é uma solução de armazenamento de dados rápida, simples e econômica que permite aos clientes
dimensionar suas análises de dados. Dezenas de milhares de clientes confiam no Amazon Redshift para analisar exabytes de
dados e executar consultas analíticas complexas, tornando-o um dos data warehouses em nuvem mais usados
atualmente. O Amazon Redshift é um serviço totalmente gerenciado e oferece opções provisionadas e sem servidor.
1
Redshift sem servidor

O Amazon Redshift Serverless facilita a execução e a escalabilidade de análises em segundos, sem a necessidade de definir
configurar e gerenciar a infraestrutura de data warehouse. Com o Redshift Serverless, seu serviço de data warehouse pode pausar,
retomar automaticamente e aumentar e diminuir automaticamente. Basta definir a capacidade das unidades de processamento
Redshift (RPU) do data warehouse base, com base em seus requisitos de preço e desempenho. Você pode criar vários grupos de
trabalho e namespaces no Redshift Serverless para permitir o isolamento da carga de trabalho ou segregar a carga de trabalho com
base em domínios de dados.
A ativação do Amazon Redshift Service leva alguns minutos, com instruções para as duas opções fornecidas abaixo. Encontre
instruções sobre como configurar o data warehouse Redshift Serverless aqui e armazém de dados provisionados Redshift aqui. Siga
as instruções fornecidas aqui para conectar-se ao Serverless e aqui para se conectar ao Provisioned para começar a consultar o
Amazon Redshift.
Clusters provisionados
Ao usar a opção de implantação provisionada, o ambiente do Amazon Redshift consiste em um cluster de nós de um determinado tipo
de nó. Ao criar seu data warehouse, você pode escolher o tipo e a quantidade de nós corretos para atender às suas necessidades.
Um cluster provisionado é mais adequado para cargas de trabalho em que você precisa de controle granular sobre configuração,
implantação e gerenciamento. Você pode dimensionar seu cluster conforme necessário usando a opção de redimensionamento e
deixar tarefas administrativas como backup, gerenciamento de falhas de nós ou unidades e ajuste de consulta para o serviço
Amazon Redshift. Com o Redshift, qualquer usuário, incluindo analistas de dados, desenvolvedores, profissionais de negócios e
cientistas de dados, pode obter insights dos dados simplesmente carregando e consultando dados no data warehouse.
Como funciona o Amazon Redshift

O Amazon Redshift usa SQL para analisar dados estruturados e semiestruturados em data warehouses, bancos de dados
operacionais e data lakes, usando hardware e machine learning projetados pela AWS para oferecer o melhor desempenho de preço
em qualquer escala.
O Amazon Redshift obtém armazenamento eficiente e desempenho ideal de consultas por meio de uma combinação de processamento
massivamente paralelo, armazenamento de dados em colunas e esquemas de codificação de compactação de dados direcionados e
eficientes.
Casos de uso do Amazon Redshift

Os casos de uso populares do Amazon Redshift incluem:
Inteligência Empresarial
Analise terabytes a petabytes de dados estruturados e semiestruturados usando SQL e consultas avançadas, relatórios e painéis.
2
Inovação por meio de aprendizado de máquina
Impulsione a tomada de decisões mais rápida em toda a sua empresa, com insights preditivos para informar novos produtos e serviços
usando o Amazon Redshift ML.
Compartilhamento de dados e colaboração
Consulte, compartilhe e analise dados em tempo real entre organizações e parceiros com o Amazon Redshift Data Sharing e o AWS
Data Exchange.
Insights operacionais em tempo real
Processe grandes volumes de dados de diversas fontes, incluindo fontes de streaming simultaneamente, com consultas e usuários
simultâneos ilimitados, tudo com alto desempenho consistente.
Fluxo típico de data warehouse para Amazon Redshift
Um data warehouse do Amazon Redshift é um sistema de gerenciamento de banco de dados relacional (RDBMS) de classe empresarial.
Na camada de ingestão de dados , diferentes tipos de fontes de dados carregam continuamente dados estruturados,
semiestruturados ou não estruturados para a camada de armazenamento de dados. Esta área de armazenamento de dados serve como
uma área de preparação que armazena dados em diferentes estados de prontidão para consumo. Um exemplo de armazenamento pode
ser um bucket do Amazon Simple Storage Service (Amazon S3).
Na camada opcional de processamento de dados , os dados de origem passam por pré-processamento, validação e transformação
usando extração, transformação, carregamento (ETL). Esses conjuntos de dados brutos são então refinados usando operações ETL. Essa
camada também pode ler fontes e gravar diretamente no Amazon Redshift Service. Um exemplo de mecanismo ETL é o AWS Glue.
3
Na camada de consumo de dados , os dados são carregados no cluster do Amazon Redshift, onde você pode executar cargas de
trabalho analíticas. Ferramentas de BI como o Amazon QuickSight são usadas para criar relatórios e painéis no data warehouse do
Amazon Redshift para fornecer insights à comunidade empresarial.
O Amazon Redshift também pode consumir dados para cargas de trabalho analíticas de diversas fontes:
• O compartilhamento de dados do Amazon Redshift pode ser usado para acessar compartilhamentos de dados de outros
ambientes do Amazon Redshift, provisionados ou sem servidor, para fins de leitura com segurança e facilidade. Você pode
compartilhar dados em diferentes níveis, como bancos de dados, esquemas, tabelas, visualizações (incluindo visualizações
regulares, de ligação tardia e materializadas) e UDFs (funções definidas pelo usuário) SQL. Para obter mais informações
sobre o compartilhamento de dados, consulte Conceitos básicos de acesso a dados em outros clusters do Amazon Redshift.
• O Amazon Redshift Spectrum pode ser usado para consultar dados em arquivos do Amazon S3 sem precisar carregar os dados
nas tabelas do Amazon Redshift. O Amazon Redshift fornece recursos SQL projetados para processamento analítico on-line
rápido (OLAP) de conjuntos de dados muito grandes armazenados em clusters do Amazon Redshift e em data lakes
do Amazon S3. Ao acessar seu data lake S3 por meio do Amazon Redshift Serverless, você não paga pelo Amazon
Redshift Spectrum separadamente. Você tem uma experiência unificada sem servidor e paga pelas consultas do data lake
também em segundos de RPU. Para obter mais informações sobre o Redshift Spectrum, consulte Introdução à consulta do
seu data lake.
• A consulta federada do Amazon Redshift pode ser usada para unir dados de bancos de dados relacionais, como Amazon
Relational Database Service (Amazon RDS) e Amazon Aurora, ou Amazon S3, com dados em seu banco de dados
Amazon Redshift. Você pode usar o Amazon Redshift para consultar dados operacionais diretamente (sem movê-los), aplicar
transformações e inserir dados nas tabelas do Amazon Redshift. Para obter mais informações sobre consultas federadas,
consulte Introdução à consulta de dados em fontes de dados remotas.
Conceitos-chave para compreender o dbt™
Arquitetura e benefícios do dbt

dbt é um fluxo de trabalho de transformação que permite às equipes implantar código analítico de forma rápida e colaborativa
seguindo as melhores práticas de engenharia de software, como modularidade, CI/CD e documentação.
Os usuários escreverão sua lógica de negócios com apenas uma instrução SQL select ou Python DataFrame (não disponível
no Redshift) como um modelo dbt. No momento da execução, o dbt compila o modelo e cuida da materialização e gravação do DML/
DDL necessário para gerenciar transações, eliminar tabelas e gerenciar alterações de esquema. O código é reutilizável e
modular e pode ser referenciado em modelos dbt subsequentes, especialmente com o uso de macros, ganchos, e gerenciamento
de pacotes.
Ao fazer com que o dbt cuide do DML/DDL, o gerenciamento do ambiente é tão simples quanto executar o modelo dbt no
ambiente desejado, removendo assim erros comuns que ocorrem ao copiar e colar SQL. O controle de versão permite processos
maduros de controle de origem, como ramificação, pull requests e código
4
avaliações. Para aumentar a confiança das partes interessadas, testes de qualidade de dados podem ser escritos e aplicados nos dados
subjacentes, detectando quaisquer casos extremos que possam ser aplicados no desenvolvimento, teste e implantação.
Nuvem DBT
dbt Cloud é um serviço hospedado que ajuda as equipes de dados a produzir implantações de dbt. O dbt Cloud oferece suporte pronto
para uso para agendamento de tarefas, integrações CI/CD, documentação de serviço, integrações git nativas, monitoramento e alertas e
um ambiente de desenvolvedor integrado (IDE), tudo dentro de uma interface de usuário (IU) baseada na web.
Para começar com dbt e Redshift, você pode instalar o adaptador Redshift para desenvolvimento local na linha de comando ou crie uma
conta dbt Cloud de teste gratuito para aproveitar o IDE e o agendador na plataforma.
Documentação e tratamento de dependências

Uma pedra angular da funcionalidade do dbt é a referência função. A função ref em dbt estabelece automaticamente uma linhagem do
modelo dbt que está sendo referenciado ao modelo declarado na referência. Ao usar a função ref, o dbt é capaz de (1) inferir
dependências e (2) garantir que as tabelas e visualizações upstream corretas sejam selecionadas com base em seu ambiente. Sempre use
a função ref ao selecionar outro modelo, em vez de usar a referência de relação direta (por exemplo, meu_esquema.minha_tabela).
Quando ref() é emparelhado com o uso de threads, dbt executa modelos seguindo um caminho ideal sem exigir entrada manual. À medida
que você aumenta o número de threads para uma execução, o dbt aumenta o número de caminhos no gráfico nos quais ele pode
trabalhar ao mesmo tempo, reduzindo assim o tempo de execução do seu projeto.
Em dbt, modelos, fontes, testes e instantâneos são exemplos de nós em projetos dbt. Emparelhando threads com a seleção de nós do
dbt, você pode otimizar sua execução de dbt executando apenas o que precisa, sem declarar explicitamente a ordem de
construção do modelo. Isso significa que você pode executar com base nos modelos que foram alterados desde a última execução ou
reiniciar após falha juntamente com a execução de modelos em paralelo.
5
Um exemplo de DAG dbt: neste exemplo, o usuário declarou no modelo dim_suppliers uma referência a
stg_tpch_nations, stg_tpch_regions e stg_tpch_suppliers. No momento de uma execução do dbt, se um usuário tiver
declarado 3 threads, o dbt saberia executar os três primeiros modelos de teste antes de executar dim_suppliers. Ao
especificar 3 threads, o dbt funcionará em até 3 modelos ao mesmo tempo sem violar dependências – o número real de
modelos nos quais ele pode trabalhar é limitado pelos caminhos disponíveis no gráfico de dependências.
Fontes funcionam de forma semelhante às referências, com a principal diferença sendo que, em vez de dizer ao dbt
como um modelo se relaciona com outro modelo, as fontes informam ao dbt como um modelo se relaciona
com um objeto de origem. Declarar uma dependência de um modelo para uma fonte dessa maneira permite algumas
coisas importantes: permite selecionar tabelas de origem em seus modelos e abre a porta para testes de projeto e
documentação mais extensos envolvendo seus dados de origem.
6
Um exemplo de DAG dbt incluindo um nó de origem: O nó verde aqui representa a tabela de origem da qual
stg_tpch_nation depende.
Tornando o código modular usando macros

No dbt, junto com o SQL, você também pode usar Jinja, uma linguagem de modelagem Pythonic que pode expandir os
recursos do SQL. Jinja oferece a capacidade de usar estruturas de controle e aplicar variáveis de ambiente.
Pedaços de código escritos com Jinja que podem ser reutilizados em todo o projeto dbt são chamados de macros. Elas são
análogas às funções de outras linguagens de programação, permitindo definir código em um local central e reutilizá-lo em
outros locais. As funções ref e source mencionadas acima são exemplos de Jinja. Além de serem úteis para a lógica
ambiental, as macros podem ajudar a operacionalizar tarefas administrativas do Redshift, como declarações de
concessão, ou remover sistematicamente objetos obsoletos. Basicamente, qualquer código que você esteja escrevendo/
executando repetidamente, você deve considerar colocá-lo em uma macro.
Iniciando o desenvolvimento do dbt com pacotes

pacotes dbt são bibliotecas de modelos e/ou macros de código aberto para uma finalidade ou fonte de dados específica.
Em vez de ter que reescrever o mesmo código que a comunidade aperfeiçoou, use pacotes para que você possa se concentrar
na implementação dos modelos personalizados e da lógica de negócios da sua organização.
A funcionalidade comum do pacote inclui:
• Métodos de modelagem para fontes de dados comuns, como anúncios do Facebook ou Netsuite
• Testes úteis que estão fora dos testes padrão do dbt
• Trabalho inovador para levar transformações de dbt a novos domínios, como dbt_ml
• E muito mais!
dbt Labs atualmente oferece suporte a um pacote Redshift para um cluster provisionado que fornece vários modelos
para tabelas de sistema Redshift, bem como algumas macros úteis que ajudam a compactar tabelas, descarregar tabelas e
até mesmo limpar e analisar tabelas. Eles são extremamente úteis se você deseja acessar e analisar dados de consultas
e permissões do Redshift sem precisar modelá-los explicitamente.
Os usuários podem adicionar pacotes de hub aos seus projetos dbt adicionando o nome do pacote e a versão desejada no
arquivo packages.yml do projeto dbt. Depois que os usuários os adicionam e executam dbt deps, eles podem acessar as
macros e modelos em todo o projeto usando a referência normal e a sintaxe da macro. Para pacotes privados, locais ou git
que não estão no hub de pacotes dbt, você pode aprender mais sobre como instalar pacotes em seu projeto dbt aqui.
Adicione o pacote dbt_utils para qualquer projeto dbt e utilizando as macros para ajudar a seguir os princípios DRY (Don't
Repeat Yourself) na modelagem de dados. dbt_utils contém uma série de macros e testes que ajudam a aliviar pontos
problemáticos comuns na modelagem de dados, como a capacidade de criar rapidamente uma coluna de data (a
7
tabela com o período de tempo relevante que possui um registro para cada data do período), destornar colunas facilmente, e
mais.
O pacote dbt_utils também suporta um tipo de materialização insert_by_period para Redshift, onde dbt pode inserir registros
em uma tabela um período (ou seja, dia, semana) por vez. Essa materialização é mais útil para dados de eventos que podem
ser processados em períodos discretos ou quando há cargas de dados incrivelmente grandes que falham em seções específicas.
À medida que sua equipe e seus dados crescem, não é incomum que as equipes criem e compartilhem pacotes internos
onde possam padronizar a lógica e as definições em vários repositórios dbt. Isso pode ajudar a garantir que as métricas tenham
a mesma definição, que a lógica de negócios seja escrita de forma consistente e limite o código WET (gravação sempre).
Documentação enquanto você codifica com dbt

O dbt permite que as equipes de dados criem documentação robusta para suas fontes de dados, modelos, testes e
exposições downstream. No nível de origem e de modelo, você pode adicionar documentação sobre os próprios modelos e
os campos que eles contêm. Os documentos do dbt ajudam todos em sua organização, incluindo usuários corporativos,
a responder perguntas cotidianas sobre conjuntos de dados e lógica de transformação.
Documentar fontes e modelos localmente por meio da linha de comando. Alternativamente, gerar documentação através do dbt
Cloud é uma ótima maneira de promover a transparência dos dados com os usuários empresariais finais.
dbt também recomenda aproveitar metacampos para fontes, modelos, testes e macros para ajudar a estabelecer uma
propriedade clara para objetos de projeto dbt. Os metacampos são uma ótima maneira de identificar claramente o proprietário, a
maturidade e os sinalizadores do modelo se ele contiver dados confidenciais como PII. Existem diversas ferramentas de
governança de dados que se integram ao dbt usando o metacampo para implementar políticas.
Exposições pode ser usado para representar painéis de BI downstream, aplicativos ou pipelines de ciência de dados em seu
projeto dbt. Documentar exposições em dbt é uma ótima maneira de identificar claramente propriedade, dependências
e descrições de aplicativos downstream.
Toda essa documentação do dbt está disponível por meio de um host local após a execução de dois comandos CLI (dbt docs
generate && dbt docs serve) ou por meio da seção “Documentação” no dbt Cloud.
Você também pode usar a API dbt Cloud Metadata para enviar as informações para nossos catálogos de dados de parceiros.
Recursos para aprender mais

Há uma grande variedade de recursos disponíveis publicamente para aprender mais. Se você é novo no dbt, comece com o Guia
adaptado para usuários do Redshift. Ele orientará o processo de configuração de um projeto dbt Redshift e de teste dos
principais recursos do dbt. Se quiser começar a usar a CLI do dbt com o Amazon Redshift, você pode usar este guia. A seguir,
experimente o curso dbt Fundamental mais aprofundado , e use a lista de verificação essencial do projeto dbt para consultar uma
lista de práticas recomendadas.
8
Otimizando uma arquitetura Amazon Redshift com

dbt
Ao introduzir o dbt em uma arquitetura Amazon Redshift, a equipe de dados pode mover o processamento de dados dentro do
Redshift, usando uma estrutura ELT (Extract-Transform-Load) em vez de uma estrutura ETL (Extract-Load-Transform). Em uma
estrutura ELT, os dados são carregados no data warehouse com pouco ou nenhum pré-processamento, e os dados
podem ser transformados no Redshift. Com a mudança para uma estrutura ELT, uma gama mais ampla de pessoas dentro da
organização pode contribuir com transformações de dados – incluindo profissionais que podem ter um contexto de negócios
profundo, mas nenhuma habilidade de programação além de SQL.
Conectando dbt ao Amazon Redshift

A estrutura dbt usa adaptadores para “adaptar” a funcionalidade do dbt a uma determinada plataforma de dados. O
adaptador dbt Redshift permite que o dbt se conecte ao Redshift. Depois que uma conexão é estabelecida, o dbt é capaz de emitir
SQL compatível com Redshift para Redshift para execução e conversão de arquivos de modelo em objetos persistentes.
Para usar o dbt Core com Redshift, o processo de configuração começa com a instalação do adaptador dbt-redshift localmente.
Depois de configurado com seu conjunto preferido de ferramentas (incluindo editor de texto, interface de linha de comando, etc.),
você estará pronto para usar o dbt com o Redshift.
Na nuvem dbt, não há necessidade de instalação. Basta criar uma conta, configurar uma conexão Redshift e você estará pronto
para desenvolver. dbt Cloud é uma interface totalmente baseada em navegador, economizando tempo na manutenção de
ambientes e atualizações de software.
9
Práticas recomendadas de dbt + Redshift
Escolha um cluster Redshift ou endpoint sem servidor

No Redshift, as equipes podem escolher entre um cluster provisionado do Amazon Redshift ou um endpoint sem servidor. Se
estiver aproveitando um cluster provisionado, recomendamos escolher o tipo de nó RA3. Os tipos de nós Redshift RA3 e endpoints sem
servidor separam a computação do armazenamento aproveitando o Redshift Managed Storage (RMS). Eles fornecem desempenho
superior junto com recursos como compartilhamento de dados, computação e armazenamento escalonáveis, AWS Data
Exchange e consultas entre bancos de dados. O Amazon Redshift serverless tem o benefício adicional de que os usuários não precisam
se preocupar com aspectos de dimensionamento e o endpoint do data warehouse pausará e retomará automaticamente,
permitindo que os usuários aproveitem um modelo de pagamento conforme o uso. Se um cliente espera um data warehouse em
nuvem quase totalmente administrativo, o Redshift Serverless é a escolha certa.
Além disso, o Amazon Redshift fornece um tipo de nó de computação densa (DC2). No entanto, não os recomendamos
devido às suas limitações com consultas entre bancos de dados e ao impacto que têm nas configurações e no desempenho do
ambiente.
A configuração e o fluxo de trabalho corretos do Redshift podem ser diferentes de equipe para equipe. No entanto, temos uma série
de recomendações para construir uma base sólida, independentemente do tamanho da organização. Em última análise, recomendamos
implementar essa estrutura básica e personalizá-la para funcionar para você e sua equipe.
Plano para garantia de qualidade

É fundamental configurar ambientes distintos de produção e desenvolvimento em dbt e Redshift. Isto reduz o risco de exposição
de dados não testados a plataformas de business intelligence (BI) e limita a necessidade de reconstruções dispendiosas.
Também é importante criar uma estrutura de controle de qualidade. Para equipes que podem acessar os mesmos dados
brutos no desenvolvimento e na produção, porque os dados são os mesmos, você pode executar tarefas relacionadas ao controle de
qualidade em seu ambiente de desenvolvimento antes de promover para produção. Para outras equipes que podem estar acessando
versões diferentes dos dados brutos com base no fato de estarem em desenvolvimento ou no ambiente de produção, um ambiente de
controle de qualidade separado de desenvolvimento e produção pode fazer sentido. Isso faz sentido especialmente quando você
introduz novos aprovadores no ambiente de controle de qualidade, em oposição ao ambiente de desenvolvimento.
Sempre recomendamos um fluxo de trabalho de controle de qualidade para promover o código desde o desenvolvimento até a
produção, independentemente de onde você realmente executa essas verificações. Para os fins deste artigo, teremos uma abordagem
mais simples de gerenciamento de fluxos de trabalho de controle de qualidade dentro do ambiente de desenvolvimento.
10
Configure seu ambiente de data warehouse (múltiplos

Clusters Redshift)
Para começar, crie três clusters Redshift ou endpoints sem servidor chamados raw, dev e prod. Se optar por criá-los em clusters Redshift separados, você
precisará habilitar o compartilhamento de dados (disponível apenas no Redshift RA3 e Serverless). O compartilhamento de dados permite que um
cluster compartilhe um conjunto de dados com outro cluster sem copiar ou mover dados. Como alternativa, você pode utilizar consultas entre bancos de
dados para criar todos os três bancos de dados em um cluster ou endpoint usando instâncias RA3 ou sem servidor.
Banco de dados bruto
Para evitar a duplicação dos dados brutos usados pelos seus modelos dbt, recomendamos armazenar os dados brutos em um banco de dados
separado, acessível tanto para ambientes de desenvolvimento quanto de produção. A exceção é se você tiver dados PHI ou PII que não podem ser expostos
a ambientes de desenvolvimento. Se você se deparar com essa necessidade, recomendamos colocar a versão limpa dos dados brutos em seu banco de
dados de desenvolvimento enquanto mantém os dados PHI/PII em produção. O objetivo aqui é minimizar a quantidade de dados duplicados que você possui
e, ao mesmo tempo, atender aos requisitos de segurança de dados.
Depois que o banco de dados bruto for criado e os dados estiverem prontos para serem carregados, crie esquemas brutos para os dados não
modelados de cada fonte de dados. Para dados de origem brutos, sugerimos nomear objetos de esquema com um prefixo da ferramenta ELT que carregou
esses dados (ex. airbyte_facebook_ads).
Banco de dados de desenvolvimento
No banco de dados dev, sugerimos que os desenvolvedores dbt tenham seu próprio esquema sandbox/desenvolvimento, prefixado com seu nome (ex.
dbt_amyc), para desenvolvimento. Neste espaço, os desenvolvedores de dbt podem criar, atualizar e excluir modelos sem o risco de impactar os espaços
de desenvolvimento de terceiros.
Banco de dados de produtos
No banco de dados prod, sugerimos organizar seus objetos de dados de produção por funcionais ou verticais. Para fazer isso, você pode colocar seus
modelos dbt em diferentes esquemas de produção. Recomendamos o uso de bancos de dados/esquemas personalizados . Por exemplo, você chamaria
de marketing o esquema que contém seus modelos de marketing de produção. Se for um modelo principal necessário para várias equipes, você
poderá nomear o esquema como núcleo.
11
12
Configure seu ambiente de data warehouse (Single Redshift

Cluster ou endpoint)
Como alternativa, você pode optar por implantar apenas um cluster ou endpoint Redshift, composto de Redshift DC2 com
três esquemas ou nós RA3 com vários bancos de dados ou um endpoint sem servidor com vários bancos de dados,
e usá-lo para hospedar todos os seus ambientes. Para fazer isso, para dc2 crie um banco de dados com esquemas
como divisores organizacionais entre ambientes, por exemplo, raw_<data_source_name>
para esquemas brutos, dbt_<developer_name> para esquemas de desenvolvimento. Prefixe seus esquemas de
produção com base na função com uma instrução prod_ para indicar que eles são esquemas de produção. Por exemplo,
você chamaria o esquema que contém seus modelos de marketing de produção de prod_marketing.
Os ambientes de transformação de dados não são tão isolados quanto os de desenvolvimento geral de software. Ao
construir pipelines de dados, pode ser necessário fazer referência a objetos de um ambiente de produção durante o
desenvolvimento ou durante a realização de verificações de garantia de qualidade. Por exemplo, se você está adiando
para um objeto existente em um ambiente de produção durante um dbt Cloud Slim CI executado, você executará o que foi
alterado em vez de reconstruir todo o projeto para economizar nos custos de armazenamento. Ao adiar, você selecionará entre os
13
objeto existente em vez de criar o objeto novamente. Uma execução Slim CI é um trabalho dbt Cloud que permite usar o seletor
de nó state:modified para comparar o manifesto da última execução de produção bem-sucedida com a execução do CI que
está sendo executada para ver o que mudou na execução do CI.
Defina seus ambientes como alvos no dbt
Para declarar ambientes em dbt, você pode usar diferentes detalhes de conexão nos destinos. Alvos são uma propriedade
dbt que contém informações sobre sua conexão com seu data warehouse. Você pode conectar seu projeto dbt ao Redshift de
várias maneiras, que abordaremos mais adiante neste artigo. Em seu núcleo, um nome de banco de dados, nome de
host, nome de usuário e porta são necessários para estabelecer um destino.
Configure controles de acesso baseados em funções (RBAC), se necessário
Usando controle de acesso baseado em função (RBAC) para gerenciar privilégios de banco de dados no Amazon Redshift, você
pode atribuir privilégios diferentes a funções diferentes e atribuir essas funções a usuários diferentes para ter um controle
mais granular do acesso do usuário. O RBAC oferece suporte à segurança em nível de linha e em nível de coluna. dbt Cloud
oferece RBAC para a experiência do dbt na camada corporativa, permitindo que os administradores controlem quem tem acesso
para desenvolver o projeto do dbt e alterar a orquestração do trabalho.
Use as visualizações de ligação tardia do Redshift para downstream

Consolidação
No Redshift, você pode criar visualizações ilimitadas de suas dependências. Isso significa que se uma visualização ou
tabela upstream for eliminada em cascata, a visualização de ligação tardia não será eliminada. As visualizações de
ligação tardia são úteis quando uma tabela precisa ser eliminada e substituída. Recomendamos o uso de visualizações
de vinculação tardia para criar visualizações em tabelas externas.
Para materializar ou materializar uma visualização de vinculação tardia em seu projeto, especifique a configuração para dbt no modelo ou
no nível do projeto. Em um arquivo de modelo, você pode definir explicitamente a materialização para uma visualização de ligação tardia
usando um bloco de configuração assim:
{{config(materialized='visualizar', bind=False) }}
Você também pode definir a configuração em nível de projeto ou subpasta. Para fazer isso, adicione (e modifique a hierarquia)
uma variável de ligação ao seu arquivo dbt_project.yml. Por favor, veja o exemplo abaixo para saber como fazer isso.
nome:
'meu_dbt_projeto'
versão: 1.0
14
#Isso fará com que todos os modelos de visualização em seu projeto usem o #modificador de ligação tardia. A configuração `bind` pode
ser especificada em qualquer lugar na hierarquia #configuration
modelos:
vincular: falso
Ajuste de desempenho do seu dbt - Amazon Redshift

Ambiente
dbt e Redshift têm múltiplas estratégias para tornar seus modelos mais eficientes e, portanto, mais econômicos. Esses incluem:
• Usando chaves de classificação e distribuição em tabelas grandes
• Armazenar dados de maneira eficiente
• Configurar o gerenciamento de carga de trabalho do Amazon Redshift (WLM)
• Escolha de materializações de modelo apropriadas
• Limitar a quantidade de dados usados durante os períodos de desenvolvimento
• Implementação de pacotes dbt para aderir às práticas DRY; e
• Aproveitar o Redshift Spectrum para grandes conjuntos de dados.
Referência às práticas recomendadas do Amazon Redshift para ajuste de desempenho: Blog. Discutimos cada uma dessas estratégias
abaixo.
Usando chaves de classificação e distribuição
À medida que seu projeto dbt e seus conjuntos de dados se expandem, seus tempos de construção também começarão a aumentar.
Felizmente, o Redshift possui chaves de classificação e distribuição (dist) para otimizar o desempenho. Quando usado corretamente,
você pode melhorar drasticamente o tempo e o custo de construção. Combinado com a mentalidade de modelagem modular
e configuração acessível do dbt, usar as chaves sort e dist é uma questão de adicionar algumas linhas a um bloco de configuração do modelo.
As chaves de classificação determinam a ordem em que as linhas de uma tabela são armazenadas. Você pode declarar qualquer
uma ou mais colunas em sua tabela como chaves de classificação e o Redshift classificará a tabela de acordo. Durante o
processamento, são gerados metadados como os valores mínimo e máximo, que então o Redshift pode acessar esses valores sem
iterar sobre os dados durante a execução da consulta. Usar a chave de classificação correta pode ajudar o Redshift a determinar quantas
linhas ele precisa verificar e fornecer uma consulta mais rápida. Se suas consultas contiverem predicados com intervalo restrito,
definir a chave de classificação em colunas de predicado poderá tornar as consultas mais eficientes. Você pode
15
definir chaves de classificação compostas ou intercaladas. A chave de classificação composta é mais eficiente quando os predicados de
consulta usam um prefixo que é um subconjunto das colunas da chave de classificação em ordem. A chave de classificação intercalada dá peso
igual a cada coluna na chave de classificação.
As chaves de distribuição determinam como as linhas de uma tabela são armazenadas em relação aos nós de computação disponíveis.
As linhas são distribuídas para nós de cálculo de acordo com os valores em uma coluna. Se você distribuir um par de tabelas nas
chaves de união, o Redshift posicionará as linhas nos nós de computação de acordo com os valores nas colunas de união. Dessa
forma, os valores correspondentes das colunas comuns são armazenados fisicamente juntos. Existem quatro tipos de estilos de distribuição:
automático, todos, pares e chave.
Quando você não especifica um estilo de distribuição, o Amazon Redshift usa auto, o que significa que o Redshift atribuirá o estilo com base
no tamanho da tabela.
A Otimização Automática de Tabela (ATO) é o recurso de autoajuste do Redshift para otimizar o design da tabela aplicando estilos de
classificação e distribuição sem intervenção do administrador. ATO observa continuamente como as consultas interagem com as tabelas e usa
métodos avançados de inteligência artificial para escolher estilos de classificação e distribuição para otimizar o desempenho. Para
ativar o ATO, crie uma nova tabela com Diststyle definido como Auto e chave de classificação definida como AUTO. Você também pode alterar
uma tabela existente com um comando alter table e alterar o estilo de distribuição e a chave de classificação para automático.
Recomendamos manter um estilo automático para Diststyle e chave Sort até que você precise de uma configuração de distribuição mais
manual. Pode chegar o momento em que você começará a buscar melhorias de desempenho e áreas para ajustes. Antes de começar,
observe os dados sobre o desempenho do seu modelo para desenvolver uma compreensão clara do DAG do seu projeto dbt (gráfico acíclico
direcionado) e as transformações acontecendo. Responda as seguintes questões:
• Quais são os seus maiores modelos?
• Que tipo de junções você está fazendo? E entre quais modelos? Em que chave?
O dbt possui vários recursos para ajudá-lo a responder a essas perguntas de forma escalonável e automatizada:
• No dbt Cloud, aproveite a API de metadados e a guia Model Timing para coletar dados sobre seus trabalhos e
modelos
• Analisar artefatos dbt gerados a partir de execuções de modelo
• Para obter artefatos de execuções de modelo no Redshift, coloque o manifest.json gerado em um bucket S3, use o pacote de tabelas
externas para prepará-lo e modelar os dados usando a inspiração do pacote dbt artefatos
O otimizador de consulta Redshift também é uma ótima ferramenta para revelar oportunidades de desempenho de modelo. Use o plano
EXPLAIN para decompor os CTEs de modelos de longa execução e verificar se a lógica pode ser limpa ou extraída para outro modelo. Em
última análise, você deseja reduzir as junções que são mais problemáticas e fazer benchmark ajustando a chave de classificação e dist.
16
Na maioria das vezes, recomendamos o uso de chaves dist em colunas com alta cardinalidade em tabelas maiores, fora do
método automatizado. Você provavelmente os usará em grandes tabelas de fatos e dimensões que eventualmente serão
expostas posteriormente em sua plataforma de BI. Isso pode minimizar o armazenamento duplicado, manter seus dados
no mesmo nó e melhorar o desempenho. Se você não conseguir distribuir por uma chave, recomendamos dar uma
olhada em nossa postagem abrangente no blog sobre esse tópico.
Armazenando dados com eficiência
Recomendamos as seguintes práticas de design de tabela para armazenar dados com mais eficiência, minimizar o uso de memória
e o desperdício de disco e melhorar o desempenho da consulta:
• Use a compactação, uma operação em nível de coluna que reduz o tamanho dos dados quando eles são armazenados, e
melhora o desempenho da consulta reduzindo a E/S do disco. Você pode especificar codificações de compactação ao criar
uma tabela, mas a compactação automática geralmente produz os melhores resultados. ENCODE AUTO é o padrão para
tabelas. O Amazon Redshift gerencia automaticamente a codificação de compactação para todas as colunas da tabela e
equilibra o desempenho geral ao escolher codificações de compactação.
• Minimize a largura da coluna. Considere os maiores valores que você provavelmente armazenará em um VARCHAR
coluna
• Use o tipo de dados apropriado. Armazene valores numéricos e de data/hora como dados correspondentes
tipos.
Configurar o gerenciamento de carga de trabalho do Amazon Redshift (WLM)
Para os clusters provisionados, ao configurar grupos de carregadores, transformadores e repórteres, aproveite o gerenciamento
automático de carga de trabalho do Redshift (Auto WLM) capacidade criando filas WLM separadas para cada tipo de carga de trabalho.
O Auto WLM otimiza o uso de recursos adaptando o nível de simultaneidade com base no tempo de execução de cada carga de
trabalho. Isso pode ajudar a garantir que consultas curtas e rápidas não fiquem presas em filas atrás de consultas longas.
Ter filas WLM separadas também permite o uso de regras de monitoramento de consulta (QMR) WLM para controlar as prioridades
de consulta em um nível mais refinado. Depois de configuradas, as regras promoverão ou rebaixarão consultas em tempo de
execução com base em métricas como espera na fila, tempo de execução e uso da CPU.
Escolhendo materializações de modelo apropriadas
Talvez seja necessário adaptar sua estratégia de materialização em dbt, se o desempenho começar a diminuir com o aumento do
tamanho do projeto e do volume de dados.
Atualmente, o dbt oferece suporte a quatro estratégias de materialização prontas para uso: visualização, tabela, efêmera e
incremental. Por padrão, o dbt materializará os modelos como visualizações, a menos que seja definido de outra
forma em dbt_project.yml ou em um bloco de configuração do modelo.
17
Muitas vezes recomendamos começar com visualizações e tabelas para estabelecer uma base sólida para um projeto dbt e recorrer a abordagens
mais complexas (como modelos incrementais) para melhorar a eficiência conforme necessário.
Um modelo incremental é construído como uma tabela normal em sua primeira execução. Nas execuções subsequentes, ele processará apenas os
dados que correspondem aos critérios de filtro incremental – normalmente dados que foram adicionados ou atualizados na tabela de origem desde
a última execução – e inserirá as alterações na tabela base criada na primeira execução. Ao limitar a quantidade de dados transformados
por execução, os modelos incrementais podem reduzir o tempo de execução e os custos dessas transformações. Freqüentemente vemos
materializações incrementais aplicadas a conjuntos de dados de grande volume, como dados de eventos de sites ou dados de plataformas de CRM
de e-mail.
Usuários avançados também podem estar interessados em criar suas próprias materializações personalizadas. Materializações
personalizadas podem ser referenciadas como qualquer outra materialização em todo o seu projeto dbt.
Visualizações materializadas no Redshift
As visualizações materializadas contêm conjuntos de resultados pré-computados e podem ser usadas para acelerar consultas complexas, como
aquelas que envolvem múltiplas junções e agregações. Para criar visualizações materializadas no Redshift, use a linguagem de definição de
dados (DDL) necessária em uma macro de materialização.
Você pode atualizar visualizações materializadas de acordo com uma programação ou configurar a atualização automática para levar em
conta possíveis alterações nos componentes subjacentes da tabela base (dados em nível de linha). Como o Amazon Redshift prioriza a carga de
trabalho do usuário, pode interromper a atualização automática para preservar o desempenho.
O Amazon Redshift usa uma das duas abordagens para atualizar uma visualização materializada:
• Em uma atualização incremental (não confundir com materializações incrementais em dbt), O Amazon Redshift identifica novos registros e
atualiza visualizações materializadas apenas com esses registros. Essa abordagem terá suporte se o SQL subjacente da visualização
contiver operações SQL aritméticas, como SUM e AVG.
• O Amazon Redshift realizará uma atualização completa, que substituirá todos os dados na visualização materializada, nos casos em
que uma atualização incremental não for compatível.
Para atualizar uma visão materializada quando sua lógica SQL subjacente for alterada, você precisará descartar a visão existente e executar
novamente o modelo manualmente. Para obter mais informações sobre as visualizações materializadas do Redshift,
confira a documentação aqui.
Limitando os dados usados no desenvolvimento

Ao desenvolver modelos, muitas vezes você precisa ajustar a lógica antes que ela esteja pronta para ser aplicada a um conjunto de dados
inteiro. A lógica condicional pode ajudá-lo a limitar o uso de dados e reduzir custos durante esta fase do trabalho, sem a necessidade de
escrever e remover manualmente cláusulas LIMIT ou WHERE. Para aplicar lógica condicional de maneira DRY (não se repita), use uma macro que
pode ser chamada entre modelos em todo o seu projeto. O código de exemplo abaixo adiciona a cláusula WHERE quando o destino é
definido como dev:
18
Usando pacotes dbt para manter projetos DRY

Use o pacote dbt_utils para aplicar princípios DRY (não se repita) aos seus modelos de dados. Este pacote contém macros e testes
que podem abordar pontos problemáticos comuns de modelagem de dados e agilizar tarefas como a criação de uma coluna de data,
colunas não dinâmicas e muito mais.
dbt_utils suporta um tipo de materialização insert_by_period, no qual dbt pode inserir registros em uma tabela um período (por exemplo,
dia, semana) por vez. Essa materialização é mais útil para dados de eventos que podem ser processados em períodos discretos ou grandes
cargas de dados que falham em seções específicas.
À medida que sua equipe e seus dados crescem, você pode querer criar e compartilhar pacotes internos para padronizar a lógica e as
definições em vários repositórios dbt. Isso pode ajudar a limitar o código redundante e manter a lógica de negócios e a definição de métricas
consistentes.
Aproveitando o Redshift Spectrum e tabelas externas

Usando o espectro Redshift, Os desenvolvedores do dbt podem consultar diretamente os dados armazenados no Amazon S3. Se sua equipe
estiver em instâncias DC2, os custos de armazenamento e computação serão associados. Quando você precisar de mais
armazenamento, mas não de mais computação, poderá reduzir custos descarregando dados consultados com pouca frequência no Amazon
Redshift para o Amazon S3 e usando o Redshift Spectrum.
Por outro lado, se sua equipe usar uma instância Serverless ou RA3, você poderá adicionar armazenamento sem adicionar computação.
Usar o Redshift Spectrum ainda é benéfico, pois você pode consultar diretamente formatos de dados abertos, incluindo Parquet,
Avro e muito mais, no Amazon S3.
O Redshift Spectrum é ideal para grandes conjuntos de dados com bilhões de linhas por dia, como dados de eventos da Web ou de e-
mail que precisam ser agregados para produzir insights mais significativos. Antes de usar o dbt com esses dados, siga estas práticas
recomendadas:
19
1. Particione os dados no Amazon S3 definindo o prefixo S3 com base nas colunas (ou seja, event_date) frequentemente usadas
no predicado SQL - O particionamento multinível é incentivado se você usa frequentemente mais de um predicado.
2. Defina as estatísticas da tabela (numRows).
Referência ao ajuste de desempenho do Amazon Redshift Spectrum: blog
Para criar e gerenciar tabelas externas no Amazon Redshift, use o pacote de tabelas externas do dbt. Essa funcionalidade permite
criar uma fonte definida por YAML a partir de arquivos armazenados no S3 ou de uma fonte de dados externa e, em seguida, executar um
comando dbt run-operation para criar, atualizar e/ou descartar a fonte.
Para usar o pacote de tabelas externas do dbt com Redshift Spectrum, você deve ter:
• Um bucket S3 existente
• Permissões definidas para criar tabela
• Um banco de dados externo do AWS Glue Data Catalog e um esquema externo do Redshift no qual o dbt preencherá a tabela
externa no Redshift
Essa abordagem reduz a complexidade e permite criar e manter a tabela externa dentro do dbt com dependências downstream levadas
em consideração.
Como alternativa, use crawlers no AWS Glue para criar e gerenciar tabelas externas no Amazon Redshift.
Os rastreadores criarão tabelas externas após extrair as informações necessárias do caminho especificado do Amazon S3.
Para usar rastreadores com Redshift Spectrum:
1. Crie um esquema externo referenciando um banco de dados AWS Glue Data Catalog
2. Crie e execute crawlers que criam tabelas externas no banco de dados do Data Catalog
Para conscientizar o dbt das dependências de uma tabela externa criada por um rastreador, defina a tabela externa como uma origem em
seu projeto dbt.
Essa abordagem pode ser preferida quando você tem pouca ou nenhuma informação sobre as tabelas externas e deseja contar com
rastreadores para extrair as informações, incluindo colunas, tipos de dados e partições. Para atualizar tabelas externas com novas
partições adicionadas ao longo do tempo, execute novamente os rastreadores. Você pode executar novamente um rastreador manualmente
ou de acordo com uma programação.
20
Otimização de código baseada em dados em dbt™ e

Redshift da Amazon
Você pode depurar e otimizar códigos e modelos sistematicamente aproveitando os metadados gerados pelo dbt e o
comando EXPLAIN do Redshift.
Analisando metadados dbt

A cada execução de trabalho, o dbt Cloud gera metadados sobre o tempo, a configuração e a atualização dos modelos em
seu projeto dbt. A API de metadados dbt é um serviço GraphQL que suporta consultas nestes metadados, através do
explorador gráfico ou o próprio endpoint. As equipes podem canalizar esses dados para seu data warehouse e analisá-los
como qualquer outra fonte de dados em uma plataforma de business intelligence. Os usuários do dbt Cloud também podem
usar os dados por meio da guia Model Timing para identificar visualmente os modelos que levam mais tempo e
podem exigir refatoração.
Consultando a API de metadados: usando a API dbt Cloud Metadata, você acessa seus metadados dbt, incluindo
informações sobre linhagem, tempo de execução e documentação.
21
Usando a guia Model Timing, esta guia é uma representação visual da execução do seu trabalho dbt, permitindo identificar modelos de longa
execução.
Usando EXPLAIN e resumo de consulta do Redshift

Os usuários do dbt também podem executar o comando EXPLAIN do Redshift para ver como um modelo será executado no otimizador de consulta.
Observando o plano de consulta completo para um determinado modelo, você pode obter informações sobre:
• Operações realizadas pelo mecanismo de execução
• Tabelas e campos usados por operação
• Volume de dados processados em cada etapa
• Custo de operação
Observe que o comando EXPLAIN na verdade não calcula a consulta.
Você pode usar esta tabela para ajudar a conectar o plano de consulta e o resumo da consulta. Você pode executar esse plano de explicação
no IDE do dbt Cloud ou no Redshift Query Explorer. Depois de identificar uma possível melhoria de desempenho, siga o fluxo de trabalho normal
do dbt criando uma nova ramificação git e atualize todas as alterações necessárias (como materialização, comando sql, etc.) e teste a melhoria.
Conclusão
Em resumo, o Amazon Redshift e o dbt™ trabalham juntos para potencializar seu armazenamento de dados e operações de
transformação. O Amazon Redshift oferece recursos avançados como Serverless, compartilhamento de dados, Redshift Spectrum e consulta
federada para ingestão e consulta de dados otimizadas. Enquanto isso, dbt™
22
permite a transformação eficiente de dados por meio das melhores práticas de engenharia de software, como modularidade, CI/
CD e lógica baseada em SQL. Quando combinados, o Amazon Redshift e o dbt™ permitem que você seja pipelines de
dados confiáveis e contínuos que facilitam a obtenção de insights rápidos de seus dados.
Colaboradores
Os colaboradores deste documento incluem:
• Amy Chen, Gerente de Engenharia de Parcerias, dbtlabs

• Kira Furuichi, redatora técnica, dbtlabs
• Maneesh Sharma, engenheiro sênior de banco de dados Redshift, Amazon Web Services
• Bhanu Pittampally, especialista sênior em análise SA, Amazon Web Services
• Jason Pedreza, especialista em análise SA, Amazon Web Services
• Harshida Patel, Especialista Principal em Análise SA, Amazon Web Services
• Randy Chng, Analytics Acceleration Lab SA, Amazon Web Services
Apêndice: Recomendações para configuração

Permissões e controles de acesso no Redshift
Dada a configuração do Redshift que abordamos anteriormente neste documento, descreveremos recomendações para
configurar permissões e grupos a longo prazo. A configuração que sugerimos aqui não funcionará necessariamente para todas
as equipes, mas fornecerá um ponto de partida para se ajustar aos seus requisitos internos e regulatórios.
Configurando permissões de grupo
Configurar grupos
Primeiro, configure grupos. No Redshift, um grupo é uma coleção de usuários que compartilham as mesmas permissões.
Recomendamos começar com três grupos principais: carregador, transformador e repórter.
• O grupo de carregamento precisa carregar dados no seu banco de dados. Ferramentas de extração e carregamento (EL),
como Fivetran ou Airbyte, se enquadrariam neste grupo.
• O grupo transformador precisa transformar os dados. Os membros deste grupo podem incluir desenvolvedores e aplicativos
dbt como dbt Cloud.
• O grupo repórter precisa ler os dados no banco de dados. Este grupo pode incluir qualquer ferramenta de ML
que precisam consultar modelos em seu warehouse.
23
Para estabelecer cada grupo, execute este comando: crie grupo group_name.
Criar usuários e alocar em grupos
Em seguida, crie usuários e atribua-os a grupos.
Você precisará criar uma conta de usuário de banco de dados para cada pessoa, bem como para cada aplicativo (como
uma ferramenta EL, plataforma de BI ou nuvem dbt), que precise carregar, transformar ou ler dados em seu warehouse.
As ferramentas ETL são geralmente classificadas como carregadores, enquanto o dbt Cloud precisará de permissões de
transformador para executar trabalhos de produção agendados do seu projeto dbt.
O exemplo de código abaixo cria e atribui usuários a grupos:
crie o usuário seu_data_loader
senha '_generate_this_'
no carregador de grupo;
crie o usuário seu_usuário_1
em transformador de grupo;
criar usuário dbt_cloud
em transformador de grupo;
crie usuário sua_bi_tool
em repórter de grupo;
A seguir, precisamos conceder explicitamente as permissões apropriadas a cada grupo.
Permissões do grupo de carregadores
O grupo de carregadores precisará da capacidade de criar esquemas e objetos de esquema. Com permissão para
criar um esquema, o grupo também poderá criar tabelas e visualizações nesse esquema bruto. Se o seu grupo de
carregadores incluir uma ferramenta ELT, certifique-se de que o grupo tenha alguns privilégios em esquemas de informações.
Uma observação: se você estiver em uma instância DC2 e tiver apenas um banco de dados, seu grupo de carregadores será
carregado em seu único banco de dados (o banco de dados analítico no exemplo abaixo). Se você estiver em um Serverless ou RA3
24
instância e tiver vários bancos de dados (por exemplo, brutos e analíticos), seu grupo de carregadores precisaria criar acesso
apenas no banco de dados bruto.
Execute as seguintes linhas abaixo para conceder ao grupo de carregadores as permissões corretas:
conceder criação na análise de banco de dados ao carregador de grupo;
conceder seleção em todas as tabelas no esquema information_schema para agrupar o carregador;
conceder seleção em todas as tabelas no esquema pg_catalog para agrupar o carregador;
Permissões do grupo de transformadores
Para permitir que usuários do grupo de transformadores criem modelos dbt, gerem documentos dbt, e realizar análises, você
precisará conceder-lhes:
• acesso ao uso do esquema
• selecione privilégios em objetos de esquema
• selecione privilégios para futuros objetos de esquema
• selecione privilégios em esquemas de informações
Para conceder acesso ao uso do esquema, execute os seguintes comandos para cada esquema:
conceder uso no esquema my_schema para agrupar o transformador;
conceda seleção em todas as tabelas no esquema my_schema para agrupar o transformador;
alterar privilégios padrão para o usuário my_user no esquema my_user
conceder seleção em tabelas para agrupar transformador;
Você precisará executar novamente esses comandos sempre que adicionar um novo esquema ao seu banco de dados por meio de uma
ferramenta ELT como Fivetran ou Airbyte.
Para conceder acesso para criar objetos no banco de dados, execute:
conceder criação na análise de banco de dados para agrupar transformador;
Para conceder privilégios de seleção em esquemas de informações, execute:
conceder seleção em todas as tabelas no esquema information_schema para agrupar o transformador;
conceder seleção em todas as tabelas no esquema pg_catalog para agrupar o transformador;
25
Permissões do grupo de repórteres
Depois que as tabelas e visualizações forem criadas por meio das funções do transformador, você poderá conceder acesso
de leitura ao grupo repórter, que pode incluir as ferramentas necessárias para consultar esses objetos no recebimento de dados, como
Ferramentas de BI ou ML.
A melhor maneira de gerenciar o acesso a tabelas e visualizações é usar a configuração de concessões do dbt para definir
essas permissões diretamente no dbt. Você pode aplicar a configuração no bloco de configuração de modelos em um arquivo YAML
ou na macro de configuração Jinja no arquivo SQL do modelo.
Em dbt_project.yml, a configuração ficará assim:
modelos:
+subsídios:
selecione: ['repórter']
No arquivo do modelo, ficará assim:
{{ config(grants = {'select': ['repórter']}) }}
Nota: Se você configurou concessões em vários locais (dbt_project.yml, resources.yml e/

ou o arquivo SQL do modelo), o dbt honrará beneficiários mais específicos em vez de beneficiários menos
específicos. Por exemplo: se você tiver concessões diferentes configuradas para um modelo em seus arquivos YAML
e SQL de modelo, o dbt aplicará apenas as concessões aplicadas no arquivo SQL. Você pode aplicar o lado + (adição)
para sinalizar que deseja aplicar o novo grupo além do grupo existente.
Isso seria parecido com:
{{ config(grants = {'+select': ['repórter']}) }}
Para mais informações, confira a documentação.
Métodos de autenticação
O dbt oferece suporte a vários métodos de autenticação para usuários do Redshift, incluindo autenticação simples
baseada em senha, autenticação IAM e conexão por meio de um túnel SSH no dbt Cloud.
Autenticação de nome de usuário e senha
Se você estiver desenvolvendo localmente, ajuste seu profiles.yml local para definir explicitamente a conexão para um
destino usando um nome de usuário e senha:
nome da empresa:
alvo: desenvolvedor
saídas:
26
desenvolvedor:
tipo: redshift
host: hostname.region.redshift.amazonaws.com
usuário: nome de usuário
senha: senha1
porta: 5439
nome do banco de dados: análise
esquema: análise
tópicos: 4
keepalives_idle: 240 # padrão 240 segundos
connect_timeout: 10 # padrão 10 segundos
sslmode: [opcional, defina o sslmode usado para conectar-se ao

banco de dados (caso este parâmetro esteja definido, procurará ca em ~/.postgresql/root.crt)]
Se você estiver usando um gerenciador de segredos, em vez de fornecer sua senha diretamente, use uma
variável de ambiente, que será semelhante a esta:
Senha: "{{env_var('DBT_USER_PASSWORD') }}"
Autenticação com IAM
Para configurar um perfil do Redshift usando autenticação IAM para desenvolvimento local, defina o parâmetro
do método como iam no arquivo profiles.yml local. Observe que não é necessária uma senha ao usar a
autenticação IAM.
Seu profiles.yml local seria parecido com isto:
meu-redshift-db:
alvo: desenvolvedor
saídas:
desenvolvedor:
tipo: redshift
método: eu
cluster_id: [cluster_id]
host: hostname.region.redshift.amazonaws.com
27
usuário: nome de usuário
iam_profile: data_engineer # opcional
iam_duration_seconds: 900 # opcional

criação automática: verdadeiro # opcional
db_groups: ['analistas'] # opcional
# Outras configurações do Redshift:
porta: 5439
nome do banco de dados: análise
esquema: análise
tópicos: 4
keepalives_idle: 240 # padrão 240 segundos
sslmode: [opcional, defina o sslmode usado para conectar-se ao

banco de dados (caso este parâmetro esteja definido, procurará ca em ~/.postgresql/root.crt)]
ra3_node: true # habilita fontes entre bancos de dados
Para todas as configurações potenciais de profiles.yml, verifique este documento.
** A autenticação IAM não é suportada para Redshift Serverless no momento da publicação.
Conexão do túnel SSH

Se você estiver usando o dbt Cloud, poderá usar um túnel SSH para conectar seu projeto dbt ao Redshift.
Navegue até a seção “Projetos” no dbt Cloud e siga as etapas abaixo:
1. Adicione seu nome de host, porta (geralmente 5439 para Redshift) e nome de usuário
2. Salve a conexão e uma chave pública será gerada e exibida na seção “Public
Seção Chave”
3. Copie esta chave para o servidor bastião que autorizará o dbt Cloud a se conectar ao Redshift
Protegendo PII: Mascaramento Dinâmico de Dados com dbt

Muitas vezes, você desejará que os valores verdadeiros das colunas sejam visualizados apenas por um determinado subconjunto de usuários
em nosso data warehouse. Colunas que você pode querer ocultar geralmente contêm PII confidenciais que apenas usuários administradores devem
28
poder visualizar e acessar. Para ocultar ou distorcer esses dados para determinados usuários, você pode criar uma macro dbt
para estabelecer uma lógica de mascaramento de dados que pode ser usada em modelos de dados. Basicamente, esta macro
usa o valor current_user() do Redshift para determinar se o valor verdadeiro da coluna ou um valor hash da coluna é mostrado. Um
mergulho mais profundo na implementação deste tipo de mascaramento de dados no Redshift pode ser encontrado neste
discurso e neste repositório Github. O Amazon Redshift agora oferece suporte nativo ao mascaramento dinâmico de dados.
Revisões de documentos
Data Descrição
Março de 2023 Primeira Publicação
29

Amazon Redshift DBT Best Practices - Paper

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Amazon Redshift DBT Best Practices - Paper

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Melhores práticas para alavancar

Opções de implantação do Amazon Redshift

Redshift sem servidor

Casos de uso do Amazon Redshift

Fluxo típico de data warehouse para Amazon Redshift

Conceitos-chave para compreender o dbt™

Arquitetura e benefícios do dbt

Documentação e tratamento de dependências

Tornando o código modular usando macros

Iniciando o desenvolvimento do dbt com pacotes

Documentação enquanto você codifica com dbt

Recursos para aprender mais

Otimizando uma arquitetura Amazon Redshift com dbt

Conectando dbt ao Amazon Redshift

Práticas recomendadas de dbt + Redshift

Escolha um cluster Redshift ou endpoint sem servidor

Plano para garantia de qualidade

Configure seu ambiente de data warehouse (vários clusters Redshift)

Configure seu ambiente de data warehouse (cluster Redshift único ou endpoint)

Defina seus ambientes como alvos no dbt

Configure controles de acesso baseados em funções (RBAC), se necessário

Use as visualizações de ligação tardia do Redshift para consolidação downstream

Ajuste de desempenho do seu dbt - Amazon Redshift Environment

Usando chaves de classificação e distribuição

Armazenando dados com eficiência

Configurar o gerenciamento de carga de trabalho do Amazon Redshift (WLM)

Escolhendo materializações de modelo apropriadas

Visualizações materializadas no Redshift

Limitando os dados usados no desenvolvimento

Usando pacotes dbt para manter projetos DRY

Aproveitando o Redshift Spectrum e tabelas externas

Otimização de código baseada em dados em dbt™ e Amazon Redshift

Analisando metadados dbt

Usando EXPLAIN e resumo de consulta do Redshift

Apêndice: Recomendações para definir permissões e controles de acesso no Redshift

Configurando permissões de grupo

Autenticação de nome de usuário e senha

Autenticação com IAM

Conexão do túnel SSH

Protegendo PII: Mascaramento Dinâmico de Dados com dbt

• Facilite o código reutilizável com macros e instruções ref.

Opções de implantação do Amazon Redshift

Redshift sem servidor

Como funciona o Amazon Redshift

Casos de uso do Amazon Redshift

Inovação por meio de aprendizado de máquina

Compartilhamento de dados e colaboração

Insights operacionais em tempo real

Fluxo típico de data warehouse para Amazon Redshift

ser um bucket do Amazon Simple Storage Service (Amazon S3).

Conceitos-chave para compreender o dbt™

Arquitetura e benefícios do dbt

Documentação e tratamento de dependências

Tornando o código modular usando macros

Iniciando o desenvolvimento do dbt com pacotes

A funcionalidade comum do pacote inclui:

• Testes úteis que estão fora dos testes padrão do dbt

Documentação enquanto você codifica com dbt

Recursos para aprender mais

Otimizando uma arquitetura Amazon Redshift com

Conectando dbt ao Amazon Redshift

Práticas recomendadas de dbt + Redshift