Procesamiento de grandes volúmenes de datos, el caso de las entidades financieras

Los grandes volúmenes de datos se han convertido en una palabra de moda en el mundo de la tecnología en los últimos años.

Desde el cambio climático a la estrategia corporativa, estamos en un momento de la historia en el que los datos y más aún las conclusiones que se extraen de ellos se presentan como la solución definitiva a los problemas más difíciles.

Por Antonio Serena

Así, no basta con capturar y almacenar información relevante, sino que hay más en el tratamiento masivo de datos y cuatro son las etapas imprescindibles que hay que contemplar al objeto de que la información recopilada pueda crear valor para nuestro negocio: Adquisición, Organización de la información, Análisis, Decisión.

En el caso de las grandes entidades financieras, están aprovechando las tecnologías de Big Data para tomar decisiones de una manera más efectiva y para mejorar sus ingresos por medio de un mayor impacto comercial. Las empresas son capaces de conocer mucho mejor a sus clientes gracias a estas tecnologías y, por tanto, de mejorar y personalizar sus productos y ofertas. Todo esto sin olvidar que las entidades financieras y de crédito deben cumplir con la Ley de Protección de Datos, puesto que a través de los datos bancarios es posible identificar a una persona. Además, aunque los datos bancarios no tienen consideración de datos sensibles, estas entidades manejan grandes volúmenes de datos personales de manera sistemática, lo que va a implicar cumplir con algunas obligaciones más estrictas Reglamento General de Protección de Datos (RGPD).

La prioridad número uno de las instituciones que ofrecen servicios financieros es la gestión del riesgo. Entre los escenarios de gestión de riesgos donde se usa tecnología de Big Data podemos encontrar multitud de casos de uso en vigilancia de mercados y en Insider trading. En un entorno de cambio continuo las instituciones financieras necesitan una ayuda tecnológica a la hora de definir nuevas reglas para identificar y mitigar el riesgo. Muchos son los tipos de riesgos que se pueden gestionar con el uso de Big Data: incertidumbre en mercados financieros, susceptibilidad a las responsabilidades legales, riesgo de pérdida de clientes a la competencia, impacto de desastres naturales, riesgo de liquidez, etc. Las soluciones de Big Data permiten obtener la información oportuna en tiempo real, compartiendo entre los departamentos afectados el estado y posición respecto al riesgo permitiendo un mejor control del riesgo en todo momento.

El riesgo de crédito es el riesgo que se materializa en la pérdida económica procedente del incumplimiento de una contraparte de sus obligaciones contractuales. Se trata del riesgo de impago de una transacción y para calcularlo, tradicionalmente, las entidades bancarias utilizaban regresiones lineales que realizaban modelos en los que basaban sus predicciones. Sin embargo, la aparición de la Inteligencia Artificial y de las técnicas de aprendizaje automático, han suscitado el interés de todo el sector bancario. La realidad es que las técnicas clásicas pueden mejorarse gracias a la implementación de estas novedosas tecnologías debido a su capacidad de comprensión de los datos no estructurados. Se trata de la dificultad particular de materializar el riesgo de crédito lo que

ha hecho que las puertas de la Inteligencia Artificial se hayan abierto.

Arquitecturas

Respecto a las principales características de las arquitecturas para el procesamiento de grandes volúmenes de datos, es importante recalcar los siguientes puntos:

• Tolerancia a fallos. El sistema siempre funciona y esto debe quedar garantizado. Puede que algunas máquinas en momentos determinados puedan verse afectadas, pero se debe contar con una infraestructura que permita seguir disponiendo del sistema en su totalidad.
• Escalabilidad. Es imprescindible y hay que poder aumentar de forma sencilla las capacidades de procesamiento y almacenamiento de datos.
• Procesamiento distribuido. El tratamiento de los datos se realiza entre diferentes máquinas para mejorar los tiempos de ejecución y así dotar al sistema de la escalabilidad que ya hemos comentado.
• Datos distribuidos. Aunque ya lo hemos nombrado en el punto anterior, es bueno contabilizarlo como característica única.
• Localidad del dato. Los datos que se van a trabajar y los procesos que los analizan deben estar cerca para así evitar posibles transmisiones por red que hagan que surjan latencias y puedan así verse afectados los tiempos de ejecución.

Por otra parte, la necesidad de grandes velocidades de procesamiento de datos impone demandas únicas en la infraestructura de computación subyacente. La potencia de cálculo necesaria para procesar rápidamente grandes volúmenes de datos puede sobrecargar un clúster de servidores. Las empresas deben aplicar el poder de cálculo adecuado a las tareas de Big Data para lograr la velocidad deseada. Esto puede potencialmente demandar cientos de servidores que pueden distribuir el trabajo y operar de manera colaborativa. Alcanzar esa velocidad de una manera rentable es también un dolor de cabeza. Muchas organizaciones son reticentes a invertir en un servidor extenso y una infraestructura de almacenamiento que sólo se puede utilizar ocasionalmente para completar tareas de Big Data. Como resultado, la computación en la nube pública ha surgido como un vehículo primario para alojar grandes proyectos de todos los sectores.

Así, antes de abordar el proyecto es importante elegir muy bien cómo se va a hacer y a través de qué método:

• On-Premise. En este caso hablamos de fijar los datos en las instalaciones propias, en el hardware propiedad de la empresa. Será un hardware dedicado en exclusiva al procesamiento de estos datos y que debe estar preparado para dar respuesta a todos los procesos en el tiempo establecido. Mantenerlo todo en local aporta saber que nadie tiene acceso a esos datos, pero como desventaja está el alto coste que esto supone tanto a nivel de conocimiento como de la propia instalación necesaria para ejecutarlo. Hasta la fecha la mayoría de las instituciones financieras están optando por esta opción.
• Nube/Cloud. Esta opción cuenta con una infinidad de funcionalidades y grandes ventajas añadidas. Uno de los puntos fuertes es la inexistencia prácticamente de una inversión en hardware. Además, está altamente automatizado y personalizado y con poco presupuesto se puede iniciar fácilmente. Sus desventajas principales son el posible control de datos a terceros y depender de un proveedor externo.
• Híbrida. En este caso es fácil imaginar ya conociendo los dos métodos anteriores cuál es el resultado y ventajas y desventajas de contar con un desarrollo de arquitectura de datos en formato híbrido. Se puede decir que esto es lo mejor de ambos mundos, ya que es un sistema flexible, ya que no pierdes el control de los datos, pero no necesitas una grandísima infraestructura como en el On-Premise. Algunas de las ventajas son reducir el tiempo de comercialización, aprovechar las inversiones locales sin comprometer la agilidad empresarial y de TI o incluso aprovechar todos esos recursos y conocimientos en un solo entorno.

En cualquier caso, se nos generan dos problemas de índole diferente, pero que van muy unidos:

• Por un lado, nos encontramos con el problema del almacenamiento de los datos. Estos deben ser almacenados en sistemas y de maneras que podamos recuperarlos de una forma lo más sencilla y rápida posible. De nada nos sirven los datos si luego no somos capaces de encontrarlos o almacenarlos.
• Por otro, tenemos un problema con el procesamiento de estos. No es lo mismo, ni se utilizan las mismas técnicas, para procesar un fichero con 1000 líneas de datos (algo que podríamos hacer hasta en nuestro teléfono móvil) que procesar un fichero con 1000 millones de líneas, y el tiempo de procesado no es el mayor de nuestros problemas.

Ante estos retos, se desarrollaron una multitud de herramientas para el almacenamiento y procesamiento de datos de forma distribuida (es decir, haciendo que múltiples ordenadores trabajen en grupo realizando cada uno una parte de la tarea). Entre las herramientas más conocidas y utilizadas se encuentran: Apache Hadoop (Fig.1), Apache Spark (Fig.2), Apache Hive, Apache Cassandra, MongoDB, Apache Kafka, etc.

En cuanto a las arquitecturas, las más comunes para abordar este tipo de problemas son principalmente dos, Kappa y Lambda, en función de si el sistema necesita realizar un tratamiento de los datos en streaming (proceso que trata flujos de datos que se están recibiendo continuamente) o si, por el contrario, se puede realizar un procesamiento batch (proceso que trata un conjunto de datos que tiene un inicio y un final).

 

Lambda

Los conceptos que involucra la propuesta de la arquitectura lambda son:

• Por lotes/batch: programado para su ejecución diferida en el tiempo
• Casi Tiempo Real/near real-time: existe una pequeña diferencia de tiempo entre el momento en que ocurre el evento y en el que se procesa (segundos, o pocos minutos).
• Tiempo Real/real-time: la información se procesa y se consume en intervalos de tiempo muy muy pequeños (milisegundos, microsegundos).
• Streaming: habitualmente asociado al flujo continuo de datos.

Las características de la arquitectura Lambda son:

• La nueva información recogida por el sistema se envía tanto a la capa de batch como a la capa de streaming (denominada como Speed Layer en la Figura anterior).
• En la capa batch (Batch Layer) se gestiona la información en crudo, es decir, sin modificar, esto comúnmente se asocia al concepto de Data Lake. Los datos nuevos se añaden a los ya existentes. Seguidamente se hace un tratamiento mediante un proceso batch cuyo resultado serán las denominadas Batch Views, que se usarán en la capa que sirve los datos para ofrecer la información ya transformada al exterior, incluso para generar modelos predictivos de Data Science.
• La capa que sirve los datos o Serving Layer, indexa las Batch Views generadas en el paso anterior de forma que puedan ser consultadas con baja latencia.
• La capa de streaming o Speed Layer, compensa la alta latencia de las escrituras que ocurre en la serving layer y solo tiene en cuenta los datos nuevos.
• Finalmente, la respuesta a las consultas realizadas se construye combinando los resultados de las Batch Views y de las vistas en tiempo real (Real-time Views), las cuales se han generado en el paso anterior.

 

Ventajas:

• Conserva los datos de entrada sin cambios.
• Esto permite reprocesar los datos cuando se producen cambios de criterio.

Desventajas:

• Mantener código diferente para producir el mismo resultado de dos sistemas distribuidos complejos (batch y speed) es costoso.
• Código muy diferente para MapReduce y Storm/Apache Spark
• Además, no sólo se trata de código diferente, sino también de depuración e interacción con otros productos.
• Al final es un problema sobre paradigmas de programación divergentes y diferentes.

Kappa

Respecto al anterior sistema, consiste en eliminar la capa batch dejando solamente la capa de streaming. Esta capa, a diferencia de la de tipo batch, no tiene un comienzo ni un fin desde un punto de vista temporal y está continuamente procesando nuevos datos a medida que van llegando. Como un proceso batch se puede entender como un stream acotado, se puede decir que el procesamiento batch es un subconjunto del procesamiento en streaming.

Se puede decir que los cuatro pilares principales de la Arquitectura Kappa, son los siguientes:

• Todo es un stream: las operaciones batch son un subconjunto de las operaciones de streaming, por lo que todo puede ser tratado como un stream.
• Los datos de partida no se modifican: los datos son almacenados sin ser transformados y las vistas se derivan de ellos. Un estado concreto puede ser re-calculado puesto que la información de origen no se modifica.
• Solo existe un flujo de procesamiento: puesto que mantenemos un solo flujo, el código, el mantenimiento y la actualización del sistema se ven reducidos considerablemente.
• Posibilidad de volver a lanzar un procesamiento: se puede modificar un procesamiento concreto y su configuración para variar los resultados obtenidos partiendo de los mismos datos de entrada.

Como requisito previo a cumplir, se tiene que garantizar que los eventos se leen y almacenan en el orden en el que se han generado. De esta forma, se puede variar un procesamiento concreto partiendo de una misma versión de los datos.

Estrategia de funcionamiento:

• Un sistema de mensajería (p.e. kafka) que mantenga el log de datos a procesar.
• Si se necesita reprocesar, se comienza el trabajo en el instante de datos requerido y su resultado se vuelca en otra tabla.
• Cuando este reprocesamiento finaliza, la aplicación comienza a leer de esta nueva tabla y se elimina la anterior.

Ventajas:

• Solo se re-computa cuando hay un cambio en el código.
• Solo se mantiene un código.
• Se puede volcar los datos de kafka a HDFS (disco), si hay limitaciones de memoria.

La Tecnología una vez más es una aliada para el negocio, especialmente cuando se trata de grandes volúmenes de datos en el sector financiero donde a menudo la información es crítica, debe ser analizada y, gracias al Big Data, la IA, y el Machine Learning, se obtienen resultados más rápidos y confiables, aunque como cualquier Tecnología, es susceptible de mejorarse.