Modelagem Dimensional e ETL no Redshift

Pesquisei o banco de dados Redshift da Amazon como uma possível substituição futura para nosso data warehouse. Minha experiência sempre foi no uso da modelagem dimensional e dos métodos de Ralph Kimball, por isso foi um pouco estranho ver que o Redshift não suporta recursos como o tipo de dados serial para colunas de incremento automático.

No entanto, há uma postagem recente no blog da AWS Big Data sobre como otimizar o Redshift para um esquema em estrela: https://blogs.aws.amazon.com/bigdata/post/Tx1WZP38ERPGK5K/Optimizing-for-Star-Schemas - e - Intercalado - Classificação na Amazon - Redshift

A pergunta que tenho é sobre qual é a melhor prática para carregar um esquema em estrela no Redshift? Não consigo encontrar essa resposta em nenhuma documentação do Redshift.

Estou inclinado a importar meus arquivos do S3 para tabelas temporárias e, em seguida, usando o SQL para fazer transformações, como pesquisas e gerar chaves substitutas, antes de inseri-las nas tabelas de destino.

É isso que os outros estão fazendo atualmente? Existe uma ferramenta ETL que vale o dinheiro para facilitar isso?

Você está definitivamente no caminho certo com Kimball ao invés de usar o Redshift.

Existem vários padrões para isso, eu os usei em diferentes casos de uso

1. Padrão "ELT" - Carregue as tabelas de origem para o redshift completo, não faça nenhuma transformação significativa até que os dados tenham sido carregados. Para isso, você pode carregar para o s3 e usar o comando redshift copy ou eu recomendaria o uso de "Serviços de migração de dados da AWS", que podem sincronizar uma fonte (por exemplo, mysql ou postgres) com um destino (por exemplo, redshift). Em seguida, execute regularmente processos sql no redshift para preencher dims então fatos. Você pode usar ferramentas baseadas em nuvem de terceiros para "simplificar" esse processo, se desejar - como o Matillion (eu não recomendo o uso de uma ferramenta de terceiros)
2. "Padrão ETL" - Transforme os dados em voo, usando o apache spark. e carregue as dims e fatos no redshift spark-> s3-> redshift. Eu usei EMR para isso, o que é bom. esta também é a abordagem adotada se você usar o AWS Glue
3. Não transforme! - semelhante a 1), mas apenas use as tabelas que foram carregadas.

Observe que, às vezes, Redshift funciona melhor se você tiver uma tabela ampla com valores repetidos, em vez de um fato e dimensões. A razão para isso é que a abordagem colunar permite que o Redshift comprima os diferentes valores até um nível bastante eficiente. Eu não tenho uma fórmula para quando usar muitas dimensões versus uma mesa larga e plana, a única maneira é experimentá-la e ver!

Alguns links

AWS DMS para taret Redshift

AWS Glue

Para ETL, há o AWS Glue. É um serviço ETL gerenciado, sem servidor, carregado no Redshift (entre outras coisas).

https://aws.amazon.com/glue/

Atualmente, estou lidando com uma tarefa semelhante. É para construir o processo ETL e projetar o modelo dimensional. Pesquisei bastante a melhor maneira de lidar com isso e encontrei uma incrível fonte útil de técnicas que definitivamente devemos aplicar ao trabalhar com o MPP.

Para responder a pergunta

A pergunta que tenho é sobre qual é a melhor prática para carregar um esquema em estrela no Redshift?

não deixe de dar uma olhada neste recurso . Aposto que você achará incrivelmente útil. É um documento de ~ 35 páginas com técnicas poderosas para alavancar o uso de lojas colunares do MPP. Ele suporta os comentários que você vê como

Observe que, às vezes, Redshift funciona melhor se você tiver uma tabela ampla com valores repetidos, em vez de um fato e dimensões. A razão para isso é que a abordagem colunar permite que o Redshift comprima os diferentes valores até um nível bastante eficiente. Eu não tenho uma fórmula para quando usar muitas dimensões versus uma mesa larga e plana, a única maneira é experimentá-la e ver!

comentário por Jon Scott

Espero que você ache tão útil quanto eu

Eu acho que o carregamento do S3 é um padrão comum.

Precisávamos impor restrições de exclusividade, então escolhemos gravar no Postgres e replicar novos dados para redshift a cada 10 minutos.

Usamos https://github.com/uswitch/blueshift para carregar no Redshift.

Como o Redshift é um banco de dados colunar, o desempenho do armazenamento e da consulta será diferente dos modelos RDBMS. A otimização para um banco de dados colunar também é diferente. Como geralmente há menos E / S de disco e menos dados carregados do disco, as consultas são mais rápidas.

Em termos da postagem do blog da AWS que você menciona, considero que você examinou essas recomendações e considerou quais opções funcionam melhor para seus dados de distribuição, chaves, cursores, gerenciamento de carga de trabalho etc. e tem pelo menos uma boa idéia da abordagem você usaria. Acho mais fácil trabalhar com uma representação visual; você pode considerar um diagrama de banco de dados rápido e sujo, mostrando como suas tabelas existentes migrariam para o Redshift. Cobrindo os principais para ter uma ideia da quantidade de dados que está indo para onde. E certamente usaria os drivers ODBC / JDBC da Amazon, carregar grandes quantidades de dados pode ser problemático em qualquer caso, muito menos mudar para um tipo de banco de dados diferente.

Quanto ao ETL / ELT, existe o AWS Glue, como outros pôsteres mencionaram. E sim, existem várias ferramentas, algumas das quais são gratuitas. A Amazon possui um Guia de práticas recomendadas do banco de dados , que também pode ajudá-lo. Uma dica que eu vi em outros fóruns é carregar seus dados o mais bruto possível e fazer as transformações no Redshift. Isso o levaria a um processo ELT. Com tantas opções, talvez olhar para uma comparação dos 2 métodos ajudaria. Aqui está um artigo de blog da Panopoly, explicando as diferenças, que pode ajudá-lo a decidir o caminho.

A Amazon publicou recentemente algumas práticas recomendadas para ETL no Redshift

https://aws.amazon.com/blogs/big-data/top-8-best-practices-for-high-performance-etl-processing-using-amazon-redshift/

Em uma apresentação sobre este tópico Tony Gibbs, o AWS Solution Architect recomenda o seguinte padrão para cargas no estilo UPSERT:

1. Carregar dados CSV (do S3) na tabela intermediária
2. Excluir linhas correspondentes da tabela prd

3. Inserir dados do estágio

   BEGIN;
   CREATE TEMP TABLE staging(LIKE …); — copies dist keys
   copy staging from ’s3://… COMPUTE OFF;
   DELETE deep_dive d
   USING staging s WHERE d.aid = s.aid;
   INSERT INTO deep_dive SELECT * FROM staging
   DROP table staging;
   COMMIT;

Quando possível, prefira DROP TABLE ou TRUNCATE para DELETE para evitar linhas fantasmas

Veja um vídeo da palestra e dos slides .

Em nossa equipe, normalmente carregamos dados no Redshift diretamente do S3 usando a instrução SQL COPY .

E gerencie todo o nosso ETL usando a excelente ferramenta Apache Airflow .

Também usamos serviços de integração como Stich, que gravam diretamente no Redshift e, em seguida, usamos CREATE TABLE LIKE e SELECT INTO para mover os dados para outro esquema.