O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Path to the future #5 - Melhores práticas de data warehouse no Amazon Redshift

341 visualizações

Publicada em

O Amazon Redshift usa uma variedade de inovações para obter um desempenho de consulta muito elevado em conjuntos de dados com tamanhos variando de centenas de gigabytes a um petabyte ou mais.

Nessa sessão será exposto boas práticas do Amazon Redshift, o dataware da AWS. Tem como intuito de expor de formas efetivas de migração, cargas de dados, realizar tunnings nas suas consultas.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Path to the future #5 - Melhores práticas de data warehouse no Amazon Redshift

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Hugo Rozestraten, Solutions Architect, AWS Setembro de 2016, Rio de Janeiro Melhores práticas de data warehouse no Amazon Redshift
  2. 2. Arquitetura do Redshfit Ingestão • COPY • Primary keys e arquivos de Manifesto • Higienização de Dados • Novas features para ingestão • Restore para Tabelas • Auto Compressão/Compres são por sort key Features • Novas Funções • UDFs • Interleaved sort keys Dicas de Migração Otimização de Ambientes • Cargas de trabalho • WLM • Console O que esperar desta Sessão
  3. 3. Rápido, Simples, data warehouse escalável a PB, por menos de $1,000/TB/ano Amazon Redshift
  4. 4. Amazon Redshift entrega Performance “[Amazon] Redshift is twenty times faster than Hive.” (5x–20x reduction in query times) link “Queries that used to take hours came back in seconds. Our analysts are orders of magnitude more productive.” (20x–40x reduction in query times) link “…[Amazon Redshift] performance has blown away everyone here (we generally see 50– 100x speedup over Hive).” link “Team played with [Amazon] Redshift today and concluded it is ****** awesome. Un-indexed complex queries returning in < 10s.” “Did I mention it's ridiculously fast? We'll be using it immediately to provide our analysts an alternative to Hadoop.” “We saw… 2x improvement in query times.” Channel “We regularly process multibillion row datasets and we do that in a matter of hours.” link
  5. 5. Arquitetura do Amazon Redshift 10 GigE (HPC) Ingestão Backup Restore JDBC/ODBC
  6. 6. Visão aprofundada na arquitetura dos Nós de Computação (”Compute Nodes”) Leader Node Dense compute nodes Large • 2 slices/cores • 15 GB RAM • 160 GB SSD 8XL • 32 slices/cores • 244 GB RAM • 2.56 TB SSD Dense storage nodes X-large • 2 slices/4 cores • 31 GB RAM • 2 TB HDD 8XL • 16 slices/ 36 cores • 244 GB RAM • 16 TB HDD
  7. 7. Ingestão
  8. 8. Uso de vários arquivos para maximizar a carga Comando COPY Cada ”slice” carrega um arquivo por vez Um arquivo único significa apenas um ”slice” carregando dados Ao invés de 100 MB/sec, você obtém somente 6.25 MB/sec
  9. 9. Uso de vários arquivos para maximizar a carga Comando COPY Você precisa de pelo menos o mesmo número de arquivos do que slices Com 16 arquivos de entrada todas as ”slices” estarão trabalhando para maximizar a carga Obtenha 100 MB/sec por nó; escale de maneira linear
  10. 10. ”Primary keys” e arquivos de manifesto Amazon Redshift não força a limitação da primary key • Se carregar várias vezes o mesmo dado o Redshift não vai acusar erro; • Se declarar primary keys para DML, o otimizador vai entender que os registros são únicos; Use arquivos de manifesto para controlar exatamente o que é carregado e o que fazer em caso de falta de arquivos • Defina um manifesto JSON no Amazon S3; • Assegura que o cluster carregue exatamente o que quer;
  11. 11. Higienização de Dados Analize tabelas regularmente • A cada carga para colunas populares • Semanalmente para todas as colunas • Veja a SVV_TABLE_INFO(stats_off) para dados ”stale” • Veja stl_alert_event_log para falta de estatísticas Realize Vacuum nas tabelas regularmente • Semanalmente é um bom alvo • Número de unsorted blocks como gatilho • Veja SVV_TABLE_INFO(unsorted, empty) • Transações ativas ou abertas podem impedir o Vacuum. Veja na SVV_TRANSACTIONS • Você pode executar o vacuum para um ”threshold PERCENT”
  12. 12. Novas Features – Ingestão Opção de Backup no CREATE TABLE • Para uso em Staging e carga de dados • Tabela será excluída em um restore Extensão de ”Sorted” Automatic COPY/INSERT • Tabela é 100% ordenada e possui apenas uma sortkey (ex. date ou timtestamp) • Você adiciona linhas na tabela toda (sempre após as existentes, distribuídas por sortkey) Alter Table Append • Adiciona linhas em uma tabela movendo dados de uma tabela source existente • Dados em uma tabela de origem são movimentados combinando com os dados na destino. • Não pode rodar ALTER TABLE APPEND dentro de um bloco de transações (BEGIN ... END)
  13. 13. Novas Features - Table Restore aws redshift restore-table-from-cluster-snapshot --cluster-identifier mycluster-example --new-table-name my-new-table --snapshot-identifier my-snapshot-id --source-database-name sample-database --source-table-name my-source-table
  14. 14. Compressão automática (quase sempre positiva) Melhor performance e diminui custo Amostra de dados quando executado um comando COPY em tabela vazia • Amostra de até 100,000 rows e escolhe o melhor Encoding Processo de ETL regular utilizando tabelas de staging ou temporárias: Desligue a compressão automática • Use análise de compressão para determinar o encoding correto • Prepare seus DML (baked) com os encodings corretos
  15. 15. Tenha cuidado com suas sort keys Zone maps grava min/max por bloco Após sabermos quais blocos contém uma sequência de dados, sabemos quais linhas não buscarmos Alta compressão significa muitas linhas por bloco Pode varrer mais blocos do que precisaria Se sua sort keys comprime significativamente suas colunas, você pode escolher não comprimir sua sortkey column(s) Veja a SVV_TABLE_INFO(skew_sortkey1) COL1 COL2
  16. 16. Mantenha as colunas tão estreitas quanto possível • Buffers são alocados baseado na declaração da largura das colunas; • Colunas mais largas sem necessidade desperdiçam memória; • Menos linhas cabem na memória mais probabilidade de gravação em disco • Veja a SVV_TABLE_INFO(max_varchar)
  17. 17. Outras Features recentes
  18. 18. Novas funções SQL Nós adicionamos funções SQL regularmente para aumentar a capacidade de execução de queries no Amazon Redshift Adicionadas 25+ funções: • LISTAGG • [APPROXIMATE] COUNT • DROP IF EXISTS, CREATE IF NOT EXISTS • REGEXP_SUBSTR, _COUNT, _INSTR, _REPLACE • PERCENTILE_CONT, _DISC, MEDIAN • PERCENT_RANK, RATIO_TO_REPORT Continuaremos realizado mas também queremos habilitar que escreva as suas
  19. 19. Funções definidas pelo usuário (UDFs) Pode escrever UDFs usando Python 2.7 • Sintaxe idêntica a do PostgreSQL UDF • Chamadas de sistema e rede UDFs não são permitidas Vem com Pandas, NumPy, e SciPy pre-instalados • Você pode importar sua biblioteca para funções mais complexas
  20. 20. Exemplo de UDF CREATE FUNCTION f_hostname (VARCHAR url) RETURNS varchar IMMUTABLE AS $$ import urlparse return urlparse.urlparse(url).hostname $$ LANGUAGE plpythonu;
  21. 21. Exemplo de UDF http://www.looker.com/blog/amazon-redshift- user-defined-functions https://www.periscope.io/blog/redshift-user- defined-functions-python.html
  22. 22. 1-click deployment to launch, on multiple regions around the world Pay-as-you-go pricing with no long term contracts required Advanced Analytics Business IntelligenceData Integration
  23. 23. Interleaved sort keys (chaves de ordenação intercaladas)
  24. 24. Chaves de ordenação compostas ( Compound sort keys ) Registros são armazenados em blocos no Amazon Redshift Nesta ilustração assumimos que 4 registros preenchem um bloco Registros para um dado cust_id ficam em um bloco Contudo, registros para um dado prod_id ficam espalhados em vários blocos 1 1 1 1 2 3 4 1 4 4 4 2 3 4 4 1 3 3 3 2 3 4 3 1 2 2 2 2 3 4 2 1 1 [1,1] [1,2] [1,3] [1,4] 2 [2,1] [2,2] [2,3] [2,4] 3 [3,1] [3,2] [3,3] [3,4] 4 [4,1] [4,2] [4,3] [4,4] 1 2 3 4 prod_id cust_id cust_id prod_id other columns blocks Select sum(amt) From big_tab Where cust_id = (1234); Select sum(amt) From big_tab Where prod_id = (5678);
  25. 25. 1 [1,1] [1,2] [1,3] [1,4] 2 [2,1] [2,2] [2,3] [2,4] 3 [3,1] [3,2] [3,3] [3,4] 4 [4,1] [4,2] [4,3] [4,4] 1 2 3 4 prod_id cust_id Chaves de ordenação intercaladas (Interleaved sort keys) Registros para um dado cust_id espalhados em 2 blocos Registros para um dado prod_id separados em 2 blocos Dados são distribuidos com pesos iguais para ambos 1 1 2 2 2 1 2 3 3 4 4 4 3 4 3 1 3 4 4 2 1 2 3 3 1 2 2 4 3 4 1 1 cust_id prod_id other columns blocks
  26. 26. Uso Nova palavra chave INTERLEAVED para Sortkeys • Sintaxe anterior continua funcionando • Pode escolher até 8 colunas para incluir e selecionar por qualquer uma Não precisa mudar as queries Só estamos iniciando • Benefícios significantes; Carga pode ser penalizada • Veja a SVV_INTERLEAVED_COLUMNS(interleaved_skew) para decidir sobre VACUUM REINDEX • Um valor maior que 5 indica necessidade de VACUUM REINDEX [[ COMPOUND | INTERLEAVED ] SORTKEY ( column_name [, ...] ) ]
  27. 27. Migrando cargas de trabalho existentes
  28. 28. Forklift = BAD
  29. 29. Responda Por que você faz isto hoje? • Muitas vezes, usuários nem sabem Qual a necessidade de negócio? • Muitas vezes, não tem relação com o que faz na prática • Talvez você se beneficie de outro serviço AWS
  30. 30. No Amazon Redshift Updates são delete + insert da linha • Deletes marcam para deleção Blocos são imutáveis • Espaço mínimo usado é um bloco por coluna, por slice Commits são custosos • 4 GB write na 8XL por nó • Espelha o dicionário INTEIRO • Serializado pelo tamanho do cluster
  31. 31. No Amazon Redshift • Nem todas as agregações são criadas da mesma forma • Pre-agregação pode ajudar • Ordenação no grupo importa • Concorrência deve ser baixa para maior throughput • Camada de Cache para dashboards é recomendada • WLM separa RAM para queries. Use múltiplos controles para melhor performance.
  32. 32. Workload Management (WLM) Concorrência e memória podem agora ser alteradas dinamicamente Você pode ter valores distintos para tempo de leitura e tempo de carga Use wlm_apex_hourly.sql para monitorar a pressão das filas
  33. 33. New Feature – WLM Queue Hopping
  34. 34. Obter meta-dados de resultados Usando SQL ou JDBC, você pode obter os nomes das colunas ResultSet rs = stmt.executeQuery("SELECT * FROM emp"); ResultSetMetaData rsmd = rs.getMetaData(); String name = rsmd.getColumnName(1); Descarga de Dados Por enquanto não provê metadados • Use SELECT top 0… • Ao invés de adicionar0=1 na sua cláusula WHERE
  35. 35. Ferramentas Open-source https://github.com/awslabs/amazon-redshift-utils Admin scripts • Diagnóstico do cluster Admin views • Gerenciamento e geração de DDLs. Column encoding utility • Permite selecionar o melhor encoding Analyze and vacuum utility • Automatiza VACUUM e operações de ANALYZE Unload and copy utility • Ajuda a migrar entre Amazon Redshift e outros bancos de dados
  36. 36. Otimizações de cargas de trabalho top_queries.sql perf_alerts.sql
  37. 37. Usando a console para otimização de queries
  38. 38. Obrigado !

×