O documento discute arquitetura de dados na AWS, incluindo como mover dados de MySQL para Redshift, as vantagens do EMR, S3 e processamento por batch. É fornecido um resumo da solução atual e recomendações como aproveitar melhor os serviços da AWS para análise de dados.

1. Arquitetura na AWS
Carlos Eduardo F. Barreto
Data Engineer @ GuiaBolso
carlos.eduardo@guiabolso.com.br

2. O papel do engenheiro de dados
“Enable others to answer questions on dataset
within latency constraints” – Marz, N.
http://101.datascience.community/2014/07/08/data-scientist-vs-data-engineer/

3. Apenas para relembrar
http://lambda-architecture.net/

4. A pergunta inicial era...
 Como podemos mover os dados do MySQL
para o Redshift da Amazon?
 Outras foram surgindo no meio do caminho:
 O Redshift é bom até que ponto?
 Seguir o modelo de dados do dev é o melhor
caminho?
 Por que o Sqoop?

5. A AWS é como uma caixa de Lego
http://www.pcguia.pt/wp-content/uploads/2014/03/lego.jpg

6. A solução atual

7. Minhas recomendações
 Use EMR para não perder tempo com infra;
 Esteja atento ao github da AWS, muita coisa lá
vai te ajudar;
 Salve todo raw data e transformações no S3 e
não tenha medo de dados duplicados;
 Inicie com bash/cron e não tenha vergonha
disto;
 Não force tecnologias que você AINDA não
precisa;
 99% dos problemas são resolvidos em batch.

8. Evoluindo a solução inicial
 CDC via binlog e envio de eventos para o
Kinesis;
 Sumarizando mais dados e menos 'as is';
 Melhorando a coleta de logs de extração;
 Usando novas estruturas para análise de
dados, ex.: Elasticsearch e DynamoDB;
 Usando novas formas de visualizar os dados e
gerar insights, ex.: Tableau, Kibana e
Quicksight.

9. Obrigado!
Perguntas?