Van Looker PDTs naar dbt: hoe we een datawarehouse opnieuw structureerden

“We hebben 47 Persistent Derived Tables in Looker. Niemand weet meer welke wat doet.”

Dat was de situatie bij een grote retailer met een hub & spoke datawarehouse in BigQuery. Looker draaide als rapportagetool, maar was gaandeweg ook de transformatielaag geworden. PDTs die op PDTs draaiden, die weer op PDTs draaiden. Een keten van afhankelijkheden die niemand meer kon overzien.

Het probleem met PDTs als transformatielaag

Looker PDTs zijn krachtig voor snelle prototypes. Maar als je er een heel datawarehouse op bouwt, loop je tegen fundamentele beperkingen aan:

• Geen versiebeheer: wijzigingen zijn direct live, zonder review of rollback
• Geen tests: je ontdekt fouten pas als een dashboard rare cijfers toont
• Geen documentatie: de logica zit verborgen in LookML-bestanden
• Cascade rebuilds: één wijziging triggert een keten van rebuilds die uren kan duren
• Geen lineage: je ziet niet welke brondata in welke rapportage terechtkomt

De aanpak: gefaseerde migratie

We hebben niet alles in één keer omgegooid. In plaats daarvan kozen we voor een pragmatische, gefaseerde aanpak.

Fase 1: Inventarisatie en classificatie

Eerst hebben we alle PDTs in kaart gebracht en geclassificeerd:

• Staging: directe transformaties op brondata
• Intermediate: business logic en joins
• Marts: eindproducten voor rapportage

Dit gaf ons voor het eerst een helder beeld van de dataflow.

Fase 2: dbt-project opzetten

Een schoon dbt-project in BigQuery met een duidelijke mappenstructuur:

models/
  staging/       - 1-op-1 met brondata
  intermediate/  - business logic
  marts/         - rapportage-klare datasets

Elke laag heeft zijn eigen schema-tests en documentatie. Niet als luxe, maar als basisvereiste.

Fase 3: Migratie per domein

Domein voor domein migreerden we de PDTs naar dbt-modellen. Per domein:

1. PDT-logica vertalen naar dbt SQL
2. Tests schrijven die output valideren tegen de bestaande PDT
3. Looker omschakelen naar de dbt-tabel
4. PDT uitschakelen

Fase 4: Optimalisatie

Met de transformaties in dbt konden we optimaliseren wat in Looker niet mogelijk was:

• Incrementele modellen: alleen nieuwe of gewijzigde data verwerken
• Materialisatie-strategie: per model kiezen tussen table, view of incremental
• Parallelle verwerking: dbt begrijpt de dependency graph en maximaliseert parallelisme

Het resultaat

Na drie maanden was de migratie compleet:

• Rebuild-tijd van 4 uur naar 20 minuten: dankzij incrementele modellen en parallellisatie
• 200+ tests: elke ochtend weten we of de data klopt vóórdat de business het dashboard opent
• Volledige documentatie: automatisch gegenereerd vanuit dbt, inclusief lineage graph
• Versiebeheer via Git: elke wijziging reviewbaar, testbaar, terugdraaibaar

Maar het belangrijkste resultaat was minder zichtbaar: het team had weer vertrouwen in de data. Geen “klopt dit cijfer wel?”-discussies meer in de wekelijkse meeting.

De les

Tooling is niet het probleem. Het probleem is wanneer een tool wordt ingezet voor iets waarvoor het niet is ontworpen. Looker is briljant als rapportagetool. Maar het is geen transformatieplatform.

De kracht van dbt zit niet in de SQL - die is hetzelfde. De kracht zit in de engineering practices die het afdwingt: tests, documentatie, versiebeheer, modulaire opbouw. Dat zijn geen nice-to-haves. Dat is het verschil tussen een datawarehouse dat je vertrouwt en een die je vreest.

---

Worstelt uw organisatie met onbeheersbare datatransformaties? Neem contact op, we helpen u graag met een gestructureerde aanpak.