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, som ofte inneholder store datamengder, blir materialisert som incremental for å redusere kjøre- og lagringstiden. Aggregater (både brede og åpne aggregater som skal deles og konsumeres) blir materialisert som view 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:

{{
  config(
    materialized = 'incremental',
    unique_key = ['fk_person1', 'aarmnd'],
    merge_exclude_columns = ['fk_person1', 'aarmnd', ...],
    ...
  )
}}

select ...

For å legge til nye rader benytter vi is_incremental()-makroen:

select ...
where 
{% if is_incremental() %}
aarmnd > (select max(aarmnd) from {{ this }})
{% endif %}

Utfordringer med materialized view

Vi forsøkte å materialisere våre aggregater som materialized view, men støtte på flere begrensninger:

1. Modeller som bruker denne materialiseringen krever materialized view log på parent-/master-modeller.
2. 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" for refresh-definisjoner.
3. 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"