Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Agilidade, escalabilidade, e ordem com Kafka e ...

Opensanca
November 13, 2019

Agilidade, escalabilidade, e ordem com Kafka e Dataflow

Apresentação do Data Meetup v2019.4 por Leonardo Miguel.

Opensanca

November 13, 2019
Tweet

More Decks by Opensanca

Other Decks in Technology

Transcript

  1. Eu • Engenheiro de Dados na Arquivei • CAASO ◦

    BCC 012 ◦ MECAI 017 • Corote pêssego - ok • Tauber e Lokal - não ok
  2. Eu • Engenheiro de Dados na Arquivei • CAASO ◦

    BCC 012 ◦ MECAI 017 • Corote pêssego - ok • Tauber e Lokal - não ok • Java - ok • JavaScript - não ok
  3. Dataflow model • Akidau, 2015 • “Modern data processing is

    a complex and exciting field.” • Junta dois papers: ◦ FlumeJava ◦ MillWheel • Batchs existentes ◦ Alta latência • Streaming existentes ◦ Tolerância a falhas, escalabilidade, latência ◦ Complexidade de janelamento
  4. Dataflow model • Akidau, 2015 • Propõe um modelo de

    programação simples para processamento de dados ◦ Event time ◦ Processing time
  5. Dataflow model • Akidau, 2015 • Propõe um modelo de

    programação simples para processamento de dados ◦ Divide pipelines em 4 dimensões ▪ Quais resultados computados? ▪ Onde serão computados? (em event time) ▪ Quando serão materializados? (em processing time) ▪ Como refinar dados recentes mais tarde?
  6. Streaming vs Batch • Streaming -> Unbounded • Batch ->

    Bounded • Unbounded: processado em batch systems • Streaming systems: capazes de processar batches
  7. Windows • Não é um sistema operacional • Divisão do

    dataset para processamento • Aligned: se aplica a todo dataset • Unaligned: se aplica a um subset
  8. Triggers • Determina quando um GroupByKeyAndWindow ocorre • Window: determina

    onde os dados serão agrupados (event time) • Trigger: determina quando os resultados dos agrupamentos serão emitidos (processing time)
  9. Triggers • Late data: atraso no event time em relação

    ao processing time • Refinamentos: ◦ Descarte: resultados futuros não dependem de dados passados ◦ Acúmulo: resultados futuros dependem de dados passados ◦ Acúmulo + Retração: ▪ resultados futuros dependem de dados passados ▪ resultados passados dependem de dados futuros
  10. Por que Kafka? • Reliable Data Delivery ◦ Dados de

    várias criticidades • Garantias ◦ Ordem ◦ Commits ▪ Uma vez commitado, dado não será mais perdido ▪ Somente serão lidos dados commitados
  11. Por que não Kafka? • Reliable Data Delivery ◦ Acaba

    gerando muitas arquiteturas ruins • Garantias ◦ Depende de uma série de configs
  12. Plataforma distribuída de streaming • O que é streaming? ◦

    Unbounded == infinite • Streams ◦ Ordenados ◦ Imutáveis ◦ Repetíveis (replayable)
  13. Plataforma distribuída de streaming • Request-response: um sistema espera outro

    • Batch: dados processados de tempos em tempos • Streaming ◦ Não é necessário espera ◦ Processamento contínuo
  14. Streaming: conceitos • Tempo ◦ Event time ◦ Processing time

    ◦ Log append time (tempo no Kafka) • Estado ◦ Interno: acessado apenas por um sistema ◦ Externo: disponível para outros sistemas
  15. Streaming: conceitos • Dualidade tabela-stream ◦ Table: coleção de registros

    ◦ Stream: cadeias de eventos que modificam algo • Table != Stream • Tabela pode ser convertida em stream (CDC) • Stream pode ser convertida em tabela (materialização) • Diferentes tipos de redundância
  16. Streaming: diferentes modelos • Local state • Problemas: ◦ Estado

    deve caber em memória ◦ Persistência ◦ Rebalanceamento
  17. Por onde começamos? • Descobrimos GCP ◦ Google Dataflow ▪

    Gerenciado ▪ Python ▪ Modelo fácil de programação
  18. Por onde começamos? • Descobrimos GCP ◦ Google Dataflow ▪

    Gerenciado ▪ Python (Java) ▪ Modelo fácil de programação ▪ Streaming! ▪ ...outra nuvem
  19. Por onde começamos? • Google Dataflow ◦ Rápido de aprender

    ◦ Escalável ◦ Zero infra ◦ Problemas de escalabilidade ▪ Outros sistemas sofrendo
  20. Por onde começamos? • Google Dataflow ◦ Batch! ▪ Default

    ◦ Streaming: ▪ Pipe genérico ▪ Backup ▪ Auditorias em “real-time” ▪ DWs “real-time” ◦ Batch+Streaming ▪ Migrações ▪ DWs “real-time” com histórico
  21. Por onde começamos? • Google Pub/Sub ◦ Barato ◦ Gerenciado

    ◦ Simples ◦ Libs prontas ◦ Problemas: ▪ Latência para AWS ▪ Ordem ◦ Não sabíamos usar Mensageria
  22. Por onde começamos? • Requisitos do pipeline de dados ◦

    Pouca infra ◦ Deploys fáceis para produtores e consumidores ▪ Desacoplado ▪ Independente
  23. Por onde começamos? • Apache Kafka ◦ Overhead de Infra

    ◦ Curva de aprendizado ◦ Escalabilidade ▪ Partições ◦ Modelos de produção ▪ Confiável ▪ Escalável ◦ Modelos de consumo ▪ Escalável ◦ Libs limitadas para PHP
  24. Como é hoje? • Apache Kafka ◦ Principal ferramenta de

    mensageria • Google Pub/Sub ◦ Usado para comunicação entre jobs • Google Dataflow ◦ Principal ferramenta de processamento de dados • Microsserviços em Go ◦ Principal ferramenta de processamento para sistemas • Kafka Streams ◦ Ferramenta alternativa de processamento em streaming
  25. Kafka vs Pub/Sub? • Apache Kafka ◦ Padrão ◦ Requisito

    de ordem ◦ Reprocessamento mais fácil ◦ Ecossistema • Google Pub/Sub ◦ Modelo permite retry ◦ Substitui HTTP Sync
  26. Dataflow vs Go? • Dataflow ◦ DataEng ◦ Autoscaling ◦

    Migrações, reprocessamentos ◦ Replicação de dados • Go ◦ Backend ◦ Baixa latência ◦ Sistemas reativos
  27. Dataflow vs Streams? • Dataflow ◦ Autoscaling ◦ Reprocessamento •

    Streams ◦ Mais leve ◦ Entrada e Saída no Kafka
  28. Formato de mensagens • JSON -> Avro • Schema ◦

    ID ◦ Version ◦ Source ◦ Type ◦ Data
  29. That’s all folks Bom TUSCA a todos! Raça CAASO! Bibliografia

    • “I Heart Logs” - Jay Kreps • “The Dataflow Model: A Practical Approach to Balancing” - Akidau • “Kafka: The Definitive Guide” - Confluent