Uma vez que o sistema de recomendação se destina a utilizar um grande volume de dados proveniente das APIs, foi necessário o desenvolvimento de uma estratégia de extração de dados com um bom balanço entre tempo de processamento e complexidade da solução. A utilização de um processo do tipo ELT permite acesso a todas as funcionalidades de transformação e o processamento de dados que a base de dados já possui.
Como referido em2.3.2.1, o processo ELT divide-se em três tarefas: extração, transformação e armazenamento. A tarefa de extração de dados é desempenhada pelas instâncias do crawler, que são responsáveis pela comunicação com as fontes de dados, pré-seleção do conteúdo, e colocaca- ção destes dados na área de staging dentro da RDBMS. Este processo é descrito com mais detalhe na subsecção4.4.1.1. Quanto às tarefas de transformação e armazenamento, são responsabilidade do RDBMS, o qual contém um processo que desempenha todas as transformações necessárias, assim como a introdução dos dados para as tabelas dimensão correspondentes. Este processo é descrito com mais detalhe na subsecção4.4.1.2. Na figura 4.6está representada a arquitetura de alto nível do processo ELT.
Figura 4.6: Arquitetura do processo ELT
4.4.1.1 Crawler
Crawler é o processo responsável por toda a extração e armazenamento dos dados, o qual foi desenvolvido em Node.js com uma arquitetura modular e resistente a falhas. Além disto, este permite a configuração, através de um ficheiro, nomeadamente da ligação à base de dados, assim como, dos top-N utilizadores com mais seguidores. De forma a agilizar os testes de integração, este processo está preparado para execução manual, através de linha de comandos, ou execução a pedido da API REST do sistema de recomendação, também de forma periódica de modo a garantir a atualização dos dados na base de dados. Como irá ser extraído um grande volume de dados, este processo permite múltiplas instâncias paralelas. Este volume resulta das dinâmicas comportamen- tais dos utilizadores na plataforma em constante mudança. A figura4.7apresenta a arquitetura do Crawler.
De modo a respeitar as limitações das APIs das plataformas, e mesmo assim tirar o maior partido dos seus serviços, cada instância do crawler está limitada a 750 pedidos por minuto. Para conseguir obter a maior quantidade de dados num curto espaço de tempo, cada chamada à API irá extrair a maior quantidade de dados possível. O valor máximo de registos de dados que é possível receber em cada pedido é 100, este valor é estipulado pelas APIs. Assim, cada instância do cra- wler pode extrair 75000 registos por minuto. Por exemplo, se se pretender extrair os seguidores de um utilizar u, ou seja, a relação entre outros utilizadores e o canal do utilizador u, por minuto é possível extrair os dados de 75000 relações.
Na fase de inicialização, o processo adquire através da BD um token de autorização, caso exista um disponível, cuja limitação é o número de instâncias configuradas. Após esta configu- ração dos acessos às APIs das plataformas, o processo obtém uma lista de usernames iniciais, a
partir de um ficheiro de configuração, e cria uma fila de processamento em memória. De seguida, cada instância do processo está preparada para iniciar a execução do processo de amostragem, de acordo com as restrições funcionais da API, referidas na subsecção2.3.1.1. Durante esta fase são inseridos os dados na área de staging do datawarehouse com uma pré-filtragem que remove informação não útil. Concorrentemente a esta inserção, é também realizado um backup dos dados no sistema de ficheiros utilizando um formato JSON comprimido com GZIP. Foi escolhido este formato, porque os dados já se encontram em JSON, e pelo facto do método de compressão do GZIP estar disponível em todos os sistemas Linux, e possuir um bom equilíbrio entre a compres- são obtida com texto e os recursos necessário para efetuar essa compressão: tempo, memória e CPU.
Figura 4.7: Arquitetura do crawler
Cada instância do crawler segue uma lógica de processo para cada utilizador alocado na fila de processamento em memória, representada no diagrama4.8. Isto é, para cada utilizador na fila, o processo deve extrair das APIs, filtrar e armazenar os dados na área de staging do datawarehouse.
O processo de extração dos dados consiste em múltiplos pedido às APIs das plataformas de streaming. Em primeiro lugar, requer a informação do utilizar, de seguida o canal e respetivos vídeos, caso existam e por último, informação dos seguidores, novamente caso existam. Dos seguidores obtidos, seleciona os TOP-N utilizadores com mais seguidores e adiciona-os à fila de processamento. O processo termina quando a fila estiver vazia ou quando atingir K utilizadores, sendo K o número máximo de utilizadores que os recursos disponíveis conseguem armazenar.
4.4.1.2 Base de Dados
Para armazenar os dados extraídos pelas instâncias do crawler, foi projetado e implementado um datawarehouse. A utilização de um datawarehouse com uma arquitetura multidimensional permite a utilização dos dados para fins analíticos mapeando-os em cada dimensão de negócio, nomeadamente, tempo, utilizador e canal. Estas dimensões são unificados numa tabela de factos, a tabela de seguidores (followers). As dimensões também foram normalizadas, criando assim uma estrutura em snowflake4.9.
Figura 4.9: Esquema em Snowflake
Neste projeto, foram criados dois esquemas na base de dados, que permitem a separação entre dados a processar e dados já processados4.10.
No esquema staging encontram-se os dados a processar, carregados pelas instâncias do cra- wler. Estes dados são armazenados em tabelas (figura4.11) com número de sequência e dentro de uma coluna com suporte a consultas sobre JSON através de SQL. Em algumas tabelas já se encontram extraídos identificadores do canal associado. Foi escolhido um tipo de coluna de JSON binarizada (JSONB), que permite otimizar a utilização de recursos, melhorar o desempenho de processamento, e tem suporte para criação de índices sobre a estrutura JSONB. Também foram criados índices, nos atributos mais requisitados, para otimizar o desempenho das pesquisas.
Figura 4.11: ERD Staging
Devido à grande dimensão dos dados, foi necessário limitar o número de tuplos a ser proces- sados. Para tal, foi criada uma tabela auxiliar que contém a data de execução e o identificador do primeiro e último tuplo que foi processado na última execução do processo de transformação.
Como já foi referido na secção4.3.1, os dados foram uniformizados (ver tabela4.1), de modo a que todos os processos de transformação sejam comuns a qualquer plataforma. Isto garante tam- bém que quaisquer tarefas de análise de dados possam ser efetuadas sem necessidade de mapear novamente as particularidades de cada fonte de dados.
Processo de transformação de dados O processo de transformação é um processo SQL, que é executado dentro do sistema de base de dados, e se divide em duas etapas: criação de dimensões e construção de fatos. Para que o processo se mantenha coerente, primeiro foram criadas as dimen- sões a partir dos dados base carregados na área de staging. Posteriormente, foi construída a tabela de fatos, a qual agrega canais aos seus seguidores e inclui a data correspondente a esta agregação. Note-se que este processo executa transformações sobre um grande volume de dados, o que o pode tornar bastante demorado. Visto que as restrições aplicadas através de chaves estrangeiras obrigam a verificações por cada tuplo gerado, estas são temporariamente desativadas durante a execução do processo. Após as tabelas serem populadas, as chaves estrangeiras são reativadas para garantir a consistência dos dados. O fluxo do processo encontra-se dentro de uma transação,
onde são executadas as várias operações de transformação e carregamento nas tabelas no esquema RS, ver figura4.12. Isto permite que, no caso em que ocorra algum problema, é efetuado o roll backautomático e logging dos problemas.
Figura 4.12: ERD RS
Atualização de credenciais de acesso Uma vez que são necessárias credenciais para acesso às APIs, foi desenvolvido um processo de atualização de credenciais, que expiram periodica- mente, integrado no sistema de base de dados. A arquitetura deste processo encontra-se na figura 4.13. O processo é regularmente executado de forma automática, utilizando o Scheduler do sis- tema (CRON), que invoca a função rs.update_token_auth() presente no esquema RS do datawa- rehouse. Esta função faz uso da ferramenta de pedidos HTTP do sistema (CURL) para efetuar o
pedido de novas credenciais às APIs. Após receber resposta a este pedido, a função procede à ex- tração dos dados necessários e atualização dos atributos token e last_update na tabela api_info. Este processo apenas afeta tokens que se encontrem próximos da sua data de expiração.
Figura 4.13: Processo de atualização das credenciais de acesso (access Token)
Outros processos Visto que o volume de dados do datawarehouse é bastante elevado, existe vantagem em adicionar uma camada de apresentação, que efetua o pré-processamentos de dados para tarefas do sistema de recomendação que ocorram com alguma regularidade. Para este efeito, foram desenvolvidos processos que constroem várias tabelas, com os conjuntos de dados que são necessários para o funcionamento do sistema de recomendação, e que não sejam dependentes do utilizador para o qual se efetua a recomendação. Esta preparação permite acelerar a resposta a pedidos de recomendação.
Sistema de Recomendação - Modelação
Este capítulo encontra-se dividido em secções que representam as fases usadas na implemen- tação do modelo de recomendação. Começa por definir a criação do dataset utilizado, e a divisão deste em dados de treino, teste e validação. Aborda também as estruturas de dados necessárias, nomeadamente, a criação de matrizes e construção da rede complexa. As matrizes são uma mais valia na visualização do problema, definindo os espaços representados pelas dimensões utilizador, canal e categorias. Já a rede complexa permite mapear as relações entre categorias tirando par- tido dos seus co-seguidores. Estas estruturas são pré-processadas em Batch de forma a otimizar a velocidade de resposta do sistema de recomendação. O processo responsável pelas estruturas de dados pode ser executado manualmente, ou a pedido, através da API para atualização das mesmas. Seguidamente, é explorado um conjunto de abordagens incrementais, onde se efetua a comparação em termos de desempenho e mais valias que justificam o seu uso. Por fim, são apresentadas as estratégias de validação dos dados e os resultados alcançados.
5.1
Divisão dos dados
A construção dos conjuntos de dados utilizados para efetuar as tarefas de modelação ma- temática e analítica do problema, foi realizada com auxílio de processos de agregação sobre o datawarehouse. A utilização destes processos permitiu acelerar e facilitar as transformações ne- cessárias aos processos de análise de dados que estão subjacentes a cada abordagem explorada. Estes melhoramentos advêm, por um lado, da correta conceção do datawarehouse e introdução de índices nas colunas que sofrem mais operações de filtragem, ligação, e agregação, e por outro lado, a expressividade da linguagem SQL que facilita a definição das transformações dos dados. Adicionalmente, estes processos permitem uma preparação prévia das estruturas de dados que irão ser utilizadas pelo sistema de recomendação, reduzindo assim as computações necessárias quando da execução dos processos de recomendação.
Foi necessária a construção de um dataset constituído por informações relevantes para o ce- nário em causa. Assim, o conteúdo do dataset passa pela identificação dos utilizadores, todos os canais que os utilizadores seguem, e a data que se inicia esta relação. A relação entre utilizador
e categorias é extraída dos canais que o utilizador segue, classificados por categorias e pelas ca- tegorias dos vídeos do canal. Na figura 5.1 estão ilustradas as relações entre Utilizador-Canal, Canal-Vídeo, Canal-Categoria, e Vídeo-Categoria.
Figura 5.1: Relação entre Utilizador-Canal e Canal/Vídeo-Categorias
Graças a relação Utilizador-Canal e Canal/Vídeo-Categoria é possível inferir a relação entre Utilizador-Categoria, como ilustrado na figura5.2.
Figura 5.2: Relação entre utilizador-Categorias
A seleção e mapeamento desta informação para a estrutura tabular do dataset é realizada por um dos processos de agregação sobre o datawarehouse. São mantidos apenas os utilizadores que seguem três ou mais categorias, de modo a selecionar os utilizadores mais ativos e para os quais existe informação suficiente para avaliar as recomendações. Após a construção do dataset, são executados os processos que tratam da estratégia de divisão do mesmo, conforme figura5.3.
Figura 5.3: Divisão do dataset
A estratégia de divisão de dados consiste, em primeiro lugar, na ordenação temporal dos tuplos pela data de criação da relação entre utilizador e canal, ou seja, instante em que um utilizador co- meça a seguir um determinado canal. Após a ordenação dos dados procede-se a divisão do dataset em dois subconjuntos, o training set cujo particionamento corresponde a 80% dos dados, e os res- tantes 20% para o validation set. Por último, são selecionados aqueles utilizadores que constam em ambos os subconjuntos anteriormente referidos, para serem utilizados como utilizadores de teste, testing set. O processo de recomendação é aplicado aos utilizadores de teste para os quais se pretende prever o comportamento natural de seguir novos canais. Esta previsão pode ser validada, analisando se as previsões correspondem ao que está presente no validationset.