Este documento destina-se a ajudar os novos administradores e analistas que concluiram o treinamento do Data Workbench no Adobe Analytics. Depois de ler este artigo, deve ficar mais fácil avisualização de como esse software funciona para solucionar problemas ou executar análises detalhadas.
Modelo de Armazenamento de Dados para o Data Workbench
As arquiteturas convencionais, como um banco de dados relacional, organizam os dados em tabelas interconectadas por chaves. Por outro lado, o componente Data Workbench no Adobe Analytics usa um processo fundamentalmente diferente, conhecido como uma arquitetura de “roda”. Este artigo descreve como a arquitetura da roda funciona em comparação com as convencionais e identifica os pontos fortes e fracos.
O que é uma arquitetura de roda?
Pense nos dados do visitante no site como malas no aeroporto que circulam em uma esteira de coleta de bagagem. Neste exemplo, o objetivo é contar as malas de uma cor semelhante à que aparecem antes.
Para consultar as malas de circulação, é possível identificar a primeira mala e depois contar as subseqüentes que se movem à frente.
Toda vez que passa uma mala que combina, ela é identificada e calcula os diferentes tipos. Isso permite contar todas as malas e agrupá-las com base no tipo.
Quando a primeira mala está à sua frente novamente, então todo o circuito está completo. Nesse ponto, é possível parar de contar e relatar os resultados.
Se outras pessoas também precisam consultar os resultados, é possível andar até a roda e assistir às malas por exatamente uma rotação, começando nas mesmas ou em diferentes voltas da roda. Esse transportador, ou roda de dados, está sempre girando e uma consulta pode começar a qualquer momento e continuar até que uma única rotação seja concluída.
Além disso, o Data Workbench garante que as malas no cinto estão em uma ordem completamente aleatória. (As companhias aéreas também fazem um bom trabalho!) Isso permite que uma consulta de dados circulares seja vista como um instantâneo aleatório do total de dados, permitindo que as consultas calculem as respostas aproximadas com rapidez, extrapolando o resultado de toda a população.
Com 50 partes de dados, isso pode não funcionar muito bem. Mas com milhões ou bilhões de dados, uma estimativa muito precisa da contagem final pode ser extraída quase que instantaneamente.
Execução de consultas detalhadas
Vamos expandir essa analogia ainda mais. Para consultas analíticas mais detalhadas, colocamos todos os itens fora da mala (mas ainda os agrupamos pelo viajante). O conteúdo é composto por uma mala pequena, uma mala organizadora ainda menor e itens individuais.
Agora que o agente de consulta tem acesso imediato ao conteúdo, uma consulta mais detalhada como "quantos viajantes carregam uma garrafa azul?" pode ser realizada.
Estrutura Hierárquica dentro de uma mala
Vamos traduzir essa analogia da bagagem de volta para dados de visitantes para análises: uma mala para cada viajante representa todos os dados de um Visitante, a tag de nome como o ID do Visitante, as malas pequenas representam uma Visita, os organizadores são os Acessos e os itens individuais são os Eventos.
No cliente do Data Workbench, essa estrutura pode ser descrita como um diagrama de esquema. Uma descrição do diagrama do esquema está disponível here.
A operação para dispor os dados de acordo com essa arquitetura é chamada de Processamento de Log. Tem que ocorrer sempre que a estrutura hierárquica muda significativamente. Enquanto esse processo leva tempo, é disponibilizado um conjunto de dados otimizado para consultas analíticas muito rápidas.
Tabelas relacionais na analogia da bagagem
Antes de descrever como a roda de dados difere das tabelas, vamos primeiro considerar como essa analogia de bagagem se encontra com uma abordagem convencional. Em um banco de dados relacional, os dados seriam algo parecido com muitas prateleiras com malas. Essa arquitetura convencional oferece uma maneira rápida de inserir uma nova mala ou extrair uma específica.
Para uma análise mais detalhada, os dados dentro de cada mala precisam ser extraídos e normalizados em prateleiras separadas como essa.
Nessa configuração, o agente de consulta precisa resolver as chaves externas para vincular cada um dos itens nas quatro prateleiras.
Consideração de custos indiretos para consulta analítica
Quando uma consulta é direcionada para uma entidade, o banco de dados relacional pode concluir a consulta com rapidez. Por exemplo, uma consulta de "quantos eventos o Sr. Taro Adobe disparou?" exige que o agente de consulta verifique um registro na tabela de Visitante, vários na tabela Visita e mais nas tabelas Acesso e Evento. Também exige uma contagem do número de eventos. Estas são etapas caras para que o banco de dados use essas chaves externas, mas fazer isso para uma pessoa ainda é prático.
No entanto, uma consulta analítica é mais aberta e requer uma resposta à pergunta: "Quantos usuários disparam os eventos por sessão?" Isso requer uma consulta em vários registros com o agente de consulta repetindo as etapas caras para todos os usuários. Consequentemente, quando há milhões ou bilhões de visitantes, isso rapidamente se torna impraticável.
Ao usar as rodas, os dados de cada visitante são organizados em uma única mala, para que o agente de consulta possa avaliar cada mala de uma só vez e passar para a próxima, permitindo que a roda termine uma consulta em uma única varredura. Portanto, a arquitetura de roda é mais adequada para consultas analíticas.
O Cubo OLAP
Para melhorar a velocidade da consulta analítica, o software típico da Inteligência de Negócios (BI) conta com uma estrutura multidimensional com dados de resumo pré-calculados, conhecidos como um cubo OLAP. Ao consultar esses resumos, o tempo de resposta fica significativamente menor para alguns aplicativos, mas se depara com problemas no caso de consultas avançadas.
Por exemplo, uma empresa tem clientes em 50 estados diferentes, 1000 linhas de produtos e 10 bilhões de transações por ano. Os dados são armazenados usando cubos tridimensionais com base na hora, no produto e no estado. Isso requer pré-cálculos de 1,2 milhão de cubos.
Nessa arquitetura, a consulta analítica de “quantos produtos vendemos por hora em cada estado?” pode ser respondida com rapidez ao olhar para um resumo dos cubos. Essa é uma grande melhoria para as consultas de tabela padrão com referências externas.
Aumento da granularidade e a escala
No entanto, uma consulta mais detalhada de "quantos produtos vendemos por minutos em cada estado?" exige pré-cálculos multiplicados por 60 por cubo OLAP. Adicionar novos produtos, expandir a contagem entre países ou introduzir novas dimensões (com base no tamanho, sexo, material etc.) faz com que o resumo do cubo OLAP multiplique a pilha a uma taxa exponencial.
À medida que a pilha de cubos cresce, o pré-cálculo e a atualização dos dados aumentam o tempo de atraso e forçam o analista a consultar um conjunto de dados que costuma ficar dias atrasados. Essa sobrecarga transacional e o crescimento exponencial de dados nas tabelas aumentam a latência e limitam severamente as consultas analíticas ao usar a arquitetura de cubos OLAP.
Em contraste, o aumento equivalente da granularidade na roda resulta em um menor crescimento incremental.
Além disso, sem a sobrecarga de pré-cálculo, novos dados adicionados ficam disponíveis logo após a chegada. Isso permite que os analistas façam consultas quase em tempo real. No próximo artigo, relataremos mais sobre como funciona o processamento em tempo real.
A consulta sobre os dados reais vs. O resumo de dados reais
Mesmo quando uma organização tem uma grande capacidade de atualizar o resumo quase em tempo real, um fator a mais deve ser considerado: uma consulta contra um cubo OLAP é uma consulta contra o resumo de dados, tornando-o menos granular e inerentemente “com perdas”. Por outro lado, os resultados da consulta na roda são calculados diretamente dos dados processados.
Conclusão:
Conforme descrito neste documento, a operação do Data Workbench no Adobe Analytics pode ser melhor descrita como dados de visitantes colocados em uma roda, em vez de interconectados como tabelas ou prateleiras lineares. É mais adequado para executar consultas analíticas para pesquisar grandes quantidades de dados.
Entender o funcionamento interno desse modelo de banco de dados ajuda a aproveitar os benefícios.
