Abordagem tradicional versus armazenamento de dados orientado por metadados
De sistemas de informações de gerenciamento monolíticos a data warehouses e data lakes modelados dimensionalmente, vimos mudanças massivas na forma como as organizações coletam, processam, armazenam e analisam seus dados ao longo dos anos. Cada salto à frente em tecnologia e técnicas foi guiado por um esforço consciente para introduzir maior agilidade, acessibilidade e escalabilidade em seus relatórios e análises.
Com razão, em um ambiente operacional onde as preferências do cliente e as condições de mercado prevalecentes podem mudar instantaneamente, as empresas geralmente precisam visualizar e consultar dados em horas para obter essa vantagem crucial sobre os concorrentes. Uma arquitetura de dados ágil é essencial para atingir esse objetivo.
Introduzir o abordagem baseada em metadados. Usando Astera DW Builder, você pode criar modelos de dados abrangentes que integram o design, a lógica e mapeamentos de dados que constituem a maior parte do desenvolvimento do data warehouse e, em seguida, replicam todo o esquema em uma nuvem ou banco de dados local de sua escolha. A partir daí, você está pronto para preencher, consumir ou atualizar seu data warehouse com facilidade.
No final do dia, você tem um processo rápido e responsivo criado para fornecer insights acionáveis de acordo com sua linha do tempo. Compare nossa abordagem de como as coisas costumavam ser feitas e você verá as vantagens dos metadados e o enorme valor que nosso produto traz para o processo de desenvolvimento.
Por que o data warehouse precisa evoluir
A abordagem tradicional
Quando falamos sobre o abordagem tradicional, nos referimos ao desenvolvimento do estilo cascata, que dominou este espaço desde os anos 90. Nesse processo, o data warehouse é construído em uma sequência meticulosamente planejada de fases, que são as seguintes:
- Recolha de requisitos: Neste estágio, os desenvolvedores se reunirão com analistas de negócios e outros usuários finais para documentar que tipo de BI é necessário.
- projeto: Depois de estudar os requisitos, os desenvolvedores projetarão uma arquitetura de protótipo que englobe a estrutura física / lógica e os mapeamentos de dados necessários para preencher e manter
- Crie acessibilidade: Os desenvolvedores devem então decidir como acessar os dados do warehouse para relatórios e análises. Os dados podem ser disponibilizados por meio de uma plataforma de BI front-end, como PowerBI ou Tableau, ou uma solução personalizada desenvolvida para atender às necessidades da organização.
- Teste: Envolve uma parte de QA para identificar e resolver quaisquer bugs que possam prejudicar a usabilidade / desempenho. Bem como o teste de aceitação do usuário para garantir que o data warehouse atenda ao propósito declarado.
Seu data warehouse não é um projeto. É um processo.
A limitação mais significativa da abordagem em cascata é que o desenvolvimento é voltado para uma solução acabada apresentada como a resposta a todos os requisitos de BI da organização. Essa abordagem de alto custo não leva em consideração a natureza em constante mudança dessas necessidades.
- Embora os requisitos de negócios sejam reunidos com base nas necessidades atuais dos usuários finais, eles também devem abranger quaisquer cenários possíveis que podem se desenvolver em meses ou até anos a partir de agora. É claro que tentar prever o estado futuro de sua empresa é mais fácil de falar do que fazer.
- Como há tantas transferências no processo de desenvolvimento de analistas de negócios para desenvolvedores, arquitetos e especialistas em ETL, sempre há a chance de que os requisitos sejam mal interpretados. Como resultado, a solução acabada pode estar longe do que foi acordado inicialmente, ou seja, o Assobio Chinês
- Também existe a possibilidade distinta de que os usuários finais possam não ter entendido seus requisitos em primeiro lugar. Eles podem ter subestimado os dados que precisam ser integrados.
- É claro que, como a maioria desses problemas só é identificada na fase de teste, qualquer correção aumentará o custo e os prazos do projeto.
Ok, mas o que torna a abordagem baseada em metadados melhor?
Vamos começar com o que entendemos por abordagem orientada por metadados, porque há muitas facetas de como tratamos o desenvolvimento de data warehouse em Astera Construtor DW.
Tudo começa com o modelo de dados
A primeira coisa a notar é que colocamos modelagem de dados bem na frente e no centro de nosso produto. Nosso designer de modelo de dados abrangente e livre de código permite que os usuários projetem cada elemento de seu EDW em um único processo de ponta a ponta. Imediatamente, isso remove as transferências sequenciais que caracterizam a abordagem em cascata. Em vez disso, o que você tem é um processo de design integrado que pode ser iniciado e gerenciado por uma única pessoa (se necessário).
Você provavelmente desejará ter usuários técnicos e não técnicos envolvidos na criação de seus modelos de dados e fluxos de ETL na prática. Este tipo de colaboração é intrinsecamente suportado em nosso produto, já que todos os elementos necessários para projetar um modelo de dados são gerenciados e configurados no nível de metadados. Esteja você modelando as entidades do sistema de origem ou configurando tabelas de fatos e dimensões individuais, tudo isso é possível interagindo diretamente com o modelo de dados usando conceitos definidos pelo negócio.
A grande vantagem aqui é que o usuário final pode realmente traduzir seus requisitos conceituais em um modelo de dados físico. Nesse caso, todos os relacionamentos de entidade, regras de negócios e convenções de nomenclatura são acordados durante a fase de design - em vez de esclarecidos no final, quando um protótipo é realmente apresentado. Outro benefício importante é que, à medida que o modelo é construído, o usuário final pode fornecer feedback imediato sobre quaisquer correções que precisem ser feitas ou ajustar seus requisitos iniciais com base no projeto de trabalho do data warehouse.
O resultado é um modelo de dados acabado que está alinhado com as necessidades da organização.
Trabalhe iterativamente para atender aos requisitos de BI
Nesta fase, vamos falar sobre desenvolvimento ágil e como ela difere da abordagem em cascata. Alguns valores fundamentais são valorizados nesta metodologia - colaboração (que abordamos), priorizando o software funcional sobre a documentação precisa e a capacidade de trabalhar rapidamente de acordo com os requisitos em constante mudança, em vez de um plano definido.
Os dois últimos pontos são críticos ao discutir como a abordagem baseada em metadados melhora o desenvolvimento do data warehouse. Nós mencionamos como é difícil criar uma documentação precisa que preveja perfeitamente quais serão seus requisitos de BI daqui a um ano ou até mais, então por que não começar a trabalhar imediatamente em uma implantação menor que atenda a uma necessidade de negócios atual.
Com Astera DW Builder, você adiciona esse tipo de agilidade ao seu data warehouse. Assim que um requisito urgente é identificado, sua equipe pode começar a trabalhar criando um modelo de dados que reflita os sistemas operacionais subjacentes que precisam ser analisados e um esquema para o data warehouse usado para consultar esses sistemas. Ao todo, o processo pode ser concluído em questão de dias ou até horas. No final, você tem uma arquitetura funcional que pode começar a fornecer percepções acionáveis para seus aplicativos front-end imediatamente.
Claro, conforme esses requisitos evoluem, você pode modificar seus modelos existentes adicionando novas entidades ou campos ao seu modelo de dados. Ou você pode criar um modelo de dados totalmente novo para um processo de negócios diferente que precisa ser investigado em profundidade. Com uma abordagem ágil em vigor, você acaba com um processo de desenvolvimento iterativo que é ideal para um ambiente de negócios que muda rapidamente.
Diga adeus à codificação manual
ETL é geralmente a parte mais demorada do desenvolvimento do data warehouse, pois os desenvolvedores devem garantir que todos os dados carregados no EDW estejam livres de duplicação ou outros problemas de qualidade de dados e que os tempos de carregamento sejam minimizados sempre que possível. Normalmente, o processo requer um esforço manual significativo, com os desenvolvedores escrevendo seu código do zero para se adequar às particularidades de cada pipeline de dados.
O ADWB vem completo com um componente de fluxo de dados que permite que você projete esses mapeamentos de data warehouse de origem para o nível de metadados. Começando com a variedade de conectores prontos para uso que permitirão que você recupere dados de sistemas de arquivos simples e APIs para esquemas de sistema de origem existentes construídos usando nosso designer de modelo de dados com facilidade.
Esta última funcionalidade é essencial porque elimina a necessidade de extrair dados diretamente de seus sistemas operacionais, o que consome recursos de computação valiosos em servidores de banco de dados críticos. Ele também cria uma camada adicional de segurança entre seus dados transacionais e o usuário final, já que você pode construir seus modelos de dados para refletir em tabelas e registros prontos para análise. Nosso produto também vem com um construtor Data Model Query dedicado, permitindo que você crie uma tabela de origem hierárquica contendo várias entidades de modelo de dados com base em relacionamentos existentes definidos no estágio de modelagem. Novamente, essa construção de consulta complexa não requer SQL real. As entidades relevantes são selecionadas e configuradas no nível de metadados.
O produto também cobre quando se trata de preparar e enriquecer seus dados de origem. O construtor de fluxo de dados oferece mais de uma centena de transformações integradas que ajudam a limpar, filtrar, substituir, analisar e validar quaisquer dados movidos para seu data warehouse. Portanto, você pode garantir que apenas dados prontos para análise de alta qualidade entrem em sua arquitetura de BI.
O mapeamento de dados é ainda mais acelerado por carregadores de fatos e dimensões dedicados que truncaram a simulação que exige muito tempo e as operações de pesquisa de dimensão complexas (em registros históricos são mantidos) para o mapeamento simples de arrastar e soltar. Basta conectar a tabela de destino à entidade relevante em seu modelo dimensional e pronto.
Assim que terminar de projetar os mapeamentos de dados de ponta a ponta, você pode executar o fluxo de dados. Nosso mecanismo ETL lerá os metadados e gerará automaticamente o código necessário para trazer os dados da origem ao destino. Oferecemos até recursos de agendamento e orquestração de fluxo de trabalho para ajudá-lo a automatizar essas operações de acordo com suas necessidades.
Teste simultaneamente antes da implantação
Com o ADWB, criamos testes contínuos na própria arquitetura da plataforma. Antes de implantar qualquer um de seus modelos de dados, você terá que verificar o design para garantir que cada entidade esteja configurada corretamente e que não haja campos em branco ou valores inconsistentes. Com o teste simultâneo implementado, você pode identificar rapidamente os erros em sua construção e corrigi-los antes que causem problemas para o usuário final.
Da mesma forma, implementamos registro em tempo real e notificações de erro durante a execução do fluxo de dados, para que quaisquer problemas em seus processos ETL possam ser identificados nos metadados. O resultado é uma arquitetura testada por estresse construída para lidar com até mesmo os casos de uso de BI mais complexos com facilidade.
Replique seu esquema em qualquer banco de dados líder.
Como os modelos de dados são criados no nível de metadados, eles não são codificados para integração com nenhuma plataforma específica. Essencialmente, o que você criou é um esquema independente de plataforma que pode ser replicado com facilidade em qualquer banco de dados de destino. Para tornar as coisas ainda mais fáceis, oferecemos suporte para liderança local e armazéns de dados em nuvem, para que você possa escolher construir seu data warehouse na infraestrutura que melhor se adapta às suas necessidades de BI.
Procurando aproveitar a escalabilidade e o desempenho de Amazon RedShift, estabeleça uma conexão com o banco de dados e encaminhe o engenheiro. Quer manter seus relatórios internamente? Selecione um provedor local, como SQL Server ou Oracle Database - a escolha é sua.
Compare esse processo com as implementações de alto custo favorecidas em cascata, onde qualquer atualização ou modificação exige outra rodada de desenvolvimento ponta a ponta, e fica claro qual método é mais adequado para BI moderno.
Experimente Data Warehousing Orientado por Metadados com Astera Construtor de DW
Você quer tirar proveito de nossa nova solução de armazenamento de dados empolgante? Entre em contacto com nossos especialistas para aprender mais sobre como nossa arquitetura orientada a metadados pode ajudá-lo a obter os resultados que você precisa ou para um demonstração personalizada para seu caso de uso específico.