O que é big data?

Os primórdios de enormes volumes de conjuntos de dados remontam à década de 1970, quando o mundo dos dados estava apenas começando com data centers e o desenvolvimento de bancos de dados relacionais, apesar do fato de que o conceito de big data ainda era relativamente novo. Essas revoluções tecnológicas levaram a computadores de mesa pessoais, seguidos por laptops e, em seguida, computadores móveis nas décadas seguintes. À medida que as pessoas tinham acesso aos dispositivos, os dados gerados começaram a crescer exponencialmente.

Por volta do ano de 2005, as pessoas começaram a perceber que os usuários geram enormes quantidades de dados. Plataformas sociais, como Facebook, Twitter e YouTube, geram dados mais rápido do que nunca, à medida que os usuários têm acesso a produtos inteligentes ou serviços relacionados à internet.

Simplificando, big data refere-se a grandes e complexos conjuntos de dados, particularmente aqueles derivados de novas fontes de dados. Esses conjuntos de dados são grandes o suficiente para que o software de processamento de dados tradicional não possa lidar com seu armazenamento e processamento de forma eficiente. Mas esses enormes volumes de dados são de grande utilidade quando precisamos obter insights analisando-os e, em seguida, resolver problemas de negócios com eles, o que não éramos capazes de fazer antes. Por exemplo, uma organização pode analisar as interações de seus usuários ou clientes com suas páginas sociais ou site para identificar seu sentimento em relação a seus negócios e produtos.

Muitas vezes, o big data é descrito pelos cinco Vs. Começou com três Vs, que incluem volume, velocidade e variedade de dados, mas à medida que evoluiu, a precisão e o valor dos dados também se tornaram aspectos importantes do big data, que é quando a veracidade e o valor foram adicionados para representá-los como cinco Vs. Esses cinco Vs são explicados da seguinte forma:

• Volume: representa a quantidade de dados que você tem para análise e realmente varia de organização para organização. Ele pode variar de terabytes a petabytes em escala.
• Velocidade: Representa a velocidade com que os dados estão sendo coletados ou processados para análise. Isso pode ser um feed de dados diário que você recebe do seu fornecedor ou um caso de uso de streaming em tempo real, onde você recebe dados a cada segundo a cada minuto.
• Variedade: Quando falamos em variedade, significa quais são as diferentes formas ou tipos de dados que você recebe para processamento ou análise. Em geral, eles são amplamente categorizados nos três seguintes:
• Estruturado: formato de dados organizado com um esquema fixo. Pode ser de bancos de dados relacionais ou CSVs ou arquivos delimitados.
• Semiestruturado: dados parcialmente organizados que não têm um esquema fixo, por exemplo, arquivos XML ou JSON.
• Não estruturado: esses conjuntos de dados são mais representados por meio de arquivos de mídia, onde eles não têm um esquema a seguir, por exemplo, arquivos de áudio ou vídeo.
• Veracidade: Isso representa o quão confiáveis ou verdadeiros são seus dados. Quando você planeja analisar big data e obter insights a partir dele, a precisão ou qualidade dos dados é importante.
• Valor: Isso geralmente é chamado de valor dos dados que você coletou, pois destina-se a fornecer insights que podem ajudar a empresa a impulsionar o crescimento.

Com a evolução do big data, o principal desafio passou a ser como processar volumes tão grandes de dados, porque as estruturas típicas de processamento de um único sistema não eram suficientes para lidar com eles. Ele precisava de uma estrutura de computação de processamento distribuído que pudesse fazer processamento paralelo.

Depois de entender o que o big data representa, vamos ver como a estrutura de processamento do Hadoop ajudou a resolver essa declaração de problema de processamento de big data e por que ela se tornou tão popular.

Hadoop – estrutura de processamento para lidar com big data

Embora houvesse diferentes tecnologias ou estruturas que vieram para lidar com big data, a estrutura que ganhou mais força foi o Hadoop, que é uma estrutura de código aberto projetada especificamente para armazenar e analisar grandes conjuntos de dados. Ele permite combinar vários computadores para formar um cluster que pode fazer processamento distribuído paralelo para lidar com dados em escala de gigabyte a petabyte.

A seguir está um modelo de fluxo de dados que explica como os dados de entrada são coletados, armazenados no Hadoop Distributed File System (HDFS), processados com estruturas de processamento de big data Hive, Pig ou Spark e a saída transformada fica disponível para consumo ou é transferida para sistemas downstream ou fornecedores externos. Ele representa um fluxo de dados de alto nível, onde os dados de entrada são coletados e armazenados como dados brutos. Em seguida, ele é processado conforme necessário para análise e, em seguida, disponibilizado para consumo:

Figura 1.1 – Fluxo de dados em um cluster Hadoop

A seguir estão os principais componentes básicos do Hadoop:

• HDFS: Um sistema de arquivos distribuído que é executado em hardware básico e fornece melhor taxa de transferência de dados em comparação com sistemas de arquivos tradicionais e maior confiabilidade com um mecanismo de tolerância a falhas integrado.
• Yet Another Resource Negotiator (YARN): Quando vários nós de computação estão envolvidos com a capacidade de processamento paralelo, o YARN ajuda a gerenciar e monitorar recursos de computação de CPU e memória e também ajuda no agendamento de trabalhos e tarefas.
• MapReduce: Este é um framework distribuído que possui dois módulos básicos, ou seja, mapear e reduzir. A tarefa de mapa lê os dados do HDFS ou de uma camada de armazenamento distribuída e os converte em pares chave-valor, que se tornam entrada para as tarefas de redução, o que agrega idealmente a saída do mapa para fornecer o resultado.
• Hadoop Common: incluem bibliotecas Java comuns que podem ser usadas em todos os módulos da estrutura do Hadoop.

Nos últimos anos, a estrutura do Hadoop tornou-se popular por causa de sua capacidade de processamento paralelo massivo (MPP) em cima de hardware de commodities e sua natureza tolerante a falhas, o que a tornou mais confiável. Ele foi estendido com ferramentas e aplicativos adicionais para formar um ecossistema que pode ajudar a coletar, armazenar, processar, analisar e gerenciar big data. Algumas das aplicações mais populares são as seguintes:

• Spark: Um sistema de processamento distribuído de código aberto que usa cache na memória e execução otimizada para desempenho rápido. Semelhante ao MapReduce, ele fornece capacidade de processamento em lote, bem como recursos de streaming em tempo real, aprendizado de máquina e processamento gráfico.
• Hive: Permite que os usuários usem mecanismos de processamento distribuídos, como MapReduce, Tez ou Spark, para consultar dados do sistema de arquivos distribuído por meio da interface SQL.
• Presto: Semelhante ao Hive, o Presto também é um mecanismo de consulta SQL distribuído de código aberto que é otimizado para acesso a dados de baixa latência a partir do sistema de arquivos distribuído. Ele é usado para consultas complexas, agregações, junções e funções de janela. O mecanismo Presto está disponível como dois componentes separados no EMR, ou seja, PrestoDB e PrestoSQL ou Trino.
• HBase: um banco de dados não-relacional ou NoSQL de código aberto executado sobre o sistema de arquivos distribuído que fornece pesquisa rápida de tabelas com bilhões de linhas e milhões de colunas agrupadas como famílias de colunas.
• Oozie: Permite a orquestração do fluxo de trabalho com os componentes do agendador e coordenador do Oozie.
• ZooKeeper: ajuda no gerenciamento e coordenação de recursos de componentes do Hadoop com comunicação, agrupamento e manutenção baseados em intercomponentes.
• Zeppelin: Um notebook interativo que permite a exploração interativa de dados usando frameworks do tipo Python e PySpark.

O Hadoop fornece uma ótima solução para as necessidades de processamento de big data e se tornou popular entre engenheiros de dados, analistas de dados e cientistas de dados para diferentes cargas de trabalho analíticas. Com seu uso crescente, os clusters do Hadoop trouxeram alta sobrecarga de manutenção, o que inclui manter o cluster atualizado com as versões de software mais recentes e adicionar ou remover nós para atender às necessidades variáveis de carga de trabalho.

Agora, vamos entender os desafios que os clusters Hadoop locais enfrentam e como o Amazon EMR vem como uma solução para eles.

Desafios com clusters Hadoop locais

Antes do Amazon EMR, os clientes costumavam ter clusters Hadoop locais e enfrentavam os seguintes problemas:

• Arquitetura de computação e armazenamento fortemente acoplada: os clusters usados para usar o HDFS como sua camada de armazenamento, onde o armazenamento em disco do nó de dados contribui para o HDFS. No caso de falhas ou substituições de nós, costumava haver movimentação de dados para ter outra réplica de dados criada.
• Super utilizado durante os horários de pico e subutilizado em outros horários: como os recursos de dimensionamento automático não estavam lá, os clientes costumavam fazer o planejamento de capacidade com antecedência e adicionar nós ao cluster antes do uso. Dessa forma, os clusters costumavam ter um número constante de nós; Durante os horários de pico, os recursos do cluster foram super utilizados e, fora do horário de expediente, foram subutilizados.
• Recurso centralizado com o desgaste de recursos: À medida que os recursos são super utilizados durante os horários de pico, isso leva à eliminação de recursos e afeta o desempenho ou o colapso dos recursos de hardware.
• Dificuldade em atualizar toda a pilha: configurar e configurar serviços era uma tarefa tediosa, pois você precisava instalar versões específicas de aplicativos Hadoop e, quando planejava atualizar, não havia opções para reverter ou fazer downgrade.
• Dificuldade em gerenciar muitas implantações diferentes (desenvolvimento/teste): Como a instalação e configuração do cluster era uma tarefa tediosa, os desenvolvedores não tinham a opção de criar rapidamente aplicativos em novas versões para provar a viabilidade. Além disso, criar diferentes ambientes de desenvolvimento e teste era um processo demorado.

Para superar os desafios anteriores, a AWS criou o Amazon EMR, que é um cluster Hadoop gerenciado que pode aumentar e diminuir a escala à medida que as necessidades de recursos de carga de trabalho mudam.

Visão geral do Amazon EMR – cluster Hadoop gerenciado e escalável na AWS

Para fornecer uma visão geral, o Amazon EMR é uma ferramenta da AWS para processamento de big data que fornece um cluster Hadoop gerenciado e escalável com várias opções de implantação que inclui EMR no Amazon Elastic Compute Cloud (EC2), EMR no Amazon Elastic Kubernetes Service (EKS) e EMR no AWS Outposts.

O Amazon EMR simplifica a configuração, a execução e o dimensionamento de ambientes de big data automatizando tarefas demoradas, como provisionar instâncias, configurá-las com serviços Hadoop e ajustar os parâmetros de cluster para obter melhor desempenho.

O Amazon EMR é usado em uma variedade de aplicativos, incluindo Extrair, Transformar e Carregar (ETL), análise de fluxo de cliques, streaming em tempo real, análise interativa, aprendizado de máquina, simulação científica e bioinformática. Você pode executar cargas de trabalho de análise em escala de petabytes no EMR por menos da metade do custo das soluções locais tradicionais e mais de três vezes mais rápido do que o Apache Spark de código aberto. Todos os anos, os clientes lançam milhões de clusters EMR para seus casos de uso em lote ou streaming.

Antes de mergulhar nos benefícios do EMR em comparação com um cluster Hadoop local, vamos examinar um breve histórico das versões do Hadoop e do EMR.

Uma breve história dos principais lançamentos de big data

Antes de prosseguirmos, o diagrama a seguir mostra o período de lançamento de alguns dos principais bancos de dados:

Figura 1.2 – Diagrama explicando o histórico dos principais lançamentos de big data

Como você pode ver no diagrama anterior, o Hadoop foi criado em 2006 com base no whitepaper MapReduce do Google e, em seguida, a AWS lançou o Amazon EMR em 2009. Desde então, o EMR adicionou muitos recursos e seu recente lançamento do Amazon EMR no EKS oferece a grande capacidade de executar cargas de trabalho do Spark em clusters Kubernetes.

Ouvimos falar sobre como empresas como o TikTok analisam grandes quantidades de dados para fazer recomendações personalizadas sobre qual clipe de vídeo mostrar a um usuário em seguida. Também lemos inúmeros artigos sobre como a nova geração de chatbots (como o ChatGPT da OpenAI ou o Bard do Google) foram treinados em conjuntos de dados massivos e, como resultado, são capazes de ter conversas semelhantes às humanas em uma ampla gama de tópicos. Experimentamos como empresas como Amazon e Netflix podem recomendar produtos ou vídeos nos quais possamos estar interessados, com base em nosso histórico de compras e visualizações. Todas essas empresas inovaram e agregaram valor ao cliente ao realizar análises complexas em conjuntos de dados muito grandes.

Também vemos a importância dos dados em grandes empresas, como demonstrado por aquelas empresas que criam um novo cargo executivo C-level – o Chief Data Officer (CDO). De acordo com um artigo (https://hbr.org/2021/08/why-do-chief-data-officers-have-such-short-tenures) na Harvard Business Review, o papel do CDO foi estabelecido pela primeira vez pelo Capital One (um banco norte-americano voltado para a tecnologia) em 2002. Em 2012, estimou-se que 12% das empresas tinham um CDO de acordo com uma pesquisa da NewVantage Partners e, em 2021, isso cresceu para 65% das empresas com um CDO.

Não há dúvida de que os dados, quando aproveitados corretamente e otimizados para o máximo valor analítico, podem ser um divisor de águas para uma organização. Ao mesmo tempo, as empresas que não conseguem utilizar efetivamente seus ativos de dados correm o risco de perder uma vantagem competitiva para outras que têm uma estratégia de dados abrangente e programas analíticos e de aprendizado de máquina eficazes.

As organizações hoje tendem a estar em um dos três estados a seguir:

• Eles têm um programa eficaz e modernizado de análise de dados e aprendizado de máquina que os diferencia de seus concorrentes.
• Eles estão conduzindo projetos de prova de conceito para avaliar como a modernização de seus programas analíticos e de aprendizado de máquina pode ajudá-los a alcançar uma vantagem competitiva.
• Seus líderes estão tendo noites sem dormir se preocupando sobre como seus concorrentes estão usando novos programas de análise e aprendizado de máquina para alcançar uma vantagem competitiva sobre eles.

Os desafios dos conjuntos de dados em constante crescimento

As organizações têm muitos ativos, como ativos físicos, propriedade intelectual, o conhecimento de seus funcionários e segredos comerciais. Mas, por muito tempo, as organizações não reconheceram totalmente que tinham outro ativo extremamente valioso e não conseguiram maximizar o uso dele – as grandes quantidades de dados que coletaram ao longo do tempo.

Isso não quer dizer que as organizações ignoraram esses ativos de dados, mas sim, devido à natureza complexa e de armazenamento e gerenciamento desses dados, as organizações tendiam a analisar e manter apenas um subconjunto de seus dados.

Inicialmente, os dados podem ter sido armazenados em um único banco de dados, mas à medida que as organizações e seus requisitos de dados cresceram, o número de bancos de dados aumentou exponencialmente. Hoje, com a moderna abordagem de desenvolvimento de aplicativos de microsserviços, as empresas geralmente têm centenas, ou mesmo milhares, de bancos de dados. Diante de muitos silos de dados, as organizações investiram em sistemas de armazenamento de dados que lhes permitiriam ingerir dados de vários bancos de dados em silos em um local central para análise. Mas, devido ao custo desses sistemas, havia limitações sobre a quantidade de dados que poderiam ser armazenados, e alguns conjuntos de dados seriam excluídos ou apenas dados agregados seriam carregados no data warehouse. Os dados também seriam mantidos apenas por um período limitado de tempo, pois o armazenamento de dados para esses sistemas era caro e, portanto, não era econômico manter dados históricos por longos períodos. Também houve falta de ferramentas amplamente disponíveis e poder computacional para permitir a análise de conjuntos de dados extremamente grandes e abrangentes.

À medida que as organizações continuavam a crescer, vários data warehouses e data marts seriam implementados para diferentes unidades de negócios ou grupos, e as organizações ainda não tinham um repositório centralizado e de fonte única para seus dados. As organizações também se depararam com novos tipos de dados, como dados semiestruturados ou mesmo não estruturados, e analisar esses conjuntos de dados usando ferramentas tradicionais foi um desafio.

Como resultado, foram inventadas novas tecnologias que eram mais capazes de trabalhar com conjuntos de dados muito grandes e diferentes tipos de dados. O Hadoop foi uma tecnologia criada no início dos anos 2000 no Yahoo como parte de um projeto de mecanismo de busca que queria indexar 1 bilhão de páginas da web. Nos anos seguintes, o Hadoop e a tecnologia MapReduce subjacente tornaram-se uma maneira popular para todos os tipos de empresas armazenarem e processarem conjuntos de dados muito grandes. No entanto, executar um cluster Hadoop era uma operação complexa e cara que exigia habilidades especializadas.

A próxima evolução para o processamento de big data foi o desenvolvimento do Spark (mais tarde assumido como um projeto Apache e agora conhecido como Apache Spark), uma nova estrutura de processamento para trabalhar com big data. O Spark mostrou aumentos significativos no desempenho ao trabalhar com grandes conjuntos de dados devido ao fato de que ele fez a maior parte do processamento na memória, reduzindo significativamente a quantidade de leitura e gravação de e para discos. Hoje, o Apache Spark é frequentemente considerado como o padrão ouro para o processamento de grandes conjuntos de dados e é usado por uma ampla gama de empresas.

Em paralelo com o surgimento do Apache Spark como uma ferramenta popular de processamento de big data foi o surgimento do conceito de data lakes – uma abordagem que usa o armazenamento de objetos de baixo custo como uma camada de armazenamento físico para uma variedade de tipos de dados, o Apache Hive como um catálogo central de todos os conjuntos de dados e disponibiliza esses dados para processamento com uma ampla variedade de ferramentas, incluindo o Apache Spark. O próprio site da AWS usa a seguinte definição de data lakes:

Um data lake é um repositório centralizado que permite armazenar todos os seus dados estruturados e não estruturados em qualquer escala. Você pode armazenar seus dados como estão, sem precisar primeiro estruturá-los, e executar diferentes tipos de análise, desde painéis e visualizações até processamento de big data, análise em tempo real e aprendizado de máquina para orientar decisões melhores.

Os data lakes eram ótimos para centralizar dados, mas geralmente eram executados por uma equipe centralizada que procurava ingerir dados de todos os silos de dados em uma organização, transformar e agregar os dados e disponibilizá-los centralmente para uso por outras equipes. Embora isso tenha sido uma melhoria definitiva em ter bancos de dados e data warehouses espalhados sem repositório central ou governança, ainda havia espaço para melhorias.

Ao centralizar todos os dados e ter uma única equipe gerenciando esse repositório de dados, as equipes que trabalhavam para transformar e extrair valor adicional dos dados geralmente não eram as pessoas mais familiarizadas com o contexto de negócios por trás dos dados.

Para resolver isso, Zhamak Dehghani (um consultor de dados que trabalhava para a Thoughtworks na época) desenvolveu uma nova abordagem, que acabou ficando conhecida como malha de dados.

Com uma arquitetura de malha de dados, a ideia é tornar as equipes que geram os dados responsáveis por criar uma versão analítica dos dados e, em seguida, tornar esses dados facilmente acessíveis ao resto da organização sem a necessidade de fazer várias cópias dos dados.

Em 2022, esse conceito ganhou apelo generalizado, e muitas empresas estavam trabalhando para implementar uma abordagem de malha de dados para seus dados. Alguns tiveram uma visão limitada do que era uma malha de dados e a consideraram principalmente um meio de compartilhar dados entre equipes sem a necessidade de mover ou copiar fisicamente os dados. No entanto, uma implementação completa de malha de dados foi muito além da tecnologia de como compartilhar dados. Uma implementação de malha de dados significou uma mudança nos processos de como os dados operacionais eram convertidos em dados analíticos e, junto com eles, as personas que eram responsáveis pelos dados. Uma implementação de malha de dados não foi apenas uma implementação técnica, mas sim uma mudança na cultura e operação das equipes dentro de uma organização.

Enquanto em muitas organizações, a análise em larga escala era feita por uma equipe centralizada, com uma abordagem de malha de dados, a equipe proprietária de um aplicativo que gera dados deve produzir esses dados para disponibilizá-los para o resto da empresa. Assim como o DevOps mudou a forma como as equipes de desenvolvimento trabalhavam para criar e dar suporte a software, a abordagem de malha de dados significava que as equipes de produto precisavam trabalhar de forma diferente na forma como geravam e compartilhavam dados analíticos. Eles nomeariam um gerente de produto de dados que seria responsável pela tarefa de coletar dados operacionais e criar um produto de dados analíticos a partir disso. Para o produto que eles criaram, eles se apropriariam de garantir a qualidade dos dados, a atualização dos dados, a comunicação em torno de alterações no produto (como alterações de esquema) e assim por diante. Eles seriam efetivamente gerentes de produto, delineando um roteiro para o produto de análise de dados que criariam e responderiam ao feedback do cliente sobre o produto de dados.

Com uma malha de dados, ainda haveria uma equipe de dados central, mas essa equipe seria responsável por criar uma plataforma de dados centralizada, que todas as diferentes equipes de produtos de dados poderiam usar. Assim, em vez de serem engenheiros de dados que transformavam dados, a equipe centralizada se concentraria em ser engenheiros de plataforma de dados, criando uma plataforma padronizada que atendesse às melhores práticas. Eles então disponibilizariam essa plataforma para equipes de desenvolvimento individuais usarem para criar e compartilhar seus próprios produtos de análise de dados.

Tendo analisado como a análise de dados se tornou uma ferramenta essencial nas organizações, vejamos agora as funções que permitem maximizar o valor dos dados para uma organização moderna.

O papel do engenheiro de dados como habilitador de big data

Em meio ao crescente reconhecimento dos dados como um ativo corporativo valioso e à introdução de novas tecnologias para armazenar e processar grandes quantidades de dados, houve um aumento nas oportunidades e funções disponíveis para carreiras relacionadas a dados.

Vejamos um exemplo de caso de uso em que um gerente de vendas de uma organização de bens de consumo deseja entender melhor quais produtos alternativos um cliente considera antes de comprar seu produto. Além disso, eles também querem ter uma maneira melhor de prever a demanda de produtos por categoria com base em fatores externos, como o clima esperado.

Alcançar os resultados desejados, conforme especificado pelo gerente de vendas, exigirá trazer dados de várias fontes internas e externas. Os conjuntos de dados que podem ser relevantes para esse cenário podem incluir o seguinte:

• Bancos de dados relacionais de clientes, produtos e pedidos
• Logs do servidor Web da vitrine voltada para o consumidor
• Dados de vendas de terceiros de mercados on-line onde produtos relevantes são vendidos (como Amazon.com)
• Outros conjuntos de dados relevantes de terceiros que podem influenciar as vendas (por exemplo, dados relacionados ao clima)

Várias equipes precisariam estar envolvidas no projeto, com as 3 funções a seguir desempenhando um papel principal na implementação da solução necessária:

• Engenheiro de dados
• Cientista de dados
• Analista de dados

Vamos dar uma olhada em como esses três papéis contribuiriam para esse novo projeto.

Entendendo o papel do engenheiro de dados

A função de um engenheiro de dados é fazer o seguinte:

• Projetar, implementar e manter os pipelines que permitem a ingestão de dados brutos em uma plataforma de armazenamento
• Transforme esses dados para serem otimizados para análise, com base nos requisitos do consumidor de dados
• Disponibilizar esses dados para vários consumidores de dados usando sua ferramenta de escolha

Um engenheiro de dados também deve garantir que eles cumpram todos os requisitos de segurança e governança necessários ao executar as tarefas acima.

Em nosso cenário, o engenheiro de dados precisará primeiro projetar os pipelines que ingerem dados brutos de várias fontes internas e externas. Para conseguir isso, eles usarão uma variedade de ferramentas, dependendo do sistema de origem e se será ingestão de lote programada ou ingestão de streaming quase em tempo real (conforme discutido no Capítulo 6, Ingestão de dados em lote e streaming).

O engenheiro de dados também é responsável por transformar os conjuntos de dados de entrada bruta para otimizá-los para análise, usando várias técnicas (conforme discutido no Capítulo 7, Transformando dados para otimizar para análise). O engenheiro de dados também deve criar processos para verificar a qualidade dos dados, adicionar metadados sobre os dados a um catálogo de dados e gerenciar o ciclo de vida do código relacionado à transformação de dados.

Finalmente, o engenheiro de dados pode precisar ajudar na integração de várias ferramentas de consumo de dados com os dados transformados, permitindo que analistas de dados e cientistas de dados usem suas ferramentas preferidas para extrair insights dos dados.

O engenheiro de dados usa ferramentas como Apache Kafka, Apache Spark e Presto, bem como outros produtos disponíveis comercialmente, para criar o pipeline de dados e otimizar dados para análise.

O engenheiro de dados é muito parecido com um engenheiro civil para um novo empreendimento residencial. O engenheiro civil é responsável por projetar e construir as estradas, pontes, estações de trem e assim por diante para permitir que os passageiros se desloquem facilmente dentro e fora do empreendimento. Da mesma forma, o engenheiro de dados é responsável por projetar e construir a infraestrutura necessária para trazer dados para uma fonte central e otimizar os dados para uso por vários consumidores de dados.

Entendendo o papel do cientista de dados

O papel de um cientista de dados é desenhar insights complexos e fazer previsões com base em vários conjuntos de dados, usando aprendizado de máquina e inteligência artificial. O cientista de dados combinará uma série de habilidades, incluindo ciência da computação, estatística, análise e matemática, a fim de ajudar uma organização a responder a perguntas complexas e tomar decisões informadas usando dados.

Os cientistas de dados precisam entender os dados brutos e saber como usá-los para desenvolver e treinar modelos complexos de aprendizado de máquina que ajudarão a reconhecer padrões nos dados e prever tendências futuras. Em nosso cenário, o cientista de dados pode construir um modelo de aprendizado de máquina que usa dados de vendas anteriores, correlacionados com informações meteorológicas de cada dia no período de relatório.

Eles podem então projetar e treinar esse modelo para ajudar os usuários de negócios a obter previsões sobre as prováveis categorias mais vendidas para datas futuras com base na previsão do tempo esperada (sorvetes vendem melhor em dias quentes e guarda-chuvas vendem melhor em dias chuvosos).

Onde o engenheiro de dados é como um engenheiro civil construindo infraestrutura para um novo desenvolvimento, o cientista de dados está desenvolvendo produtos novos e avançados para os moradores do empreendimento, como tipos avançados de transporte dentro e fora do empreendimento. Os cientistas de dados criam os modelos de aprendizado de máquina que permitem que os consumidores de dados e analistas de negócios extraiam novos insights e previsões a partir dos dados. No entanto, assim como o projetista de um novo avião depende de ter um aeroporto onde o avião possa pousar e decolar, o cientista de dados depende de engenheiros de dados criando pipelines de dados para trazer os dados necessários para treinar novos modelos de aprendizado de máquina.

Entendendo o papel do analista de dados

O papel de um analista de dados é examinar e combinar vários conjuntos de dados para ajudar uma empresa a entender as tendências nos dados e tomar decisões de negócios mais informadas. Enquanto um cientista de dados desenvolve modelos que fazem previsões futuras ou identifica padrões não óbvios nos dados, o analista de dados trabalha com dados bem estruturados e modelados para entender as condições atuais e destacar padrões recentes dos dados.

Um analista de dados pode responder a perguntas como qual item do menu vendeu melhor em diferentes regiões geográficas no último mês ou qual procedimento médico teve o melhor resultado para pacientes de diferentes idades. Esses insights ajudam uma organização a tomar melhores decisões para o futuro.

Em nosso cenário, o analista de dados pode executar consultas complexas nos diferentes conjuntos de dados disponíveis (como um banco de dados de pedidos ou logs do servidor Web), unindo subconjuntos de dados de cada fonte para obter novos insights. Por exemplo, o analista de dados pode criar um relatório destacando quais produtos alternativos são mais frequentemente procurados por um cliente antes de um produto específico ser comprado. O analista de dados também pode fazer uso de modelos avançados de aprendizado de máquina desenvolvidos pelos cientistas de dados para obter mais insights valiosos.

Onde o engenheiro de dados é como um engenheiro civil construindo infraestrutura, e o cientista de dados está desenvolvendo novas e avançadas formas de transporte, o analista de dados é como um piloto habilidoso, usando sua experiência para levar os usuários ao seu destino final.

Noções básicas sobre outras funções comuns relacionadas a dados

As organizações podem ter outros títulos de função e descrições de cargos para cargos relacionados a dados, mas, geralmente, esses serão um subconjunto das funções descritas nas seções anteriores.

Por exemplo, um arquiteto de big data ou arquiteto de plataforma de dados pode ser um subconjunto da função de engenheiro de dados, focado em projetar a arquitetura para pipelines de big data, mas não em criar os pipelines específicos de dados. Ou, um desenvolvedor de visualização de dados pode estar focado em criar visualizações usando ferramentas de business intelligence, mas isso é efetivamente um subconjunto da função de analista de dados.

Organizações maiores tendem a ter funções de trabalho mais focadas, enquanto em uma organização menor, uma única pessoa pode assumir o papel de engenheiro de dados, cientista de dados e analista de dados.

Neste livro, vamos nos concentrar no papel do engenheiro de dados e mergulhar profundamente em como um engenheiro de dados é capaz de construir pipelines de dados complexos usando o poder dos serviços de computação em nuvem. Vejamos agora como a computação em nuvem simplificou a forma como as organizações são capazes de criar e expandir soluções de processamento de big data.

Os benefícios da nuvem na criação de soluções analíticas de big data

Por muito tempo, as organizações dependiam de sistemas complexos que seriam executados em seus próprios data centers para ajudá-las a capturar, armazenar e processar grandes quantidades de dados. Mas, na última década, houve uma tendência de aumento da quantidade de dados que as organizações desejam armazenar e analisar, e os sistemas locais têm lutado para escalar para acompanhar a demanda. Expandir essas ferramentas tradicionais para gerenciar tamanhos de conjuntos de dados cada vez maiores tem sido caro, complexo e demorado, e as organizações têm buscado soluções alternativas para lidar com o aumento do volume de dados.

Desde que a Amazon lançou a AWS em 2006, as organizações têm percebido os benefícios de executar suas cargas de trabalho na nuvem. A computação em nuvem permite escalabilidade, eficiência de custos, segurança e automação que a maioria das empresas considera impossível de alcançar dentro de seus próprios data centers, e isso também se aplica à área de análise de dados. Um dos primeiros serviços da AWS foi o Amazon Simple Storage Service (Amazon S3), um armazenamento de objetos baseado em nuvem que oferece escalabilidade essencialmente ilimitada a baixo custo e, ainda assim, fornece durabilidade e disponibilidade que a maioria dos gerentes de data center só poderia sonhar em alcançar. Hoje, o Amazon S3 se tornou a camada de armazenamento físico para muitos milhares de projetos de data lake, e um amplo ecossistema de ferramentas analíticas foi criado para trabalhar com o serviço.

Os engenheiros de dados bem-sucedidos precisam entender as ferramentas disponíveis na nuvem para criar projetos complexos de análise de dados e entender qual conjunto de ferramentas é melhor para alcançar o resultado necessário para seu projeto.

As inovações no gerenciamento e processamento de dados nas últimas décadas lançaram as bases para os sistemas analíticos modernos. Quando você olha para o cenário de análise de uma organização madura típica, você encontrará as pegadas de muitas dessas inovações em suas plataformas de análise de dados. Como engenheiro de dados, você pode se deparar com pipelines analíticos que foram criados usando tecnologias de diferentes gerações, e é de se esperar que você os entenda. Portanto, é importante estar familiarizado com alguns dos principais desenvolvimentos em análise ao longo do tempo, bem como entender os conceitos fundamentais de armazenamento de dados analíticos, gerenciamento de dados e pipelines de dados.

Bancos de dados e data warehouses

Existem dois tipos amplos de sistemas de banco de dados, e ambos existem há muitos anos:

• Os sistemas OLTP (Online Transaction Processing) são usados principalmente para armazenar e atualizar dados transacionais em grandes volumes. Por exemplo, bancos de dados do tipo OLTP são frequentemente usados para armazenar registros de clientes, incluindo detalhes de transações (como compras, devoluções e reembolsos).
• Os sistemas OLAP (Online Analytical Processing) são usados principalmente para gerar relatórios sobre grandes volumes de dados. É comum que os sistemas OLAP obtenham dados de vários bancos de dados OLTP e forneçam um repositório centralizado de dados que podem ser usados para fins de relatório.
• 
  

Tanto o processamento de dados OLTP quanto o OLAP e os sistemas analíticos evoluíram ao longo de várias décadas. Na década de 1980, o foco era o processamento em lote, onde os dados seriam processados em execuções noturnas em grandes computadores mainframe.

Na década de 1990, o uso de bancos de dados explodiu, e as organizações se viram com dezenas, ou mesmo centenas, de bancos de dados suportando diferentes processos de negócios. Geralmente, esses bancos de dados eram para processamento transacional (OLTP), e a capacidade de executar análises entre sistemas era limitada.

Como resultado, na década de 1990, os data warehouses (sistemas OLAP) tornaram-se uma ferramenta popular com a qual os dados podiam ser ingeridos de vários sistemas de banco de dados em um repositório central, e o data warehouse poderia se concentrar na execução de relatórios analíticos.

O data warehouse foi projetado para armazenar dados integrados, altamente selecionados e confiáveis, que também eram muito estruturados (formatados com um esquema bem definido). Os dados seriam ingeridos regularmente de outras fontes altamente estruturadas, mas antes de entrar no data warehouse, os dados passariam por uma quantidade significativa de pré-processamento, validação e transformações. Quaisquer alterações no esquema do data warehouse (como os dados foram organizados ou estruturados), ou a necessidade de ingerir novas fontes de dados, exigiriam um esforço significativo para planejar o esquema e os processos relacionados.

Nas últimas décadas, empresas e consumidores adotaram rapidamente tecnologias web e móveis, e isso resultou em um rápido crescimento nas fontes de dados, nos volumes de dados e nas opções para analisar uma quantidade crescente de dados. Em paralelo, as organizações perceberam o valor comercial dos insights que podem obter combinando dados de seus sistemas internos com dados externos de seus parceiros, da Web, das mídias sociais e de provedores de dados de terceiros. Para processar volumes de dados consistentemente maiores e demandas maiores para dar suporte a novos consumidores, os data warehouses evoluíram por meio de várias gerações de inovações tecnológicas e arquitetônicas.

Os primeiros data warehouses foram criados sob medida usando bancos de dados relacionais comuns em servidores poderosos, mas exigiam que as equipes de TI gerenciassem servidores host, armazenamento, software e integrações com fontes de dados. Eles eram difíceis de gerenciar e, portanto, em meados dos anos 2000, houve o surgimento de dispositivos de hardware projetados como dispositivos modulares de data warehouse, construídos para processamento de big data em escala de terabytes e petabytes. Esses dispositivos continham novas inovações de hardware e software e eram fornecidos como unidades fáceis de instalar e gerenciar de fornecedores populares como Oracle, Teradata, IBM Netezza, Pivotal Greenplum e outros.

Lidando com dados grandes e não estruturados

Embora os data warehouses tenham evoluído constantemente nos últimos 25+ anos para suportar volumes crescentes de dados altamente estruturados, houve um crescimento exponencial na quantidade de dados semiestruturados e não estruturados produzidos por plataformas digitais modernas (como aplicativos móveis e web, sensores, dispositivos IoT, mídias sociais e plataformas de mídia de áudio e vídeo).

Essas plataformas produzem dados em alta velocidade e em volumes muito maiores do que os dados produzidos por fontes estruturadas tradicionais. Para obter uma vantagem competitiva transformando a experiência do cliente e as operações de negócios, tornou-se essencial para as organizações obter insights mais profundos dessas novas fontes de dados. Os data warehouses tradicionais são bons em armazenar e gerenciar dados simples e estruturados de fontes como um conjunto de tabelas, organizadas como um esquema relacional. No entanto, eles não são adequados para lidar com os enormes volumes de dados semiestruturados e não estruturados de alta velocidade que estão se tornando cada vez mais populares.

Como resultado, no início da década de 2010, novas tecnologias para processamento de big data se tornaram populares. O Hadoop, uma estrutura de código aberto para processar grandes conjuntos de dados em clusters de computadores, tornou-se a principal maneira de trabalhar com big data. Esses clusters continham dezenas de centenas de máquinas com volumes de disco conectados que podiam armazenar dezenas de milhares de terabytes de dados gerenciados em um único sistema de arquivos distribuído conhecido como Hadoop Distributed File System (HDFS).

Muitas organizações implantaram distribuições Hadoop de provedores como Cloudera, Hortonworks, MapR e IBM para grandes clusters de computadores em seus data centers. Esses pacotes do Hadoop incluíam utilitários de gerenciamento de cluster, bem como estruturas de processamento de dados distribuídos de código aberto pré-configuradas e pré-integradas, como MapReduce, Hive, Spark e Presto.

No entanto, a criação e o dimensionamento de clusters Hadoop locais normalmente exigiam um grande investimento inicial de capital em máquinas e armazenamento. Além disso, o gerenciamento contínuo do cluster e dos pipelines de processamento de big data exigiu uma equipe de especialistas que incluía o seguinte:

• Administradores do Hadoop especializados em hardware e software de cluster
• Engenheiros de dados especializados em frameworks de processamento como Spark, Hive e Presto

À medida que o volume de dados crescia, novas máquinas e armazenamento precisavam ser adicionados continuamente ao cluster.

As equipes de big data que gerenciam clusters locais normalmente gastam uma porcentagem significativa de seu tempo gerenciando e atualizando o hardware e o software do cluster, além de otimizar as cargas de trabalho.

Soluções baseadas em nuvem para análise de big data

Na última década, as organizações adotaram cada vez mais soluções de nuvem pública para lidar com o desafio de aumentar o volume e a diversidade de dados. Fazer uso de soluções em nuvem para processamento de big data tem uma série de benefícios, incluindo:

• Capacidade sob demanda
• Dimensionamento ilimitado e elástico
• Presença global
• Modelos de custo baseados no uso
• Liberdade de gerenciamento de hardware

Depois que a AWS lançou o Amazon EMR em 2009 (uma plataforma gerenciada para executar estruturas Hadoop) e o Amazon Redshift em 2013 (um data warehouse nativo da nuvem), o número de outras empresas que desenvolvem soluções baseadas em nuvem para análise de big data aumentou rapidamente.

Hoje, empresas como Google Cloud Platform (GCP), Microsoft Azure, Snowflake e Databricks fornecem uma série de soluções para ingerir, armazenar e analisar grandes conjuntos de dados na nuvem.

Com o tempo, esses data warehouses em nuvem e outros sistemas de big data baseados em nuvem expandiram rapidamente seus conjuntos de recursos para exceder os de dispositivos de armazenamento de dados locais de alto desempenho e clusters Hadoop. Além de nenhum investimento inicial, uma escala de petabytes e alto desempenho, esses serviços baseados em nuvem fornecem dimensionamento elástico de capacidade, um modelo de custo baseado em uso e liberdade de gerenciamento de infraestrutura.

Na última década, o número de organizações que criam seus aplicativos de processamento de big data na nuvem acelerou. Somente nos últimos 5 anos, milhares de organizações migraram seus data warehouses existentes e aplicativos Hadoop de produtos e dispositivos de fornecedores locais para serviços baseados em nuvem.

Outra tendência trazida pela mudança para a nuvem foi a adoção de armazenamentos de objetos em nuvem altamente duráveis, baratos e praticamente ilimitados. Os armazenamentos de objetos na nuvem, como o Amazon S3, podem armazenar centenas de petabytes de dados a uma fração do custo do armazenamento local e oferecem suporte ao armazenamento de dados, independentemente de sua origem, formato ou estrutura. Eles também fornecem integrações nativas com centenas de ferramentas de processamento e análise de dados nativos da nuvem e de terceiros.

Esses novos armazenamentos de objetos em nuvem permitiram que as organizações criassem uma nova abordagem de gerenciamento de dados analíticos mais integrada com computação e armazenamento desacoplados, chamada de arquitetura de data lake. Uma arquitetura de data lake torna possível criar uma única fonte de verdade, reunindo uma variedade de dados de todos os tamanhos e tipos (estruturados, semiestruturados ou não estruturados) em um só lugar: um repositório central e altamente escalável construído usando armazenamento em nuvem barato. Uma ampla variedade de ferramentas analíticas foi criada ou modificada para se integrar a esses armazenamentos de objetos em nuvem, fornecendo às organizações muitas opções para a criação de plataformas de big data baseadas em data lake.

Em vez de elevar e transferir data warehouses existentes e clusters Hadoop para a nuvem como estão, muitas organizações estão refatorando suas cargas de trabalho locais anteriores para criar um data lake de nuvem integrado. Nessa abordagem, todos os dados são primeiro ingeridos, processados e armazenados no data lake para criar uma única fonte de verdade e, em seguida, um subconjunto dos dados "quentes" é carregado nos esquemas dimensionais de um data warehouse em nuvem para oferecer suporte a acesso de baixa latência.

Nos últimos anos, outro termo foi cunhado para se referir a uma variedade de novas tecnologias que permitem integrar o melhor dos data lakes e recursos de armazenamento de dados, chamada de abordagem data lake house. Houve soluções de empresas comerciais (como AWS, GCP, Snowflake e Databricks), bem como iniciativas lideradas pela comunidade de código aberto (como Apache Hudi e Apache Iceberg) que se referiram a uma data lake house (também às vezes chamada de Lakehouse).

alguns dos novos recursos incluem:

• A capacidade de ingerir rapidamente qualquer tipo de dados
• Armazenamento e processamento de petabytes de dados não estruturados, semiestruturados e estruturados
• Suporte para transações ACID (que faz referência a 4 propriedades principais de uma transação - ou seja, sua atomicidade, consistência, isolamento e durabilidade - permitindo que vários usuários simultâneos leiam, insiram, atualizem e excluam registros em um conjunto de dados gerenciado pelo data lakehouse)
• Acesso a dados de baixa latência
• A capacidade de consumir dados com uma variedade de ferramentas, incluindo SQL, Spark, estruturas de aprendizado de máquina e ferramentas de business intelligence

Um mergulho mais profundo nos conceitos e na arquitetura do data warehouse

Um EDW (Enterprise Data Warehouse) é o repositório de dados central que contém ativos de dados estruturados, curados, consistentes e confiáveis que são organizados em um esquema bem modelado. Os ativos de dados em um EDW são compostos por todas as informações relevantes sobre os principais domínios de negócios e são criados integrando dados provenientes dos seguintes locais:

• Executar aplicativos transacionais de negócios (ERPs, CRMs e aplicativos de linha de negócios) que oferecem suporte a todos os principais domínios de negócios em uma empresa.
• Fontes de dados externas, como dados de parceiros e terceiros.

Um EDW fornece aos usuários de negócios e tomadores de decisão uma plataforma central fácil de usar que os ajuda a encontrar e analisar uma versão única e bem modelada da verdade para várias áreas de assuntos de negócios, como clientes, produtos, vendas, marketing, cadeia de suprimentos e muito mais. Os usuários de negócios analisam dados no armazém para medir o desempenho dos negócios, encontrar tendências de negócios atuais e históricas, encontrar oportunidades de negócios e entender o comportamento do cliente.

No restante desta seção, revisaremos os conceitos fundamentais de um data warehouse discutindo uma arquitetura típica de gerenciamento de dados com um EDW no centro, conforme ilustrado na Figura 2.1. Normalmente, uma arquitetura centrada em data warehouse inclui o seguinte:

• Fontes de dados de toda a empresa que fornecem dados brutos para o data warehouse por meio de processos de extração, transformação, carga (ETL) ou extração, carregamento, transformação (ELT) (mais sobre isso mais adiante neste capítulo)
• Um ou mais data warehouses (e, opcionalmente, vários data marts focados no assunto)
• Ferramentas analíticas do usuário final para consumir dados do armazém (como ferramentas analíticas baseadas em SQL e sistemas de visualização de business intelligence)

O diagrama a seguir mostra como um data warehouse corporativo se encaixa em uma arquitetura de análise:

Figura 2.1: Arquitetura de armazenamento de dados corporativos

No centro de nossa arquitetura está o EDW, que hospeda um conjunto de ativos de dados que contêm dados atuais e históricos sobre as principais áreas de negócios. Também temos data marts opcionais que contêm um subconjunto dos dados do armazém, focados e otimizados para consultas em um domínio de negócios específico (vendas, finanças, produto, etc.).

No lado esquerdo, temos nossos sistemas de origem e um pipeline de ETL para carregar os dados no armazém e transformá-los. No lado direito, podemos ver vários sistemas/aplicativos que consomem dados do data warehouse e data marts.

Antes de nos aprofundarmos na arquitetura técnica e nas técnicas de otimização usadas em data warehouses modernos, vamos revisar alguns dos conceitos fundamentais em torno dos dados modelagem em data warehouses.

Modelagem dimensional em data warehouses

Os ativos de dados no armazém são normalmente armazenados como tabelas relacionais que são organizadas em modelos dimensionais amplamente usados, como um esquema em estrela ou um esquema de floco de neve. Armazenar dados em um armazém usando um modelo dimensional facilita a recuperação e a filtragem de dados relevantes e também torna o processamento de consultas analíticas flexível, simples e eficiente.

Vamos nos aprofundar em duas técnicas de modelagem de data warehouse amplamente usadas e ver como podemos organizar entidades de domínio de vendas como exemplo. Observe que este exemplo é apenas uma subseção de um esquema de data warehouse muito maior.

A Figura 2.2 ilustra como os dados em uma área de assunto de vendas podem ser organizados usando um esquema em estrela:

Figura 2.2: Entidades de dados de vendas organizadas em um esquema em estrela

Em data warehouses, as tabelas são geralmente separadas em tabelas de fatos e tabelas de dimensão. Na Figura 2.2, as entidades de dados são organizadas como uma estrela, com a tabela de fatos de vendas formando o meio da estrela e as tabelas de dimensão formando os cantos.

Uma tabela de fatos armazena medidas/métricas numéricas granulares para um domínio específico (como vendas). Na Figura 2.2, temos uma tabela que armazena fatos sobre uma transação de vendas individual, como o preço de venda e a quantidade vendida. A tabela de fatos também tem um grande número de colunas de chave estrangeira que fazem referência às chaves primárias das tabelas de dimensão associadas. SALES_FACT

As tabelas de dimensões armazenam o contexto sob o qual as medições de fatos foram capturadas. Na Figura 2.2, por exemplo, temos tabelas de dimensões com informações sobre lojas, produtos e outras dimensões relacionadas a cada transação de venda. Cada tabela de dimensões individuais fornece essencialmente atributos granulares relacionados a uma das dimensões do fato (como a loja onde a venda ocorreu).

Por exemplo, para uma venda específica, registramos o preço, a quantidade e o imposto para a venda na tabela de fatos e, em seguida, referenciamos dimensões como a da loja em que a venda ocorreu e a do produto que foi vendido. Em vez de armazenar todos os detalhes da loja na tabela de fatos (como endereço, região, país e número de telefone), apenas armazenamos os relacionados à venda específica como uma chave estrangeira. Quando queremos consultar dados de vendas, podemos fazer uma junção entre a tabela e a tabela para relatar os detalhes da venda (preço e quantidade) junto com a região e o país da loja (ou quaisquer outros detalhes capturados na tabela de dimensão). Também podemos fazer uma junção entre outras tabelas de dimensões para recuperar detalhes sobre o produto vendido, o funcionário que fez a venda, o dia da semana da venda, etc. store_idproduct_idstore_idSALES_FACTSTORE_DIMENSION

Os atributos dimensionais são fundamentais para encontrar e agregar medições armazenadas nas tabelas de fatos em um data warehouse. Os analistas de negócios normalmente fatiam, dados e agregam fatos de diferentes perspectivas dimensionais para gerar insights de negócios sobre a área de assunto representada pelo esquema de estrelas. Eles podem encontrar respostas para perguntas como:

• Qual é o volume total de um determinado produto vendido durante um determinado período?
• Qual é a receita total em uma determinada categoria de produto?
• Qual loja vende o maior número de produtos em uma determinada categoria?

Em um esquema em estrela, enquanto os dados de uma área de assunto são normalizados dividindo medidas e informações de contexto em tabelas de fatos e dimensões separadas, as tabelas de dimensões individuais são normalmente mantidas desnormalizadas para que todos os atributos relacionados de um tópico dimensional possam ser encontrados em uma única tabela.

Isso facilita a localização de todos os atributos relacionados de um tópico dimensional em uma única tabela (menos junções e um modelo mais simples de entender), mas para tabelas de dimensões maiores, uma abordagem desnormalizada pode levar à duplicação de dados e inconsistências na tabela de dimensões. Grandes tabelas de dimensões desnormalizadas também podem demorar a ser atualizadas.

Uma abordagem para contornar esses problemas é um tipo ligeiramente modificado de esquema, o esquema de floco de neve, que é mostrado na Figura 2.3:

Figura 2.3: Entidades de dados de vendas organizadas em um esquema de floco de neve

Os desafios de inconsistências e duplicação em um esquema de estrela podem ser resolvidos por snowflaking (basicamente normalizando) cada tabela de dimensões em várias tabelas de dimensões relacionadas (normalizando a dimensão original do produto em dimensões de produto e categoria de produto, por exemplo). Essa normalização de tabelas continua até que cada tabela de dimensão individual contenha apenas atributos com uma correlação direta com a chave primária da tabela. O modelo altamente normalizado resultante deste snowflaking é chamado de esquema de floco de neve.

O esquema de flocos de neve pode ser projetado estendendo o esquema de estrelas ou pode ser construído do zero, garantindo que cada dimensão seja altamente normalizada e conectada a tabelas de dimensões relacionadas formando uma hierarquia. Um esquema de floco de neve pode reduzir a redundância e minimizar o espaço em disco, em comparação com um esquema em estrela, que geralmente contém registros duplicados. No entanto, por outro lado, o esquema de floco de neve pode exigir junções complexas para responder a consultas de negócios e pode diminuir o desempenho da consulta.

Para decidir se deseja usar um esquema de floco de neve ou estrela, você precisa considerar os tipos de consultas que provavelmente serão executados em relação ao conjunto de dados e equilibrar os prós e contras de consultas potencialmente mais lentas e complexas com um esquema de floco de neve versus atualizações de menor desempenho e mais complexidade no gerenciamento de alterações em tabelas de dimensão com um esquema em estrela.

Vamos agora dar uma olhada mais de perto no papel dos data marts, que podem ser usados para fornecer um repositório de dados mais fácil de trabalhar, com um esquema focado em um aspecto específico de um negócio.

Entendendo o papel dos data marts

Os data warehouses contêm dados de todos os domínios de negócios relevantes e têm um esquema abrangente e complexo. Os data warehouses são projetados para a análise entre domínios necessária para informar decisões estratégicas de negócios. No entanto, as organizações geralmente também têm um conjunto mais restrito de usuários que desejam se concentrar em uma determinada linha de negócios, departamento ou área de assunto de negócios. Esses usuários preferem trabalhar com um repositório que tenha um esquema simples de aprender e apenas o subconjunto de dados que se concentra na área em que estão interessados. As organizações normalmente criam data marts para atender a esses usuários.

Um data mart é focado em um único repositório de assuntos de negócios (por exemplo, marketing, vendas ou finanças) e normalmente é criado para atender a um grupo mais restrito de usuários corporativos, como um único departamento. Um data mart geralmente tem um conjunto de tabelas de fatos desnormalizadas organizadas em um esquema muito mais simples em comparação com o de um EDW. Esquemas mais simples e um volume de dados reduzido tornam os data marts mais rápidos de criar, mais simples de entender e mais fáceis de usar para os usuários finais. Um data mart pode ser criado como:

• De cima para baixo: os dados são retirados de um data warehouse existente, com foco em uma fatia dos dados do assunto da empresa
• De baixo para cima: os dados são originados diretamente dos bancos de dados transacionais usados para executar um domínio de negócios específico de interesse

Tanto os data warehouses quanto os data marts fornecem uma visão integrada dos dados de várias fontes, mas diferem no escopo dos dados que armazenam. Os data warehouses fornecem um armazenamento central de dados para toda a empresa, ou divisão, e abrangem todos os domínios de negócios. Os data marts servem a uma função de negócios específica, fornecendo uma visão integrada de uma área temática relevante para essa função de negócios.

Até agora, discutimos vários aspectos de data warehouses e data marts, os repositórios de dados centrais de nossa arquitetura EDW da Figura 2.1. Agora, vamos fazer um mergulho mais profundo na arquitetura técnica e nas otimizações que tornam os data warehouses modernos eficazes na consulta de grandes volumes de dados.

Armazenamento distribuído e processamento paralelo maciço

Na Figura 2.4, vemos a arquitetura subjacente de um cluster do Amazon Redshift. Existem vários tipos diferentes de nós Redshift, e a Figura 2.4 mostra um cluster Redshift baseado em nós RA3 (que examinaremos mais detalhadamente no Capítulo 9, Um mergulho mais profundo em Data Marts e Amazon Redshift):

Figura 2.4: Arquitetura MPP de um cluster RA3 do Amazon Redshift

Como visto na Figura 2.4, um cluster do Amazon Redshift contém um nó líder e um ou mais nós de computação:

• O nó líder faz interface com aplicativos cliente, recebe e analisa consultas e coordena a execução de consultas em nós de computação.
• Vários nós de computação têm armazenamento de alto desempenho para armazenar um subconjunto dos dados do armazém e executar etapas de execução de consulta em paralelo nos dados que armazenam.
• Para tipos de nó RA3 (conforme ilustrado neste diagrama), o Amazon S3 é usado como Redshift Managed Storage (RMS) para dados de depósito, e o armazenamento local de alto desempenho do nó de computação é usado como um cache para dados ativos.

Cada nó de computação tem seus próprios processadores independentes, memória e volumes de armazenamento de alto desempenho que são isolados de outros nós de computação no cluster (isso é chamado de arquitetura de nada compartilhado).

Os data warehouses em nuvem implementam uma arquitetura de processamento de consultas distribuída chamada MPP (Massively Parallel Processing) para acelerar consultas em grandes volumes de dados. Nessa abordagem, o nó líder do cluster primeiro compila a consulta do cliente de entrada em um plano de execução distribuído. Em seguida, ele coordena a execução de segmentos de código de consulta compilado em vários nós de computação do cluster de data warehouse, em paralelo. Cada nó de computação executa segmentos de consulta atribuídos em uma parte do conjunto de dados distribuído.

Armazenamento de dados colunares e compactação de dados eficiente

Além de fornecer armazenamento massivo e computação em cluster, os data warehouses modernos também aumentam o desempenho de consultas por meio de armazenamento orientado a colunas e compactação de dados. Nesta seção, examinaremos como isso funciona, mas primeiro, vamos entender como os bancos de dados OLTP armazenam seus dados.

Os aplicativos OLTP normalmente funcionam com linhas inteiras que incluem todas as colunas da tabela (por exemplo, leitura/gravação de um registro de vendas ou pesquisa de um registro de catálogo). Para atender aplicativos OLTP, os bancos de dados back-end precisam ler e gravar linhas completas com eficiência no disco. Para acelerar pesquisas e atualizações de linha inteira, os bancos de dados OLTP usam um layout orientado a linha para armazenar linhas de tabela no disco. Em um layout de dados físicos orientado a linha, todos os valores de coluna de uma determinada linha são co-localizados, conforme ilustrado na Figura 2.5:

Figura 2.5: Layout de armazenamento orientado a linha

A maioria das consultas de análise que os usuários corporativos executam em um data warehouse são gravadas para responder a uma pergunta específica e normalmente incluem agrupamento e agregações (como soma, média ou média) em um grande número de linhas, mas de um conjunto estreito de colunas das tabelas de fato e dimensão (elas geralmente contêm muito mais colunas do que o conjunto estreito de colunas incluído na consulta). As consultas do Google Analytics geralmente precisam examinar um grande número de linhas, mas precisam de dados de apenas um conjunto restrito de colunas relacionadas à consulta específica. Um layout de dados físicos orientado a linhas força as consultas de análise a examinar um grande número de linhas completas (todas as colunas), mesmo que elas precisem apenas de um subconjunto das colunas dessas linhas. As consultas analíticas em um banco de dados orientado a linha podem, portanto, exigir um número muito maior de operações de E/S de disco do que o necessário.

Os data warehouses modernos armazenam dados em discos usando um layout físico orientado a colunas. Isso é mais adequado para o processamento de consultas analíticas, que requer apenas um subconjunto de colunas por consulta. Ao armazenar os dados de uma tabela em um layout físico orientado a colunas, um data warehouse divide uma tabela em grupos de linhas, chamados de blocos/grupos de linhas. Em seguida, ele usa um bloco de linha de cada vez e estabelece os dados desse bloco de linha, uma coluna de cada vez, de modo que todos os valores de uma coluna (ou seja, para esse bloco de linha) sejam fisicamente co-localizados no disco, conforme ilustrado na Figura 2.6:

Figura 2.6: Layout de armazenamento orientado a colunas

Os data warehouses repetem isso para todos os blocos de linha da tabela. Além de armazenar tabelas como blocos de linha e usar um layout físico orientado a colunas em discos, os data warehouses também mantêm mapas na memória dos locais desses blocos. Os data warehouses modernos usam esses mapas na memória para identificar locais de coluna no disco e ler os valores fisicamente colocalizados da coluna. Isso permite que o mecanismo de consulta recupere dados apenas para o conjunto restrito de colunas necessárias para uma determinada consulta de análise. Ao fazer isso, a E/S de disco é significativamente reduzida em comparação com o que seria necessário para executar a mesma consulta em um banco de dados orientado a linha.

Além de usar um layout de armazenamento orientado a colunas, os data warehouses modernos também empregam vários algoritmos de compactação para uma tabela. O armazém é capaz de corresponder colunas individuais com o algoritmo de compactação que é mais ideal para o tipo de coluna e perfil de sua coluna conteúdo de dados.

Além de economizar espaço de armazenamento, os dados compactados exigem E/S de disco muito menor para ler e gravar dados no disco. Os algoritmos de compactação fornecem taxas de compactação muito melhores quando todos os valores que estão sendo compactados têm o mesmo tipo de dados e têm uma porcentagem maior de duplicatas. Como os bancos de dados orientados a colunas estabelecem valores da mesma coluna (portanto, o mesmo tipo de dados, como cadeias de caracteres ou inteiros) juntos, os data warehouses alcançam boas taxas de compactação, resultando em leitura/gravação mais rápidas e menores ocupações em disco.

Agora que temos uma melhor compreensão da arquitetura dos data warehouses modernos, vamos examinar os processos (geralmente chamados de pipelines) que são usados para mover dados para um data warehouse e para transformar os dados para otimizá-los para análise.

Alimentando dados no armazém – pipelines ETL e ELT

Para trazer dados para o armazém (e, opcionalmente, data marts), as organizações normalmente criam pipelines de dados que fazem o seguinte:

• Extrair dados de sistemas de origem.
• Transforme os dados de origem validando-os, limpando-os, padronizando-os e organizando-os.
• Carregue os dados de origem transformados no esquema de data warehouse corporativo e, opcionalmente, também em um data mart.

Nesses pipelines, a primeira etapa é extrair dados dos sistemas de origem, mas as duas próximas etapas podem assumir uma sequência Transform-Load ou Load-Transform (portanto, ETL ou ELT).

Os data warehouses de uma organização moderna normalmente ingerem dados de um conjunto diversificado de fontes, como bancos de dados de aplicativos ERP e CRM, arquivos armazenados em arrays NAS (Network-Attached Storage, armazenamento conectado à rede), aplicativos SaaS e aplicativos de parceiros externos. Os componentes usados para implementar a etapa Extract dos pipelines ETL e ELT normalmente precisam se conectar a essas fontes e manipular diversos formatos de dados (incluindo tabelas relacionais, arquivos simples e fluxos contínuos de registros).

A decisão de criar um pipeline de dados ETL ou ELT baseia-se no seguinte:

• A complexidade das transformações de dados necessárias
• As habilidades e ferramentas que a organização tem disponíveis para criar etapas de transformação de dados
• A velocidade com que os dados de origem precisam ser disponibilizados para análise no data warehouse depois de produzidos no sistema de origem.

A Figura 2.7 mostra um pipeline ETL típico para carregar dados em um data warehouse:

Figura 2.7: Pipeline de ETL

Com um pipeline de ETL, as transformações são executadas fora do data warehouse usando scripts personalizados, um serviço de ETL nativo da nuvem, como o AWS Glue, ou uma ferramenta de ETL especializada de um fornecedor comercial, como Informatica, Talend, DataStage, Microsoft ou Pentaho.

Um pipeline de ETL pode ser um único sistema que tem conectores para extrair e carregar os dados, além de fazer as transformações, ou pode haver vários sistemas no pipeline. Por exemplo, um pipeline de ETL pode consistir no seguinte:

• Um ou mais sistemas que extraem dados de várias fontes (bancos de dados, soluções SaaS, armazenamento de arquivos, etc.) e gravam os dados em uma área de armazenamento bruto/de preparo
• Um ou mais trabalhos de transformação que leem dados da área de armazenamento bruto/de preparo, transformam os dados e os gravam em uma área de armazenamento transformada
• Outro sistema que lê os dados da área de armazenamento transformada e carrega os dados no data warehouse

Um mecanismo de transformação pode executar vários trabalhos de transformação para executar tarefas como validar dados, limpar dados e transformar dados para o esquema dimensional do data warehouse de destino.

Uma abordagem de ETL para criar um pipeline de dados é normalmente usada quando os seguintes itens são verdadeiros:

• As tecnologias e os formatos do banco de dados de origem são diferentes daqueles do data warehouse
• A equipe de engenharia deseja realizar transformações usando uma linguagem de programação (como PySpark) em vez de SQL puro
• As transformações de dados são complexas e exigem muita computação

Por outro lado, um pipeline ELT extrai dados (normalmente dados altamente estruturados) de várias fontes e os carrega como está na área de preparo do data warehouse. O mecanismo de banco de dados que alimenta o data warehouse é usado para executar operações de transformação nos dados em estágios e grava os dados transformados em uma tabela de produção (pronta para consumo).

A figura 2.8 mostra um pipeline típico do ELT:

Figura 2.8: Pipeline ELT

A abordagem ELT permite carregar rapidamente grandes quantidades de dados de origem no armazém. Além disso, a arquitetura MPP dos data warehouses modernos pode acelerar significativamente as etapas de transformação nos pipelines ELT. A abordagem ELT é normalmente aproveitada quando o seguinte é verdadeiro:

• As fontes de dados e o armazém têm tecnologias de banco de dados semelhantes, facilitando o carregamento direto dos dados de origem nas tabelas de preparo no depósito.
• Um grande volume de dados precisa ser carregado rapidamente no armazém.
• Todas as etapas de transformação necessárias podem ser executadas usando os recursos SQL nativos do mecanismo de banco de dados do armazém.

Com uma abordagem ELT, as tarefas de transformação de dados geralmente são executadas usando código SQL. Embora haja uma grande quantidade de conhecimento e habilidades em SQL disponíveis no mercado, há outras opções para executar transformações (como usar o Apache Spark com código PySpark ou Scala). O uso de uma abordagem ELT limita suas transformações ao uso de SQL, que pode ou não ser melhor com base nos conjuntos de habilidades e requisitos de sua organização.

A principal diferença entre ETL e ELT é sobre onde a transformação de dados ocorre. Com o ELT, os dados são carregados diretamente no data warehouse e o mecanismo do data warehouse é usado para a transformação (normalmente usando SQL para criar uma nova versão transformada dos dados). Com o ETL, um mecanismo fora do data warehouse primeiro transforma os dados antes de gravá-los no data warehouse.

Nesta seção, aprendemos como os data warehouses podem armazenar e processar petabytes de dados estruturados. Os data warehouses modernos fornecem processamento de alto desempenho usando um modelo de dados dimensionais (como estrela ou floco de neve), paralelismo computacional e um layout de dados físicos colunares com compactação. As arquiteturas de gerenciamento de dados nas organizações modernas, no entanto, também precisam armazenar e analisar volumes explosivos de dados semiestruturados e não estruturados. Na próxima seção, aprenderemos sobre uma arquitetura mais recente, chamada data lakes, que as principais organizações atuais normalmente implementam para armazenar, processar e analisar dados estruturados, semiestruturados e não estruturados.

Uma visão geral da arquitetura e dos conceitos de data lake

Como vimos na seção anterior, os EDWs têm sido os repositórios ideais para armazenar dados tabulares altamente estruturados provenientes dos bancos de dados transacionais usados por aplicativos de negócios. No entanto, a falta de uma estrutura tabular bem definida torna os data warehouses típicos menos adequados para armazenar dados não estruturados e semiestruturados. Além disso, embora sejam bons para casos de uso que precisam de processamento baseado em SQL, os data warehouses são limitados ao processamento de dados principalmente usando apenas SQL, e o SQL não é a ferramenta certa para todos os requisitos de processamento de dados. Por exemplo, extrair metadados de dados não estruturados, como arquivos de áudio ou imagens, é mais adequado para ferramentas especializadas de aprendizado de máquina.

Um data lake na nuvem é um repositório central e altamente escalável na nuvem onde uma organização pode gerenciar exabytes de vários tipos de dados, incluindo:

• Dados estruturados (tabelas baseadas em linha-coluna)
• Dados semiestruturados (como arquivos JSON e XML, registros de log e fluxos de dados do sensor)
• Dados não estruturados (como áudio, fluxos de vídeo, documentos Word/PDF e e-mails)

Os dados de qualquer uma dessas fontes podem ser carregados rapidamente no data lake como estão (mantendo o formato e a estrutura originais da fonte). Ao contrário dos data warehouses, os dados não precisam primeiro ser convertidos em uma estrutura padrão antes de serem consumidos.

Um data lake em nuvem também se integra nativamente a serviços analíticos de nuvem que são desacoplados do armazenamento de data lake e permite diversas ferramentas analíticas, incluindo SQL, ferramentas baseadas em código (como o Apache Spark), ferramentas especializadas de aprendizado de máquina e ferramentas de visualização de business intelligence.

Na próxima seção, nos aprofundaremos na arquitetura de um data lake típico.

Arquitetura lógica de data lake

Vamos examinar mais de perto a arquitetura de um data lake nativo da nuvem, observando sua arquitetura lógica, conforme mostrado na Figura 2.9:

Figura 2.9: Camadas lógicas de uma arquitetura de data lake

Podemos visualizar uma arquitetura de data lake como um conjunto de componentes independentes organizados em cinco camadas lógicas. Uma arquitetura de data lake em camadas e orientada a componentes pode evoluir ao longo do tempo para incorporar novas inovações em métodos de gerenciamento e análise de dados, bem como para fazer uso de novas ferramentas. Isso mantém o data lake responsivo a novas fontes de dados e requisitos em mudança. Na próxima seção, vamos nos aprofundar nessas camadas.

A camada de armazenamento e as zonas de armazenamento

Na parte inferior da arquitetura de data lake ilustrada na Figura 2.9 está a camada de armazenamento, criada em um armazenamento de objetos na nuvem, como o Amazon S3. Isso fornece armazenamento praticamente ilimitado e de baixo custo que pode armazenar uma variedade de dados, independentemente da estrutura ou formato.

A camada de armazenamento é organizada em diferentes zonas, com cada zona tendo uma finalidade específica. Os dados se movem pelas várias zonas do data lake, com cópias novas e modificadas dos dados em cada zona à medida que os dados passam por várias transformações. Não há regras rígidas sobre quantas zonas devem existir, ou os nomes das zonas, mas as seguintes zonas são comumente encontradas em um data lake típico:

• Zona de pouso/crua. Esta é a zona onde a camada de ingestão grava dados, como estão, dos sistemas de origem. A zona de pouso/bruto armazena permanentemente os dados brutos da origem.
• Zona de limpeza/transformação. O processamento inicial de dados na zona de pouso/bruto, como validação, limpeza e otimização de conjuntos de dados, grava dados na zona de limpeza/transformação. Os dados aqui são frequentemente armazenados em formatos otimizados, como o Parquet, e muitas vezes são particionados para acelerar a execução da consulta e o processamento downstream. Os dados nessa zona também podem ter tido informações de PII removidas, mascaradas ou substituídas por tokens.
• Zona com curadoria/enriquecimento. Os dados na zona limpa/transformada podem ser refinados e enriquecidos com lógica e transformações específicas do negócio, e esses dados são gravados na zona curada/enriquecida. Esses dados estão em seu estado mais consumível e atendem a todos os padrões organizacionais (em termos de limpeza, formatos de arquivo e esquema). Normalmente, os dados aqui são particionados, catalogados e otimizados para a camada de consumo.

Dependendo dos requisitos de negócios, alguns data lakes podem incluir mais ou menos zonas do que as 3 zonas destacadas acima. Por exemplo, um data lake muito simples pode ter apenas duas zonas (as zonas brutas e selecionadas), enquanto alguns data lakes podem ter 5 ou mais zonas para lidar com estágios intermediários ou requisitos específicos.

Camadas de catálogo e pesquisa

Um data lake normalmente hospeda um grande número de conjuntos de dados (potencialmente milhares), de uma variedade de fontes internas e externas. Esses conjuntos de dados geralmente são úteis para várias equipes em toda a organização, e essas equipes precisam da capacidade de pesquisar conjuntos de dados disponíveis e revisar O esquema e outros metadados desses conjuntos de dados.

Um catálogo técnico é usado para mapear os muitos arquivos armazenados na camada de armazenamento em uma representação lógica de bancos de dados e tabelas, com cada tabela tendo colunas de um tipo de dados específico (o esquema de tabela). Um catálogo técnico, como o AWS Glue Data Catalog, armazena os metadados que definem a relação entre arquivos físicos no armazenamento e uma definição de tabela no catálogo. As ferramentas de consumo (como o Amazon Athena) podem usar o catálogo técnico para entender quais arquivos ler da camada de armazenamento quando um usuário consulta um banco de dados e uma tabela específicos.

Um catálogo de negócios se concentra nos metadados que são importantes para os negócios. Isso pode incluir atributos como o proprietário dos dados, a data em que o conjunto de dados foi atualizado pela última vez, uma descrição da finalidade da tabela, definições de coluna e muito mais. O catálogo de negócios também pode se integrar ao catálogo técnico para fornecer informações sobre o esquema de tabela na interface do catálogo de negócios. O catálogo de negócios também deve oferecer suporte à capacidade de fazer pesquisas avançadas, permitindo que as equipes encontrem dados relevantes para seus casos de uso. Fazemos um mergulho profundo na catalogação de dados no Capítulo 4, Governança de dados, segurança e catalogação.

Camada de ingestão

A camada de ingestão é responsável por se conectar a diversos tipos de fontes de dados e trazer seus dados para a zona de pouso/bruto da camada de armazenamento. Essa camada pode conter uma variedade de ferramentas independentes, cada uma criada especificamente para se conectar a uma fonte de dados com um perfil distinto em termos de:

• Estrutura de dados (estruturada, semiestruturada ou não estruturada)
• Tipo de entrega de dados (linhas de tabela, fluxo de dados, arquivo de dados)
• Cadência de produção de dados (lote ou streaming)

Essa abordagem fornece a flexibilidade de adicionar facilmente novas ferramentas para corresponder ao perfil distinto de uma nova fonte de dados.

Uma camada de ingestão típica pode incluir ferramentas como o AWS Database Migration Service (DMS) para ingestão de vários bancos de dados, o Amazon Kinesis Firehose para ingestão de dados de streaming e o Amazon AppFlow para ingestão de dados de aplicativos SaaS.

A camada de processamento

Uma vez que a camada de ingestão traz dados de um sistema de origem para a zona de pouso, é a camada de processamento que os torna prontos para o consumo pelos consumidores de dados. A camada de processamento transforma os dados no lago por meio de vários estágios de limpeza, padronização e enriquecimento de dados. Ao longo do caminho, a camada de processamento armazena dados transformados nas diferentes zonas – gravando-os na zona limpa e, em seguida, na zona selecionada e, em seguida, garantindo que o catálogo de dados técnicos seja atualizado. As ferramentas comumente usadas nessa camada incluem o AWS Glue e o Amazon EMR.

Os componentes nas camadas de ingestão e processamento são usados para criar pipelines ELT. Nesses pipelines, os componentes da camada de ingestão extraem dados dos sistemas de origem e carregam os dados no data lake e, em seguida, os componentes da camada de processamento os transformam para torná-los adequados para o consumo por componentes na camada de consumo.

A camada de consumo

Uma vez que os dados são ingeridos e processados para torná-los prontos para o consumo, eles podem ser analisados usando várias técnicas, como processamento interativo de consultas, painéis de business intelligence e aprendizado de máquina. Para executar análises em dados no lago, a camada de consumo fornece ferramentas criadas especificamente que podem acessar dados da camada de armazenamento e o esquema da camada de catálogo (para aplicar esquema em leitura aos dados hospedados no lago).

Resumo da arquitetura do data lake

Nesta seção, aprendemos sobre arquiteturas de data lake e como elas podem permitir que as organizações gerenciem e analisem grandes quantidades de dados estruturados, não estruturados e semiestruturados.

As plataformas de análise em uma organização típica precisam atender a casos de uso de análise de dados estruturados no estilo de armazenamento (como para consultas complexas e painéis de BI), bem como casos de uso que exigem o gerenciamento e a análise de grandes quantidades de dados não estruturados e semiestruturados. Como resultado, as organizações normalmente acabam criando um data warehouse e um data lake, geralmente com pouca interação entre o armazém e o lago.

Reunindo o melhor dos data warehouses e data lakes

No mundo altamente digitalizado de hoje, os dados sobre clientes, produtos, operações e a cadeia de suprimentos podem vir de muitas fontes e podem ter um conjunto diversificado de estruturas. Para obter insights mais profundos e completos orientados por dados sobre um tópico de negócios (como jornada do cliente, retenção de clientes, desempenho do produto etc.), as organizações precisam analisar todos os dados relevantes para o tópico, de todas as estruturas, de todas as fontes, juntos.

Um data lake é adequado para armazenar todos esses diferentes tipos de dados de forma barata e fornece uma ampla variedade de ferramentas para trabalhar e consumir os dados. Isso inclui a capacidade de transformar dados com estruturas como o Apache Spark, treinar modelos de aprendizado de máquina nos dados usando ferramentas como o Amazon SageMaker e consultar os dados usando SQL com ferramentas como Amazon Athena, Presto ou Trino.

No entanto, existem algumas limitações para os data lakes tradicionais. Por exemplo, implementações tradicionais de data lakes não oferecem suporte às propriedades ACID (atomicidade, consistência, isolamento e durabilidade) comuns na maioria dos bancos de dados. Além disso, devido ao uso de armazenamento de objetos barato como camada de armazenamento, o desempenho da consulta não corresponde ao que é possível com data warehouses que usam armazenamento local baseado em SSD de alto desempenho.

Essas limitações causam complexidade quando você tem várias equipes trabalhando no mesmo conjunto de dados, pois uma equipe atualizando dados no data lake enquanto outra equipe tenta consultar o data lake pode levar a inconsistências nas consultas. Além disso, quando você usa muito painéis e relatórios, como é comum com aplicativos de Business Intelligence, o desempenho de consultas em dados de data lake pode não atender aos requisitos.

Esses desafios geralmente são contornados carregando um subconjunto dos dados do data lake em um data warehouse, como o Amazon Redshift ou o Snowflake. Isso oferece o desempenho necessário para aplicativos de business intelligence exigentes e também fornece consistência quando várias equipes estão trabalhando com o mesmo conjunto de dados. No entanto, o armazenamento de data warehouse é caro, e alguns casos de uso exigem a junção de dados em um conjunto diversificado de dados e não é econômico carregar todos esses dados no data warehouse.

Para contornar esses desafios, foram criados novos formatos de tabela que simplificam o processo de atualização de tabelas de data lake de forma transacionalmente segura, e uma nova funcionalidade está disponível para habilitar consultas federadas (junções de dados em diferentes mecanismos de armazenamento) em uma abordagem geralmente chamada de data lake house.

A abordagem da data lake house

Durante o ano de 2020, vários fornecedores começaram a usar um novo termo para falar sobre uma abordagem que reunia o melhor dos data warehouses e data lakes. Alguns fornecedores se referiram a isso como uma Lakehouse, enquanto outros a chamaram de data lake house, ou data lakehouse. Além dessas diferenças no nome da abordagem, os diferentes vendedores tinham definições ligeiramente diferentes do que era uma casa no lago.

Ainda hoje você pode ler blogs e artigos sobre diferentes abordagens de lake house de empresas como AWS, Azure, Google, Snowflake, Databricks, Dremio e Starburst. Por causa disso, eu consideraria a terminologia da casa do lago mais um termo de marketing do que um termo técnico. Em última análise, não há uma definição padrão de uma casa de lago, além da intenção de diferentes fornecedores de fornecer o melhor de data warehouses e data lakes com suas próprias pilhas de tecnologia.

No entanto, há uma série de tecnologias e abordagens amplamente adotadas que permitem que essas empresas borrem as linhas entre um data warehouse e um data lake.

Novos formatos de tabela data lake

Ao longo dos últimos anos, uma série de novos formatos de mesa foram propostos que são efetivamente uma nova geração do formato de mesa Hive original, um formato desenvolvido no Facebook há mais de uma década. Embora o Hive tenha sido fundamental para permitir a criação e o crescimento de data lakes, há uma série de desafios com o formato Hive que impõem limites significativos aos data lakes baseados no Hive. Como resultado, hoje existem três novos formatos de tabela concorrentes principais que podem ser usados para desenvolver data lakes modernos.

Embora cada um desses formatos de tabela tenha seus próprios pontos fortes e fracos, todos eles se destinam a permitir atualizações e leituras simplificadas e mais consistentes de dados de data lake (especialmente quando você tem várias equipes trabalhando com o mesmo conjunto de dados), bem como oferecer melhorias de desempenho e a capacidade de consultar uma tabela como ela era em um determinado ponto no tempo (muitas vezes chamada de viagem no tempo). Muitos provedores de soluções de big data estão adicionando suporte para um ou mais desses formatos de tabela, à medida que criam suas ofertas de "data lake house". Esses novos formatos de tabela fornecem funcionalidade para trabalhar com dados em um data lake semelhante ao que tradicionalmente só estava disponível em bancos de dados e data warehouses.

Os três principais formatos de tabela de nova geração são:

• Lago Delta. Este é um formato de tabela criado pela empresa Databricks e é oferecido tanto como uma versão comercial paga com funcionalidade aprimorada quanto como uma versão de código aberto, que é um projeto Linux Foundation. Várias ferramentas comerciais e de código aberto são capazes de trabalhar com arquivos Delta Lake, incluindo Apache Spark, Presto, Snowflake, Redshift e outros.
• Apache Hudi. Este é um formato de tabela que foi criado pela Uber, e mais tarde doado para a Apache Software Foundation, e agora está disponível como uma solução de código aberto. O Hudi tem sido bastante adotado, e postagens de blog/estudos de caso que mencionam o uso do Apache Hudi incluem aqueles de empresas como Amazon Transportation Service, Walmart, Robinhood e GE Aviation.
• Iceberg Apache. Este formato de tabela foi criado por dois engenheiros da Netflix e posteriormente doado à Apache Software Foundation, tornando-o disponível como uma solução de código aberto. As empresas que mencionaram publicamente o uso do Apache Iceberg, ou que contribuíram para o projeto de código aberto, incluem Airbnb, Expedia, Adobe, Apple e Lyft.

É impossível prever com certeza qual desses formatos de tabela (ou potencialmente outros ainda a serem popularizados) se tornará dominante nos próximos anos, mas recentemente parece que o Apache Iceberg está gerando cada vez mais interesse e ganhando cada vez mais suporte de fornecedores de produtos de big data.

Consultas federadas em mecanismos de banco de dados

Outra abordagem que se tornou comum na busca por combinar o melhor dos data lakes e data warehouses é a funcionalidade que permite consultas em diferentes mecanismos de banco de dados ou plataformas de armazenamento. Por exemplo, data warehouses em nuvem, como Amazon Redshift e Snowflake, podem consultar dados carregados no data warehouse, bem como dados em um data lake baseado no Amazon S3.

Com essa abordagem, os 12 meses mais recentes de dados poderiam ser carregados em um data warehouse, enquanto os 4 anos anteriores de dados poderiam ser armazenados no data lake. A maioria das consultas consultaria apenas os 12 meses mais recentes de dados, e isso seria armazenado no armazenamento de alto desempenho do data warehouse. No entanto, para as consultas que precisavam acessar as informações históricas, o data warehouse poderia unir tabelas no data lake do S3 com os dados recentes no data warehouse.

Essa federação de consulta pode ir além de apenas unir tabelas no data warehouse e tabelas no data lake baseado no S3 para consultar dados em outros mecanismos de armazenamento também. Por exemplo, com o Amazon Redshift, você pode definir tabelas externas que apontam para dados em um banco de dados PostgreSQL ou MySQL.

Com consultas federadas, a necessidade de copiar dados entre diferentes sistemas de dados por meio de pipelines de ETL é reduzida. No entanto, a consulta em sistemas diferentes não funciona tão bem quanto a consulta em dados somente locais, portanto, há casos de uso em que você ainda deseja copiar dados entre sistemas. No entanto, ter a capacidade de consultar dados entre sistemas é útil em muitas situações e ajuda a criar um ecossistema de big data mais integrado. As mensagens da AWS em torno do conceito de casa do lago muitas vezes incluíram destacar essa capacidade de ter acesso a dados em diferentes sistemas, com um catálogo de dados compartilhado e sem a necessidade de sempre criar uma cópia dos dados de origem em cada sistema.

Prático – usando a AWS Command Line Interface (CLI) para criar buckets do Simple Storage Service (S3)

O acesso ao console permite que você acesse os serviços da AWS e execute a maioria das funções; no entanto, às vezes também pode ser útil interagir com os serviços da AWS por meio da CLI.

Nesta seção prática, você aprenderá a acessar a AWS CLI e, em seguida, usar a CLI para criar buckets do Amazon S3 (um contêiner de armazenamento no serviço do Amazon S3).

Acesso à AWS CLI

A AWS CLI pode ser instalada em seu computador/laptop pessoal ou pode ser acessada no Console AWS. Para acessar a CLI em seu computador pessoal, você precisa gerar um conjunto de chaves de acesso.

Suas chaves de acesso consistem em um ID de chave de acesso (que é comparável a um nome de usuário) e uma chave de acesso secreta (que é comparável a uma senha). Com essas duas informações, você pode se autenticar como seu usuário e executar todas as ações que seu usuário está autorizado a executar.

No entanto, se qualquer outra pessoa conseguisse obter seu ID de chave de acesso e chave de acesso secreta, ela teria acesso às mesmas permissões. No passado, houve casos em que os usuários expuseram acidentalmente seu ID de chave de acesso e chave de acesso secreta, permitindo que terceiros mal-intencionados usassem sua conta de forma fraudulenta.

Como resultado, a maneira mais fácil e segura de acessar a CLI é por meio do serviço AWS CloudShell, que pode ser acessado por meio do console.

Como usar o AWS CloudShell para acessar a CLI

O CloudShell fornece uma interface de terminal em seu navegador da Web, como parte do Console AWS, que pode ser usada para explorar e gerenciar recursos da AWS, usando as permissões do usuário com o qual você faz login no console. Com essa abordagem, não há necessidade de gerar chaves de acesso para seu usuário.

Use as seguintes etapas para acessar a CLI por meio do AWS CloudShell:

1. Faça login no Console AWS (https://console.aws.amazon.com) usando as credenciais criadas no Capítulo 1.
2. Clique no ícone do CloudShell ou use a barra de pesquisa para procurar o serviço CloudShell.

Figura 2.10: Acesso ao serviço AWS CloudShell no console

1. Para interagir com os serviços da AWS, execute o comando . Para saber como interagir com um serviço específico, você pode executar o comando, seguido do nome do serviço da AWS com o qual deseja interagir (como S3), seguido de . Por exemplo, para saber como usar o serviço do Amazon S3, execute o seguinte comando, que exibirá a página de ajuda do serviço do S3: awsawshelp

aws s3 help 
Copy
Explain

Figura 2.11: Exibição da página de ajuda da AWS CLI para o Amazon S3

1. Pressione a barra de espaço para exibir as páginas subsequentes da ajuda ou pressione a letra q para sair das páginas de ajuda.

Criação de novos buckets do Amazon S3

O Amazon S3 é um serviço de armazenamento de objetos que oferece capacidade quase ilimitada com altos níveis de durabilidade e disponibilidade. Para armazenar dados no S3, você precisa criar um bucket. Depois de criado, o bucket pode armazenar qualquer número de objetos.

Cada bucket do S3 precisa ter um nome globalmente exclusivo, e é recomendável que o nome seja compatível com DNS. Para obter mais informações sobre regras para nomes de bucket, consulte https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html:

1. Para criar um bucket do S3 usando a AWS CLI, execute o seguinte comando no prompt de comando no CloudShell. No comando a seguir, substitua por um nome exclusivo para seu bucket: <bucket-name>

$ aws s3 mb s3://<bucket-name> 
Copy
Explain

1. 
   
2. Lembre-se de que o nome do bucket especificado aqui deve ser globalmente exclusivo. Se você tentar criar um bucket usando um nome usado por outra conta da AWS, verá um erro semelhante ao seguinte:

$ aws s3 mb s3://test-bucket make_bucket failed: s3://test-bucket An error occurred (BucketAlreadyExists) when calling the CreateBucket operation: The requested bucket name is not available. The bucket namespace is shared by all users of the system. Please select a different name and try again. 
Copy
Explain

1. 
   
2. Se o seu comando retornou uma mensagem semelhante à seguinte, então parabéns! Você criou seu primeiro bucket.aws s3 mb

make_bucket: <bucket-name> 
Copy
Explain

1. Agora podemos criar baldes adicionais que usaremos em alguns dos exercícios práticos nos próximos capítulos. Conforme discutido anteriormente neste capítulo, os data lakes geralmente têm várias zonas para dados em diferentes estágios. Para configurar nosso data lake, queremos criar buckets do S3 para a zona de pouso, a zona limpa e a zona selecionada. Consulte a seção intitulada A camada de armazenamento e as zonas de armazenamento anteriormente neste capítulo para obter uma descrição de cada uma das regiões.

Para garantir que cada nome de bucket criado seja globalmente exclusivo, você pode acrescentar alguns caracteres exclusivos a cada nome, como suas iniciais e, se necessário, alguns números. Nos exemplos abaixo, vou anexar a cada nome de bucket para garantir que ele seja exclusivo. gse23

Execute os três comandos a seguir no terminal do CloudShell para criar seus buckets (substituindo por seu próprio identificador). gse23

$ aws s3 mb s3://dataeng-landing-zone-gse23 $ aws s3 mb s3://dataeng-clean-zone-gse23 $ aws s3 mb s3://dataeng-curated-zone-gse23 
Copy
Explain

Agora criamos os buckets de armazenamento que formarão a base das três zonas do nosso data lake (zona de pouso, zona limpa e zona selecionada). Nos próximos capítulos, ingeriremos dados na zona de aterrissagem e, em seguida, criaremos cópias transformadas desses dados nas outras zonas.

Benefícios do big data para corporações

Os benefícios do big data para corporações são diversos e incluem:

• Melhoria da experiência do cliente: O big data pode ser usado para personalizar o conteúdo e os serviços oferecidos aos clientes, de acordo com suas preferências e interesses individuais. Isso pode levar a uma experiência mais envolvente e satisfatória, que pode aumentar a fidelidade do cliente e as vendas.
• Maior eficiência operacional: O big data pode ser usado para identificar padrões e tendências nos dados, o que pode ajudar as corporações a melhorar a eficiência operacional. Por exemplo, o big data pode ser usado para otimizar as cadeias de suprimentos, reduzir custos e melhorar a segurança.
• Tomadas de decisão mais informadas: O big data pode ser usado para fornecer insights valiosos que podem ajudar as corporações a tomar decisões mais informadas. Por exemplo, o big data pode ser usado para prever tendências de mercado, identificar oportunidades de negócios e mitigar riscos.

Desafios do big data para corporações

Apesar dos benefícios, o big data também apresenta alguns desafios para corporações, incluindo:

• Complexidade: O big data pode ser complexo e desafiador de gerenciar. As corporações precisam de ferramentas e recursos adequados para coletar, armazenar, analisar e interpretar grandes quantidades de dados.
• Confiabilidade: Os dados usados para análise devem ser confiáveis e precisos. As corporações precisam implementar medidas de segurança para proteger seus dados e garantir sua integridade.
• Ética: O uso do big data levanta questões éticas, como a privacidade dos dados e a discriminação. As corporações precisam ser transparentes sobre como usam os dados e tomar medidas para proteger os direitos dos indivíduos.

Conclusão

O big data é um ativo poderoso que pode ser usado pelas corporações para alcançar uma série de objetivos. No entanto, é importante estar ciente dos desafios envolvidos no uso do big data para garantir que ele seja usado de forma responsável e ética.