Deep dive de Amazon Redshift

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Hugo Rozestraten – Database and Big Data Solutions Architect – AWS
José Otávio Rizzatti Ferreira – Data Engineer - VivaReal
Junho 22, 2017
Deep Dive em Amazon Redshift
Camada de Armazenamento e Ciclo de Vida das Queries

Visão Geral - Deep Dive em Amazon Redshift
• Amazon Redshift história e desenvolvimento
• Arquitetura do Cluster
• Conceitos e terminologia
• Deep dive em Storage
• Ciclo de vida de Consultas
• Features novas e esperadas;

Amazon Redshift História e Desenvolvimento

Columnar
MPP
OLAP
AWS Identity
and Access
Management
(IAM)
Amazon
VPC
Amazon SWF
Amazon S3 AWS KMS Amazon
Route 53
Amazon
CloudWatch
Amazon
EC2
PostgreSQL
Amazon Redshift

Fevereiro 2013
Junho 2017
> 100 Patches Significantes
> 150 Features Significantes

Arquitetura do Cluster Amazon Redshift

Arquitetura do Cluster Amazon Redshift
Massivamente paralelo, ”shared nothing”
Nó Líder
• SQL ponto de conexão
• Armazenamento metadados
• Coordena o processamento paralelo de
SQL
Nós de Computação
• Storage colunar local
• Executa queries em paralelo
• Carga, backup e recuperação
10 GigE
(HPC)
Ingestion
Backup
Restore
SQL Clients/BI Tools
128GB RAM
16TB disk
16 cores
S3 / EMR / DynamoDB / SSH
JDBC/ODBC
128GB RAM
16TB disk
16 cores
Nó de
Computação
128GB RAM
16TB disk
16 cores
Nó de
Computação
128GB RAM
16TB disk
16 cores
Nó de
Computação
Nó
Líder

Componentes dos nós de computação
e Nó Líder

128GB RAM
16TB disk
16 cores
128GB RAM
16TB disk
16 cores
Nó de
Computação
128GB RAM
16TB disk
16 cores
Nó de
Computação
128GB RAM
16TB disk
16 cores
Nó de
Computação
Nó Líder

• Interpretar & re-escrita
• Otimizador e planejamento
• Gerador de código
• Input: optimized plan
• Output: >=1 C++
functions
• Compilador
• Agendador de tarefas
• WLM
• Admissão
• Agendamento
• PostgreSQL tabela de
• catálogos
128GB RAM
16TB disk
16 cores
128GB RAM
16TB disk
16 cores
Nó de
Computação
128GB RAM
16TB disk
16 cores
Nó de
Computação
128GB RAM
16TB disk
16 cores
Nó de
Computação
Nó Líder

• Processo de execução de Query
• Backup & restore
• Replicação
• Storage Local
• Discos
• ”Slices”
• Tabelas
• Colunas
• Blocos
128GB RAM
16TB disk
16 cores
128GB RAM
16TB disk
16 cores
128GB RAM
16TB disk
16 cores
128GB RAM
16TB disk
16 cores
Nó Líder
Nó de
Computação
Nó de
Computação
Nó de
Computação

Desenhado para redução de I/O
Storage Colunar
Compressão de Dados
”Zone Maps” - mapeamento
aid loc dt
CREATE TABLE deep_dive (
aid INT --audience_id
,loc CHAR(3) --location
,dt DATE --date
);
aid loc dt
1 SFO 2016-09-01
2 JFK 2016-09-14
3 SFO 2017-04-01
4 JFK 2017-05-14
• Acessando dt com row:
o Lê tudo
o IO desnecessário

aid loc dt
Storage Colunar
,dt DATE --date
);
aid loc dt
1 SFO 2016-09-01
2 JFK 2016-09-14
3 SFO 2017-04-01
4 JFK 2017-05-14
• Acessando coluna dt com storage colunar
o Só scanea blocos para colunas
relevantes

Storage Colunar
aid loc dt
aid INT ENCODE LZO
,loc CHAR(3) ENCODE BYTEDICT
,dt DATE ENCODE RUNLENGTH
);
aid loc dt
1 SFO 2016-09-01
2 JFK 2016-09-14
3 SFO 2017-04-01
4 JFK 2017-05-14
• Colunas grow and shrink independently
• Reduz requiremento de storage
• Reduz I/O

Desenhado para Redução I/O
Storage Colunar
aid loc dt
1 SFO 2016-09-01
2 JFK 2016-09-14
3 SFO 2017-04-01
4 JFK 2017-05-14
aid loc dt
,dt DATE --date
);
• Metadados In-memory
• Contém valores MIN e MAX para a coluna
• Retira efetivamente blocos que não contém
dados para uma determinada query
• Elimina I/O desnecessário

SELECT COUNT(*) FROM deep_dive WHERE dt = '09-JUNE-2013'
MIN: 01-JUNE-2013
MAX: 20-JUNE-2013
MIN: 08-JUNE-2013
MAX: 30-JUNE-2013
MIN: 12-JUNE-2013
MAX: 20-JUNE-2013
MIN: 02-JUNE-2013
MAX: 25-JUNE-2013
Tabela sem Ordenação
MIN: 01-JUNE-2013
MAX: 06-JUNE-2013
MIN: 07-JUNE-2013
MAX: 12-JUNE-2013
MIN: 13-JUNE-2013
MAX: 18-JUNE-2013
MIN: 19-JUNE-2013
MAX: 24-JUNE-2013
Ordenado por Data
Zone Maps

Terminologia e Conceitos: Ordenção de Dados
• Objetivos:
• Ordem física das linhas da tabela baseada em uma coluna
• Otimiza a eficiência de Zone Maps
• Habilita operações de MERGE JOIN
• Impacto:
• Habilita otimização de leitura utilizando zone maps
• Redução de I/O
• Habilitada pela propriedade SORTKEY, definida entre 1(uma) ou mais colunas
• SORTKEY ótima depende:
• Padrões de queries
• Perfil dos dados
• Necessidade de negócio

Terminologia e Conceitos: Ordenção de Dados
Uma slice pode ser pensada como
“virtual compute node”
• Unidade de particionamento dos dados
• Processamento em paralelo
Fatos sobre fatias ”Slices”:
• Cada nó de computação tem 2, 16, ou 32 slices
• Registros são distribuídas em slices
• Uma ”slice” processa somente seu dado

Distribuição de Dados
• Estilo de Distribuição é uma propriedade da tabela que define como o dados será
distribuído através do Cluster:
• KEY: O valor é ”hashed”, o mesmo valor vai para a mesma localização
• (slice)
• ALL: A tabela inteira vai para os primeiros slices de todos os Nós
• EVEN: Round robin
• Objetivo:
• Distribuir o dado igualmente para processamento paralelo
• Minimiza a movimentação de dados durante o processamento
• da query
KEY
ALL
Node 1
Slice
1
Slice
2
Node 2
Slice
3
Slice
4
Node 1
Slice
1
Slice
2
Node 2
Slice
3
Slice
4
Node 1
Slice
1
Slice
2
Node 2
Slice
3
Slice
4
EVEN

Distribuição dos dados Key: Exemplo
,dt DATE --date
) DISTSTYLE (EVEN|KEY|ALL);
CN1
Slice 0 Slice 1
CN2
Slice 2 Slice 3
Table: deep_dive
User
Columns
System
Columns
aid loc dt ins del row

Distribuição dos dados : EVEN Exemplo
,dt DATE --date
) DISTSTYLE EVEN;
CN1
Slice 0 Slice 1
CN2
Slice 2 Slice 3
INSERT INTO deep_dive VALUES
(1, 'SFO', '2016-09-01'),
(2, 'JFK', '2016-09-14'),
(3, 'SFO', '2017-04-01'),
(4, 'JFK', '2017-05-14');
Table: loft_deep_dive
User Columns System Columns
Rows: 0 Rows: 0 Rows: 0 Rows: 0
(3 User Columns + 3 System Columns) x (4 slices) = 24 Blocks (24 MB)

Distribuição dos dados: KEY Exemplo #1
,dt DATE --date
) DISTSTYLE KEY DISTKEY (loc);
CN1
Slice 0 Slice 1
CN2
Slice 2 Slice 3
(1, 'SFO', '2016-09-01'),
(2, 'JFK', '2016-09-14'),
(3, 'SFO', '2017-04-01'),
(4, 'JFK', '2017-05-14');
Rows: 2 Rows: 0 Rows: 0
Rows: 0Rows: 1
Rows: 2Rows: 0Rows: 1

Distribuição dos dados: KEY Exemplo #2
,dt DATE --date
) DISTSTYLE KEY DISTKEY (aid);
CN1
Slice 0 Slice 1
CN2
Slice 2 Slice 3
(1, 'SFO', '2016-09-01'),
(2, 'JFK', '2016-09-14'),
(3, 'SFO', '2017-04-01'),
(4, 'JFK', '2017-05-14');

Distribuição dos dados: ALL Exemplo
CREATE TABLE loft_deep_dive (
,dt DATE --date
) DISTSTYLE ALL;
CN1
Slice 0 Slice 1
CN2
Slice 2 Slice 3
(1, 'SFO', '2016-09-01'),
(2, 'JFK', '2016-09-14'),
(3, 'SFO', '2017-04-01'),
(4, 'JFK', '2017-05-14');
Rows: 0 Rows: 0
(3 User Columns + 3 System Columns) x (2 slice) = 12 Blocks (12 MB)
Rows: 0Rows: 1Rows: 2Rows: 4Rows: 3
Rows: 0Rows: 1Rows: 2Rows: 4Rows: 3

Terminologia e Conceitos: Distribuição dos dados
KEY
• A chave que cria a distribuição
• Joins são realizados entre tabela fato e grandes
dimensões
• Otimiza merge joins e group by
ALL
• Dimensões pequenas ou médias (< 2-3M)
EVEN
• Quando nenhuma chave faz uma distribuição
boa

Storage Deep Dive: Discos
• Amazon Redshift utiliza storage locais conectados
aos nós
• Nós de computação têm 2.5-3x da capacidade que
informamos
• 1, 3, 8, ou 24 discos dependem do tipo de nó
• Cada disco é dividido em partições
• Local data storage, acessado pelo CN (nó de comp.)
• Dados espelhados acessados por nó remoto CN
• Partições são raw devices
• Storage locais são efêmeros por natureza
• Tolerante a múltiplas falhas de disco em um mesmo
nó

Storage Deep Dive: Blocos
Dados de uma Coluna data são persistidos em 1 MB
bloco imutável
Cada bloco contém metadados in-memory:
• Zone Maps (valores de MIN/MAX)
• Localização do bloco anterior e próximo
• Blocos são comprimidos individualmente com 1 dos 11
algorítimos de compressão
Um bloco inteiro pode conter de 16 a 8.4 milhões de
valores

Storage Deep Dive: Colunas
• Colunas: Estrutura lógica acessível via SQL
• Estrutura física são blocos duplamente ligados
• Estas cadeias de blocos (”blockchains”) existem em cada ”slice” para
cada coluna
• Todas as cadeias de blocos ordenados ou não compõem uma coluna
• Propriedades das colunas:
• Distribution Key
• Sort Key
• Compression Encoding
• Colunas aumentam e diminuem de tamanho independentemente, 1 bloco
por vez
• Três colunas de sistema por Slice por MVCC (Multiversion Concurrency
Control

Propriedade dos Blocos: considerações para
desenho
• Poucas escritas:
• Processamento Batch é otimizado
• Para 1MB + blocos imutáveis, blocos na escrita para evitar
fragmentação
• Escrita pequena (~1-10 linhas) mesmo custo que (~100 K linhas)
• UPDATE e DELETE:
• Blocos imutáveis significam que nós deletamos linhas quando
ocorre um UPDATE ou DELETE
• Rodar VACUUM ou DEEP COPY para remover linhas fantasmas
das tabelas

Propriedade das Colunas: considerações para
desenho
• Compressão:
• COPY analisa automaticamente dados nas cargas de tabelas, quando em
tabelas vazias
• ANALYZE COMPRESSION checa a existência e propõe algoritmos de
compressão para cada coluna
• Mudar o tipo de compressão implica em um ”rebuild” da tabela
• DISTKEY e SORTKEY influenciam performance (ordens de magnitude)
• Distribution keys:
• Uma chave pobre DISTKEY pode introduzir um vício de dados em slices
• Uma query termina tão rápido quanto a menor slice termina de processar
• Sort keys:
• A chave de ordenação é tão efetiva quanto o perfil dos dados permitir
• Seletividade necessita ser considerada

Conceitos e Terminologia: Slices
Uma slice é como um nó de computação virtual
• Unidade de particionamento
• Processamento paralelo de queries
Fatos sobre slices:
• Cada nó de computação tem 2, 16, ou 32 slices
• Registros de uma tabela são distribuídos em Slices
• Uma slice processa somente seus dados

Terminologia de Execução das queries
Step(passo):
• Uma operação individual necessária durante a execução da query
• Steps são combinados para permitir que os nós consigam realizar Joins
• Exemplos: scan, sort, hash, aggr
Segment(segmentos):
• A combinação de vários steps pode ser realizado por um único processo
• A menor unidade de compilação executada por uma slice
• Segmentos dentro de um fluxo podem rodar em paralelo
Stream(fluxo):
• Um conjunto de segmentos
• Saída para o próximo stream ou Client SQL

Vizualização Streams, Segments, e Steps
Stream 0
Segment 0
Step 0 Step 1 Step 2
Segment 1
Step 0 Step 1 Step 2 Step 3 Step 4
Segment 2
Step 0 Step 1 Step 2 Step 3
Segment 3
Step 0 Step 1 Step 2 Step 3 Step 4 Step 5
Stream 1
Segment 4
Segment 5
Segment 6
Stream 2
Segment 7
Step 0 Step 1
Segment 8
Step 0 Step 1
Time

Ciclo de vida de Query
client
JDBC ODBC
Leader Node
Parser
Query Planner
Code Generator
Final Computations
Gera o código
para todos os
segmentos de
um stream
Plano de Execução
Compute Node
Receive Compiled
Code
Run the Compiled
Code
Return results to
Leader
Compute Node
Receive Compiled
Code
Run the Compiled Code
Return results to
Leader
Return results to client
Segments dentro de
um stream são
executados em
paralelo. Cada passo é
executado de forma
serial dentro de um
segment.

Execução de Query Deep Dive: Nó Líder
• Nó Líder recebe uma query e interpreta o SQL
• Interprete produz a lógica de representação da query original
• Esta ”árvore”da query é a entrada para o otimizador (volt)
• Volt re-escreve a query para maximizar a eficiência
• Algumas vezes uma query simples é re-escrita como vários comandos executores
em background
• A query re-escrita é então enviada ao planejador que gera 1+ planos de query para
execução com máxima performance
• O plano é enviado para execução, aonde é traduzido em steps, segments, e
streams
• O plano traduzido é envidado ao gerador de código, que gera uma função C++ para
cada segment
• O código C++ é compilado com gcc para um arquivo .o e distribuído para os nós de
computação.

Execução - Deep Dive: Nós de Computação
• Slices executam segmentos da query em paralelo
• Segmentos executáveis são criados para cada stream em
sequência
• Quando os nós de computação terminam, eles retornam os
resultados para o nó líder para o processamento final
• O nó líder faz o ”merge” dos dados em um único resultado
e endereçam qualquer necessidade de ordenação ou
agregação
• O Nó Líder retorna para o cliente

Execução da query
Stream 0
Segment 0
Segment 1
Segment 2
Segment 3
Stream 1
Segment 4
Segment 5
Segment 6
Stream 2
Segment 7
Step 0 Step 1
Segment 8
Step 0 Step 1
Time
Stream 0
Segment 0
Segment 1
Segment 2
Segment 3
Stream 1
Segment 4
Segment 5
Segment 6
Stream 2
Segment 7
Step 0 Step 1
Segment 8
Step 0 Step 1
Stream 0
Segment 0
Segment 1
Segment 2
Segment 3
Stream 1
Segment 4
Segment 5
Segment 6
Stream 2
Segment 7
Step 0 Step 1
Segment 8
Step 0 Step 1
Stream 0
Segment 0
Segment 1
Segment 2
Segment 3
Stream 1
Segment 4
Segment 5
Segment 6
Stream 2
Segment 7
Step 0 Step 1
Segment 8
Step 0 Step 1
Slices
0
1
2
3

Considerações de desenho do Redshift slices
DS2.8XL Compute Node
Capacidade de ingestão:
• Cada ”Slice” (fatia) pode processar um arquivo por vez:
• Streaming decompression
• Parse
• Distribute
• Write
Performance parcial de um Nó, utilizando uma só slice, atinge
6.25% do potencial ativo
0 2 4 6 8 10 12 141 3 5 7 9 11 13 15

Considerações de desenho do Redshift slices
Use ao menos o mesmo número
de arquivos que você tem de
Slices no seu Cluster
Com16 arquivos de input, todas
as slices estarão trabalhando
para maximizar a performance de
carga
COPY continua escalando
linearmente conforme adiciona
nós
16 Input Files
DS2.8XL Compute Node
0 2 4 6 8 10 12 141 3 5 7 9 11 13 15

Preparação dos Dados para o COPY do Redshift
Exporte dados de uma origem
• CSV Recommend (Simple Delimiter ',' or '|')
• Be aware of UTF-8 varchar columns (UTF-8 take 4 bytes per char)
• Be aware of your NULL character (N)
• GZIP Compress Files
• Split Files (1MB – 1GB after gzip compression)
Muitas opções úteis do COPY para PoCs e conhecimento dos dados
• MAXERRORS
• ACCEPTINVCHARS
• NULL AS

Ferramentas abertas
https://github.com/awslabs/amazon-redshift-utils
https://github.com/awslabs/amazon-redshift-monitoring
https://github.com/awslabs/amazon-redshift-udfs
Admin scripts
Scripts para diagnósticos no seu cluster
Admin views
Utilitários para gerenciamento do cluster, gera DDL de schema, etc.
ColumnEncodingUtility
Habilidade de aplicar o encoding ótimo para um schema estabelecido com dados
Amazon Redshift Engineering’s Advanced Table Design Playbook
https://aws.amazon.com/blogs/big-data/amazon-redshift-engineerings-advanced-
table-design-playbook-preamble-prerequisites-and-prioritization/

Features adicionadas recentemente
Novo Data Type – TIMESTAMPTZ
Suporte para Timestamp with Time zone
Multi-byte Object Names
Suporte para Multi-byte (UTF-8) caracteres para tabelas, colunas e outros nomes de objetos
Limite de conexões de usuários
Agora você pode limitar o número de conexões à base de dados um usuário é autorizado a fazer de
maneira concorrente
Automatic Data Compression para CTAS
Todas as tabelas novas terão o enconding default
New Column Encoding - ZSTD
Approximate Percentile Functions

Features adicionadas recentemente
Melhorias de Performance
• Vacuum (10x faster for deletes)
• Snapshot Restore (2x faster)
• Queries (Up to 5x faster)
Copy Pode extender Sorted Region on Single Sort Key
• Não é necessário vacuum para carregar em ordem de sort
Enhanced VPC Routing
• Restrict S3 Bucket Access
Schema Conversion Tool - One-Time Data Exports
• Oracle
• Teradata
Schema Conversion Tool
• Vertica
• SQL Server

Amazon Redshift Spectrum
Rode queries SQL diretamente sobre dados no S3
Alta concorrência: múltiplos
clusters do mesmo dado
Sem ETL: Query dos dados no local
em múltiplos formatos abertos
Suporta Redshift SQL
S3
SQL

O VivaReal é um Marketplace
Imobiliário que busca ajudar
pessoas a encontrar a casa dos
seus sonhos.
O time de Data Analytics é o
responsável por consolidar todos
os dados gerados no VivaReal e
democratizar o acesso a eles.
“O Redshift era
maduro e
simples de usar
e foi a escolha
óbvia para o
nosso volume de
dados”

Escalabilidade de acordo com
aumento de tráfego.
Processamento de grandes
volumes de dados sem perda de
performance.
Fácil integração com dados
transacionais para efeitos de
análise.
O Desafio

Monitora e
controla recursos
por query
Notificações, abort
e repriorização para
long-running / bad
queries
Templates para os
use cases comuns
Em breve: Monitoramento de regras para Query

BI tools SQL clientsAnalytics tools
Client AWS
Redshift
ADFS
Corporate
Active Directory IAM
Amazon Redshift
ODBC/JDBC
User groups Individual user
Single Sign-On
Identity providers
Novo Driver
ODBC/JDBC.
Grab the ticket
(userid) and get a
SAML assertion.
Em Breve: IAM Authentication

VACUUM automático e incremental
• Reclama espaço e ordena quando o cluster está Idle
• Vacuum é iniciado quando a performance pode ser melhorada
• Melhora performance de query e ETL
Em breve: Muito mais …

Lembre-se de avaliar a
apresentação!

Deep dive de Amazon Redshift

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Deep dive de Amazon Redshift

Semelhante a Deep dive de Amazon Redshift (20)

Mais de Amazon Web Services LATAM

Mais de Amazon Web Services LATAM (20)

Último

Último (8)

Deep dive de Amazon Redshift

Notas do Editor