1. Guia de Arquitetura do GBDS 4

1.1. Visão Geral

GBDS é o componente ABIS do Griaule Biometric Suite. O GBDS 4 é implementado sobre a plataforma Apache Hadoop 3 e usa diversas de suas ferramentas e componentes (tais como Kafka, Zookeeper, Ambari, HBase e HDFS) para implementar um ABIS (Sistema Automatizado de Identificação Biométrica) escalável, distribuído e tolerante a falhas.

O GBDS é responsável por:

• Armazenamento: Persistência de registros biométricos, solicitações de clientes e suas respostas, resultados de transações e logs em uma base de dados escalável, distribuída e tolerante a falhas.
• Extração: Processamento de dados crus (imagens) de capturas biométricas para geração de templates que serão usados para batimentos biométricos.
• Batimento: Execução eficiente de comparação de templates biométricos com distribuição de carga entre diversos servidores (nós).
• Processamento de Solicitações: O GBDS recebe solicitações de clientes, gerencia sua execução entre os nós do sistema e os notifica os clientes assincronamente quando as respostas se tornam disponíveis. Solicitações são realizadas através de APIs HTTP/HTTPS. O GBDS implementa um terminal (endpoint) de alta disponibilidade e alto fluxo (High Availability, High Throughput) para solicitações de clientes.

Este documento descreve a arquitetura do GBDS 4.

1.2. Componentes Hadoop

O Apache Hadoop 3 é uma coleção de ferramentas e componentes de código aberto para o desenvolvimento de sistemas distribuídos. Hadoop é baseado em Java, uma tecnologia presente mais de 13 bilhões de dispositivos. O desenvolvimento do Hadoop começou em 2006, e logo tornou-se o padrão de facto para sistemas distribuídos tolerantes a falha com alta disponibilidade. Em 2013, Hadoop já era usado em mais de metade das empresas Fortune 50.

O GBDS usa diversas ferramentas e componentes do ecossistema Hadoop 3:

• HDFS é um sistema de arquivos distribuído, escalável e portável. O HDFS provê distribuição transparente de dados entre nós de armazenamento e armazenamento eficiente de arquivos grandes e grandes coleções de arquivos.
• HBase é um banco de dados distribuído não-relacional, construído sobre o sistema de arquivos HDFS.
• Zookeeper é um repositório distribuído de pares chave-valor, e é usado pelo GBDS como um gerenciador de consenso.
• Kafka é uma plataforma de processamento distribuído de filas de tarefas. As filas gerenciadas pelo Kfka são chamadas tópicos (topics), que têm conteúdo enfileirado por produtores e processado por consumidores. Kafka distribui cargas de trabalho de tópicos eficientemente entre os nós disponíveis.
• Ambari é uma ferramenta de monitoração e gerenciamento para clusters Hadoop. Administradores do GBDS interagem e gerenciam seus clusters através do Ambari.

1.3. Nós

Um cluster GBDS é composto por nós, e cada nó executa os mesmos componentes: HBAse, Zookeeper, Ambari, Kafka e o Subsistema de nós do GBDS. Todos os nós podem receber requisições de aplicações-cliente externas, e todos os nós podem enviar notificações assíncronas para aplicações-cliente externas.

O diagrama abaixo mostra a estrutura geral de um cluster GBDS, que é uma coleção de nós GBDS:

O GBDS usa dois bancos de dados distintos: MYSQL e HBase. Templates biométricos são armazenados no HBase, e dados são distribuídos em subconjuntos chamados regiões. Cada nó é responsável por pelo menos uma região. Dados biométricos são distribuídos em regiões de forma transparente pelo HBase, baseado na capacidade do hardware de cada nó.

O banco de dados MySQL armazena informações de metadados de transações, exceções biométricas, casos criminais, perfis biográficos cadastrados e latentes não resolvidas. A base SQL armazena metadados que referenciam o registro HBase, que por sua vez armazena os dados exigidos para processamento, como imagens e templates.

Um nó atua como Nó Líder. Este nó inicializa o cluster e particiona os dados biométricos entre os nós GBDS disponíveis. O Nó Líder é escolhido automaticamente pelo Zookeeper.

O componente Kafka do cluster gerencia tópicos (filas) para tarefas pendentes (a serem processadas pelo cluster) e resultados (a serem entregues assincronamente a clientes ou componentes do GBDS quando tarefas são concluídas). O GBDS tem múltiplos tópicos para tarefas pendentes, um para cada nível de prioridade. Tarefas em tópicos de maior prioridade sempre são consumidas antes das tarefas em tópicos de menos prioridade. O GBDS tem 8 níveis de prioridade: Lowest, Lower, Low, Default, High, Higher, Highest and Maximum (Baixíssima, Muito Baixa, Baixa, Default, Alta, Muito Alta, Altíssima e Máxima). Aplicações cliente não podem usar a prioridade Maximum/Máxima, que é reservada para operações internas do GBDS. Neste manual o conjunto de tópicos para tarefas pendentes é representando como uma única entidade.

O diagrama abaixo mostra os componentes executados em cada nó:

O subsistema de nós do GBDS é responsável pela lógica do ABIS. Ele atua tanto como produtor e consumidor de tópicos Kafka, e tanto como consumidor de requisições de clientes e produtos de notificações enviadas para clientes.

1.4. Subsistema de Nós do GBDS

O Susbsistema de Nós do GBDS implementa os fluxos específicos para a operação do ABIS. Ele tem 3 módulos internos principais: o Módulo de API, o Módulo Mestre, e o Módulo de Notificação. Cada um destes módulos pode ser iniciado e parado de forma independente em cada nó.

O diagrama abaixo mostra a arquitetura interna do componente GBDS e as interações entre suas partes:

• Quando uma solicitação de cliente é recebida pelo Módulo de API, ela é resolvida localmente ou submetida ao tópico Kafka de Tarefas Pendentes da prioridade adequada.
• O Módulo Mestre é responsável por gerenciar a tolerância a falhas, distribuir e carregar dados do banco de dados para a RAM em tempo de boot, e processar tarefas biométricas distribuídas. Ele continuamente consome itens de Tarefas Pendentes que envolvem processamento distribuído.
• Quando uma solicitação de cliente é concluída, os resultados são consolidados por um nó específico, que submete os resultados para o tópico de Resultados no Kafka. O nó de consolidação para cada transação é determinado por uma função de espalhamento (hash function) do identificador único da transação, o que distribui as tarefas de consolidação global de forma uniforme entre os nós do cluster.
• O Módulo de Notificação é responsável por consumir itens do tópico de Resultados do Kafka e enviar notificações assíncronas às aplicações-cliente externas. O módulo de notificação é um singleton e pode estar ativo em apenas um nó, escolhido pelo administrador do sistema.

1.4.1. Módulo de API

O Módulo de API tem um componente principal, o Tratador de API (API Handler), que recebe requisições HTTP/HTTPS de aplicações-cliente externas e pode 1) processá-las localmente; ou 2) preparar uma transação para processamento distribuído e enfileirá-la em um tópico Kafka de Tarefas Pendentes com prioridade adequada, para que possa ser processada por todo o cluster.

O Tratador de API é responsável por realizar a extração de templates biométricos. Se uma requisição entrante tiver dados biométrico crus (i.e., imagens em vez de templates), este componente lança processos e/ou threads de extração biométrica no nó local para gerar os templates biométricos correspondentes. A escolha de processos ou threads depende da modalidade biométrica.

Transações de Cadastro (Enrollment) e Identificação (Identification, 1:N) são enfileiradas para um tópico Kafka de Tarefas Pendentes para serem processadas de forma distribuída por todo o cluster.

As demais transações são processadas localmente pelo Tratador de API. Quaisquer templates necessários para estas operações são extraídos localmente ou recuperados do HBase, e as respostas para os clientes são enviadas de forma síncrona: o tópico de Resultados do Kafka e o Módulo de Notificação não são envolvidos na operação.

Estas transações processadas localmente podem ser:

• Verificação (1:1): O Tratador de API extrai o template biométrico para a consulta (se enviado como imagem), recupera o template de referência do HBase, realiza a comparação biométrica localmente, e responde diretamente para o cliente.
• Atualização (Update): O Tratador de API atualiza os dados biográficos e/ou biométricos diretamente no HBase, e enfileira um item de Tarefa Pendente no Kafka na fila de prioridade Máxima para forçar os nós do cluster que têm em RAM o perfil afetado a atualizar seus registros locais antes de começar a processar novas tarefas de prioridade inferior à Máxima.
• Deletar: O Tratador de API apaga o registro do HBase, e enfileira um item de Tarefa Pendente no Kafka na fila de prioridade Máxima, forçando os nós do cluster que têm em RAM o perfil afetado a atualizar seus registros locais antes de começar a processar novas tarefas com prioridade inferior à Máxima.
• Tratamento de Exceção: O Tratador de API atualiza o registro da exceção no HBase.
• Tratamento de Qualidade: O Tratador de API atualiza o registro da transação no HBase.
• Get, List: Estas são requisições somente-leitura para obter dados de registros ou transações. O Tratador de API recupera os dados solicitados do HBase e responde diretamente para a aplicação cliente.

1.4.2. Módulo Mestre

Este Módulo é responsável por inicializar (dar boot) o nó GBDS, gerenciar o estado do cluster (por exemplo, redistribuir a carga do cluster quando um nó falha), e por processar transações biométricas.

1.4.2.1. Gerenciador de Nós

Este componente lê arquivos de configuração, inicia outros componentes e monitora ativamente os outros nós do cluster e decide como redistribuir os dados biométricos no cluster quando outros nós falham.

1.4.2.2. Gerenciador de Boot

Este componente é responsável por carregar templates biométricos do HBase para a memória RAM. Batimento biométrico eficiente requer que os templates estejam presentes em RAM. Carregar e indexar os templates em RAM é uma tarefa longa mas, uma vez concluída, garante o processamento rápido de transações.

1.4.2.3. Fluxo de Processamento de Tarefas

Os demais componentes do Módulo Mestre realizam o batimento biométrico distribuído.

O componente Consumidor de Tarefas (Task Consumer) consome continuamente itens dos tópicos de Tarefas Pendentes do Kafka. Ele sempre consome uma tarefa do tópico não-vazio de maior prioridade.

O componente Supervisor de Matchers (Matcher Supervisor) gerencia os processos e/ou threads de matchers biométricos (a escolha depende da modalidade biométrica) e realiza as operações de comparação biométrica entre templates de consulta (da transação sendo processada) e templates de referência (da base biométrica e carregados na RAM do nó local). O batimento de templates biométricos não é uma operação trivial e envolve algoritmos complexos.

O componente Supervisor de Consolidação organiza os resultados gerados pelos matchers e os envia para o Consolidador Global responsável pela transação corrente, que pode estar rodando em outro nó do cluster.

O componente Consolidador Global recebe resultados de batimento de todos os nós que contribuíram para o processamento da tarefa/transação e gera resultados consolidados de batimento. Cada tarefa/transação é consolidada em um único nó, escolhido de forma determinística por uma função de espalhamento (hash function) sobre o identificador único da transação/perfil. Esta função de espalhamento distribui as tarefas de consolidação global de forma uniforme entre os nós disponíveis do cluster.

Algumas transações, como buscas de latentes em sistemas forenses, exigem uma operação de batimento adicional para refinar e/ou reordenar os resultados, chamada de Pós-matching. O Supervisor de Pós-Matching gerencia os processos/threads para tais casos, e também é executado apenas no nó de consolidação global atribuído à transação.

O Tratador de Commits (Commit Handler) recebe os resultados finais do Consolidador Global ou do Supervisor de Pós-Matching e aplica de forma definitiva os resultados da transação:

• Todas as mudanças ao estado da base biométrica são aplicados no HBase.
• Se os resultados da transação exigem que quaisquer nós do cluster atualizem seus dados locais em RAM (ex.: uma nova pessoa for adicionada à base como resultado de uma transação de cadastro), um item é enfileirado no tópico do Kafka de Tarefas Pendentes de prioridade Máxima.
• Um item é enfileirado ao tópico de Resultados do Kafka, que será enviado à aplicação cliente pelo Módulo Notificador.

1.4.3. Módulo Notificador

Este módulo tem um componente principal, o Tratador de Notificações, que consome continuamente itens do tópico Resultados do Kafka e envia notificações HTTP/HTTPS para as aplicações-cliente, informando assíncronamente o status das transações processadas.

O Módulo Notificador é um singleton, e fica ativo em apenas um nó do cluster. O nó que roda o Módulo Notificador é escolhido pelo administrador do sistema.

1.5. Fluxos de Transação

Esta seção ilustra como cada tipo de transação é processado pelo GBDS.

1.5.1. Identificação (1:N)

Em uma transação de identificação (busca 1:N), o cliente deseja buscar a base biométrica por casamentos com um dado biométrico de consulta. A base biométrica inteira pode precisar ser percorrida. O Tratador de API recebe a solicitação no nó para o qual ela foi enviada. Se a consulta contém o dado biométrico cru (imagens), seus templates são extraídos pelo Tratador de API neste nó local. A transação é então enfileirada para um tópico de Tarefas Pendentes do Kafka.

Todos os nós do cluster eventualmente consumirão o item do tópico (módulo Consumidor de Tarefas), e realizarção sua parte da busca biométrica (módulos Supervisor de Matchers e Supervisor de Consolidação). Os resultados de cada nó são enviados para o Consolidador Global no nó de consolidação global, determinado pelo identificador da transação.

No nó de consolidação global, o módulo de Consolidação Global espera até o cluster completar a operação de busca e consolida os resultados finais. Pós-matching é realizado, se necessário (módulo Supervisor de Pós-Matching), o e Tratador de Commits aplica os resultados no HBase e enfileira um item no tópico de Resultados do Kafka.

O Módulo de Notificação singleton, executado no nó de Notificação, eventualmente consome o item associado do tópico de Resultados do Kafka e envia uma notificação assíncrona à aplicação cliente, informando a conclusão da transação.

1.5.2. Cadastro

Em uma transação de Cadastro, o cliente solicita a inserção de uma nova pessoa na base de dados, desde que os dados biométricos não sejam duplicatas de algum registro existente. O fluxo desta transação é bem similar ao da operação de Identificação, já que envolve uma busca 1:N por registros com biometrias duplicadas. Como a transação exige que todos os nós atualizem seus templates em memória (para reconhecer a presença da nova pessoa na base), o Tratador de Commits enfileirará um novo item ao tópico de Tarefas Pendentes com prioridade Máxima do Kafka, forçando a atualização de todos os nós. Se a transação gerar uma exceção que requeira revisão manual, permanecerá suspensa até que a exceção seja tratada por outra transação.

Este fluxo também é realizado quando uma transação de Atualização (Update) adiciona novos dados biométricos a um registro existente.

1.5.3. Verificação (1:1), Get, List

Em uma transação de Verificação, o cliente deseja verificar se uma dado biométrico de consulta casa com um pessoa específica presente na base de dados. Esta transação é processada pelo Módulo de API no mesmo nó que recebe a solicitação. O Módulo de API recupera os templates biométricos da pessoa do HBase, realiza o batimento biométrico localmente e responde para o cliente de forma síncrona.

Get e List são transações de somente-leitura para recuperar dados e/ou resultados do GBDS. Elas são processadas localmente pelo Módulo de API, que recupera os dados do HBase e responde para o cliente de forma síncrona.

1.5.4. Atualização, Delete

Em uma transação de Atualização (Update), o cliente deseja alterar dados biográficos e/ou biométricos de um registro existente. Se novos dados biométricos forem inseridos, a transação segue o fluxo de um Cadastro, pois a base precisa ser percorrida em busca de biometrias duplicadas. Senão, o Módulo de API realiza quaisquer extrações de templates necessárias, atualiza o HBase, responde para o cliente de forma síncrona e enfileira um item no tópico do Kafka de Tarefas Pendentes com prioridade Máxima para forçar todos o nós do cluster a reconhecer as alterações realizadas.

Em uma transação Delete, o cliente deseja remover uma pessoa da base de dados. O Módulo de API realiza a remoção do HBase e responde para o cliente de forma síncrona. O módulo também enfileira um item no tópico do Kafka de Tarefas Pendentes com prioridade Máxima para forçar todos o nós do cluster a reconhecer as alterações realizadas.

1.5.5. Tratamento de Exceção, Tratamento de Qualidade

O GBDS gerencia itens de Exceção e de Controle de Qualidade. Estes são gerados quando transações de Cadastro encontram suspeitas de duplicata ou transações de Atualização encontram discordâncias entre as biometrias de consulta e as biometrias de referência (Exceções), e quando dados biométricos de baixa qualidade são inseridos (Controle de Qualidade). Estes itens exigem revisão manual, dependendo das configurações do GBDS. Estas transações atualizam o status de itens pendentes de Exceção e Controle de Qualidade. O Tratador de API processa estas transações localmente, atualiza seu status no HBase e responde para o cliente de forma síncrona.