O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Como arquiteturas de dados quebram

265 visualizações

Publicada em

Apresentação na QCon São Paulo 2018 sobre Data engineering e casos de arquiteturas com grande volume de dados usando Cassandra, Elasticsearch e Postgresql

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Como arquiteturas de dados quebram

  1. 1. Como arquiteturas de dados quebram Data Engineering 101 Gleicon Moraes
  2. 2. Data Engineering life ● Descobrir legados ● Administrar storage, message queue, scheduling ● Refatorar comunicação via DB para APIs ● Treinar e manter modelos ● Backfill, backfills everywhere ● Capacity planning ● Latencia
  3. 3. Como arquiteturas quebram ● Por design ● Por capacidade ● Por falta de dono ● Por escolha de tecnologia
  4. 4. Analytics architecture
  5. 5. Lambda architecture
  6. 6. Data gravity "As Data accumulates (builds mass), there is a greater likelihood that additional Services and Applications will be attracted to this data. (...) Data, if large enough, can be virtually impossible to move." Dave McCrory * *https://blog.mccrory.me/2010/12/07/data-gravity-in-the-clouds/
  7. 7. Data gravity
  8. 8. Data gravity
  9. 9. Data gravity
  10. 10. Data gravity
  11. 11. Data gravity
  12. 12. O caso do cluster sem cabeça ● ScyllaDB 0.0x ● Cluster 6 nodes Multi-AZ ● 1.5 TB Raid/Node ● 3 Seeds nodes ● 4 Keyspaces ● 65% ocupado ● 35 - 50k writes/sec, picos de 150k writes/sec
  13. 13. O caso do cluster sem cabeça
  14. 14. O caso do cluster sem cabeça
  15. 15. O caso do cluster sem cabeça
  16. 16. O caso do cluster sem cabeça
  17. 17. O caso do cluster sem cabeça ● 16h de manutenção (nodetool cleanup usava todos cores) ● Um cluster de Cassandra para cada keyspace ● 3 meses de migração ● De 6 para 63 nodes ● Crescimento de 7x do volume de dados. ● Take out 1: Não se empolgar com bancos de dados imaturos ● Take out 2: Não concentrar todas aplicações no mesmo data store ● Take out 3: Melhor escalar horizontalmente do que verticalmente
  18. 18. Analytics ● Analytics pipeline ● Relatórios sobre longos períodos de tempo ● Volume de dados cresceu 7x em 10 meses ● Bases de dados compartilhadas ● Meio baseado em eventos, meio baseado em ETLs
  19. 19. Analytics Batch Processing
  20. 20. Analytics Batch Processing
  21. 21. Analytics Online Processing
  22. 22. Analytics ● Sair de ETLs para streams de dados ● Não compartilhar data storages ● Não se comunicar por data storages ● Sair de consumidores baseados em Spark ● Pré calcular relatórios
  23. 23. Obrigado ! ● github.com/gleicon ● medium.com/@gleicon ● twitter.com/gleicon ● gleicon@gmail.com

×