Data warehouse (DW), conhecido como armaz\u00e9m de dados em portugu\u00eas, \u00e9 um sistema na computa\u00e7\u00e3o usado para o armazenamento, consulta e an\u00e1lise de dados. Um DW \u00e9 um reposit\u00f3rio central para a integra\u00e7\u00e3o de dados de uma ou v\u00e1rias fontes, como sistemas transacionais, bancos de dados, arquivos e planilhas. Ele armazena dados hist\u00f3ricos e atuais em um \u00fanico local, permitindo que os usu\u00e1rios realizem an\u00e1lises complexas e obtenham insights valiosos sobre o neg\u00f3cio.<\/p>\n\n\n\n
Para contar a hist\u00f3ria do Data Warehouse, precisamos entender o cen\u00e1rio anterior ao seu desenvolvimento. Atualmente, contamos com dois tipos de bancos de dados: os transacionais e os anal\u00edticos. O banco de dados transacional \u00e9 respons\u00e1vel por armazenar toda a estrutura tecnol\u00f3gica e dados da empresa, incluindo os dados brutos e de suporte, enquanto o banco de dados anal\u00edtico oferece a estrutura tecnol\u00f3gica e de dados necess\u00e1ria para a realiza\u00e7\u00e3o de atividades de an\u00e1lise de dados.<\/p>\n\n\n\n
Na d\u00e9cada de 70 e 80, o \u00fanico tipo de banco de dados dispon\u00edvel era o transacional. Ele era usado simultaneamente para suporte aos servi\u00e7os e para an\u00e1lise e relat\u00f3rios, o que causava atrasos e problemas em ambas as \u00e1reas, afetando a efetividade dos servi\u00e7os e an\u00e1lises.<\/p>\n\n\n\n
O conceito de DW se originou no final dos anos 80, quando os pesquisadores da IBM Barry Devlin e Paul Murphy desenvolveram o que chamaram de business data warehouse, traduzido livremente como armaz\u00e9m de dados de neg\u00f3cios. O objetivo era criar um sistema em que os dados flu\u00edssem do sistema operacional at\u00e9 os setores dos tomadores de decis\u00e3o de forma fluida e integrada.<\/p>\n\n\n\n
O DW \u00e9, ent\u00e3o, focado principalmente em consultas e an\u00e1lises complexas, enquanto o banco de dados transacional \u00e9 respons\u00e1vel pela inser\u00e7\u00e3o, atualiza\u00e7\u00e3o e dele\u00e7\u00e3o de dados. Essa divis\u00e3o \u00e9 essencial para garantir a efetividade das an\u00e1lises do banco de dados anal\u00edtico e o bom funcionamento e seguran\u00e7a do banco de dados transacional.<\/p>\n\n\n\n
Entramos, ent\u00e3o, na \u00e1rea de arquitetura de dados, que \u00e9 respons\u00e1vel por implementar e gerenciar o DW. O arquiteto de dados possui conhecimentos sobre neg\u00f3cios e entende as necessidades da empresa e ser\u00e1 respons\u00e1vel por estudar os dados j\u00e1 existentes e decidir quais regras de neg\u00f3cio e informa\u00e7\u00f5es devem fazer parte do DW.<\/p>\n\n\n\n
A estrutura de um DW \u00e9 desenvolvida para possibilitar a consulta e an\u00e1lise eficiente dos dados armazenados. Assim, no momento da constru\u00e7\u00e3o de um DW, \u00e9 necess\u00e1rio saber para que os dados ser\u00e3o utilizados.<\/p>\n\n\n\n
No DW, utiliza-se a modelagem dimensional, na qual os dados s\u00e3o organizados em torno de t\u00f3picos ou assuntos. Existem dois modelos principais de modelagem dimensional: o Modelo Estrela (Star Schema) e o Modelo Floco de Neve (Snowflake Schema).<\/p>\n\n\n\n
Os dados passar\u00e3o por um processo chamado ETL ou ELT<\/a>, que \u00e9 a sigla em ingl\u00eas para o processo de Extrair, Transformar e Carregar dados.<\/p>\n\n\n\n Na extra\u00e7\u00e3o de dados, h\u00e1 a coleta de dados das fontes fornecidas, isso pode ser feito de forma manual ou automatizada, com a ajuda de ferramentas como a Kondado<\/a>. Os dados s\u00e3o ent\u00e3o transformados para atender as condi\u00e7\u00f5es do Data Warehouse. Essas necessidades podem incluir a limpeza de dados, a aplica\u00e7\u00e3o de regras de neg\u00f3cios, a convers\u00e3o de dados e a agrega\u00e7\u00e3o de dados. Essas transforma\u00e7\u00f5es podem ocorrer antes (ETL) ou depois (ELT) do carregamento dos dados no banco de dados.<\/p>\n\n\n\n O DW \u00e9 focado principalmente em consultas e an\u00e1lises complexas, o que traz diversas vantagens para as empresas. Com a implementa\u00e7\u00e3o do DW, a empresa pode armazenar seus dados provenientes de diferentes fontes em um \u00fanico local, facilitando a compreens\u00e3o dos dados e permitindo maior precis\u00e3o nas an\u00e1lises.<\/p>\n\n\n\n A empresa pode reduzir custos financeiros e de tempo associados \u00e0 extra\u00e7\u00e3o e transforma\u00e7\u00e3o de dados. A \u00e1rea de an\u00e1lise de dados pode se dedicar mais \u00e0s an\u00e1lises em si e menos tempo procurando, preparando e limpando os dados a serem analisados.<\/p>\n\n\n\n O DW pode ser acessado por v\u00e1rios usu\u00e1rios simultaneamente, auxiliando o processo de intera\u00e7\u00e3o entre setores. Al\u00e9m disso, com sua base de dados hist\u00f3ricos, o DW serve a outras \u00e1reas de dados, como a ci\u00eancia de dados<\/a>, permitindo \u00e0 empresa prever tend\u00eancias e comportamentos futuros.<\/p>\n\n\n\n Como um todo, o Data Warehouse ajuda a empresa na tomada de decis\u00f5es, seja pela an\u00e1lise de padr\u00f5es ou pelas proje\u00e7\u00f5es. <\/p>\n\n\n\n Um termo Tamb\u00e9m muito falado no neste universo de dados \u00e9 o Data Lake, e \u00e9 uma d\u00favida muito comum saber qual a diferen\u00e7a entre esse e o Data Warehouse.<\/p>\n\n\n\n O Data Lake, que na tradu\u00e7\u00e3o livre significa lago de dados, \u00e9 um reposit\u00f3rio centralizado de dados brutos, armazenados em sua forma original. Ou seja, no Data Lake, os dados n\u00e3o s\u00e3o tratados ou estruturados. Os dados podem vir nas mais diversas formas e de v\u00e1rias fontes, sem seguir uma regra definida. Neste momento, do recebimento dos dados, ainda n\u00e3o se sabe para que ser\u00e3o utilizados os dados.<\/p>\n\n\n\n Como no Data Lake os dados n\u00e3o s\u00e3o tratados, eles podem ser acessados pelos analistas ou cientistas de dados em sua forma original. Assim, o Data Lake tamb\u00e9m serve a um prop\u00f3sito, pois os analistas e cientistas podem necessitar destas informa\u00e7\u00f5es sem a limpeza e especifica\u00e7\u00f5es feitas pelo engenheiro de dados.<\/p>\n\n\n\n Os dados em um Data Lake podem ser usados imediatamente, em alguns meses, anos ou talvez nunca, tudo depender\u00e1 da necessidade dos profissionais da \u00e1rea. Por isso, os Data Lakes s\u00e3o geralmente constru\u00eddos com tecnologias de Big Data, como Hadoop, Spark, entre outras. Por essa raz\u00e3o, o Data Lake \u00e9 particularmente interessante para os cientistas de dados, que podem trabalhar com os dados em seu formato nativo e realizar an\u00e1lises em tempo real ou pr\u00f3ximas ao tempo real.<\/p>\n\n\n\n O Data Lake exige governan\u00e7a de dados e manuten\u00e7\u00e3o cont\u00ednua, para que n\u00e3o se torne, como diz o termo em ingl\u00eas, um “Data Swamp” (p\u00e2ntano de dados).<\/p>\n\n\n\n Para encerrar nosso artigo, \u00e9 interessante mencionar o Data Mart. O Data Mart \u00e9 um reposit\u00f3rio com o objetivo de atender equipes espec\u00edficas, como marketing, vendas, RH, entre outros, fornecendo apenas as informa\u00e7\u00f5es que essas \u00e1reas precisam. O Data Mart \u00e9 um subconjunto do Data Warehouse e cont\u00e9m apenas os dados relevantes para um determinado departamento, sendo criado a partir do Data Warehouse por meio da sele\u00e7\u00e3o e agrupamento de dados.<\/p>\n\n\n\n O processo de ETL (ou ELT) para centralizar dados em um Data Warehouse, Data Lake ou Data Mart pode ser bastante complexo, demandando horas de desenvolvimento, estudo de API, defini\u00e7\u00e3o de estrat\u00e9gia de replica\u00e7\u00e3o, entre outros aspectos importantes.<\/p>\n\n\n\n Por\u00e9m, esse processo pode ser facilitado com plataformas de integra\u00e7\u00e3o de dados, como a Kondado<\/a>, onde \u00e9 poss\u00edvel utilizar conectores pr\u00e9 constru\u00eddos de mais de 80 ferramentas<\/a>, e configurar integra\u00e7\u00f5es de dados com apenas alguns cliques.<\/p>\n\n\n\nQual a import\u00e2ncia do Data Warehouse dentro de um neg\u00f3cio?<\/h2>\n\n\n\n
Data Warehouse vs Data Lake<\/h2>\n\n\n\n
Data Mart<\/h2>\n\n\n\n
ETL ou ELT para um Data Warehouse, Data Lake ou Data Mart<\/h2>\n\n\n\n