Clase impartidas por de
🎯 Objetivo de la clase
Al finalizar esta clase, el participante será capaz de comprender las tecnologías fundamentales que soportan Big Data en instituciones financieras, distinguir entre arquitecturas tradicionales y distribuidas, evaluar cuándo conviene usar procesamiento batch o streaming, y relacionar tecnologías como Hadoop, NoSQL, Spark, Flink, AWS EMR y BigQuery con casos concretos de negocio financiero.
📦 Entregable de la sesión
Matriz tecnología–caso de uso financiero
Cada participante construirá una matriz donde relacione:
Agenda de la sesión
Apertura
Idea central
La tecnología de Big Data no debe presentarse como una colección de herramientas. En finanzas, la arquitectura tecnológica determina qué tan rápido una institución puede observar, interpretar y actuar sobre eventos económicos.
Un banco, una aseguradora, una casa de bolsa o una fintech no compiten solamente por tener más datos. Compiten por convertir esos datos en decisiones antes que sus competidores, antes que el fraude avance, antes que el riesgo se materialice y antes que el cliente abandone.
Pregunta detonadora
¿Qué ocurre cuando la velocidad del mercado supera la velocidad de la infraestructura?
La respuesta no es técnica. Es económica.
Cuando la infraestructura es más lenta que el entorno, aparecen consecuencias concretas:
Qué ocurre
Durante muchos años, las instituciones financieras diseñaron sistemas para registrar operaciones. El objetivo era conservar evidencia: quién hizo qué, cuándo, por cuánto dinero y bajo qué condiciones.
Ese mundo todavía existe. Sigue siendo indispensable.
Pero el nuevo problema es distinto. Hoy una institución financiera necesita reaccionar mientras los eventos están ocurriendo. Debe detectar anomalías en pagos digitales, recalcular riesgo intradía, analizar señales de mercado, integrar datos de comportamiento y responder a clientes que esperan decisiones inmediatas.
Por eso, en esta clase no vamos a estudiar tecnología como si fuera catálogo de software. Vamos a estudiarla como una infraestructura de decisión.
Caso detonador: fraude en pagos digitales
Escenario A: arquitectura tradicional
Una institución procesa las transacciones del día durante la noche. Al día siguiente revisa reglas, genera alertas y envía casos sospechosos a revisión.
El sistema funciona, pero llega tarde.
El fraude ya ocurrió. El cliente ya fue afectado. La pérdida ya se materializó.
Escenario B: arquitectura Big Data
La institución analiza cada transacción en el momento en que ocurre. Combina monto, ubicación, historial del cliente, dispositivo, patrón de comportamiento y señales externas. Un motor de streaming evalúa la operación en milisegundos y decide si autoriza, bloquea o solicita autenticación adicional.
La diferencia no es que el segundo caso “tenga más tecnología”.
La diferencia es que reduce incertidumbre económica antes.
Big Data no es almacenar más datos. Es diseñar sistemas capaces de convertir eventos masivos en decisiones económicamente superiores.
Infraestructura, Hadoop, NoSQL y SQL
1.3 SQL y bases relacionales
Las bases relacionales siguen siendo indispensables en finanzas.
No hay que caricaturizarlas como tecnología obsoleta. SQL es extraordinariamente útil cuando los datos tienen estructura clara, reglas de consistencia fuertes y necesidad de integridad transaccional.
Por ejemplo:
Comparación SQL vs NoSQL
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.
NoSQL no reemplaza SQL.
El error común es plantear la discusión como una guerra tecnológica. La pregunta ejecutiva no es “¿cuál es mejor?”. La pregunta correcta es: “¿qué tipo de dato, decisión y latencia tengo?”.
Si se trata de saldos contables, SQL suele ser la opción natural. Si se trata de millones de eventos semiestructurados de navegación digital, NoSQL puede ser más adecuado.
Descanso intermedio
Pausa de 10 minutos
Durante el descanso, pedir a los participantes que regresen con una idea concreta:
¿Qué proceso financiero de su organización está limitado por almacenamiento, procesamiento o latencia?
Esta pausa está alineada con la estructura general del programa: clases de 2 horas con 10 minutos de receso intermedio.
Taller aplicado
Construcción de la matriz tecnología–caso de uso
Instrucción
Cada participante o equipo debe seleccionar un problema financiero concreto y construir una matriz que justifique qué tecnología usaría.
Casos sugeridos
Plantilla de trabajo
Checklist del entregable
El caso de uso está claramente definido La decisión financiera está identificada La latencia requerida está justificada La tecnología seleccionada corresponde al problema Se distingue batch de streaming Se considera nube cuando aporta elasticidad Se identifican riesgos de costo, gobierno o cumplimiento
Síntesis
La clase comenzó con una idea: la arquitectura tecnológica no es solamente infraestructura. Es una capacidad de decisión.
Hoy revisamos cómo las tecnologías Big Data responden a distintos problemas:
Una buena arquitectura no es la más sofisticada. Es la que mejor conecta datos, decisión, latencia, costo y riesgo.