Processament de grans volums de dades, el cas de les entitats financeres

Els grans volums de dades s’han convertit en una paraula de moda en el món de la tecnologia en els darrers anys.

Estem en un punt de la història en el que les dades, i encara més les conclusions que s’extrauen d’elles, es presenten com la solució definitiva als problemes més difícils.

Per Antonio Serena

De manera que no és suficient amb capturar i emmagatzemar informació rellevant sinó que s’ha de fer un tractament massiu de les dades, en concret són quatre les etapes imprescindibles que necessitarem perquè la informació recopilada pugui aportar valor al nostre negoci. Adquisició, Organització de la informació, Anàlisis i Decisió.

Les grans entitats financeres estan aprofitant les tecnologies de Big Data per prendre decisions més efectives per tal de millorar els seus ingressos mitjançant un major impacte comercial. Les empreses són capaces de conèixer millor els seus clients gràcies a aquestes tecnologies i, per tant, de millorar i personalitzar els seus productes i ofertes. Tot això sense oblidar que les entitats financeres i de crèdit hi han de complir amb la Llei de protecció de dades donat que a través de les dades bancàries es pot identificar a les persones. A més, aquestes dades bancàries no contemplen les dades delicades, aquestes entitats gestionen grans volums de dades personals de manera sistemàtica, la qual cosa implica complir amb les obligacions més estrictes del Reglament General de Protecció de Dades (RGPD).

La prioritat número 1 d’aquestes institucions és la gestió del risc. Entre els escenaris de la gestió de riscos on es fa ús de la tecnologia Big Data podem trobar multitud de casos d’ús en la vigilància de mercats i en el Insider trading. En un entorn canviant les institucions financeres necessiten una ajuda tecnològica a l’hora de definir noves mesures per identificar i prevenir el risc. Es poden gestionar multitud de riscos amb el Mig Data: incertesa en els mercats financers, susceptibilitat a les responsabilitats legals, risc de pèrdua de clients, impacte per desastres naturals, risc de liquiditat, etc. Les solucions Big Data permeten obtenir informació a temps reals compartint entre els departaments afectats l’estat i posició respecte al risc permetent un major control del risc en tot moment.

El risc de crèdit és el risc que es materialitza en una pèrdua econòmica procedent del acumpliment de les obligacions contractuals. Es tracta del risc d’impacte d’una transacció per calcular-ho, tradicionalment, les entitats bancàries utilitzaven regressions lineals que realitzaven models en els quals basaven les seves prediccions. No obstant això, amb l’aparició de la intel·ligència artificial i de les tècniques d’aprenentatge automàtic, han despertat l’interès de tot el sector. La realitat és que les tècniques clàssiques poden millorar-se gràcies a la implementació de noves tecnologies gràcies a la seva capacitat de compressió de dades no estructurades. Es tracta de la dificultat de materialitzar el risc de crèdit el que ha obert les portes a la IA.

 

Arquitectures

Principals característiques de les arquitectures per al processament de grans volums de dades:

• Tolerància als errors. El sistema sempre funciona i això ha de garantir. Pot ser que algunes màquines es vegin afectades en alguns moments determinats i per això s’ha de comptar amb una infraestructura que permeti continuar disposant del sistema en la seva totalitat.
• Escalable. És imprescindible i s’ha de poder augmentar de manera senzilla les capacitats de processament i emmagatzemant de les dades.
• Processament distribuït. El tractament de les dades es realitza entre diferents màquines per a millorar els temps d’execució i així dotar al sistema de l’escalabilitat que ja hem comentat.
• Dades distribuïdes. Encara que ja ho hem comentat en el punt anterior, és bo comptabilitzar-lo com a característica única.
• Localitat de la dada. Les dades que es treballaran i els processos que els analitzen han d’estar a prop per poder evitar possibles transmissions que generin latències i afectin als temps d’execució.

D’altra banda, la necessitat de grans velocitats de processament de dades imposa demandes úniques en la infraestructura de computació subjacent. La potència de càlcul necessària per a processar de manera ràpida grans volums de dades pot sobrecarregar un clúster de servidors. Les empreses han d’aplicar el poder de càlcul adequat a les tasques de Big Data per a aconseguir la velocitat desitjada.

Això pot demandar centenars de servidors que poden distribuir el treball i operar de manera col·laborativa. Aconseguir aquesta velocitat de manera rendible és també un mal de cap. Moltes organitzacions són reticents a invertir en servidors externs i en infraestructura d’emmagatzematge que només es pot utilitzar ocasionalment per a completar tasques de Big Data. Com a resultat, la computació en el núvol públic ha sorgit com un vehicle primari per a allotjar grans projectes de tots els sectors.

Així, abans d’abordar el projecte és important triar molt bé com es farà i a través de quin mètode:

• On-Premise. En aquest cas parlem de fixar les dades a instal·lacions pròpies, en el hardware propietat de l’empresa. Serà un hardware dedicat en exclusiva al processament d’aquestes dades i ha d’estar preparat per a donar resposta a tots els processos en el temps establert. Mantenir-ho tot en local aporta saber que ningú té accés a aquestes dades però te un cost elevat. Per ara la majoria de les institucions financeres estan optant per aquesta opció.
• Nube/Cloud. Aquesta opció compta amb una infinitat de funcionalitats i grans avantatges afegits. Un dels punts forts és que no cal invertir en hardware. A més, està altament automatitzat i personalitzat, amb poc pressupost es pot iniciar fàcilment. Un dels principals inconvenients és el possible control de dades a tercers i haver de dependre d’un proveïdor extern.
• Híbrida. Arribats a aquest punt ja ens podem imaginar quins seran els avantatges e inconvenients de fer ús d’un desenvolupament d’arquitectura de dades en format híbrid. Podem dir que aquest té el millor de tots dos mons, ja que és un sistema flexible, no perds el control de les dades, no necessites una grandíssima infraestructura com amb el On-Premise. Alguns dels avantatges són reduir el temps de comercialització, aprofitar les inversions locals sense comprometre l’agilitat empresarial i de TU o fins i tot aprofitar tots aquests recursos i coneixements en un sol entorn.

En qualsevol cas, se’ns generen dos problemes de caràcter diferent, però que van molt lligats:

• Per una banda, ens trobem amb el problema de l’emmagatzematge de dades. Aquestes han de ser emmagatzemades de maneres que puguem recuperar-les de manera senzilla i ràpida. De res ens serveixen les dades si després no som capaces de trobar-les o emmagatzemar-les.
• Per altre banda, tenim un problema amb el processament. No és el mateix, ni s’utilitzen les mateixes tècniques, per a processar un fitxer amb 1000 línies de dades (alguna cosa que podríem fer fins i tot en el nostre telèfon mòbil) que processar un fitxer amb 1000 milions de línies, i el temps de processament no és el major dels nostres problemes.

Davant d’aquests reptes es van desenvolupar una multitud d’eines per a l’emmagatzematge i processament de dades de forma distribuïda (és a dir, fent que múltiples ordinadors treballin en grup realitzant cadascun una part de la tasca). Entre les eines més conegudes i utilitzades es troben: Apatxe Hadoop (Fig.1), Apatxe Spark (Fig.2), Apatxe Hive, Apatxe Cassandra, MongoDB, Apatxe Kafka, etc.

Respecte a les arquitectures, les més comunes per a abordar aquest tipus de problemes són principalment dos, Kappa i Lambda, en funció de si el sistema necessita realitzar un tractament de les dades en streaming (procés que tracta fluxos de dades que s’estan rebent contínuament) o si, per contra, es pot realitzar un processament batch (procés que tracta un conjunt de dades que té un inici i un final).

 

Lambda

Els conceptes que involucra la proposta de l’arquitectura lambda són:

• Lotes/batch: programat per a la seva execució diferida en el temps
• Casi Temps Real/near real-time: existeix una petita diferència de temps entre el moment que ocorre l’esdeveniment i en el qual es processa (segons, o pocs minuts).
• Temps Real/real-time: la informació es processa i es consumeix en intervals de temps molt molt petits (mil·lisegons, microsegons).
• Streaming: habitualment associat al flux continu de dades.

Les característiques de l’arquitectura Lambda són:

• La nova informació recollida pel sistema s’envia tant a la capa de batch com a la capa de streaming (denominada com Speed Layer a la imatge anterior).
• A la capa batch (Batch Layer) es gestiona la informació en cru, és a dir, sense modificar, això comunament s’associa al concepte de Data Lake. Les dades noves s’afegeixen a les ja existents. Seguidament es fa un tractament mitjançant un procés batch el resultat del qual seran les denominades Batch Views, que es faran servir a la capa que serveix les dades per a oferir la informació ja transformada a l’exterior, fins i tot per a generar models predictius de Data Science.
• La capa que serveix les dades o Serving Layer, indexa les Batch Views generades en el pas anterior de manera que puguin ser consultades amb latència baixa.
• La capa de streaming o Speed Layer compensa la latència alta de les escriptures que ocorre en la serving layer i només té en compte les dades noves.
• Finalment, la resposta a les consultes realitzades es construeix combinant els resultats de les Batch Views i de les vistes en temps real (Real-estafi Views), les quals s’han generat en el pas anterior.

 

Avantatges:

• Conserva les dades d’entrada sense canvis.
• Això permet reprocessar les dades quan es produeixen canvis de criteri.

Desavantatges:

• Mantenir codi diferent per a produir el mateix resultat de dos sistemes distribuïts complexos (batch i speed), és costós.
• Codi molt diferent per a MapReduce i Storm/Apatxe Spark
• A més, no sols es tracta de codi diferent, sinó també de depuració i interacció amb altres productes.
• Al final és un problema sobre paradigmes de programació divergents i diferents.

Kappa

Consisteix a eliminar la capa batch deixant solament la capa de streaming. Aquesta capa, a diferència de la de tipus batch, no té un inici i un final des d’un punt de vista temporal i està contínuament processant noves dades a mesura que van arribant. Com un procés batch es pot entendre com un stream delimitat, es pot dir que el processament batch és un subconjunt del processament en streaming.

Els quatre pilars principals de l’Arquitectura Kappa, són els següents:

• Tot és un stream: les operacions batch són un subconjunt de les operacions de streaming, per la qual cosa tot pot ser tractat com un stream.
• Les dades de partida no es modifiquen: les dades són emmagatzemades sense ser transformades i d’elles es deriven les vistes. Un estat concret pot ser re-calculat perquè la informació d’origen no es modifica.
• Només existeix un flux de processament: ja que mantenim un sol flux, el codi, el manteniment i l’actualització del sistema es veuen reduïts considerablement.
• Possibilitat de tornar a llançar un processament: es pot modificar un processament concret i la seva configuració per a variar els resultats obtinguts partint de les mateixes dades d’entrada.

Com a requisit previ a complir, s’ha de garantir que els esdeveniments es llegeixen i emmagatzemen en l’ordre en el qual s’han generat. D’aquesta manera, es pot variar un processament concret partint d’una mateixa versió de les dades.

Estratègia de funcionament:

• Un sistema de missatgeria (p.e. kafka) que mantingui el log de dades a processar.
• Si es necessita reprocessar, es comença el treball en l’instant de dades requerit i el seu resultat es bolca en una altra taula.
• Quan aquest reprocessament finalitza, l’aplicació comença a llegir d’aquesta nova taula i s’elimina l’anterior.

Avantatges:

• Només es re-computa quan hi ha un canvi en el codi.
• Només es manté un codi.
• Es pot bolcar les dades de kafka a HDFS (disc), si hi ha limitacions de memòria.

La Tecnologia una vegada més és una aliada per al negoci, especialment quan es tracta de grans volums de dades en el sector financer on sovint la informació és crítica, ha de ser analitzada i, gràcies al Big Data, la IA, i el Machine Learning, s’obtenen resultats més ràpids i de confiança, encara que com qualsevol Tecnologia, és susceptible de millorar-se.