Engenharia de Dados 101

Dilemas, stack e problemas da engenharia de dados ;)

Transcript

1. ENGENHARIA DE DADOS 101
2. quem eu sou • Comecei técnico no Fernando em 2009 e odiei; • Formei em engenharia mecatrônica (promissor); • Acabei virando cientista (criminoso), analista de dados até me encontrar como Engenheiro; • Passei pela Gamers Club, Gympass, idwall e hoje trabalho como Team Lead SR Data Engineer na 90PoE; • No pessoal: Tenho dois gatos: Vorti e Ciri. Gosto de viajar, samba, cerâmica, bebidas alcoólicas, fotografia analógica e sou ex-viciado em jogos competitivos.
3. mas afinal, o que é engenharia de dados?
4. (eu também não sei)
5. cuida da plataforma de dados que é consumida por analíticos, relatoriais, modelagens (ciência de dados) ou mesmo transacionais.
6. mas qual problema a eng. de dados resolve?
7. história
8. queremos analisar dados!
9. o primeiro problema surge
10. mas como um banco transacional reage?
11. queries "pesadas" oneram o banco
12. banco transacional não foi desenhado para queries analíticas
13. mas tudo é contornável • adicionar indíces para melhorar a performance; ◦ tudo que resta é dor, pois afeta diretamente outros sistemas produtivos • colocar uma réplica asíncrona e exclusivamente para a ponta de reporting ◦ essa não é tão ruim (mas depende) • recomeçar com uma alternativa sustentável do início.
14. extrair transformar load (carregar)
15. Pipeline v1
16. • Isolar infraestrutura é importante em nível de propósito (análise ≠ aplicação); • Pode-se criar diferentes scripts para ingerir de diferentes fontes; • Flexibilidade para construir tabelas que sejam otimizadas para análise de negócio e não para transações O que ganhamos:
17. As fontes diversificam
18. Pipeline v1
19. Mais fontes: + dados para armazenar e processar
20. • Nem todo dado vai ser consultado o tempo todo; • Latência de query não é um problema; ◦ Uma query analítica não tem percepção de diferença de alguns milisegundos para poucos segundos; • Muitos dados :(: ◦ Arquivos podem usar compressão! ( - custo, - network) Características:
22. aqui começa um pouco de loucura
23. armazenar Object Storage (s3, Gcs & azure blob storage)
24. em formato de parquet (mas poderia ser json, txt, csv, etc)
25. respira Um Estranho no Ninho (1975)
26. parquet: armazenamento orientado a colunas
27. Linha vs Colunar id nome idade 1 Gordon Freeman 27 2 Jane Doe 27 3 John Doe 32
28. Linha vs Colunar 1, Gordon Freeman, 27 ; 2, Jane Doe, 27 ; 3, John Doe, 32 Linha (localidade para cada registro) 1, 2, 3 ; Gordon Freeman, Jane Doe, John Doe ; 27, 27, 32 Colunar (localidade para cada coluna)
29. compressão
30. Run length encoding (RLE) 1, 2, 3 ; Gordon Freeman, Jane Doe, John Doe ; 27, 27, 32 Colunar 1, 2, 3 ; Gordon Freeman, Jane Doe, John Doe ; 27(2), 32 Colunar (row length encoding)
31. Outras firulas Bit-map Bitpacking Vale a pena entender a cunho de curiosidade
32. Pipeline v2
33. performance
34. queries analíticas são um pouco diferentes
35. e muitas vezes só usam um subset dos dados 5 colunas utilizadas Se cada tabela ter 20 colunas, isso significa que polpamos o scan de 18 + 17 (35) colunas na operação. *essa query pode ser melhorada ;)
36. ou não: nem sempre é bala de prata.
37. Bladerunner (1982)
38. Como saber quais tabelas estão no filesystem?
39. Introduzindo: Catálogo (que só é um catálogo mesmo)
40. E um motor de query (Trino/Presto/Athena)
41. Pipeline v3
42. • Isolamos (na medida do possível) o banco de aplicação da nossa pipeline; • Flexibilidade para processar fontes diferentes; • Armazenamento com alta disponibilidade e baixo custo para o alto volume de dados; • Parquets dão eficiência em compressão e performance de leitura; • Nosso motor de query (Trino) pode escalar para picos de uso durante o dia; Em suma:
43. • Propriedades ACID de banco que são importantíssimas; ◦ Existem "Modern Lake tools" que combinam parquet + metadata para dar suporte nisso; • Muitas "partes móveis" que dificultam desenvolvimento, teste e monitoramento; • Dilemas em controlar acesso (ACL); • Complexidade. Mas também perdemos:
44. linguagens
45. Comum: Python e Scala
46. Muitas libs úteis e são duas das linguagens suportadas pelo Apache Spark, um processador de dados distribuído (para atender muito volume)
47. mas dá para fazer MUITA coisa com bash/shell e é importantíssimo ter o básico.
48. infraestrutura
49. onde deployar?
50. Kubernetes, lambdas (aws) ou ECS (aws)
51. e se for em algum recurso da cloud: Terraform (ou algum IaC) é sempre bem vindo
52. mas os scripts rodam 100% do tempo?
53. não, muitas análises usam dados do dia anterior e não precisam do dia corrente;
54. e aí precisamos de mais um item: um orquestrador que vai definir a lógica e horários de execução
55. Crontabs e hoje crontab 0 0 * * * minuto hora dia mês dia da semana Airflow define ordem de execução, horários, mantém variáveis e secrets bem como invoca código, containers, pods e o que mais precisar;
56. o que preciso aprender?
57. Algumas coisinhas • SQL e uma linguagem como Scala/Python; • Uma stack de cloud (AWS/GCS/Azure); • Bash; • Docker; • Entender e saber do funcionamento de alguns bancos de dados; • Apache Spark. Legal ter: Airflow, Kubernetes, Terraform, Monitoria, Kafka, boas noções de deployment, CI/CD etc;
58. é muito comum back-ends ou cientistas/analistas migrarem para engenharia de dados
59. é muito comum back-ends ou cientistas/analistas migrarem para engenharia de dados
60. Ótimo para qualquer área que mexa com dados
61. Introdutório
62. Slack + newsletter com bastante conteúdo de dados em geral (PT) https://www.datahackers.com.br/
63. Data Engineering Weekly (em Ingles): https://www.dataengineeringweekly.com/
64. extras
65. How Levels.fyi scaled to millions of users with Google Sheets as a backend link
66. minhas redes
67. obrigado!
68. dúvidas?