La dirección de Contoso Airlines lleva meses haciendo la misma pregunta y nadie sabe responderla con datos: qué rutas son realmente rentables por temporada. No es una consulta caprichosa; de ella dependen la programación del invierno, la renegociación de tasas con dos aeropuertos y la decisión de mantener o cerrar la ruta de Palma a Múnich. Responderla exige cruzar tres años de ventas de db-reservas, la ocupación real de los vuelos, las tarifas aplicadas que viven en Cosmos DB, los costes por rotación del sistema de tripulaciones y los retrasos operativos: unos 400 millones de filas.

El primer impulso —lanzar esa consulta contra db-reservas— es exactamente lo que no hay que hacer. Esta lección construye la alternativa: una plataforma analítica que responde preguntas grandes sobre datos históricos sin tocar ni una vez las bases operativas. Y con ella se cierra el módulo.

Aviso de coste importante: la analítica es donde las facturas se descontrolan más rápido. Un grupo de SQL dedicado de Synapse cuesta más de 1.000 € al mes si se deja encendido, y hay que pausarlo a mano. Los grupos de SQL sin servidor facturan por TB leídos, así que una consulta mal escrita sobre datos sin particionar puede costar más que un día entero de máquinas virtuales. Para aprender, usa SQL sin servidor con ficheros pequeños, y elimina el grupo de recursos al terminar.

1. Por qué las bases operativas no sirven para analizar
2. La arquitectura analítica y sus cinco piezas
3. Azure Data Lake Storage Gen2
4. Capas bronce, plata y oro
5. Formatos de fichero: CSV frente a Parquet y Delta
6. Azure Data Factory: la canalización nocturna
7. Actividad de copia frente a flujos de datos de asignación
8. Azure Synapse Analytics
9. Microsoft Fabric, con honestidad
10. Power BI y el cuadro de mando de rentabilidad
11. Gobierno del dato con Microsoft Purview
12. Los costes de la analítica y cómo se disparan
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

Una base de datos transaccional (OLTP) y una analítica (OLAP) están optimizadas para cosas opuestas:

La consecuencia práctica: una consulta analítica sobre la base operativa recorre millones de filas, ocupa la memoria del motor, invalida sus cachés y bloquea recursos. Aunque acabe funcionando, degrada la venta de billetes para todos los clientes mientras dura. Por eso se separan los mundos, y la separación tiene además una ventaja de negocio: el histórico analítico conserva datos que la base operativa borra o archiva.

Toda plataforma analítica moderna, se llame como se llame, tiene las mismas cinco piezas:

Ingesta (traer los datos), almacenamiento (guardarlos barato y en bruto), transformación (limpiarlos y agregarlos), servicio (exponerlos para consultar) y consumo (visualizarlos). Azure pone un servicio para cada pieza, y lo importante es entender el papel de cada uno antes que sus menús.

Data Lake Storage Gen2 no es un servicio aparte: es una cuenta de Azure Storage, la misma de la lección 02-04, con una opción activada al crearla: el espacio de nombres jerárquico. Eso cambia dos cosas fundamentales:

• Directorios reales. En Blob Storage, 2026/07/ventas.parquet es un nombre plano que simula carpetas; renombrar "una carpeta" con un millón de ficheros significa copiar y borrar uno a uno. Con espacio de nombres jerárquico, el directorio existe de verdad y renombrarlo es una operación atómica de milisegundos. Para un motor analítico que escribe y reorganiza miles de ficheros, la diferencia es enorme.
• ACL POSIX. Además del control de acceso por RBAC, se pueden asignar permisos de lectura, escritura y ejecución a nivel de directorio y de fichero para usuarios y grupos de Microsoft Entra ID. Contoso lo usa para que el equipo financiero de Nuria Peña lea la capa oro pero no tenga acceso a los datos personales de la capa bronce.

Todo lo aprendido en 02-04 sigue vigente: niveles de acceso Hot, Cool y Archive con políticas de ciclo de vida, redundancia, cifrado y acceso con identidad de Entra ID en lugar de claves.

La organización en tres capas —también llamada arquitectura de medallón— evita el destino habitual de los lagos de datos: convertirse en un pantano donde nadie sabe qué fichero es fiable.

Las tres reglas que hacen que funcione: la capa bronce nunca se modifica (si una transformación falla, se rehace desde ahí sin volver a molestar al origen); las transformaciones solo van hacia adelante; y solo la capa oro se conecta a los cuadros de mando, lo que evita que cada analista construya su propia versión de la verdad.

Fíjate en la ruta de bronce: los datos se guardan particionados por fecha en directorios anio=/mes=/dia=. No es cosmético. Cuando una consulta filtra por agosto de 2026, el motor lee solo ese directorio en lugar de tres años de ficheros. Es la optimización que más dinero ahorra en toda esta lección.

El motivo de que el formato columnar importe tanto es directamente económico. La consulta de rentabilidad usa 4 columnas de una tabla de 40. En CSV hay que leer los 400 GB completos; en Parquet se leen unos 12 GB, y como el sin servidor de Synapse factura por TB leídos, la misma consulta cuesta unas 30 veces menos. Regla práctica: los datos entran como vengan, pero en el lago se guardan en Parquet (o Delta si hay que actualizar filas), siempre particionados por fecha.

Data Factory es el servicio de integración y orquestación. Sus cinco conceptos, que son los mismos en Synapse Pipelines y en Fabric:

Ese último concepto es el que más confusión genera y el que Contoso necesita entender bien: para leer db-reservas, que solo es accesible por punto de conexión privado, hace falta un entorno de ejecución con acceso a la red virtual; y para leer el sistema de facturación heredado del sótano de Barcelona haría falta un entorno autohospedado, un agente instalado en un servidor local que establece la conexión de salida.

La canalización nocturna de Contoso copia cada día las reservas del día anterior a la capa bronce:

Tres decisiones de diseño están escritas en ese JSON. La consulta trae solo el día anterior en lugar de la tabla entera: eso se llama carga incremental y es la diferencia entre una copia de dos minutos y una de dos horas que además castiga la base operativa. El destino es Parquet en el lago. Y la política de reintentos evita que un fallo transitorio de red obligue a alguien a relanzar la canalización a mano por la mañana.

El desencadenador es de ventana de saltos de tiempo a las 03:00, no una programación simple, porque garantiza ventanas de tiempo no solapadas y permite reprocesar un día concreto si se detecta un error: se relanza la ventana del 11 de agosto y se corrige solo ese directorio.

El criterio es directo: usa la actividad de copia para mover y los flujos de datos solo cuando la transformación lo justifique. Si tu equipo sabe escribir SQL o Python, transformar con un cuaderno de Spark o con vistas de Synapse sin servidor suele ser más barato y más fácil de versionar en Git que un flujo visual.

Synapse es un espacio de trabajo que reúne varios motores. Lo importante es saber cuál usar:

El grupo sin servidor es la puerta de entrada natural, porque permite consultar el lago sin cargar nada en ningún sitio:

OPENROWSET lee los ficheros donde están; el ** recorre los subdirectorios de partición. No hay que crear tablas ni cargar datos, y si mañana llegan más ficheros a esa ruta, la misma consulta los incluye. Cuando una consulta como esta se usa a diario, se guarda como vista en una base de datos sin servidor y Power BI se conecta a ella.

El grupo dedicado, en cambio, es un almacén de datos completo con su almacenamiento columnar propio y distribución de tablas. Aporta rendimiento constante y alta concurrencia, y cuesta lo que cuesta: se paga por hora encendido, se use o no, así que se pausa cuando no se necesita. Contoso, con 400 millones de filas y una decena de analistas, empieza por sin servidor y solo valorará un grupo dedicado si la concurrencia lo exige.

Microsoft Fabric es la evolución donde Microsoft está convergiendo todo esto: Data Factory, Synapse, Power BI y el lago en una única plataforma SaaS, con un almacenamiento común llamado OneLake, formato Delta por defecto y facturación por capacidad en lugar de por servicio.

Lo honesto es decir tres cosas. Primera: los conceptos de esta lección —capas del lago, Parquet, canalizaciones, motores SQL y Spark— son los mismos en Fabric, así que nada de lo aprendido se pierde. Segunda: Fabric es hacia donde apuntan los desarrollos nuevos, y para un proyecto que empieza hoy merece una evaluación seria. Tercera: Synapse y Data Factory siguen plenamente soportados y son lo que hay desplegado en la mayoría de las organizaciones, incluida la Contoso de este curso, que ya tiene su plataforma montada y no va a rehacerla por una novedad.

Power BI es la capa de consumo: se conecta a la capa oro o a las vistas sin servidor y produce el cuadro de mando que responde la pregunta de la dirección. El de Contoso tiene una página por pregunta: ingresos y margen por ruta y temporada, ocupación media frente a punto de equilibrio, evolución de los últimos 36 meses y detalle por ruta.

Dos decisiones técnicas que conviene conocer: el modo importación copia los datos en el modelo de Power BI y da respuestas instantáneas, con el precio de que los datos son de la última actualización; el modo DirectQuery consulta el origen en cada interacción, siempre actualizado pero más lento y con coste por consulta —importante aquí, porque cada interacción con sin servidor lee TB y factura—. Para un cuadro de mando que se refresca cada noche, importación es la elección correcta y la más barata.

Cuando hay un lago con tres capas, decenas de ficheros y varios equipos consumiendo, aparecen preguntas nuevas: ¿de dónde sale este número? ¿quién puede ver esta columna? ¿dónde hay datos personales?

Microsoft Purview responde a eso con un catálogo que analiza automáticamente los orígenes y construye un inventario, clasifica datos sensibles (detecta que una columna contiene correos o documentos de identidad) y muestra el linaje: qué origen alimenta qué fichero y qué informe. Para Contoso importa especialmente por el RGPD: saber exactamente en qué capas del lago hay datos personales de pasajeros es un requisito, no una comodidad. Aquí queda solo introducido; la gobernanza se retoma con Azure Policy en la lección 04-06.

Las cuatro causas de las facturas desagradables, con su remedio:

Y una medida de higiene que evita el goteo: aplicar una política de ciclo de vida al lago, como la de la lección 02-04, para que los datos de la capa bronce con más de un año pasen a nivel Cool y los de más de tres a Archive. La capa oro, que es la que se consulta, se queda en Hot.

• Consultar la base operativa para hacer informes. Degrada la venta de billetes mientras dura. Es el error que da origen a toda esta lección.
• Olvidar pausar el grupo de SQL dedicado. Es la factura sorpresa más habitual de Azure y la más fácil de evitar.
• Guardar el lago en CSV. Multiplica por decenas el coste de cada consulta sin servidor y pierde los tipos de datos.
• No particionar por fecha. Sin particiones, cada consulta lee todo el histórico aunque solo pida un mes.
• Modificar la capa bronce. Es la copia fiel del origen y la red de seguridad para rehacer cualquier transformación. Si se toca, se pierde.
• Conectar los cuadros de mando a la capa plata "porque es más completa". Cada analista acaba con su propia versión de la verdad y dos informes dan cifras distintas en la misma reunión.
• Copiar datos personales a la capa oro sin necesidad. El RGPD se aplica igual en el lago; seudonimiza al pasar a plata.
• Consejo: empieza siempre por SQL sin servidor. Solo cuando midas que la concurrencia o el rendimiento no dan, valora un grupo dedicado.
• Consejo: pon una alerta de presupuesto específica para el grupo de recursos de analítica. Es el que más rápido se desvía.

Hay que llevar al lago tres orígenes: db-reservas (crece 40.000 filas al día), el catálogo de tarifas de Cosmos DB (cambia dos veces al día) y un CSV mensual de costes de combustible que envía un proveedor externo.

1. Para cada origen, indica estrategia de carga (completa o incremental), frecuencia y tipo de desencadenador.
2. ¿Qué tipo de entorno de ejecución de integración necesita cada uno y por qué?
3. ¿En qué formato y con qué estructura de directorios los guardarías en bronce?

La consulta de rentabilidad recorre tres años de reservas: 400 GB en CSV o 40 GB equivalentes en Parquet particionado por año y mes, y usa 4 columnas de 40. Se ejecutará una vez al día para refrescar el cuadro de mando y, ocasionalmente, de forma interactiva.

1. ¿Qué motor de Synapse elegirías y por qué descartas los otros?
2. Estima el orden de magnitud de los datos leídos en CSV frente a Parquet particionado, si la consulta filtra un solo año.
3. ¿Qué modo de conexión de Power BI usarías y qué impacto tiene en el coste?

Nuria Peña detecta que el grupo de recursos de analítica ha pasado de 300 a 2.400 € al mes. Encuentras: un grupo de SQL dedicado activo desde hace seis semanas sin consultas en las últimas cuatro, ficheros CSV sin particionar en toda la capa bronce, una canalización que copia dbo.Reservas completa cada noche y tres flujos de datos que solo renombran columnas.

1. Ordena los cuatro problemas por ahorro potencial.
2. Propón una corrección concreta para cada uno.
3. ¿Qué medida preventiva implantarías para que no vuelva a ocurrir?

Solución 1:

1. Estrategias: db-reservas, incremental por fecha (solo las reservas del día anterior), diaria de madrugada, con desencadenador de ventana de saltos de tiempo para poder reprocesar días concretos. Cosmos DB, incremental mediante la fuente de cambios (lección 03-03) o carga completa diaria, dado que el catálogo es pequeño. El CSV de combustible, carga completa mensual con desencadenador basado en eventos, que se dispara cuando el fichero aparece en el almacenamiento.
2. db-reservas y Cosmos DB: entorno de ejecución de Azure con acceso a la red virtual, porque ambos están tras punto de conexión privado y no son accesibles desde internet. El CSV: entorno de Azure gestionado si el proveedor lo deja en una cuenta de almacenamiento, o autohospedado si hubiera que recogerlo de un servidor local.
3. En Parquet, particionado por fecha: bronce/reservas/anio=2026/mes=08/dia=11/, bronce/tarifas/anio=2026/mes=08/dia=11/ y bronce/combustible/anio=2026/mes=08/. El CSV original se conserva tal cual junto a su versión Parquet, porque la capa bronce debe poder reproducir el origen.

Solución 2:

1. Grupo de SQL sin servidor. El grupo dedicado se descarta porque una consulta diaria y algunas interactivas no justifican pagar un almacén por horas, y habría que acordarse de pausarlo; Spark se descarta porque la transformación es una agregación SQL sencilla y levantar un clúster añade minutos de arranque y coste sin aportar nada.
2. En CSV sin particionar se leen los 400 GB completos, ya que el formato por filas obliga a recorrer todas las columnas y no hay particiones que descartar. En Parquet particionado y filtrando un año se lee aproximadamente un tercio de los datos y solo 4 columnas de 40: del orden de 1-2 GB. La diferencia es de dos órdenes de magnitud, y como el sin servidor factura por TB leídos, esa es también la diferencia en la factura.
3. Importación, con actualización nocturna tras la canalización. Con DirectQuery, cada interacción de cada usuario con el cuadro de mando lanzaría una consulta contra sin servidor y facturaría datos leídos; con importación se paga una lectura al día y las respuestas son instantáneas.

Solución 3:

1. Orden por ahorro: (a) el grupo dedicado ocioso, que por sí solo explica la mayor parte del sobrecoste; (b) los CSV sin particionar, que encarecen cada consulta sin servidor; (c) la copia completa nocturna, que paga transferencia, almacenamiento y carga sobre la base operativa; (d) los flujos de datos triviales, que levantan un clúster de Spark para renombrar columnas.
2. Correcciones: pausar el grupo dedicado de inmediato y, si en cuatro semanas no ha habido consultas, eliminarlo y trabajar con sin servidor; convertir la capa bronce a Parquet particionado por fecha y reescribir las rutas de las consultas; cambiar la canalización a carga incremental con parámetro de día y desencadenador de ventana de saltos de tiempo; sustituir los tres flujos por una actividad de copia con asignación de columnas o una vista de sin servidor.
3. Prevención: una alerta de presupuesto específica para el grupo de recursos de analítica (lección 01-03 y módulo 8), un runbook de Automation que pause el grupo dedicado fuera del horario laboral, y una revisión mensual de Azure Advisor. En el módulo 4 se añade Azure Policy para impedir directamente que se creen ciertos recursos sin etiquetas o fuera de las regiones permitidas.

Con esta lección se cierra el módulo 3 y el mapa de datos de Contoso Airlines está completo. Sabes por qué una base transaccional no sirve para analizar —almacenamiento por filas frente a columnas, normalización frente a esquema en estrella, latencia por operación frente a volumen procesado— y por qué lanzar el informe de rentabilidad contra db-reservas habría degradado la venta de billetes. Conoces las cinco piezas de una plataforma analítica y qué servicio ocupa cada una. Has creado Data Lake Storage Gen2 entendiendo qué añade sobre Blob Storage —espacio de nombres jerárquico con directorios reales y ACL POSIX— y lo has organizado en capas bronce, plata y oro con sus tres reglas: bronce no se toca, las transformaciones solo van hacia adelante y solo oro alimenta los cuadros de mando. Sabes por qué el formato Parquet particionado por fecha es la decisión que más dinero ahorra, y cuándo hace falta Delta.

Has montado la ingesta con Azure Data Factory, con sus servicios vinculados, conjuntos de datos, actividades, canalizaciones, desencadenadores y entornos de ejecución de integración, y con una canalización nocturna de carga incremental que copia las reservas del día anterior al lago con reintentos y ventanas reprocesables; y distingues cuándo basta una actividad de copia y cuándo se justifica pagar un flujo de datos de asignación. En Synapse has comparado los cuatro motores y consultado el lago con SQL sin servidor mediante OPENROWSET, sin cargar nada en ninguna parte, sabiendo que el grupo dedicado se paga por hora encendido y hay que pausarlo. Sitúas Microsoft Fabric como la convergencia hacia la que apunta Microsoft sin que lo aprendido pierda validez, has llevado la capa oro a Power BI eligiendo importación frente a DirectQuery por rendimiento y por coste, y conoces Microsoft Purview para catalogar, clasificar y trazar el linaje del dato.

Recapitulando el módulo entero: empezaste con el criterio para elegir un servicio de datos y saliste con un mapa razonado de cinco almacenes. Desplegaste db-reservas en Azure SQL Database con su esquema, sus índices, su punto de conexión privado y su restauración a un momento dado. Pusiste el catálogo de tarifas en Cosmos DB con la clave de partición /origenDestino, sus unidades de solicitud y su nivel de consistencia elegido dato a dato. Migraste el portal heredado a Azure Database for MySQL sin reescribir una línea de WordPress, y el sistema de tripulaciones a Azure Database for PostgreSQL con PostGIS, PgBouncer y el autovacuum bajo control. Y hoy has construido la plataforma analítica que responde, por fin, qué rutas son rentables por temporada.

Toda esa plataforma —cómputo, almacenamiento, red y ahora datos— se ha construido con configuraciones de seguridad mínimas: contraseñas de administrador escritas a mano, cadenas de conexión con secretos dentro, permisos amplios porque era lo rápido, un WAF que aún no existe y ninguna política que impida a nadie crear un recurso sin etiquetas en la región equivocada. Ha sido una decisión consciente para poder avanzar, y ahora toca cerrarla de verdad. En el módulo 4, Seguridad en Azure, empezarás por Microsoft Entra ID y la gestión de identidades, seguirás con RBAC e identidades administradas para que las aplicaciones se autentiquen sin una sola contraseña, centralizarás los secretos en Azure Key Vault, protegerás el perímetro con DDoS y un firewall de aplicaciones web, evaluarás la postura completa con Microsoft Defender for Cloud y acabarás imponiendo las reglas del juego con Azure Policy. Nos vemos allí.