La direcció de Contoso Airlines fa mesos que fa la mateixa pregunta i ningú no sap respondre-la amb dades: quines rutes són realment rendibles per temporada. No és una consulta capriciosa; d'ella depenen la programació de l'hivern, la renegociació de taxes amb dos aeroports i la decisió de mantenir o tancar la ruta de Palma a Munic. Respondre-la exigeix creuar tres anys de vendes de db-reservas, l'ocupació real dels vols, les tarifes aplicades que viuen a Cosmos DB, els costos per rotació del sistema de tripulacions i els retards operatius: uns 400 milions de files.

El primer impuls —llançar aquesta consulta contra db-reservas— és exactament el que no s'ha de fer. Aquesta lliçó construeix l'alternativa: una plataforma analítica que respon preguntes grans sobre dades històriques sense tocar ni una vegada les bases operatives. I amb ella es tanca el mòdul.

Avís de cost important: l'analítica és on les factures es descontrolen més ràpid. Un grup de SQL dedicat de Synapse costa més de 1.000 € al mes si es deixa encès, i cal pausar-lo a mà. Els grups de SQL sense servidor facturen per TB llegits, així que una consulta mal escrita sobre dades sense particionar pot costar més que un dia sencer de màquines virtuals. Per aprendre, fes servir SQL sense servidor amb fitxers petits, i elimina el grup de recursos en acabar.

1. Per què les bases operatives no serveixen per analitzar
2. L'arquitectura analítica i les seves cinc peces
3. Azure Data Lake Storage Gen2
4. Capes bronce, plata i oro
5. Formats de fitxer: CSV davant de Parquet i Delta
6. Azure Data Factory: la canalització nocturna
7. Activitat de còpia davant de fluxos de dades d'assignació
8. Azure Synapse Analytics
9. Microsoft Fabric, amb honestedat
10. Power BI i el quadre de comandament de rendibilitat
11. Govern de la dada amb Microsoft Purview
12. Els costos de l'analítica i com es disparen
13. Errors Comuns i Consells
14. Exercicis
15. Conclusió

Una base de dades transaccional (OLTP) i una d'analítica (OLAP) estan optimitzades per a coses oposades:

La conseqüència pràctica: una consulta analítica sobre la base operativa recorre milions de files, ocupa la memòria del motor, invalida les seves memòries cau i bloqueja recursos. Encara que acabi funcionant, degrada la venda de bitllets per a tots els clients mentre dura. Per això se separen els mons, i la separació té a més un avantatge de negoci: l'històric analític conserva dades que la base operativa esborra o arxiva.

Tota plataforma analítica moderna, es digui com es digui, té les mateixes cinc peces:

Ingesta (portar les dades), emmagatzematge (desar-les barat i en brut), transformació (netejar-les i agregar-les), servei (exposar-les per consultar) i consum (visualitzar-les). Azure hi posa un servei per a cada peça, i l'important és entendre el paper de cadascun abans que els seus menús.

Data Lake Storage Gen2 no és un servei a part: és un compte d'Azure Storage, el mateix de la lliçó 02-04, amb una opció activada en crear-lo: l'espai de noms jeràrquic. Això canvia dues coses fonamentals:

• Directoris reals. A Blob Storage, 2026/07/ventas.parquet és un nom pla que simula carpetes; canviar el nom d'«una carpeta» amb un milió de fitxers significa copiar i esborrar un a un. Amb espai de noms jeràrquic, el directori existeix de debò i canviar-li el nom és una operació atòmica de mil·lisegons. Per a un motor analític que escriu i reorganitza milers de fitxers, la diferència és enorme.
• ACL POSIX. A més del control d'accés per RBAC, es poden assignar permisos de lectura, escriptura i execució a nivell de directori i de fitxer per a usuaris i grups de Microsoft Entra ID. Contoso ho fa servir perquè l'equip financer de la Nuria Peña llegeixi la capa oro però no tingui accés a les dades personals de la capa bronce.

Tot el que has après a 02-04 continua vigent: nivells d'accés Hot, Cool i Archive amb polítiques de cicle de vida, redundància, xifratge i accés amb identitat d'Entra ID en lloc de claus.

L'organització en tres capes —també anomenada arquitectura de medalló— evita el destí habitual dels llacs de dades: convertir-se en un aiguamoll on ningú no sap quin fitxer és fiable.

Les tres regles que fan que funcioni: la capa bronce no es modifica mai (si una transformació falla, es refà des d'allà sense tornar a molestar l'origen); les transformacions només van cap endavant; i només la capa oro es connecta als quadres de comandament, cosa que evita que cada analista construeixi la seva pròpia versió de la veritat.

Fixa't en la ruta de bronce: les dades es desen particionades per data en directoris anio=/mes=/dia=. No és cosmètic. Quan una consulta filtra per agost de 2026, el motor llegeix només aquest directori en lloc de tres anys de fitxers. És l'optimització que més diners estalvia de tota aquesta lliçó.

El motiu que el format columnar importi tant és directament econòmic. La consulta de rendibilitat fa servir 4 columnes d'una taula de 40. En CSV cal llegir els 400 GB complets; en Parquet se'n llegeixen uns 12 GB, i com que el sense servidor de Synapse factura per TB llegits, la mateixa consulta costa unes 30 vegades menys. Regla pràctica: les dades entren com vinguin, però al llac es desen en Parquet (o Delta si cal actualitzar files), sempre particionades per data.

Data Factory és el servei d'integració i orquestració. Els seus cinc conceptes, que són els mateixos a Synapse Pipelines i a Fabric:

Aquest últim concepte és el que genera més confusió i el que Contoso necessita entendre bé: per llegir db-reservas, que només és accessible per punt de connexió privat, cal un entorn d'execució amb accés a la xarxa virtual; i per llegir el sistema de facturació heretat del soterrani de Barcelona caldria un entorn autoallotjat, un agent instal·lat en un servidor local que estableix la connexió de sortida.

La canalització nocturna de Contoso copia cada dia les reserves del dia anterior a la capa bronce:

Tres decisions de disseny estan escrites en aquest JSON. La consulta porta només el dia anterior en lloc de la taula sencera: això s'anomena càrrega incremental i és la diferència entre una còpia de dos minuts i una de dues hores que a més castiga la base operativa. La destinació és Parquet al llac. I la política de reintents evita que una fallada transitòria de xarxa obligui algú a rellançar la canalització a mà al matí.

El desencadenador és de finestra de salts de temps a les 03:00, no una programació simple, perquè garanteix finestres de temps no solapades i permet reprocessar un dia concret si es detecta un error: es rellança la finestra de l'11 d'agost i es corregeix només aquest directori.

El criteri és directe: fes servir l'activitat de còpia per moure i els fluxos de dades només quan la transformació ho justifiqui. Si el teu equip sap escriure SQL o Python, transformar amb un quadern de Spark o amb vistes de Synapse sense servidor sol ser més barat i més fàcil de versionar en Git que un flux visual.

Synapse és un espai de treball que reuneix diversos motors. L'important és saber quin fer servir:

El grup sense servidor és la porta d'entrada natural, perquè permet consultar el llac sense carregar res enlloc:

OPENROWSET llegeix els fitxers on són; el ** recorre els subdirectoris de partició. No cal crear taules ni carregar dades, i si demà arriben més fitxers a aquesta ruta, la mateixa consulta els inclou. Quan una consulta com aquesta es fa servir cada dia, es desa com a vista en una base de dades sense servidor i Power BI s'hi connecta.

El grup dedicat, en canvi, és un magatzem de dades complet amb el seu emmagatzematge columnar propi i distribució de taules. Aporta rendiment constant i alta concurrència, i costa el que costa: es paga per hora encès, es faci servir o no, així que es pausa quan no es necessita. Contoso, amb 400 milions de files i una desena d'analistes, comença per sense servidor i només valorarà un grup dedicat si la concurrència ho exigeix.

Microsoft Fabric és l'evolució on Microsoft està convergint tot això: Data Factory, Synapse, Power BI i el llac en una única plataforma SaaS, amb un emmagatzematge comú anomenat OneLake, format Delta per defecte i facturació per capacitat en lloc de per servei.

L'honest és dir tres coses. Primera: els conceptes d'aquesta lliçó —capes del llac, Parquet, canalitzacions, motors SQL i Spark— són els mateixos a Fabric, així que res del que has après no es perd. Segona: Fabric és cap on apunten els desenvolupaments nous, i per a un projecte que comença avui mereix una avaluació seriosa. Tercera: Synapse i Data Factory continuen plenament admesos i són el que hi ha desplegat a la majoria de les organitzacions, inclosa la Contoso d'aquest curs, que ja té la seva plataforma muntada i no la refarà per una novetat.

Power BI és la capa de consum: es connecta a la capa oro o a les vistes sense servidor i produeix el quadre de comandament que respon la pregunta de la direcció. El de Contoso té una pàgina per pregunta: ingressos i marge per ruta i temporada, ocupació mitjana davant del punt d'equilibri, evolució dels últims 36 mesos i detall per ruta.

Dues decisions tècniques que convé conèixer: el mode importació copia les dades al model de Power BI i dona respostes instantànies, amb el preu que les dades són de l'última actualització; el mode DirectQuery consulta l'origen a cada interacció, sempre actualitzat però més lent i amb cost per consulta —important aquí, perquè cada interacció amb sense servidor llegeix TB i factura—. Per a un quadre de comandament que es refresca cada nit, importació és la tria correcta i la més barata.

Quan hi ha un llac amb tres capes, desenes de fitxers i diversos equips consumint, apareixen preguntes noves: d'on surt aquest número? qui pot veure aquesta columna? on hi ha dades personals?

Microsoft Purview hi respon amb un catàleg que analitza automàticament els orígens i construeix un inventari, classifica dades sensibles (detecta que una columna conté correus o documents d'identitat) i mostra el llinatge: quin origen alimenta quin fitxer i quin informe. Per a Contoso importa especialment pel RGPD: saber exactament en quines capes del llac hi ha dades personals de passatgers és un requisit, no una comoditat. Aquí queda només introduït; la governança es reprèn amb Azure Policy a la lliçó 04-06.

Les quatre causes de les factures desagradables, amb el seu remei:

I una mesura d'higiene que evita el degoteig: aplicar una política de cicle de vida al llac, com la de la lliçó 02-04, perquè les dades de la capa bronce amb més d'un any passin a nivell Cool i les de més de tres a Archive. La capa oro, que és la que es consulta, es queda a Hot.

• Consultar la base operativa per fer informes. Degrada la venda de bitllets mentre dura. És l'error que dona origen a tota aquesta lliçó.
• Oblidar pausar el grup de SQL dedicat. És la factura sorpresa més habitual d'Azure i la més fàcil d'evitar.
• Desar el llac en CSV. Multiplica per desenes el cost de cada consulta sense servidor i perd els tipus de dades.
• No particionar per data. Sense particions, cada consulta llegeix tot l'històric encara que només demani un mes.
• Modificar la capa bronce. És la còpia fidel de l'origen i la xarxa de seguretat per refer qualsevol transformació. Si es toca, es perd.
• Connectar els quadres de comandament a la capa plata «perquè és més completa». Cada analista acaba amb la seva pròpia versió de la veritat i dos informes donen xifres diferents a la mateixa reunió.
• Copiar dades personals a la capa oro sense necessitat. El RGPD s'aplica igual al llac; pseudonimitza en passar a plata.
• Consell: comença sempre per SQL sense servidor. Només quan mesuris que la concurrència o el rendiment no donen l'abast, valora un grup dedicat.
• Consell: posa una alerta de pressupost específica per al grup de recursos d'analítica. És el que es desvia més ràpid.

Cal portar al llac tres orígens: db-reservas (creix 40.000 files al dia), el catàleg de tarifes de Cosmos DB (canvia dues vegades al dia) i un CSV mensual de costos de combustible que envia un proveïdor extern.

1. Per a cada origen, indica estratègia de càrrega (completa o incremental), freqüència i tipus de desencadenador.
2. Quin tipus d'entorn d'execució d'integració necessita cadascun i per què?
3. En quin format i amb quina estructura de directoris els desaries a bronce?

La consulta de rendibilitat recorre tres anys de reserves: 400 GB en CSV o 40 GB equivalents en Parquet particionat per any i mes, i fa servir 4 columnes de 40. S'executarà una vegada al dia per refrescar el quadre de comandament i, ocasionalment, de manera interactiva.

1. Quin motor de Synapse triaries i per què descartes els altres?
2. Estima l'ordre de magnitud de les dades llegides en CSV davant de Parquet particionat, si la consulta filtra un sol any.
3. Quin mode de connexió de Power BI faries servir i quin impacte té en el cost?

La Nuria Peña detecta que el grup de recursos d'analítica ha passat de 300 a 2.400 € al mes. Hi trobes: un grup de SQL dedicat actiu des de fa sis setmanes sense consultes en les últimes quatre, fitxers CSV sense particionar a tota la capa bronce, una canalització que copia dbo.Reservas sencera cada nit i tres fluxos de dades que només canvien el nom de columnes.

1. Ordena els quatre problemes per estalvi potencial.
2. Proposa una correcció concreta per a cadascun.
3. Quina mesura preventiva implantaries perquè no torni a passar?

Solució 1:

1. Estratègies: db-reservas, incremental per data (només les reserves del dia anterior), diària de matinada, amb desencadenador de finestra de salts de temps per poder reprocessar dies concrets. Cosmos DB, incremental mitjançant la font de canvis (lliçó 03-03) o càrrega completa diària, atès que el catàleg és petit. El CSV de combustible, càrrega completa mensual amb desencadenador basat en esdeveniments, que es dispara quan el fitxer apareix a l'emmagatzematge.
2. db-reservas i Cosmos DB: entorn d'execució d'Azure amb accés a la xarxa virtual, perquè tots dos estan darrere d'un punt de connexió privat i no són accessibles des d'internet. El CSV: entorn d'Azure gestionat si el proveïdor el deixa en un compte d'emmagatzematge, o autoallotjat si calgués recollir-lo d'un servidor local.
3. En Parquet, particionat per data: bronce/reservas/anio=2026/mes=08/dia=11/, bronce/tarifas/anio=2026/mes=08/dia=11/ i bronce/combustible/anio=2026/mes=08/. El CSV original es conserva tal qual al costat de la seva versió Parquet, perquè la capa bronce ha de poder reproduir l'origen.

Solució 2:

1. Grup de SQL sense servidor. El grup dedicat es descarta perquè una consulta diària i algunes d'interactives no justifiquen pagar un magatzem per hores, i caldria recordar-se de pausar-lo; Spark es descarta perquè la transformació és una agregació SQL senzilla i aixecar un clúster afegeix minuts d'arrencada i cost sense aportar res.
2. En CSV sense particionar es llegeixen els 400 GB complets, ja que el format per files obliga a recórrer totes les columnes i no hi ha particions per descartar. En Parquet particionat i filtrant un any es llegeix aproximadament un terç de les dades i només 4 columnes de 40: de l'ordre d'1-2 GB. La diferència és de dos ordres de magnitud, i com que el sense servidor factura per TB llegits, aquesta és també la diferència a la factura.
3. Importació, amb actualització nocturna després de la canalització. Amb DirectQuery, cada interacció de cada usuari amb el quadre de comandament llançaria una consulta contra sense servidor i facturaria dades llegides; amb importació es paga una lectura al dia i les respostes són instantànies.

Solució 3:

1. Ordre per estalvi: (a) el grup dedicat ociós, que tot sol explica la major part del sobrecost; (b) els CSV sense particionar, que encareixen cada consulta sense servidor; (c) la còpia completa nocturna, que paga transferència, emmagatzematge i càrrega sobre la base operativa; (d) els fluxos de dades trivials, que aixequen un clúster de Spark per canviar el nom de columnes.
2. Correccions: pausar el grup dedicat immediatament i, si en quatre setmanes no hi ha hagut consultes, eliminar-lo i treballar amb sense servidor; convertir la capa bronce a Parquet particionat per data i reescriure les rutes de les consultes; canviar la canalització a càrrega incremental amb paràmetre de dia i desencadenador de finestra de salts de temps; substituir els tres fluxos per una activitat de còpia amb assignació de columnes o una vista de sense servidor.
3. Prevenció: una alerta de pressupost específica per al grup de recursos d'analítica (lliçó 01-03 i mòdul 8), un runbook d'Automation que pausi el grup dedicat fora de l'horari laboral, i una revisió mensual d'Azure Advisor. Al mòdul 4 s'hi afegeix Azure Policy per impedir directament que es creïn certs recursos sense etiquetes o fora de les regions permeses.

Amb aquesta lliçó es tanca el mòdul 3 i el mapa de dades de Contoso Airlines està complet. Saps per què una base transaccional no serveix per analitzar —emmagatzematge per files davant de columnes, normalització davant d'esquema en estrella, latència per operació davant de volum processat— i per què llançar l'informe de rendibilitat contra db-reservas hauria degradat la venda de bitllets. Coneixes les cinc peces d'una plataforma analítica i quin servei ocupa cadascuna. Has creat Data Lake Storage Gen2 entenent què afegeix sobre Blob Storage —espai de noms jeràrquic amb directoris reals i ACL POSIX— i l'has organitzat en capes bronce, plata i oro amb les seves tres regles: bronce no es toca, les transformacions només van cap endavant i només oro alimenta els quadres de comandament. Saps per què el format Parquet particionat per data és la decisió que més diners estalvia, i quan cal Delta.

Has muntat la ingesta amb Azure Data Factory, amb els seus serveis vinculats, conjunts de dades, activitats, canalitzacions, desencadenadors i entorns d'execució d'integració, i amb una canalització nocturna de càrrega incremental que copia les reserves del dia anterior al llac amb reintents i finestres reprocessables; i distingeixes quan n'hi ha prou amb una activitat de còpia i quan es justifica pagar un flux de dades d'assignació. A Synapse has comparat els quatre motors i consultat el llac amb SQL sense servidor mitjançant OPENROWSET, sense carregar res enlloc, sabent que el grup dedicat es paga per hora encès i cal pausar-lo. Situes Microsoft Fabric com la convergència cap a la qual apunta Microsoft sense que el que has après perdi validesa, has portat la capa oro a Power BI triant importació davant de DirectQuery per rendiment i per cost, i coneixes Microsoft Purview per catalogar, classificar i traçar el llinatge de la dada.

Recapitulant el mòdul sencer: vas començar amb el criteri per triar un servei de dades i en vas sortir amb un mapa raonat de cinc magatzems. Vas desplegar db-reservas a Azure SQL Database amb el seu esquema, els seus índexs, el seu punt de connexió privat i la seva restauració a un moment donat. Vas posar el catàleg de tarifes a Cosmos DB amb la clau de partició /origenDestino, les seves unitats de sol·licitud i el seu nivell de consistència triat dada a dada. Vas migrar el portal heretat a Azure Database for MySQL sense reescriure ni una línia de WordPress, i el sistema de tripulacions a Azure Database for PostgreSQL amb PostGIS, PgBouncer i l'autovacuum sota control. I avui has construït la plataforma analítica que respon, per fi, quines rutes són rendibles per temporada.

Tota aquesta plataforma —còmput, emmagatzematge, xarxa i ara dades— s'ha construït amb configuracions de seguretat mínimes: contrasenyes d'administrador escrites a mà, cadenes de connexió amb secrets a dins, permisos amplis perquè era el ràpid, un WAF que encara no existeix i cap política que impedeixi a ningú crear un recurs sense etiquetes a la regió equivocada. Ha estat una decisió conscient per poder avançar, i ara toca tancar-la de debò. Al mòdul 4, Seguretat a Azure, començaràs per Microsoft Entra ID i la gestió d'identitats, continuaràs amb RBAC i identitats administrades perquè les aplicacions s'autentiquin sense ni una contrasenya, centralitzaràs els secrets a Azure Key Vault, protegiràs el perímetre amb DDoS i un tallafoc d'aplicacions web, avaluaràs la postura completa amb Microsoft Defender for Cloud i acabaràs imposant les regles del joc amb Azure Policy. Ens hi veiem.