O Guia de analistas para projetar um moderno armazém de dados

então você é convidado a construir um armazém de dados para sua empresa. Um armazém de dados eficiente, escalável e confiável. Se sua empresa está seriamente embarcando na implementação de relatórios de dados como um ativo estratégico chave para o seu negócio, a construção de um data warehouse eventualmente surgirá na conversa.mas construir um armazém de dados não é fácil nem trivial. Mais de 50 por cento dos projetos do data warehouse têm aceitação limitada,ou serão falhas diretas.como você deve começar a projetar e construir seu armazém de dados? Quais são as armadilhas e como você deve otimizá-lo? Mais importante, por onde devo começar?

Este post fornece um guia de alto nível sobre como pensar em criar o seu armazém de dados para evitar algumas armadilhas comuns.o que é um armazém de dados?

uma empresa moderna normalmente tem dados armazenados em diferentes locais (fontes de dados). Isto pode ser dados de:

• bases de dados de Aplicação: para startups, isto é provavelmente a sua aplicação principal do produto. Para outras empresas, pode ser o seu ponto de venda aplicação,
• aplicações Web: estas podem ser aplicações que são necessárias para escalar um negócio ou manter operações de Negócio. Exemplos podem ser softwares de email marketing como Mailchimp, aplicações de análise web como Google Analytics ou Mixpanel, ou até mesmo softwares de contabilidade como Xero e Quickbooks.
• planilhas: isto pode ser na forma de planilhas de desktop (Excel, CSV) ou planilhas online, como o Google Sheets. Estes dados podem ser atualizados manualmente por alguém, ou atualizados por uma atividade Zapier.

um armazém de dados sincroniza os dados de diferentes fontes num único local para todas as necessidades de comunicação de dados.

ele fornece dados que podem ser confiáveis, e pode lidar com a carga de trabalho questionável de todos os funcionários da empresa.

projetar um armazém de dados

também deve ler: quando você deve obter um armazém de dados?

Aqui está como uma configuração típica de armazenamento de dados se parece:

Você projetar e construir seu armazém de dados com base em seus requisitos de relatórios. Depois de identificar os dados de que precisa, desenhe os dados para transferir informações para o seu armazém de dados.

crie um esquema para cada fonte de dados

crie um esquema de base de dados para cada fonte de dados que goste de sincronizar com a sua base de dados. Este

1. ajuda a identificar rapidamente a fonte de dados de que cada tabela vem, o que ajuda à medida que o seu número de fontes de dados cresce. Futuros analistas de dados e membros da equipe de negócios que se juntam a sua empresa também podem aprender rapidamente o que cada fonte de dados tem.
2. Permite-lhe atribuir permissões específicas (ler/escrever) para cada fonte de dados. Por exemplo, um engenheiro de dados pode não querer permitir que um Analista Júnior apenas leia, mas não escreva para um esquema específico.isto é especialmente útil quando o seu número de fontes de dados cresce ao longo do tempo. Basta olhar para o número de fontes em que seus dados podem estar.

   Por exemplo, você pode configurar um esquema chamado de mailchimpxero, ou fbads para o e-mail marketing, finanças e publicidade de dados que você deseja importar a partir desses aplicativos em seu armazém, respectivamente.

   Quando importar a sua tabela de contactos do Mailchimp para a sua base de dados, poderá consultá-los como:

   SELECT name, email FROM mailchimp.contacts

   como criar um esquema

   criar um esquema é fácil. Você só precisa digitar uma linha para criar um novo esquema. Na verdade, são apenas três palavras em Postgres.

   CREATE SCHEMA 

   exemplo:

   CREATE SCHEMA mailchimp

   Nota 1: os novos analistas podem ficar confusos entre um esquema de base de dados. Existem 2 definições de esquema. Um esquema pode ser usado para descrever ou

   1. Como as tabelas e campos de uma base de dados estão relacionados entre si, ou
   2. uma pasta para tabelas de bases de dados, assim como como as pastas organizam os seus ficheiros

   Nota 2: as bases de dados mySQL não suportam o esquema, por isso poderá querer usar uma convenção de nomes para nomear as tabelas que importar, como o mailchimp_contacts, etc. Essa é uma das razões pelas quais encorajamos nossos clientes a usar PostgreSQL para seu banco de dados de relatórios.

   mover os dados de origem para o seu armazém de dados

   o próximo passo é sincronizar os seus dados de origem para o seu armazém de dados. Os seus engenheiros devem saber isso como um script ETL.

   Desenhe o seu programa de importação com as seguintes considerações:

   1. remova colunas que são obviamente desnecessárias. Não é assim tão difícil adicioná-los mais tarde se você perceber que você precisa deles.
   2. mudar o nome das colunas para torná-las mais descritivas ou amigáveis à base de dados (como usar minúsculas, ou camel case.filtrar registos obviamente desnecessários. Isto pode ser registros de seus usuários internos testar em seu sistema de produção (às vezes seus usuários podem adicionar dados como [email protected] ou definir o seu primeiro nome como ensaios)
   3. mapear os valores de registo para torná-los mais legíveis. Isso economiza o seu esforço de analistas renomeá-los durante o relatório com CASE-IFs mais tarde). Por exemplo, alguns registros podem armazenar chaves numéricas (1,2,3, 99 etc) ou nomes abreviados que podem não ser conhecidos pelo resto da organização. Nesses casos, você pode querer mapear essas chaves para seus valores reais durante o processo de importação.
   4. aplique os índices da base de dados na sua tabela de destino após a importação ser feita. Note que nós escrevemos sobre quais índices de banco de dados estão em um post anterior. tratamento de erros: configurar e-mails//mensagem de Alerta de folga a serem enviados para as partes interessadas relevantes (especialmente analistas de dados) com diários de erro detalhados quando a tarefa falha. Você pode querer configurar tentativas de repetição automatizadas (ou processos de recuperação automatizados) dentro de um período de tempo específico para reduzir o número de falsos positivos neste caso.deve transformar os seus dados de origem (raw)?

      uma questão que muitas vezes nos perguntam é como aplicar a transformação de dados antes de mover os dados para o armazém.o nosso conselho geral é não o fazer. Pelo menos, não no início. Especialmente se este é o seu primeiro projeto de data warehouse. Há algumas razões para isto.

      A. É improvável que você tenha requisitos claros em suas necessidades de transformação de dados

      mesmo que você tenha “requisitos claros”, é provável que este requisito vai mudar ao longo do projeto, ou fica desatualizado.

      Você não vai querer gastar tempo revisando seu script ETL com base no que diferentes partes interessadas querem em diferentes pontos no tempo.

      mover os seus dados de fonte (não traduzidos) ajuda-o a separar a dependência do seu script ETL dos “Requisitos de Negócio”.

      B. É provável que você precise dos dados de fonte para outros casos

      pense em seus dados de fonte como uma base de interação que pode ser derivada em várias tabelas derivadas, quer agregando-as ao longo de diferentes dimensões ou juntando-as com tabelas de outras fontes.

      Ver exemplo abaixo sobre como rastrear a eficácia da conversão do vendedor.

      ao transformar dados, você perde detalhes a partir dos dados de origem que podem ser necessários para futuros relatórios de uso-casos.

      Por exemplo, quando você resume a receita de vendas por período de tempo, você perde detalhes dos registros de transações específicas que outro usuário pode precisar correlacionar com outros relatórios.mover os seus dados não traduzidos dar-lhe-á flexibilidade para combiná-los com outras fontes de dados.

      a necessidade de dados de origem torna-se mais importante quando você começa a olhar para a construção de modelos de dados reutilizáveis para responder a diferentes perguntas. Veja um exemplo abaixo sobre um relatório de coorte é construído com uma série de dados pós-transformados. Isto será mais difícil de fazer se você não tiver

      C. Reduzir a carga em seus sistemas de origem

      a execução de dados transforma no sistema de origem pode absorver recursos consideráveis, especialmente se você tem um banco de dados que atendem clientes em todo o mundo.

      Você não vai querer sobrecarregá-lo com tarefas de transformação de dados de longa duração antes de movê-los.

      Existem alguns casos que podem fazer sentido para você transformar dados antes de movê-los sobre, mas esses casos são tipicamente para empresas que já configuraram um armazém de dados confiável e procurando melhorá-lo ainda mais.

      transformar dados para resolver um problema específico

      pensar sobre como transformar dados pode ser complexo. Se não for controlado, você pode acabar gastando muito tempo otimizando dados que não entregam valor para o negócio.planear, conceber e implementar os dados transforma-se sem um resultado claro é uma solução que procura um problema.

      uma boa regra é começar com o fim em mente. Os dados transformados devem ser criados apenas para resolver um caso de uso prático ou problema a partir de seu relatório.

      Uma boa maneira de encontrar (e priorizar) esses casos de uso prático é começar a construir os relatórios e painéis com os dados que você importou.

      Quando seus usuários começam a levantar problemas de desempenho da consulta, você pode então olhar para transformar os dados.

      isto pode ser causado por relatórios que tanto
      (A) contém subqueries aninhadas ou expressões de tabelas personalizadas (Eti)

      (b) ou têm múltiplas (caras) juntas em várias tabelas.

      é aqui que a flexibilidade dos Relatórios baseados em SQL é útil para ajudar a identificar os problemas que a transformação de dados pode resolver.

      é fácil para qualquer analista identificar rapidamente a causa raiz dos relatórios com consultas de longa duração, e iniciar para otimizar o seu desempenho.

      isto é feito em grande parte através da pré-agregação automática dos dados. Isto pode ser feito com visualizações materializadas onde você pode criar dados que transformem empregos que tanto:

      1. agregam tabelas de transações grandes para acelerar o desempenho da consulta.
      2. Criar tabelas derivadas com colunas de diferentes fontes de dados
      3. substituir / mascarar dados sensíveis para grupos seleccionados de utilizadores.

      outra recomendação é criar um novo esquema de banco de dados em seu armazém de dados para que você armazene suas tabelas transformadas (ou pós-processadas).

      Como a abordagem anterior de separar cada fonte de dados por esquemas, a criação de um esquema específico pode ajudá-lo a identificar a lista de tabelas de dados derivadas/transformadas. Isso será útil mais tarde, quando você começar a string uma série de importações de dados, os dados transformam trabalhos em sequência à medida que sua maturidade de dados cresce.

      crie os seus documentos de dados internos

      isto é importante, especialmente se não quiser que o seu armazém de dados seja uma caixa negra onde apenas alguns engenheiros entendem como usá-lo. Se os seus utilizadores não o compreenderem, não estarão confiantes em interrogá-lo.

      pode começar por criar um documento partilhado (pode ser o Google Doc) que descreve um entendimento comum de:

      • tabelas e colunas nos seus dados de origem, e como interpretá-los
      • incluir Diagrama de dados se existir.
      • Como ler as suas colunas nos seus relatórios (painel de instrumentos, métricas) e quaisquer pressupostos subjacentes a cada um deles

      cada vez que um relatório é criado (ou actualizado), actualize este documento para reflectir qualquer novo nível de compreensão empresarial dos seus dados.

      iremos partilhar mais detalhes sobre como criar e estruturar este documento interno de dados num post separado, por isso cuidado com este espaço!é isso!esperamos que este guia tenha sido útil! Deixe-nos saber como podemos ajudar com a sua viagem para construir um armazém de dados confiável.