El mercat mundial de cloud data warehouse passarà de 13.350 milions de dòlars el 2025 a més de 91.330 milions el 2034 —un creixement anual del 23,82%, segons Fortune Business Insights—, però fins al 70% dels projectes de modernització fracassa o dispara el pressupost i els terminis, d'acord amb CloudDataInsights. La diferència entre els projectes que generen retorn i els que es converteixen en un pou de costos rarament es troba en la tecnologia triada: es troba en l'arquitectura. Aquesta guia explica què és un data warehouse, com es diferencia d'un data lake i d'un lakehouse, què ofereixen les plataformes modernes i com abordar el projecte a la teva empresa sense convertir-te en una estadística més dels que fracassen.
Què és un data warehouse i per què la vostra empresa el necessita
Un data warehouse (magatzem de dades) és un repositori centralitzat dissenyat específicament per consolidar, organitzar i analitzar grans volums de dades procedents de múltiples sistemes operatius —ERP, CRM, plataformes d'e-commerce, eines de màrqueting— amb un únic objectiu: alimentar l'analítica i la presa de decisions. A diferència d'una base de dades transaccional, que està optimitzada per registrar operacions individuals a gran velocitat, el data warehouse està optimitzat per respondre preguntes complexes sobre historials complets: "com ha evolucionat el marge per línia de producte els últims tres anys per regió?".
La característica tècnica que defineix un data warehouse clàssic és l'enfocament schema-on-write (esquema en escriure). Segons IBM, això significa que les dades s'estructuren, es netegen i es modelen abans de carregar-se al magatzem, la qual cosa el fa especialment eficient per a dades estructurades i casos d'ús de business intelligence. El preu d'aquesta eficiència és la rigidesa: cal decidir l'estructura per endavant.
Per què la vostra empresa el necessita
Sense un data warehouse, l'analítica d'una organització sol dependre d'exportacions manuals a fulls de càlcul, informes que ningú no sap si estan actualitzats i un departament de TI saturat de peticions puntuals. Les conseqüències pràctiques són tres:
- Una única versió de la veritat. Quan vendes, finances i operacions consulten la mateixa font governada, desapareixen les reunions en les quals cada àrea defensa la seva pròpia xifra.
- Historial consultable. El data warehouse conserva la dada al llarg del temps, la qual cosa permet detectar tendències, estacionalitats i anomalies que un sistema transaccional, centrat en el "ara", no mostra.
- Rendiment analític. Les consultes que creuen milions de registres s'executen en segons gràcies a l'emmagatzematge columnar i al processament paral·lel, sense penalitzar els sistemes operatius.
El data warehouse és, en la pràctica, la base sobre la qual es construeix tota la capa d'analítica avançada. Si esteu pensant en com ordenar aquesta base, els nostres serveis d'analítica de dades i business intelligence estan dissenyats precisament per portar una empresa des de les dades disperses fins a una plataforma analítica governada.
Data warehouse vs data lake vs lakehouse: quin triar
La confusió entre aquests tres conceptes és una de les causes més freqüents de projectes mal dimensionats. No són el mateix i, en moltes organitzacions, no són excloents.
Un data lake és un repositori que emmagatzema dades en el seu format original —estructurades, semiestructurades i no estructurades: imatges, vídeo, àudio, documents, logs—. Segons IBM, la seva característica clau és l'enfocament schema-on-read (esquema en llegir): les dades s'aboquen tal com estan i l'estructura s'aplica en el moment de consultar-les. Això el fa barat i flexible per emmagatzemar-ho tot, però menys eficient i governat per a l'analítica de negoci directa.
Un data lakehouse és l'arquitectura que fusiona ambdós mons. Com explica IBM, emmagatzema qualsevol format de dada a baix cost —com un lake— però suporta consultes ràpides i analítica optimitzada —com un warehouse—. És la resposta del mercat a la pregunta "per què he de triar?".
| Característica | Data warehouse | Data lake | Lakehouse |
|---|---|---|---|
| Tipus de dada | Estructurada | Estructurada, semi i no estructurada | Tots els formats |
| Esquema | Schema-on-write | Schema-on-read | Híbrid |
| Cost d'emmagatzematge | Mitjà-alt | Baix | Baix |
| Optimitzat per | BI i reporting | Emmagatzematge massiu, data science | BI + IA/ML |
| Govern de la dada | Alt | Baix per defecte | Alt |
| Cas d'ús típic | Quadres de comandament financers | Repositori de dades crues | Plataforma analítica unificada |
Està el lakehouse desplaçant el data warehouse tradicional?
La tendència del mercat és clara. Segons l'informe State of the Data Lakehouse in the AI Era de Dremio (gener de 2025, basat en una enquesta de Propeller Insights a 563 responsables de TI), el 67% de les organitzacions planeja executar la major part de la seva analítica sobre data lakehouses en els pròxims tres anys, enfront del 55% actual. I la dada més reveladora per a qualsevol empresa que miri cap a la intel·ligència artificial: el 85% ja utilitza lakehouses per al desenvolupament de models d'IA.
La lectura correcta no és "el data warehouse ha mort", sinó que la frontera entre els tres conceptes s'està difuminant. Per a una pime o una empresa mitjana que només necessita consolidar el seu reporting financer i comercial, un data warehouse al núvol ben dissenyat continua sent l'opció més senzilla i rendible. Per a una organització que vol combinar BI tradicional amb casos d'ús de machine learning sobre dades no estructurades, el lakehouse evita mantenir dues plataformes separades. La decisió correcta depèn dels casos d'ús, no de la moda, i aquesta és exactament la conversa que abordem en un projecte d'estratègia de dades.
Arquitectures modernes: Snowflake, BigQuery i Amazon Redshift
Les tres plataformes que dominen el mercat de cloud data warehouse comparteixen un principi comú —escalar al núvol— però resolen l'arquitectura de maneres diferents, i aquestes diferències tenen conseqüències directes en cost i operació.
Snowflake: separació nativa de còmput i emmagatzematge
La proposta de valor de Snowflake, segons l'anàlisi comparativa basada en el Gartner Magic Quadrant for Cloud DBMS, és que separa de manera nativa el còmput de l'emmagatzematge, la qual cosa permet escalar cada recurs de forma independent. En la pràctica, això significa que podeu dimensionar la potència de càlcul d'un equip d'analistes durant el tancament mensual sense tocar el cost d'emmagatzematge, i apagar aquest còmput quan no s'usa. És una arquitectura molt popular en organitzacions amb càrregues de treball variables i multicloud.
Google BigQuery: serverless pur
BigQuery aposta per una arquitectura serverless amb escalat automàtic, segons la mateixa comparativa. El client no gestiona clústers ni nodes: llança la consulta i Google assigna els recursos. Això redueix dràsticament la càrrega operativa i resulta especialment atractiu per a equips petits sense un perfil dedicat d'administració de bases de dades, així com per a organitzacions ja establertes en l'ecosistema de Google Cloud.
Amazon Redshift: MPP i emmagatzematge columnar
Amazon Redshift utilitza una arquitectura MPP (processament massivament paral·lel) amb emmagatzematge columnar, que distribueix les consultes entre múltiples nodes per executar-les en paral·lel. La seva maduresa es reflecteix en les avaluacions independents: en el Gartner Critical Capabilities for Cloud DBMS for Analytical Use Cases 2025 —on Gartner va avaluar 18 proveïdors en 12 capacitats crítiques i 3 casos d'ús— Amazon Redshift va obtenir la puntuació més alta en Event Analytics i la segona més alta en Enterprise Data Warehouse i en Lakehouse.
| Plataforma | Arquitectura distintiva | Millor encaix |
|---|---|---|
| Snowflake | Còmput i emmagatzematge separats de manera nativa | Càrregues variables, multicloud |
| Google BigQuery | Serverless amb escalat automàtic | Equips sense DBA, ecosistema Google |
| Amazon Redshift | MPP + emmagatzematge columnar | Càrregues intensives, ecosistema AWS |
La convergència de 2025
Un punt crític que moltes empreses passen per alt en triar: les plataformes s'assemblen cada vegada més. Segons l'informe The State of Cloud Data Warehouses 2025 de Recordly, els grans proveïdors convergeixen al voltant de formats de taula oberts com Apache Iceberg i Delta Lake, i tots ofereixen ja còmput serverless, ETL/ELT integrat, runtimes de machine learning i interfícies d'IA generativa. La conseqüència estratègica és important: el risc de quedar atrapat en un proveïdor (vendor lock-in) disminueix, i el criteri de selecció es desplaça de "qui té la millor tecnologia" a "quin s'adapta millor al meu ecosistema, les meves competències internes i el meu model de costos".
Inmon, Kimball i el dilema ETL vs ELT
La tecnologia de la plataforma és només la meitat de la decisió. L'altra meitat —i on es juga gran part de l'èxit— és com es modela i es carrega la dada.
Les dues escoles clàssiques de disseny
Hi ha dues metodologies de referència per dissenyar un data warehouse, i continuen sent plenament vigents:
- Enfocament Inmon (top-down). Definit per Bill Inmon, proposa construir primer un repositori centralitzat i normalitzat (en tercera forma normal, 3NF) que actuï com a única font corporativa, i a partir d'ell derivar els data marts departamentals. Segons Keboola, prioritza la integritat i la consistència a costa d'un arrencada més lenta.
- Enfocament Kimball (bottom-up). Definit per Ralph Kimball, proposa començar pels data marts orientats a processos de negoci, modelats amb un esquema en estrella (taules de fets envoltades de taules de dimensions). Com recullen Keboola i Dataversity, ofereix resultats més ràpids i consultes intuïtives per al negoci, a costa d'un esforç posterior d'integració.
En la pràctica de la majoria de les empreses mitjanes, un enfocament Kimball pragmàtic —començar per un domini de negoci concret i lliurar valor ràpid— sol ser el camí més assenyat per no caure en projectes eterns.
ETL vs ELT: per què l'ordre importa
L'acrònim descriu l'ordre de tres passos: extreure, transformar i carregar.
- En l'ETL tradicional, les dades es transformen abans de carregar-se al warehouse, normalment en un servidor intermedi.
- En l'ELT modern, les dades es carreguen primer en brut i es transformen dins del propi warehouse, aprofitant la seva potència de càlcul.
L'elecció no és indiferent. Segons Matillion i Keboola, les bases de dades MPP com Amazon Redshift, Google BigQuery i Snowflake es van dissenyar i optimitzar per a ELT, mentre que l'ETL tradicional sol provocar problemes de rendiment amb grans volums de dades. Dit d'una altra manera: si heu invertit en una plataforma cloud moderna i l'opereu amb un patró ETL heretat, esteu desaprofitant precisament allò pel que pagueu. El patró ELT permet a més conservar la dada crua, la qual cosa facilita refer transformacions quan canvien les necessitats de negoci sense haver de tornar a les fonts.
Per què fracassen tants projectes de data warehouse?
És la pregunta incòmoda, i la resposta explica per què tantes inversions en dades no arriben a produir retorn. Segons CloudDataInsights, fins al 70% dels projectes de modernització de data warehouse fracassen o superen significativament pressupost i terminis. El patró de les causes és notablement consistent.
La qualitat de la dada és el problema número u
Segons Integrate.io, el 64% de les organitzacions cita la qualitat de les dades com el seu principal repte d'integritat. Un data warehouse no arregla dades dolentes: les centralitza i les fa més visibles. Si les fonts contenen duplicats, camps incoherents o regles de negoci no documentades, el magatzem amplificarà el problema en lloc de resoldre'l.
La càrrega de dades és més difícil del que sembla
El mateix estudi d'Integrate.io revela que el 88% dels responsables de TI declara tenir dificultats en carregar dades als seus data warehouses. Els principals inhibidors són:
- Tecnologia legacy (49%): sistemes antics que no exposen les dades amb facilitat.
- Tipus i formats de dades complexos (44%): fonts heterogènies que requereixen transformació no trivial.
- Sitges de dades (40%): informació atrapada en departaments que mai no es van dissenyar per compartir-la.
Les causes reals, més enllà de la tecnologia
Sumant les dades anteriors amb l'experiència de camp, els projectes fracassen per motius que rarament són tècnics:
- Començar per l'eina i no pel cas d'ús. Comprar la plataforma abans de definir quines decisions de negoci ha d'habilitar és la recepta més comuna del fracàs.
- Abast "big bang". Intentar consolidar tota l'organització d'una vegada, en lloc de lliurar valor per dominis, multiplica el risc i esgota el pressupost abans de demostrar resultats.
- Ignorar el govern de la dada. Sense propietaris de la dada, definicions acordades i regles de qualitat, el magatzem es degrada en mesos.
- Subestimar l'adopció. Un data warehouse tècnicament perfecte que ningú no utilitza perquè els quadres de comandament són confusos és un fracàs de negoci tot i ser un èxit d'enginyeria.
La conclusió que extraiem d'aquestes xifres coincideix amb el missatge d'obertura: el coll d'ampolla no és la tecnologia, que és més madura i accessible que mai, sinó l'arquitectura, el govern i l'enfocament del projecte.
Com abordar un projecte de data warehouse pas a pas
A partir dels patrons de fracàs anteriors, aquest és el camí que recomanem perquè la inversió generi retorn.
1. Comenceu per les preguntes de negoci, no per les dades
Abans d'avaluar una sola plataforma, definiu les cinc o deu decisions concretes que el data warehouse ha d'habilitar. "Conèixer la rendibilitat real per client" és un objectiu accionable; "tenir totes les dades en un lloc" no ho és. Aquestes preguntes determinaran el modelatge, les fonts prioritàries i els quadres de comandament.
2. Auditeu les vostres fonts i la qualitat de la dada
Atès que la qualitat de la dada és el repte número u, avalueu aviat l'estat real dels vostres sistemes origen: on hi ha els duplicats, les definicions contradictòries, les sitges? Un diagnòstic honest en aquesta fase evita sorpreses que disparen el pressupost més endavant.
3. Trieu arquitectura i plataforma segons el vostre context
Amb els casos d'ús i les fonts clars, l'elecció entre data warehouse, lakehouse i entre Snowflake, BigQuery o Redshift es converteix en una decisió informada: ecosistema cloud actual, competències internes, model de costos i necessitat d'IA/ML. Recordeu que, amb la convergència de 2025, gairebé totes les plataformes cobreixen el cas base; el criteri decisiu és l'encaix.
4. Modeleu amb un enfocament incremental
Apliqueu un enfocament Kimball pragmàtic: trieu un primer domini de negoci d'alt valor (per exemple, vendes o finances), lliureu-lo complet amb el seu esquema en estrella i els seus quadres de comandament, i demostreu retorn abans d'expandir-vos. Dissenyeu els fluxos de càrrega amb el patró ELT que la vostra plataforma cloud afavoreix.
5. Governeu i mesureu l'adopció
Definiu propietaris de la dada, un glossari de mètriques acordat i regles de qualitat automatitzades des del primer dia. I mesureu l'adopció real: nombre d'usuaris actius, decisions preses amb la dada, informes manuals eliminats. La capa visible de tot aquest esforç solen ser els quadres de comandament, i per això una eina com Power BI ben implementada marca la diferència entre un projecte que s'utilitza i un que s'ignora; així ho abordem als nostres serveis d'implantació de Power BI.
Checklist resum
| Fase | Pregunta clau | Risc si s'omet |
|---|---|---|
| 1. Casos d'ús | Quines decisions habilita? | Plataforma sobredimensionada |
| 2. Auditoria de fonts | Quina qualitat té la dada? | Sobrecostos i retards |
| 3. Arquitectura | Warehouse o lakehouse? Quina plataforma? | Vendor lock-in, mal encaix |
| 4. Modelatge incremental | Per quin domini començo? | Projecte "big bang" etern |
| 5. Govern i adopció | Qui és propietari de la dada? Qui l'utilitza? | Magatzem que ningú no usa |
Conclusió
Un data warehouse modern és la base sobre la qual una empresa construeix la seva capacitat de decidir amb dades, i el context no ha estat mai tan favorable: un mercat que es multiplica per gairebé set fins al 2034, plataformes que convergeixen en capacitats i un patró ELT que exprimeix la potència del núvol. Però les xifres també són un avís: quan el 70% dels projectes fracassa, l'avantatge competitiu no es troba en comprar l'eina correcta, sinó en abordar el projecte amb l'arquitectura, el govern i l'enfocament incremental correctes.
Si la vostra organització està valorant construir o modernitzar el seu data warehouse, el primer pas més rendible és un diagnòstic honest de la situació actual. Podeu començar amb la nostra auditoria gratuïta de Power BI per veure l'estat de la vostra analítica i de les vostres fonts de dades, o contactar amb el nostre equip per dissenyar l'arquitectura de dades que la vostra empresa realment necessita, sense caure en les estadístiques del fracàs.
