AWS – Arquitetura Redshift

Olá pessoal, como alguns devem saber, estou no Peru em um projeto de Bigdata na AWS. Vou aproveitar esses 2 meses por aqui para focar em AWS.

Para começar, vamos falar um pouco de Redshift, que é um “PostgreSQL” (8.0) redesenhado para trabalhar com OLAP/DW em um grande volume da dados (escalável até Petabytes), armazenando-os em formato colunar. E quando falamos em grande volume de dados, um pequeno deslize pode ter um grande impacto. Nesta sequência de artigos pretendo dedicar um pouco à modelagem no Redshift.

Por ser um PostgreSQL, traz toda a vantagem e compatibidade de um banco de dados que já está extremamente maduro no mercado. Isso quer dizer que, para fazer uma conexão no Redshift, usamos as mesmas técnicas (padrões de mercado) que as usadas no seu “pai”: JDBC e ODBC.

A arquitetura de Cluster no Redshift pode ser single (um node) ou multi-node (mais de um node). Sempre que o cluster for multi-node, haverá um Leader Node (LN) que coordenará o trabalho dos Compute Nodes (CN) e fará a interface com os clients. Já os CN neste cenários, estarão isolados em uma rede que não permite acesso direto dos clients.

Os Leader Nodes recebem requisições externas, criam os planos de execução e os entregam para os CN. O interessante é que ele só distribui tarefas referentes aos dados que os CN armazenam. Se você tiver uma tabela com dados particionados por mês, o CN só recebe requisição de trabalho sobre os meses que ele possui. Queries que não envolvem dados de usuários são executadas no próprio LN.

Os Compute Nodes processam os planos de execução recebidos e os devolvem para que o LN possa consolidar/agregar e então retornar os dados para o client. Estas são as instances que escolhemos no momento de criação do cluter (veremos em um próximo artigo) – não escolhemos instances do LeaderNodes.

Cada CN, por sua vez, é particionado em Slices, que nada mais é do que uma parte de memória e disco isolada logicamente, onde são executados os SQL. O LN é responsável por distribuir os dados entre os Slices e também os SQLs. Desta forma, o CN trabalha em paralelo (isto, é claro, se forem escolhidas partitions keys apropriadas para suas tabelas) para atender as demandas executando uma query por Slice por vez.  A quantidade de Slices depende do NodeType que escolhemos. Veja a tabela:

Por fim, cada cluster pode ter até 60 user databases (DB), que ficarão armezenados nos CN. Vale enfatizar que o Redshift retirou suporte a algumas funcionalidades do PostgreSQL visando performance. Portanto, tenha bastante cuidado quando for utilizá-lo para operações que envolvem poucas linhas.

Era isso. Em seguida devo escrever sobre como criar um Cluster. Qualquer dúvida, pontos a acrescentar, retirar ou alterar, deixe nos comentários.

Até a próxima.