Skip to content

Clase 2 — Tecnologías y arquitectura de datos

Big Data Business Solutions in Finance
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:
Elemento
Pregunta guía
Problema financiero
¿Qué decisión o proceso se quiere mejorar?
Tipo de datos
¿Son estructurados, semiestructurados o no estructurados?
Latencia requerida
¿Se puede esperar o debe resolverse en tiempo real?
Tecnología recomendada
¿Conviene SQL, NoSQL, Hadoop, Spark, Flink o nube?
Lógica arquitectónica
¿Por qué esa tecnología es adecuada?
There are no rows in this table

Agenda de la sesión

Tiempo
Bloque
Propósito
0:00–0:15
Apertura
Conectar tecnología con decisiones financieras
0:15–0:50
Bloque 1
Infraestructura, Hadoop, NoSQL y SQL
0:50–1:00
Descanso
Pausa intermedia
1:00–1:35
Bloque 2
Spark, Flink, batch, streaming y nube
1:35–1:55
Taller
Construcción de matriz tecnología–caso de uso
1:55–2:00
Cierre
Síntesis ejecutiva y aprendizajes clave
There are no rows in this table

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:
Situación
Consecuencia económica
Fraude detectado tarde
Mayor pérdida esperada
Riesgo recalculado con retraso
Exposición no observada
Datos de cliente fragmentados
Menor personalización
Reportes regulatorios manuales
Mayor riesgo operativo
Modelos entrenados con datos limitados
Decisiones menos precisas
There are no rows in this table

Qué ocurre

ChatGPT Image 18 may 2026, 02_16_45 p.m..png
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

6b535963-0e53-4b6e-8b48-824bd54998e4.png

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.1

image.png

1.2

image.png

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:
Caso
Por qué SQL sigue siendo adecuado
Core bancario
Requiere consistencia transaccional
Contabilidad
Necesita estructura y auditoría
Saldos
Requiere precisión
Reportes financieros
Necesita definiciones estables
Catálogos maestros
Requiere control y consistencia
There are no rows in this table

1.4


image.png

Comparación SQL vs NoSQL

Dimensión
SQL
NoSQL
Estructura
Esquema fijo
Esquema flexible
Escalamiento
Usualmente vertical
Usualmente horizontal
Fortaleza
Consistencia
Flexibilidad
Datos ideales
Transaccionales
Heterogéneos
Uso financiero
Core, contabilidad, saldos
Cliente, eventos, logs, señales digitales
There are no rows in this table
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.

image.png


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

Caso
Decisión a habilitar
Fraude en pagos móviles
Autorizar, bloquear o escalar transacción
Scoring crediticio alternativo
Aprobar crédito con señales no tradicionales
Riesgo intradía
Detectar exposición relevante durante el día
Churn bancario
Identificar clientes con probabilidad de abandono
Trading con noticias
Generar señales a partir de eventos externos
There are no rows in this table

Plantilla de trabajo

Campo
Respuesta del equipo
Caso de uso financiero
Decisión que se quiere mejorar
Fuentes de datos
Tipo de datos
Latencia requerida
Batch o streaming
Tecnología recomendada
Justificación arquitectónica
Riesgos de implementación
Métrica de éxito
There are no rows in this table

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:
Tecnología
Pregunta que responde
Hadoop
¿Cómo almaceno datos masivos?
NoSQL
¿Cómo manejo datos flexibles o heterogéneos?
Spark
¿Cómo proceso grandes datasets rápidamente?
Flink
¿Cómo reacciono a eventos en tiempo real?
Nube
¿Cómo escalo sin comprar capacidad fija?
SQL
¿Dónde necesito consistencia transaccional?
There are no rows in this table


Una buena arquitectura no es la más sofisticada. Es la que mejor conecta datos, decisión, latencia, costo y riesgo.


Want to print your doc?
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.