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.
Slide 3
Slide 3 text
mas afinal, o que é
engenharia de dados?
Slide 4
Slide 4 text
(eu também não sei)
Slide 5
Slide 5 text
cuida da plataforma de dados
que é consumida por
analíticos, relatoriais,
modelagens (ciência de dados)
ou mesmo transacionais.
Slide 6
Slide 6 text
mas qual problema a
eng. de dados resolve?
Slide 7
Slide 7 text
história
Slide 8
Slide 8 text
queremos analisar dados!
Slide 9
Slide 9 text
o primeiro problema surge
Slide 10
Slide 10 text
mas como um banco transacional reage?
Slide 11
Slide 11 text
queries "pesadas" oneram o banco
Slide 12
Slide 12 text
banco transacional
não foi desenhado
para queries analíticas
Slide 13
Slide 13 text
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.
Slide 14
Slide 14 text
extrair
transformar
load (carregar)
Slide 15
Slide 15 text
Pipeline v1
Slide 16
Slide 16 text
● 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:
Slide 17
Slide 17 text
As fontes diversificam
Slide 18
Slide 18 text
Pipeline v1
Slide 19
Slide 19 text
Mais fontes:
+ dados para
armazenar e processar
Slide 20
Slide 20 text
● 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:
em formato de
parquet
(mas poderia ser json, txt, csv, etc)
Slide 25
Slide 25 text
respira
Um Estranho no Ninho
(1975)
Slide 26
Slide 26 text
parquet:
armazenamento orientado a
colunas
Slide 27
Slide 27 text
Linha vs Colunar
id nome idade
1 Gordon Freeman 27
2 Jane Doe 27
3 John Doe 32
Slide 28
Slide 28 text
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)
Slide 29
Slide 29 text
compressão
Slide 30
Slide 30 text
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)
Slide 31
Slide 31 text
Outras firulas
Bit-map Bitpacking
Vale a pena entender a cunho
de curiosidade
Slide 32
Slide 32 text
Pipeline v2
Slide 33
Slide 33 text
performance
Slide 34
Slide 34 text
queries analíticas são um pouco diferentes
Slide 35
Slide 35 text
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 ;)
Slide 36
Slide 36 text
ou não: nem sempre é bala de prata.
Slide 37
Slide 37 text
Bladerunner (1982)
Slide 38
Slide 38 text
Como saber quais tabelas estão no filesystem?
Slide 39
Slide 39 text
Introduzindo: Catálogo (que só é um catálogo mesmo)
Slide 40
Slide 40 text
E um motor de query (Trino/Presto/Athena)
Slide 41
Slide 41 text
Pipeline v3
Slide 42
Slide 42 text
● 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:
Slide 43
Slide 43 text
● 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:
Slide 44
Slide 44 text
linguagens
Slide 45
Slide 45 text
Comum:
Python e Scala
Slide 46
Slide 46 text
Muitas libs úteis e são duas das
linguagens suportadas pelo
Apache Spark, um processador de
dados distribuído
(para atender muito volume)
Slide 47
Slide 47 text
mas dá para fazer MUITA coisa com
bash/shell e é importantíssimo ter o
básico.
Slide 48
Slide 48 text
infraestrutura
Slide 49
Slide 49 text
onde deployar?
Slide 50
Slide 50 text
Kubernetes,
lambdas (aws)
ou ECS (aws)
Slide 51
Slide 51 text
e se for em algum recurso da
cloud: Terraform (ou algum
IaC) é sempre bem vindo
Slide 52
Slide 52 text
mas os scripts rodam
100% do tempo?
Slide 53
Slide 53 text
não, muitas análises usam
dados do dia anterior e não
precisam do dia corrente;
Slide 54
Slide 54 text
e aí precisamos de mais um
item: um orquestrador que
vai definir a lógica e horários
de execução
Slide 55
Slide 55 text
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;
Slide 56
Slide 56 text
o que preciso aprender?
Slide 57
Slide 57 text
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;
Slide 58
Slide 58 text
é muito comum back-ends ou
cientistas/analistas migrarem
para engenharia de dados
Slide 59
Slide 59 text
é muito comum back-ends ou
cientistas/analistas migrarem
para engenharia de dados
Slide 60
Slide 60 text
Ótimo para qualquer
área que mexa com
dados
Slide 61
Slide 61 text
Introdutório
Slide 62
Slide 62 text
Slack + newsletter com
bastante conteúdo de
dados em geral (PT)
https://www.datahackers.com.br/
Slide 63
Slide 63 text
Data Engineering
Weekly (em Ingles):
https://www.dataengineeringweekly.com/
Slide 64
Slide 64 text
extras
Slide 65
Slide 65 text
How Levels.fyi scaled to millions of users with
Google Sheets as a backend
link