Padrões de arquitetura para big data na AWS
•Als PPTX, PDF herunterladen•
5 gefällt mir•2,226 views
Com um conjunto cada vez maior de tecnologias para processar grandes volumes de dados, as organizações muitas vezes lutam para entender como construir aplicações escaláveis para suprir esses casos de uso. Neste webinar, vamos ajuda-lo a entender como simplificar o processamento desses dados como um pipeline que abrange vários estágios, e mostrar-lhe como escolher a tecnologia certa para cada etapa com base em critérios como, estrutura de dados, padrões de design e melhores práticas. Objetivos de aprendizado: - Compreender os principais serviços da AWS para Big Data, incluindo S3, Amazon EMR, Kinesis e Redshift. - Aprender padrões de arquitetura para Big Data - Ficar por dentro das melhores práticas para a construção de aplicações de Big Data na AWS
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (19)
Mehr von Amazon Web Services LATAM
Mehr von Amazon Web Services LATAM (20)
Padrões de arquitetura para big data na AWS
- 1. João Paulo (JP) Santana, Arquiteto de Soluções da AWS Novembro de 2016 Padrões de arquitetura para big data na AWS © 2016, Amazon Web Services, Inc. ou suas afiliadas. Todos os direitos reservados.
- 2. Agenda Desafios de big data Como simplificar o processamento de big data Quais tecnologias você deve usar? • Por quê? • Como? Arquitetura de referência Padrões de design
- 3. Big data em constante crescimento
- 4. Evolução do big data Lote Relatório Tempo real Alertas Predição Previsão
- 5. Grande número de ferramentas Amazon Glacier S3 DynamoDB RDS EMR Amazon Redshift Data Pipeline Amazon Kinesis CloudSearch Aplicativo habilitado para Kinesis Lambda ML SQS ElastiCache DynamoDB Streams
- 6. Há uma arquitetura de referência? Quais ferramentas eu devo usar? Como? Por quê?
- 7. Princípios de arquitetura “Barramento de dados” desconectado • Dados → Armazenamento → Processamento → Respostas Use a ferramenta certa para a tarefa • Estrutura de dados, latência, taxa de transferência, padrões de acesso Use ideias de arquitetura Lambda • Registro imutável (somente anexação), camada de lote/velocidade/veiculação Utilize os serviços gerenciados da AWS • Sem/pouca administração Big data ≠ grande custo
- 8. Simplifique o processamento de big data incluir/ coletar armazenar processar/ analisar consumir/ visualizar Tempo até a resposta (latência) Taxa de transferência Custo
- 10. Tipos de dados Transacional • Leituras e gravações no banco de dados (OLTP) • Cache Pesquisar • Registros • Streams Arquivo • Arquivos de log (/var/log) • Estruturas e coletores de registros Stream • Registros de log • Sensores e dados de IoT Banco de dados Armazena- mento de arquivos Armazena- mento de streams A iOS Android Aplicações Web Logstash RegistroIoTAplicações Dados transacionais Dados de arquivos Dados de fluxo Aplicações móveis Dados de pesquisa Pesquisar Coletar Armazenar RegistroIoT
- 11. Armazenar
- 12. Armaze- namento de streams A iOS Android Aplicações Web Logstash Amazon RDS Amazon DynamoDB Amazon ES Amazon S3 Apache Kafka Amazon Glacier Amazon Kinesis Amazon DynamoDB Amazon ElastiCache PesquisaSQLNoSQL Cache Armazenamentode fluxo Armazename ntode arquivos Dados transacionais Dados de arquivos Dados de fluxo Aplicações móveis Dados de pesquisa Banco de dados Armazena- mento de arquivos Pesquisar Coletar Armazenar RegistroIoTAplicações
- 13. Opções de armazenamento de fluxo Serviços gerenciados da AWS • Amazon Kinesis → fluxos • DynamoDB Streams → tabela + fluxos • Amazon SQS → fila • Amazon SNS → pub/ass Não gerenciado • Apache Kafka → fluxo
- 14. Por que usar o armazenamento de streams? Desconecte produtores e consumidores Buffer persistente Colete vários streams Preserve os pedidos dos clientes Streaming do MapReduce Consumo paralelo 4 4 3 3 2 2 1 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 4 3 3 2 2 1 1 Fragmento 1 / Partição 1 Fragmento 2 / Partição 2 Consumidor 1 Contagem de chaves vermelhas = 4 Contagem de chaves violeta = 4 Consumidor 2 Contagem de chaves azuis = 4 Contagem de chaves verdes = 4 DynamoDB Stream Kinesis Stream Tópico do Kafka
- 15. E quanto a filas e pub/sub? • Desconecte produtores e consumidores/assinantes • Buffer persistente • Colete vários fluxos • Sem consumo paralelo para o Amazon SQS • O Amazon SNS pode rotear para várias filas ou funções ʎ • Sem streaming do MapReduce Consumidores Produtores Produtores Amazon SNS Amazon SQS fila tópico função ʎ AWS Lambda Amazon SQS fila Assinante
- 16. Qual armazenamento de fluxo devo usar? Amazon Kinesis DynamoDB Streams Amazon SQS Amazon SNS Kafka Gerenciado Sim Sim Sim Não Pedidos Sim Sim Não Sim Entrega pelo menos uma vez exatamente uma vez pelo menos uma vez pelo menos uma vez Duração 7 dias 24 horas 14 dias Configurável Replicação 3 AZ 3 AZ 3 AZ Configurável Taxa de transferência Sem limite Sem limite Sem limite nº aprox. nós Clientes paralelos Sim Sim Não (SQS) Sim MapReduce Sim Sim Não Sim Tamanho do registro 1 MB 400 KB 256 KB Configurável Custo Baixo Mais alto (custo da tabela) Baixo-médio Baixo (+ admin.)
- 17. Armaze- namento de arquivos A iOS Android Aplicações Web Logstash Amazon RDS Amazon DynamoDB Amazon ES Amazon S3 Apache Kafka Amazon Glacier Amazon Kinesis Amazon DynamoDB Amazon ElastiCache PesquisaSQLNoSQL Cache ArmazenamentodefluxoArmazenamentode arquivos Dados transacionais Dados de arquivos Dados de fluxo Aplicações móveis Dados de pesquisa Banco de dados Pesquisar Coletar Armazenar RegistroIoTAplicações
- 18. Por que o Amazon S3 é bom para big data? • Suportado de maneira nativa por estruturas de big data (Spark, Hive, Presto etc.) • Sem necessidade de executar clusters de computação para armazenamento (diferente de HDFS) • Pode executar clusters Hadoop temporários e instâncias do Amazon EC2 Spot • Vários clusters diferentes (Spark, Hive, Presto) podem usar os mesmos dados • Número ilimitado de objetos • Largura de banda muito alta – sem limite agregado de taxa de transferência • Altamente disponível – pode tolerar falhas de AZ • Desenvolvido para ter uma durabilidade de 99,999999999% • Armazenamento em níveis (Standard-IA, Amazon Glacier) por meio da política de ciclo de vida • Seguro – SSL, criptografia no lado do cliente/servidor em repouso • Baixo custo
- 19. E quanto ao HDFS e ao Amazon Glacier? • Use o HDFS para dados acessados com muita frequência (quentes) • Use o Amazon S3 Standard para dados acessados com muita frequência • Use o Amazon S3 Standard-IA para dados acessados com pouca frequência • Use o Amazon Glacier para arquivar dados frios
- 20. Banco de dados + Pesquisa Nível A iOS Android Aplicações Web Logstash Amazon RDS Amazon DynamoDB Amazon ES Amazon S3 Apache Kafka Amazon Glacier Amazon Kinesis Amazon DynamoDB Amazon ElastiCache PesquisaSQLNoSQLCacheArmazenamentodefluxoArmazenamentode arquivos Dados transacionais Dados de arquivos Dados de fluxo Aplicações móveis Dados de pesquisa Coletar Armazenar
- 21. Banco de dados + Antipadrão do nível de pesquisa Banco de dados + Nível de pesquisa
- 22. Melhor prática - Use a ferramenta certa para a tarefa Camada de dados Search Amazon Elasticsearch Service Amazon CloudSearch Cache Redis Memcached SQL Amazon Aurora MySQL PostgreSQL Oracle SQL Server NoSQL Cassandra Amazon DynamoDB HBase MongoDB Banco de dados + Search
- 24. Qual armazenamento de dados devo usar? Estrutura de dados → Esquema fixo, JSON, chave-valor Padrões de acesso → Armazene os dados no formato em que você os acessará Características de acesso/dados → quentes, mornos, frios Custo → Custo certo
- 25. Estrutura dos dados e padrões de acesso Padrões de acesso O que usar? Put/Get (chave, valor) Cache, NoSQL Relacionamentos simples → 1:N, M:N NoSQL Joins de várias tabelas, transações, SQL SQL Facetamento/pesquisa Search Estrutura de dados O que usar? Esquema fixo SQL, NoSQL Sem esquema (JSON) NoSQL, Search (Chave, valor) Cache, NoSQL
- 26. Qual é a temperatura dos dados/do acesso?
- 27. Quentes Mornos Frios Volume MB–GB GB–TB PB Tamanho do item B–KB KB–MB KB–TB Latência ms ms, s min, h Durabilidade Baixa–alta Alta Muito alta Taxa de solicitações Muito alta Alta Baixa Custo/GB $$-$ $-¢¢ ¢ Dados quentes Dados mornos Dados frios Características dos dados/do acesso: Quentes, mornos, frios
- 28. Cache SQL Taxa de solicitações Alta Baixa Custo/GB Alta Baixa Latência Baixo Alto Volume de dados Baixa Alta Glacier Estrutura NoSQL Dados quentes Dados mornos Dados frios Baixo Alto Pesquisa
- 29. Amazon ElastiCache Amazon DynamoDB Amazon Aurora Amazon Elasticsearch Amazon EMR (HDFS) Amazon S3 Amazon Glacier Latência média ms ms ms, s ms, s s, min, h ms, s, min (tamanho aprox.) h Volume de dados GB GB–TBs (sem limite) GB–TB (No máx. 64 TB) GB–TB GB–PB (nº aprox. nós) MB–PB (sem limite) GB–PB (sem limite) Tamanho do item B-KB KB (No máx. 400 KB) KB (64 KB) KB (No máx. 1 MB) MB-GB KB-GB (No máx. 5 TB) GB (No máx. 40 TB) Taxa de solicitações Alta - Muito alta Muito alta (sem limite) Alta Alta Baixa – Muito alta Baixa – Muito alta (sem limite) Muito baixa Custo do armazenamento GB/mês $$ ¢¢ ¢¢ ¢¢ ¢ ¢ ¢/10 Durabilidade Baixa - Moderada Muito alta Muito alta Alta Alta Muito alta Muito alta Dados quentes Dados mornos Dados frios Dados quentes Dados mornos Dados frios Qual armazenamento de dados devo usar?
- 30. Design baseado em custo Exemplo: devo usar o Amazon S3 ou o Amazon DynamoDB? “No momento, estou desenvolvendo um projeto que aumentará muito o uso que minha equipe faz do Amazon S3. Espero que você possa responder a algumas perguntas. A iteração atual do design chama muitos arquivos pequenos, talvez até um bilhão durante o pico. O tamanho total ficaria na ordem de 1,5 TB por mês…” Taxa de solicitações (gravações/s) Tamanho do objeto (Bytes) Tamanho total (GB/mês) Objetos por mês 300 2048 1483 777,600,000
- 31. Design baseado em custo Exemplo: devo usar o Amazon S3 ou o Amazon DynamoDB? https://calculator.s3.amazonaws.com/index.html Calculadora mensal simples
- 32. Taxa de solicitações (Gravações/s) Tamanho do objeto (Bytes) Tamanho total (GB/mês) Objetos por mês 300 2,048 1,483 777,600,000 Amazon S3 ou Amazon DynamoDB?
- 33. Taxa de solicitações (Gravações/s) Tamanho do objeto (Bytes) Tamanho total (GB/mês) Objetos por mês Cenário 1 300 2,048 1,483 777,600,000 Cenário 2 300 32,768 23,730 777,600,000 Amazon S3 Amazon DynamoDB use use
- 35. AnalisarA iOS Android Aplicações Web Logstash Amazon RDS Amazon DynamoDB Amazon ES Amazon S3 Apache Kafka Amazon Glacier Amazon Kinesis Amazon DynamoDB Amazon Redshift Impala Pig Amazon ML Amazon Kinesis AWS Lambda AmazonElasticMapReduce Amazon ElastiCache PesquisaSQLNoSQLCache StreamsBatchInterativo Registro Armazenamentodefluxo IoTAplicações Armazenamentode arquivos Quente s Frios Mornos Quente s Quente s ML Dados transacionais Dados de arquivos Dados de fluxo Aplicações móveis Dados de pesquisa Coletar Armazenar Analisar Streaming
- 36. Análise interativa É necessário um grande volume de dados (quentes/frios) Leva segundos para receber as respostas Exemplo: painéis de autoatendimento
- 37. Análise em Batch É necessário um grande volume de dados (quentes/frios) Leva minutos ou horas para receber as respostas Exemplo: geração de relatórios diários, semanais ou mensais
- 38. Análise em tempo real Use uma pequena quantidade de dados quentes para fazer perguntas Leva pouco tempo (milissegundos ou segundos) para receber a resposta Tempo real (evento) • Resposta em tempo real a eventos em fluxos de dados • Exemplo: alertas de faturamento/fraude Quase em tempo real (microlote) • Operações quase em tempo real em pequenos lotes de eventos em fluxos de dados • Exemplo: métricas de 1 minuto
- 39. Previsões por meio de Machine Learning Com o ML, os computadores podem aprender sem ser programados de maneira explícita Algoritmos de aprendizagem automática: Aprendizagem supervisionada ← você “ensina” o programa - Classificação ← Essa transação é uma fraude? (sim/não) - Regressão ← Valor da vida útil do cliente? Aprendizagem sem supervisão ← deixe-o aprender sozinho - Clustering ← Segmentação de mercado
- 40. Ferramentas e estruturas de análise Machine Learning • Mahout, Spark ML, Amazon ML Análise interativa • Amazon Redshift, Presto, Impala, Spark Processamento em batch • MapReduce, Hive, Pig, Spark Processamento de streams • Microlote: Streaming do Spark, KCL, Hive, Pig • Tempo real: Storm, AWS Lambda, KCL Amazon Redshift Impala Pig Amazon Machine Learning Amazon Kinesis AWS Lambda AmazonElasticMapReduce ProcessamentodefluxosLoteInterativoML Analisar Streaming
- 41. Qual tecnologia de processamento de fluxos devo usar? Streaming do Spark Apache Storm Biblioteca cliente do Amazon Kinesis AWS Lambda Amazon EMR (Hive, Pig) Escala/taxa de transferência Nº aprox. nós Nº aprox. nós Nº aprox. nós Automático Nº aprox. nós Lote ou tempo real Tempo real Tempo real Tempo real Tempo real Lote Capacidade de gerenciamento Sim (Amazon EMR) Faça você mesmo Amazon EC2 + Auto Scaling Gerenciado pela AWS Sim (Amazon EMR) Tolerância a falhas AZ único Configurável Multi-AZ Multi-AZ AZ único Linguagens de programação Java, Python, Scala Qualquer linguagem por meio do Thrift Java por meio de MultiLangDaemon (.Net, Python, Ruby, Node.js) Node.js, Java, Python Hive, Pig, linguagens de streaming Alta
- 42. Qual tecnologia de processamento de dados devo usar? Amazon Redshift Impala Presto Spark Hive Latência da consulta Baixa Baixa Baixa Baixa Média (Tez) – Alta (MapReduce) Durabilidade Alta Alta Alta Alta Alta Volume de dados No máx. 1,6 PB Nº aprox. nós Nº aprox. nós Nº aprox. nós Nº aprox. nós Gerenciado Sim Sim (EMR) Sim (EMR) Sim (EMR) Sim (EMR) Armazena- mento Nativo HDFS/S3A* HDFS/S3 HDFS/S3 HDFS/S3 Compatibilida de com SQL Alta Média Alta Baixa (SparkSQL) Média (HQL) AltaMédia
- 43. E quanto à ETL? Armazenar Analisar https://aws.amazon.com/big-data/partner-solutions/ ETL
- 45. Coletar Armazenar Analisar Consumir A iOS Android Aplicações Web Logstash Amazon RDS Amazon DynamoDB Amazon ES Amazon S3 Apache Kafka Amazon Glacier Amazon Kinesis Amazon DynamoDB Amazon Redshift Impala Pig Amazon ML Amazon Kinesis AWS Lambda AmazonElasticMapReduce Amazon ElastiCache PesquisaSQLNoSQLCache ProcessamentodefluxosLoteInterativo Registro Armazenamentodefluxo IoTAplicações Armazenamentode arquivos Análiseevisualização Quente s Frios Morno s Quente s Baixa Quentes ML Rápido Rápido Dados transacionais Dados de arquivos Dados de fluxo Notebooks Previsões Aplicativos e APIs Aplicações móveis IDE Dados de pesquisa ETL Streaming Amazon QuickSight
- 46. Consumir Previsões Análise e visualização Notebooks IDE Aplicativos e API Consumir AnáliseevisualizaçãoNotebooks Previsões Aplicativos e APIs IDE Armazenar Analisar ConsumirETL Usuários comerciais Cientista de dados, desenvolvedores Amazon QuickSight
- 48. Coletar Armazenar Analisar Consumir A iOS Android Aplicações Web Logstash Amazon RDS Amazon DynamoDB Amazon ES Amazon S3 Apache Kafka Amazon Glacier Amazon Kinesis Amazon DynamoDB Amazon Redshift Impala Pig Amazon ML Amazon Kinesis AWS Lambda AmazonElasticMapReduce Amazon ElastiCache PesquisaSQLNoSQLCache ProcessamentodefluxosLoteInterativo Registro Armazenamentodefluxo IoTAplicações Armazenamentode arquivos Análiseevisualização Quente s Frios Mornos Quente s Baix a Quente s ML Rápido Rápido Dados transacionais Dados de arquivos Dados de fluxo Notebooks Previsões Aplicativos e APIs Aplicações móveis IDE Dados de pesquisa ETL Arquitetura de referência Streaming Amazon QuickSight
- 50. "Barramento de dados" desconectado em várias etapas Várias etapas Armazenamento desconectado do processamento Armazenar Processar Armazenar Processar processar armazenar
- 51. Vários aplicativos (ou conectores) de processamento podem ler de vários armazenamentos de dados ou gravar neles Amazon Kinesis AWS Lambda Amazon DynamoDB Amazon Kinesis S3 Connector processar armazenar Amazon S3
- 52. Estruturas de processamento (KCL, Storm, Hive, Spark etc.) poderiam ler de vários armazenamentos de dados Amazon Kinesis AWS Lambda Amazon S3 Amazon DynamoDB Hive SparkStorm Amazon Kinesis S3 Connector processar armazenar
- 53. Streaming do Spark, Apache Storm AWS Lambda KCL Amazon Redshift Spark Impala Presto Hive Amazon Redshift Hive Spark Presto Impala Amazon Kinesis Apache Kafka Amazon DynamoDB Amazon S3dados Quentes Frios Temperatura dos dados Latênciado processamento Baixa Alta Respostas Amazon EMR (HDFS) Hive Nativo KCL AWS Lambda Temperatura dos dados x latência do processamento Batch
- 54. Análise em tempo real Produtor Apache Kafka KCL AWS Lambda Spark Streaming Apache Storm Amazon SNS Amazon ML Notificações Amazon ElastiCache (Redis) Amazon DynamoDB Amazon RDS Amazon ES Alerta Estado do aplicativo Previsão em tempo real KPI processar armazenar DynamoDB Streams Amazon Kinesis
- 55. Camada em lote Amazon Kinesis dados processar armazenar Amazon Kinesis S3 Connector Amazon S3 A p l i c a ç õ e s Amazon Redshift Amazon EMR Presto Hive Pig Spark resposta Camada de velocidade resposta Camada de veiculação Amazon ElastiCache Amazon DynamoDB Amazon RDS Amazon ES resposta Amazon ML KCL AWS Lambda Streaming do Spark Storm Arquitetura Lambda
- 56. Resumo Crie um “barramento de dados” desconectado • Dados → Armazenamento ↔ Processamento → Respostas Use a ferramenta certa para a tarefa • Latência, taxa de transferência, padrões de acesso Use ideias de arquitetura do Lambda • Registro imutável (somente anexação), camada de lote/velocidade/veiculação Utilize os serviços gerenciados da AWS • Sem/pouca administração Crie um design baseado em custo • Big data ≠ grande custo
- 57. Obrigado! Encontre Guias de conceitos básicos | Tutoriais | Laboratórios aws.amazon.com/big-data
Hinweis der Redaktion
- Bom dia! Eu sou João Paulo (JP) Santana, Arquiteto de Soluções da AWS Obrigado pela pela presença de todos e por tomar uma hora da sua agenda para falarmos sobre pardrões de arquitetura para big data na AWS.
- Como simplificar o processamento de Big Data através do pipeline de fases de Ingestão, Armazenamento, processamento e visualização. Em cada um dos passos vamos ver como é importante utilizarmos a ferramenta correta para cada tipo de trabalho. Vamos ver por que cada ferramenta faz mais sentido dependendo do caso de uso.
- Volume: Hoje clientes demandam a construção de aplicações de big data para sustentar um volume de centenas ou milhares de terabytes por dia, isso está ficando normal hoje em dia. Velocidade: Agora está se tornando normal, milhões de requisições por segundo ao invés de milhares ou centenas. Variedade: Hoje não precisamos coletar somente dados transacionais, estruturados, existe um valor enorme e dados não estruturados e semi-estruturados os quais as empresas precisam analizar para minerar o ouro contido neles.
- Na evolução estamos vendo que workloads estão movendo-se de padrões batch para análises em tempo real, ou próximas de tempo real (near real time) E também análises preditivas. Por exemplo, hoje você espera que um provedor de telefonia celular não te envie somente a fatura no final do mes, mas que também possa, analisando seu comportamento de uso, enviar alertas de uso por subscrição ou te proponha planos mais adequados ao seu perfil. A previsão de ”o que vem por aí” também é mto importante. Prever se um tipo de transação é possívelmente de um valor muito alto, ou se é uma fraude potencial. Isto está se tornando critico em termos de prover ao cliente um nível de serviço diferencial
- A boa notícia (ou a má?) é que, para implementar tudo isso existe hoje uma infinidade de ferramentas. A esquerda vocês podem ver a infinidade de ferramentas do ecosistema opensource apache (haddoop, hive, pig) Hoje, se vc for a uma conferencia de big data, Spark é a resposta padrão para qualquer pergunta. Para motor de busca, Elasticsearch é a resposta padrão para tudo. O esquilo à esquerda é o Apache Flink, que agora parece estar ameaçando a dominância do Spark. Do lado direito temos Serviços Gerenciados da AWS muito populares para Big Data (EMR, S3, Kinesis). Um arquiteto hoje precisa se perguntar, como construo minha arquitetura na nuvem AWS de uma maneira que eu retire dos meus ombros aquilo que não é diferencial para o core business da minha empresa e, desta forma, agrego valor à minha solução de Big Data?
- Existe uma arquitetura ”one size fits all”? Quais ferramentas utilizar? Vamos tentar a ajuda-los a descobrir a resposta…
- Alguns principios de arquiteturas que vêm desafiando o tempo sendo sempre relevantes: Desacoplar camadas do pipeline… Usar a ferramenta correta de acordo com os critérios necessários para o caso de uso. Critérios como: Padrões de acesso, estrutuda do dado, temperatura do dado, etc… A Arquitetura Lambda tem se tornado um padrão consolidado no mundo de big data. Tratar casos de processamento em realtime com processamento em batch no mesmo sistema de big data, para trazer ganhos de custo. Usar serviços gerenciados AWS. Minha habilidade de manter os name e secondary nodes, manter o yarn… faz minha empresa ganhar mais dinheiro? Big data não tem q ter grande custo. Se o custo é grande, é indicio de que algo foi arquitetado de forma errada.
- O pipeline de big data é muito frequentemente similar à este:
- No estágio de ingestão ou coleta temos Aplicação, frameworks de logging (fluentd), ou mais recentemente IoT… Variedade de dados é grande: Dados trasacionais, dados em arquivo, dados não estruturados, streams de dados…
- Para armazenar todos esses tipos variados de dados…
- … Precisamos nos preocupar com o armazenamento desses dados em stream
- Temos opções que podemos classificar em serviços gerenciados e não gerenciados. Temos aí os serviços gerenciados da AWS para processamentos de dados desse tipo. E no mundo opensource, o Kafka é muito popular também… Voltamos áquele ponto: Configurar, monitorar e gerenciar um cluster de Kafka faz minha empresa ganhar mais dinheiro? é diferencial para meu negócio? Ou posso passar o trabalho não diferencial para a AWS e me focar no meu core business?
- Storage de strems no ajuda a desacoplar os produtores de dados dos consumidores Provê um buffer persistente que o produtor dos dados pode usar, ao invés de ele mesmo armazenar os dados Coletar vários streams em paralelo. O importante é que dessa forma conseguimos preservar a autoria do dado e a ordem do dado Se o dado for escrito com uma chave consistente com o stream ferramentas como o Kinesis e o Kafka irão preservar a sequencia do stream de dados Isso permitira por exemplo, num caso de um carrinho de compras, enviado os clickstreams, que o consumidor dos dados pudesse dizer quando o cliente abandonou o carrinho, e até fazer predições a esse respeito. Isso pq a sequencia dos dados entrando bate com a sequencia das ações do cliente no website. Permitiria por exemplo também, calcular máximo e mínimo de uma medição de temperatura para um motor, num caso de uso de IoT, etc Consumo paralelo: Frequentemente CTO’s querem que seus distintos times consumam dados do mesmo repositório e façam processamentos ou criem aplicações mantendo-se na mesma origem. Assim um time não depende do outro e podem trabalhar em paralelo
- Filas e tópicos podem ser usados para desacoplar camadas, criar bufferes persistentes e coletar paralelamente de vários fluxos também Porém eles não tem a funcionalidade de consumo paralelo consumo e stream de mapreduce Agora o SQS pode preservar autoria e ordem… No entanto se um cliente precisa dessas funcionalidades a melhor opção é usar as ferramentas mais especializadas para processamento de streams, que descrivi anteriormente
- Aqui fiz uma matriz de comparação entre os atributos necessários para esse caso de uso de armazenamento de streams e as diferentes ferramentas. Os serviços gerenciados da AWS e o Kafka que é não gerenciado. Essa tabela pode ajudar na tomada de decisao dependendo do caso de uso. De maneira geral, Kinesis tem o melhor custo beneficio nessa área.
- E no caso de armazenamento de arquivos?
- O S3 é o lugar ideal para armazenar dados de Big Data. Suportada de maneira nativa um grande número de formatos Desacopla storage de processamento, então vc não precisa persistir os dados no cluster e consequentemente pode ter um cluster efemero Que vc liga e desliga conforme a utilização para processamento Datalake Segurança Baixo custo
- HDFS está sendo usado menos e menos Pode ser usado como um estagio intermediário para duas fazes de processamento Hadoop Mas até mesmo para isso, S3 tem uma performance bem alta Pode ser útil no caso de o cliente querer utilizar um cluster steady state com HBASE… Mas esse caso de uso poderia ser atendido perfeitamente pelo Amazon DynamoDB S3 também tem multiplas classes de storage para adequar seu dado à sua temperatura
- Vamos para bancos de dados…
- Usar um mesmo banco de dados relacional para todo tipo de caso geralmente não é uma boa prática… é necessário utilizar a ferramenta adequada para o trabalho. Enão se isso é um anti-patern, qual é a boa prática?
- A boa prática é pensar o DB em termos de Armazenamento e Search incluindo categorias de dados que se encaixem em Cache, NoSQL, SQL e Search
- Como realmente então construir um sistema pensando banco de dados dessa maneira? Para construir esses sistemas podemos usar serviços gerenciados AWS que se encaixem em cada uma dessas categorias Cache: Elasticache (Redis e Mencached) Search: CloudSearch ou ElasticSearch gerenciado NoSQL: DynamoDB SQL: RDS BASE: NoSQL Basic Availability, Soft-state, Eventual consistency ACID: SQL Atomic, Consistent, Isolated, Durable Para fazer a integração no caso de um sistema que utilize todos esses serviços de consistencia eventual, e deixalos em sincronia Podemos utilizar o Kinesis KCL ou mesmo funções do AWS Lambda
- Qual tipo de banco de dados usar? Depende da natureza do dado (estruturado, semi, não estruturado) Como o dado será acessado Temperatura do dado E relação entre custo e beneficio
- Aqui uma outra tabela que ajuda na tomada de decisão:
- Outro fator importante é a temperatuda do dado…
- Tipicamente dado quente inclui pequenos datasets que se movem muito rapidamente, talvez centenas ou milhares de requests por segundo, onde a sequencia de acesso é muito rápida. Ao contrário, dados mais mornos ou frios possuem tamanhos de datasets maiores e a sequencia de acesso é mais baixa. Normalmente dados quentes são tratados em RAM ou SSD, onde há menor latencia enquanto dados menos quentes são tratados em spinning disks. Isso também impacta no custo que tende a ser mais alto quanto maior é a temperatura do dado.
- Aqui temos um mapa mental de como a temperatura do dado reflete na ferramenta utilizada e também mostra a relação entre custo, latencia e velocidade e volume dos dados
- Aqui outra matriz que ajuda na tomada de decisão de que ferramenta utilziar dependendo da temperatura do dado e o impacto em custo e latencia apropriada para cada tipo de workload
- Aqui um exercício que mostra como desenhar a arquitetura tendo em mente o custo é extremamente importante.
- Neste caso o DynamoDB custaria: 644 dolares Enquanto o S3 custaria 3932 dolares Mas o S3 não é extremamente barato? Sim mas o S3 é desenhado para objetos de tamanho maior e não para essa quantidade e norme de requests/segundo Enquanto o DynamoDB é desenhado exatamente para sustentar esse tipo de padrão de acesso..
- Ja nesse outros cenário onde temos objetos de tamanho maior, de 32 Kb: O S3 custaria: 4588 dolares Enquanto o DynamoDB custaria: 10131 dolares Esse é um exemplo de o quao importante é usar a ferramenta certa para o trabalho e de como isso pode impactar nos custos.
- Vamos falar sobre Processamento e análise…
- O aspecto de análise podemos categorizar em 4 grupos: Streams, Batch, Interativo e Machine Learning
- Em termos de análise interativa, onde temos um analista em frente de um dashboard explorando dados a resposta é esperada para retornar em segundos.
- No caso de Batch, tipicamente estamos tratando com um volume bem grande de dados onde trabalhamos com jobs que levam minutos ou horas para gerar a resposta.
- Pequenas quantidades de dados que precisam ser analizadas em segundos ou milisegundos para, por exemplo, alertar rapidamente contrar fraudes.
- Utilizando Machine Learning. Suporvisionado, onde você ensina o programa usando alguns datasets exemplo e então faz uma pargunta. Como ”essa transação é fraudulenta?” e a resposta é binária (sim ou não) Ou, ”por quanto posso vender essa casa?”… ela tem 2 banheiros, está nesse CEP… Machine learning não supervisionado onde o programa aprende sozinho. Na amazon.com por exemplo, temos uma variedade de roupas ou sepatos e precisamos categorizar através de algoritmos esse produtos para podermos implementar facetamento…
- Em termos de ferramental, esses são os mais populares: No Amazon EMR vc pode rodar praticamente todas essas ferramentas do Ecosistema Hadoop descritas acima.
- Outra matriz para nos ajudar a tomar a decisão de que ferramenta é mais apropriada para cada tipo de caso Vale lembrar que, em termos de escalabilidade agora o Amazon EMR suporta auto-scaling
- Como são muitas as ferramentas essa matriz está em duas partes, Amazon Redshif terá baixissima latencia se vc está trabalhando com um cluster de dataware house de processamento paralelo massivo. Impala, recentemente foi adicionado ao EMR. Presto que é utilizado pelo Netflix para seu sistema de cobrança… Estão super felizes com ele. Vejam que esses sistemas são suportados no Amazon EMR Nós vamos disponibilizar essa apresentação depois no Youtube e Slideshare para que vocês tenham esse material.
- Passando agora para ETL, o Datapipeline é uma ferramenta que pode te ajudar na movimentação de dados entre serviços AWS Temos também um grande ecosistema de parceiros…
- Visualização e consumo dos dados
- Dependendo do chapeu que vc tem na empresa, algumas dessas ferramentas podem ser mais interessantes… Agora temos o Amazon QuickSight disponível na console AWS, como nossa própria ferramenta de visualização. Utiliza um motor de tratamento dos dados em memória chamado SPICE, que provê baixíssima latencia. O Kibana também pode ser usado para projetar belos graficos a partir do ElasticSearch gerenciado da AWS. E temos também vários produtos de parceiros disponíveis no nosso aws marketplace Notebooks também estão se tornando muito populares, vc pode usar Ipython e Zepelin com Notebooks direto do Amazon EMR podem fazer uma busca por esse tema no Blog de Big Data da AWS para mais informações de como implementar a solução.
- Essa é a arquitetura de referencia que engloba tudo em uma única página para categorizar todas as opções que discutimos.
- Construir um pipeline de big data em barramento, com multiplos estágios, como esse no slide, ”armazena, processa, armazena, processa” Faz muito sentido em vários casos pois os subsistemas podem rodar na sua propria velocidade, podem ser desacoplados tornando o pipeline muito mais eficiente
- Essa estratégia em barramento também nos permite criar diferentes camadas de processamento, com uma origem comum mas possívelmente destinos diferentes dependendo do tipo de dado. Como mostramos antes essa estratégia mtas vezes traz ganhos de custo e performance.
- Essa estratégia também permite ter multiplos frameworks de processamento Fazendo por exemplo processamento de joins de diferente sources, como o Hive nesse caso fazendo joins de dados que estão no DynamoDB com dados provenientes do S3
- Esse slide também é mto interessante Na horizontal: Temperatura Dado quente à frio, categorizando por exemplo Kinesis, Kafka e DynamoDBcomo armazenamento de dados quentes enquanto EMR e S3 para dados mais frios Na vertical: Latencia Categorizando a ferramenta apropriada para cada tipo de cenário (tempo real, batch, interativo) e o tempo de resposta apropriado para cada um.
- Agora dando um deep dive nos cenários mais específicos: Basando-nos nas arquiteturas de referencia AWS O produtor do dado tipicamente envia o dado para o Amazon Kinesis, Kafka ou DynamoDB Streams. Para a maioria dos casos eu escolheria o Kinesis. A não ser que tenha alguma razão especifica para não… Para processar o dado podemos usa também serviços gerenciados como o AWS Lambda ou EMR rodando spark streaming ou Storm ou mesmo o KCL Se vc precisar de alerta, pode usar o SNS, nosso serviço gerenciado de notificações Para o armazenamento e visualização podemos usar algum desses serviços gerenciados também Para tomada de ação preditiva em real time usar o Amazon ML
- A Famosa Arquitetura Lambda Aqui eu tenho o Kinesis e duas camadas distintas para processar dados em Stream ou em Batch. Explicar as camadas… É extremamente critico ter uma camada de serviço que sirva o dado na forma e padrão necessário pela aplicação que vai consumir o dado
- Resumindo Quando construimos um pipeline de big data, desacoplar as camadas é importante Usar a ferramenta correta para cada tipo de trabalho é crítico. Usar os padrões q eu demonstrei de latencia, natureza do dado, taxa de transferencia, vai ajudar na tomada de decisão Usar a arquitetura Lambda usando uma camada para batch e outra para análise em tempo real no mesmo sistema, alimentando uma camada de apresentação comum Ser consciente com relação a custo quando se desenha a arquitetura também é importantíssimo
- Muito obrigado pela presença de todos e espero que essa sessão tenha sido útil para vocês.