Skip to content
tablas,columnas,filas,llaves primarias,relaciones,reglas de integridad.
datos demográficos,productos contratados,dispositivos registrados,interacciones digitales,preferencias,eventos recientes,alertas de riesgo.
clientes,cuentas,tarjetas,dispositivos,comercios,direcciones IP,beneficiarios,teléfonos.
transacciones,app móvil,web,call center,CRM,campañas,quejas,redes sociales,scoring interno.
¿qué clientes muestran señales tempranas de abandono?¿qué canal usa más cada cliente?¿qué comportamiento es anómalo respecto a su patrón histórico?¿qué clientes están conectados a redes sospechosas?¿qué oferta debería recibir cada segmento?
un dispositivo usado por múltiples cuentas,una dirección IP asociada a fraudes previos,una cuenta beneficiaria compartida,comercios con patrones anómalos,clientes vinculados indirectamente.
NoSQL
Propósito del bloque
El objetivo de esta sección es que el participante entienda por qué, en proyectos de Big Data financiero, las bases relacionales no desaparecen, pero dejan de ser suficientes para ciertos tipos de problemas.
El temario de la clase 2 incluye explícitamente la comparación entre bases NoSQL y bases relacionales tradicionales dentro del bloque de tecnologías clave de Big Data.
Idea central
Durante décadas, las bases de datos relacionales fueron la columna vertebral de los sistemas financieros. Funcionan muy bien cuando los datos son estructurados, las reglas son claras y la consistencia transaccional es indispensable.
Pero Big Data introdujo otro tipo de problema: datos que llegan en grandes volúmenes, con estructuras cambiantes, desde múltiples canales y con necesidades analíticas que no siempre encajan bien en tablas rígidas.
Ahí aparece NoSQL.
¿Qué significa NoSQL?
NoSQL no significa “no usar SQL nunca”.
Una mejor forma de entenderlo es:
NoSQL = Not Only SQL No todo problema de datos debe resolverse con una base relacional tradicional.
NoSQL agrupa distintos tipos de bases de datos diseñadas para manejar datos más flexibles, distribuidos y heterogéneos.
Por qué surge NoSQL
Las bases relacionales parten de una lógica muy ordenada:
Esa lógica es muy poderosa para sistemas como:
Sistema financiero
Por qué SQL funciona bien
Core bancario
Requiere exactitud transaccional
Contabilidad
Necesita estructura estable
Saldos
Exige consistencia fuerte
Reportes financieros
Requiere definiciones controladas
Catálogos maestros
Necesita gobierno y control
There are no rows in this table
Pero en una institución financiera moderna también aparecen datos como:
Fuente
Tipo de dato
App móvil
Eventos de navegación
Call center
Texto transcrito
Redes sociales
Opiniones no estructuradas
Dispositivos
Señales y logs
Open banking
Respuestas semiestructuradas
Ciberseguridad
Eventos de comportamiento
Marketing digital
Clickstream y journeys
There are no rows in this table
Estos datos no siempre tienen una estructura estable. Pueden cambiar con frecuencia, crecer rápidamente y no ajustarse bien al modelo de filas y columnas.
Narrativa para explicar en clase
La forma más simple de explicarlo es esta:
Un banco sabe perfectamente cómo guardar una cuenta, un saldo o una transacción. Para eso, una base relacional es extraordinaria.
Pero cuando quiere entender cómo se comporta un cliente antes de abandonar la institución, el problema cambia. Ahora necesita combinar transacciones, frecuencia de uso de la app, llamadas al call center, quejas, respuestas a campañas, navegación web, ubicación, horarios de interacción y quizá señales externas.
Ese perfil ya no se comporta como una simple tabla. Se parece más a un expediente dinámico, cambiante, con muchos tipos de datos.
Ahí NoSQL empieza a tener sentido.
Comparación ejecutiva: SQL vs NoSQL
Dimensión
SQL / Relacional
NoSQL
Modelo de datos
Tablas estructuradas
Documentos, grafos, columnas, clave-valor
Esquema
Fijo o rígido
Flexible o evolutivo
Escalabilidad
Principalmente vertical
Principalmente horizontal
Consistencia
Alta, fuerte
Variable según diseño
Mejor uso
Sistemas transaccionales
Datos heterogéneos y analítica flexible
Ejemplo financiero
Core bancario
Perfil 360 del cliente
There are no rows in this table
Tipos principales de bases NoSQL
1. Documentales
Guardan información en documentos, normalmente con estructura tipo JSON.
Ejemplo financiero: perfil de cliente enriquecido.
Un cliente puede tener:
No todos los clientes tienen exactamente los mismos atributos. Una base documental permite esa flexibilidad.
Tecnologías típicas: MongoDB, Couchbase.
2. Clave-valor
Funcionan como grandes diccionarios: una clave apunta a un valor.
Ejemplo financiero: consultas rápidas de sesión, tokens, parámetros de autenticación o respuestas de baja latencia.
Son útiles cuando se necesita velocidad extrema y el acceso es simple.
Tecnologías típicas: Redis, DynamoDB.
3. Columnares distribuidas
Organizan información por columnas y pueden escalar masivamente.
Ejemplo financiero: almacenamiento de eventos transaccionales, logs o series muy grandes que necesitan alto volumen de lectura y escritura.
Son útiles cuando hay grandes volúmenes distribuidos y cargas intensivas.
Tecnologías típicas: Cassandra, HBase.
4. Grafos
Representan entidades y relaciones.
Ejemplo financiero: detección de redes de fraude.
Un grafo permite analizar conexiones entre:
Esto ayuda a detectar patrones que no son evidentes en tablas tradicionales.
Tecnologías típicas: Neo4j, Amazon Neptune.
Caso financiero: perfil 360 del cliente
Problema
Un banco quiere construir una visión integral del cliente para mejorar personalización, prevención de churn y venta cruzada.
Los datos vienen de:
Dificultad
No todos los datos tienen la misma estructura. Algunos son registros formales; otros son eventos digitales; otros son texto; otros son señales de comportamiento.
Forzar todo a una base relacional puede generar rigidez, altos costos de modelado y pérdida de velocidad analítica.
Uso de NoSQL
Una base NoSQL documental puede guardar un perfil flexible del cliente, mientras una base de grafos puede ayudar a entender relaciones entre clientes, dispositivos y cuentas.
Resultado esperado
El banco puede responder preguntas como:
Caso financiero: fraude con grafos
En fraude, muchas veces el problema no está en una transacción aislada. Está en la red.
Una operación puede parecer normal si se analiza de forma individual. Pero puede volverse sospechosa si está conectada con:
Una base de grafos permite analizar esas relaciones de manera natural.
La pregunta ya no es solo:
¿Esta transacción es sospechosa?
Sino:
¿A qué red de relaciones pertenece esta transacción?
Qué problema resuelve NoSQL
Problema
Cómo ayuda NoSQL
Datos con estructura cambiante
Permite esquemas flexibles
Alta variedad de datos
Acepta documentos, eventos, grafos o clave-valor
Escalamiento horizontal
Distribuye datos entre múltiples nodos
Acceso rápido a ciertos patrones
Optimiza consultas específicas
Modelos analíticos exploratorios
Facilita integrar nuevas variables
There are no rows in this table
Qué problema no resuelve NoSQL
NoSQL no es una solución universal.
Puede generar nuevos riesgos si se usa sin criterio:
Riesgo
Explicación
Menor consistencia
Algunas arquitecturas sacrifican consistencia por disponibilidad
Duplicación de datos
Es común replicar información para acelerar consultas
Mayor complejidad
Cada tipo de NoSQL tiene lógica distinta
Gobierno más difícil
La flexibilidad puede producir desorden
Consultas menos estandarizadas
No todo se resuelve con SQL tradicional
There are no rows in this table
Mensaje crítico para los participantes
NoSQL debe verse como una herramienta arquitectónica, no como una moda tecnológica.
La decisión correcta no es reemplazar SQL con NoSQL. La decisión correcta es definir qué parte del problema necesita consistencia transaccional y qué parte necesita flexibilidad, escala o velocidad.
En una arquitectura financiera madura, SQL y NoSQL conviven.
Arquitectura típica combinada
Capa
Tecnología probable
Uso
Core transaccional
SQL
Saldos, cuentas, movimientos oficiales
Perfil flexible
NoSQL documental
Vista enriquecida del cliente
Relaciones sospechosas
Grafo
Fraude y conexiones
Eventos digitales
Columnar / clave-valor
Logs, clickstream, señales
Analítica masiva
Spark / lake
Modelos, segmentación, riesgo
There are no rows in this table
Ejercicio para clase
Clasificación rápida
Pedir a los participantes que clasifiquen cada caso como SQL, NoSQL o híbrido:
Caso
Tecnología sugerida
Justificación
Registro contable oficial
SQL
Requiere estructura y consistencia
Perfil 360 de cliente
NoSQL / híbrido
Datos heterogéneos y cambiantes
Red de dispositivos vinculados a fraude
Grafo
Importan las relaciones
Saldos de cuenta
SQL
Alta integridad transaccional
Eventos de navegación en app móvil
NoSQL / lake
Alto volumen y estructura flexible
There are no rows in this table
Frase de cierre del bloque
SQL sigue siendo indispensable para la verdad transaccional. NoSQL se vuelve poderoso cuando la institución necesita capturar variedad, escalar horizontalmente y analizar comportamientos que no caben bien en tablas rígidas.
Transición al siguiente bloque
Una vez que entendemos dónde y cómo guardar distintos tipos de datos, aparece la siguiente pregunta:
¿Cómo procesarlos suficientemente rápido?
Esa pregunta nos lleva a Spark, Flink y al procesamiento paralelo, temas que el programa ubica en el segundo bloque de la sesión junto con nube, AWS EMR y BigQuery.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.