Três Princípios de Desenvolvimento de Data Warehouse

O Gartner estima que cerca de 70 a 80 por cento dos projetos de inteligência de negócios recém-iniciados falham. Isso se deve a inúmeras razões, desde a má escolha da ferramenta até a falta de comunicação entre a TI e as partes interessadas do negócio. Tendo implementado com sucesso projetos de BI em todos os setores, espero compartilhar minhas experiências nesta postagem do blog e destacar as principais razões pelas quais os projetos de inteligência de negócios falham. Este artigo apresentará contramedidas à falha com base em três princípios que devem reger como os data warehouses são construídos. Seguir esses conceitos de data warehouse deve ajudá-lo como desenvolvedor de data warehouse a navegar na jornada de desenvolvimento, evitando os buracos comuns ou até mesmo os buracos das implementações de BI.

Implementação de Data Warehouse de Business Intelligence

Embora os critérios para um data warehouse de inteligência de negócios bem-sucedido variem de acordo com o projeto, certos mínimos são esperados e exigidos em todos os projetos. Aqui está uma lista dos principais atributos normalmente encontrados em um data warehouse de business intelligence bem-sucedido:

• Valor: Os projetos de inteligência de negócios podem durar muitos meses ou até anos. No entanto, é importante mostrar os benefícios de um data warehouse para as partes interessadas de sua empresa logo no início do projeto para garantir financiamento e interesse contínuos. Idealmente, as partes interessadas devem receber algum valor comercial significativo do novo sistema nas primeiras três semanas de um projeto.
• BI de autoatendimento: Os dias de espera da TI para atender às solicitações de dados ou realizar análises de dados acabaram. O sucesso de qualquer projeto de BI agora é medido por quão bem ele capacita os usuários de negócios a extrair valor do próprio sistema.
• Custo: Os projetos de BI geralmente têm custos iniciais de implementação relativamente altos. Para contrabalançar e compensar o alto custo inicial, é importante projetar armazéns com baixos custos de manutenção. Se o cliente precisar de uma equipe completa de desenvolvedores de BI para garantir/diagnosticar problemas de qualidade de dados, fazer alterações de rotina nos modelos de dados ou lidar com falhas de ETL, o sistema seria caro para o orçamento e correria o risco de ser desligado após algum tempo .
• Adaptabilidade: A capacidade de se adaptar às demandas de negócios em evolução é crucial. É importante ter em mente o incontável número de ferramentas de BI que estão disponíveis no mercado e o ritmo em que elas evoluem para incluir funcionalidades e recursos adicionais. Juntamente com o fato de que os negócios evoluem continuamente, os requisitos para o armazém mudarão; a adaptabilidade exige que os data warehouses sejam projetados para permitir o uso de ferramentas alternativas de BI, como diferentes back-ends ou ferramentas de visualização no futuro, e que sejam adaptáveis ​​a mudanças muitas vezes imprevistas nos requisitos.

Através da minha experiência na construção de soluções bem-sucedidas e, talvez ainda mais importante, no envolvimento em projetos fracassados, cheguei à conclusão de que três princípios-chave são fundamentais para aumentar a probabilidade de uma implementação bem-sucedida do sistema de inteligência de negócios. No entanto, antes de cobri-los em detalhes, vamos começar com algum contexto.

O que é um Data Warehouse?

Antes de se aprofundar nos diferentes conceitos de data warehouse, é importante entender o que realmente é um data warehouse.

Os armazéns de dados são muitas vezes considerados como sistemas de inteligência de negócios criados para ajudar com as necessidades de relatórios do dia-a-dia de uma entidade comercial. Eles não têm os mesmos requisitos de desempenho em tempo real (em implementações padrão) que os sistemas de dados OLTP e, enquanto os sistemas OLTP conterão apenas os dados relativos a um pequeno subconjunto do negócio, os data warehouses procuram abranger todos os dados relacionados ao negócio .

Os modelos de data warehouse oferecem benefícios a um negócio apenas quando o warehouse é considerado o hub central de “todos os dados” e não apenas uma ferramenta por meio da qual seus relatórios operacionais são produzidos. Todos os sistemas operacionais devem ter comunicação bidirecional com o data warehouse para alimentar os dados e receber feedback sobre como melhorar a eficiência operacional. Qualquer mudança nos negócios, como um aumento nos preços ou redução de fornecimento/inventário, deve primeiro ser prototipada e prevista em seu ambiente de data warehouse para que sua empresa possa prever e quantificar com segurança o resultado. Nesse contexto, todas as funções de ciência de dados e análise de dados seriam centradas no data warehouse.

Existem muitos componentes de um data warehouse, e não é simplesmente um banco de dados:

• Um banco de dados é um meio pelo qual você armazena seus dados.
• Um data warehouse vai além disso para incluir ferramentas e componentes necessários para extrair valor comercial de seus dados e pode incluir componentes como pipelines de integração, estruturas de qualidade de dados, ferramentas de visualização e até plug-ins de aprendizado de máquina.

Aqui está uma representação mais visual da diferença entre um banco de dados e uma estrutura de armazenamento de banco de dados. Bancos de dados ou novos meta armazenamentos de dados lógicos, como o Hive, formam a estrela central do sistema estelar de um data warehouse, com todos os outros componentes como seus planetas giratórios. No entanto, diferentemente de um sistema em estrela, um data warehouse pode ter um ou mais bancos de dados e esses bancos de dados devem ser intercambiáveis ​​com novas tecnologias, como discutiremos mais adiante neste artigo.

Primeiro Princípio do Data Warehouse: A qualidade dos dados reina suprema

Os data warehouses só são úteis e valiosos na medida em que os dados nele contidos são confiáveis ​​pelas partes interessadas do negócio. Para garantir isso, estruturas que capturam e corrigem automaticamente (quando possível) problemas de qualidade de dados precisam ser construídas. A limpeza de dados deve fazer parte do processo de integração de dados com auditorias regulares de dados ou a criação de perfis de dados para identificar quaisquer problemas de dados. Enquanto essas medidas proativas são implementadas, você também precisa considerar medidas reativas quando dados inválidos passam por esses portões e são relatados pelo usuário.

Para garantir a confiança do usuário no sistema de data warehouse, quaisquer dados incorretos destacados pelos usuários de negócios devem ser investigados com prioridade. Para ajudar nesses esforços, a linhagem de dados e as estruturas de controle de dados devem ser incorporadas à plataforma para garantir que quaisquer problemas de dados possam ser identificados e corrigidos rapidamente pela equipe de suporte. A maioria das plataformas de integração de dados integra algum grau de soluções de qualidade de dados, como DQS no MS SQL Server ou IDQ na Informatica.

Aproveite essas plataformas integradas se você estiver usando uma ferramenta comercial em seus pipelines de integração de dados, mas, adicionalmente ou não, certifique-se de criar os mecanismos que o ajudariam a manter a qualidade de seus dados. Por exemplo, a maioria das ferramentas de integração de dados não possui uma boa funcionalidade para rastrear a linhagem de dados. Para superar essa limitação, uma estrutura de controle de lote personalizada pode ser criada usando uma série de tabelas de controle para rastrear cada fluxo de dados que ocorre no sistema.

É muito difícil reconquistar a confiança das partes interessadas do seu negócio se eles encontrarem má qualidade em sua plataforma, portanto, o investimento inicial em estruturas de qualidade de dados deve valer a pena.

Segundo Princípio do Data Warehouse: Vire o Triângulo

Esta figura ilustra a divisão de esforços na implementação e uso da maioria dos data warehouses.

A maior parte do esforço é investido na construção e manutenção do armazém, enquanto o valor agregado de ter um armazém para análise de negócios é uma parte muito menor do esforço. Essa é outra razão pela qual os projetos de inteligência de negócios geralmente falham. Às vezes, leva muito tempo no ciclo do projeto para mostrar qualquer valor significativo para o cliente e, quando o sistema finalmente está em funcionamento, ainda exige muito esforço de TI para obter qualquer valor comercial dele. Como dissemos na introdução, projetar e implantar sistemas de inteligência de negócios pode ser um processo caro e demorado. Portanto, as partes interessadas esperam com razão começar a colher rapidamente o valor agregado por seus esforços de inteligência de negócios e armazenamento de dados. Se nenhum valor agregado se materializar, ou se os resultados simplesmente chegarem tarde demais para terem algum valor real, não há muito que os impeça de puxar o plugue.

O segundo princípio do desenvolvimento de data warehouse é inverter o triângulo conforme ilustrado aqui.

Sua escolha de ferramentas de inteligência de negócios e as estruturas que você implementa precisam garantir que uma parte maior do esforço direcionado ao warehouse seja extrair valor comercial do que construí-lo e mantê-lo. Isso garantirá altos níveis de envolvimento das partes interessadas do seu negócio, pois elas verão imediatamente o valor de investir no projeto. Mais importante, você permite que a empresa seja autossuficiente na extração de valor sem ter uma dependência tão forte da TI.

Você pode aderir a esse princípio seguindo as metodologias de desenvolvimento incremental ao construir o armazém para garantir a entrega da funcionalidade de produção o mais rápido possível. Seguir a estratégia de data mart de Kimball ou as metodologias de projeto de data warehouse do Data Vault de Linstedt ajudará você a desenvolver sistemas que são construídos de forma incremental enquanto contabilizam as mudanças sem problemas. Use uma camada semântica em sua plataforma, como um cubo MS SSAS ou até mesmo um Business Objects Universe, para fornecer uma interface de negócios fácil de entender para seus dados. No caso do primeiro, você também fornecerá um mecanismo fácil para os usuários consultarem dados do Excel – ainda a ferramenta de análise de dados mais popular.

A incorporação de ferramentas de BI que defendem o BI de autoatendimento, como Tableau ou PowerBI, só ajudará a melhorar o envolvimento do usuário, pois a interface para consultar dados agora é drasticamente simplificada em vez de escrever SQL.

Armazenar dados de origem em um data lake antes de preencher um banco de dados ajudará a expor os dados de origem aos usuários muito cedo no processo de integração. Pelo menos usuários avançados, como quants de negócios, agora poderão digerir os dados de origem (através dos arquivos brutos) conectando ferramentas como Hive/Impala em cima dos arquivos. Isso ajudará a reduzir o tempo necessário para a empresa analisar um novo ponto de dados de semanas para dias ou até horas.

Princípio do Terceiro Database Warehouse: Plug and Play

Os dados estão prestes a se tornar o equivalente digital do petróleo. Nos últimos anos, testemunhamos uma explosão no número de ferramentas que podem ser usadas como parte de uma plataforma de data warehouse e na taxa de inovação. Liderando a carga estão as inúmeras ferramentas de visualização disponíveis no momento, com opções avançadas para back-ends logo atrás. Dado esse ambiente e a propensão para os requisitos de negócios mudarem constantemente, é importante ter em mente que você precisaria trocar componentes de sua pilha de tecnologia ou até mesmo introduzir/remover outros com o tempo, conforme ditam as mudanças nos negócios e na tecnologia.

Com base na experiência pessoal, seria uma sorte se uma plataforma pudesse durar 12 meses sem algum tipo de mudança significativa. Uma quantidade razoável de esforço é inevitável nessas situações; no entanto, deve ser sempre possível alterar tecnologias ou design, e sua plataforma deve ser projetada para atender a essa eventual necessidade. Se o custo de migração de um armazém for muito alto, a empresa pode simplesmente decidir que o custo não se justifica e abandonar o que você construiu em vez de procurar migrar a solução existente para novas ferramentas.

Construir um sistema que atenda a todas as necessidades futuras imagináveis ​​é impossível. Portanto, um certo nível de apreciação de que tudo o que você projeta e constrói agora pode ser substituído com o tempo é necessário ao construir data warehouses. Para esse fim, eu recomendaria o uso de ferramentas e designs genéricos sempre que possível, em vez de acoplar fortemente sua plataforma às ferramentas em que está sendo executada. Obviamente, isso precisa ser feito após um planejamento cuidadoso e consideração, pois o poder de muitas ferramentas, especialmente bancos de dados, está em sua individualidade e em um complemento próximo.

Por exemplo, o desempenho de ETL é drasticamente aprimorado ao usar procedimentos armazenados em um banco de dados para criar novos dados de análise de negócios em vez de extrair e processar os dados fora do banco de dados usando Python ou SSIS. Com relação à camada de relatórios, as ferramentas de visualização ofereceriam certas funcionalidades que não estão prontamente disponíveis em outras — por exemplo, o Power BI oferece suporte a consultas MDX personalizadas, mas o Tableau não. Meu ponto não é defender a deserção de procedimentos armazenados ou evitar cubos SSAS ou Tableau em seus sistemas. Minha intenção é apenas promover a importância de estar atento ao justificar quaisquer decisões para acoplar firmemente sua plataforma às suas ferramentas.

Outro sumidouro potencial está na camada de integração. É muito fácil usar uma ferramenta como o SSIS para sua integração de dados por causa de seus recursos de depuração ou facilidade de uso com a plataforma SQL Server. No entanto, migrar centenas de pacotes SSIS para outra ferramenta se tornaria um projeto muito caro. Nos casos em que você está fazendo principalmente “EL”, procure usar uma ferramenta genérica para fazer seu processamento. Usar uma linguagem de programação como Python ou Java para escrever um carregador genérico para carregar sua camada de teste ajudará a reduzir pacotes SSIS individuais que você precisaria de outra forma. Essa abordagem não apenas ajuda a reduzir os custos de manutenção e migração futura, mas também ajuda a automatizar mais aspectos do processo de integração de dados sem a necessidade de escrever novos pacotes individuais (ligando-se ao Princípio 2).

Em todos esses casos, você precisa decidir sobre um compromisso prático entre os benefícios imediatos e os custos de migração futuros para garantir que o warehouse não seja descartado porque não pode lidar com a mudança ou porque a mudança exigiria muito tempo, esforço ou investimento.

Empacotando

Existem muitas razões pelas quais um determinado sistema de inteligência de negócios pode falhar, e também existem alguns descuidos comuns que podem levar a uma eventual falha. O cenário tecnológico em constante mudança, o orçamento limitado para sistemas de dados devido à prioridade secundária mal concebida para os sistemas operacionais e a enorme complexidade e dificuldade de trabalhar com dados significam que uma consideração cuidadosa não apenas das metas imediatas, mas também dos planos futuros precisa acontecer ao projetar e construir os componentes de um data warehouse.

Os fundamentos de armazenamento de dados descritos neste artigo destinam-se a ajudar a orientá-lo ao fazer essas considerações importantes. É claro que levar em conta esses princípios não garante o sucesso, mas eles certamente ajudarão você a evitar o fracasso.