1. Como praticar
1.1. https://www.hackerrank.com/
1.2. https://exercism.org/
1.3. https://leetcode.com/
1.4. https://www.codecademy.com/
1.5. https://www.alura.com.br/
1.6. https://judge.beecrowd.com/pt/login
1.6.1. Brasileiro, muito bom!
2. A Engenharia de Dados
2.1. Falamos sobre a profissão, de modo técnico, mas aqui é o momento de você ir além.
2.1.1. O que é um engenheiro de dados?
2.2. No papel, temos diversas responsabilidades
2.2.1. Desenvolver pipelines de qualidade
2.2.2. Prezar pela eficiência dos pipelines
2.2.3. Seguir as diretrizes de governança
2.2.3.1. Governança de Dados
2.2.4. Entregar dados de alta qualidade
2.2.5. Nos mantermos atualizados quanto às tecnologias
2.3. Mas esses são apenas alguns dos pontos importantes da profissão.
2.3.1. O Engenheiro tem um papel que vai além, que é o que mais tem valorizado a profissão
2.3.1.1. Ele é o motor de valor dos dados que são utilizados pela companhia.
2.4. Sem um bom time de engenharia de dados
2.4.1. O time de BI não funciona bem
2.4.2. O time de ciência de dados não funciona bem
2.4.3. O time de machine learning não funciona bem
2.4.4. O time de business não funciona bem
2.5. O engenheiro de dados é responsável pela parte mais importante dos dados
2.5.1. A disponibilização.
2.5.1.1. Se os dados são disponibilizados sem qualidade, de forma incorreta, todo o downstream é prejudicado
2.5.1.1.1. Downstream é tudo o que se segue depois
2.5.1.1.2. Upstream é tudo o que veio antes
2.6. Essa profissão tem ganhado mais tração (e vai continuar ganhando) porque é algo fundamental em qualquer time de dados
2.6.1. Existem empresas que contratam três engenheiros de dados para cada um cientista.
2.6.2. Em casos parecidos, você tem 3 a 5 vezes mais chances de conseguir um emprego, porque você tem um volume de vagas disponíveis muito maior
2.7. Além disso, a demanda por engenheiros acompanha, diretamente, a evolução do horizonte de dados
2.7.1. Quanto mais dados esperamos ser produzidos, mais engenheiros precisamos
2.8. É uma profissão que não tem perspectiva de frenagem. Quanto mais o tempo passa, mais precisamos de engenheiros de dados.
3. Analytics
3.1. Já falamos um pouco sobre dados e Big Data, mas precisamos afunilar um pouco mais o tema
3.2. Analytics é o uso de dados em seu mais alto nível e valor possível.
3.3. Analytics é sobre aplicar técnicas matemáticas, estatísticas e modernas para extrair valor de dados e construir produtos estratégicos.
3.3.1. É sobre elevar o valor dos dados para a tomada de decisão.
3.4. Todas as profissões especialistas de dados estão envoltas no universo de analytics.
3.5. É muito importante que você estude mais sobre esse conceito
3.5.1. O que é analytics?
3.5.2. Como extrair valor através de analytics?
3.5.3. O que é "infonomics"? Como isso se relaciona com "dados são o novo petróleo"?
3.5.3.1. https://www.youtube.com/watch?v=km8E5DCBexI&pp=ugMICgJwdBABGAHKBQppbmZvbm9taWNz
3.5.3.2. https://www.youtube.com/watch?v=p73iVdd-o7c&pp=ugMICgJwdBABGAHKBQppbmZvbm9taWNz
3.6. Mais um tópico de estudo
3.6.1. Self-service Analytics
4. Modelos de armazenamento
4.1. Bancos de dados relacionais
4.1.1. É um dos assuntos mais importantes da engenharia de dados
4.1.2. Sem esse tipo de banco de dados, não existiria nada.
4.1.3. É um banco de dados que se baseia em tabelas, que podem ser modeladas de várias formas
4.1.3.1. Pesquise por "modelagem de dados", principalmente sobre
4.1.3.1.1. Modelo dimensional
4.1.3.1.2. UML
4.1.3.1.3. DER (Diagrama Entidade-relacionamento)
4.1.4. É importante você escolher um banco de dados para chamar de "seu"
4.1.4.1. MySQL
4.1.4.2. PostgreSQL
4.1.4.3. Oracle
4.1.4.4. Microsoft SQL Server
4.1.5. É muito importante entender de bancos de dados e sua estrutura, porque tudo depois daqui se baseia nisso (de alguma forma)
4.1.6. Aqui, um dos tópicos mais importante para fixar são as três formas normais
4.1.6.1. Essas formas ditam as estruturas das tabelas e como organizá-las de modo a preservar o que entendemos por "ACID"
4.1.6.1.1. A - Atomicidade
4.1.6.1.2. C - Consistência
4.1.6.1.3. I - Isolamento
4.1.6.1.4. D - Durabilidade
4.1.6.2. Esse conceito é extremamente importante, você precisa entender o máximo possível dele
4.1.7. O Curso do Felipe Mafra já resolve quase tudo (incluindo SQL)
4.1.7.1. https://www.udemy.com/course/bancos-de-dados-relacionais-basico-avancado/
4.2. Bancos de dados não-relacionais
4.2.1. Com o advento do Big Data e o aumento massivo de volume e variedade de dados, descobrimos um grande problema
4.2.1.1. Armazenar dados apenas em tabelas dava muito trabalho
4.2.1.2. Como você armazena vídeos?
4.2.1.3. Como você armazena sons?
4.2.1.4. Como você armazena imagens?
4.2.2. Isso trouxe a necessidade de inovar, mais uma vez, a forma com que tratávamos nossos dados
4.2.2.1. Pense que antes, tínhamos dados estruturados, que vinham com uma forma definida (que chamamos de schema)
4.2.2.1.1. Estude sobre o conceito de "schema", é uma das coisas mais importantes da estrutura de um dado
4.2.2.2. Agora, os dados não tem um schema definido ou tem um muito fluído
4.2.2.2.1. Esses novos tipos de dados ficaram conhecidos como
4.2.2.3. Como lidamos com esses novos tipos de dados?
4.2.3. Daí nasceram os bancos que conhecemos como "NoSQL"
4.2.3.1. Algumas pessoas traduziram como "No Structure Query Language", como uma forma de negação ao SQL (por não haver uma tabela)
4.2.3.2. Hoje, entendemos a sigla como "Not Only SQL"
4.2.4. Os bancos não relacionais se baseiam, basicamente em três tipos
4.2.4.1. Bancos orientados a documentos
4.2.4.2. Bancos orientados a chave-valor
4.2.4.3. Bancos orientados a grafos
4.2.4.3.1. Estude a teoria dos grafos, vai fazer muito sentido
4.2.4.3.2. É o banco que possibilita a existência de redes sociais, por exemplo
4.2.5. Dentre os bancos NoSQL mais utilizados, temos
4.2.5.1. MongoDB
4.2.5.2. CassandraDB
4.2.5.3. Neo4J
4.2.5.4. Redis
4.2.5.5. Elasticsearch
4.2.5.6. Couchbase
4.2.5.6.1. CouchDB
4.2.6. A necessidade de se aprofundar em um banco de dados NoSQL é muito complicada
4.2.6.1. Boa parte das empresas do Brasil não utiliza, por conta da complexidade
4.2.6.2. Boa parte das empresas do exterior utiliza, por conta da praticidade e otimização
4.2.6.3. Um grande ponto é: existem ferramentas de dados que ignoram se o bancos de dados é relacional ou não e transformam tudo em tabelas
4.2.6.3.1. Como o Apache Spark, por exemplo
4.2.7. O que eu recomendo
4.2.7.1. Estude o conceito
4.2.7.2. Escolha qualquer um dos bancos
4.2.7.2.1. Eu recomendo o MongoDB ou o CouchDB
4.2.7.3. Implemente uma solução seguindo a documentação
4.2.7.4. Entenda como ele se difere dos bancos relacionais de antes
4.2.8. O Mafra tem um curso de NoSQL muito bom
4.2.8.1. https://www.udemy.com/course/curso-banco-de-dados-nosql-mongodb-neo4j-redis/
4.3. Data Warehouses
4.3.1. Também chamado carinhosamente de DW"
4.3.2. Quando aumentamos a complexidade e volume dos nossos dados relacionais, tropeçamos em um outro problema
4.3.2.1. Como, cargas dágua, consultamos esses dados?
4.3.3. Imagine o seguinte cenário
4.3.3.1. Você tem uma empresa que já tem um banco de dados rodando
4.3.3.2. Esse banco de dados é responsável por registrar seus pedidos/vendas
4.3.3.3. As pessoas da sua empresa aprendem SQL e começam a usar esse banco de dados para consultar informações
4.3.3.4. O que acontece conforme mais e mais pessoas vão executando essas consultas SQL?
4.3.3.4.1. O banco tomba.
4.3.4. A partir desse cenário, temos a divisão do armazenamento de dados em dois grandes blocos, basicamente
4.3.4.1. O ambiente transacional
4.3.4.1.1. Conhecido como OLTP
4.3.4.2. O ambiente analítico
4.3.4.2.1. Conhecido como OLAP
4.3.4.3. Você precisa ter muito claro os dois conceitos, porque isso é fundamental para entender a necessidade do data warehouse
4.3.4.4. Além da necessidade, cada um dos ambientes tem suas características próprias como
4.3.4.4.1. Modelagem das tabelas presentes
4.3.4.4.2. Otimização de consultas x otimização de escritas
4.3.4.4.3. Plataformas onde os data warehouses são construídos
4.3.5. O Data Warehouse tem uma premissa clara
4.3.5.1. Facilitar a consulta de dados em grande escala
4.3.6. As tabelas, aqui dentro, tendem a ser modeladas de forma com que ocorram o mínimo de joins possíveis
4.3.6.1. O que faz com que as tabelas tenham MUITAS colunas
4.3.6.1.1. Não é incomum ter tabelas com mais de 100 colunas para trabalhar
4.3.7. Aqui, o foco é trabalhar os domínios do negócio e responder de forma rápida as perguntas mais relevantes
4.3.7.1. Quantas vendas foram realizadas no último mês?
4.3.7.1.1. Uma informação como essa, quando respeitadas as formas normais, pode envolver uma quantidade enorme de tabelas
4.3.7.1.2. Em um data warehouse, não
4.3.8. É o que chamamos de bancos de dados orientados à consultas
4.3.9. Se você se apaixonar pelo assunto, recomendo ler o livro mais conhecido do mercado
4.3.9.1. https://www.amazon.com.br/Data-Warehouse-Toolkit-Definitive-Dimensional/dp/1118530802
4.4. Data Lakes
4.4.1. Aqui é onde as coisas começam a ficar *REALMENTE* interessantes
4.4.2. Por mais que o data warehouse seja importante para a construção de um ambiente analítico, ainda temos uma limitação
4.4.2.1. Estamos sempre falando de tabelas
4.4.3. Com o avanço do Big Data, precisamos de um lugar para salvar os arquivos não-estruturados e semi-estruturados que discutimos antes
4.4.4. Com isso, nascem o "data lakes"
4.4.4.1. Uma forma de armazenar arquivos, que podem ser estruturados, semi-estruturados ou não-estruturados
4.4.4.2. É como se fosse uma grande pasta, onde podem ficar vários tipos de arquivo dentro
4.4.4.3. Você usa de programas específicos, como um script em Python, para ler e estruturar esses arquivos de forma trabalhável
4.4.5. Os data lakes possibilitaram uma grande disrupção na tecnologia
4.4.5.1. Agora, não existiam mais limites para o que poderia ser salvo
4.4.6. O que causou um problema gigantesco
4.4.6.1. Agora, não existiam mais limites para o que poderia ser salvo
4.4.7. Apesar de ser um modelo extremamente robusto, com uma infinidade de vantagens, existem algumas desvantagens-chave que levaram à sua revolução
4.4.7.1. Não há atomicidade (ACID)
4.4.7.2. O controle da qualidade de dados é muito complexo
4.4.7.2.1. O que gera um novo conceito, chamado de "data swamp"
4.4.7.3. A não-estrutura dos dados demanda uma nova camada de trabalho para que analistas de dados e BI possam consumí-los
4.4.7.3.1. O que posteriormente foi resolvido por tecnologias como dbt e Spark
4.4.7.4. As consultas são mais lentas, porque estamos lidando com arquivos que precisam ser consolidados, interpretados e trabalhados
4.4.7.5. Segurança e governança se tornam questões muito mais críticas e complexas
4.4.8. Como toda tecnologia tem seu tempo, o data lake deu espaço à algo muito maior
4.5. Data Lakehouses
4.5.1. Onde nascem os data lakehouses
4.5.2. A proposta do data lakehouse é simples
4.5.2.1. Trazer a flexibilidade do data lake com a confiabilidade do data warehouse
4.5.3. Baseado em um formato de dados que revolucionou o mundo de dados, o Delta, os lakehouses trazem uma vantagem gigantesca de manipulação de dados
4.5.3.1. Inclusive, é mandatório estudar Delta para se dar bem
4.5.3.1.1. https://delta.io/#:~:text=Lake%204.0%20Preview-,Key%20Features,-ACID%20Transactions
4.5.3.2. Além do Delta, existem alguns formatos de dados que são bem críticos nesse momento
4.5.3.2.1. Parquet
4.5.3.2.2. ORC
4.5.3.2.3. Avro
4.5.4. Por enquanto, o lakehouse tem cumprido de forma brilhante o seu papel, sendo o formato adotado pela maioria das grandes empresas
4.5.5. Ele é rápido, seguro, flexível, auditável e eficiente
4.5.5.1. Tudo o que precisamos no contexto atual
4.5.6. Existem desvantagens
4.5.6.1. Os dados nunca são deletados fora da política de vacuum (por exemplo)
4.5.6.2. Pesquise mais downsides/desvantagens
4.5.7. Melhor recurso de estudos
4.5.7.1. https://www.databricks.com/product/data-lakehouse
5. Linguagens
5.1. Estude sobre lógica de programação
5.1.1. Não só programação, como lógica, também
5.1.2. https://portugol.dev/
5.2. Python
5.2.1. É a linguagem de programação mais utilizada do mundo de dados
5.2.2. Python tem um nível de dificuldade muito baixo, em relação a outras linguagens
5.2.2.1. Por isso, as pessoas preferem desenvolver aqui
5.2.3. Hoje, Python tem uma quantidade gigantesca de bibliotecas para trabalhar com dados
5.2.3.1. Biblioteca é o termo utilizado para descrever uma porção de código que já vem pronto para uso
5.2.4. Quando falamos de Python para engenharia de dados, você tem que aprender alguns conceitos chave
5.2.4.1. O que são variáveis
5.2.4.2. Quais são os tipos de dados primários
5.2.4.2.1. int
5.2.4.2.2. float
5.2.4.2.3. string
5.2.4.3. Quais são as estruturas de dados primárias
5.2.4.3.1. lista
5.2.4.3.2. tupla
5.2.4.3.3. dicionário
5.2.4.3.4. conjunto
5.2.4.4. O que são estruturas de controle de código
5.2.4.4.1. if-else
5.2.4.4.2. while
5.2.4.4.3. for
5.2.4.5. O que são funções e classes
5.2.4.6. O que são bibliotecas
5.2.4.6.1. Dentro disso, como funcionam as bibliotecas mais importantes de dados
5.2.4.7. Além disso, existem conceitos fundamentais para você ser bem-sucedido enquanto engenheiro
5.2.4.7.1. Programação orientada a objetos
5.2.4.7.2. Programação funcional
5.2.4.7.3. O compilador C do Python
5.2.4.7.4. Linguagens compiladas x linguagens interpretadas
5.2.4.7.5. Entender o que é um design pattern
5.2.4.7.6. Estudar sobre as PEPs
5.2.4.8. Fontes muito relevantes de cursos para você aprender boa parte do que precisa
5.2.4.8.1. Coursera
5.2.4.8.2. YouTube
5.3. SQL
5.3.1. ***Structured Query Language ***
5.3.2. É A LINGUAGEM de consulta de bancos de dados
5.3.2.1. "A Linguagem", não "uma linguagem"
5.3.2.2. Vale ressaltar que SQL é uma linguagem de consulta, não de programação
5.3.2.3. Por mais que você consiga expressar lógica, ela não é verdadeiramente programática
5.3.2.4. Existem formas de programar em bancos de dados, mas isso é outro assunto
5.3.3. O mundo de dados gira ao redor de SQL e você precisa aprender bastante sobre a linguagem
5.3.4. Existem milhares de cursos por aí, mas eu recomendo 1 que resolve todos os conhecimentos
5.3.4.1. https://www.udemy.com/course/bancos-de-dados-relacionais-basico-avancado
5.3.5. Se você não fizer o curso recomendado, terá que estudar sobre
5.3.5.1. Comandos básicos no SQL
5.3.5.1.1. SELECT
5.3.5.1.2. FROM
5.3.5.1.3. WHERE
5.3.5.1.4. JOIN
5.3.5.1.5. GROUP BY
5.3.5.1.6. ORDER BY
5.3.5.1.7. DISTINCT
5.3.5.2. Comandos de agregação
5.3.5.2.1. SUM
5.3.5.2.2. AVG
5.3.5.2.3. COUNT
5.3.5.2.4. MIN
5.3.5.2.5. MAX
5.3.5.3. Subqueries
5.3.5.4. CTEs
5.3.5.4.1. Common Table Expressions
5.3.5.5. Window Functions
5.3.5.6. Views
5.3.5.6.1. e View materializadas
5.3.5.7. Stored procedures
5.3.5.7.1. Como programar em bancos de dados
5.3.5.8. Particionamento de dados
5.3.5.9. Otimização de queries
5.4. Versionamento de código
5.4.1. Imagine a seguinte situação
5.4.1.1. Você passou dias escrevendo um código muito importante no seu computador
5.4.1.2. No dia de enviar o código para seu superior aprovar, você esbarrou na xícara de café
5.4.1.3. Seu notebook pifou completamente e todo o seu código foi perdido
5.4.1.4. Em pleno 2024, Elon Musk mandando foguete para a lua, não podemos deixar isso acontecer.
5.4.1.5. Para preservar a qualidade, mudança e cooperação em códigos, temos o "versionamento" como principal ferramenta
5.4.2. O que é?
5.4.2.1. O versionamento de código é um recursos que permite que você salve, de forma local ou na nuvem, as versões do código que você produz.
5.4.2.2. É como construir um histórico daquilo que foi alterado.
5.4.2.3. Quando falamos de contribuições individuais, como um pipeline pequeno que você está desenvolvendo, é muito simples de você administrar o código de forma trivial
5.4.2.3.1. Agora, imagine uma grande corporação, com milhares de desenvolvedores
5.4.2.3.2. Como você faz para organizar todo esse desenvolvimento de código de forma que os desenvolvedores possam manter seus códigos seguros e contribuírem uns com os outros?
5.4.2.3.3. Utilizando o versionamento
5.4.3. Imagine que
5.4.3.1. Você desenvolveu 2 recursos novos pro aplicativo que você está trabalhando
5.4.3.1.1. Versão 1
5.4.3.2. Chega no outro dia, você desenvolve mais um recurso e envia para o seu gestor
5.4.3.2.1. Versão 2
5.4.3.3. Você recebe a devolutiva de que o último recurso que você desenvolveu não pode ser utilizado por riscos de segurança
5.4.3.3.1. Basta voltar à versão 1, sem ter que apagar manualmente o código desenvolvido
5.4.4. O versionamento traz ferramentas poderosíssimas para a colaboração e a qualidade dos códigos construídos
5.4.5. Quando falamos de versionamento, existe um software que destoa de todos os outros
5.4.5.1. O git
5.4.5.1.1. Desenvolvido por Linus Torvaldi e Junio Hamano
5.4.5.1.2. É o software open-source de controle de código mais utilizado do mundo
5.4.5.1.3. O git facilita de forma brilhante o controle das suas versões de código, além de possibilitar que você salve todo o seu progresso na nuvem
5.4.5.1.4. Além de facilitar a identificação de alterações, necessidade de desfazer qualquer código produzido e cooperar com outros desenvolvedores
5.4.5.1.5. Git x GitHub ou GitLab ou BitBucket ou qualquer coisa
5.4.6. Referência
5.4.6.1. Só o curso do William Justen é suficiente. São poucas horas para entender o propósito do versionamento e a ferramenta mais utilizada
5.4.6.1.1. https://www.udemy.com/course/git-e-github-para-iniciantes/
5.4.6.2. Se não for seguir o curso
5.4.6.2.1. O que é e para que serve o versionamento de código?
5.4.6.2.2. Como surgiu o git
5.4.6.2.3. git versus github
5.4.6.2.4. Trabalhando cooperativamente com Git
5.4.6.2.5. Comandos básicos do git
5.4.6.2.6. Comandos avançados do git
5.4.7. GitHub como portfolio
5.4.7.1. Caso você queira ser mais purista.
5.5. Seja ligeiro
5.5.1. Python e SQL se conversam, mas não são dependentes
5.5.2. Você pode estudar ambas em paralelo, é até melhor para ganhar tempo
5.5.3. Parte da lógica que você usa em uma, existe na outra.
6. Os dois frameworks mais importantes do seu início
6.1. ETL
6.1.1. *Extract, transform and load *
6.1.2. É para isso, aqui, que você é pago como engenheiro
6.1.2.1. Engenheiros de Dados são pagos para construção de pipelines de ETL
6.1.2.1.1. Pipeline é o termo que utilizamos para descrever um conjunto ordenado de códigos/algoritmos que chegam em algum lugar
6.1.2.1.2. Por exemplo, um pipeline pode ser
6.1.3. É o paradigma de extração e carga de dados mais utilizado da atualidade
6.1.4. Cada letra da sigla possui seu peso e suas necessidades de especialização
6.1.4.1. Extract
6.1.4.1.1. Extração de dados
6.1.4.2. Transform
6.1.4.2.1. Transformação de dados
6.1.4.3. Load
6.1.4.3.1. Carga de dados
6.1.5. Assim como existem ferramentas/bibliotecas para cada uma delas
6.1.5.1. Extract
6.1.5.1.1. Python
6.1.5.2. Transform
6.1.5.2.1. Python
6.1.5.3. Load
6.1.5.3.1. Python
6.1.6. O ETL teve uma serventia muito grande, porém ele tem uma falha conceitual
6.1.6.1. O que acontece se os meus dados carregados tiverem um problema?
6.1.6.1.1. Eu preciso reconsultar a minha fonte
6.1.6.2. O que acontece se a minha fonte não estiver mais disponível? E se os meus dados da fonte forem voláteis, como uma camada de staging
6.1.6.2.1. Se você não leu nada sobre a camada de staging no data warehouse, agora é o momento certo.
6.1.6.3. Fodeu. Não tem o que fazer.
6.1.6.3.1. Por isso, foi necessário repensar um pouco o modelo.
6.1.7. O nascimento do ELT
6.1.7.1. Ao invés de termos o processo
6.1.7.1.1. Extração > Transformação > Carga
6.1.7.2. Passamos a ter o processo
6.1.7.2.1. Extração > Carga > Transformação
6.1.7.3. Desse modo, qualquer tipo de problema nos resultados dos dados transformados pode ser facilmente tratado
6.1.7.4. Claro, esse novo modelo acarreta em um detalhe: armazenamento
6.1.7.4.1. Mas, como storage tem ficado cada vez mais barato, pode nem ser um problema tão grande assim
6.1.8. É importante que você conheça algumas ferramentas já estabelecidas no mercado para realização de ETL
6.1.8.1. Talend
6.1.8.2. Apache NiFi
6.1.8.3. Apache Airflow
6.1.8.4. Informatica Powercenter
6.1.8.5. Microsoft (SQL Server) Integration Services
6.1.8.5.1. SSIS
6.1.9. Existem diversas formas de você organizar o seu ETL
6.1.9.1. https://www.youtube.com/watch?v=EmBwKA6vI14
6.2. Apache Spark
6.2.1. É o framework de analytics mais importante da atualidade
6.2.2. O Apache Spark permite o processamento, em memória, de grandes volumes de dados através da computação distribuída
6.2.3. O Spark (falando de 3.0) revoluciona o mercado de dados porque ele consegue integrar diversas necessidades em um único framework
6.2.3.1. Você pode
6.2.3.1.1. Utilizar SQL para consultar um data lake
6.2.3.1.2. Construir transformações complexas de forma muito eficiente
6.2.3.1.3. Desenvolver algoritmos de machine learning de forma distribuída
6.2.4. O Spark deu o pontapé inicial para a integração das especialidades técnicas de dados em uma linguagem comum
6.2.4.1. "Linguagem" modo de dizer, porque todo mundo vai usar Python ou SQL no fim do dia
6.2.5. A principal vantagem do Spark está em quanto ele se responsabiliza das coisas por você
6.2.5.1. Além de ele processar as informações em memória
6.2.5.1.1. O que já representa um ganho gigantesco de performance
6.2.5.2. O Spark possui um sistema de otimização automática de código
6.2.5.2.1. Através de dois componentes-chave
6.2.5.3. Por ser o que chamamos de "lazy evaluated" o Spark segue um caminho muito interessante, onde
6.2.5.3.1. Você escreve o seu código
6.2.5.3.2. O Spark "compila" ele para entender o que está acontecendo
6.2.5.3.3. A partir da leitura do seu código, ele cria um plano lógico
6.2.5.3.4. Esse plano lógico é otimizado atravé do Catalyst
6.2.5.3.5. São criados alguns planos físicos (para serem executados pelos recursos do computdor)
6.2.5.3.6. Esses planos físicos passam por um modelo de CBO para encontrar qual é mais eficiente
6.2.5.3.7. O plano escolhido é convertido em bytes, para ser mais eficiente e é executado pela JVM
6.2.6. Os fatores de otimização e execução em memória, além de uma vasta integração de "workloads de dados" tornam o Spark uma ferramenta estupidamente potente
6.2.7. Tudo o que você precisa está em um único recurso
6.2.7.1. https://www.amazon.com.br/Learning-Spark-2e-Jules-Damji/dp/1492050040/
7. Orquestração
7.1. Agora você sabe que precisa criar pipelines de ETL para levar dados de um lado para o outro
7.2. Como organizar essa bagaça?
7.2.1. Através de orquestradores
7.2.1.1. Orquestradores são programas responsáveis por organizar, gerir e monitorar a execução de pipelines de forma automática
7.2.1.2. É como um funcionário que faz aquilo que deve ser feito, na hora que deve ser feito.
7.3. Principais vantagens
7.3.1. Automatizam boa parte do trabalho
7.3.2. Boa parte das soluções são muito maduras e se integram com muitas coisas
7.3.2.1. Algumas são até soluções completas de ETL, por si só
7.3.3. Você pode condicionar o resultado das suas execuções
7.3.3.1. Se falhar, você faz uma coisa
7.3.3.2. Se demorar, você faz outra
7.3.3.3. Se for sucesso, outra ainda
7.3.4. Escalabilidade
7.3.4.1. As ferramentas de orquestração já têm recursos muito úteis para você escalar sua estrutura de códigos
7.3.4.1.1. Uma coisa é gerenciar 10 pipelines
7.3.4.1.2. Outra coisa é gerenciar 1000
7.4. Principais orquestradores
7.4.1. Apache Airflow
7.4.1.1. É o que você mais deve estudar
7.4.1.2. Astronomer
7.4.2. Azure Data Factory
7.4.3. AWS CloudFormation
7.4.4. IBM IWS
7.5. Assim como os bancos de dados, é interessante você ter um para chamar de "seu"
7.5.1. Eu recomendo o Airflow
8. Plataformas de dados
8.1. Entender o que é o ciclo de vida do dado
8.1.1. "Data lifecycle"
8.1.1.1. Existem muitos modelos que explicam o ciclo de vida do dado
8.1.1.2. Pesquise o máximo possível sobre eles, para te ajudar a ter clareza
8.1.1.3. Um dos que eu mais gosto é
8.1.1.3.1. 1. Planejamento
8.1.1.3.2. 2. Aquisição
8.1.1.3.3. 3. Processamento
8.1.1.3.4. 4. Análise
8.1.1.3.5. 5. Integração
8.1.1.3.6. 6. Compartilhamento
8.1.1.3.7. 7. Expurgo
8.2. Entender o que é uma plataforma de dados
8.3. Camadas da plataforma de dados
8.3.1. Ingestão
8.3.2. Armazenamento
8.3.2.1. Se aprofundar mais nas camadas do medallion e suas outras nomenclaturas
8.3.2.1.1. Bronze
8.3.2.1.2. Prata
8.3.2.1.3. Ouro
8.3.3. Processamento
8.3.3.1. Processamento em lote (batch)
8.3.3.2. Processamento em tempo quase real (streaming ou near realtime)
8.3.4. Catálogo de dados
8.3.4.1. Metadados
8.3.4.1.1. Dados sobre dados
8.3.4.1.2. { "nome": "João" }
8.3.5. Análise de Dados
8.3.5.1. Metabase
8.3.5.2. Power BI
8.3.5.3. Tableau
8.3.5.4. Looker
8.3.6. Monitoramento
8.3.6.1. Monitoramento de pipelines
8.3.6.2. Datadog
8.3.6.2.1. Pesquisar concorrentes
8.3.7. Governança de Dados
8.3.7.1. Estudar sobre o conceito de governança de dados
8.3.7.2. Principais ferramentas
8.3.7.2.1. Azure Purview
8.3.7.2.2. Datahub
8.3.7.2.3. AWS Glue Catalog
8.3.7.2.4. Informatica EDX
8.3.7.2.5. Databricks Unity Catalog
8.4. Plataformas de dados na nuvem
8.4.1. Databricks
8.4.1.1. Essa é a maior de todas
8.4.1.2. Você precisa se aprofundar um pouco mais nela para entender sobre
8.4.1.2.1. Databricks Workloads
8.4.1.2.2. Como funciona a plataforma
8.4.1.2.3. Porque ela tem tanta atenção global
8.4.1.2.4. Quem é o Matei Zaharia
8.4.1.2.5. Devorar os vídeos do "Databricks Summit" no YouTube.
8.4.1.2.6. Databricks Unity Catalog
8.4.1.2.7. O conceito de "open data lake"
8.4.2. Azure
8.4.2.1. Azure Synapse Analytics
8.4.2.2. Azure Data Lake
8.4.2.3. Azure Data Factory
8.4.2.4. Azure Purview
8.4.2.4.1. Catálogo e Governança de dados
8.4.3. AWS
8.4.3.1. AWS Redshift
8.4.3.2. AWS S3
8.4.3.3. AWS Glue
8.4.3.4. AWS Athena
8.4.3.5. AWS Glue Data Catalog
8.4.4. GCP
8.4.4.1. BigQuery
8.4.4.1.1. Merece uma atenção especial, porque é uma das mais maduras soluções de data warehouse do mercado
8.4.4.2. Cloud Storage
8.4.4.3. Dataflow
8.4.4.4. Dataproc
8.4.5. Snowflake
8.5. Entender como as empresas estão desenvolvendo isso dentro de casa
8.5.1. "Open Source Data Platform"
8.5.2. Modern data stack
8.5.2.1. dbt
9. Introdução a containers
9.1. 1 dia
9.2. A ideia é ter uma visão abrangente do conceito de containers, não virar um software engineer
9.3. O que são containers
9.3.1. Principalmente sobre isolamento de aplicações
9.3.2. Conteinerização
9.4. Diferenças entre containers e máquinas virtuais
9.5. Principais vantagens de criar aplicações em containers
9.6. Docker
9.6.1. O que é o docker
9.6.2. Componentes principais
9.6.2.1. Dockerfile
9.6.2.2. Docker Engine
9.6.2.3. Docker CLI
9.6.2.4. Docker Image
9.6.2.4.1. Imagens de containers
9.7. Orquestração de containers
9.7.1. Kubernetes
9.7.1.1. "K8s"
9.7.1.2. Pods
9.7.1.3. Deployment de um cluster K8s
9.7.2. Apache Mesos
9.8. Segurança de containers
10. Infrastructure as Code
10.1. Terraform
10.1.1. https://www.terraform.io/use-cases/infrastructure-as-code