La plataforma de dades d'AlpinaShop funciona. Les comandes entren soles, Dataflow les neteja, Spark calcula la cistella mitjana, Data Fusion porta el fitxer del transportista i Workflows ho coordina tot cada nit amb la seva comprovació de qualitat. Tècnicament és un èxit.

I tanmateix, tres coses continuen sense funcionar.

Ningú no sap què hi ha. A alpinashop_analitica hi ha setze taules, sis vistes, dues vistes materialitzades i una anomenada pedidos_evento que ningú no recorda per què existeix. Quan algú de màrqueting pregunta "on és la dada de conversió?", la resposta és "pregunta-ho a la Lucía". I si la Lucía se'n va de vacances, la resposta és "no ho sé".

Ningú no sap què significa. La columna ventas_eur apareix en quatre taules. Inclou IVA? Descompta devolucions? Compta les comandes cancel·lades? La Marta creu que sí, la Lucía creu que no, i l'informe que va a direcció fa servir una de les dues definicions sense dir quina. Ningú no ho ha escrit mai.

Ningú no sap qui pot veure què. A 04-01 es va protegir email_cliente amb una etiqueta de política. Però des de llavors han passat sis lliçons: Dataflow escriu a pedidos_streaming, la subscripció de Pub/Sub bolca a pedidos_evento, l'arxiu d'esdeveniments va a Cloud Storage i Data Fusion va portar el CSV del transportista amb el nom del destinatari. Hi ha correus de clients en algun d'aquests llocs sense protecció? Ningú no ho ha comprovat.

I hi ha una quarta cosa que falta, la que direcció porta demanant des del mòdul 3: el tauler de control. Les dades són impecables i ningú no les veu.

En aquesta lliçó tanquem el mòdul resolent les quatre. Veuràs què és el govern de les dades i per què una pime el necessita tant com una multinacional, organitzaràs i documentaràs la plataforma amb Dataplex, definiràs regles de qualitat que es comproven soles, descobriràs i desidentificaràs les dades personals amb Sensitive Data Protection, i construiràs per fi a Looker Studio el tauler de control d'AlpinaShop, evitant l'error de permisos que converteix un informe compartit en una fuga de dades.

1. Què és el govern de les dades i per què també en una pime
2. Dataplex: llacs, zones i actius
3. El catàleg universal i la cerca de dades
4. Etiquetes i plantilles: documentar alpinashop_analitica
5. Perfils de dades: què hi ha realment a les teves taules
6. Regles de qualitat i què fer quan fallen
7. Llinatge automàtic d'extrem a extrem
8. Sensitive Data Protection: descobrir on són les dades personals
9. Desidentificació: emmascarament i tokenització
10. Looker Studio: connectar i modelar
11. El tauler de control de direcció d'AlpinaShop
12. Cost i rendiment: extracció, consulta en directe i BI Engine
13. Permisos: l'error clàssic de les credencials del propietari
14. Looker i LookML: quan justifica el seu preu
15. Checklist d'una plataforma de dades sana

El govern de les dades és el conjunt de pràctiques que garanteixen que les dades d'una organització siguin trobables, comprensibles, fiables, segures i gestionades al llarg de la seva vida. Cinc potes:

L'objecció habitual és que això és cosa de bancs i multinacionals. És exactament al revés, i val la pena argumentar-ho:

El RGPD no distingeix per mida. Una empresa de 40 persones que tracta dades de clients europeus té les mateixes obligacions que una de 40.000: saber quines dades personals té, on són, amb quina base legal, quant de temps les conserva, i poder atendre un dret de supressió. Si no se sap on és el correu d'un client, no es pot esborrar quan ho demani.

El cost del desconeixement és proporcionalment més gran. En una empresa gran hi ha redundància: si algú se'n va, un altre ho sap. A AlpinaShop, si la Lucía se'n va, el coneixement de la plataforma se'n va amb ella. La documentació no és burocràcia, és continuïtat.

Els errors arriben abans a direcció. Amb tres persones i un tauler de control, una dada mal calculada no passa per cap filtre intermedi. Va directa a una decisió.

I el moment correcte és ara. Governar setze taules és una feina d'una tarda. Governar-ne dues-centes, després de tres anys de creixement desordenat, és un projecte de mesos. El deute de govern s'acumula amb interessos.

Dataplex és la capa de gestió unificada de dades de Google Cloud. La seva idea central: les dades d'una organització estan repartides entre BigQuery, Cloud Storage i altres sistemes, i cal una capa lògica per sobre que les organitzi, les descrigui i els apliqui polítiques comunes sense moure-les.

La seva jerarquia:

Les zones tenen dos tipus amb semàntica diferent:

• Raw: dades en el seu format original, sense validar. Qualsevol format.
• Curated: dades ja netes i estructurades, amb esquema. Només formats estructurats (Parquet, Avro, ORC) o taules de BigQuery. Dataplex valida que el que s'hi registra ho compleix.

Creació:

L'opció --discovery-enabled és la que aporta valor immediat: Dataplex rastreja automàticament els actius, infereix esquemes dels fitxers del bucket, detecta particions per l'estructura de carpetes, i crea taules externes de BigQuery perquè aquests fitxers siguin consultables amb SQL sense que ningú les declari.

Per a AlpinaShop això significa que els Parquet que la feina de Spark deixa a gs://alpinashop-datalake/resultados/cesta/ apareixen com a taula consultable sense feina addicional. És descobriment automàtic de dades, i és la raó pràctica de registrar els buckets encara que el govern formal no interessi.

L'Universal Catalog de Dataplex —hereu de Data Catalog— indexa automàticament les metadades de BigQuery, Cloud Storage, Pub/Sub, Spanner i Bigtable de tota l'organització. I sobre aquest índex hi ha un cercador.

La sintaxi de cerca:

Des de la línia de comandes:

Aquesta consulta respon en segons a una pregunta que sense catàleg requereix obrir taula per taula: on hi ha correus? És el primer pas de l'apartat 8.

La resposta a la pregunta de màrqueting —"on és la dada de conversió?"— passa de "pregunta-ho a la Lucía" a buscar conversion al catàleg i trobar agg_embudo_dia amb la seva descripció. Aquest canvi és tot el valor del catàleg.

El catàleg indexa el que existeix, però no sap què significa. Per a això hi ha les etiquetes (tags), que afegeixen metadades de negoci a taules i columnes, estructurades segons una plantilla.

Primer la plantilla, que defineix quins camps es documenten i amb quins valors permesos:

I ara s'etiqueta cada taula:

Aquest camp definicion_negocio és la solució al segon problema de l'inici de la lliçó. Una frase escrita una vegada elimina per sempre la discussió sobre si total_pedido porta IVA. I queda on es busca, no en un document que ningú no obre.

La disciplina d'etiquetatge que AlpinaShop adopta:

La columna apta per a informes és la més útil en el dia a dia: distingeix el que pot alimentar un tauler de control del que és lampisteria. Sense ella, algú acabarà construint un informe de direcció sobre pedidos_staging, que es buida cada nit.

Abans de definir regles de qualitat cal saber com són les dades. El perfilatge de Dataplex analitza una taula i produeix estadístiques per columna: valors nuls, diferents, mínims, màxims, mitjanes, percentils i els valors més freqüents.

Un perfil típic revela coses que ningú no sospitava:

Tres troballes accionables en una sola passada: el 12 % de compres sense client identificat (que pot ser normal o pot ser una fallada del registre), la inconsistència de majúscules a canal que trenca qualsevol GROUP BY, i un total_pedido negatiu, que probablement sigui un abonament mal modelat i que està distorsionant totes les mitjanes.

Aquest últim és l'exemple perfecte de per què el perfilatge va abans que les regles: la regla "total mai negatiu" no s'inventa, es descobreix.

Amb el perfil a la mà es defineixen les regles. Un escaneig de qualitat executa un conjunt de comprovacions i dóna un resultat d'aprovat o fallit amb el detall per regla.

Les sis dimensions de qualitat estàndard, amb la seva interpretació a AlpinaShop:

Què fer quan una regla falla. Aquesta és la part que més es descuida, i sense ella l'escaneig és decoratiu:

La integració amb l'orquestrador de 04-06 tanca el cercle:

Amb fail_on_dq_failure=True, una fallada de qualitat atura el procés nocturn abans de propagar dades dolentes al tauler de control. És la versió industrialitzada de la comprovació de qualitat que vam escriure a mà a 04-06.

A 04-05 vam veure el llinatge de Data Fusion, limitat als seus pipelines. Dataplex Lineage ho fa de manera transversal: captura automàticament el llinatge de BigQuery (cada consulta que escriu en una taula), Dataflow, Data Fusion, Composer i Dataproc.

I ja està: a partir d'aquí, cada feina registra el seu llinatge sola.

El graf complet d'AlpinaShop, que Dataplex construeix sense que ningú el dibuixi:

Les preguntes que aquest graf respon en un clic:

• "El marge de l'informe surt estrany. D'on ve?" → agg_ventas_categoria_dia ← lineas_pedido + costes_producto_erp ← Datastream ← MySQL de l'ERP. En quatre salts s'arriba a l'origen.
• "Canviarem l'esquema de l'ERP. Què es trenca?" → Tot el que penja de costes_producto_erp, inclòs el tauler de control de direcció.
• "Un client exerceix el seu dret de supressió. On és la seva dada?" → Es rastreja pedidos cap endavant i apareixen totes les taules derivades.
• "Podem apagar l'exportació nocturna de Cloud SQL?" → El graf mostra que pedidos_staging en depèn. No.

Aquesta última pregunta és la que més diners estalvia a la pràctica: saber què es pot apagar. Tota plataforma de dades amb dos anys acumula processos que ja no alimenten res, i sense llinatge ningú no s'atreveix a tocar-los.

Avís de RGPD. Aquest apartat i el següent tracten dades personals. Les eines que s'hi descriuen són controls tècnics, no un dictamen jurídic. Determinar la base legal d'un tractament, els terminis de conservació, la necessitat d'una avaluació d'impacte o si una pseudonimització és suficient correspon a un professional de compliance o al delegat de protecció de dades, i s'ha de fer abans de posar res en producció. Totes les dades d'aquest curs són fictícies.

Sensitive Data Protection —el servei abans conegut com a Cloud DLP— fa dues coses: inspeccionar per descobrir on hi ha dades sensibles, i desidentificar perquè deixin de ser-ho.

Comencem per la inspecció, que respon al tercer problema de l'inici de la lliçó: hi ha correus de clients en llocs on no n'hi hauria d'haver?

Una feina d'inspecció sobre tot el dataset:

Dues decisions deliberades en aquesta configuració:

• includeQuote: false: les troballes no inclouen el valor trobat. Si ho posessis a true, la taula de troballes contindria els correus reals, és a dir, hauries creat una còpia sense protegir de les dades que intentes protegir. És un error clàssic i greu.
• rowsLimitPercent: 10: per descobrir si hi ha dades sensibles no cal escanejar el 100 %. Un mostreig del 10 % troba el problema i costa la desena part.

I una consulta sobre les troballes:

Resultat típic a AlpinaShop, i per què fa mal:

Quatre de les cinc troballes són sorpreses. Cap no és fruit de mala fe: són conseqüències naturals de moure dades. La subscripció de BigQuery de 04-04 bolca el missatge sencer. El transportista escriu el que vol al camp d'incidència. Els clients posen el seu telèfon en una ressenya. I una IP, que sembla tècnica, és dada personal.

Això és exactament el que cap organització no sap sense inspeccionar. I és la raó per la qual aquest apartat existeix.

Per fer-ho continu, Dataplex ofereix perfilatge de dades sensibles a nivell d'organització, que escaneja automàticament tot BigQuery i manté un inventari actualitzat d'on hi ha dades sensibles i amb quin nivell de risc, sense llançar feines a mà.

Descobert el problema, cal actuar. Les tècniques, de menor a major utilitat conservada:

La distinció crítica és entre hash i tokenització determinista:

• El hash amb clau produeix el mateix resultat per al mateix valor, així que permet comptar i agrupar clients diferents, però no es pot tornar enrere. És el correcte per a analítica pura.
• La tokenització determinista amb preservació de format produeix un testimoni que sembla un correu i es pot revertir amb la clau. És el correcte quan un sistema autoritzat necessita recuperar el valor original.

Configuració de desidentificació per a AlpinaShop:

Què fa cada transformació:

• email_cliente → hash amb clau embolcallada a KMS. Reutilitza clave-pedidos del keyring alpinashop-keyring creat a 03-06. La clau no surt mai de KMS, així que ni tan sols qui tingui accés a la taula pot revertir el hash. La Lucía continua podent comptar clients únics amb COUNT(DISTINCT email_hash).
• codigo_postal → emmascarament dels 3 últims. 08013 es converteix en 08XXX. Es conserva la província, que és el que serveix per a l'anàlisi geogràfica, i es perd el carrer, que és el que identifica.
• texto_opinion → substitució per tipus dins del text lliure. "Truqueu-me al 611223344, soc l'Ana" es converteix en "Truqueu-me al [PHONE_NUMBER], soc l'[PERSON_NAME]". La ressenya continua sent analitzable —inclosa l'anàlisi de sentiment del mòdul 5— sense dades personals a dins.

L'última és la més valuosa i la que cap altra eina no fa bé: desidentificar dins de text lliure, on la dada personal no és en una columna sinó incrustada en una frase.

I la vista que exposa la Lucía i el tauler de control:

El principi operatiu: les dades personals existeixen a la taula base, protegida i amb accés restringit a gcp-seguridad@; tota la resta —analítica, taulers de control, exploració— consumeix vistes desidentificades. La minimització no és una neteja puntual, és una arquitectura.

Looker Studio (abans Data Studio) és l'eina gratuïta de visualització de Google. Es connecta a BigQuery i a desenes d'orígens, i permet construir informes interactius sense codi.

Hi ha tres maneres de connectar-lo a BigQuery, i triar bé determina el cost i el rendiment:

La regla d'or: no connectis mai Looker Studio directament a una taula de detall gran. Connecta'l a una taula agregada o a una vista materialitzada. Un tauler de control amb sis gràfics que consulta lineas_pedido executa sis consultes cada vegada que algú canvia un filtre, i amb deu usuaris refrescant, la factura de BigQuery es dispara —exactament l'escenari de l'exercici 3 de 04-01.

Per a AlpinaShop, l'origen del tauler de control serà una taula preparada pel procés nocturn:

Aquesta taula té uns pocs milers de files —dos anys × 3 canals × 14 països × 6 categories— davant dels milions de lineas_pedido. Consultar-la és pràcticament gratis.

Els camps calculats de Looker Studio es defineixen sobre l'origen i es comporten com a columnes:

Consell de modelatge: defineix els camps calculats a la vista de BigQuery, no a Looker Studio, sempre que puguis. Un camp definit en SQL està versionat a Git, és reutilitzable per altres informes i per Spark, i no es perd si algú duplica l'informe. Un camp definit a Looker Studio viu dins d'aquest informe i ningú més no el veu.

Dissenyem l'informe que direcció porta demanant des del mòdul 3.

Estructura en tres pàgines:

Els indicadors clau, amb la seva definició explícita —que és el que evita la discussió de "aquest número no és el que jo tenia":

El cost d'adquisició mereix una nota honesta: requereix una dada que AlpinaShop encara no té a la plataforma —la inversió mensual en publicitat—. Hi ha dues opcions: carregar-la com una taula manual mantinguda per màrqueting, o integrar-la des de l'API de la plataforma publicitària. La primera és la sensata per començar. I cal mostrar-la a l'informe indicant d'on surt, perquè un indicador l'origen del qual ningú no coneix acaba desacreditant la resta.

Bones pràctiques de disseny, que són les que separen un informe que s'utilitza d'un que s'obre una vegada:

• El més important a dalt a l'esquerra. És on va la vista.
• Quatre targetes d'indicador, no dotze. Un tauler de control amb vint xifres no es llegeix: s'ignora.
• Comparació sempre. Un número sense context no informa. 42.180 € no diu res; +12,4 % davant del mes anterior sí.
• Un tipus de gràfic per pregunta: línia per a evolució, barres per comparar categories, taula per al detall. Res de gràfics de pastís amb dotze porcions.
• Filtres a dalt i comuns a la pàgina, no repartits pels gràfics.
• Colors amb significat i accessibles: verd i vermell tenen sentit per a bo i dolent, però cal assegurar-se que es distingeixen també per a daltònics, afegint fletxes o signes a més del color.
• Data de darrera actualització visible. Un informe sense ella genera desconfiança i trucades.
• Una nota metodològica al peu. On es defineix cada indicador. És la diferència entre un informe i una discussió.

Els tres mecanismes, en ordre de cost creixent:

1. Extracció de dades. Looker Studio copia fins a un límit de dades a la seva pròpia memòria cau i les serveix des d'allà. Refresc programable de fins a una vegada al dia. Cost de BigQuery pràcticament nul, rendiment excel·lent. És l'opció per defecte per a un informe amb dades agregades que no necessita ser d'avui mateix.

2. Consulta en directe amb memòria cau. Looker Studio guarda a la memòria cau els resultats durant un temps configurable (fins a 12 hores). Amb la memòria cau activada, deu persones mirant el mateix informe generen una consulta, no deu. És el que s'ha d'utilitzar en un tauler de control compartit.

3. BI Engine. Un servei d'acceleració en memòria de BigQuery. Es reserva una capacitat i les consultes que hi caben es responen en mil·lisegons i sense cost de bytes escanejats.

Amb la taula bi_resumen_diario, que ocupa uns pocs megabytes, 2 GB de BI Engine hi caben de sobres: el tauler de control sencer se serveix des de memòria, amb latència de mil·lisegons i sense facturar escaneig. El cost de la reserva és de l'ordre d'uns pocs euros al mes, i sol sortir més barat que pagar les consultes que evita.

Comprovar que BI Engine s'està utilitzant:

Si modo és FULL, la consulta es va resoldre íntegrament en memòria. Si és DISABLED o PARTIAL, el camp bi_engine_statistics.acceleration_mode explica per què —normalment perquè la consulta utilitza una funció no admesa o la taula no hi cap.

La recepta completa d'AlpinaShop, resumida: taula agregada petita + memòria cau activada + BI Engine + informe connectat a la vista desidentificada. Cost mensual del tauler de control: uns pocs euros. Sense aquesta disciplina, els mateixos gràfics costarien centenars.

Aquí hi ha l'error més perillós de tota la lliçó, i passa constantment perquè la interfície ho posa fàcil.

Quan es crea un origen de dades a Looker Studio cal triar amb quines credencials s'executen les consultes:

L'escenari del desastre, pas a pas:

1. La Lucía crea el tauler de control connectat a BigQuery amb credencials del propietari. És el còmode, i és el que la interfície suggereix.
2. La Lucía té, a més d'accés als agregats, permís de lectura sobre pedidos complet.
3. La Lucía comparteix l'informe amb "qualsevol persona amb l'enllaç" perquè un proveïdor extern vegi un gràfic.
4. Aquest proveïdor —o qualsevol a qui reenviïn l'enllaç— pot explorar les dades amb els permisos de la Lucía. Pot afegir camps, canviar dimensions i, si l'origen és una taula amb dades personals, veure-les.
5. Ningú a BigQuery no ha donat cap permís a aquesta persona. Els permisos de BigQuery no la protegeixen, perquè les consultes no es fan en nom seu.

Això és una bretxa de dades personals amb obligació de notificació sota el RGPD.

Les regles que AlpinaShop adopta, sense excepció:

1. L'origen apunta sempre a una vista desidentificada i autoritzada, mai a una taula amb dades personals. Encara que el mode de credencials sigui l'equivocat, no hi ha res sensible al darrere. Aquesta és la defensa que no depèn que ningú se'n recordi.
2. Credencials de l'espectador en qualsevol informe que surti de l'equip de dades.
3. Mai "qualsevol persona amb l'enllaç" per a informes amb dades de negoci. Compartir sempre amb persones o grups concrets (gcp-datos@, direccion@).
4. Revisió trimestral de amb qui estan compartits els informes. Els permisos s'acumulen sols.
5. Si calen credencials del propietari —perquè els espectadors no tenen ni han de tenir permisos de BigQuery—, aleshores l'origen ha de ser una vista agregada sense cap dada personal ni confidencial. Sense negociació.

Verificació des de BigQuery de qui està consultant des de Looker Studio:

Si en aquesta llista apareix una sola adreça de correu —la de la Lucía— quan l'informe el miren quinze persones, ets en mode credencials del propietari. És la comprovació de trenta segons que convé fer avui.

Looker (sense "Studio") és un producte diferent i molt més car. La seva diferència essencial és LookML, un llenguatge de modelatge on es defineix una sola vegada què significa cada mètrica i cada dimensió, i tots els informes de l'empresa consumeixen aquestes definicions.

Quan justifica el seu preu: quan el cost de la incoherència supera el cost de la llicència. És a dir, quan hi ha desenes d'analistes creant informes, quan "vendes" significa coses diferents en tres departaments i les reunions es dediquen a discutir de qui és el número bo, o quan es necessita govern del model semàntic amb revisió per pull request.

Per a AlpinaShop, Looker Studio és la resposta òbvia: tres persones, un tauler de control, pressupost de pime. La coherència es garanteix amb la disciplina de l'apartat 10 —definir les mètriques en vistes de BigQuery versionades a Git— que és el 80 % del valor de LookML pel 0 % del preu.

Organització i descobriment

• [ ] Tots els datasets i buckets registrats en un llac de Dataplex amb les seves zones.
• [ ] Descobriment automàtic activat als actius de Cloud Storage.
• [ ] Tota taula amb description i amb etiquetes de govern.
• [ ] Distinció explícita entre taules aptes per a informes i taules de lampisteria.
• [ ] Cada taula amb un propietari nomenat.

Qualitat

• [ ] Perfilatge executat sobre les taules principals.
• [ ] Regles de qualitat definides per a completesa, unicitat, validesa, exactitud i frescor.
• [ ] Escaneigs programats diàriament.
• [ ] L'orquestrador bloqueja el procés si falla una regla crítica.
• [ ] Resultats històrics exportats a BigQuery per veure la tendència.

Llinatge

• [ ] API de llinatge activada.
• [ ] Graf revisat després de cada canvi d'arquitectura.
• [ ] Processos sense consumidors identificats i apagats.

Seguretat i privacitat

• [ ] Inspecció de dades sensibles executada sobre tot el dataset, no només on se sospita.
• [ ] Columnes amb dades personals etiquetades amb política d'accés.
• [ ] Vistes desidentificades com a única superfície d'exposició analítica.
• [ ] Cap eina de BI connectada a una taula amb dades personals.
• [ ] Claus de hash i tokenització a KMS, mai al codi.
• [ ] Revisió per un professional de compliance o el DPD abans de producció.

Cost

• [ ] Taules particionades i clusteritzades; require_partition_filter a les grans.
• [ ] Taulers de control connectats a agregats, mai a taules de detall.
• [ ] Memòria cau d'informes activada; BI Engine si compensa.
• [ ] Pressupostos i alertes per etiqueta de centre de cost.
• [ ] Res permanentment encès que no ho necessiti: sense clústers de Dataproc oblidats, sense instàncies de Data Fusion enceses, sense pipelines de streaming orfes.
• [ ] Auditoria periòdica de consultes cares amb INFORMATION_SCHEMA.

Operació

• [ ] Tots els processos orquestrats, cap en un cron d'una VM.
• [ ] Tasques idempotents; reprocessos segurs.
• [ ] Alertes que arriben a una persona concreta, no a un correu genèric.
• [ ] Codi —DDL, DAG, pipelines, fluxos— versionat a Git.
• [ ] Documentació de què fa cada procés i a qui avisar.

Documentar només al principi. Un catàleg amb etiquetes de fa un any és pitjor que cap, perquè genera confiança injustificada. Documentar ha de ser part de crear la taula, no un projecte a part.

Posar regles de qualitat sense perfilar abans. S'acaben definint llindars inventats que fallen a diari, tothom ignora les alertes, i el sistema deixa de servir. Perfila, mira les dades reals, i després defineix.

Regles de qualitat que no bloquegen res. Si una fallada de qualitat no atura el procés ni avisa ningú, és decoració.

Inspeccionar amb includeQuote: true. Es crea una taula de troballes que conté les dades sensibles que es volien protegir. És empitjorar el problema.

Confondre hash amb anonimització. Un hash sense sal ni clau d'un correu és reversible per força bruta —l'espai de correus plausibles no és tan gran—. Continua sent dada personal a efectes del RGPD. La clau ha d'estar a KMS.

Connectar Looker Studio a una taula de detall. Cada filtre dispara consultes sobre milions de files. És el camí directe a una factura sorpresa.

Credencials del propietari més enllaç públic. L'error més greu de la lliçó. Qualsevol amb l'enllaç consulta amb els permisos del propietari.

No posar la data d'actualització a l'informe. Genera desconfiança, trucades i decisions basades en dades de la setmana passada creient que són d'avui.

Definir les mètriques a Looker Studio en comptes de a BigQuery. Queden tancades en aquest informe, no es versionen, i en duplicar-lo divergeixen.

Consell: escriu la definició de negoci de cada mètrica i publica-la. La meitat de les discussions sobre dades són discussions sobre definicions, no sobre números.

Consell: posa un enllaç al catàleg al peu del tauler de control. Qui vulgui saber què significa un número, que hi pugui arribar sol.

Consell: fes la inspecció de dades sensibles avui, no quan hi hagi un incident. Costa una tarda i gairebé sempre troba alguna cosa que ningú no sabia.

Per a la taula alpinashop_analitica.opiniones: (a) escriu la comanda que la registra com a actiu a la zona curada del llac; (b) crea l'etiqueta de govern indicant propietari, domini, sensibilitat, frescor, retenció, aptitud per a informes i una definició de negoci precisa; (c) defineix un escaneig de qualitat amb almenys cinc regles que cobreixin completesa, unicitat, validesa de rang, conjunt de valors i una regla SQL pròpia; (d) explica quina acció prendries davant de la fallada de cada regla.

El camp texto d'opiniones és text lliure escrit per clients. Dissenya: (a) la feina d'inspecció que descobreixi quins tipus de dades personals conté, amb les opcions correctes per no crear una còpia de les dades sensibles; (b) la plantilla de desidentificació que permeti conservar el text analitzable —per a l'anàlisi de sentiment del mòdul 5— eliminant les dades personals; (c) la vista que s'exposaria a Looker Studio; (d) l'advertiment de RGPD que acompanyaria la proposta abans de portar-la a producció.

El tauler de control de direcció porta dos mesos funcionant i hi ha quatre problemes. Un: triga 40 segons a carregar i el cost de BigQuery del projecte ha passat de 12 € a 310 € al mes. Dos: INFORMATION_SCHEMA mostra que totes les consultes de l'informe les fa [email protected], encara que el miren dotze persones. Tres: l'informe està compartit com a "qualsevol persona amb l'enllaç" perquè es va haver d'ensenyar a un consultor extern. Quatre: direcció diu que el número de vendes de l'informe no coincideix amb el de comptabilitat.

Diagnostica cada problema, indica la seva gravetat relativa i proposa la solució concreta amb l'ordre d'actuació.

Solució 1

(a) Registrar l'actiu. La taula ja és dins del dataset alpinashop_analitica, que es va registrar complet com a actiu activo-analitica a zona-curada. Per tant no cal registrar la taula individualment: Dataplex la descobreix en rastrejar el dataset. Si es volgués un actiu separat —per exemple, per a un dataset diferent— seria:

(b) Etiqueta de govern.

sensibilidad: datos-personales i apto_para_informes: false són les dues decisions clau: encara que el camp texto sembli innocu, és text lliure i per tant imprevisible.

(c) Escaneig de qualitat.

(d) Acció davant de cada fallada:

Solució 2

(a) Inspecció.

Les tres decisions que s'avaluen:

• includeQuote: false: sense això, la taula hallazgos_dlp_opiniones contindria els telèfons i noms reals trobats. S'hauria creat una segona còpia sense protegir d'exactament el que es vol protegir.
• minLikelihood: POSSIBLE en comptes de LIKELY: en text lliure escrit per persones, les dades apareixen en formats irregulars ("truqueu-me al sis onze..."). Un llindar baix genera més falsos positius, cosa que és preferible a no detectar una dada real. En una columna estructurada s'utilitzaria LIKELY.
• identifyingFields: permet saber quina ressenya conté la troballa sense guardar el valor, cosa que fa el resultat accionable.

(b) Plantilla de desidentificació.

Per què replaceWithInfoTypeConfig i no supressió. Substitueix cada troballa pel seu tipus entre claudàtors:

• Original: "Molt comoda. Si teniu dubtes escriviu-me a [email protected] o al 611223344, soc Ana Ruiz"
• Resultat: "Molt comoda. Si teniu dubtes escriviu-me a [EMAIL_ADDRESS] o al [PHONE_NUMBER], soc [PERSON_NAME]"

El text continua sent analitzable. La ressenya conserva la seva estructura, la seva longitud aproximada i —el que importa per al mòdul 5— el seu sentiment: "Molt còmoda" continua sent-hi. Amb supressió pura es perdria la coherència sintàctica i l'anàlisi de sentiment es degradaria.

(c) Vista exposada.

El pipeline nocturn escriu a opiniones_desidentificadas aplicant la plantilla, i la taula original opiniones queda amb accés restringit a gcp-seguridad@. Looker Studio, la Lucía i els futurs models del mòdul 5 consumeixen exclusivament la vista.

(d) Advertiment de RGPD.

Les ressenyes de clients contenen dades personals, tant en camps estructurats (pais combinat amb sku i fecha pot ser reidentificable si el volum és baix) com incrustades en text lliure. Aquesta proposta aplica dues mesures tècniques: desidentificació automàtica del text mitjançant Sensitive Data Protection i restricció d'accés a la taula original.

Abans de passar a producció és necessari que un professional de compliance o el delegat de protecció de dades determini: la base legal del tractament analític de les ressenyes; si la desidentificació aplicada constitueix anonimització efectiva o mera pseudonimització —cosa que determina si el RGPD continua aplicant-se al resultat—; el termini de conservació adequat; el risc de reidentificació per combinació de camps aparentment no identificatius; i si l'ús previst al mòdul 5 (anàlisi de sentiment) requereix informació addicional a l'interessat. La desidentificació automàtica no és infal·lible: un client que escrigui "soc el que va comprar la motxilla blava el dimarts a la botiga de Sabadell" no serà detectat per cap tipus de dada predefinit. Totes les dades d'aquest curs són fictícies.

Solució 3

Gravetat relativa, de major a menor:

Problema 3 (enllaç públic) + Problema 2 (credencials del propietari) = INCIDENT DE SEGURETAT. No són dos problemes: són un de sol i greu. Que totes les consultes les faci la Lucía significa mode credencials del propietari. Combinat amb "qualsevol persona amb l'enllaç", qualsevol que tingui o rebi aquest enllaç consulta BigQuery amb els permisos de la Lucía, que inclouen la taula pedidos amb email_cliente. Si el consultor extern va reenviar l'enllaç, o si va acabar en un correu o un xat, hi ha una possible bretxa de dades personals amb obligació de notificació. S'actua primer, avui, en minuts.

Problema 4 (el número no quadra amb comptabilitat) = CRISI DE CONFIANÇA. És el segon en gravetat perquè destrueix el valor de tot el construït. Un tauler de control en què direcció no confia deixa d'utilitzar-se, i la feina de set lliçons es perd.

Problema 1 (lent i car) = OPERATIU. 310 € al mes fan mal, però no comprometen ni la seguretat ni la confiança. S'arregla en una tarda.

Actuació en tres fases:

Fase 1 — Avui, en minuts: tallar l'exposició.

I en paral·lel: avisar el responsable de seguretat i el DPD. La valoració de si això constitueix una bretxa notificable sota el RGPD no la pren l'equip tècnic. Cal documentar quines dades eren accessibles, durant quant de temps i a qui es va compartir l'enllaç.

Fase 2 — Aquesta setmana: recuperar la confiança en el número.

La discrepància amb comptabilitat té tres causes candidates, i cal determinar quina és abans de tocar res:

Gairebé amb tota seguretat, comptabilitat utilitza la definició C —vendes netes sense IVA— i l'informe mostra la A. No és un error de dades: és un error de definició no documentada, exactament el segon problema de l'inici d'aquesta lliçó.

La correcció:

1. Acordar amb comptabilitat una definició canònica i escriure-la.
2. Implementar-la a la taula bi_resumen_diario, exposant totes dues magnituds amb noms inequívocs: ventas_brutas_iva_incl i ventas_netas_sin_iva.
3. Escriure-la a l'etiqueta definicion_negocio del catàleg de Dataplex.
4. Afegir una nota metodològica visible al peu del tauler de control.

Fase 3 — Aquest mes: cost i rendiment.

El diagnòstic primer:

El resultat esperat: l'informe està connectat directament a lineas_pedido o a pedidos, i cadascun dels vuit gràfics executa la seva pròpia consulta cada vegada que algú mou un filtre. Dotze persones × diversos filtres al dia × vuit gràfics = milers de consultes sobre milions de files.

Les quatre correccions, per ordre d'impacte:

1. Reapuntar l'informe a bi_resumen_diario, la taula agregada d'uns pocs milers de files que produeix el procés nocturn. Sola, aquesta mesura sol dividir el cost per cent i baixar la càrrega de 40 segons a menys de 3.
2. Activar la memòria cau de l'informe amb 12 hores de vigència. Dotze persones mirant generen una consulta, no dotze.
3. Reservar 2 GB de BI Engine. La taula agregada hi cap sencera en memòria: resposta en mil·lisegons i zero bytes facturats.
4. Posar una quota diària de bytes al projecte i una alerta de pressupost sobre l'etiqueta centro-coste:analitica, perquè un problema equivalent es detecti als 20 € i no als 310 €.

Resultat esperat: de 310 €/mes a menys de 10 €, i de 40 segons a menys de 3.

La lliçó transversal de l'exercici: els quatre problemes eren evitables amb el que ja sabíem. El cost, amb el de 04-01. Els permisos, amb el de 03-04 i l'apartat 13. La discrepància de definicions, amb l'etiquetatge de l'apartat 4. Cap no era una fallada tècnica difícil: els quatre eren fallades de govern.

El mòdul 4 es tanca aquí, i es tanca amb la plataforma completa.

Has entès què és el govern de les dades —catàleg, llinatge, qualitat, classificació i cicle de vida— i per què una pime el necessita igual o més que una multinacional: el RGPD no distingeix per mida, el coneixement no té redundància quan l'equip són tres persones, els errors arriben a direcció sense filtres intermedis, i el deute de govern s'acumula amb interessos.

Has organitzat la plataforma a Dataplex: el llac alpinashop-lago-comercial amb la seva zona crua i la seva zona curada, amb els buckets i el dataset registrats com a actius i amb descobriment automàtic que converteix els Parquet de Spark en taules consultables sense declarar res. Has utilitzat el catàleg universal per respondre en segons a "on és la dada de conversió?" i a "on hi ha columnes que es diguin email". I has documentat amb una plantilla d'etiquetes que obliga a declarar propietari, domini, sensibilitat, frescor, retenció, aptitud per a informes i —el més valuós— la definició de negoci, aquella frase escrita una vegada que resol per sempre si total_pedido inclou IVA.

Has perfilat les taules abans de jutjar-les, descobrint el que ningú no sospitava: un 12 % de comandes sense client, cinc valors a canal on n'hi havia d'haver tres, i un total_pedido negatiu que distorsionava totes les mitjanes. I sobre aquest coneixement has definit regles de qualitat en les sis dimensions, amb llindars, amb exportació de resultats i —això és el que les fa útils— amb una acció assignada a cada fallada i amb integració a l'orquestrador perquè una fallada crítica aturi el procés abans de propagar dades dolentes.

Has activat el llinatge automàtic i tens el graf complet des de Cloud SQL i l'ERP de Sabadell fins al tauler de control, capaç de respondre d'on ve un número, què es trenca si canvies un esquema, on és la dada d'un client que exerceix el seu dret de supressió, i quin procés es pot apagar sense por.

Has inspeccionat amb Sensitive Data Protection i has trobat el que sempre es troba: correus al bolcat cru de Pub/Sub, noms al camp d'incidències del transportista, telèfons dins de ressenyes de clients, i IP a les dades de navegació. Quatre sorpreses de cinc troballes, cap per mala fe. I has desidentificat amb criteri: hash amb clau de KMS per poder comptar clients sense saber qui són, emmascarament del codi postal conservant la província, i substitució per tipus dins del text lliure perquè les ressenyes continuïn sent analitzables sense dades personals a dins. Amb l'advertiment exprés, repetit on tocava, que això són controls tècnics i que la decisió jurídica correspon a un professional de compliance o al DPD.

I has construït per fi el tauler de control que direcció demanava: connectat a una taula agregada petita i no a la taula de detall, amb memòria cau, amb BI Engine, amb camps calculats definits en SQL versionat i no tancats a l'informe, amb quatre indicadors i no dotze, amb comparació sempre, amb data d'actualització visible i amb nota metodològica al peu. I amb la lliçó de permisos que val per si sola tota la lliçó: credencials de l'espectador, compartició amb persones concretes, i l'origen apuntant sempre a una vista desidentificada, perquè és l'única defensa que no depèn que ningú se'n recordi. Saps quan Looker amb LookML justifica el seu preu —quan el cost de la incoherència supera el de la llicència— i per què AlpinaShop no és en aquest cas.

Mira el que existeix ara i que no existia fa set lliçons. Les comandes entren per Pub/Sub sense acoblar la botiga a res. Dataflow les transforma per lots i en streaming, amb el temps de l'esdeveniment ben entès. Dataproc calcula allò algorítmic en clústers que viuen quatre minuts. Data Fusion porta el que arriba brut de fora. BigQuery ho guarda i ho respon en segons, particionat, clusteritzat i sense arruïnar ningú. Workflows ho orquestra cada nit amb comprovacions que bloquegen si alguna cosa no quadra. Dataplex ho cataloga, ho mesura i ho rastreja. I Looker Studio ho ensenya. AlpinaShop ha passat de no saber quina motxilla es ven més a Catalunya a tenir una plataforma de dades governada per la qual la Lucía no demana res a ningú.

Però fixa't en el que tot això té en comú: descriu el que ja va passar. Explica les vendes d'ahir, l'embut del mes, el marge del trimestre, quins productes es van comprar junts. És memòria, i la memòria és valuosíssima. No és predicció, i no és automatització.

I AlpinaShop té ara mateix quatre preguntes que la memòria no pot respondre. Quan un client posa uns grampons al carretó, què li hauria de suggerir el web en aquell instant, aprofitant la matriu de coocurrència que va calcular Spark? Quan entren 60 GB d'imatges noves al catàleg, les ha d'etiquetar algú a mà o pot la màquina dir "això és una motxilla blava de 40 litres"? Amb 8.000 ressenyes en text lliure ja desidentificades, algú se les llegirà totes per saber què falla als frontals? I amb 2.400 fitxes de producte per descriure, qui les escriu?

Al mòdul 5, Aprenentatge automàtic i IA, AlpinaShop passa de descriure a predir i automatitzar. Començarem per 05-01, Vertex AI, la plataforma que unifica tot el cicle de vida del model —dades, entrenament, avaluació, desplegament i monitoratge— i que connectarà directament amb el dataset alpinashop_analitica que acabes de governar. Després arribaran AutoML per entrenar sense escriure codi, TensorFlow per quan calgui control total, les API de llenguatge natural i de visió que responen a les preguntes de les ressenyes i de les imatges sense entrenar res, la IA generativa amb Gemini per a les descripcions, i MLOps amb Vertex AI Pipelines perquè un model no sigui un experiment al portàtil d'algú sinó un sistema de producció amb la mateixa disciplina d'idempotència, qualitat, llinatge i cost que has aplicat en tot aquest mòdul.

Les dades ja són netes, governades, documentades i consultables. Això no era l'objectiu: era el requisit. Ara comença el que és interessant.