Arquitectura del GBDS

Visión general

GBDS es el componente ABIS del Griaule Biometric Suite. El GBDS está implementado sobre la plataforma Apache Hadoop 3 y usa diversas de sus herramientas y componentes (como Kafka, Zookeeper, Ambari, HBase y HDFS) para implementar un ABIS (Sistema Automático de Identificación Biométrica) escalable, distribuido y tolerante a fallos.

El GBDS es responsable de:

• Almacenamiento: Persistencia de registros biométricos, solicitudes de clientes y sus respuestas, resultados de transacciones y registros en una base de datos escalable, distribuida y tolerante a fallos.

• Extracción: Procesamiento de datos en bruto (imágenes) de capturas biométricas para generación de templates que serán usados para comparaciones biométricas.

• Comparación: Ejecución eficiente de comparación de templates biométricos con distribución de carga entre diversos servidores (nodos).

• Procesamiento de Solicitudes: El GBDS recibe solicitudes de clientes, gestiona su ejecución entre los nodos del sistema y notifica a los clientes de forma asincrónica cuando las respuestas están disponibles. Las solicitudes se realizan a través de APIs HTTP/HTTPS. El GBDS implementa un terminal (endpoint) de alta disponibilidad y alto rendimiento (High Availability, High Throughput) para solicitudes de clientes.

Este documento describe la arquitectura del GBDS.

Componentes Hadoop

Apache Hadoop 3 es una colección de herramientas y componentes de código abierto para el desarrollo de sistemas distribuidos. Hadoop está basado en Java, una tecnología presente en más de 13 mil millones de dispositivos. El desarrollo de Hadoop comenzó en 2006, y pronto se convirtió en el estándar de facto para sistemas distribuidos tolerantes a fallos con alta disponibilidad. En 2013, Hadoop ya era usado en más de la mitad de las empresas Fortune 50.

El GBDS usa diversas herramientas y componentes del ecosistema Hadoop 3:

• HDFS es un sistema de archivos distribuido, escalable y portable. HDFS provee distribución transparente de datos entre nodos de almacenamiento y almacenamiento eficiente de archivos grandes y grandes colecciones de archivos.

• HBase es una base de datos distribuida no relacional, construida sobre el sistema de archivos HDFS.

• Zookeeper es un repositorio distribuido de pares clave-valor, y es usado por el GBDS como un gestor de consenso.

• Kafka es una plataforma de procesamiento distribuido de colas de tareas. Las colas gestionadas por Kafka se llaman tópicos (topics), que tienen contenido encolado por productores y procesado por consumidores. Kafka distribuye cargas de trabajo de tópicos eficientemente entre los nodos disponibles.

• Ambari es una herramienta de monitoreo y gestión para clusters Hadoop. Los administradores del GBDS interactúan y gestionan sus clusters a través de Ambari.

Nodos

Un cluster GBDS está compuesto por nodos, y cada nodo ejecuta los mismos componentes: HBase, Zookeeper, Ambari, Kafka y el Subsistema de nodos del GBDS. Todos los nodos pueden recibir solicitudes de aplicaciones cliente externas, y todos los nodos pueden enviar notificaciones asincrónicas a aplicaciones cliente externas.

El diagrama abajo muestra la estructura general de un cluster GBDS, que es una colección de nodos GBDS:

El GBDS usa dos bases de datos distintas: MYSQL y HBase. Los templates biométricos se almacenan en HBase, y los datos se distribuyen en subconjuntos llamados regiones. Cada nodo es responsable de por lo menos una región. Los datos biométricos son distribuidos en regiones de forma transparente por HBase, basado en la capacidad del hardware de cada nodo.

La base de datos MySQL almacena información de metadatos de transacciones, excepciones biométricas, casos criminales, perfiles biográficos registrados y latentes no resueltas. La base SQL almacena metadatos que referencian el registro HBase, que a su vez almacena los datos exigidos para el procesamiento, como imágenes y templates.

Un nodo actúa como Nodo Líder. Este nodo inicializa el cluster y particiona los datos biométricos entre los nodos GBDS disponibles. El Nodo Líder es elegido automáticamente por Zookeeper.

El componente Kafka del cluster gestiona tópicos (colas) para tareas pendientes (a ser procesadas por el cluster) y resultados (a ser entregados asincrónicamente a clientes o componentes del GBDS cuando las tareas se completan). El GBDS tiene múltiples tópicos para tareas pendientes, uno para cada nivel de prioridad. Las tareas en tópicos de mayor prioridad siempre son consumidas antes que las tareas en tópicos de menor prioridad. El GBDS tiene 8 niveles de prioridad: Lowest, Lower, Low, Default, High, Higher, Highest and Maximum (Muy baja, Muy baja, Baja, Default, Alta, Muy alta, Altísima y Máxima). Las aplicaciones cliente no pueden usar la prioridad Maximum/Máxima, que está reservada para operaciones internas del GBDS. En este manual el conjunto de tópicos para tareas pendientes está representado como una sola entidad.

El diagrama abajo muestra los componentes ejecutados en cada nodo:

El subsistema de nodos del GBDS es responsable de la lógica del ABIS. Actúa tanto como productor y consumidor de tópicos Kafka, y tanto como consumidor de solicitudes de clientes y productor de notificaciones enviadas a clientes.

Subsistema de Nodos del GBDS

El Subsistema de Nodos del GBDS implementa los flujos específicos para la operación del ABIS. Tiene 3 módulos internos principales: el Módulo de API, el Módulo Maestro, y el Módulo de Notificación. Cada uno de estos módulos puede ser iniciado y detenido de forma independiente en cada nodo.

El diagrama abajo muestra la arquitectura interna del componente GBDS y las interacciones entre sus partes:

• Cuando una solicitud de cliente es recibida por el Módulo de API, esta se resuelve localmente o se somete al tópico Kafka de Tareas Pendientes de la prioridad adecuada.

• El Módulo Maestro es responsable de gestionar la tolerancia a fallos, distribuir y cargar datos de la base de datos a la RAM en tiempo de arranque, y procesar tareas biométricas distribuidas. Consume continuamente ítems de Tareas Pendientes que implican procesamiento distribuido.

• Cuando una solicitud de cliente es completada, los resultados son consolidados por un nodo específico, que somete los resultados al tópico de Resultados en Kafka. El nodo de consolidación para cada transacción es determinado por una función de dispersión (hash function) del identificador único de la transacción, lo que distribuye las tareas de consolidación global de forma uniforme entre los nodos del cluster.

• El Módulo de Notificación es responsable de consumir ítems del tópico de Resultados de Kafka y enviar notificaciones asincrónicas a las aplicaciones cliente externas. El módulo de notificación es un singleton y puede estar activo en solo un nodo, elegido por el administrador del sistema.

Módulo de API

El Módulo de API tiene un componente principal, el Manejador de API (API Handler), que recibe solicitudes HTTP/HTTPS de aplicaciones cliente externas y puede 1) procesarlas localmente; o 2) preparar una transacción para procesamiento distribuido y encolarla en un tópico Kafka de Tareas Pendientes con la prioridad adecuada, para que pueda ser procesada por todo el cluster.

El Manejador de API es responsable de realizar la extracción de templates biométricos. Si una solicitud entrante tiene datos biométricos en bruto (es decir, imágenes en lugar de templates), este componente lanza procesos y/o hilos de extracción biométrica en el nodo local para generar los templates biométricos correspondientes. La elección de procesos o hilos depende de la modalidad biométrica.

Transacciones de Registro (Enrollment) y Identificación (Identification, 1:N) son encoladas a un tópico Kafka de Tareas Pendientes para ser procesadas de forma distribuida por todo el cluster.

Las demás transacciones son procesadas localmente por el Manejador de API. Cualesquiera templates necesarios para estas operaciones son extraídos localmente o recuperados de HBase, y las respuestas a los clientes son enviadas de forma síncrona: el tópico de Resultados de Kafka y el Módulo de Notificación no están involucrados en la operación.

Estas transacciones procesadas localmente pueden ser:

• Verificación (1:1): El Manejador de API extrae el template biométrico para la consulta (si fue enviado como imagen), recupera el template de referencia de HBase, realiza la comparación biométrica localmente, y responde directamente al cliente.

• Actualización (Update): El Manejador de API actualiza los datos biográficos y/o biométricos directamente en HBase, y encola un ítem de Tarea Pendiente en Kafka en la fila de prioridad Máxima para forzar a los nodos del cluster que tienen en RAM el perfil afectado a actualizar sus registros locales antes de comenzar a procesar nuevas tareas de prioridad inferior a la Máxima.

• Eliminar: El Manejador de API borra el registro de HBase, y encola un ítem de Tarea Pendiente en Kafka en la fila de prioridad Máxima, forzando a los nodos del cluster que tienen en RAM el perfil afectado a actualizar sus registros locales antes de comenzar a procesar nuevas tareas con prioridad inferior a la Máxima.

• Tratamiento de Excepción: El Manejador de API actualiza el registro de la excepción en HBase.

• Tratamiento de Calidad: El Manejador de API actualiza el registro de la transacción en HBase.

• Get, Listar: Estas son solicitudes sólo-lectura para obtener datos de registros o transacciones. El Manejador de API recupera los datos solicitados de HBase y responde directamente a la aplicación cliente.

Módulo Maestro

Este Módulo es responsable de inicializar (hacer boot) el nodo GBDS, gestionar el estado del cluster (por ejemplo, redistribuir la carga del cluster cuando un nodo falla), y de procesar transacciones biométricas.

Gestor de Nodos

Este componente lee archivos de configuración, inicia otros componentes y monitorea activamente los otros nodos del cluster y decide cómo redistribuir los datos biométricos en el cluster cuando otros nodos fallan.

Gestor de Boot

Este componente es responsable de cargar templates biométricos de HBase a la memoria RAM. La comparación biométrica eficiente requiere que los templates estén presentes en RAM. Cargar e indexar los templates en RAM es una tarea larga pero, una vez concluida, garantiza el procesamiento rápido de transacciones.

Flujo de Procesamiento de Tareas

Los demás componentes del Módulo Maestro realizan la comparación biométrica distribuida.

El componente Consumidor de Tareas (Task Consumer) consume continuamente ítems de los tópicos de Tareas Pendientes de Kafka. Siempre consume una tarea del tópico no vacío de mayor prioridad.

El componente Supervisor de Matchers (Matcher Supervisor) gestiona los procesos y/o hilos de matchers biométricos (la elección depende de la modalidad biométrica) y realiza las operaciones de comparación biométrica entre templates de consulta (de la transacción que se está procesando) y templates de referencia (de la base biométrica y cargados en la RAM del nodo local). La comparación de templates biométricos no es una operación trivial e involucra algoritmos complejos.

El componente Supervisor de Consolidación organiza los resultados generados por los matchers y los envía al Consolidador Global responsable de la transacción corriente, que puede estar ejecutándose en otro nodo del cluster.

El componente Consolidador Global recibe resultados de comparación de todos los nodos que contribuyeron al procesamiento de la tarea/transacción y genera resultados consolidados de comparación. Cada tarea/transacción es consolidada en un único nodo, elegido de forma determinista por una función de dispersión (hash function) sobre el identificador único de la transacción/perfil. Esta función de dispersión distribuye las tareas de consolidación global de forma uniforme entre los nodos disponibles del cluster.

Algunas transacciones, como búsquedas de latentes en sistemas forenses, exigen una operación de comparación adicional para refinar y/o reordenar los resultados, llamada Post-matching. El Supervisor de Post-Matching gestiona los procesos/hilos para tales casos, y también se ejecuta solo en el nodo de consolidación global asignado a la transacción.

El Manejador de Commits (Commit Handler) recibe los resultados finales del Consolidador Global o del Supervisor de Post-Matching y aplica de forma definitiva los resultados de la transacción:

• Todos los cambios al estado de la base biométrica se aplican en HBase.

• Si los resultados de la transacción requieren que cualquier nodo del cluster actualice sus datos locales en RAM (ej.: una nueva persona es añadida a la base como resultado de una transacción de alta), un ítem es encolado en el tópico de Kafka de Tareas Pendientes de prioridad Máxima.

• Un ítem es encolado al tópico de Resultados de Kafka, que será enviado a la aplicación cliente por el Módulo Notificador.

Módulo Notificador

Este módulo tiene un componente principal, el Manejador de Notificaciones, que consume continuamente ítems del tópico Resultados de Kafka y envía notificaciones HTTP/HTTPS a las aplicaciones cliente, informando de forma asincrónica el estado de las transacciones procesadas.

El Módulo Notificador es un singleton, y permanece activo en solo un nodo del cluster. El nodo que ejecuta el Módulo Notificador es elegido por el administrador del sistema.

Flujos de Transacción

Esta sección ilustra cómo cada tipo de transacción es procesado por el GBDS.

Identificación (1:N)

En una transacción de identificación (búsqueda 1:N), el cliente desea buscar en la base biométrica coincidencias con un dato biométrico de consulta. Puede ser necesario recorrer toda la base biométrica. El Manejador de API recibe la solicitud en el nodo al que fue enviada. Si la consulta contiene el dato biométrico en bruto (imágenes), sus templates son extraídos por el Manejador de API en este nodo local. La transacción es entonces encolada a un tópico de Tareas Pendientes de Kafka.

Todos los nodos del cluster eventualmente consumirán el ítem del tópico (módulo Consumidor de Tareas), y realizarán su parte de la búsqueda biométrica (módulos Supervisor de Matchers y Supervisor de Consolidación). Los resultados de cada nodo son enviados al Consolidador Global en el nodo de consolidación global, determinado por el identificador de la transacción.

En el nodo de consolidación global, el módulo de Consolidación Global espera hasta que el cluster complete la operación de búsqueda y consolida los resultados finales. Se realiza post-matching, si es necesario (módulo Supervisor de Post-Matching), el y Manejador de Commits aplica los resultados en HBase y encola un ítem en el tópico de Resultados de Kafka.

El Módulo de Notificación singleton, ejecutado en el nodo de Notificación, eventualmente consume el ítem asociado del tópico de Resultados de Kafka y envía una notificación asincrónica a la aplicación cliente, informando la finalización de la transacción.

Registro

En una transacción de Registro, el cliente solicita la inserción de una nueva persona en la base de datos, siempre que los datos biométricos no sean duplicados de algún registro existente. El flujo de esta transacción es muy similar al de la operación de Identificación, ya que implica una búsqueda 1:N por registros con biometrias duplicadas. Como la transacción exige que todos los nodos actualicen sus templates en memoria (para reconocer la presencia de la nueva persona en la base), el Manejador de Commits encolará un nuevo ítem al tópico de Tareas Pendientes con prioridad Máxima de Kafka, forzando la actualización de todos los nodos. Si la transacción genera una excepción que requiera revisión manual, permanecerá suspendida hasta que la excepción sea tratada por otra transacción.

Este flujo también se realiza cuando una transacción de Actualización (Update) añade nuevos datos biométricos a un registro existente.

Verificación (1:1), Get, Listar

En una transacción de Verificación, el cliente desea verificar si un dato biométrico de consulta coincide con una persona específica presente en la base de datos. Esta transacción es procesada por el Módulo de API en el mismo nodo que recibe la solicitud. El Módulo de API recupera los templates biométricos de la persona desde HBase, realiza la comparación biométrica localmente y responde al cliente de forma síncrona.

Get y Listar son transacciones de solo-lectura para recuperar datos y/o resultados del GBDS. Son procesadas localmente por el Módulo de API, que recupera los datos de HBase y responde al cliente de forma síncrona.

Actualización, Eliminar

En una transacción de Actualización (Update), el cliente desea cambiar datos biográficos y/o biométricos de un registro existente. Si se insertan nuevos datos biométricos, la transacción sigue el flujo de un Registro, ya que la base debe ser recorrida en busca de biometrias duplicadas. De lo contrario, el Módulo de API realiza las extracciones de templates necesarias, actualiza HBase, responde al cliente de forma síncrona y encola un ítem en el tópico de Kafka de Tareas Pendientes con prioridad Máxima para forzar a todos los nodos del cluster a reconocer los cambios realizados.

En una transacción de Delete, el cliente desea eliminar a una persona de la base de datos. El Módulo de API realiza la eliminación en HBase y responde al cliente de forma síncrona. El módulo también encola un ítem en el tópico de Kafka de Tareas Pendientes con prioridad Máxima para forzar a todos los nodos del cluster a reconocer los cambios realizados.

Tratamiento de Excepción, Tratamiento de Calidad

El GBDS gestiona ítems de Excepción y de Control de Calidad. Estos se generan cuando transacciones de Registro encuentran sospechas de duplicado o transacciones de Actualización encuentran discrepancias entre las biometrias de consulta y las biometrias de referencia (Excepciones), y cuando se insertan datos biométricos de baja calidad (Control de Calidad). Estos ítems requieren revisión manual, dependiendo de las configuraciones del GBDS. Estas transacciones actualizan el estado de ítems pendientes de Excepción y Control de Calidad. El Manejador de API procesa estas transacciones localmente, actualiza su estado en HBase y responde al cliente de forma síncrona.