Deep dive de Amazon Redshift
Transferir como PPTX, PDF2 gostaram395 visualizações
O documento é uma apresentação técnica sobre o Amazon Redshift, abordando sua arquitetura e o ciclo de vida das consultas. Ele detalha a armazenamento colunar, a compressão de dados, a distribuição de dados em 'slices' e o funcionamento dos nós de computação. Além disso, discute conceitos como zone maps, sort keys e o processo de execução de queries, ilustrando como esses elementos colaboram para otimizar desempenho e eficiência.
Deep dive de Amazon Redshift
- 1. © 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
- 2. 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;
- 3. Amazon Redshift História e Desenvolvimento
- 4. 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
- 5. Fevereiro 2013 Junho 2017 > 100 Patches Significantes > 150 Features Significantes
- 6. Arquitetura do Cluster Amazon Redshift
- 7. 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
- 8. Componentes dos nós de computação e Nó Líder
- 9. 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
- 10. • 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
- 11. • 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
- 13. 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
- 14. Desenhado para redução de I/O aid loc dt Storage Colunar Compressão de Dados ”Zone Maps” - mapeamento 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 coluna dt com storage colunar o Só scanea blocos para colunas relevantes
- 15. 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 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
- 16. Desenhado para Redução I/O Storage Colunar Compressão de Dados ”Zone Maps” - mapeamento 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 CREATE TABLE deep_dive ( aid INT --audience_id ,loc CHAR(3) --location ,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
- 17. 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
- 18. 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
- 19. 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
- 20. 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
- 21. Distribuição dos dados Key: Exemplo CREATE TABLE deep_dive ( aid INT --audience_id ,loc CHAR(3) --location ,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
- 22. Distribuição dos dados : EVEN Exemplo CREATE TABLE deep_dive ( aid INT --audience_id ,loc CHAR(3) --location ,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 aid loc dt ins del row Table: loft_deep_dive User Columns System Columns aid loc dt ins del row Table: loft_deep_dive User Columns System Columns aid loc dt ins del row Table: loft_deep_dive User Columns System Columns aid loc dt ins del row Rows: 0 Rows: 0 Rows: 0 Rows: 0 (3 User Columns + 3 System Columns) x (4 slices) = 24 Blocks (24 MB) Rows: 1 Rows: 1 Rows: 1 Rows: 1
- 23. Distribuição dos dados: KEY Exemplo #1 CREATE TABLE deep_dive ( aid INT --audience_id ,loc CHAR(3) --location ,dt DATE --date ) DISTSTYLE KEY DISTKEY (loc); 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 aid loc dt ins del row Rows: 2 Rows: 0 Rows: 0 (3 User Columns + 3 System Columns) x (2 slices) = 12 Blocks (12 MB) Rows: 0Rows: 1 Table: loft_deep_dive User Columns System Columns aid loc dt ins del row Rows: 2Rows: 0Rows: 1
- 24. Distribuição dos dados: KEY Exemplo #2 CREATE TABLE deep_dive ( aid INT --audience_id ,loc CHAR(3) --location ,dt DATE --date ) DISTSTYLE KEY DISTKEY (aid); 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 aid loc dt ins del row Table: loft_deep_dive User Columns System Columns aid loc dt ins del row Table: loft_deep_dive User Columns System Columns aid loc dt ins del row Table: loft_deep_dive User Columns System Columns aid loc dt ins del row Rows: 0 Rows: 0 Rows: 0 Rows: 0 (3 User Columns + 3 System Columns) x (4 slices) = 24 Blocks (24 MB) Rows: 1 Rows: 1 Rows: 1 Rows: 1
- 25. Distribuição dos dados: ALL Exemplo CREATE TABLE loft_deep_dive ( aid INT --audience_id ,loc CHAR(3) --location ,dt DATE --date ) DISTSTYLE ALL; 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'); Rows: 0 Rows: 0 (3 User Columns + 3 System Columns) x (2 slice) = 12 Blocks (12 MB) Table: loft_deep_dive User Columns System Columns aid loc dt ins del row Rows: 0Rows: 1Rows: 2Rows: 4Rows: 3 Table: loft_deep_dive User Columns System Columns aid loc dt ins del row Rows: 0Rows: 1Rows: 2Rows: 4Rows: 3
- 26. 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
- 28. 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ó
- 29. 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
- 30. 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
- 31. 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
- 32. 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
- 33. Ciclo de vida de Query
- 34. 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
- 35. • 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
- 36. 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
- 37. 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 Step 0 Step 1 Step 2 Step 3 Segment 5 Step 0 Step 1 Step 2 Segment 6 Step 0 Step 1 Step 2 Step 3 Step 4 Stream 2 Segment 7 Step 0 Step 1 Segment 8 Step 0 Step 1 Time
- 38. 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.
- 39. 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.
- 40. 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
- 41. 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 Step 0 Step 1 Step 2 Step 3 Segment 5 Step 0 Step 1 Step 2 Segment 6 Step 0 Step 1 Step 2 Step 3 Step 4 Stream 2 Segment 7 Step 0 Step 1 Segment 8 Step 0 Step 1 Time
- 42. Execução da query 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 Step 0 Step 1 Step 2 Step 3 Segment 5 Step 0 Step 1 Step 2 Segment 6 Step 0 Step 1 Step 2 Step 3 Step 4 Stream 2 Segment 7 Step 0 Step 1 Segment 8 Step 0 Step 1 Time 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 Step 0 Step 1 Step 2 Step 3 Segment 5 Step 0 Step 1 Step 2 Segment 6 Step 0 Step 1 Step 2 Step 3 Step 4 Stream 2 Segment 7 Step 0 Step 1 Segment 8 Step 0 Step 1 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 Step 0 Step 1 Step 2 Step 3 Segment 5 Step 0 Step 1 Step 2 Segment 6 Step 0 Step 1 Step 2 Step 3 Step 4 Stream 2 Segment 7 Step 0 Step 1 Segment 8 Step 0 Step 1 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 Step 0 Step 1 Step 2 Step 3 Segment 5 Step 0 Step 1 Step 2 Segment 6 Step 0 Step 1 Step 2 Step 3 Step 4 Stream 2 Segment 7 Step 0 Step 1 Segment 8 Step 0 Step 1 Slices 0 1 2 3
- 43. 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
- 44. 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
- 45. 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
- 46. 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/
- 47. Novidades e Features futuras
- 48. 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
- 49. 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
- 50. 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
- 51. Demonstração
- 52. 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”
- 53. 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
- 54. Solução
- 55. 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
- 56. 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
- 57. 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 …
- 59. Lembre-se de avaliar a apresentação!
Notas do Editor
- #18: Sorted columns enable fetching the minimum number of blocks required for query execution. In this example, an unsorted table al most leads to a full table scan O(N) and a sorted table leads to one block scanned O(1).
- #51: VERIFY!! - Room 2018 Level 2 @ 3:45PM on April 19th
- #53: 30 segundos para apresentar a empresa, rapidamente
- #54: Os 4 (máximo) maiores desafios do projeto, que foram resolvidos pela utilização da nuvem da AWS
- #55: Diagrama de solução, e explicar a solução, vantagens, etc
- #56: Rules Auto statistics collection We keep track of the statistics Usage patterns – avoid analyze if not required
- #57: 1 – customers setup their AD and IdP environment, and register with IAM 2 – End-users leverage SSO with Corporate AD and IdP 3 – Redshift ODBC/JDBC drivers obtain SAML assertion from IdP 4 – Redshift drivers get temporary credentials 5 – Connection is established between client and Redshift