Data Warehousing e o Desafio de Infraestrutura - dummies

A natureza de um data warehouse (que é composto principalmente, ou exclusivamente, de dados que vem de outro lugar, outro aplicativo bases de dados e é convertido em um recurso de dados) significa que ele não pode ficar sozinho como uma entidade independente dentro da sua organização.

O crescimento fenomenal da computação distribuída (Internet e intranet, bem como data warehousing dados internos e externos) resultou em uma mudança fundamental na forma como os aplicativos são construídos. Nos velhos tempos de mainframes e minicomputadores, um único sistema físico continha amplamente a infra-estrutura (sistemas operacionais, bancos de dados e sistemas de arquivos e gerentes de comunicações e transações).

< ! --1 ->

Com a computação distribuída agora, o modelo dominante (mesmo os mainframes e os minicomputadores geralmente fazem parte de um ambiente distribuído maior), a infraestrutura é distribuída em diferentes p Latforms em toda a sua empresa e possivelmente fora de sua empresa.

Quando você desenvolve qualquer aplicativo ou sistema, armazenagem de dados ou um aplicativo de processamento de transações mais tradicional, você possui dependências significativas em partes do ambiente geral sobre as quais você não possui controle direto. Aqui estão alguns exemplos específicos do data warehousing:

• Você projeta um data warehouse que, com base em requisitos de negócios e políticas de disponibilidade de dados de aplicativos, deve ter aproximadamente 25 gigabytes de dados novos e atualizados extraídos de várias fontes todas as noites e enviados pela rede para o plataforma de hardware na qual o data warehouse está sendo executado.

  Sua infraestrutura de rede corporativa ainda está subdimensionada. Após uma análise adicional, a rede não pode se aproximar de suportar o throughput necessário para mover os dados para o seu armazém na janela de tempo disponível.

• Durante a fase de escopo do projeto de data warehousing, você determina que uma estratégia de empurrão para atualizar o data warehouse é o modelo mais adequado a seguir. Para implementar uma estratégia de empurrão, você deve modificar cada aplicativo de origem para incluir o código que detecta quando esse aplicativo deve empurrar dados (enviar) para o data warehouse.

  As aplicações legadas que fornecem dados ao armazém são, infelizmente, tão difíceis de entender que uma política de não fazer alterações, a menos que absolutamente necessário esteja em vigor para cada aplicativo.

• Você decide prosseguir uma solução OLAP relacional (ou ROLAP) e executar uma série de benchmarks em relação a três produtos DBMS relacionais (RDBMS) para ver qual deles é compatível com o processamento de informações e decisões (em vez de processamento de transações).

  O produto que apresentou o menor desempenho em seus benchmarks é, infelizmente, também seu padrão corporativo, e qualquer banco de dados relacional instalado em qualquer lugar da sua empresa deve ser desta variedade, não importa como planeja usá-lo.

Pense conceitualmente (não se preocupe com os detalhes da implementação) nos estágios iniciais de um projeto de data warehousing, ou qualquer outro esforço de desenvolvimento de aplicativos - não é apenas aceitável, também é uma boa prática de desenvolvimento de sistemas.

Em algum momento, no entanto, você deve considerar hardware, software, custos, orçamento e outros tipos de restrições do mundo real. Antes de começar a construção, certifique-se de considerar tudo o que pode afetar seus projetos e planos para seu data warehouse.

Este projeto é muito parecido com a construção de uma casa. Você segue um processo pelo qual você determina suas necessidades e, em seguida, o arquiteto elabora planos. Os planos destacam os materiais que você precisa para suportar seus requisitos - garantindo que o produto acabado atinja a visão estabelecida no início.