Este artigo é estritamente uma ilustração simplificada do produto. Destina-se a ajudar os analistas a visualizar a operação para solucionar os problemas.
Visão geral
No nosso previous article, descrevemos como os dados de log de vários canais formam um único dado do visitante. Agora estamos mudando nosso foco para um conjunto de dados inteiro.
Processo de Log - Construção de conjunto de dados -
A construção do conjunto de dados é chamada Log Process, que consiste em duas fases.
(1) Fase de processamento de log
Primeiro, os servidores devem decodificar os arquivos de dados de log brutos, organizá-los como dados do visitante (cartão de contato) e armazená-los em um conjunto de dados (titular do cartão). Esta fase também é conhecida como Fast Input.
Durante esta fase, dezenas de milhares de arquivos de log grandes são decodificados linha por linha. Para tal, esta fase leva uma quantidade considerável de tempo.
(2) Fase de transformação
Enquanto a fase anterior era toda sobre decodificação de dados de log brutos, esta fase se concentra em transformar os dados decodificados em uma forma com mais utilidade. Esta fase também é conhecida como Fast Merge.
Neste ponto, os servidores estão trabalhando em um conjunto de dados, que é menor e é organizado para acesso rápido, ao contrário dos arquivos de log simples. Por esse motivo, essa fase geralmente termina muito mais rápido que a fase de processamento de logs.
À medida que progride, a porção finalizada torna-se gradualmente disponível para uma consulta.
O uso de transformações intensivas de recursos como a CrossRows transformation poderia expandir a duração desta fase, bem como o consumo de disco.
Tarefa de transformação durante a fase de processamento de log
Os tipos de transformação mais simples podem ser executados durante a fase de processamento de logs sem esperar pela fase de transformação. A ilustração abaixo faz a mesma transformação de pesquisa descrita no the previous article em uma única varredura.
Alguns tipos de transformação devem aguardar a conclusão da fase de processamento de log. Por exemplo, as transformações de linha cruzada tomam outros campos em um cartão como entrada, o que pode não ser decodificado ainda. Eles podem ser executados posteriormente durante a fase de transformação.
Processamento em Tempo Real - atualização contínua -
Mesmo depois de concluir o processo de log, novos dados são adicionados continuamente para manter o conjunto de dados atualizado. Esse incremento contínuo é chamado modo Real Time Processing e um servidor faz isso em segundo plano ao responder a consultas.
Ao alimentar a via Sensor module, os dados de eventos são processados em minutos ou até menos em um cluster de tamanho adequado. Os analistas podem, então, executar consultas sobre eventos quase em tempo real.
No entanto, se houver picos de quantidade de log de dados, eles podem sobrecarregar o cluster. Por exemplo, o número de visitantes pode multiplicar várias vezes em um dia de lançamento do produto. Isso faz com que os dados pendentes se acumulem, ampliando a distância entre As-Of Time e hora atual.
- Pegar um atraso -
Uma vez que o atraso de tempo atinge o threshold, o conjunto de dados retorna novamente à fase Processo de Log e de Transformação. Isso ajudará a recuperar o atraso.
Log Processing phase (incremental) também conhecido como Fast Input: Como os dados de campo existentes no conjunto de dados podem ser reutilizados, somente os dados pendentes são decodificados e concluídos com relativa rapidez. Durante essa fase, o conjunto de dados deixa de aceitar consultas e concentra todos os seus recursos no processamento de log.
Transformation phase (full) também conhecido como Fast Merge: A adição de dados recém decodificados invalida os dados transformados existentes; portanto, a fase de transformação terá que ser executada novamente na íntegra. Dados parciais ficam disponíveis para uma consulta conforme ela avança.
Depois que todas as transformações são concluídas, o conjunto de dados retornará ao modo de processamento em tempo real.
A maneira que os dados são alimentados no cluster variam de caso para caso. A sua organização pode alimentar dados através do uso do sensor, do feed diário do Adobe Analytics Report (SiteCatalyst), dos arquivos de log de vários aplicativos personalizados ou a combinação deles. O exemplo acima é o mínimo para ilustrar o mecanismo. Entre em contato com o consultor da Adobe para elaborar o melhor plano para seu caso de uso específico.
Reprocessar - Reconstrução do conjunto de dados -
Mudanças substanciais de arquitetura, recuperação de danos inesperados ou manutenção periódica requerem outra rodada de Log Process e Transformation. Tal reconstrução é chamada de Reprocess.
Por exemplo, digamos que o arquiteto decide incorporar logs da central de atendimento. Ele atualiza a arquitetura de dados marcada em amarelo e inicia o reprocessamento.
Quando o reprocessamento termina, as consultas mais sofisticadas como essa podem ser executadas.
"Among in-store add-on purchase items, which products are more likely to result in support calls?"
Naturalmente, o reprocessamento de todo o conjunto de dados leva tempo e deve ser executado fora do horário comercial.
Retransformação - Reconstrução parcial -
Quando um arquiteto precisa fazer alterações nas operações da fase de transformação, a repetição dessa fase pode ser suficiente. Isso é chamado de Retransformation, e possibilitará que a fase Log Processing seja ignorada.
Obviamente, a retransformação não atualiza retroativamente as operações da fase de Processamento de Log, portanto, qualquer alteração exige o reprocessamento total.
- Manutenção do Conjunto de Dados -
Por padrão, o Data Workbench mantém o processamento de dados de log indefinidamente e o conjunto de dados continua crescendo até o próximo reprocessamento. Para evitar o excesso de dados, o suporte da Adobe recomenda o reprocessamento periódico com atualizações Start Time. A prática recomendada para gerenciar o tamanho do conjunto de dados pode ser encontrada aqui.
