Termos e Definições - Governança de Dados

Livro com termos e definições relacionados à gestão e governança de dados.

#Referências

Gestão de Dados

Dados precisam ser vistos como ativos críticos para o sucesso das atividades operacionais e administrativas do negócio, e não como meios temporários para alcançar resultados, ou mesmo como subprodutos de processos de negócio. Neste contexto, vale destacar que a despeito do nível de maturidade em gestão de dados de uma organização, dados e informações são vitais para as suas operações do dia-a-dia. Deste modo, independentemente se a organização consiga ou não obter valor a partir da análise de dados por meio de ferramentas de Business Intelligence, por exemplo, esta não conseguirá nem mesmo conduzir os seus negócios sem a utilização de dados (DAMA-DMBOK, 2017). 

De acordo com o DAMA-DMBOK (2017), gestão de dados consiste no desenvolvimento, execução e supervisão de planos, políticas, programas e práticas que entregam, controlam, protegem e aumentam o valor dos ativos de dados e informações ao longo de seus ciclos de vida. Ainda de acordo com o DAMA-DMBOK (2017), a gestão de dados visa a utilização adequada de dados e informações para o alcance dos objetivos estratégicos da organização. Logo, um profissional de gestão de dados é qualquer pessoa que trabalha com qualquer aspecto relacionado à gestão de dados (desde o gerenciamento técnico de dados ao longo de seu ciclo de vida, até a garantia de que os dados sejam utilizados e aproveitados adequadamente) para o alcance dos objetivos estratégicos organizacionais.

Diante do exposto, pode-se concluir que as atividades de gestão de dados são muito abrangentes, incluindo atividades que vão desde a capacidade de tomar decisões consistentes sobre como obter valor estratégico a partir dos dados até as atividades técnicas de implantação e gerência de desempenho dos bancos de dados. Deste modo, pode-se afirmar que a gestão de dados requer habilidades técnicas e não técnicas (ou seja, de negócios). Portanto, a responsabilidade pela gestão de dados deve ser compartilhada entre as funções de negócios e de TI, e as pessoas em ambas as áreas devem ser capazes de colaborar para garantir que uma organização tenha dados de alta qualidade que atendam às suas necessidades estratégicas.

No intuito de prover suporte aos profissionais que atuam na gestão de dados, em 2017, a associação DAMA International (The Data Management Association) -- organização sem fins lucrativos, dedicada ao desenvolvimento de padrões internacionais para profissionais de gestão de dados -- publicou a segunda edição do livro Data Management Body of Knowledge (DMBOK). Este livro é constituído por diversos conceitos importantes sobre gestão de dados e apresenta o framework DAMA Data Management Framework, que fornece o contexto para o trabalho realizado por profissionais de gestão de dados em várias Áreas de Conhecimento. As Áreas de Conhecimento que compõem o escopo geral da gestão de dados são apresentadas pela Figura 1.

image-1648049751544.png

Figura 1: DAMA-DMBOK2 Data Management Framework (The DAMA Wheel) -- Framework de Gestão de Dados DAMA-DMBOK2. Fonte: (DAMA-DMBOK, 2017).

A Figura 1, apelidada pelo DAMA-DMBOK (2017) de The Dama Wheel, apresenta as Áreas de Conhecimento envolvidas na gestão de dados. A área Governança de Dados está posicionada no centro das áreas de gerenciamento de dados, uma vez que a governança é necessária para a consistência e o equilíbrio entre as demais áreas. Todas as Áreas de Conhecimento dispostas na Figura 1 são partes necessárias para uma gestão de dados madura, porém elas podem ser implementadas em momentos diferentes, a depender dos requisitos organizacionais.

O DMBOK é estruturado sobre as 11 Áreas de Conhecimento do framework de gestão de dados ilustrado pela Figura 1. Cada uma das áreas descreve o escopo e o contexto de um conjunto de atividades de gerenciamento de dados, embutindo princípios e objetivos da gestão de dados. As atividades das Áreas de Conhecimento possuem interseção tanto umas com as outras quanto com outras funções organizacionais, visto que os dados movem-se horizontalmente dentro das organizações. O DMBOK (DAMA-DMBOK, 2017) detalha, em capítulos próprios, cada uma das Áreas de Conhecimento, descritas brevemente abaixo:

Em complementação aos capítulos relativos às Áreas de Conhecimento, o DMBOK possui capítulos específicos para os seguintes tópicos:

Governança de Dados

O DMBOK (DAMA-DMBOK, 2017) define Governança de Dados (GD) como a execução de autoridade, controle e tomada de decisão compartilhada (planejamento, monitoramento e fiscalização) sobre o gerenciamento de ativos de dados, com os seguintes objetivos:

Neste mesmo sentido, Barbieri (2019) define Governança de Dados como um conjunto de práticas, dispostas em um framework, com o objetivo de organizar o uso e o controle adequado dos dados como um ativo organizacional. 

O DAMA-DMBOK (2017) afirma que dados e informações são ativos, visto que são ou podem criar valor para a organização. No entanto, ao mesmo tempo que podem cirar valor, trazem riscos (vazamentos de dados, tomadas de decisões erradas devido a problemas de interpretação ou inconsistências, etc.). O DAMA-DMBOK (2017) complementa que governar dados exige um programa contínuo focado em assegurar que a organização obtenha valor a partir dos seus dados, minimizando os riscos associados aos mesmos. Neste sentido, a Governança de Dados fornece princípios, políticas, procedimentos, estrutura operacional, métricas e vigilância.

A Governança de Dados fornece a orientação e o contexto de negócios necessários para que as atividades de gerenciamento de dados estejam alinhadas com os objetivos organizacionais, de modo que a organização obtenha valor a partir dos seus dados.

Relação entre Governanças

A Governança de Dados surgiu a partir do termo raiz “Governança”, extraído do contexto maior “Governança Corporativa”. A Governança de Dados tangencia pontos da Governança de TI, focando em princípios de organização e controle sobre os insumos de dados, essenciais para a produção de informação e conhecimento (BARBIERI, 2019).

De acordo com Barbieri (2019), os dados não podem mais ficar restritos à esfera da tecnologia da informação, mas sim, devem ser considerados insumos de negócio, um ativo organizacional. Para tal, as organizações devem definir objetivos organizacionais e processos institucionalizados, que devem ser implementados dentro de um equilíbrio fundamental entre tecnologia da informação e área de negócios. A Figura 1 ilustra as relações entre Governança Corporativa, Governança de Dados e Governança de TI.

image-1647454448524.png

Figura 1: Relações entre Governança Corporativa, Governança de Dados e Governança de TI. Fonte: Adaptado de BARBIERI (2019).

Frameworks para Definição dos Componentes da Governança de Dados

Alguns frameworks sugerem o conceito e a forma de implementação da Governança de Dados em uma organização. Barbieri (2019) destaca os seguintes: (a) Framework de Governança de Dados - 5W2H; (b) Framework de Governança de Dados - IBM; (c) EDM (Enterprise Data Management Council) e DCAM (Data Management Capacity Assessment Model); (d) Modelo Data Management Maturity (DMM) do CMMI institute; e (f) Gestão, Governança e Gerência de Dados: DAMA DMBOk V2.

Segundo Barbieri (2019), todos os frameworks supracitados mostram alguns caminhos comuns, mas, o DAMA DMBOK V2 mostra-se acima dos demais. Sendo, portanto, a referência mais indicada na implementação e execução de programas de gestão e Governança de Dados.

Foco e Escopo

O foco e o escopo de um programa de GD depende das necessidades de cada organização, mas a maioria dos programas incluem (DAMA-DMBOK, 2017):

Para comprir tais objetivos, um programa de Governança de Dados precisará desenvolver políticas e procedimentos, cultivar práticas de administração de dados (stewardship) em diferentes níveis da organização, e envolver-se em esforços de gerenciamento de mudanças organizacionais que comunicam ativamente à organização os benefícios da GD aprimorada e os comportamentos necessários para gerenciar, com sucesso, os dados como um ativo.

É importante destacar que a Governança de Dados não é um fim em si mesma. Ela precisa alinhar-se diretamente às estratégias organizacionais. Quanto mais claramente a GD auxiliar na resolução dos problemas organizacionais, maior a probabilidade das pessoas mudarem comportamentos e adotarem práticas de governança.

Assim como um auditor controla processos financeiros mas não executa a gestão financeira, a Governança de Dados deve garantir que os dados sejam gerenciados adequadamente sem executar diretamente o gerenciamento (Figura 2). Deste modo, a Governança de Dados representa uma separação inerente de dever entre a supervisão e a execução.

image-1648216231647.pngFigura 2: Governança de Dados e Gerenciamento de Dados. Fonte: (DAMA-DMBOK, 2017)

 

No framework de Gestão de Dados DAMA-DMBOK2 (Figura 3), a Governança de Dados está posicionada no centro das demais Áreas de Conhecimento, trazendo consistência e equilíbrio entre as áreas por meio do supervisionamento e do direcionamento das atividades de gerenciamento de dados. Deste modo, a responsabilidade sobre a GD é compartilhada entre os administradores de dados de negócios (business data stewards) e a área técnica de gerenciamento de dados (DAMA-DMBOK, 2017).

image-1648216337353.png

Figura 3: DAMA-DMBOK2 Data Management Framework (The DAMA Wheel) -- Framework de Gestão de Dados DAMA-DMBOK2. Fonte: (DAMA-DMBOK, 2017).

A Governança de Dados, além de ser uma área de conhecimento, reside também dentro de cada outra área de conhecimento, com olhar específico de controle sobre aquela gerência. Por exemplo, dentro da área de conhecimento Integração e Interoperabilidade de Dados (Data Integration & Interoperability), a Governança de Dados deverá estender sua visão para acordos de compartilhamento de dados, linhagem de dados e métricas de integração (BARBIERI, 2019).

Cultura Organizacional

As organizações se esforçam cada vez mais para tornarem-se orientadas por dados (data-driven), considerando proativamente os requisitos de dados como parte do desenvolvimento de estratégias, planejamento de programas e implementação de tecnologias. No entanto, fazer isso muitas vezes envolve desafios culturais significativos. Conforme afirmado no DAMA-DMBOK (2017), a cultura de uma organização pode inviabilizar qualquer estratégia de dados. Deste modo, os esforços de Governança de Dados precisam incluir um componente de mudança cultural, apoiado por uma liderança forte.

Neste sentido, o DAMA-DMBOK (2017) afirma que, para a maioria das organizações, a mudança cultural é o maior desafio para o sucesso de programas de gestão e governança de dados. Considerando que um dos princípios fundamentais da gestão de mudanças é que a mudança organizacional exige mudança individual, e que programas de gestão e governança de dados exigem mudança cultural, o gerenciamento formal de mudanças torna-se necessário para o sucesso destes programas.

Ferramentas

O DAMA-DMBOK (2017) afirma que a Governança de Dados é fundamentalmente sobre o comportamento organizacional. Ou seja, este não é um problema que pode ser solucionado apenas com tecnologia. Deste modo, antes de escolher uma ferramenta para uma função específica, como por exemplo uma solução tecnológica para gerenciamento do glossário de negócios -- ferramenta central na Governança de Dados --, a organização precisa definir suas metas e requisitos gerais de governança, com o objetivo de estabelecer o seu conjunto de ferramentas. Estas ferramentas devem ser avaliadas em suas capacidades e funcionalidades, no intuito de evitar sobreposição indesejada de funcionalidades e recursos. Algo que pode trazer desorganização e interferir negativamente  no processo de implantação do programa de GD.

Implementação e Estabelecimento

De acordo com Barbieri (2019), uma das principais ações para a implementação da Governança de Dados constitui a definição formal de uma estrutura corporativa, composta por elementos de negócios e de TI, regida por políticas amplas de dados. Deve-se buscar constantemente a conscientização organizacional de que dados não devem mais ser vistos como produtos colaterais da execução de processos.

O processo de implementação da Governança de Dados não é trivial, diante disso, Barbieri (2019) sugere buscar modificações culturais gradativas, de modo a alcançar patamares crescentes de maturidade. Uma das formas mais comuns de adoção da GD é por meio de projetos especiais de dados (projeto estruturante, de extrema importância organizacional). Projetos de Business Intelligence, de qualidade, Gerência de Dados Mestres e LGPD estão entre os tipos mais usuais de projetos com esta finalidade. Tais projetos, cada vez mais, percebem que de nada adianta o investimento em novas plataformas de dados, caso estes não estejam devidamente “governandos”.

Neste mesmo sentido, o DAMA-DMBOK (2017) afirma que a Governança de Dados deve ser implementada de modo incremental, dentro de um contexto estratégico maior de negócios e gestão de dados. Portanto, os objetivos globais devem ser mantidos em evidência enquanto as peças da GD são colocadas no lugar.

Barbieri (2019) salienta que dados "governados" não significa apenas a resolução física de duplicatas ou de conflitos de hierarquias semânticas, por exemplo, mas também a definição clara dos papéis de administradores de dados (data stewards) e de responsáveis pelos dados (data owners), que serão as referências responsáveis por aquele ativo específico dentro do contexto organizacional. Tudo isso orientado por políticas, padrões e processos, definidos e aprovados sob uma estrutura de governança.

 

Glossário de Negócios

Um glossário de negócios é um tipo de dicionário que busca garantir coerência e consistência semântica na organização, contendo termos e definições padronizados e organizados, relativos aos dados geridos na organização. É uma ferramenta central na Governança de Dados (DAMA-DMBOK, 2017).

O desenvolvimento de uma documentação padronizada para os dados reduz a ambiguidade e melhora a comunicação. Para tanto, as definições devem ser claras, rigorosas, e explicar quaisquer exceções, sinônimos e variações.

De acordo com o DAMA-DMBOK (2017), um glossário é necessário pois as pessoas utilizam palavras de forma diferente. Sendo particularmente importante que dados possuam definições claras, pois estes representam coisas além dele mesmo. Pode-se adicionar que muitas organizações desenvolvem o seu próprio vocabulário, podendo ressignificar conceitos utilizados em outras áreas e organizações.

Ainda de acordo com o DAMA-DMBOK (2017), um glossário de negócios não deve ser meramente uma lista de termos e definições. Cada termo deve ser associado, quando aplicável, a metadados importantes para a sua compreensão e manutenção, tais como: sinônimos, exceções, métricas, área responsável, etc.

Um glossário de negócios possui os seguintes objetivos (DAMA-DMBOK, 2017):

O Glossário de Negócios da UFLA pode ser acessado a partir da seguinte URL: https://glossario.ufla.br/.

Gerência de Dados Mestres e de Referência

Em qualquer organização, certos dados são comuns entre diferentes áreas de negócio, processos e sistemas. O compartilhamento de dados comuns (ex: lista de servidores; lista de alunos; lista de cursos; centros de custo; códigos de localização geográfica; etc) dentre as unidades de negócio é algo que beneficia tanto a organização quanto os seus clientes, visto que minimiza os riscos de inconsistências. Usuários de dados geralmente assumem a existência de um certo nível de consistência, até que se deparam com divergências entre fontes distintas  (DAMA-DMBOK, 2017).

Na maioria das organizações, os sistemas evoluem de forma mais orgânica do que os profissionais de gerenciamento de dados gostariam. Particularmente em grandes organizações, vários projetos e iniciativas, fusões e aquisições e outras atividades de negócios resultam em vários sistemas executando essencialmente as mesmas funções, isolados uns dos outros. Essas condições inevitavelmente levam a inconsistências na estrutura de dados e valores de dados entre sistemas. Essa variabilidade aumenta os custos e os riscos, que podem ser reduzidos através da Gerência de Dados Mestres e Dados de Referência  (DAMA-DMBOK, 2017).

Dados de Referência

Dados de Referência, ou Dados Referenciais, são qualquer dado utilizado para caracterizar ou classificar outro dado, ou para relacionar dados com informações externas à organização. Os Dados de Referência mais básicos consistem em códigos e descrições, mas alguns podem ser mais complexos e incorporar mapeamentos e hierarquias. Dados de referência existem em praticamente todos os armazenamentos de dados. Classificações e categorias podem incluir status ou tipos (por exemplo, Status do pedido: Novo, Em andamento, Fechado, Cancelado)  (DAMA-DMBOK, 2017).

De acordo com Barbieri (2019), Dados Referenciais são atributos, normalmente associados aos Dados Mestres e que merecem pela sua volatilidade uma certa gerência especial. Por exemplo: CEP (atributo de endereço de alguém ou de alguma coisa), Código Internacional de Doenças (atributo fundamental do Dado Mestre Doenças em um ambiente de sistemas de saúde, por exemplo). São normalmente obtidos de fontes externas definidas por entidades oficiais (CID, CEP, código de aeroportos, códigos de cidades, de estados, de países, etc.), mas podem ser produzidos internamente, de acordo com o negócio da empresa/organização. Têm forte associação com os Dados Mestres, na maioria das vezes, codificando algumas de suas propriedades.

Dados de Referência e Dados Mestre compartilham propósitos conceitualmente semelhantes. Ambos fornecem contexto para a criação e uso de dados transacionais (Dados de Referência também fornecem contexto para Dados Mestres). Eles permitem que os dados sejam compreendidos de forma significativa.

O objetivo da Gerência de Dados de Referência (Reference Data Management - RDM) é garantir que os Dados de Referência sejam consistentes e atuais em diferentes funções e que os dados sejam acessíveis à toda a organização.

Dados Mestres

Segundo a definição do Gartner (2022), Dados Mestres pode ser definido como um conjunto consistente e uniforme de identificadores e atributos que descrevem as principais entidades da organização, como por exemplo: alunos, cursos, colaboradores, estrutura administrativa, fornecedores, hierarquias, planos de conta, etc.

De acordo com Barbieri (2019) Dados Mestres são os dados base ou pilares da instituição. Os Dados Mestres tendem a ser mais estáveis e não muito relacionados com o tempo e sustentam as grandes transações institucionais. São chamados dados de fundação (foundational) e através deles são produzidos os dados transacionais. Por exemplo, um cliente do WalMart compra produtos em uma loja. Veja que há três dados mestres (produto, loja e cliente) se relacionando em um ato de Compra, que é um dado transacional.

Dados Mestres exigem a identificação e/ou desenvolvimento de uma versão confiável da verdade para cada instância de entidade conceitual, como aluno, curso, undiade organizacional, pessoa ou organização, e a manutenção da validade dessa versão. O principal desafio é a resolução de entidade, o processo de discernir e gerenciar associações entre dados de diferentes sistemas e processos.

A Gerência de Dados Mestres (Master Data Management - MDM) reduz os riscos de tomada de decisão incorreta e perda de oportunidades por meio de uma representação consistente das entidades críticas para o negócio da organização  (DAMA-DMBOK, 2017).

Gerência de Dados Mestres

A Gerência de Dados Mestres (Master Data Management - MDM) envolve o controle sobre valores e identificadores de Dados Mestres de modo a permitir o uso consistente entre os sistemas, dos dados mais precisos e atualizados sobre as entidades essenciais para o negócio  (DAMA-DMBOK, 2017).

De acordo com o Gartner (2022), Gerência de Dados Mestres é uma disciplina na qual a área de negócios e a área de TI trabalham juntas para garantir uniformidade, precisão, administração (stewardship), consistência semântica e responsabilidade (accountability) dos ativos de Dados Mestres compartilhados da organização.

DAMA (2017) menciona que, infelizmente, o acrônimo MDM é muitas vezes referenciado como sistemas ou produtos utilizados para gerenciar Dados Mestres. Embora existam aplicações que facilitem esta gerência, elas não garantem que os Dados Mestres serão gerenciados de modo a atender as necessidades organizacionais.

A avaliação dos requisitos de MDM de uma organização inclui identificar DAMA-DMBOK (2017) :

DAMA-DMBOK (2017) complementa que a Gerência de Dados Mestres é desafiadora, e ilustra um desafio fundamental: “as pessoas escolhem maneiras diferentes de representar conceitos semelhantes e a reconciliação entre essas representações nem sempre é direta; tão importante quanto, as informações mudam ao longo do tempo e contabilizar sistematicamente essas mudanças requer planejamento, conhecimento sobre os dados e habilidades técnicas. Resumindo, é muito trabalhoso.“

Uma organização que percebe a necessidade da Gerência de Dados Mestres provavelmente já possui um arcabouço complexo de sistemas, com múltiplas formas de captura e armazenamento de dados que representam entidades do mundo real. Devido ao crescimento orgânico ao longo do tempo, ou fusões e aquisições, os sistemas que forneceram entrada para o processo de MDM podem ter definições diferentes das próprias entidades e muito provavelmente possuem padrões diferentes sobre a definição de qualidade de dados. Devido a essa complexidade, é recomendado abordar a Gerência de Dados Mestres um domínio de negócios por vez. Ou seja, comece com algumas entidades e atributos e evolua com o tempo, de modo incremental.

Dentre as atividades críticas para o sucesso da Gerência de Dados Mestres mencionadas por DAMA-DMBOK (2017), destaco:

A Figura 1 apresenta as principais etapas de processamento necessárias para a Gerência de Dados Mestres (MDM). Inclui as etapas de gerência do modelo de dados; aquisição de dados; validação padronização e enriquecimento de dados; resolução de entidades; e administração e compartilhamento de dados. Em um ambiente abrangente de MDM, o modelo de dados lógicos será instanciado fisicamente em várias plataformas. Este modelo orienta a implementação da solução de MDM, fornecendo a base para os serviços de integração.

image-1647614127760.png

Figura 1: Processos-chave de etapas para a Gerência de Dados Mestres. Fonte: DAMA-DMBOK (2017)

Note que as etapas da Figura 1 são condizentes com as etapas que ocorrem em uma solução de Data Warehouse / Business Intelligence, da modelagem ao compartilhamento e visualização de dados.

Sistema de Registro e Sistema de Referência

Quando existem versões potencialmente diferentes da “verdade”, é necessário distingui-las. Para isso, é preciso saber de onde os dados se originam ou são acessados e quais dados foram preparados para usos específicos. Um Sistema de Registro é um sistema onde os dados são criados/capturados e/ou mantidos por meio de um conjunto definido de regras (por exemplo, um sistema ERP pode ser o Sistema de Registro para clientes de venda). Um Sistema de Referência é um sistema onde os consumidores de dados podem obter dados confiáveis para apoiar transações e análises, mesmo que a informação não tenha origem no sistema de referência. Sistemas MDM, Data Hubs e Data Warehouses geralmente servem como sistemas de referência  (DAMA-DMBOK, 2017).

Fonte confiável

Uma fonte confiável (Trusted Source) pode ser definida como uma fonte com “a versão mais precisa da verdade”, baseada na combinação de regras automatizadas e gerência manual (stewardship) do conteúdo dos dados. Todo sistema de MDM/RDM deve ser gerido para ser esta fonte confiável institucional  (DAMA-DMBOK, 2017).

 

Business Intelligence

Business Intelligence (BI), ou Inteligência de Negócios é um termo abrangente que pode ser definido como um conjunto de sistemas e processos que uma organização utiliza para recuperar, processar e analisar informações para suporte à tomada de decisão (KIMBALL e ROSS, 2013).

De acordo com a Microsoft (2022), soluções de BI auxiliam organizações na análise de dados históricos e correntes, de modo a possibilitar a descoberta de insights acionáveis para a tomada de decisão estratégica. Ainda segundo a Microsoft (2022), ferramentas de BI tornam isso possível devido ao processamento de conjuntos de dados provenientes de múltiplas fontes, apresentando as descobertas em formatos visuais fáceis de entender e compartilhar.

Neste mesmo sentido, Tableau (2022) afirma que BI combina análise de negócios (business analytics), mineração de dados, visualização de dados, ferramentas e infraestrutura de dados e práticas recomendadas para ajudar as organizações a tomar decisões impulsionadas por dados.

Ainda no contexto de BI, Gartner (2022) afirma que Plataformas de BI habilitam organizações a construírem aplicações de BI por meio do provimento de capacidades em três categorias: análises, como por exemplo Online Analytical Processing (OLAP); entrega de informações, como relatórios e dashboards; e integração de plataforma, como a gestão de metadados de BI e um ambiente de desenvolvimento.

De acordo com as definições apresentadas, pode-se observar que o termo BI é abrangente, podendo abarcar diferentes tipos de iniciativas, das mais simples, como por exemplo a utilização de ferramentas de visualização de dados e planilhas eletrônicas para extrair e analisar dados armazenados em sistemas transacionais ou em planilhas, às mais complexas, que podem envolver a construção de Data Warehouses, Data Marts e Data Lakes.

De acordo com Kimball e Ross (2013), a construção de um Data Warehouse capaz de integrar toda a instituição é fundamental para a governança de dados. A ausência de um DW institucional como plataforma de BI, alinhado à uma boa governança de dados, leva à perpetuação de silos de dados similares entre departamentos, mas com versões da verdade ligeiramente diferentes (KIMBALL e ROSS, 2013).

Data Warehouse

Data Warehouse (DW) consiste em um sistema para armazenamento de dados originados de múltiplas fontes, especialmente estruturados para consulta e análise. Um DW busca a criação de uma fonte de dados padronizada, confiável e de acesso simplificado, para apoio à tomada de decisão (Kimball e Ross, 2013).

De acordo com o DAMA (2017), um DW é a combinação de dois componentes principais: (a) um banco de dados integrado para apoio à tomada de decisão e (b) o conjunto de softwares relacionados, utilizados para coletar, limpar, transformar e armazenar os dados a partir de várias fontes de origem.

De acordo com Anand (2019), Data Warehouse pode ser considerado um modelo arquitetônico para armazenamento de dados estruturados. Não sendo portanto uma tecnologia em especial.

Segundo Inmon (2005), um DW consiste em uma coleção de dados orientados por assunto, integrados, não voláteis e variantes no tempo, com o intuito de prover suporte à tomada de decisão. Na arquitetura de DW proposta por Inmon (2005), a não volatilidade de um DW deve ser garantida por meio do que é chamado pelo autor de snapshots. De acordo com Inmon (2005), uma vez inserido em um DW, o dado não poderá mais ser atualizado. No entanto, em seu próprio livro, são demonstradas algumas opções de alteração de dados históricos, como por exemplo, a correção de um valor incorrento de saldo bancário histórico de cliente. Este aspecto de não volatilidade absoluta conflita com a proposta de arquitetura de Data Warehouse de Kimball e Ross (2013). Na aquitetura de Kimball e Ross (2013), a manutenção da história em um DW é feita por meio da técnica Slowly Changing Dimensios (SCDs). Esta técnica assume a possibilidade de modificação de dados históricos em um modelo dimensional, possibilitando este controle a nível de atributos.

De acordo com Khine e Wang (2018), um Data Warehouse ser não volátil significa que os dados permanecem inalterados entre as cargas de dados. Diferenciando-se dos dados transacionais de sistemas que podem ser alterados a todo instante.

Existem diversas abordagens para a construção de Data Warehouses. Kimball e Ross (2013) propõem uma abordagem de construção de um DW que integre toda a organização (Enterprise Data Warehouse - EDW). De acordo com os autores, a construção deste tipo de DW é fundamental para a governança de dados. Ainda de acordo com Kimball e Ross (2013), a ausência de um DW institucional como plataforma de BI, alinhado à uma boa governança de dados, leva à perpetuação de silos de dados similares entre departamentos, mas com versões da verdade ligeiramente diferentes.

A UFLA utiliza a arquitetura de Enterprise Data Warehouse proposta por Kimball e Ross (2013). Esta escolha deve-se ao fato desta ser uma arquitetura já consolidada, amplamente aceita e utilizada no mercado.

O EDW é construído com a técnica denominada Modelagem Dimensional, que, segundo Kimball e Ross (2013), trata-se de uma abordagem amplamente aceita para consolidação de dados analíticos por abordar dois requisitos de forma simultânea:

Kimball e Ross (2013) mencionam ainda as seguintes técnicas existentes para a construção de Data Warehouses:

Kimball e Ross (2013) demonstram que as abordagens mencionadas acima possuem grandes desvantagens em comparação à abordagem de EDW com Modelagem Dimensional. Para mais detalhes sobre essas desvantagens consulte as páginas 26, 27, 28, 29 e 30 (KIMBALL e ROSS, 2013).

Um EDW considera os seguintes princípios para a sua construção:

A Figura abaixo apresenta os elementos chave para a arquitetura Kimball de DW/BI (KIMBALL e ROSS, 2013):

image-1646668045868.png

De acordo com Khine e Wang (2018), como um Data Warehouse possui uma estrutura fixa, com processos de extração, transformação e carga de dados muito bem definidos, este possui um aspecto forte de gestão de governança de dados.

 

Data Warehousing

De acordo com o DAMA (2017), Data Warehousing refere-se aos processos operacionais de extração, limpeza, transformação, controle e carregamento que mantêm os dados em um Data Warehouse. O processo de Data Warehousing concentra-se em possibilitar a manutenção de um histórico de contexto de negócios, por meio da aplicação de regras de negócios e manutenção dos relacionamentos apropriados dos dados de negócio. O processo de Data Warehousing ainda inclui atividades para gestão de repositórios de metadados.

Ainda de acorodo com o DAMA (2017), tradicionalmente, Data Warehousing concentra-se em dados estruturados. No entanto, com os recentes avanços tecnológicos, o espaço de BI e DW agora também abrange dados semiestruturados e não estruturados.

Data Mart

Um Data Mart é um subconjunto completo de um Data Warehouse, e, assim como este, deve possuir os dados armazenados em seu formato mais granular (KIMBALL e ROSS, 2010).

Data Marts são muitas vezes construídos devido à impossibilidade de se construir de uma única vez, um Data Warehouse (DW) capaz de atender a toda a organização (Kimball e Ross, 2010). Como demonstrado por Kimball e Ross (2013), uma arquitetura de barramento (Enterprise Data Warehouse Bus Architecture) permite a construção incremental de DW que atenda a toda a organização (Enterprise Data Warehouse - EDW).

Embora possa-se buscar a construção de um EDW a partir de um conjunto de Data Marts, por meio da utilização da Modelagem Dimensional e dimensões conformadas (cópias fiéis e atualizadas de dimensões comuns) entre os diferentes Data Marts, esta arquitetura não estará totalmente de acordo com o conceito de EDW de Kimball e Ross (2013), devido a um dos princípios centrais desta arquitetura: a construção do EDW deve ser orientada a processos de negócio, não a departamentos ou setores.

Big Data

De acordo com Salinas e Lemus (2017), o termo Big Data foi criado em 1997 por Michael Cox e David Ellsworth, pesquisadores da NASA que tinham que trabalhar com conjuntos de dados geralmente muito grandes, o que sobrecarregava a memória principal, disco local e capacidade de disco remoto. Eles chamaram isso de problema do Big Data.

Apesar de ser amplamente referenciado, Big Data não tem uma definição rigorosa e consensual. Geralmente está associado ao tratamento de dados massivos, extraídos de diferentes fontes e sem estruturas pré-definidas (SALINAS e LEMUS, 2017). De acordo com Gandomi e Haider (2015), cerca de 95% dos dados tratados por tecnologias de Big Data são dados não estruturados.

Para alguns autores, Big Data nada mais é do que um conjunto de dados cujo tamanho está além das ferramentas típicas de bancos de dados para capturar, armazenar, gerenciar e analisar (SALINAS e LEMUS, 2017). De acordo com SAS (2022), big data refere-se a conjuntos de dados tão grandes, rápidos ou complexos que são difíceis ou impossíveis de processar usando métodos tradicionais. O ato de acessar e armazenar grandes quantidades de informações para análise existe há muito tempo. Mas o conceito de big data ganhou força no início dos anos 2000.

Para Anand (2019), Big data é uma tecnologia utilizada para armazenar dados, tanto em formatos não estruturados quanto semi estruturados e estruturados, utilizando dispositivos de armazenamento mais baratos. Para agilizar o processamento, este é feito de forma descentralizada e distribuída por múltiplos servidores. Os dados são armazenados em formato nativo, sem um esquema ou modelagem definida.

Segundo Oussous et al. (2018) o termo big data refere-se a grandes conjuntos de dados, em constante crescimento, que incluem formatos heterogêneos de dados estruturados, não estruturados e semiestruturados. Big data possui natureza complexa e exige tecnologias sofisticadas e algoritmos avançados. Neste novo contexto, ferramentas tradicionais de Business Intelligence mostram-se ineficientes para aplicações de big data.

Muitos experts e cientistas de dados definem big data pelas seguintes características principais (chamadas 3 Vs) (OUSSOUS et al., 2018) (GANDOMI e HAIDER, 2015):

De acordo com Gandomi e haider (2015), além dos três Vs principais, as seguintes novas dimensões foram também mencionadas como características inerentes ao Big Data:

Desafios

Embora a mineração de big data ofereça oportunidades atrativas, pesquisadores e profissionais têm se deparado com diversos desafios ao tentarem extrair valor e conhecimento a partir desta mina de informações. As dificuldades estão em diferentes níveis, incluindo: captura de dados, armazenamento, busca, compartilhamento, análise, gerenciamento e visualização. Além disso, há problemas de segurança e privacidade, especialmente em aplicativos orientados a dados distribuídos (OUSSOUS et al., 2018).

Apesar de novas tecnologias terem sido desenvolvidas para o armazenamento de dados, os volumes de dados estão dobrando em tamanho a cada dois anos. As empresas ainda se esforçam para acompanhar a evolução de seus dados e encontrar maneiras de armazená-los com eficiência (ORACLE, 2022).

De acordo com a Oracle (2022), apenas armazenar os dados não é o suficiente. Eles devem ser usados para serem úteis, e isso depende de curadoria. Dados limpos ou relevantes para o cliente e organizados de maneira que permita uma análise significativa exigem muito trabalho. Ainda de acordo com a Oracle (2022), cientistas de dados gastam até 80 por cento de seu tempo fazendo a curadoria e preparação dos dados antes que estes possam ser utilizados.

Por fim, nota-se que a tecnologia de big data está mudando em ritmo acelerado. Há alguns anos, o Apache Hadoop era a tecnologia popular para esta finalidade. Em seguida, o Apache Spark foi introduzido em 2014. Hoje, uma combinação das duas estruturas parece ser a melhor abordagem. Manter-se atualizado com a tecnologia de big data é um desafio contínuo (ORACLE, 2022).

 

Tecnologias de Big Data

Os sistemas de Data Warehouse são tradicionalmente suportados por modelos multidimensionais predefinidos, tendo o intuito de prover suporte a aplicações de Business Intelligence. Tais modelos são geralmente implementados sobre bancos de dados relacionais e geridos por meio da linguagem SQL (Structured Query Language) (SALINAS e LEMUS, 2017). Embora SGBDs relacionais possam gerenciar grandes quantidades de informações, estes possuem certas limitações de escalabilidade horizontal, o que não ocorre com soluções de Big Data (MONGODB, 2022; SALINAS e LEMUS, 2017). A resposta às novas necessidades é a utilização de memória extensiva, distribuição de dados e paralelização de processamento, que de uma forma ou de outra estão incluídos no Apache Hadoop, Apache Spark, bases de dados NoSQL e tecnologias complementares a estas (SALINAS e LEMUS, 2017).

Apache Hadoop

O Apache Hadoop é um framework de código aberto usado para armazenar e processar com eficiência grandes conjuntos de dados que variam em tamanho de gigabytes a petabytes. Em vez de usar um grande computador para armazenar e processar os dados, o Hadoop permite agrupar (clustering) vários computadores para analisar conjuntos de dados massivos em paralelo (AMAZON, 2022). O Apache Hadoop é constituído por quatro módulos:

Apache Spark

O Apache Spark é um sistema de processamento distribuído de código aberto usado para processar cargas de trabalho de big data. Ele utiliza in-memory cache (cache em memória) e recursos de otimização de consultas para agilizar a execução de consultas analíticas em conjuntos de dados de qualquer tamanho. Ele fornece APIs de desenvolvimento em Java, Scala, Python e R e oferece suporte à reutilização de código em várias cargas de trabalho -- processamento em lote, consultas interativas, análise em tempo real, aprendizado de máquina e processamento de grafos. O Apache Spark é atualmente uma das estruturas de processamento distribuído de big data mais populares (AMAZON, 2022).

O Spark foi criado para resolver limitações do MapReduce, fazendo processamento em memória (in-memory), reduzindo o número de etapas de trabalho e reutilizando dados em várias operações paralelas. Com o Spark, apenas uma etapa é necessária onde os dados são lidos na memória, as operações são executadas e os resultados são gravados de volta, resultando em uma execução muito mais rápida.

O Spark também reutiliza dados usando um cache na memória para acelerar os algoritmos de aprendizado de máquina que chamam repetidamente uma função no mesmo conjunto de dados. A reutilização de dados é realizada por meio da criação de DataFrames, uma abstração sobre Resilient Distributed Dataset (RDD), que é uma coleção de objetos armazenados em cache na memória e reutilizados em várias operações do Spark. Isso reduz drasticamente a latência, tornando o Spark várias vezes mais rápido que o MapReduce, especialmente em trabalhos de aprendizado de máquina e análises interativas.

Apache Spark vs. Apache Hadoop

Fora as diferenças no design do Spark e do Hadoop MapReduce, muitas organizações consideram essas estruturas de big data complementares.

O Hadoop é um framework open source que possui o Hadoop Distributed File System (HDFS) como armazenamento, o YARN como forma de gerenciar os recursos computacionais utilizados por diferentes aplicações e uma implementação do modelo de programação MapReduce como mecanismo de execução.

Spark é um framework de código aberto, focado em consultas interativas, aprendizado de máquina e cargas de trabalho em tempo real. Ele não possui seu próprio sistema de armazenamento, mas executa análises em outros sistemas de armazenamento como HDFS ou outras soluções populares como Amazon Redshift, Amazon S3, Couchbase, Cassandra e outras. O Spark sendo executado sobre o Hadoop aproveita o YARN para compartilhar clusters conjuntos de dados comuns, bem como outros recursos do Hadoop, garantindo níveis consistentes de serviço e resposta.

Ecossistema Hadoop

O ecossistema Hadoop cresceu significativamente ao longo dos anos devido à sua extensibilidade. Hoje, o ecossistema Hadoop inclui muitas ferramentas e aplicativos para ajudar a coletar, armazenar, processar, analisar e gerenciar big data. Algumas das aplicações mais populares são (AMAZON, 2022):

Spark – Um sistema de processamento distribuído de código aberto comumente usado para cargas de trabalho de big data. O Apache Spark usa cache na memória e execução otimizada para desempenho rápido e oferece suporte a processamento geral em lote, análise de streaming, aprendizado de máquina, bancos de dados de grafos e consultas ad-hoc.

Presto - Um mecanismo de consulta SQL distribuído de código aberto otimizado para análise de dados ad-hoc de baixa latência. Ele suporta o padrão ANSI SQL, incluindo consultas complexas, agregações, junções e funções de janela. O Presto pode processar dados de várias fontes de dados, incluindo o Hadoop Distributed File System (HDFS) e o Amazon S3.

Hive - Permite que os usuários aproveitem o Hadoop MapReduce usando uma interface SQL, permitindo análises em grande escala, além de armazenamento de dados distribuído e tolerante a falhas.

HBase - Um banco de dados com versão não relacional e de código aberto executado no Amazon S3 (usando EMRFS) ou no Hadoop Distributed File System (HDFS). O HBase é um armazenamento de big data distribuído e massivamente escalável, criado para acesso aleatório, estritamente consistente e em tempo real para tabelas com bilhões de linhas e milhões de colunas.

Bancos de Dados NoSQL

O termo NoSQL refere-se a um conjunto de sistemas de gerenciamento de bancos de dados baseados em estruturas não relacionais e sem um esquema pré-definido, que facilitam a escalabilidade horizontal e a gestão de dados não estruturados. Para melhorar o desempenho desses bancos de dados, as propriedades transacionais de conformidade ACID (Atomicity, Consistency, Isolation, Durability) não são garantidas, aderindo ao princípio de design BASE (basic availability, soft state, eventually consistent). O teorema CAP afirma que um sistema distribuído só pode fornecer simultaneamente duas propriedades entre consistência (C), disponibilidade (A) e tolerância à partição (P). A conformidade com ACID mantém consistência e disponibilidade, abrindo mão da possibilidade de implementações distribuídas em paralelo. O BASE, em vez disso, adota a tolerância à partição e, portanto, abre mão da disponibilidade imediata (CP) ou da consistência imediata (AP), dependendo do tipo de requisitos na camada de aplicação (SALINAS e LEMUS, 2017).

Bancos de dados NoSQL podem ser agrupados em bancos de dados documentais, de colunas (column-family), de valores-chave (key-value) ou grafos. Em bancos de dados orientados a documentos, cada registro é armazenado como um documento que é encapsulado e codificado em um formato padrão semi-estruturado como XML, JSON, BSON, etc.. Os bancos de dados orientados a documentos mais populares são MongoDB e CouchDB. Os bancos de dados orientados a colunas são caracterizados pela agregação de colunas de dados dentro de contêineres dados (keyspace). Algumas implementações deste tipo são Google BigTable, Cassandra, Apache HBase, Hypertable e Cloudata. Os bancos de dados orientados a valores-chave são caracterizados por armazenar dados como pares de valores-chave. Isso funciona eficientemente na memória usando estruturas map, arrays associativos ou tabelas hash, e também gerencia o armazenamento persistente. Apache Accumulo, CouchDB, Amazon Dynamo e Redis, entre outros, são os bancos de dados de chave-valor mais usados. Por fim, os bancos de dados orientados a grafos são caracterizados por uma organização de armazenamento diferente, na qual cada nó representa um objeto que pode estar relacionado a outros objetos por meio de uma ou mais arestas direcionadas (que, também, podem ser objetos). Dentro desta categoria podemos citar Neo4J, AllegroGraph e FlockDB. Em certos casos, bancos de dados orientados a grafos podem ser configurados para cumprir as propriedades ACID (SALINAS e LEMUS, 2017).

Salinas e Lemus (2017) mencionam sobre a utilização de bancos de dados NoSQL para a construção de Data Warehouses. Considerando a utilização da Modelagem Dimensional na estruturação de Data Warehouses, aparentemente a utilização de bancos de dados NoSQL não aparenta ser a melhor opção, como demonstrado por Pereira, Oliveira e Rodrigues (2015). Em seu trabalho, estes autores comparam o desempenho de um DW construído sobre o SQL Server (banco de dados relacional) e o MongoDB (banco de dados NoSQL).

 

Big Data vs Data Warehouse

Diferentemente de um Data Warehouse, o Big Data vai além da consolidação de informações, pois é utilizado principalmente para o armazenamento e processamento de qualquer tipo e volume de dados com um volume que potencialmente cresce exponencialmente. De certo modo, Data Warehouse (DW) e Big Data (BD) possuem o mesmo propósito, isto é, prover suporte a tomada de decisões, explorar dados para a identificação de padrões, geração de estatísticas e indicadores de desempenho (SALINAS e LEMUS, 2017).

As diferenças entre DW e BD estão na natureza dos dados, nos usuários a que são destinados e nos procedimentos e ferramentas para aquisição, armazenamento e análise de dados. Big Data foca principalmente na exploração de dados brutos, como dados não estruturados e não repetíveis, não susceptíveis a agregações e tratamentos sistemáticos. Por isso, geralmente, usuários de Big Data são mais especializados (por exemplo, cientistas de dados), que com a utilização de ferramentas, técnicas e algoritmos especiais conseguem identificar padrões que resultam em conclusões valiosas. Data Warehouses são focados em dados estruturados e alguns tipos de dados não estruturados, que precisam ser pré-processados antes de serem disponibilizados aos usuários finais (que podem não ter o conhecimento necessário de mineração de dados ou outras conhecimentos específicos), deste modo, estes podem fazer análises independentemente da origem dos dados, tipo de armazenamento, arquitetura, ferramentas e algoritmos específicos (SALINAS e LEMUS, 2017).

Para Salinas e Lemus (2017), a integração de conjuntos de dados heterogêneos pode ser a principal diferença entre um Data Warehouse e uma aplicação de Big Data. Em um DW, o propósito de uma integração é a obtenção de uma visão uniforme da organização, enquanto que em uma aplicação de BD, a integração não consiste em seu objetivo final. Neste último caso, conjuntos de dados não estruturados não passíveis de integração devem ser mantidos em seu formato original, permitindo a possibilidade de usos futuros, não previsíveis para o momento.

Em seu artigo, Salinas e Lemus (2017) concluem que aplicações de Big Data não constituem uma evolução para Data Warehouses. Na realidade DW e BD são complementares e podem ser integrados para o compartilhamento não apenas de dados, mas também de armazenamento e demais recursos computacionais.

Salinas e Lemus (2017) alertam que a demanda por soluções rápidas e a versatilidade de algumas ferramentas têm levado ao desenvolvimento de projetos de DW sem a utilização de metodologias e frameworks adequados. Após o investimento de tempo e recursos financeiros, organizações têm se visto presas em “soluções” de DW/BI que não cumprem as expectativas iniciais, inflexíveis a mudanças, difíceis de manter e escalar. Em relação a soluções de Big Data, existe atualmente todo um ecossistema de tecnologias, não necessariamente integradas em uma única plataforma, que pode aumentar a complexidade de desenvolvimento de novos projetos.

Big Data substitui a necessidade de um Data Warehouse?

Como já mencionado por Salinas e Lemus (2017), Big Data e Data Warehouse são complementares. Esta é também uma visão da Oracle (2022), ao afirmar que muitos veem big data como uma extensão integral de seus recursos existentes de business intelligence, plataforma de data warehousing e arquitetura de informações.

Para Anand (2019), uma solução de Big Data é uma tecnologia, enquanto que Data Warehousing seria um conceito arquitetônico em computação de dados. Uma organização pode ter diferentes combinações, com apenas soluções de Big Data ou de Data Warehouse, ou ambas simultaneamente, a depender dos seguintes fatores: Estrutura dos dados na origem; volume de dados; velocidade com que os dados deverão estar disponíveis para análise; e nível de conhecimento dos usuários dos dados.

Do ponto de vista do usuário final, em um DW, os dados armazenados estão sempre prontos para serem consumidos, mas são limitados aos dados já armazenados. Os dados em um DW estarão orientados por assunto/processo de negócio, portanto mais facilmente entendíveis por usuários finais. No entanto, se os usuários precisam de dados não presentes em um DW (como por exemplo, dados de redes sociais ou de algum log), a inclusão poderá não ser ágil devido ao processo necessário para coleta, tratamento e ingestão de dados de forma estruturada e organizada. Tais dados poderiam ser direcionados a uma solução de Big Data, permitindo com que os usuários pudessem acessá-los em formato nativo, mas que precisariam de transformações para a elaboração de relatórios. A recuperação de dados presentes em soluções de Big Data é difícil, pois os dados armazenados são desestruturados e desorganizados (ANAND, 2019).

Análise de big data (Big data analytics)

De acordo com o SAS (2022), técnicas de big data analytics (análise de big data) examinam grandes quantidades de dados na tentativa de descobrir padrões ocultos, correlações e outros insights.

Para Gandomi e Haider (2015), o potencial do big data surge apenas quando aproveitado para apoiar na tomada de decisões. Para isso, são necessários processos eficientes para transformar grandes volumes de dados, diversos e rápidos, em insights significativos.

O processo geral de extração de insights de big data pode ser dividido em cinco etapas, como pode ser visto na Figura 1.

image-1646849515052.png

Figura 1: Proceso geral de big data. Fonte: GANDOMI e HAIDER (2015).

Esses cinco estágios formam os dois principais subprocessos: gerenciamento de dados (Data Management) e análise (Analytics). O gerenciamento de dados envolve processos e tecnologias para adquirir, armazenar e preparar os dados para análise. A análise (Analytics), por outro lado, refere-se às técnicas usadas para analisar e adquirir inteligência a partir de big data. Deste modo, a análise de big data (Big data analytics) pode ser vista como um subprocesso no processo geral de “extração de insights” de big data (GANDOMI e HAIDER, 2015).

De acordo com o SAS (2022), não há uma tecnologia única que englobe a análise de big data. Existem análises avançadas que podem ser aplicadas a big data, mas, na realidade, vários tipos de tecnologia e técnicas precisam trabalhar juntas para a máxima obtenção de valor sobre os dados. SAS (2022) menciona os seguintes componentes relacionados à análise de big data:

Gandomi e Haider (2015) descrevem as cinco técnicas de análise de big data mais relevantes, de acordo com os autores. As técnicas descritas são listadas abaixo. Para mais detalhes, consultar o artigo referenciado:

Data Lake

Embora Data Warehouses sejam ainda muito relevantes e muito poderosos para dados estruturados, não se pode dizer o mesmo para dados semi-estruturados e não estruturados (KHINE e WANG, 2018; SAWADOGO e DARMONT, 2021). Como a maioria dos dados provenientes de Big Data são dados não estruturados (MILOSLAVSKAYA e TOLSTOY, 2016), pode-se concluir que Data Warehouses tradicionais não mostram-se alternativas viáveis como fonte de dados analíticos de Big Data. Neste sentido, o conceito de Data Lake desafia os tradicionais Data Warehouses no armazenamento de dados heterogêneos e complexos (KHINE e WANG, 2018).

As definições para Data Lake têm variado ao longo do tempo (KHINE e WANG, 2018; SAWADOGO e DARMONT, 2021). Alguns autores definem Data Lake apenas como um novo rótulo para soluções como Apache Hadoop por exemplo, o que, segundo Sawadogo e Darmont (2021) não estaria correto. Outros autores afirmam que Data Lakes podem ser utilizados apenas por alguns profissionais específicos, como estatísticos e cientistas de dados, pois os dados armazenados neste tipo de repositório requer certos cuidados que usuários de negócio poderiam negligenciar. Para Sawadogo e Darmont (2021), a definição mais correta para Data Lake é:

“um sistema escalável de armazenamento e análise de dados de qualquer tipo, retido em seu formato nativo e utilizado principalmente por especialistas em dados (estatísticos, cientistas de dados ou analistas) para extração de conhecimento. Suas características incluem:

Para Sawadogo e Darmont (2021), Data Lakes não necessariamente precisam ser restritos a estatísticos e cientistas de dados. Na visão destes autores, especialistas de negócio podem acessar Data Lakes através de um software de navegação ou de análise de dados apropriados.

De acordo com a Amazon (2022), um Data Lake é um repositório centralizado que permite armazenar dados estruturados e não estruturados, em qualquer escala. Os dados podem ser armazenados como estão, sem precisar primeiro estruturá-los. Uma vez armazenados, podem ser executadas diferentes tipos de análises sobre os dados, desde painéis e visualizações até processamento de big data, análise em tempo real e aprendizado de máquina.

Para Khine e Wang (2018), Data Lake consiste em um repositório em que todos os dados de uma organização, ou seja, dados estruturados, semi estruturados e não estruturados, são armazenados juntos, independentemente dos tipos, formato ou estrutura. Em um Data Lake, o entendimento dos dados, da sua estrutura e natureza, é delegada ao consumidor do dado, no momento da recuperação (ou seja, no momento da consulta). Os dados são transformados pelo usuário, ou aplicação, de acordo com o setor da organização, no intuito de adquirir insights de negócios. Alguns Data Lakes possuem recursos que possibilitam a criação de uma camada semântica sobre os dados, que permitem a construção de uma camada de contexto, significado e relacionamento entre os dados armazenados.  (KHINE e WANG, 2018).

No contexto de um Data Lake, todos os dados são primeiramente coletados de suas fontes (Extract - E), depois carregados no Data Lake (Load - L), sem modificação de seus formatos originais, e por fim são transformados (Transform - T), de acordo com o interesse do cliente consumidor (KHINE e WANG, 2018). Ou seja, com Data Lake temos o acrônimo ELT, ao invés do ETL utilizado no Data Warehouse.

Sawadogo e Darmont (2021) apresentam diversas arquiteturas de Data Lakes, e concluem que tanto as arquiteturas funcionais quanto as arquiteturas baseadas em maturidade de dados são limitadas, e expõem a necessidade de uma arquitetura que aborde simultaneamente, funcionalidade e maturidade de dados.

A maioria dos Data Lakes são construídos sobre o ecossistema Apache Hadoop (HDFS, MapReduce, Spark, etc.), mas como exposto por Sawadogo e Darmont (2021), esta não é a única alternativa, visto que a construção de um Data Lake exige diversas partes básicas, tais como:

Combinando Data Lakes com Data Warehouses

Sawadogo e Darmont (2021) citam duas abordagens de combinação de Data Lakes com Data Warehouses. A primeira utiliza o Data Lake como fonte de dados para o DW, para onde os dados susceptíveis ao rigor do processo de ETL são enviados, enquanto os dados remanescentes ficam disponíveis para análises complementares. A segunda abordagem considera a construção de um DW dentro do Data Lake. Algo que, segundo Sawadogo e Darmont (2021),  seria possível com a abordagem de subdivisão do Data Lake em data ponds, proposta por Inmon (2016). Data ponds estruturados a partir de aplicações operacionais poderiam ser considerados equivalentes a Data Warehouses (INMON, 2016).

Oreščanin e Hlupić (2021) mencionam uma combinação entre Data Wharesouse e Data Lake que envolve a migração de dados históricos de um DW para um Data Lake. De acordo com os autores, nesta configuração, o DW teria a função de armazenar os dados (fatos) mais recentes, e, à medida em que o DW for aumentando de tamanho, os dados mais antigos, e portanto menos acessados, poderiam ser migrados para a Foundation Area de um Data Lake. Deste moto, o DW ganharia performance de consulta e espaço em disco. Nesta configuração, os dados armazenados no Data Lake continuariam acessíveis e prontos para serem analisados juntamente com os dados no DW.

Maturidade e segurança

Caso o Data Lake não seja gerenciado adequadamente, este pode deteriorar-se a tal ponto de tornar-se o que é chamado de data swamp (pantano de dados) (KHINE e WANG, 2018; OREŠČANIN e HLUPIĆ, 2021). Ninguém sabe exatamente o que será incluído em um Data Lake, não havendo procedimentos para prevenção de inclusão de dados inconsistentes ou repetidos, por exemplo. Se ninguém sabe exatamente o que há no Data Lake até a extração, dados corrompidos podem ser utilizados equivocadamente em tomadas de decisão, fazendo com que o erro seja descoberto tarde demais (KHINE e WANG, 2018). De acordo com Sawadogo e Darmont (2021), a gestão de metadados é fundamental para impedir que o Data Lake se torne um data swamp.

Neste mesmo sentido, Khine e Wang (2018) afirmam que a gestão de metadados é fundamental em um Data Lake. Como a forma de armazenamento não possui schemas pré-definidos (schema-on-ready), como em um Data Warehouse (que é schema-on-write), o Data Lake precisa fornecer metadados aos clientes durante o processo de análise e realização de consultas. Os metadados precisam ser adicionados no momento de armazenamento dos dados. Deste modo, a definição de uma arquitetura coerente, juntamente com a gestão de metadados, são cruciais para a qualidade de dados.

Begoli, Goethert e Knight (2021) afirmam que Data Lakes não impõem explicitamente um schema para armazenamento de dados. Este aspecto, em um cenário de crescimento exponencial de dados, provenientes de inúmeras fontes, pode transformar o Data Lake em um Data Swamp, ou seja, em um pântano cheio de detritos de dados.

De acordo com Sawadogo e Darmont (2021), temas como governança de dados e segurança em Data Lakes são atualmente pouco abordados pela literatura. De acordo com Khine e Wang (2018), Data Warehouses podem garantir governança, performance, segurança e controle de acesso aos dados, enquanto Data Lakes não podem garantir, de forma plena, nenhum destes aspectos. Neste sentido, Khine e Wang (2018) afirmam que gerar valor com Data Lakes é ainda algo muito difícil.

Data Lakehouse

Data Lakes, como um conceito moderno de armazenamento de dados em formato nativo, foi apresentado como um substituto para Data Warehouses. No entanto, com o passar do tempo, ficou claro que Data Lakes pode ser utilizado em complementação ao Data Warehouses, não como substituto (OREŠČANIN e HLUPIĆ, 2021).

Data Warehouses (DW) surgiram com o intuito de auxiliar usuários de negócio a obterem insights analíticos através da centralização de dados provenientes de diversas fontes, principalmente de bancos de dados operacionais. Os dados em um DW são utilizados como suporte à tomada de decisão por meio de aplicações de Business Intelligence (BI). Os dados em um DW são armazenados em uma estrutura fixa, em schemas pré-definidos (schema-on-write), de modo a garantir segurança e performance. Este tipo de solução é chamado de plataforma de análise de dados de primeira geração (ARMBRUST, GHODSI, XIN e ZAHARIA, 2021).

Com o surgimento do Big Data (grande volume de dados, em grande velocidade e variedade de fontes e múltiplos formatos), os Data Warehouses passaram a não conseguir suprir as necessidades de algumas organizações, surgindo então a segunda geração de plataforma de análise de dados, os Data Lakes (ARMBRUST, GHODSI, XIN e ZAHARIA, 2021). Data Lakes utilizam formas de armazenamento de baixo custo (HDFS do Apache Hadoop, por exemplo) e, geralmente, com formatos de armazenamento abertos, como Apache Parquet e ORC. Data Lakes possuem arquitetura schema-on-read, ou seja, os dados não são armazenados em estruturas rígidas pré-definidas, e sim em seu formato original. Fornecendo flexibilidade e agilidade no armazenamento e acesso aos dados. Porém, por outro lado, a flexibilidade trazida por Data Lakes traz problemas de qualidade e governança de dados, como já apontado por Khine e Wang (2018) e Sawadogo e Darmont (2021).

De 2015 em diante surgiu uma nova forma de organização das plataformas de dados, com a utilização complementar de Data Lakes e Data Warehouses. Data Lakes em nuvem, como S3, ADLS e GCS têm substituído o Apache HDFS, com o armazenamento posterior de parcela dos dados em Data Warehouses, como Redshift e Snowflake (ARMBRUST, GHODSI, XIN e ZAHARIA, 2021). Esta arquitetura de duas camadas, Data Lake + Data Warehouse é, segundo Armbrust, Ghodsi, Xin e Zaharia (2021), dominante no mercado (aparentemente utilizado por todas as empresas do ranking Fortune 500).

Esta arquitetura de duas camadas possui alta complexidade de manutenção. Primeiramente os dados são carregados em um Data Lake, e depois em um Data Warehouse, exigindo portanto duas etapas de ETL até a sua disponibilização para análise por usuários de BI. A nova arquitetura, portanto, aumentou a complexidade, os atrasos e os pontos de falha se comparada à estratégia de inclusão de dados diretamente no Data Warehouse, por exemplo (ARMBRUST, GHODSI, XIN e ZAHARIA, 2021).

Diante dos problemas ainda não solucionados por Data Warehouses e/ou Data Lakes, surge um novo conceito de arquitetura denominado Data Lakehouse, com o objetivo de superar tais problemas (OREŠČANIN e HLUPIĆ, 2021).

Um Data Lakehouse busca combinar as vantagens das arquiteturas presentes em Data Lakes e Data Warehouses, contendo tanto estruturas de dados pré-definidas (schema-on-write), quanto não pré-definidas (schema-on-read) (OREŠČANIN e HLUPIĆ, 2021).

Conceitualmente, um Data Lakehouse promete conciliar as demandas de armazenamento de dados heterogêneos de modo eficiente e econômico, permitindo o acesso aos mesmos por meio de diversos tipos de aplicações, desde aquelas baseadas em aprendizado de máquina àquelas baseadas em SQL. De modo geral, Data Lakehouses buscam solucionar os problemas de confiabilidade e obsolescência de dados, suporte limitado a análises avançadas e diminuição do custo total de propriedade das arquiteturas de dados (BEGOLI, GOETHERT E KNIGHT, 2021).

Definição

Armbrust, Ghodsi, Xin e Zaharia (2021) definem um Data Lakehouse como um sistema de gerenciamento de dados baseado em armazenamento de baixo custo e de acesso direto, que também fornece recursos de desempenho e gerenciamento analíticos tradicionais de SGBDs, como transações ACID, controle de versão de dados, auditoria, indexação, armazenamento em cache e otimização de consultas. Deste modo, Lakehouses combinam os principais benefícios de Data Lakes e Data Warehouses: armazenamento de baixo custo em formatos abertos e acessíveis, e poderosos recursos de gerenciamento e otimização. A questão-chave é se é possível combinar esses benefícios de maneira eficaz: em particular, o suporte de Lakehouses para acesso direto aos dados significa que eles abrem mão de alguns aspectos de independência de dados, que tem sido um dos pilares do design de SGBDs relacionais.

Begoli, Goethert e Knight (2021) afirmam que o conceito de Data Lakehouse ainda é vago, não materializado. De acordo com os autores, não há ainda uma solução completa definitiva, “fora da prateleira”, para o conceito de Data Lakehouse. Ou seja, é ainda um conceito em evolução, que parte das seguintes premissas:

Direcionamento da indústria

Armbrust, Ghodsi, Xin e Zaharia (2021) argumentam que a arquitetura de Data Warehouse como a conhecemos hoje tende a perder importância nos próximos anos, e deverá ser substituída por um novo padrão arquitetônico, o Data Lakehouse que:

De acordo com Armbrust, Ghodsi, Xin e Zaharia (2021), Data Lakehouses podem ajudar a enfrentar vários desafios importantes enfrentados atualmente com Data Lakes e Data Warehouses, incluindo:

Armbrust, Ghodsi, Xin e Zaharia (2021) concluem que a indústria tende a convergir para a adoção de Data Lakehouses devido à vasta quantidade de dados já depositados atualmente em Data Lakes, e devido à grande oportunidade de simplificação das suas arquiteturas de dados.

 

image-1647025671823.png

Figrua 1: Evolução das arquiteturas de plataforma de dados. Fonte: (ARMBRUST, GHODSI, XIN e ZAHARIA, 2021).

 

Data Mesh

Em 2019, no artigo How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh, Zhamak Dehghani propõe uma nova abordagem para construção de plataformas de dados, chamado Data Mesh. De acordo com Dehghani (2019), os modelos atuais de plataforma de dados, sendo estes baseados em Data Lakes ou Data Warehouses, são centralizados, monolíticos e agnósticos a domínios (áreas de negócio). Embora inúmeras organizações tenham investido fortemente na construção de soluções que facilitem a tomada de decisão orientada por dados, como plataformas de dados e inteligência, estas organizações têm considerado os resultados medíocres (DEHGHANI, 2019).

Dehghani (2019) reconhece a necessidade de usuários de dados, como cientistas de dados e analistas, terem acesso simplificado a um conjunto diversificado de dados, bem como a necessidade de separar o uso de dados de sistemas operacionais dos dados consumidos para fins analíticos. Mas propõe que os modelos de solução centralizados existentes não são a resposta ideal para grandes empresas com múltiplos domínios (áreas de negócio), onde novas fontes de dados são continuamente adicionadas.

Dehghani (2019) complementa que não defende a fragmentação em silos de conjunto de dados orientados a domínios (áreas de negócio), ocultos sob algum sistema de informação e geralmente difíceis de descobrir, entender e consumir. Tão pouco a existência de vários Data Warehouses (ou Data Lakes) fragmentados em decorrência de anos de dívidas técnicas acumuladas. Dehghani (2019) argumenta que a resposta a esses silos acidentais de dados inacessíveis não é criar uma plataforma de dados centralizada, com uma equipe centralizada que possui e faz a curadoria dos dados de todos os domínios (áreas de negócio), pois este tipo de solução não é escalável.

Dehghani (2019) define as gerações de plataformas de dados da seguinte forma:


Embora a última geração de plataforma de dados tenha abordado algumas lacunas das gerações anteriores, como a análise de dados em tempo real e redução do custo de gerenciamento da infraestrutura de big data, esta ainda sofre de muitas das características subjacentes que levaram aos fracassos das gerações anteriores (DEHGHANI, 2019).

Falhas das arquiteturas atuais

De acordo com Dehghani (2019), as arquiteturas atuais possuem os seguintes problemas:

image-1647367960529.png

Figura 1: Plataforma de dados centralizada sem a clara definição de fronteiras entre dados de domínios distintos. Fonte: (DEHGHANI, 2019).

image-1647368118305.png

Figura 2: Decomposição arquitetônica da plataforma de dados. Fonte: (DEHGHANI, 2019).

image-1647368204805.png

Figura 3: Silos hiper especializados de times de plataforma de dados. Fonte: (DEHGHANI, 2019).

A próxima arquitetura corporativa de plataforma de dados

A nova proposta de arquitetura de plataforma de dados trata a questão da onipresença de dados e fontes por meio do conceito de Data Mesh (malha de dados distribuída).

De acordo com Dehghani (2019), a solução dos problemas das arquiteturas de dados atuais requer uma mudança de paradigma. Dehghani (2019) sugere que a próxima arquitetura de plataforma de dados corporativos esteja na convergência dos conceitos de Arquitetura Distribuída Orientada a Domínio (Distributed Domain Driven Architecture), Design de Plataforma Self-Service (Self-serve Platform Design) e Pensamento em Dados como Produto (Product Thinking with Data).

Decomposição e propriedade de dados orientada a domínio

Para que a plataforma de dados monolítica seja descentralizada, será necessário reverter a forma como pensamos sobre os dados, sua localidade e propriedade. Em vez de transferir os dados dos domínios para um Data Lake ou plataforma de propriedade central, os domínios precisam hospedar e servir seus conjuntos de dados de domínio de maneira facilmente consumível. O armazenamento físico pode ser uma infraestrutura centralizada, como buckets do Amazon S3, mas o conteúdo e a propriedade dos conjuntos de dados devem permanecer com o domínio que os gera (DEHGHANI, 2019).

Dados de domínios orientado à origem

Em uma situação madura e ideal, um sistema de informação e sua equipe ou unidade organizacional não são apenas responsáveis por fornecer requisitos e recursos de negócios, mas também por fornecer as verdades de seu domínio de negócios como conjuntos de dados de domínio de origem (DEHGHANI, 2019).

Na escala corporativa, nunca há um mapeamento de um para um entre um conceito de domínio e um sistema de origem. Muitas vezes existirão muitos sistemas que podem servir partes dos dados que pertencem a um domínio, alguns legados e alguns mais susceptíveis a mudanças. Portanto, podem haver muitos conjuntos de dados alinhados à origem, que precisam ser agregados a um conjunto de dados alinhado ao domínio coeso.

Observe que os conjuntos de dados de domínio devem ser separados dos conjuntos de dados dos sistemas internos. A natureza dos conjuntos de dados de domínio é muito diferente dos dados internos que os sistemas de informação usam para fazer seu trabalho. Eles têm um volume muito maior, representam fatos temporais imutáveis e mudam com menos frequência do que seus sistemas de origem. Por esse motivo, o armazenamento subjacente real deve ser adequado para big data e separado dos bancos de dados operacionais existentes (DEHGHANI, 2019).

Pipelines distribuídos como implementação interna do domínio

A necessidade de limpeza, preparação, agregação e fornecimento de dados permanece, assim como o uso do pipeline de dados. Nesta arquitetura, um pipeline de dados é simplesmente uma complexidade interna e implementação do domínio de dados, sendo tratado internamente dentro do domínio. Como resultado, veremos uma distribuição dos estágios dos pipelines de dados em cada domínio.

image-1647368460110.png

Figura 4: Pipelines distribuídos entre domínios como um detalhe interno de implementação. Fonte: (DEHGHANI, 2019).

Convergência entre dados e product thinking

A distribuição da propriedade dos dados e a implementação de pipelines nas mãos dos domínios de negócios levantam uma preocupação importante sobre acessibilidade, usabilidade e harmonização de conjuntos de dados distribuídos.

Para que uma plataforma de dados distribuídos seja bem-sucedida, as equipes de dados de domínio devem aplicar o pensamento de produto (Product Thinking) com rigor semelhante aos conjuntos de dados que fornecem; considerando seus ativos de dados como seus produtos e os outros cientistas/engenheiros de dados da organização como seus clientes (DEHGHANI, 2019).

Para prover a melhor experiência aos consumidores de dados, os produtos de dados de domínio precisam possuir as seguintes qualidades básicas (DEHGHANI, 2019):

Equipes multifuncionais

Equipes responsáveis por domínios (áreas de negócio) responsáveis pelo fornecimento de dados como produtos, precisam contar com novos conjuntos de habilidades: (a) o proprietário do produto de dados e (b) engenheiros de dados.

Um proprietário de produto de dados toma decisões em torno da visão e do roadmap para os produtos de dados, preocupa-se com a satisfação de seus consumidores e mede e aprimora continuamente a qualidade e a riqueza dos dados que seu domínio possui e produz. É responsável pelo ciclo de vida dos conjuntos de dados do domínio, buscando um equilíbrio entre as necessidades concorrentes dos consumidores de dados do domínio (DEHGHANI, 2019).

Para construir e operar os pipelines de dados internos dos domínios, as equipes devem incluir engenheiros de dados. Um efeito colateral vantajoso dessa equipe multifuncional é o compartilhamento de habilidades entre os membros da equipe. Observa-se em algumas situações do mundo real que alguns engenheiros de dados, embora competentes no uso das ferramentas da sua área de atuação, carecem de práticas concernentes à engenharia de software, como entrega contínua e testes automatizados, por exemplo, quando se trata de construir ativos de dados. Da mesma forma, os engenheiros de software que estão construindo sistemas de informação geralmente não têm experiência na utilização de soluções de engenharia de dados (DEHGHANI, 2019).

Os dados devem ser tratados como uma peça fundamental de qualquer ecossistema de software, portanto, engenheiros e generalistas de software devem adicionar a experiência e o conhecimento do desenvolvimento de produtos de dados ao seu cinto de ferramentas.

Convergência de design de plataforma de dados self-service

A construção de infraestruturas comuns como plataforma é um problema bem compreendido e resolvido, embora reconhecidamente as ferramentas e técnicas não sejam tão maduras para ecossistemas de dados.


A utilização de recursos de infraestrutura agnóstica a domínio a partir de uma plataforma de infraestrutura de dados resolve a necessidade de duplicar o esforço de configurar mecanismos de pipeline de dados, armazenamento e infraestrutura de streaming. Neste sentido, uma equipe de infraestrutura de dados deve fornecer a tecnologia necessária que os domínios precisam para capturar, processar, armazenar e disponibilizar seus produtos de dados (DEHGHANI, 2019).

image-1647368697155.png

Figura 5: Plataforma de infraestrutura de dados agnóstica a domínio. Fonte: (DEHGHANI, 2019).

A chave para construir uma infraestrutura de dados como plataforma é: (a) não incluir nenhum conceito específico de domínio ou lógica de negócios, mantendo-a agnóstica de domínio, e (b) certificar-se de que a plataforma oculte toda a complexidade subjacente e forneça os componentes de infraestrutura de dados em uma forma self-service (DEHGHANI, 2019).

image-1647368790582.png

Figura 6: Visão de altíssimo nível de uma arquitetura de Data Mesh. Fonte: (DEHGHANI, 2019).

Você deve estar se perguntando onde o Data Lake ou o Data Warehouse se encaixam nesta arquitetura. Eles são simplesmente nós na malha. É muito provável que não precisemos de um Data Lake, porque os logs distribuídos e os dados originais de sistemas estão disponíveis para exploração de diferentes conjuntos de dados imutáveis endereçáveis como produtos. No entanto, nos casos em que precisamos fazer alterações no formato original dos dados para exploração adicional, como rotulagem, o domínio com essa necessidade pode criar seu próprio Data Lake ou Data Warehouse (DEHGHANI, 2019).

A principal mudança é tratar o produto de dados de domínio como uma preocupação de primeira classe e as ferramentas e o pipeline de Data Lake / Data Warehouse como uma preocupação de segunda classe - um detalhe de implementação. Isso inverte o modelo mental atual de um Data Lake / DW centralizado para um ecossistema de produtos de dados que funcionam juntos, uma malha de dados (DEHGHANI, 2019).

Data Hub

De acordo com o Goasduff (2020), Data Hubs são “hubs” conceituais, lógicos e físicos para mediação da semântica, em suporte à governança e compartilhamento de dados entre sistemas. Data Hubs possibilitam o fluxo contínuo de dados devidamente governados.

Para o DAMA (2017), existem diferentres tipos de Data Hubs, uma vez que este é um conceito que objetiva a consolidação e o provimento de dados consistentes tanto para outros sistemas quanto diretamente para para humanos. Neste sentido, DAMA (2017) menciona que Data Warehouses e soluções de Gestão de Dados Mestres são tipos de Data Hubs.

Segundo Harrad (2020), o Data Hub é o local ideal para os dados principais de uma organização. Ele centraliza os dados que são críticos entre os aplicativos e permite o compartilhamento contínuo entre diversos endpoints, ao mesmo tempo em que é a principal fonte de dados confiáveis para a iniciativa de governança de dados. Os Data Hubs fornecem Dados Mestres para aplicativos e processos corporativos. Eles também são usados para conectar aplicativos de negócios a estruturas analíticas, como data warehouses e data lakes.

image-1647868803510.pngFigura 1: Data Hub como pilar principal de dados governados. Fonte: HADDAD (2020).

Diferentemente de Data Warehouses e Data Lakes, que são focados no provimento de dados para finalidades analíticas, os Data Hubs servem como pontos de mediação e compartilhamento de dados, com o foco em governança (HARRAD, 2020).

Data warehouses, Data Lakes e Data Hubs não são alternativas intercambiáveis, mas sim complementares. Juntos podem apoiar iniciativas baseadas em dados e transformação digital. A tabela abaixo resume suas semelhanças e diferenças HARRAD (2020):

 

Data Hub

Data Warehouse

Data Lake

Uso primário

Processos operacionais

Análise e relatórios

Análise, relatórios e Machine Learning.

Formato dos dados

Estruturados

Estruturados

Estruturados e não estruturados

Governança de Dados

Pilar principal para todas as regras de aplicação de governança de dados

Governança pós-fato, pois consome dados operacionais existentes

Abordagem de dados “Use por sua conta e risco”. Pouco governado

Qualidade de Dados

Altíssima qualidade

Alta qualidade

Média e baixa qualidade

Integração com aplicações

Integração bidirecional em tempo real com processos de negócios existentes por meio de APIs.

ETL monodirecional em lote. Os dados transformados e limpos são atualizados em baixa frequência (por hora, diariamente ou semanalmente)

ETL ou ELT monodirecional em lote. Os dados são despejados sem controle, assumindo uma limpeza futura pelo consumidor

Interação com usuários de negócio

Pode ser a fonte primária de autoria de elementos-chave de dados, como Dados Mestre e Dados de Referência. Expõe interfaces amigáveis para criação de dados, administração de dados e pesquisa.

Oferece acesso somente leitura a dados limpos e preparados, por meio de relatórios, painéis analíticos ou consultas ad-hoc.

Requer limpeza/preparação de dados antes do consumo. O acesso aos usuários corporativos é oferecido principalmente por meio de relatórios, painéis ou consultas ad-hoc. Usado para preparar conjuntos de dados de aprendizado de máquina.

Processos Operacionais da organização

Repositório principal para dados confiáveis expostos em processos de negócios. Pode ser o principal condutor dos processos de negócios corporativos.

Serve principalmente para processos de análise.

Atende principalmente processos de Machine Learning.

 

Integração e Governança de Dados

A necessidade de gerenciar a complexidade, juntamente com os seus custos decorrentes, são os motivos para arquitetar a integração de dados em uma perspectiva corporativa. Um projeto corporativo de integração de dados é comprovadamente mais eficiente e econômico do que soluções distribuídas ou ponto a ponto, visto que o desenvolvimento de soluções ponto a ponto entre sistemas pode acabar sobrecarregando até mesmo os recursos de suporte de TI mais eficientes (DAMA, 2017).

Data Hubs, como Data Warehouses e soluções de Gestão de Dados Mestres auxiliam na minimização de tais problemas por meio da consolidação e provimento de dados consistentes para usuários e outros sistemas. Da mesma forma, a complexidade do gerenciamento de dados operacionais e transacionais que precisam ser compartilhados em toda a organização pode ser bastante simplificada por meio da utilização de técnicas de integração de dados corporativos, como integração hub-and-spoke e modelos de mensagens canônicas (DAMA, 2017).

Sabe-se que Integração e interoperabilidade de dados é algo crítico para Data Warehousing e Business Intelligence, bem como para a Gestão de Dados Mestres e de Referência, visto que esses tópicos concentram-se na transformação e integração de dados de sistemas de origem para Data Hubs (hubs de dados) consolidados, e destes para sistemas de destino, de onde os dados podem ser entregues tanto para outros sistemas quanto diretamente para para humanos (DAMA, 2017).

O modelo hub-and-spoke de Data Hub mostra-se como uma alternativa às integrações do tipo ponto-a-ponto. Este modelo consolida dados compartilhados (fisicamente ou virtualmente) em um hub de dados central em que muitos aplicativos podem utilizar. Deste modo, todos os sistemas que desejam trocar dados o fazem por meio de um sistema central comum de controle de dados, em vez de diretamente entre si (ponto a ponto).

Os Enterprise Service Buses (ESB) constituem um tipo de solução de integração para compartilhamento de dados quase em tempo real entre vários sistemas, onde o hub é um conceito virtual do formato padrão ou do modelo canônico para compartilhamento de dados na organização.

Uma arquitetura hub-and-spoke nem sempre pode ser a melhor solução. A latência ou o desempenho do modelo pode às vezes não ser adequada para a necessidade. O próprio hub cria sobrecarga em uma arquitetura hub-and-spoke. Uma solução ponto a ponto não exigiria o hub, no entanto, os benefícios do mesmo superam as desvantagens da sobrecarga assim que três ou mais sistemas estão envolvidos no compartilhamento de dados. O uso do padrão de design hub-and-spoke para o intercâmbio de dados pode reduzir drasticamente a proliferação de soluções de integração e transformação de dados e, assim, simplificar massivamente o suporte organizacional necessário (DAMA, 2017).

Qualidade de Dados

Existe uma percepção incorreta de que a qualidade de dados esteja estritamente relacionada com os seus aspectos estruturais. A qualidade de dados deve ser analisada em diversos aspectos, dos quais, muitos não estão diretamente relacionados à forma física do dado, mas ao seu entorno (BARBIERI, 2019).

Barbieri (2019) comenta que há vários autores com variadas classificações de dimensões de qualidade de dados. Abaixo são listadas algumas das dimensões mais usualmente encontrados na literatura:

Com a evolução da ciência de dados, outros aspectos, como privacidade e ética, passarão a ser considerados dentro dos aspectos de qualidade.

Kimball e Ross (2013) pontuam que iniciativas puramente técnicas para solucionar problemas de qualidade de dados geralmente não funcionam, a não ser que façam parte de uma cultura geral de qualidade, estabelecida pela alta cúpula da instituição. Deste modo, Kimball e Ross (2013) afirmam que problemas com qualidade de dados não podem ser solucionados apenas pela TI. Em muitos casos, na realidade, problemas com qualidade de dados nada tem haver com TI.

Referências

 

Linhagem de Dados

De acordo com Kimball e Ross (2013), a linhagem de dados descreve as origens e as etapas de processamento que produziram cada elemento de dado em uma tabela. Esta linhagem deve ser armazenada no Data Warehouse / Data Lake por meio dos metadados associados a cada elemento. Essa linhagem é explicitamente exigida por certos requisitos de conformidade, mas deve fazer parte de todas as situações de arquivamento.

Segundo Barbieri (2019), Linhagem de Dados significa o entendimento de cada passo ao longo dos processos, observando quais dados e metadados entraram em cada bloco de processamento, quais dados saíram, quais foram os processamentos efetuados, regras aplicadas, etc. Deste modo, quando houver um problema específico no fluxo de processamento de dados, a linhagem poderá auxiliar na depuração e identificação do problema. Conhecer os detalhes deste caminho é fundamental para a depuração de erros que possam surgir em um ponto mais adiante do fluxo, mas que podem ter sido produzidos em estágios anteriores.

image-1647437239771.pngFigura 1: Exemplo de visualização de um grafo de exibição de linhagem de dados.

ETL

De acordo com Kimball e Ross (2010), ETL (Extract, Transform, Load) consiste em um paradigma padrão para a aquisição e preparação de dados, de modo a torná-los prontos para exposição a ferramentas de Business Intelligence (BI). O processo de ETL preenche a lacuna entre os dados fonte dos sistemas transacionais de produção e a camada de apresentação e schemas dimensionais necessários para o consumo por ferramentas de BI. É um trabalho pesado, que consome cerca de 70% do tempo necessário para a construção de ambientes de Business Intelligence.

O sistema de ETL agrega valor aos dados com as tarefas de limpeza e conformidade, alterando os dados e aprimorando-os. Além disso, essas atividades podem ser arquitetadas para criar metadados de diagnóstico, eventualmente levando à reengenharia de processos de negócios para melhorar a qualidade dos dados nos sistemas de origem ao longo do tempo (Kimball e Ross, 2013).

Staging Area

De acordo com Kimball e Ross (2010), Staging Area é o local onde os dados fontes são transformados em dados com significados, prontos para serem apresentados aos usuários finais. Este processo precisa ser capaz de transformar, eficientemente, dados brutos em dados de valor, acomodados em um modelo objetivo, minimizando a movimentação desnecessária.

Neste mesmo sentido, DAMA (2017) define Staging Area como uma área intermediária de armazenamento, entre os dados originais e o repositório centralizado. Nesta área, os dados são transformados, integrados e preparados para o carregamento no Data Warehouse.

EDW e Modelagem Dimensional

EDW e Modelagem Dimensional

Modelagem Dimensional

Modelagem dimensional é uma disciplina de design que abrange a modelagem relacional formal e a engenharia de realidades textuais e numéricas. Comparada à terceira forma normal da Modelagem Entidade-Relacionamento, é menos rigorosa (permitindo ao designer mais discrição na organização das tabelas), porém mais prática pois acomoda a complexidade de um banco de dados enquanto contribui para a melhoria do seu desempenho. A modelagem dimensional possui um portfólio extenso de técnicas para lidar com situações do mundo real (KIMBALL e ROSS, 2010).

Devido a sua simplicidade na apresentação dos dados, a modelagem dimensional tem sido amplamente aceita como a técnica dominante de modelagem de Data Warehouses. A simplicidade é a chave fundamental que permite aos usuários finais navegarem com eficiência sobre os dados apresentados pelo DW. Ao focar consistentemente em uma perspectiva orientada para os negócios, recusando-se a comprometer a objetivos específicos de usuários, você estabelece um design coerente que atende às necessidades analíticas da organização (KIMBALL e ROSS, 2013).

O modelo dimensional deve corresponder à estrutura física dos eventos de captura de dados. Um modelo não deve ser elaborado para atender a um relatório em específico (report-of-the-day). Os processos de negócios de uma empresa ultrapassam as fronteiras dos departamentos e funções organizacionais. Em outras palavras, você deve construir uma única tabela de fatos para métricas de vendas atômicas em vez de preencher bancos de dados / tabelas semelhantes, mas ligeiramente diferentes, contendo métricas de vendas para as equipes de vendas, marketing, logística e finanças separadamente (KIMBALL e ROSS, 2013).

Medições e Contexto

A modelagem dimensional se inicia dividindo o mundo entre medições e contexto. Medições são usualmente numéricas e tomadas repetidamente. Medições numéricas são fatos. Fatos estão sempre cercados geralmente por contexto textuais, que são verdadeiros no momento em que os fatos são gerados. Fatos são constituídos de atributos numéricos, muito específicos e bem definidos. Em contraste, o contexto que cerca os fatos é aberto e verboso (KIMBALL e ROSS, 2010).

Embora possamos aglomerar todo o contexto juntamente com cada medida em um vasto e único registro lógico, veremos que, geralmente, é mais conveniente separar o contexto em grupos independentes. Quando armazenados fatos -- vendas em reais de uma mercearia referentes a um produto específico, por exemplo -- naturalmente dividiremos o contexto entre grupos denominados Nome do Produto, Loja, Horário, Cliente, Balconista, dentre outros. Chamamos esses agrupamentos lógicos de dimensões, e assumimos informalmente que essas dimensões são independentes. A figura abaixo mostra um modelo dimensional para um armazenamento típico de fatos para uma mercearia (KIMBALL e ROSS, 2010).

image-1646672321686.png

Na realidade, dimensões são raramente independentes dentro de um contexto estatístico. No exemplo da mercearia, cliente (customer) e loja (store) terão claramente uma correlação estatística. Mas é usualmente uma decisão correta separar cliente e loja em dimensões separadas. Uma única dimensão combinada provavelmente seria difícil de manejar, com dezenas de milhões de linhas. O registro de onde um cliente comprou em determinada loja é expressado mais naturalmente em uma Tabela Fato, que mostra também quando isso ocorreu (dimensão tempo) (KIMBALL e ROSS, 2010).

Assumir a independência de dimensões significa que todas as dimensões, como produto, loja e cliente são independentes do fator tempo. Mas devemos levar em conta a mudança lenta e esporádica dessas dimensões ao longo do tempo. De fato, como mantenedores do Data Warehouse, assumimos o compromisso de representar essas mudanças. Esta situação dá origem à técnica denominada Slowly Changing Dimensions (SCD) (KIMBALL e ROSS, 2010).

Relacionando os dois Mundos da Modelagem

Modelos dimensionais são modelos relacionais, em que Tabelas Fato estão na terceira forma normal e as Tabelas de Dimensão estão na segunda forma normal, confusamente chamadas de desnormalizadas. Lembre-se que a grande diferença entre a segunda e a terceira forma normal é que os valores repetidos (redundantes) são removidos da segunda forma normal por meio da criação de novas tabelas (snowflake). O fato de removermos os valores de dimensão da Tabela Fato, e colocando esses valores em suas próprias tabelas, coloca a Tabela Fato na terceira forma normal (KIMBALL e ROSS, 2010).

Devemos resistir ao impulso de colocar as tabelas de dimensão na terceira forma normal (snowflake), pois tabelas únicas (flat) são muito mais eficientes para recuperação de dados por meio de instruções SQL. Em particular, os atributos de dimensão com muitos valores repetidos são alvos perfeitos para índices de bitmap. Colocar uma dimensão na terceira forma normal (snowflaking), embora não seja incorreto, elimina a possibilidade de utilização de índices de bitmap e aumenta a percepção de complexidade no design (KIMBALL e ROSS, 2010).

Lembre-se que na área de apresentação de um DW não precisamos nos preocupar em forçar a aplicação de regras de dados muito rígidas, exigindo dimensões snowflaked (terceira forma normal). A garantia de integridade já é garantida no estágio de ETL (staging ETL system) (KIMBALL e ROSS, 2010).

EDW e Modelagem Dimensional

Arquitetura de Barramento do Enterprise Data Warehouse

A arquitetura de barramento do Enterprise Data Warehouse (Enterprise Data Warehouse Bus Architecture) fornece uma abordagem incremental para construir o sistema de DW/BI corporativo. Essa arquitetura decompõe o processo de planejamento de DW/BI em partes gerenciáveis, concentrando-se nos processos de negócios, enquanto oferece integração por meio de dimensões padronizadas que são reutilizadas em todos os processos. Ela  fornece uma estrutura de arquitetura, ao mesmo tempo em que decompõe o programa para incentivar implementações ágeis gerenciáveis correspondentes às linhas na matriz de barramento do EDW (KIMBALL e ROSS, 2013).

Ao definir uma interface de barramento padrão para o ambiente DW/BI, modelos dimensionais separados podem ser implementados por diferentes grupos em momentos diferentes. Deste modo, as áreas de negócio distintas podem se conectar e coexistirem de maneira complementar.

Como ilustrado pelo diagrama abaixo, podemos vislumbrar diversos processos de negócio plugados em um barramento comum. Cada processo da cadeia de valor de uma organização pode exigir a criação de uma família de modelos dimensionais, que compartilham uma série de dimensões conformadas.

image-1646653078758.png

Sem a definição de uma matriz de barramento, algumas equipes de DW/BI caem na armadilha de usar técnicas ágeis para criar rapidamente soluções isoladas (relatórios e dashboards). Na maioria das situações, a equipe atua com um pequeno conjunto de usuários para extrair um conjunto limitado de dados de origem e disponibilizá-los para resolver seus problemas exclusivos. O resultado geralmente é um canal de dados autônomo que outros não podem aproveitar, ou pior ainda, fornece dados que não estão vinculados às outras informações analíticas da organização. Incentivamos a agilidade, quando apropriado, mas a construção de conjuntos de dados isolados deve ser evitada (KIMBALL e ROSS, 2013).

 

EDW e Modelagem Dimensional

Matriz de Barramento

A matriz de barramento do Enterprise Data Warehouse (Enterprise Data Warehouse Bus Matrix) é uma ferramenta essencial para projetar e comunicar a arquitetura de barramento do EDW. Como pode ser visto na imagem abaixo, as linhas da matriz são processos de negócios e as colunas são dimensões. As células marcadas da matriz indicam se uma dimensão está associada a um determinado processo de negócios. A equipe de design verifica cada linha para testar se uma dimensão candidata está bem definida para o processo de negócios e também verifica cada coluna para ver onde uma dimensão deve ser conformada em vários processos de negócios. Além das considerações de projeto técnico, a matriz de barramento é usada como entrada para priorizar projetos de DW/BI com gestão de negócios, pois as equipes devem implementar uma linha da matriz por vez (KIMBALL e ROSS, 2013).

image-1646653835752.png

EDW e Modelagem Dimensional

Tabela Fato

Tabelas Fato são tabelas para armazenamento de medidas. A maioria das medidas armazenadas em Tabelas Fato dizem respeito a séries temporais, em que são armazenados timestamps e chaves estrangeiras conectando a dimensões de data calendário.

Cada linha em uma Tabela Fato corresponde a um evento de medição. A ideia de que um evento de medição no mundo físico tem um relacionamento de um para um com uma única linha na tabela de fatos correspondente é um princípio fundamental para a modelagem dimensional. Todo o resto é construído a partir dessa premissa (KIMBALL e ROSS, 2013).

Tabelas Fato são a figura central de qualquer modelo dimensional. Toda Tabela Fato deve possuir uma única e explícita granularidade definida. A granularidade de uma Tabela Fato deve ser definida durante o processo de modelagem. Kimball e Ross (2010) recomendam que a definição da granularidade (explicitar exatamente o que uma Tabela Fato representa) seja a primeira ação a ser realizada na modelagem de uma Tabela Fato. Podem ser feitas declarações atômicas ou de alto nível, representando agrupamentos e sumarizações. Após definir a granularidade, deve-se então definir precisamente as dimensões possíveis associadas.

Kimball e Ross (2010) recomendam que os detalhes mais atômicos disponíveis nos sistemas de origem devem ser refletidos no DW por meio de Tabelas Fato. Um registro fato (fact record) em um modelo dimensional é criado como uma resposta 1:1 para a medida de um evento em um processo de negócio específico. Tabelas Fato são definidas pela física do mundo real.

image-1646673540968.png

Os fatos de uma Tabela Fato devem ser “Verídicos à Granularidade”. Por exemplo, os seguintes fatos são exemplos apropriados para a declaração "line item of a doctor’s bill”:

Outros fatos, como “Valor cobrado no ano até a data corrente para o paciente para todos os tratamentos” não são Verídicos. Neste caso, quando aplicações de BI combinam registros de fato arbitrariamente, estes Fatos Inverídicos produzem resultados sem sentido e inúteis. Olhando desta maneira, este tipo de fato é perigoso pois induz usuários de negócio a erros. Este tipo de fato agregado deve ser omitido do design do DW e calculado diretamente na aplicação de BI (KIMBALL e ROSS, 2013).

Como os dados de medição são esmagadoramente o maior conjunto de dados, eles não devem ser replicados em vários locais para várias funções organizacionais na organização. Permitir que usuários de negócios de várias organizações acessem um único repositório centralizado para cada conjunto de dados garante o uso de dados consistentes em toda a empresa (KIMBALL e ROSS, 2013).

É teoricamente possível que um fato medido seja textual; no entanto, a condição raramente surge. Na maioria dos casos, uma medida textual é uma descrição de algo e é extraída de uma lista discreta de valores. O designer deve fazer todos os esforços para colocar os dados textuais em dimensões onde possam ser correlacionados de forma mais eficaz com os outros atributos de dimensão textual. Você não deve armazenar informações textuais redundantes em tabelas de fatos. A menos que o texto seja exclusivo para cada linha na tabela de fatos, ele pertence à tabela de dimensão. Um fato de texto verdadeiro é raro porque o conteúdo imprevisível de um fato de texto, como um comentário de texto de forma livre, torna-o quase impossível de ser analisado (KIMBALL e ROSS, 2013).

Tabelas Fato correspondem a medidas resultantes de eventos observáveis, e não a demandas de relatórios específicos (KIMBALL e ROSS, 2013).

EDW e Modelagem Dimensional

Tabela de Dimensão

Tabelas de dimensão são companheiras integrais de Tabelas Fato. Tabelas de dimensão possuem descrições textuais que descrevem o contexto associado à medida realizada pelo processo de negócio. Elas descrevem o “quem, o quê, onde, quando, como e porque”, associado ao evento. Como ilustrado abaixo, tabelas de dimensão geralmente possuem muitos atributos. Não é incomum que uma tabela de dimensão possua de 50 a 100 atributos, embora algumas possuam apenas uma quantidade reduzida (Kimball e Ross, 2013).

image-1646407776464.png

Os atributos das dimensões servem como a fonte primária de restrições em consultas, agrupamentos e rótulos para colunas de relatórios. Por exemplo, quando um usuário deseja ver o valor vendido por marca, a coluna “marca” deve estar disponível como um atributo da dimensão associada (Kimball e Ross, 2013).

Os atributos devem consistir em palavras reais em vez de abreviações. Você deve se esforçar para minimizar o uso de códigos em tabelas de dimensão, substituindo-os por atributos textuais mais detalhados. Às vezes, os códigos ou identificadores operacionais têm um significado legítimo de negócio para os usuários, ou são requeridos ao se comunicar com a área operacional. Nestes casos, os códigos devem aparecer como atributos de dimensão explícitos, além dos atributos textuais de fácil interpretação. Códigos operacionais às vezes têm inteligência embutida. Por exemplo, os primeiros dois dígitos podem identificar a linha de negócios, enquanto os próximos dois dígitos podem identificar a região global. Em vez de forçar os usuários a interrogar ou filtrar em substrings dentro dos códigos operacionais, extraia os significados incorporados e apresente-os aos usuários como atributos de dimensão separados que podem ser facilmente filtrados, agrupados e reportados (Kimball e Ross, 2013).

Kimball e Ross (2013) mostram que quanto mais granular é o dado, maior a sua dimensionalidade. Deste modo, o dado deve ser armazenado em um DW em sua menor granularidade e maior número de dimensões possíveis. Isso deve ser feito para que o usuário de negócio tenha a maior gama possível de possibilidades de filtros e agrupamentos na elaboração de relatórios ad-hoc.

Embora seja aceitável, relacionamentos entre dimensões devem ser evitados. Na maioria dos casos, as correlações entre dimensões (Outrigger Dimensions) devem ser denotadas por meio de Tabelas Fato (Kimball e Ross, 2013).

Quando as dimensões são separadas, alguns designers desejam criar uma pequena tabela com apenas as duas chaves de dimensão para mostrar a correlação sem usar a tabela de fato. Em muitos cenários, essa tabela bidimensional é desnecessária. Não há razão para evitar a tabela fato para responder a esta consulta de relacionamento. As tabelas fato são incrivelmente eficientes porque contêm apenas chaves de dimensão e medições, juntamente com a dimensão degenerada ocasional. A tabela fato é criada especificamente para representar as correlações e os relacionamentos muitos para muitos entre as dimensões (Kimball e Ross, 2013).

EDW e Modelagem Dimensional

Star Schema

Agora que você entende as Tabelas Fato e Dimensões, é hora de reunir os blocos de construção em um modelo dimensional, conforme mostrado na figura abaixo. Cada processo de negócio é representado por um modelo dimensional que consiste em uma Tabela Fato contendo os dados numéricos do evento medido, cercada por um grupo de tabelas de dimensão, com o contexto que era verdadeiro no momento em que o evento ocorreu. Essa estrutura característica em forma de estrela costuma ser chamada de junção em estrela (Star Join) (KIMBALL e ROSS, 2013).

image-1646673024351.png

 

EDW e Modelagem Dimensional

Tabela Fato sem Fato

Tabela Fato sem fato (Factless Fact Tables) são Tabelas Fato que não possuem nada além de chaves estrangeiras para dimensões. O primeiro tipo de Factless Table diz respeito a uma tabela que armazena eventos. Diversas Tabelas Fato para rastreamento de eventos tornam-se Tabelas Fato sem fato. Um exemplo seria uma Tabela Fato para armazenar atendimentos a estudantes em uma faculdade, como pode ser visto na figura abaixo:

image-1646407279435.png

Esse tipo de tabela torna-se uma Tabela Fato sem fato, pois não existem fatos óbvios gerados a cada atendimento de um estudante. Devido a ausência de fatos, e no intuito de melhorar a legibilidade de instruções SQL sobre esse tipo de tabela, alguns engenheiros de dados optam por incluir um fato fictício ao final da tabela, com valor constante 1, por exemplo, “atendimento”.

Um segundo tipo de Tabela Fato sem fato é denominado tabela de cobertura (coverage table). Uma tabela de cobertura típica é mostrada abaixo:

 

image-1646407348510.png

Tabelas de cobertura são frequentemente necessárias quando as Tabelas Fato principais são esparsas. A figura acima mostra também uma tabela de vendas (Sales Fact) que armazena as vendas de produtos em lojas em dias particulares, sob condições diversas de promoção. A Tabela Fato principal responde diversas perguntas de negócio interessantes, mas não pode dizer nada sobre coisas que não ocorreram. Por exemplo, não pode responder perguntas como: “Quais produtos estavam em promoção, mas não venderam?”, pois a tabela possui apenas produtos que foram vendidos (Kimball e Ross, 2013).

 

EDW e Modelagem Dimensional

Tabela Fato de Snapshot Periódico

Uma linha em uma Tabela Fato de Snapshot Periódico (Periodic Snapshot Fact Table) sumariza diversas medidas de eventos ocorridos sobre um período pré-definido, como um dia, uma semana, ou um mês. Neste caso, o grão é o período, não a transação individual. Este tipo de tabela possui muitos fatos porque qualquer evento de medição consistente com a granulação da tabela de fatos é permitido. São tabelas geralmente uniformemente densas em suas chaves estrangeiras, pois mesmo que nenhuma atividade tenha ocorrido no período, uma linha é tipicamente inserida para cada fato, contendo zero ou null (Kimball e Ross, 2013).

EDW e Modelagem Dimensional

Fatos Conformados

Se a mesma medida aparece em diferentes Tabelas Fato, deve ser tomado o devido cuidado para que as definições técnicas dos fatos sejam idênticas. Se fatos separados são consistentes, tais fatos conformados devem possuir a mesma nomenclatura. Mas se os fatos são incompatíveis, eles devem possuir nomenclaturas diferentes, que servirão como alerta aos usuários de negócio (Kimball e Ross, 2013).

EDW e Modelagem Dimensional

Chaves Dimensionais

Se fatos são medidas reais geradas rapidamente, concluímos que Tabelas Fato criam uma situação de relacionamento muitos-para-muitos (M:N) entre as dimensões. Muitos clientes compram muitos produtos em diversas lojas em diversos momentos (KIMBALL e ROSS, 2010).

Deste modo, modelamos as medidas como Tabelas Fato com diversas chaves estrangeiras (Foreign Key - FK), referenciando as entidades de contexto (dimensões). E as tabelas de dimensões (entidades de contexto) possuem, cada uma, a sua chave primária (Primary Key - PK) (KIMBALL e ROSS, 2010).

Uma Tabela Fato em um modelo dimensional Star Schema é constituída, além das medidas, por múltiplas FKs, cada uma pareada com a chave primária em uma dimensão. Note que este design possibilita às tabelas de dimensão possuírem chaves primárias não existentes na Tabela Fato. Esta situação é consistente com a manutenção da integridade referencial e apropriada para a modelagem dimensional (KIMBALL e ROSS, 2010).

No mundo real, existem diversas razões convincentes para a construção de pares FK-PK como chaves substitutas (Surrogate Keys), que são apenas números inteiros sequenciais. É um grande erro definir chaves em um DW com base em chaves naturais (Natural Keys), provenientes das fontes operacionais (KIMBALL e ROSS, 2010).

Ocasionalmente, uma medida perfeitamente válida poderá envolver alguma dimensão ausente. Talvez, em algumas situações, um produto poderá ser vendido a um cliente por meio de uma transação sem uma loja definida. Neste caso, ao invés de armazenarmos null na FK de loja, podemos manter um registro especial na dimensão loja, com o valor “No Store”, e utilizá-lo para esta finalidade, por exemplo (KIMBALL e ROSS, 2010).

Logicamente, uma Tabela Fato não precisa de uma chave primária. Dependendo da situação, duas observações legítimas poderão ser representadas de forma idêntica na Tabela Fato. Da perspectiva prática, esta é uma ideia terrível, pois teremos muita dificuldade em separar tais registros por meio da utilização de instruções SQL. Será difícil verificar a qualidade dos dados se diversos registros forem representados de forma idêntica em nossa Tabela Fato (KIMBALL e ROSS, 2010).

EDW e Modelagem Dimensional

Tabela Fato Transacional

De acordo com Kimball e Ross (2013) uma Tabela Fato Transacional (Transaction Fact Table) é um tipo de tabela fato onde são mantidos os fatos na menor granularidade possível. Neste caso, é mantida uma transação para cada evento real. Uma Tabela Fato é do tipo transacional se:

A quantidade de registros da tabela é a mesma da origem.

EDW e Modelagem Dimensional

Tabela Fato de Snapshot Acumulado

De acordo com (Kimball e Ross, 2013), uma Tabela Fato de Snapshot Acumulado (Accumulating Snapshot Fact Table) é menos frequente que as demais e corresponde a um processo previsível, cujos início e fim são bem definidos. Capturam os resultados de eventos-chave em uma relação de processos relacionados. As linhas da tabela são carregadas quando o primeiro evento ocorre, ou quando um marco histórico é alcançado. Diferentemente de outros tipos de Tabelas Fato, neste caso, linhas pré-existentes são atualizadas para refletir resultados correntes, ou acumulados de cada evento.

EDW e Modelagem Dimensional

Natural Key

Uma Natural Key (NK) é uma chave única, composta por uma ou mais colunas, que identificam um registro unicamente, possuindo significado para o negócio. Uma NK possui relação semântica com os demais atributos em uma relação. Ex. CPF, CEP, RG, etc.

EDW e Modelagem Dimensional

Dimensões de Etapa (Step Dimensions)

Processos sequenciais, como eventos de página da Web, normalmente têm uma linha separada em uma tabela de fatos para cada etapa de um processo. Para saber onde a etapa individual se encaixa na sessão geral, é usada uma dimensão de etapa que mostra qual número de etapa é representado pela etapa atual e quantas etapas a mais foram necessárias para concluir a sessão  (Kimball e Ross, 2013).

EDW e Modelagem Dimensional

Tabelas Fato Agregadas

Em adição às Tabelas Fato que armazenam dados atômicos relativos a fatos únicos de processos, tabelas agregadas são muitas vezes criadas. Essas tabelas combinam métricas de múltiplos processos em um nível comum de detalhe. São tabelas complementares às Tabelas Fato detalhadas, e não substitutas (KIMBALL e ROSS, 2013).

Agregações necessariamente agrupam e/ou removem dimensões presentes em Tabelas Fato atômicas. Deste modo, agregações sempre devem ser utilizadas juntamente com os dados atômicos, visto que estes possuem dimensões mais detalhadas.

EDW e Modelagem Dimensional

Fatos Aditivos

No coração de qualquer Tabela Fato existe uma lista de fatos que representam medidas. Como a maioria das Tabelas Fato são grandes, com milhões ou até bilhões de registros, dificilmente utilizaremos um único registro para responder a alguma questão de negócio. Ao invés disso, geralmente recuperamos uma grande quantidade de registros, comprimidos em um formato amigável de soma (adição), contagem, média, valor máximo, valor mínimo, etc. Mas por questões práticas, o formato mais utilizado, de longe, é a soma. Deste modo, sempre que possível, devemos armazenar fatos aditivos (que permitam a soma). Deste modo, no exemplo da mercearia, não precisamos armazenar o preço unitário de um produto. Pois conseguiremos este valor simplesmente dividindo o valor da compra (dollar sales) pela quantidade comprada (unit sales) (KIMBALL e ROSS, 2010).

Alguns fatos, como saldos bancários e níveis de estoque, representam intensidades difíceis de expressar em um formato aditivo. Neste caso, tratamos este tipo de fato semi-aditivo como se fossem aditivos, mas antes de apresentar a informação para usuários de negócio, dividimos a resposta pela quantidade de períodos para termos o resultado correto. Esta técnica é chamada de média sobre o tempo (averaging over time) (KIMBALL e ROSS, 2010).

Algumas Tabelas Fato representam medições de eventos sem fato, esse tipo de tabela é chamada Tabela Fato sem Fato (factless fact tables). O exemplo clássico é o registro de atendimentos de estudantes de uma determinada turma para um dia em particular. As dimensões podem ser “dia”, “estudante”, “professor”, “curso” e “local”, mas veja que não há uma métrica claramente definida (KIMBALL e ROSS, 2010).

EDW e Modelagem Dimensional

Dimensões Multivaloradas e Tabelas Ponte (bridge table)

Em um esquema dimensional clássico, cada dimensão anexada a uma tabela de fatos tem um único valor consistente com a granulação da tabela de fatos. Mas há uma série de situações em que uma dimensão é legitimamente multivalorada. Por exemplo, um paciente que recebe um tratamento de saúde pode ter vários diagnósticos simultâneos. Nesses casos, a dimensão multivalorada deve ser anexada à tabela de fatos por meio de uma chave de dimensão de grupo para uma tabela de ponte (bridge table) com uma linha para cada diagnóstico simultâneo em um grupo (Kimball e Ross, 2013).

EDW e Modelagem Dimensional

Tabelas Fato Consolidadas

Frequentemente, é conveniente combinar fatos de vários processos em uma única Tabela Fatos consolidada se eles puderem ser expressos na mesma granulação. Por exemplo, dados de vendas podem ser consolidados com previsões de vendas em uma única Tabela Fatos para simplificar a tarefa de analisar os valores reais e os previstos, em comparação com a realização de uma operação de drill-across, usando Tabelas Fato separadas. Tabelas Fatos consolidadas aumentam a carga do processamento de ETL, mas facilitam a carga analítica nos aplicativos de BI. Esse tipo de Tabela Fato deve ser considerada para métricas frequentemente analisadas em conjunto (KIMBALL e ROSS, 2013).

Quando os fatos de vários processos de negócios são combinados em uma tabela de fatos consolidada, eles devem estar no mesmo nível de granularidade e dimensionalidade. Como os fatos separados raramente vivem naturalmente em um grão comum, você é forçado a eliminar ou agregar algumas dimensões para suportar a correspondência um-para-um, mantendo os dados atômicos em tabelas de fatos separadas. As equipes de projeto não devem criar fatos ou dimensões artificiais na tentativa de forçar a consolidação de dados de fatos com granulação diferente (KIMBALL e ROSS, 2013).

Tabelas Fato consolidadas contêm chaves estrangeiras para dimensões conformadas reduzidas, bem como fatos agregados criados pela soma de medidas de tabelas fato mais atômicas (KIMBALL e ROSS, 2013).

EDW e Modelagem Dimensional

Fatos Agregados e Atributos de Dimensões

Usuários de negócio geralmente estão interessados em restringir a dimensão do cliente com base em métricas de desempenho agregadas, como filtrar todos os clientes que gastaram mais de um determinado valor no ano passado ou talvez durante a vida do cliente. Fatos agregados podem ser colocados em uma dimensão para restrição e como rótulos de linha para relatórios. As métricas geralmente são apresentadas como intervalos em faixas na tabela de dimensões. Os atributos de dimensão que representam as métricas de desempenho agregadas adicionam carga ao processamento de ETL, mas aliviam a carga analítica na camada de BI (Kimball e Ross, 2013).

EDW e Modelagem Dimensional

Dimensões Genéricas Abstratas

Alguns modeladores são atraídos por dimensões genéricas abstratas. Por exemplo, seus esquemas incluem uma única dimensão de localização genérica em vez de atributos geográficos incorporados nas dimensões de loja, depósito e cliente. Da mesma forma, sua dimensão de pessoa inclui linhas para funcionários, clientes e contatos de fornecedores porque todos são seres humanos, independentemente de serem significativamente diferentes devido aos atributos coletados para cada tipo. Dimensões genéricas abstratas devem ser evitadas em modelos dimensionais.

Os conjuntos de atributos associados a cada tipo geralmente diferem. Se os atributos forem comuns, como um estado geográfico, eles devem ser rotulados de forma exclusiva para distinguir o estado de uma loja do estado de um cliente. Finalmente, despejar todas as variedades de locais, pessoas ou produtos em uma única dimensão invariavelmente resulta em uma tabela de dimensão maior. A abstração de dados pode ser apropriada no sistema de origem operacional ou no processamento ETL, mas afeta negativamente o desempenho e a legibilidade da consulta no modelo dimensional (Kimball e Ross, 2013).

EDW e Modelagem Dimensional

Dimensões de comentário

Em vez de tratar os comentários de forma livre como métricas textuais em uma tabela de fatos, eles devem ser armazenados fora da tabela de fatos em uma dimensão de comentários separada (ou como atributos em uma dimensão com uma linha por transação se a cardinalidade dos comentários corresponder ao número de transações exclusivas) com uma chave estrangeira correspondente na tabela de fatos (Kimball e Ross, 2013).

EDW e Modelagem Dimensional

Dimensões de Auditoria

Quando uma linha da tabela de fatos é criada pelo processo de ETL, é útil criar uma dimensão de auditoria contendo os metadados de processamento de ETL conhecidos no momento. Uma linha de dimensão de auditoria simples pode conter um ou mais indicadores básicos de qualidade de dados, talvez derivados do exame de um esquema de evento de erro que registra violações de qualidade de dados encontrados durante o processamento dos dados. Outros atributos de dimensão de auditoria úteis podem incluir variáveis de ambiente que descrevem as versões do código ETL usadas para criar as linhas de fatos ou os carimbos de tempo de execução do processo ETL (KIMBALL e ROSS, 2013).

Essas variáveis de ambiente são especialmente úteis para fins de conformidade e auditoria porque permitem que as ferramentas de BI façam uma busca detalhada para determinar quais linhas foram criadas com quais versões do software ETL.

EDW e Modelagem Dimensional

Dimensão Conformada

Uma Dimensão Conformada (também chamada de Dimensão Compartilhada ou Dimensão Mestre) é uma dimensão que possui o mesmo significado para todas as Tabelas Fato que podem fazer junção à mesma. Uma das maiores responsabilidades em manter o DW está em estabelecer, publicar, manter e fazer valer as dimensões conformadas (KIMBALL e ROSS, 2010).

Tabelas de dimensão são conformes quando atributos com o mesmo nome em tabelas diferentes possuem o mesmo significado e conteúdo. Informações de diferentes Tabelas Fato podem ser combinadas em um único relatório por meio de atributos de dimensões conformadas. Quando um atributo conformado é utilizado como um label (isto é, no GROUP BY da instrução SQL), os resultados de diferentes Tabelas Fato podem ser alinhados na mesma linha em um relatório drill-across (KIMBALL e ROSS, 2013).

O estabelecimento de uma dimensão conformada é um passo muito importante. Uma dimensão conformada de Clientes, por exemplo, é uma tabela mestre de clientes com uma chave e atributos bem definidos e íntegros. É provável que a dimensão conformada de clientes seja aglomerado de dados de vários sistemas legados e possivelmente de fontes externas. O campo de endereço, por exemplo, deve ser constituído do endereço mais completo e atualizado possível para cada cliente (KIMBALL e ROSS, 2010).

A dimensão conformada de produtos, por exemplo, é a lista mestre de todos os produtos comercializados pela empresa, incluindo todos os atributos do produto e todas as suas agregações, como categoria e departamento. Uma boa dimensão de produtos, assim como uma boa dimensão de clientes, deve ter ao menos 50 atributos textuais (KIMBALL e ROSS, 2010).

Idealmente, a dimensão conformada de localização deve ser baseada em pontos específicos do mapa, como endereços específicos de ruas ou até mesmo latitudes e longitudes. Pontos específicos no espaço se acumulam em todas as hierarquias geográficas concebíveis, incluindo cidade-região-estado-país, bem como códigos postais, territórios e regiões de vendas (KIMBALL e ROSS, 2010).

A dimensão conformada de data quase sempre será uma tabela de dias individuais, abrangendo uma década ou mais. Cada dia terá muitos atributos úteis extraídos dos calendários legais dos vários estados e países com os quais a empresa lida, bem como períodos fiscais especiais e temporadas de marketing relevantes (KIMBALL e ROSS, 2010).

Dimensões conformadas são extremamente importantes para o DW. Sem uma adesão estrita às dimensões conformadas, o DW não pode funcionar como um todo integrado.

EDW e Modelagem Dimensional

Dimensões reduzidas (Shrunken Dimensions)

Dimensões reduzidas são dimensões conformadas que são um subconjunto de linhas e/ou colunas de uma dimensão conformada original. São necessárias ao construir Tabelas Fato agregadas. Elas também são necessárias para processos de negócios que capturam dados naturalmente em um nível mais alto de granularidade, como uma previsão por mês e marca (em vez da data mais atômica e do produto associado aos dados de vendas). Outro caso de subconjunto de dimensão conformada ocorre quando duas dimensões estão no mesmo nível de detalhe, mas uma representa apenas um subconjunto de linhas (Kimball e Ross, 2013).

EDW e Modelagem Dimensional

Slowly Changing Dimensions

Slowly Changing Dimensions (SCD) consiste em técnicas para gerenciamento da história de dados dimensionais em um DW. Deve-se ter em mente que as dimensões associadas às Tabelas Fato são afetadas com o passar do tempo. A mudança nos valores de dimensões pode ocorrer às vezes, em alguns casos, meramente para a correção de erros. Mas, às vezes, uma mudança em alguma descrição representa uma mudança verdadeira ocorrida em algum ponto do tempo, como a mudança do nome de um produto, ou de um cliente, por exemplo. Como tais mudanças ocorrem de forma inesperada, e esporadicamente, e com bem menos frequência que medidas em Tabelas Fato, o tópico é denominado Slowly Changing Dimensions (SCDs) (Kimball e Ross, 2013).

Os representantes de governança e administração de dados da empresa devem estar ativamente envolvidos nas decisões sobre o tratamento de mudanças em valores de dimensões; A TI não deve fazer determinações por conta própria (Kimball e Ross, 2013).

Kimball e Ross (2013) afirmam que são necessárias apenas três respostas básicas em caso de mudança de descrição em algum atributo de dimensão:

É comum uma mesma dimensão possuir estratégias de tratamento de mudanças específicas para cada atributo (Kimball e Ross, 2013).

EDW e Modelagem Dimensional

Dimensões Degeneradas

Em diversas situações onde a granularidade é um filho de algum evento maior, a chave natural deste evento pai acaba tornando-se um órfão durante o design. No exemplo dado pela Figura 1, a granularidade definida é uma linha da nota de venda (ticket). O número do ticket (ticket number) é a chave natural da nota de venda. Como os dados do ticket foram espalhados em dimensões de contexto, o número do ticket foi deixado para trás, sem atributos específicos. Neste caso, o número do ticket é incluído diretamente na Tabela Fato. Chamamos esta situação de dimensão degenerada (degenerate dimension). O número do ticket é útil pois é a cola que segura os itens presentes em uma mesma nota (KIMBAL e ROSS, 2013).

EDW e Modelagem Dimensional

Mantendo a Granularidade na Modelagem Dimensional

Embora teoricamente qualquer mistura de fatos possa ser incluída em uma mesma tabela, um design dimensional apropriado permite apenas fatos na mesma granularidade (mesma dimensionalidade) coexistirem em uma mesma Tabela Fato. Uma granularidade uniforme garante que todas as dimensões serão utilizadas por todos os fatos, reduzindo drasticamente a possibilidade de equívocos durante a combinação de dados de diferentes granularidades. Por exemplo, geralmente não faz sentido adicionar dados diários a dados anuais. Quando você tem fatos em duas granularidades diferentes, coloque-os em tabelas separadas (KIMBALL e ROSS, 2010).

O poder do modelo dimensional vem da sua aderência a uma granularidade específica. Uma definição clara da granularidade de uma Tabela Fato possibilita a definição dos modelos físico e lógico. Uma definição confusa ou imprecisa impõe ameaças em todos os aspectos de design, desde os processos de ETL até as ferramentas de visualização que farão uso do dado (KIMBALL e ROSS, 2010).

A granularidade de uma Tabela Fato é a definição de negócio de uma medida que resulta na criação de um registro fato (fact record). Toda a definição de granularidade deve ser iniciada do menor nível possível (atômico), relativo para o evento gerador do fato. Manter aderência à granularidade significa construir Tabelas Fato em torno de cada evento de medição de processos de negócio atômicos. Essas tabelas são simples de serem implementadas, mas proveem uma fundação durável e flexível, capaz de endereçar questões de negócio e relatórios do dia-a-dia (KIMBALL e ROSS, 2010).

EDW e Modelagem Dimensional

Pense Dimensionalmente

Ao reunir os requisitos para uma iniciativa de DW/BI, você precisa ouvir e em seguida, sintetizar as descobertas em torno dos processos de negócios. Quando especificar o escopo de um projeto, mantenha o foco em um único processo de negócio por projeto, evitando a elaboração de dashboards com inúmeros processos de negócio associados (KIMBALL e ROSS, 2013).

Embora seja fundamental que a equipe de DW/BI se concentre nos processos de negócios, é igualmente importante manter o alinhamento com a equipe de negócios. Devido às políticas históricas de financiamento da TI, a empresa pode estar mais familiarizada com implantações de soluções a nível departamental. Você precisa mudar a mentalidade dos envolvidos para a implementação de soluções de DW/BI para uma perspectiva de processos de negócios. Felizmente, gestores de negócio geralmente adotam essa abordagem porque reflete seu pensamento sobre os principais indicadores de desempenho. Além disso, eles viveram com inconsistências, debates incessantes e reconciliações sem fim causadas pela abordagem departamental, então eles estão prontos para uma nova abordagem (KIMBALL e ROSS, 2013).

Ao atuar com as lideranças de negócios, classifique cada processo em escala de valor e viabilidade e, em seguida, ataque primeiramente os processos com as pontuações de maior impacto e viabilidade. Embora a priorização seja uma atividade conjunta com o negócio, sua compreensão subjacente dos processos de negócios da organização é essencial para sua eficácia e subsequente capacidade de ação (KIMBALL e ROSS, 2013).

Os programas de governança de dados devem se concentrar primeiro nas dimensões principais. Dependendo do setor da indústria, a lista pode incluir data, cliente, produto, funcionário, aluno, corpo docente e assim por diante. Pensar nos substantivos centrais usados para descrever o negócio se traduz em uma lista de esforços de governança de dados a serem liderados por especialistas no assunto e representantes da comunidade de negócios. Estabelecer responsabilidades de governança de dados para esses substantivos é a chave para implementar dimensões que entreguem consistência e atendam às necessidades de negócios de filtragem analítica, agrupamento e rotulagem. Dimensões robustas se traduzem em sistemas DW/BI robustos (KIMBALL e ROSS, 2013).

Modelos dimensionais devem ser elaborados em colaboração com a área de negócios, e não por indivíduos que não entendem completamente o negócio e suas necessidades (KIMBALL e ROSS, 2013).

EDW e Modelagem Dimensional

Schemas de Eventos de Erros

Gerenciar a qualidade de dados em um Data Warehouse requer um sistema abrangente de qualidade que testa os dados à medida que fluem dos sistemas de origem para a plataforma de BI. Quando o script de qualidade de dados detecta um erro, esse evento é registrado em um esquema dimensional especial que está disponível apenas no backend do processo de ETL. Esse esquema consiste em uma tabela de fatos de evento de erro cuja granulação é o evento de erro individual e uma tabela de fatos de detalhes de evento de erro associada cuja granulação é cada coluna em cada tabela que participa de um evento de erro (KIMBALL e ROSS, 2013).

EDW e Modelagem Dimensional

Surrogate Key

Uma Surrogate Key (SK), ou chave substituta, assim como uma Natural Key (NK), é um identificador único em uma tabela, capaz de identificar unicamente cada registro. No entanto, uma SK não possui nenhuma relação semântica com os demais atributos de uma tabela. É apenas uma valor, geralmente inteiro e sequencial, gerado com o propósito de ser a chave primária da relação.

Kimball e Ross (2010) recomendam que todas as Tabelas Dimensão tenham uma SK, mesmo aquelas com tratamento SCD do Tipo 1. Isto irá isolar o DW de surpresas ao incorporar novos dados provenientes de fontes com suas próprias ideias sobre chaves. Ainda de acordo com os autores, a utilização de SKs tornará o banco de dados mais rápido.

Existem momentos em que a utilização de SKs em Tabelas Fato (FSKs) é importante. Embora FSKs não tenham utilidade para o negócio, elas possuem diversas vantagens internamente para o DW:

Uma NK pode não ser durável, visto que não teremos controle sobre possíveis mudanças de chave nas fontes de origem. NKs podem ser originárias de mais de uma fonte, e neste caso, cada fonte de dados pode utilizar uma NK diferente para um mesmo processo de negócio.

EDW e Modelagem Dimensional

Data Profiling

Ao longo do processo de modelagem dimensional, a equipe precisa desenvolver uma compreensão cada vez maior da estrutura, conteúdo, relacionamentos e regras de derivação dos dados de origem. É necessário verificar se os dados estão em um estado utilizável, ou se ao menos suas falhas podem ser gerenciadas, entendendo o que é necessário para convertê-los para o modelo dimensional. O objetivo da atividade de data profiling (verificação do perfil dos dados) é a exploração do conteúdo e dos relacionamentos reais dos dados no sistema de origem, ao invés de depender de documentação, talvez incompleta ou desatualizada.