AWS

AWS para engenharia de dados

A stack do time é AWS mais Databricks, então a banca vai testar se você sabe onde cada serviço encaixa e quanto ele custa. A pergunta de custo do Athena é quase certa, porque separa quem já pagou a conta de quem só leu a documentação.

Como cai: Uma consulta no Athena custou caro. O que você olha primeiro?

Erros comuns

• ×Achar que Athena cobra por tempo de consulta. A cobrança padrão é por volume de dados varridos, então otimizar é reduzir bytes lidos, não segundos gastos.
• ×Criar partição no S3 e esquecer de registrar no catálogo. Sem MSCK REPAIR, ALTER TABLE ADD PARTITION, crawler ou partition projection, o Athena não enxerga a partição e continua varrendo tudo.
• ×Escolher Redshift para consulta exploratória esporádica sobre o lake. Você paga cluster ligado o tempo todo para um uso que o Athena atenderia sob demanda.
• ×Usar EMR por hábito onde Glue ou Databricks resolveriam. EMR entrega controle do cluster e da versão do Spark, e cobra isso em operação e tuning.
• ×Tratar Lake Formation como sinônimo de bucket policy. Ele dá permissão fina por tabela, coluna e linha sobre o catálogo, coisa que política de S3 não expressa.
• ×Anexar policy larga na role do job para destravar o deploy. Menor privilégio é requisito em banco, e a banca pergunta como você restringiria depois.
• ×Guardar arquivo pequeno demais no S3. Milhares de arquivos de poucos KB destroem a performance do Athena e do Spark por sobrecarga de listagem e abertura.

Redshift e a camada de consumo analítico

Na sabatina de Analytics, a pergunta não é o que é Redshift: é por que a sua consulta demora e o que você faria. Chave de distribuição errada é a resposta certa na maioria das vezes, e quem não sabe explicar embaralhamento entre nós não consegue defender nenhuma escolha de modelagem.

Como cai: Uma consulta que junta fato e dimensão ficou lenta depois que a tabela cresceu. O que você investiga?

Erros comuns

• ×Tratar o Redshift como um banco relacional maior. Ele é colunar e massivamente paralelo: a otimização que importa é distribuição e ordenação entre nós, não índice por linha.
• ×Deixar a distribuição no padrão para tabelas grandes que se juntam. Chaves mal escolhidas fazem o dado atravessar a rede entre nós a cada junção, e é isso que aparece como lentidão.
• ×Usar distribuição ALL numa tabela grande. Replicar em todos os nós só compensa para dimensão pequena e estável; numa tabela grande, multiplica armazenamento e o custo de carga.
• ×Achar que Spectrum substitui a carga. Ele lê direto do S3, o que é ótimo para dado frio ou eventual; consulta frequente e sensível a desempenho continua melhor dentro do cluster.
• ×Esquecer a chave de ordenação. Sem ela, filtros por data varrem blocos que poderiam ser descartados; é o ganho mais barato numa tabela de fato.
• ×Modelar no Redshift como se fosse OLTP, normalizando tudo. Junção demais em colunar custa caro; a modelagem dimensional existe por isso.

Vocabulário

chave de distribuição

— Coluna que decide em qual nó cada linha fica. Quando duas tabelas grandes se juntam pela mesma coluna e estão distribuídas por ela, a junção acontece dentro de cada nó, sem tráfego de rede.

chave de ordenação

— Coluna pela qual os blocos ficam ordenados. O cluster guarda o mínimo e o máximo de cada bloco e descarta blocos inteiros que não atendem ao filtro.

Redshift Spectrum

— Consulta arquivos no S3 direto do cluster, sem carregá-los, cobrando por dado lido. Permite juntar tabela interna com histórico externo na mesma consulta.

QuickSight

— Ferramenta de BI da AWS. Conecta a Redshift, Athena, S3 e bancos, e tem o SPICE, um motor em memória que guarda uma cópia do conjunto para o painel responder sem consultar a origem a cada clique.