TDC2018SP | Trilha BigData - O que nao te falam sobre ir de uma pipeline de dados de batch para streaming
•Transferir como PPTX, PDF•
0 gostou•132 visualizações
O documento discute considerações importantes ao processar dados em streaming, incluindo domínio de negócio, valor de negócio, monitoramento, recuperação de dados e alternativas de implantação. Também apresenta exemplos de processamento de dados em lote e streaming, estratégias de implantação resiliente e reprocessamento de dados.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a TDC2018SP | Trilha BigData - O que nao te falam sobre ir de uma pipeline de dados de batch para streaming
Semelhante a TDC2018SP | Trilha BigData - O que nao te falam sobre ir de uma pipeline de dados de batch para streaming (20)
Mais de tdc-globalcode
Mais de tdc-globalcode (20)
Último
Último (20)
TDC2018SP | Trilha BigData - O que nao te falam sobre ir de uma pipeline de dados de batch para streaming
- 1. Coisas interessantes para saber quando começar a processar dados em streaming algumas vivências de projeto
- 2. Quem sou eu?
- 5. vamos falar! ✔ domínio de negócio ✔ valor de negócio ✔ soluções possíveis (não únicas) ✔ monitoramento ✔ recuperação de dados ✔ serviços da AWS ✔ alternativas para deploy não vamos falar ✖ segurança ✖ performance ✖ Spark ou Flink? ✖ código
- 6. Processamento de dados de sensores. Como fazemos?
- 7. em batch Pipeline de Detecção de Falhas Serviços Auxiliares ETL S3 Bucket Serviços Auxiliares
- 8. Era uma vez o tão esperado "vê se rola" (MVP)
- 9. em batch e streaming Serviços Auxiliares ETL S3 Bucket Serviços Auxiliares Streaming Pipeline S3 Bucket Pipeline de Detecção de Falhas
- 10. Mas e se a gente falhar?
- 12. Pipeline de Dados Resiliente ✔ escalabilidade ✔ disponibilidade ✔ rápida recuperação de falhas
- 13. Cenários: 1. reprocessamento de dados 2. estratégia de deploy fonte: https://i.gifer.com/3vwT.gif
- 14. Reprocessamento de dados Contexto Contexto: ● streaming dados que são enviados atualmente de uma em uma hora; Pontos de Atenção: ● restrição de escalabilidade no Kinesis; ● limite de leitura de dados do Kinesis;
- 15. Reprocessamento de dados Solução Atual ● mecanismo de reprocessamento das Lambdas ● backup dos dados puros ● monitoramento via Splunk e CloudWatch ● reprocessamento dos dados via postagem Streaming Pipeline
- 16. Reprocessamento de dados Outras Soluções ● Dead Letter Queues (DLQ) fonte: https://cdn-images-1.medium.com/max/1600/1*RrSXb7Kiep3OX5KIMVoqBg.png
- 17. Estratégia de Deploy Contexto ● todas as Lambdas se encontram em um mesmo projeto; ● pipeline de dados principal em um cluster Spark
- 18. Estratégia de Deploy Solução Atual ● monitoramento
- 19. Estratégia de Deploy Soluções Futuras ● Blue Green deployment ● Spark checkpoint fonte: https://martinfowler.com/bliki/images/blueGreenDeployment/blue_green_deployments.png
- 20. Pontos de Atenção ● Arquitetura evolutiva ● Logs, logs e mais logs ● Engenharia do Caos
- 21. Lições Aprendidas ✓ MVP é MVP ✓ entenda as necessidades do contexto atual ✓ entenda as limitações da equipe ✓ irão ser geradas dívidas técnicas, mas tudo bem
- 22. Literaturas
- 23. Referências gerador de ppt: http://lulapptgenerator.top implantação blue green: https://martinfowler.com/bliki/BlueGreenD eployment.html atualizando aplicações spark: https://spark.apache.org/docs/latest/strea ming-programming- guide.html#upgrading-application-code ícones AWS: https://aws.amazon.com/architecture/i cons/ resiliência em microserviços: https://www.infoq.com/br/presentation s/resiliencia-com-microservices-cache- distribuido-feedback-e-tuning 3 Pro Tips for Developers using AWS Lambda with Kinesis Streams: https://read.acloud.guru/aws-lambda- 3-pro-tips-for-working-with-kinesis- streams-8f6182a03113 The world beyond batch: Streaming 101 https://www.oreilly.com/ideas/the- world-beyond-batch-streaming-101
- 24. Referências Understanding Retry Behavior: https://docs.aws.amazon.com/lambda/late st/dg/retries-on-errors.html Building Microservices: Designing Fine- Grained Systems: https://samnewman.io/books/building_mic roservices/ Dead letter queue: https://en.wikipedia.org/wiki/Dead_letter_ queue Building Reliable Reprocessing and Dead Letter Queues with Kafka https://eng.uber.com/reliable- reprocessing/ Splunk e Jenkins ícone ic8.link/49188 ; ic8.link/49188 Princípios do caos https://principlesofchaos.org/ Data Pipeline Design Considerations https://bostata.com/post/data_pipeline _design_considerations/ Radar Tecnológico https://www.thoughtworks.com/pt/rad ar https://www.facebook.com/TWTechTal ksRecife/
- 25. Obrigada :) Para sugestões, feedbacks e dúvidas: mirelythaisa@gmail.com nas internets: Twitter: @thaisa_mirely
Notas do Editor
- A ideia dessa conversa surgiu durante a implementação do MVP(mínimo produto viável), de uma pipeline de dados de dados via streaming no meu projeto atual, muito veio também da dificuldade que tive de encontrar um compilado de matérias falando sobre algumas técnicas de resiliência interessantes para esse contexto de processamento de dados. E é sobre isso que vou falar um pouco para vocês agora.
- Me chamo Thaisa e além de ser uma pessoa política e reclamona gosto de gatos, podcast, plantas e conversar sobre temas polêmicos no domingo a noite. Atualmente minhas áreas de interesse são devops, micro serviços e engenharia de dados. E daqui a umas semanas indo para tecnologias P2P, como parte da minha jornada em entender como podemos construir um futuro tecnológico justo.
- Eu sou consultora de desenvolvimento de software na Thoughtworks que se define como comunidade de indivíduos apaixonados cujo objetivo é revolucionar o design, a criação e o fornecimento de softwares, ao mesmo tempo em que defende mudanças sociais positivas. ela está presente em 14 países com 42 escritórios e no brasil tem escritórios em Porto Alegre, aqui em São Paulo, BH e um no país Recife que é de onde eu venho. Uma das coisas bacanas que a Thoughtworks faz, é semestralmente disponibilizar o radar tecnológico. Que é um compilado de tendências que ela disponibiliza pra comunida, baseada nas nossas experiências no dia-a-dia de projetos. .
- Como tudo na vida é importante setar as espectativas
- O meu cliente é do setor de energia e tem como foco o uso otimizado de energia através de ferramentas de automação. Em um contexto breve, o objetivo do meu projeto é que através da leituras de sensores instalados em aparelhos elétricos, como por exemplo um ar condicionado, passar a ser checadas falhas e a causa raiz de porque aquele aparelho está consumindo mais energia do que esperado. é um propósito bacana para os três lados, para o meu cliente(como capitalização de um produto), para o cliente do meu cliente (que economiza energia e dinheiro) e para o planeta(menos consumo de energia, menos uso de termelétricas e outras fontes não sustentáveis).
- Para que essa automação de falhas seja gerada, existe um ecossistema com aproximadamente 14 serviços, aplicações e scripts. nossa tech stack é composta de frameworks como Spark, messageria com kafka e kinesis, além de Java com Spring boot, React, NodeJs e linguagens como Scala, Java, Python e JavaScript. muitos desses serviços auxiliares que falei, estão representados na figura por essas setas azuis. o coração do nosso processamento de dados é representado pela figura legendada como Pipeline de Detecção de falhas, onde processamos as leituras que recebemos do ETL, do dia anterior, e nele são aplicados alguns cálculos feitos pelos engenheiros de energia do cliente. No final esses dados processados
- falar um pouco sobre o projeto: leirura de sensores de prédios com o objetivo de checar o consumo de energia de aparelhos e reportar as causas dos problemas no final
- falar da tech stack da streaming
- transcrevendo essa definição para software, resiliência pode ser entendido como a capacidade de um aplicativo de se recuperar de certos tipos de falha e ainda assim permanecer funcional na perspectiva do cliente. No mundo de software resiliência está associada com outra palavra, confiabilidade, que é uma meta que desenvolvedores buscam, operação perfeita o tempo todo. Ou seja meu software é confiável se seus recursos poderem se recuperar de falhas.
- Trazendo a Resiliência para o contexto de engenharia de dados há três pontos que eu acho interessantes você como pessoa desenvolvedora se questionar. escalabilidade: minha aplicação está é a medida de quão bem um serviço ou aplicativo pode crescer para atender às crescentes demandas de desempenho. Monitoramento de dados e alertas são ferramentas muito usadas para compreender limites de processamento. Os SLAs( SLA é a sigla de Service Level Agreement, que significa “Acordo de Nível de Serviço - ANS”) Disponibilidade: minha aplicação precisa ter downtime 0? ou seja, ela nunca pode está fora do ar? em um cenário de procesamento em bacth talvez isso não precise ser pensado a risca, já em um cenário de streaming com intervalos de recebimento de dados pequenos o tempo de disponibilidade da minha aplicação já passa a ser algo mais crítico. escalabilidade e redundância ajudam um sistema a não quebrar completamente em caso de falha. mas para ser realmente resiliente, precisamos ser capazes de lidar com falhas e recuperar o estado pretendido / original do aplicativo.
- Adicionar dados do email de limitação do Kinesis
- adicionar mecanismos de reprocessamento de lambdas: explicar o backup dos dados informar do monitoramente de write capacite explicar o funcionamento do job do jenkins
- O que é Dead Letter Queues? Na fila de mensagens, a fila de mensagens mortas é uma implementação de serviço para armazenar mensagens que atendem a um ou mais dos seguintes critérios: Mensagem enviada para uma fila que não existe. [1] [2] Limite de comprimento da fila excedido. Limite de tamanho da mensagem excedido. A mensagem é rejeitada por outra troca de filas. [3] A mensagem atinge um número de contador de leitura de limite, porque não é consumido. Às vezes isso é chamado de "fila de recuo". O armazenamento da fila de mensagens mortas dessas mensagens permite que os desenvolvedores procurem padrões comuns e possíveis problemas de software. [4]
- adicionar mecanismos de reprocessamento de lambdas: explicar o backup dos dados informar do monitoramente de write capacite explicar o funcionamento do job do jenkins
- MVP é MVP: não podemos esperar aplicar todos os cenários de tolerância a falha na primeira versão de um mínimo produto viável. Isso dever ser feito de forma incremental nas próximas versões; entenda as necessidades do contexto atual: tínhamos uma janela de uma hora de downtime, não precisamos aplicar práticas mais robustas e complexas de resiliência. Deve se entender o que é necessário entregar naquele momento. entenda as limitações da equipe: o MVP foi construído em um período de poucos meses, como dito antes, não havia como implementar todas irão ser geradas dívidas técnicas: a partir dessa versão e do entendimento melhor de algumas técnicas, já sabemos que precisaremos rever alguns pontos da arquitetura, principalmente quando o downtime ficar mais reduzido. Alguns podem também entender não como dívidas técnicas porque é um olhar pra uma expectativa futura do produto
- Construindo Microserviços, Sam Newman Projetando aplicativos com uso intensivo de dados, Martin Kleppmann