From f8d66bf1defa3adbedd8f73f9ad810594cd99f9a Mon Sep 17 00:00:00 2001 From: delmona Date: Tue, 15 Oct 2024 11:34:54 +0200 Subject: [PATCH] Legger til side om materialiseringsstrategi i Team Spenn --- docs/arkitektur/materialisering_spenn.md | 44 ++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 docs/arkitektur/materialisering_spenn.md diff --git a/docs/arkitektur/materialisering_spenn.md b/docs/arkitektur/materialisering_spenn.md new file mode 100644 index 0000000..15d1c5d --- /dev/null +++ b/docs/arkitektur/materialisering_spenn.md @@ -0,0 +1,44 @@ +# Materialiseringsstrategi i Team Spenn + +Formålet med denne strategien er å unngå droppe og deretter opprette datavarehusobjekter hver gang et dbt-løp kjøres da dette er ugunstig mhp. DMO. Derfor har `table`-materialisering blitt faset ut i våre prosjekter. Følgende materialiseringer blir derfor tatt i bruk på tvers av våre dbt-løp: + +| | Materialisering | Kommentar | +|------------------|-------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **Staging** | `ephemeral` | Staging-modellene blir materialisert som `ephemeral` fordi de kun fungerer som simple transformasjoner som ikke skal eksponeres for sluttbrukeren. Det er heller ikke behov for å lagre dataene fysisk. | +| **Intermediate** | `view` | Intermediate-modellene blir materialisert som `view` fordi de har kompleks logikk og kjører ikke for tregt. | +| **Marts** | `incremental` og `view` | Faktatabeller og aggregater (både brede og åpne aggregater som skal deles og konsumeres) blir materialisert som hhv. `incremental` og `view`. Faktatabeller, som ofte inneholder store datamengder, blir materialisert som `incremental` for å redusere kjøre- og lagringstiden. Aggregater blir materialisert som `view`, og ikke som `incremental`, da de ikke inneholder mye data og mangler unike nøkler. Hvis aggregatene begynner å ta for lang tid å kjøre som `view`, kan de alternativt materialiseres som `incremental` (gitt at duplikater ikke er et problem for modellen og/eller at `unique_key` eksisterer) eller som `materialized view` (se utfordringer nevnt nedenfor). | + +## Mer om vår incremental-materialisering i Marts + +Vi bruker `unique_key`-konfigurasjonen for å finne rader fra en tidligere kjøring med samme unike ID. Dette gjør det mulig å oppdatere eksisterende rader i stedet for å legge dem til som nye: + +```sql +{{ + config( + materialized = 'incremental', + unique_key = ['kolonne_1', 'kolonne_2'], + merge_exclude_columns = ['kolonne_1', 'kolonne_2', ...], + ... + ) +}} + +select ... +``` +For å legge til nye rader benytter vi `is_incremental()`-makroen: +```sql +select ... +where +{% if is_incremental() %} +kolonne_dato_kilde > (select max(kolonne_dato_target) from {{ this }}) +{% endif %} +``` + +## Utfordringer med materialized view + +Vi forsøkte å materialisere aggregatene våre som `materialized view`, men støtte på flere begrensninger: +- Modeller som bruker denne materialiseringen krever `materialized view log` på parent-/master-modeller. +- Modeller som bruker denne materialiseringen blir automatisk satt til "forced refresh" i Oracle - se tabell 5-3 under [seksjon 5.3.7 "About refresh Options for Materialized Views"](https://docs.oracle.com/en/database/oracle/oracle-database/12.2/dwhsg/basic-materialized-views.html#GUID-11109A1B-1E8A-4F10-9BB3-DEB4D1AAEC36) for refresh-definisjoner. +- Det er flere restriksjoner for "fast refresh" på `materialized view`: + - 5.3.7.4 "General Restrictions on Fast Refresh" + - 5.3.7.5 "Restrictions on Fast Refresh on Materialized Views with Joins Only" + - 5.3.7.6 "Restrictions on Fast Refresh on Materialized Views with Aggregates" \ No newline at end of file