Criando um modelo de dados baseado em eventos para analisar dados on-line
Atualizado: 30 de Abr de 2018
Introdução
Se você estiver muito interessado neste tópico, provavelmente é porque você é experiente o suficiente para entender que coletar e analisar eventos é sua autoestrada da informação para entender como seus usuários interagem com a sua aplicação. Mas vamos voltar por um segundo e fazer a pergunta a qual essa ideia se baseia: Porque coletamos eventos em primeiro lugar?
As iterações passadas de profissionais de BI teriam inferido bastante das informações demográficas e psicográficas coletadas sobre seus usuários em vários estágios do processo de compra. É fácil dizer que as pessoas dos Estados Unidos tendem a comprar mais do que em outros países e que as pessoas mais jovens tendem a ter maior propensão a fazer compras on-line.
Contudo dados demográficos e psicográficos não dizem tudo. Estudos mostram que dados comportamentais sobre os usuários são surpreendentemente melhores para prever coisas como compras, atualizações e "churn".
Na Cooladata, seguimos o ditado do nosso fundador, Tomer Ben Moshe:
“Você é definido pelo que faz, não quem você é”.
Essa filosofia não apenas une nossa empresa, mas permeia nosso produto e orienta todas as decisões que tomamos. O Cooladata é um sistema completo e projetado para permitir uma rápida análise e compreensão do comportamento do usuário.
Neste universo do comportamento do usuário, os eventos são os átomos. Quando um usuário realiza algum tipo de ação mensurável em seu website, em seu aplicativo ou em um de seus canais digitais essa ação é registrada como um evento.
Definição Geral
Os dados on-line provenientes do seu site, dispositivos móveis ou IOT são baseados em eventos em que cada evento tem suas próprias propriedades, por exemplo:
Modelagem de dados de evento é o processo de usar lógica de negócios para armazenar dados em nível de evento para produzir dados que são “analisáveis”, que é simples de consultar e entender o comportamento do usuário.
Um modelo de dados baseado em evento normalmente tem 3 níveis hierárquicos principais.
Usuário
Sessão
Evento
Usuário
A entidade usuário conterá atributos específicos sobre o usuário como por exemplo:
Email
CEP
Celular
e outros atributos
Sessão
A entidade sessão conterá atributos específicos sobre a sessão como por exemplo:
Browser
Dispositivo
Pais (IP)
Fonte de referência, etc..
Evento
A entidade evento conterá atributos específicos sobre o evento como por exemplo:
O evento de Login : ID de usuário, landing page, fonte de referência
O evento adicionar item: Produto , Preço , Cor , Tamanho etc..
O evento de checkout : Preço Total, Desconto, Opções de envio, etc.
O Desafio
Os modelos de dados tradicionais de BI, como o esquema em estrela ou o floco de neve, contêm tabelas de fatos e dimensões com uma estrutura fixa. Isso é eficiente e fácil de usar para analisar dados, mas funciona somente em dados estruturados e o esquema não muda muito. Um modelo de dados baseado em eventos é baseado em dados estruturados e semi-estruturados, por exemplo:
URL- contem vários atributos em uma linha c (página , título , campanha etc..)
DUA - agente do dispositivo do usuário contém muitos atributos sobre a sessão, como dispositivo, navegador, sistema operacional, localização etc.
Tipo de evento: cada tipo de evento tem um esquema diferente uma vez que é baseado em atributos totalmente diferentes, tornando quase impossível usar modelos tradicionais de dados de BI
A estrutura de dados do evento também tende a mudar com muita frequência. Isso significa que você teria que adicionar campos e tabelas quase diariamente. As estruturas de dados tendem a mudar rapidamente devido à natureza em rápida evolução das empresas hoje (contra 20 anos atrás). Com uma nova funcionalidade no produto, uma nova ferramenta ou uma nova versão, você precisará de um modelo de dados baseado em eventos que seja flexível, escalável e possa incorporar facilmente novos eventos. Modelos rígidos como o "snowflake" ou o esquema estrela simplesmente não são bons para se adaptar à natureza em rápida mudança dos negócios do século XXI. Existem várias maneiras de criar modelos de dados de eventos. Abaixo, listamos os 3 mais populares, bem como nossa própria versão. Antes de começarmos, vamos analisar algumas das considerações mais importantes para um modelo de dados de evento.
Considerações para um modelo de dados de evento:
Fácil de usar - Quão fácil é analisar dados usando SQL?
Desempenho - Minimize os "joins" e as varreduras completas;
Preço - Você deseja usar clusters Redshift mais baratos ou reduzir os custos do BigQuery?
Fácil de popular - Quão fácil é carregar dados no modelo? - Carga completa, carga incremental e atualização de dados.
Agora vamos dar uma olhada mais de perto em algumas de suas opções.
Opção 1 - Uma tabela para cada tipo de evento + uma tabela de atributos comum
Uma tabela de fatos para cada tipo de evento
Cada tabela de tipo de evento contem campos específicos para o atributo de evento
Uma tabela com "todos os eventos" para todos os tipos de eventos com campos para atributos comuns:
Prós
Bom desempenho para consultas comportamentais específicas.
Por exemplo, a análise de funil fará "join" entre as tabelas de tipos de evento, que é muito mais eficiente do que fazer "join" em todos os eventos usando subconsulta para cada tipo de evento.
Otimizar para analisar o tipo de evento específico
Por exemplo: Analisar o tipo de evento “instalar” na tabela de instalação será muito mais eficiente do que fazer isso em toda a tabela de eventos. Exemplo: A análise do evento "registrar" acessa apenas a tabela de registro.
Você ainda pode analisar todos os eventos com atributos comuns usando a tabela de fatos "Todos os eventos".
Contras
Difícil de gerenciar, especialmente em ambiente dinâmico. Sempre que adicionar um tipo de evento, você precisa adicionar uma tabela refletindo o ETL, metadados e monitoramento
Cada tipo de evento requer uma nova tabela. Mesmo que esse tipo de evento seja raramente usado, você precisará manter uma tabela para cada tipo de evento, mas quando você tem centenas de tipos de eventos isso se torna impossível de gerenciar.
Por ter uma tabela "todos_eventos" e uma tabela "tipo_evento", você está replicando dados. Isso dá muito mais trabalho e pode facilmente perder a sincronização resultando em problemas de qualidade de dados.
Opção 2 - Uma tabela de eventos comuns + campo json para atributos customizados
Uma única tabela de evento
A tabela contém os atributos comuns como campos
Atributos customizados são armazenados como um campo json
Json:
Prós
Mais fácil de gerenciar do que uma tabela para cada evento - Novos atributos são adicionados ao campo json. Não é necessário gerenciar muitas tabelas tipo_evento
Fácil de analisar atributos de eventos comuns como por exemplo, "timestamp" de eventos, id de usuário, de sessão, etc.
Você pode armazenar dados do usuário e da sessão na tabela de eventos (isso é chamado de "smearing" e ajuda a gerenciar as dimensões que mudam lentamente).
Contras
Difícil de analisar os atributos personalizados, você precisa extrair o atributo personalizado do campo json em cada consulta impactando o desempenho
Custoso - Por exemplo, selecionar no Google BigQuery uma pequena quantidade de dados de um objeto JSON maior é mais caro, pois o preço do BigQuery é baseado no tamanho da verificação (bytes processados)
Difícil mapear os metadados e usar ferramentas de BI para os atributos personalizados, já que os dados podem estar em uma cadeia json aninhada
Opção 3 - Um modelo de dados de tabela aninhada
Uma única tabela de fatos para todos os eventos
Atributos comuns na mesma hierarquia
Atributos personalizados na hierarquia aninhada
Você pode criar hierarquias para dados de usuários e sessão
Exemplo
Prós
Elegante e fácil de entender o modo como os dados são armazenados.
Flexível em atributos para cada hierarquia.
Bom desempenho para determinadas consultas, como contagem distinta.
Certas consultas como as de contagem distinta analisam menos dados
Todo o dado está contido em uma única tabela reduzindo a necessidade de "joins" entre tabelas
Contras
Os dados aninhados tornam-se difíceis de consultar
Difícil de carregar dados nas tabelas - especialmente dados incrementais.
Difícil mapear os metadados e usar ferramentas de BI sobre um modelo de dados aninhados. As colunas que contêm dados aninhados exigem esquemas razoavelmente complexos definidos para considerar possíveis eventos JSON autoexplicativos que possam ocorrer nessas colunas.
É quase impossível atualizar dados
A Opção da Cooladata:
Uma única tabela de evento
Existe uma opção para armazenar tipos de eventos específicos em diferentes tabelas, por exemplo, tipos de eventos populares, como "visualizações de páginas", podem ser armazenados em uma tabela separada e os tipos de eventos restantes podem ser armazenados em uma única tabela.
A tabela contem os atributos comuns e customizados como campos
A tabela tem dados de usuário & sessão para cada linha de evento (Smearing)
Prós
Fácil de entender o modo como os dados são armazenados.
Ao armazenar tipos de eventos populares em tabelas separadas, você obtém o desempenho de custo ótimo.
Todo o carregamento dos dados é controlado pela Cooladata.
Você é capaz de analisar os dados com muita facilidade
Você tem acesso fácil a mudanças históricas (dimensão de alteração lenta).
You have easy access to historical changes (slowly changing dimension).\
Contras
Para um ótimo desempenho você precisa usar o CQL (Cooladat SQL)
O gerenciamento de dados é via Cooladata
Recursos adicionais do Cooladata
Esquema físico
Nós particionamos os dados por tempo e propriedade como geografia do tipo de evento, etc. para obter o máximo desempenho e otimizar o acesso aos dados.
Armazenamos os dados em um banco de dados analítico colunar esparso, obtendo flexibilidade e desempenho.
Camada semântica/ Metadados
Criamos automaticamente a camada semântica e os metadados a partir de dados on-line, bem como dados tradicionais
Camada de acesso a dados otimizada (Parser)
Nosso "parser" inteligente traduz instruções SQL simples para poder acessar partições relevantes
Extensões de série temporal comportamental (CQL)
Estendemos o SQL com mais funções, permitindo a análise de séries temporais sobre dados granulares
Nossa tecnologia exclusiva fornece esses recursos:
Combine dados transações e on-line em um fluxo coerente.
Flexibilidade de um esquema base de documento no modelo de dados.
Análises de séries temporais e dimensionais abrangentes em um esquema.
Capacidade de usar ferramentas comuns de visualização no modelo de dados.
Unificação ad hoc de dados Online e tradicionais
Otimize o custo dos dados por meio do particionamento inteligente.
Rastreamento completo de mudanças de dados históricos (dimensões que mudam lentamente).
Sobre a Cooladata
O Cooladata é um data warehouse completo, baseado em nuvem e totalmente gerenciado, otimizado para análise comportamental e projetado para empresas com produtos digitais.
Ele auxilia as equipes de dados a unificar todos os seus dados em um único local, de forma que cada equipe em suas empresas possam obter as respostas necessárias, em segundos, não em horas ou dias.
Ele auxilia pequenas equipes de dados a fazer grandes coisas fornecendo-lhes todo o poder de um data warehouse sem as dores de cabeça e o custo de construir e manter um.
A Cooladata é apoiada pela 83 North / Greylock Israel, pela Carmel Ventures e pela Salesforce Ventures.
0 visualização