Almudena Herrero: Big Data para la persecución del Fraude

Almudena Herrero ha sido alumna del Master de Arquitectura Big Data y ya ha presentado su proyecto sobre detección del fraude.

Nadie mejor que ella para explicárnoslo y contarnos como ha investigado y montado toda la estructura para la recogida de información:

Trabajo en Accenture desde hace 9 años y mi última asignación fue el departamento de fraude y riesgo de una compañía de telecomunicaciones española, por lo tanto en algunas ocasiones había trabajado con las aplicaciones de fraude y me parecían interesantes.

Además escogí este tema porque dada la situación económica del país los clientes tienden a interesarse cada vez más por tener robustos sistemas de prevención para poder evitar pérdidas económicas, por lo tanto abarca gran parte del mercado ya que se podría aplicar a diferentes tipos de negocio.

Por otra parte y tras documentarme bastante descubrí la pericia que pueden llegar a desarrollar algunas personas para evitar pagar sus deudas e intentar volver a establecer una relación comercial con una empresa en la que ha cometido fraude anteriormente. Esto aumentó mi interés ya que tuve que buscar los recovecos que se utilizaban e implementarlos para que el sistema  detectara que la persona que estaba intentando darse de alta ya había sido cliente de la compañía y además era un cliente fraudulento.

El sistema de gestión está planteado para una empresa de telecomunicaciones, en concreto para altas de línea fija por lo tanto todas las comprobaciones se basan en los datos personales del cliente. Como he indicado anteriormente la arquitectura se podría aplicar a otros negocios siempre y cuando se dispusiera de los datos personales del cliente a dar de alta para poder realizar las diferentes comprobaciones sobre los mismos.

La información de obtiene de diferentes fuentes, algunas son ficheros batch y otras son simulaciones de fuentes de datos streaming que registrarán la información en tiempo real.

La arquitectura del sistema está compuesta por flume y Kafka para la ingesta de datos, flume obtendrá los ficheros batch y los almacenará en el HDFS y Kafka  que creará una cola de mensajes con los datos en streaming que posteriormente será leída por Spark.

La parte de procesamiento se realizará con Spark, tanto la batch como la streaming y tras realizar los diferentes procesos de negocio la información resultante será almacenada en una bbdd MongoDB.

En cuanto a mi paso por la escuela lo recordaré como una buena experiencia ya que ante cualquier problema siempre he recibido una buena respuesta tanto de los profesores como del personal de DKS y con el proyecto de fin de máster siempre he tenido respuestas rápidas a mis dudas y un buen asesoramiento.

En el fichero adjunto lo siguiente:

1- Documentación: Análisis funcional de la aplicación y presentación.

2- Ficheros Carga: ficheros con los que he realizado las pruebas.

3- Ficheros configuración flume: Fichero de configuración de los agentes de flume que deberían ponerse en la carpeta conf de flume para poder ejecutarlos.

4- Hadoop: Creación de rutas de los directorios que utilizo en el HDFS.

5- MongoDB: Creación de la bbdd y los índices de las tablas.

6- Proyecto: Código del proyecto.

Al final de documento del análisis hay un apartado denominado Ejecución de la aplicación, en este apartado se indica paso a paso cómo habría que ir ejecutando los agentes de flume y el código de la aplicación para que funcione correctamente.