Arquitetura Data Warehouse Vamos agora nos aprofundar como fica um desenho de arquitetura de solução completa de um Data Warehouse. Eu estou construindo esse diagrama há alguns anos, baseado na minha experiência, na minha vivência de projetos de Data Warehouse. Eu comentei com vocês na abertura do curso que eu atuei durante muito tempo como desenvolvedor de ETLs, que estão representadas aqui nesse diagrama como essas setas que apontam da esquerda para a direita. Então, os processos de extração, transformação e carga. Então, tive uma vivência muito ampla, muito extensa como desenvolvedor desse tipo de processo e também como modelador de dados. Então, eu modelei estruturas que estão aqui representadas em terceira forma normal, em forma dimensional, estruturas agregadas, estruturas derivadas, estruturas em star esquema predominantemente bancos de dados Oracle, Microsoft SQL Server e Sybase IQ, que é um banco com uma proposta relacional colunar. Ou seja, esta imagem representa toda a experiência que eu tive de implementação e de casos reais que eu atuei. Mas vamos navegar por partes. Primeiros pontos de destaque. Nós temos três elementos principais neste diagrama de arquitetura. Na esquerda, nós temos um pilar de origem de dados. Então, aqui nós vamos encontrar os OLTPs que estão rodando na organização. Então, você vai provavelmente encontrar um CRM, um ERP, sistemas financeiros, sistemas de logística, sistemas de recursos humanos e também é muito comum você se encontrar com determinadas áreas ou departamentos da organização que vão alimentar uma planilha ou uma extração de arquivo texto. Eu me deparei na minha carreira com diversos data houses de diferentes indústrias aqui no Brasil que além de carregar uma carga de dados que vinha do ERP também carregava uma planilha do financeiro da área de controladoria ou um arquivo txt que vinha da área de logística então como origem de dados vamos entender aqui dados predominantemente estruturados como nós vimos nos conceitos iniciais sobre o Data Warehouse, e eventualmente algum arquivo que também será estruturado. Um arquivo texto pode estar estruturado como separado por vírgulas, que é o CSV, ou separado por tabulação, que é o arquivo tab, o arquivo tabulado. Existe uma estrutura nesses arquivos que nada mais é do que uma tabela representada em arquivo texto diretamente. Vamos avançar agora para o meio do desenho, ocupando a maior parte da área desenhada, que é o Datware House. E aqui eu já quero diferenciar Data Warehouse de Data Warehousing com o ING no final. Então, o Data Warehouse é o artefato que é o nosso repositório de dados. Este Data Warehouse, frequentemente, é implementado em banco relacional. Eu, pessoalmente, implementei isso aqui em Oracle, em SQL Server e Sybase IQ, diferentes implementações, mas com estruturas muito similares. Uma curiosidade também, eu nunca encontrei um Data Warehouse igual ao outro. Sempre foram implementações extremamente personalizadas para cada caso de negócio. cada caso de negócio. O Data Warehousing no gerúndio do inglês, com esse ING no fundo, representa o processo, os processos de movimentação dos dados das nossas origens até as estruturas que estão fazendo toda a limpeza, curadoria e preparação dessa informação para a camada de visualização de dados, que está à direita, esse pilar à direita, onde nós temos os nossos processos de business intelligence, as nossas ferramentas de visualização da informação, os painéis gerenciais, os relatórios. Então, perceba que a visualização do Data Warehouse está à parte, é uma outra camada Visualização do Data House está à parte, é uma outra camada composta por uma ou mais ferramentas de interação e de visualização dos dados. Dentro do nosso Data House, vamos perceber também duas grandes estruturas. House tem um primeiro pilar que é o staging, que são os processos que vão copiar os dados das origens e gravar isso na área de staging, ou área de carga. Este artefato existe como propósito de fazer uma leitura extremamente rápida da origem da informação e ter uma cópia fiel dessas informações. Então, a stage é a maneira como um data warehouse realiza a cópia bruta das suas informações estruturadas dos sistemas de origem. Por que ter uma camada que é idêntica ao transacional? É porque no momento em que você está realizando a cópia, você, da Fairhouse, é mais um processo de leitura concorrendo com o que está acontecendo no ambiente transacional. Então, vamos recapitular que a característica principal do OLTP é ter tempos altíssimos de resposta para manipulação de pequenas quantidades de dados de maneira simultânea, em alto volume e com muita frequência. Ou seja, nós não queremos impactar um processo de negócio por conta de um centro de distribuição porque o ERP não conseguiu processar a liberação daquela mercadoria, daquela nota fiscal, porque o data warehouse estava sendo carregado. Então, a técnica de tentar mitigar o risco de uma parada no seu transacional por conta de uma leitura do data warehouse é fazer uma cópia direta. por conta de uma leitura do Data Warehouse, é fazer uma cópia direta. Então, como não existe nenhuma transformação acontecendo nesse primeiro conjunto de setas, aqui da esquerda para a direita, da origem de dados para a área de stage, este processo de extração acaba sendo mais rápido e é uma técnica amplamente empregada em data warehouses. Logo em seguida, mais à direita, nós vamos ter o que eu chamei aqui de data warehousing, os processos de data warehousing, que vão ler os dados brutos, que são exatamente como foram gerados na sua origem, e nós teremos agora dois elementos adicionais dentro dessa camada. O primeiro elemento que está ali no 3MF, terceira forma normal, é um elemento mais antigo, um elemento das primeiras versões da Ferhouse e que corresponde a um conceito do autor Bill Immon. Então, no livro do Bill Immon, nós vamos perceber que este autor sugere uma camada modelada em terceira forma normal que carrega todos os dados da organização. Então, vamos lembrar que o Dutcher House tem como propósito ler um ou mais sistemas, OLTP, sistemas transacionais, que estão realizando negócios dessa organização. Então, nesta proposta, a ideia é ter uma camada única que modela todos os conceitos. Então, por exemplo, clientes, com certeza existe esse conceito na área financeira, na área de vendas, na área de logística. Então, cada um desses sistemas tem a sua versão de cliente e provavelmente um cadastro de clientes diferente. Então, por essa razão, o Bill Wimmon propõe esta camada em terceira forma normal, que vai fazer esta consolidação de múltiplas origens. Logo em seguida, nós vamos ter a camada DNF, que é o Dimensional Normal Form, ou forma normal dimensional. Aqui nós temos o modelo em terceira forma normal admitindo uma denormalização para que os processos de leitura e agregação das informações sejam otimizados. Nós vamos falar muito sobre esquema estrela ou estare esquema ou também de constelação, que é um conjunto de esquemas estrela que compartilham entre si dimensões. Então, aqui nós temos uma técnica de modelagem. Modelagem dimensional de dados em um banco relacional vai corresponder a um conjunto de tabelas que estarão distribuídas entre dimensões e tabelas fato. entre dimensões e tabelas fato. As dimensões são cliente, produto, tempo, que o tempo pode estar interpretado como data de venda, data de entrega, data de estorno, data de devolução. Então, esses elementos são as dimensões. O que aconteceu, ou seja, a venda realiz realizada a devolução feita o cancelamento realizados são fatos e estes fatos geralmente terão números ou métricas associadas o valor vendido a quantidade de produtos vendida a a quantidade estornada, número de clientes com cancelamento. Então, esta organização que evolui um modelo de dados em terceira forma normal para um modelo de dados que organiza essa informação entre dimensão e fato é a modelagem dimensional de dados. dimensional de dados. Em um banco relacional, a estrela do esquema estrela é representada por uma tabela fato em seu centro e as tabelas de menções ao seu redor. Então, isso é o Star Schema. Adicionalmente, a gente pode conectar ferramentas de leitura otimizada desse Star Schema. Isso é uma abordagem também bastante inicial, para não dizer bastante antiga, mas que entrega bastante desempenho na hora da análise. Então, ferramentas como o Cognos Transformer vão ler dados do modelo estrela e vão otimizar essa leitura em algo que nós chamamos de cubo. otimizar essa leitura em algo que nós chamamos de cubo. Este cubo também é representado por uma estrela lá no relacional. Porém, ele já é preparado com uma série de derivações e cálculos que vai entregar uma experiência para o usuário final, que é o slice and dice, você fazer a customização da sua análise de dados. Além disso, nós podemos ter outros elementos no Data Warehouse, que são as tabelas derivadas, preparadas para uma determinada ação específica. Uma vez, eu participei de um projeto que fez toda a implementação do Star Schema, porém existia um requisito estatístico a ser feito. Então, nós modelamos uma tabela derivada que representava o data frame. Era uma tabela bastante longa, com muitas colunas, cuja cada linha representava um cliente. Então, a ideia daquele modelo era um cliente com diferentes atributos que representavam aquele cliente. atributos que representavam aquele cliente então esse tipo de de tabela modelada é uma tabela derivada o mesmo vai acontecer também com tabelas agregadas então pra facilitar para entregar uma uma sumarização mais rápida talvez você tenha dados de vendas minuto a minuto mas se alguém puxar um relatório das vendas mensais, imagina você varrer bilhões de registros para fazer essa sumarização. Então é muito comum também você montar um Star Schema na granularidade do mês e essa consolidação será feita ou à noite, num Datterhaus mais tradicional, ou de maneira contínua à medida em que novos dados são recebidos, no caso de um data house moderno. Um outro conceito importante para a gente mencionar aqui, que também vai aparecer com muita frequência, é o conceito do data mart. Então, pode surgir nas suas discussões o que é data House e o que é Data Mart. Então, o Data Mart é um silo de dados que foi organizado de uma certa maneira e que até mesmo apresenta um estar esquema, um modelo estrela. Mas vamos entender o Data Mart como uma unidade departamental, é uma fração dos dados da sua organização e que não necessariamente vai compartilhar os conceitos com as demais organizações. Então, as dimensões de um data mart, quando não são compartilhadas, na verdade você está obtendo esse data mart de forma isolada e de maneira como se fosse um silo de informação. formulada e de maneira como se fosse um estilo de informação nós vamos ter um segundo autor muito popular que é o ralph kimball e uma das definições que o ralph kimball nos traz é que um data house é o conjunto dos data martins de uma organização eu pessoalmente concordo com essa definição desde que nós tenhamos o compartilhamento das dimensões entre os diferentes fatos ou diferentes departamentos da organização. Então, falei de cliente, que é uma entidade extremamente comum da gente encontrar, a dimensão cliente vale para todo mundo da empresa. Vale para vendas, vale para suporte, vale para logística, vale para garantia. Então, quando a gente tem o compartilhamento das dimensões, o nosso modelo estrela se transforma em uma constelação. E isso, uma constelação de estrelas, também é um data warehouse. A partir do data warehouse, nós teremos a conexão de uma ou mais ferramentas de interesse das áreas de usuário terem conectividade. Então, teremos um conjunto de relatórios que pode ser conectado pelo Power BI, outro conjunto de relatórios que pode estar sendo acessado pelo My Strategy e até mesmo outros painéis ou outras formas de acesso de todo esse dado que foi preparado. No exemplo que eu comentei sobre a análise estatística, a ferramenta que conectava naquela tabela que nós modelamos cujo registro representa um cliente com todos os seus atributos, era uma ferramenta estatística que conectava em cima dela. Então, com isso, nós temos este primeiro contato com a arquitetura Data Warehouse. Temos três elementos principais. A origem dos dados, que é altamente estruturada. O Data Warehouse, que é um artefato que está quebrado em três grandes elementos. A área de stage, que é uma cópia dos dados originais e no seu formato bruto. Nos Dapper Houses mais tradicionais vai existir uma camada de terceira forma normal, proposta pelo Bill Eamon, e nos mais modernos você vai encontrar somente a forma dimensional proposta pelo Ralph Kimball. Se você está fazendo um Dapper House hoje, eu pessoalmente não recomendo você investir tempo na terceira forma normal, porque é uma forma que não é humanamente próxima do nosso raciocínio. A terceira forma normal exige sempre que seja uma pessoa que cursou essa disciplina de banco de dados, que se aprofundou em modelos de dados para ter uma compreensão. Já um modelo dimensional, por mais que possa parecer sofisticado e complexo quando a gente olha uma tabela fato no centro do modelo de dados e rodeada de tabelas de dimensão, pensar em dimensão e fato é algo mais intuitivo. Então, fica mais fácil a gente fazer uma análise de negócio e fazer um relatório em cima disso. Então, Data House é o repositório de dados, Staging e Data Housing, no gerúndio do inglês, são os processos que estão justamente movimentando as informações das origens e persistindo nessas camadas modeladas de maneira intermediária, mas pensando sempre na otimização de processo de leitura e de agregação da informação.