Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Como arquiteturas de dados quebram

259 views

Published on

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

Published in: Technology
  • Be the first to comment

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

×