Tema 4 de 5
Cargas de trabajo transaccionales y analíticas
Los mismos datos sirven para dos cosas muy distintas: registrar el día a día del negocio y analizar lo que ha pasado. Cada uso necesita sistemas diseñados de otra forma. El examen pregunta las propiedades ACID, las piezas de una arquitectura analítica y la diferencia entre data lake, data warehouse y lakehouse.
Contenido
Procesamiento transaccional (OLTP)
Un sistema transaccional registra transacciones: eventos concretos que la organización quiere seguir. Puede ser financiera (mover dinero entre cuentas) o comercial (cobrar un producto a un cliente). Piensa en una transacción como una unidad de trabajo pequeña y discreta.
- Suelen manejar mucho volumen: a veces millones de transacciones al día, con datos accesibles rápidamente.
- A este trabajo se le llama OLTP (Online Transactional Processing).
- Se apoyan en bases de datos optimizadas para lectura y escritura, con operaciones de crear, leer, actualizar y eliminar (CRUD).
- Dan soporte a las aplicaciones del negocio en vivo, llamadas aplicaciones LOB (line of business).
Propiedades ACID
Los sistemas OLTP aplican las transacciones con semántica ACID para garantizar la integridad. Ejemplo: transferir 40 dólares de la cuenta A (saldo 100) a la cuenta B (saldo 50).
Atomicidad
La transacción es una sola unidad que se completa entera o falla entera. Si no se puede abonar a B, tampoco se carga a A.
Consistencia
La base de datos solo pasa de un estado válido a otro. Al terminar, el dinero se ha movido de una cuenta a la otra.
Aislamiento
Las transacciones concurrentes no se interfieren. Una consulta de saldos durante la transferencia no ve una cuenta antes y otra después.
Durabilidad
Una vez confirmada, la transacción permanece. Aunque se apague el sistema, al volver los saldos nuevos siguen ahí.
Procesamiento analítico
El procesamiento analítico suele usar sistemas de solo lectura (o casi) que guardan grandes volúmenes de datos históricos o métricas de negocio. El análisis puede basarse en una instantánea de los datos en un momento dado o en una serie de instantáneas.
Arquitectura analítica típica
Extraer y cargar: Los datos operativos se extraen, transforman y cargan (ETL) en un data lake; o se extraen y cargan primero y se transforman después (ELT), un patrón común en los lakehouses modernos.
Esquema de tablas: Los datos se cargan en tablas: en un lakehouse, con abstracciones tabulares sobre archivos del data lake, o en un data warehouse con un motor SQL totalmente relacional.
Modelo analítico: Los datos se pueden agregar en un modelo OLAP, hoy llamado normalmente modelo semántico (históricamente, cubo).
Consumo: Los datos del lake, el warehouse y el modelo se consultan para generar informes, visualizaciones y paneles.
La diferencia entre ETL y ELT es el orden: transformar antes de cargar o después. El dominio D4 lo desarrolla.
Data lake, data warehouse y lakehouse
Data lake
Habitual en análisis a gran escala, cuando hay que reunir y analizar un gran volumen de datos basados en archivos.
Data warehouse
Forma consolidada de guardar datos en un esquema relacional optimizado para lectura: consultas de informes y visualización.
Lakehouse
Innovación más reciente que combina el almacenamiento flexible y escalable de un data lake con la semántica de consulta relacional de un warehouse.
Desnormalizar para analizar
En el esquema analítico se suele desnormalizar parte de los datos que venían normalizados de OLTP: se introduce algo de duplicación para que las consultas sean más rápidas. Es lo contrario de lo que se busca en un sistema transaccional.
Modelos OLAP y semánticos
Un modelo OLAP (o modelo semántico) es un almacenamiento agregado optimizado para análisis. Calcula valores numéricos agregados (medidas) de las tablas de hechos para las intersecciones de dimensiones de las tablas de dimensiones: por ejemplo, ingresos por fecha, cliente y producto.
- Las agregaciones se organizan en niveles, lo que permite profundizar o resumir (drill down/up): ventas por región, por ciudad o por dirección.
- Como los datos están preagregados, las consultas que devuelven esos resúmenes son rápidas.
- Los modelos semánticos de Power BI son un ejemplo habitual.
| Usuario | Dónde trabaja normalmente |
|---|---|
| Científicos de datos | Directamente con archivos del data lake, para explorar y modelar |
| Analistas de datos | Consultando tablas del data warehouse para informes complejos |
| Usuarios de negocio | Consumiendo datos preagregados del modelo en informes y paneles |
Arquitectura de medallón
Patrón habitual para organizar los datos de un lakehouse en tres capas:
Bronze
Datos en bruto tal como llegan de los sistemas de origen, sin transformar, para poder reprocesarlos
Silver
Datos limpios y homogéneos: sin duplicados y con tipos estandarizados
Gold
Datos agregados y listos para el negocio, modelados para informes y análisis concretos
Crea límites de calidad claros en cada capa, y siempre se puede reprocesar desde Bronze si cambian los requisitos. Las plataformas que lo implementan, Microsoft Fabric y Azure Databricks, se ven en D4.
OLTP frente a análisis
| Transaccional (OLTP) | Analítico | |
|---|---|---|
| Objetivo | Registrar operaciones del negocio | Analizar e informar |
| Operaciones | Lectura y escritura (CRUD) | Solo lectura o casi |
| Datos | Actuales, transacción a transacción | Históricos, grandes volúmenes |
| Esquema | Normalizado | A menudo desnormalizado |
| Usuarios | Aplicaciones LOB | Analistas, científicos de datos, negocio |
Escenarios de examen
| Situación | Respuesta | Por qué |
|---|---|---|
| Registrar millones de pagos al día y consultarlos al instante | Carga transaccional (OLTP) | Lecturas y escrituras rápidas con integridad. |
| Una transferencia debe cargar una cuenta y abonar otra, o ninguna | Atomicidad | Todo o nada. |
| Mientras se hace una transferencia, otra consulta no ve saldos a medias | Aislamiento | Las transacciones concurrentes no se interfieren. |
| Tras confirmar la transacción, sobrevive a un apagado | Durabilidad | Lo confirmado queda persistido. |
| Analizar cinco años de ventas por región y producto | Carga analítica | Datos históricos, solo lectura. |
| Guardar archivos en bruto de muchas fuentes para analizarlos después | Data lake | Almacén de archivos a gran escala. |
| Ver ventas totales por región y bajar hasta ciudad | Modelo OLAP / semántico | Agregados por jerarquías de dimensiones. |
| Separar datos en bruto, limpios y listos para el negocio | Arquitectura de medallón | Capas Bronze, Silver y Gold. |
Trampas frecuentes del examen
❓ ¿Qué propiedad ACID evita que una consulta vea una cuenta antes y otra después de una transferencia?
El aislamiento.
❓ ¿Qué propiedad garantiza que una transacción confirmada sobrevive a un apagado?
La durabilidad.
❓ ¿Los sistemas analíticos se optimizan para escribir mucho?
No. Son de solo lectura o casi; los optimizados para leer y escribir son los OLTP.
❓ ¿Un lakehouse es un data warehouse con otro nombre?
No. Combina el almacenamiento flexible de un data lake con la consulta relacional de un warehouse.
❓ ¿En qué capa del medallón están los datos en bruto?
En Bronze. Silver tiene datos limpios y Gold datos listos para el negocio.
❓ ¿Cómo se llama hoy normalmente a un modelo OLAP?
Modelo semántico (históricamente, cubo).
❓ ¿En ELT los datos se transforman antes de cargarlos?
No. En ELT se cargan primero y se transforman después; en ETL se transforman antes.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Durante una transferencia bancaria, falla el abono en la cuenta destino. El sistema deshace también el cargo en la cuenta origen. ¿Qué propiedad ACID se está aplicando?
¿Listo para poner a prueba "Cargas transaccionales y analíticas"?
Preguntas originales, cada una con su explicación.
Empezar un simulacro