Sejam muito bem-vindos ao curso de Engenharia de Dados: Arquiteturas de Dados Modernas. Neste curso, vamos percorrer toda a trajetória de construção de uma arquitetura analítica moderna, começando nos sistemas operacionais, passando pelo Data Warehouse, Data Lake, Lake House e chegando até o consumo analítico por meio de ferramentas de Business Intelligence. Nosso objetivo aqui é entender não apenas as tecnologias, mas principalmente os conceitos de arquitetura que uma pessoa engenheira de dados precisa dominar.
Ao final do curso, teremos uma visão clara de como as diferentes peças da arquitetura de dados se conectam e qual é o papel de cada uma delas dentro do ecossistema analítico moderno. O curso está organizado da seguinte maneira: primeiro, vamos começar a entender as diferenças entre sistemas transacionais e analíticos, estudaremos o que é OLTP (Online Transaction Processing) e OLAP (Online Analytical Processing) e como esses dois mundos possuem características completamente diferentes.
Após isso, vamos construir o sistema transacional do nosso caso prático, que será um pequeno e-commerce chamado Minishop. Este sistema do Minishop será nossa fonte de dados durante todo o curso. Em seguida, vamos entrar no universo do Data Warehouse, estudaremos os conceitos de modelagem multidimensional, entenderemos como transformar dados operacionais em estruturas analíticas e aprenderemos a construir tabelas de fatos e dimensões.
Durante esta etapa, vamos criar o Data Warehouse do Minishop, que transformará os dados do sistema transacional em um modelo preparado para análise. Depois de entender este modelo, trabalharemos no processo de ETL (Extract, Transform, Load), onde veremos como extrair dados do sistema transacional, transformá-los e carregá-los no Data Warehouse.
Estudaremos conceitos fundamentais deste processo, como lookups (buscas), surrogate keys (chaves substitutas), slowly changing dimensions (dimensões que mudam lentamente), dimensão temporal e políticas de carga. E, novamente, tudo será implementado na prática, criando o processo de ETL do Minishop.
Na segunda metade do curso, avançaremos para as arquiteturas modernas de dados. Primeiro, vamos entender o conceito de Data Lake e suas camadas e fluxos de dados que alimentam esse ambiente. Depois, discutiremos o conceito de Lake House, que busca unir as vantagens do Data Lake com as capacidades analíticas do Data Warehouse. Entenderemos quando cada arquitetura deve ser utilizada e como podem coexistir dentro da mesma plataforma.
Por último, vamos estudar como os dados são consumidos pelas áreas de negócio. Falaremos da camada semântica que organiza e padroniza os indicadores da empresa, permitindo que ferramentas de Business Intelligence, como, por exemplo, Power BI ou outras plataformas analíticas, possam consumir os dados de forma consistente. Também discutiremos a governança de dados, que é um tema fundamental para garantir a qualidade, a padronização e a confiança na informação.
Ao concluir este curso, teremos desenvolvido uma visão completa sobre as arquiteturas modernas de dados e como são construídas. E, mais importante ainda, teremos entendido o papel de cada componente dentro dessa arquitetura. Esse tipo de conhecimento é fundamental para qualquer profissional que deseje atuar como engenheiro de dados, arquiteto de dados ou especialista em analítica. No mundo real, construir visões ou escrever consultas SQL é apenas parte do trabalho. A verdadeira diferença está em entender a arquitetura como um todo.
Agora que já sabemos o que vamos construir juntos ao longo deste curso, comecemos pela base de tudo: a diferença entre OLTP e OLAP. Muito obrigado e nos veremos na primeira aula.
Olá a todos, sejam muito bem-vindos ao curso Arquiteturas de Dados Modernas. Antes de falarmos sobre Data Warehouse, Data Lake ou qualquer outra arquitetura mais sofisticada, precisamos começar pela base, e essa base é entender o que é um sistema OLTP. Uma arquitetura moderna nasce de uma necessidade, e essa necessidade surge quando o sistema transacional começa a atingir seus limites. Por isso, se não entendermos profundamente o que é OLTP, não compreenderemos por que existem as outras arquiteturas. Hoje queremos que entendam não apenas a definição, mas o papel estrutural do OLTP dentro de um negócio. E faremos isso sempre conectando com nosso caso de estudo que usaremos neste curso, que é o e-commerce da empresa Minishop.
Quando falamos de OLTP, nos referimos a Online Transaction Processing, ou processamento de transações em linha. Mas, mais importante do que memorizar essa sigla, é entender o que ela representa. OLTP são sistemas projetados para registrar as operações do dia a dia da empresa. É o OLTP que registra um pedido, que atualiza um inventário, que processa um pagamento, que cadastra um cliente, que altera, por exemplo, um endereço. Note que falamos de ações operacionais, ações que fazem o negócio funcionar. O OLTP não está preocupado em analisar tendências ou gerar relatórios estratégicos. Está preocupado em garantir que a operação ocorra corretamente. Se o sistema transacional parar, por exemplo, a empresa deixará de vender. É assim de simples. O OLTP é o coração do negócio.
Vamos trazer isso para o mundo real. Imaginemos isso em nossa aplicação de e-commerce da Minishop. Está funcionando perfeitamente. Então, um cliente acessa o site online, através do navegador ou do celular, navega pelos produtos, escolhe um artigo, adiciona ao carrinho, finaliza a compra e realiza o pagamento. Para o usuário, esses cliques parecerão algo muito simples e rápido. Mas, por trás dessa experiência, existe uma sequência coordenada de operações que ocorrem no banco de dados. Porque cada ação do usuário, cada clique, vai gerar no banco de dados inserções, atualizações, leituras e validações. Quando o pedido é criado, o sistema guarda informações do cliente, a data da compra e gera, claro, um identificador único. Quando os itens são adicionados ao carrinho, novos registros são criados. Quando o pagamento é confirmado, seu estado é atualizado. E tudo isso deve ocorrer de forma rápida, segura e, claro, consistente. Porque, veja, se o pagamento falhar, o pedido não poderá ser confirmado. Se o inventário não for atualizado corretamente, podemos vender a um cliente algo que não existe. É exatamente para garantir que essas situações não ocorram que o OLTP foi projetado.
Existem algumas características fundamentais que definem um sistema OLTP. E não queremos que simplesmente leiam essas características como uma lista. Queremos que entendam por que realmente essas características são fundamentais e necessárias. Bem, são estas: primeiro, alta concorrência. Depois, baixa latência. Em seguida, dados normalizados. E, por último, transações ACID. Cada uma dessas quatro características que acabamos de mencionar vai resolver um problema real da operação. Vamos explorá-las com calma.
Comecemos pela alta concorrência. Imaginemos uma promoção com milhares de pessoas acessando o site ao mesmo tempo. Todas tentando comprar, todas competindo pelo mesmo produto, todas executando transações simultâneas. O banco de dados, então, precisa lidar com esses volumes de acessos concorrentes, sem corromper os dados, sem gerar o que chamaríamos de inconsistências. E para que isso ocorra, precisamos de mecanismos de controle de transações, controle de bloqueios e isolamento entre, por exemplo, operações simultâneas. Ou seja, não basta que o sistema suporte múltiplos usuários. Trata-se de garantir que, mesmo com muitos usuários ao mesmo tempo, o sistema permaneça íntegro e consistente.
A segunda característica é a baixa latência. Coloquemo-nos no lugar do usuário. Estamos lá, finalizamos uma compra e esperamos uma resposta imediata. Clicamos e queremos que essa resposta seja confirmada. Se o sistema começar a demorar vários segundos para confirmar o pedido, nossa experiência de usuário será ruim. Em alguns casos, o cliente pode até desistir da compra. Por isso, os sistemas OLTP estão otimizados para operações rápidas e específicas. São consultas diretas que farão no banco de dados, normalmente baseadas no que chamamos de chave primária da tabela. Ou seja, vamos inserir um pedido apenas, atualizar um estado, buscar um cliente por seu identificador. Não estamos falando de análises complexas, mas de operações pontuais que devem ocorrer em milissegundos.
Falemos agora de dados normalizados, que é a terceira característica. Em um sistema transacional, todo o foco é a integridade. Ou seja, para evitar redundância e inconsistência de dados, estes são organizados em tabelas normalmente separadas. Cada tabela do banco de dados terá uma responsabilidade bem definida. Temos uma tabela de clientes, outra de produtos, outra de pedidos, outra de itens de pedidos e assim por diante. Essa separação de tabelas evitará a duplicação de informação e garantirá que as mudanças ocorram em um único ponto.
Se o e-mail do cliente mudar, ele será modificado apenas em uma tabela. Essa estrutura pode tornar algumas consultas mais complexas, mas o objetivo aqui não é simplificar a análise. O objetivo do OLTP é garantir a integridade operacional. Por fim, chegamos às transações ACID, que são a base de confiabilidade do OLTP. ACID é uma sigla composta por quatro letras. A primeira, A, vem de atomicidade. Atomicidade significa que uma transação ocorre por completo ou não ocorre. Ou seja, ela é completada ou não realizada.
Consistência é a segunda letra da sigla ACID. Significa que garantiremos que a base nunca fique em um estado inválido. A letra I, de isolamento, assegura que as transações simultâneas não interfiram entre si. E a letra D, de durabilidade, garante que, após a confirmação dos dados, eles permanecerão armazenados na base, mesmo em caso de falhas. Sem essas quatro propriedades, não podemos confiar no sistema. E um sistema transacional sem confiança não pode existir.
Observemos também o tipo de consulta que faremos em uma base de dados OLTP. São consultas muito direcionadas e específicas. Vamos buscar um pedido por seu identificador, atualizar apenas o estado de um pagamento ou inserir um novo cliente. Note que não estamos fazendo grandes agregações nem percorrendo milhões de registros. Se alguém nos perguntar qual foi o faturamento do último ano, essa já é uma pergunta analítica, que não pertence ao mundo do OLTP. Portanto, essa diferença entre o que pertence ao mundo transacional, ou seja, OLTP, ou não, é muito importante. Essa diferenciação será repetida ao longo do curso e nos acompanhará nas próximas aulas.
Vamos aplicar tudo isso diretamente em nosso e-commerce Minishop. Em nossa base de dados, temos uma tabela de clientes e uma tabela de produtos. No entanto, no momento, as tabelas de inventário, itens de pedido, pedidos e pagamentos estão vazias. Essas seis tabelas suportam toda a operação do e-commerce. Agora, por enquanto, não veremos como é a estrutura dessas tabelas. Vamos entender como é o fluxo da transação dentro do sistema.
Quando o cliente, por exemplo, confirma um pedido, o primeiro passo é registrar na tabela de pedidos o cabeçalho do pedido. Ou seja, vamos atribuir um número para o pedido, uma data e um código que relacione o cliente que está fazendo esse pedido. Isso seria o cabeçalho da operação do pedido. Em seguida, vamos inserir na tabela de itens de pedido, artigo por artigo. Cada produto comprado gerará uma linha na tabela que estará de alguma forma associada ao pedido. Aqui já começamos a consolidar valores e quantidades. Ou seja, após inserir esses três itens, vamos gravar na tabela de pedidos o valor total de todos os itens.
Depois, o inventário será atualizado. Ou seja, se estamos vendendo esses itens, precisamos ir ao inventário e debitar a quantidade de estoque dos três produtos que fazem parte do pedido. Essa operação gera outra operação na parte de inventário. E, claro, após registrar o pedido, precisamos gerar uma fatura, um comprovante para que o cliente realize o pagamento. Note que o ato de comprar na aplicação Minishop consiste em todas essas operações: criar o cabeçalho do pedido, registrar os itens do pedido, baixar o inventário e gerar a fatura. O pedido estará completo apenas quando tudo isso for concluído corretamente. Tudo isso é o que chamamos de atomicidade.
Observemos agora a estrutura mais simplificada das tabelas dessa base. Note que cada tabela termina tendo uma responsabilidade clara e que as relações entre elas devem estar bem definidas. Essa organização da base, dessa maneira, ou seja, cada tabela com sua responsabilidade e as relações entre elas bem definidas, é o que garante o que chamamos de integridade referencial da base. Este é o padrão clássico de uma base de dados OLTP, responsável pela arquitetura transacional da empresa.
Um erro muito comum quando as empresas começam a crescer é tentar usar a própria base transacional para fazer, por exemplo, análises mais pesadas, consultas que vão agregar milhões de registros. Fazer isso faz com que tenhamos que competir por recursos de hardware com a operação do dia a dia. E qual é o resultado? Lentidão, bloqueios, degradação do desempenho. Isso impactará diretamente na experiência do cliente no site. Por isso, misturar carga operacional com carga analítica é um erro de arquitetura. E, claro, veremos mais adiante como resolver esse problema.
O objetivo deste vídeo foi fazer compreender o papel do OLTP dentro de uma arquitetura de dados. Ou seja, o OLTP é o sistema que registra o presente, que mantém a operação viva e que exige consistência, velocidade e confiabilidade. Vamos encerrar o vídeo aqui e, no próximo, olharemos para o outro lado dessa estrutura, que é o ambiente analítico. E começaremos a perceber por que separar esses dois mundos é uma decisão fundamental quando analisamos arquiteturas modernas de bases de dados. Agradecemos a todos, um grande abraço e até o próximo vídeo.
No vídeo anterior, nós nos aprofundamos no universo do OLTP, entendendo que é o sistema responsável por sustentar a operação do negócio, registrar pedidos, atualizar inventário e confirmar pagamentos. O OLTP se ocupa do presente, mantendo a empresa em funcionamento. No entanto, surge uma pergunta inevitável: se o OLTP registra tudo o que ocorre, como a empresa transforma esses registros em conhecimento? Como o gestor entende se o negócio está crescendo? Como a área financeira da empresa sabe qual é a faturação do mês? Como o marketing descobre qual categoria de produtos está rendendo melhor?
Perguntas como: "Quanto vendemos no mês passado?", "Qual categoria cresceu mais?", "Qual é o ticket médio por região?" e "Qual produto é mais rentável?" não são perguntas operativas; elas não buscam saber sobre um pedido específico, mas sim entender padrões e tendências, compreender comportamentos. É exatamente aqui que entra o OLAP. Quando falamos de OLAP, nos referimos ao Online Analytical Processing (Processamento Analítico em Linha). Assim como vimos o conceito de OLTP, não queremos que apenas memorizem o significado da sigla OLAP. Queremos que entendam o papel do OLAP dentro de nossa arquitetura. Enquanto o OLTP registra o presente, o OLAP analisa o passado. O OLAP não foi criado para que inseríssemos novos pedidos ou atualizássemos o inventário; ele foi criado para permitir o análise, gerar uma visão estratégica da empresa e transformar dados brutos em informações úteis para a tomada de decisões.
É no ambiente OLAP que faremos as agregações, consolidações, análises históricas e comparações entre períodos. No OLAP surgem os dashboards, os relatórios gerenciais e os indicadores de desempenho. Se o OLTP mantém o negócio vivo, o OLAP ajuda o negócio a evoluir. A diferença fundamental entre OLTP e OLAP aparece no tipo de pergunta que cada um responde. No OLTP, fazemos perguntas como: "Qual é o pedido 1050?" ou "Este pagamento foi aprovado?". Notem que são perguntas muito específicas e direcionadas a poucos registros dentro do banco de dados. Em contrapartida, no OLAP, a pergunta muda completamente de natureza. Em vez de buscar um registro, queremos saber, por exemplo, qual foi a faturação total de março ou como as receitas deste trimestre se comparam com o mesmo período do ano passado. Aqui, não nos interessa um detalhe isolado, mas sim um comportamento agregado. Essa mudança de perspectiva altera completamente como projetamos o banco de dados. O que funciona bem para buscar um registro específico não será necessariamente eficiente para somar milhões de linhas e, por exemplo, agrupar essas linhas por mês, categoria ou região.
Vamos olhar para o nosso mundo do e-commerce do mini-shop. Imagine, por exemplo, o diretor financeiro se preparando para uma reunião com investidores. Ele precisa apresentar uma cifra de receitas mensais, mostrar a evolução da empresa ao longo do ano, compará-la com o ano anterior, explicar o lucro por categoria e analisar o desempenho da empresa por cada região geográfica. Para responder a essas perguntas, o sistema precisa percorrer milhares ou até milhões de pedidos, somar valores em cada um, agrupar por diferentes dimensões e comparar todos esses períodos. É fácil entender que fazer isso exige processamento intensivo e requer uma leitura massiva de dados. Se tentarmos fazer isso diretamente no banco transacional, corremos o risco de comprometer a operação, pois enquanto o sistema agrega milhões de registros para gerar um relatório, ao mesmo tempo o cliente está tentando finalizar uma compra. É nesse momento que percebemos a necessidade de separar esses dois ambientes.
O sistema OLAP terá características próprias que o diferenciarão da estrutura do OLTP. Primeiro, o OLAP trabalha com grandes volumes de dados e executa consultas complexas, organizando a informação de forma diferente. O OLAP é projetado para a leitura; está orientado à leitura, e essas características não são escolhas arbitrárias. Elas são respostas diretas ao tipo de problema que o OLAP precisa resolver. Vamos tentar entender isso com mais profundidade. Primeiro, o OLAP trabalhará com grandes volumes de dados; ele não trabalha apenas com o presente, mas com históricos: meses, anos, às vezes décadas de informação. Não estamos interessados apenas no que aconteceu hoje; no OLAP, estamos interessados em ver como o comportamento evoluiu ao longo do tempo. Essa perspectiva histórica do banco de dados é fundamental para que, por exemplo, realizemos uma análise estratégica da empresa. Sem histórico, não podemos obter tendências, e sem tendências, não podemos fazer, por exemplo, a planejamento da empresa. Outra característica são as consultas complexas. No ambiente analítico, no OLAP, utilizaremos funções de agregação, como soma, média e contagem.
Agruparemos os dados por mês, por categoria, por região; cruzaremos informações de diferentes tabelas; aplicaremos, por exemplo, filtros temporais sobre nossas consultas. Uma consulta típica de OLAP é calcular a faturação mensal nos últimos três anos, separada por categoria e região. Isso implicará varrer grandes volumes de dados e realizar múltiplos agrupamentos nessa consulta. Este é um tipo de processamento completamente diferente do que estamos executando no OLTP.
Outra diferença importante está na organização dos dados. No OLTP, priorizamos a normalização para garantir a integridade; no OLAP, muitas vezes priorizamos o desempenho de leitura. Por isso, usamos estruturas que chamamos de modelo estrela, tabelas de fatos, tabelas de dimensão para projetar um OLAP. Não se preocupe; esses termos serão bem compreendidos nos próximos vídeos. Em vez de depender de dezenas de joins complexos para fazer as consultas, algo que seria necessário para obter os mesmos relatórios em um OLTP, organizamos os dados no OLAP de forma a facilitar as agregações rápidas. Essa mudança de modelagem é o primeiro passo para que, mais adiante, entendamos o que é um Data Warehouse.
Além disso, o OLAP está predominantemente orientado à leitura, ao contrário do OLTP, onde milhares de escritas ocorrem simultaneamente. No OLAP, as escritas ocorrem em lotes programados. Realizamos uma carga diária no OLAP, uma carga mensal, uma carga semestral e pronto. A maior parte do tempo, o OLAP está disponível para consultas. Após os dados serem carregados, o ambiente passa a ser consultado intensamente. Assim, geraremos muitos relatórios, muitos dashboards, faremos muitas análises a partir do OLAP. É um padrão de trabalho completamente diferente quando comparamos com o OLTP, o sistema transacional.
Vamos aplicar tudo isso ao e-commerce do Minishop. No ambiente transacional, no OLTP, temos a tabela de pedidos com cada compra individual. No ambiente analítico, não queremos apenas ver pedidos isolados, mas sim as vendas consolidadas. Criamos uma estrutura com uma tabela que chamamos de tabela de fatos, onde registramos métricas, como quantidade vendida e valor total. Conectamos essa tabela de fatos às tabelas que chamamos de tabelas de dimensão, como a tabela de cliente, a tabela de produto e a tabela de tempo. Com esse design, podemos analisar vendas por cidade, por categoria, por período. Essa estrutura de dados pode responder perguntas como: qual foi a faturação por categoria no último trimestre? Ou quantas unidades foram vendidas por estado no último ano? Estamos falando de uma visão consolidada, não de registros individuais. Por isso, o OLAP, projetado para obter visões consolidadas, mostra o verdadeiro poder desse design de dados.
Por que não usar OLTP para tudo? Muitas empresas acabam fazendo isso. À medida que o volume cresce, problemas começam a surgir. Enquanto o sistema é pequeno, é possível gerar relatórios ao mesmo tempo que a administração do dia a dia da empresa. Mas, à medida que os sistemas crescem, os relatórios começam a demorar mais minutos para serem executados, as consultas bloqueiam as tabelas e, por exemplo, o checkout de pagamento do cliente no site se torna lento, surgindo conflitos que chamamos de bloqueios de tabelas. O problema desses erros não está na tecnologia, mas na mistura de objetivos, na mistura de cargas que têm naturezas diferentes. Operação e análise competirão pelos mesmos recursos. Quando isso acontece, a experiência do cliente pode ser afetada. Separar os ambientes não é um luxo; é uma decisão estratégica.
Gostamos de deixar uma imagem mental simples para que se lembrem: o OLTP é o sistema que faz o negócio funcionar, e o OLAP é o sistema que faz o negócio evoluir. O OLTP registra a venda, o OLAP explica a venda; o OLTP trabalha no detalhe, o OLAP trabalha no agregado. Essa separação conceitual é a base de toda a arquitetura moderna que vamos estudar neste curso.
No e-commerce do Minishop, teremos claramente esses dois mundos. Primeiro, teremos uma base transacional que gerenciará o site do Minishop, responsável por realizar pedidos, pagamentos, garantir a estabilidade e consistência do funcionamento da empresa. Em seguida, esse ambiente analítico evoluirá para um data warehouse, que pode se integrar a um data lake, ou até mesmo adotar a forma de um lake house. Antes de entendermos a arquitetura desses quatro ambientes, precisamos compreender essa divisão clara entre operação e análise.
No próximo vídeo, consolidaremos aspectos já mencionados, mas os consolidaremos lado a lado. Falaremos sobre as características do OLTP e do OLAP, as consolidaremos e tentaremos mostrar essas características de uma forma mais estruturada. A partir daí, começaremos a evoluir nesses quatro ambientes ao longo do curso. Obrigado a todos, um abraço e até o próximo vídeo.
O curso Engenharia de Dados: Arquiteturas de Dados Modernas - DW, Data Lake e Lakehouse possui 433 minutos de vídeos, em um total de 78 atividades. Gostou? Conheça nossos outros cursos de Engenharia de Dados em Data Science, ou leia nossos artigos de Data Science.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
O Plano Plus evoluiu: agora com Luri para impulsionar sua carreira com os melhores cursos e acesso à maior comunidade tech.
2 anos de Alura
Matricule-se no plano PLUS 24 e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Programação, Data Science, Front-end, DevOps, Mobile, Inovação & Gestão, UX & Design, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
Acesso à inteligência artificial da Alura.
No Discord, você participa de eventos exclusivos, pode tirar dúvidas em estudos colaborativos e ainda conta com mentorias em grupo com especialistas de diversas áreas.
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
Luri Vision chegou no Plano Pro: a IA da Alura que enxerga suas dúvidas, acelera seu aprendizado e conta também com o Alura Língua que prepara você para competir no mercado internacional.
2 anos de Alura
Todos os benefícios do PLUS 24 e mais vantagens exclusivas:
Chat, busca, exercícios abertos, revisão de aula, geração de legenda para certificado.
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
Para quem quer atingir seus objetivos mais rápido: Luri Vision ilimitado, vagas de emprego exclusivas e mentorias para acelerar cada etapa da jornada.
2 anos de Alura
Todos os benefícios do PRO 24 e mais vantagens exclusivas:
Catálogo de tecnologia para quem é da área de Marketing
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais de forma ilimitada.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
Conecte-se ao mercado com mentoria individual personalizada, vagas exclusivas e networking estratégico que impulsionam sua carreira tech para o próximo nível.
