Materialisatie voor metrische weergaven

Materialisatie voor metrische weergaven versnelt query's door het gebruik van gerealiseerde weergaven om aggregaties vooraf te berekenen. Lakeflow-pijplijnen orkestreren door de gebruiker gedefinieerde gematerialiseerde weergaven voor een gegeven metrische weergave. Tijdens het uitvoeren van query’s stuurt de queryoptimalisator query’s naar de beste gematerialiseerde weergave met behulp van automatische aggregatiebewuste querymatching (queryherschrijving). U voert een query uit op de metrische weergave zoals gebruikelijk, zonder extra handmatige inspanning. Databricks vernieuwt de materialisaties om ze up-to-date te houden. Het kiest ook welke materialisatie moet worden bevraagd voor snellere query's tegen lagere kosten.

Hoe materialisatie werkt

Materialisatie voor metrische weergaven omvat twee fasen: het definiëren van de materialisatie en het uitvoeren van query's hierop.

Definitiefase (fase waarin de definitie plaatsvindt)

Wanneer u een metrische weergave definieert met materialisatie, geeft u uw velden, metingen en vernieuwingsschema op in de YAML voor de metrische weergave. Vanuit die definitie maakt Databricks een beheerde Lakeflow-pijplijn die de gerealiseerde weergaven bouwt en onderhoudt.

Definitie en materialisatiepijplijn voor metrische weergave

Hierdoor blijft de metrische definitie gescheiden van hoe deze wordt opgeslagen:

  • De metrische weergave is een Unity Catalog-object dat de velden, metingen en joins van de metrische gegevens definieert, samen met de materialisatieconfiguratie (planning en granulariteit). Het is de enige bron van waarheid voor wat de metrische waarde betekent.
  • De pijplijn materialiseert die definitie in een of meer gerealiseerde weergaven, elk vooraf berekend op een specifieke granulariteit. Databricks kiest welke moet worden gelezen tijdens het uitvoeren van query's.

Query uitvoeren

Wanneer u SELECT ... FROM <metric_view> uitvoert, gebruikt de query-optimizer het herschrijven van aggregaatbewuste query's om de prestaties te optimaliseren.

Uitvoering van query's met aggregate-bewuste herschrijving

  • Snelle route: leest uit vooraf berekende gerealiseerde weergaven wanneer er een geschikte materialisatie bestaat.
  • Terugvalpad: leest rechtstreeks uit brongegevens wanneer er geen geschikte materialisatie beschikbaar is.

De queryoptimalisatie zorgt automatisch voor een balans tussen prestaties en nieuwheid door te kiezen tussen gerealiseerde en brongegevens. U ontvangt transparant resultaten, ongeacht welk pad de optimizer gebruikt. Zie Query's uitvoeren op metrische weergaven voor meer informatie over het uitvoeren van query's op metrische weergaven.

Requirements

Materialisatie gebruiken voor metrische weergaven:

  • Je werkruimte moet serverless compute ingeschakeld hebben om Lakeflow-pijpleidingen te draaien.
  • Een SQL Warehouse- of rekenresource met Databricks Runtime 17.3 of hoger. Metrische weergaven zonder materialisatie worden ondersteund vanaf Databricks Runtime 16.4. Zie beschikbaarheid van metrische weergavefuncties voor de minimale runtime voor elke functie.

Important

Je kunt geen metrische weergave materialiseren wanneer de weergave of een van de brontabellen gebruikmaakt van row-level security (RLS),kolommaskers of attribute-based access control (ABAC)-beleid. Omdat een materialisatie vooraf wordt berekend zodra de identiteit van de eigenaar is gebruikt, zou het leveren ervan aan andere gebruikers de per-gebruiker toegangscontroles omzeilen die deze functies bij het querymoment afdwingen. Voor details, zie Query herschrijfmodus.

Configuratiegids

U configureert materialisatie in een veld op het hoogste niveau materialization in de YAML-definitie van de metrische weergave. Met dit veld stelt u de query-herschrijving mode in (altijd relaxed), evenals een optionele verversing schedule en een lijst met te onderhouden materialized_views. Elke gerealiseerde weergave is aggregated, waarmee vooraf specifieke dimensies en metingen worden berekend, of unaggregated, waarmee het volledige gegevensmodel wordt gerealiseerd.

Zie schedule voor de volledige specificatie per veld, inclusief vereiste en optionele velden, toegestane waarden en de componentbeperkingen.

Voorbeelddefinitie

In het volgende voorbeeld wordt een metrische weergave gedefinieerd met één niet-samengevoegde en twee geaggregeerde materialisaties:

version: 1.1

source: prod.operations.orders_enriched_view

filter: revenue > 0

fields:
  - name: category
    expr: substring(category, 5)

  - name: color
    expr: color

measures:
  - name: total_revenue
    expr: SUM(revenue)

  - name: number_of_suppliers
    expr: COUNT(DISTINCT supplier_id)

materialization:
  schedule: every 6 hours
  mode: relaxed

  materialized_views:
    - name: baseline
      type: unaggregated

    - name: revenue_breakdown
      type: aggregated
      dimensions:
        - category
        - color
      measures:
        - total_revenue
      cluster_by:
        cols:
          - category
          - color
      partition_by:
        - category

    - name: suppliers_by_category
      type: aggregated
      dimensions:
        - category
      measures:
        - number_of_suppliers

Note

Het materialization blok gebruikt het trefwoord dimensions: om velden op te sommen die moeten worden gematerialiseerd, ook al gebruikt de definitie op het hoogste niveau fields:. De twee trefwoorden zijn gelijkwaardig. Zie Velden.

De revenue_breakdown-materialisatie gebruikt cluster_by en partition_by om te bepalen hoe de gematerialiseerde gegevens fysiek worden opgeslagen, op dezelfde manier als de componenten CLUSTER BY en PARTITION BY bij een gematerialiseerde weergave. Zie Materialisatie voor de volledige veldspecificatie.

De metrische weergave maken met behulp van SQL

Als u deze metrische weergave buiten Catalog Explorer wilt maken, verpakt u de YAML in CREATE OR REPLACE VIEW ... WITH METRICS LANGUAGE YAML AS en plaatst u de definitie tussen de $$ scheidingstekens:

CREATE OR REPLACE VIEW catalog.schema.orders_materialized WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1

  source: prod.operations.orders_enriched_view

  filter: revenue > 0

  dimensions:
    - name: category
      expr: substring(category, 5)

    - name: color
      expr: color

  measures:
    - name: total_revenue
      expr: SUM(revenue)

    - name: number_of_suppliers
      expr: COUNT(DISTINCT supplier_id)

  materialization:
    schedule: every 6 hours
    mode: relaxed

    materialized_views:
      - name: baseline
        type: unaggregated

      - name: revenue_breakdown
        type: aggregated
        dimensions:
          - category
          - color
        measures:
          - total_revenue

      - name: suppliers_by_category
        type: aggregated
        dimensions:
          - category
        measures:
          - number_of_suppliers
$$

Herschrijfmodus voor query's

In de modus relaxed wordt bij het automatisch herschrijven van query’s alleen gecontroleerd of mogelijke gematerialiseerde weergaven over de benodigde velden en maatstaven beschikken om de query uit te voeren.

De volgende controles worden overgeslagen:

  • Nieuwheid: Het controleert niet of de materialisatie up-to-date is.
  • SQL-instellingen: Er wordt niet gecontroleerd of instellingen zoals TIMEZONE of ANSI_MODE overeenkomen.
  • Determinisme: Er wordt niet gecontroleerd of de gerealiseerde resultaten volledig deterministisch zijn.

Query’s die overeenkomen met een materialisatie gebruiken de meest recente vernieuwing. Query’s die niet overeenkomen, vallen terug op de gegevensbron en geven livegegevens terug. Als gevolg hiervan kan de versheid van gegevens variëren, afhankelijk van of een query in aanmerking komt voor herschrijven. Als u de consistentie wilt controleren, moet u het vernieuwingsschema voor materialisatie afstemmen met uw bronpijplijn. Als uw bron bijvoorbeeld dagelijks wordt bijgewerkt met een batchpijplijn, plant u de materialisatieverversingen zo dat ze worden uitgevoerd nadat die pijplijn is voltooid. U kunt ook een niet-samengevoegde materialisatie gebruiken om ervoor te zorgen dat alle query's uit dezelfde momentopname worden gelezen.

U kunt geen materialisatie maken wanneer de metrische weergave of een van de brontabellen gebruikmaakt van:

  • Beveiliging op rijniveau (RLS), maskering op kolomniveau (CLM) of ABAC-beleid. Vooraf berekende resultaten kunnen toegangscontroles per gebruiker omzeilen die tijdens de uitvoering van een query moeten worden afgedwongen.
  • Aanroeperafhankelijke expressies, waarvan het resultaat wordt gewijzigd op basis van wie de query uitvoert (bijvoorbeeld current_user() of is_member()). Een materialisatie wordt één keer vooraf berekend en gedeeld; als die aan een andere gebruiker wordt aangeboden, levert dat onjuiste of onveilige resultaten op.

Databricks valideert deze beperking wanneer u een materialisatie maakt, wijzigt of vernieuwt. Deze bewerkingen mislukken met de foutvoorwaarde METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED (SQLSTATE 42K0E). Zie METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED.

Soorten materialisaties voor metrische weergaven

In de volgende secties worden de typen gerealiseerde weergaven uitgelegd die beschikbaar zijn voor metrische weergaven en bieden richtlijnen voor het selecteren van de juiste configuratie voor uw gegevensbronnen en querypatronen.

Geaggregeerd type

Met dit type worden aggregaties vooraf berekend voor opgegeven combinaties van metingen en velden voor gerichte dekking.

Gebruik een geaggregeerd type wanneer er specifieke dimensie- en metingcombinaties zijn die regelmatig worden opgevraagd. Bij geaggregeerde materialisaties worden zowel exacte overeenkomst- als roll-upovereenkomst-strategieën toegepast, wat de beste queryprestaties voor deze patronen oplevert.

Voor optimale aggregaties:

  • Neem de meest gebruikte dimensies op in GROUP BY clausules.
  • Neem alle mogelijke filterkolommen op (kolommen die in WHERE tijdens het uitvoeren van query's worden gebruikt).
  • Materialiseer op het meest gedetailleerde niveau dat uw query's nodig hebben. Een materialisatie op (region, sku, event_day) kan bijvoorbeeld voor al het volgende dienen:
    • GROUP BY region
    • GROUP BY region, event_month
    • GROUP BY sku met WHERE region = 'US'
  • Vermijd dimensies zo gedetailleerd dat ze voornamelijk groepen met één rij produceren (bijvoorbeeld een onbewerkte tijdstempel met millisecondenprecisie). Dit heeft geen voordeel en vergroot de opslag.
  • Let op niet-additieve metingen. Niet-additieve metingen kunnen niet opnieuw worden samengevoegd vanuit gedeeltelijke resultaten (bijvoorbeeld COUNT(DISTINCT), MEDIANen percentielen) en vereisen een exacte overeenkomst ten opzichte van een materialisatie.

Eén aggregatie kan alleen query’s verwerken die overeenkomen met de specifieke dimensies ervan (exacte overeenkomst) of met een subset van die dimensies (rollup-overeenkomst). Databricks raadt aan om meerdere geaggregeerde materialisaties te maken voor verschillende queryshapes.

Niet-geaggregeerd type

Dit type omvat het volledige niet-geaggregeerde gegevensmodel (de velden source, joins, filter en fields) voor een bredere dekking met minder gevolgen voor de prestaties vergeleken met het geaggregeerde type.

Gebruik een niet-samengevoegd type als een van de volgende waar is:

  • Uw metriekweergave vereist kostbare brontransformaties of join-bewerkingen.
  • Zoekpatronen zijn onvoorspelbaar of wisselend.
  • Alle gebruikers die een query uitvoeren op de metrische weergave, moeten consistentie in de gegevens zien.

Met niet-geaggregeerde materialisaties worden kostbare bronweergaven en joins één keer berekend tijdens het vernieuwen, in plaats van bij elke query. Wanneer er zowel geaggregeerde als niet-geaggregeerde materialisaties bestaan, berekent Databricks de geaggregeerde materialisaties van de niet-samengevoegde materialisatie. Dit biedt een consistente momentopname en vermijdt redundante hercomputatie van de bron. Een niet-samengevoegde overeenkomst komt altijd in aanmerking, ongeacht de vorm van de query, met inachtneming van de beperkingen die worden beschreven in de modus voor het herschrijven van query's.

Een niet-geaggregeerde materialisatie helpt niet wanneer de bron een directe tabelverwijzing is zonder selectief filter. In dat geval heeft het geen voordeel om rechtstreeks een query uit te voeren op de bron.

Zie Een materialisatietype voor metrische weergaven kiezen voor aanvullende richtlijnen over hoe en wanneer u deze materialisatietypen gebruikt.

Automatisch opnieuw schrijven van query's

Wanneer u een query uitvoert op een metrische weergave, wordt uw query automatisch gerouteerd naar de best beschikbare materialisatie. Het gebruikt drie queryherschrijfstrategieën: exacte overeenkomst, roll-up-overeenkomst en niet-geaggregeerde overeenkomst.

Aggregat-aware query herschrijven

De query wordt automatisch uitgevoerd op de beste materialisatie in plaats van de basistabellen met behulp van dit algoritme:

  1. Eerst probeert de queryoptimizer een exacte overeenkomst te vinden.
  2. Als er geen exacte overeenkomst is, probeert de queryoptimalisator een roll-upmatch.
  3. Als er geen rollup-overeenkomst is en er een niet-geaggregeerde materialisatie bestaat, probeert de query-optimizer een niet-geaggregeerde overeenkomst te vinden.
  4. Als er geen niet-geaggregeerde overeenkomst is, leest de query rechtstreeks uit de brontabellen.

In de volgende secties wordt uitgelegd hoe elke strategie werkt.

Overeenkomststrategieën voor herschreven zoekopdrachten

Note

Materialiseringen moeten voltooid zijn voordat het herschrijven van queries van kracht kan worden.

Exacte overeenkomst

De query vraagt precies om wat er vooraf is berekend in de materialisatie. Bij het herschrijven van query's wordt het opgeslagen resultaat gelezen zonder extra werk, waardoor snelle resultaten mogelijk zijn.

Om in aanmerking te komen voor een exacte match:

  • De expressies van GROUP BY de query moeten exact overeenkomen met de materialisatiedimensies.
  • De metingen van de query moeten een subset van de materialisatiemetingen zijn.

Een materialisatie heeft bijvoorbeeld dimensies en metingen [region, order_date][total_revenue, order_count]. Een query die groepeert op region en order_date en total_revenue opvraagt, is een exacte match, omdat de dimensies hetzelfde zijn en de meetwaarde al vooraf berekend was.

Samengevouwen overeenkomst

De query vraagt om een samenvatting op een grofer niveau dan wat vooraf is berekend. De optimizer leest het vooraf berekende resultaat en voegt het opnieuw samen tot het niveau dat de query nodig heeft.

Om in aanmerking te komen voor rollup match:

  • Grovere korrel: De query groepeert op minder dimensies of een bredere tijdsgranulariteit dan de materialisatie.
  • Alle metingen zijn additief: elke meting die door uw query wordt gevraagd, moet een meting zijn die correct kan worden berekend door gedeeltelijke resultaten (bijvoorbeeld SUM van SUMs of MAXMAXes) te combineren. MEDIAN kan niet worden samengeteld omdat deze afhankelijk is van de groepsdistributie.
  • Alle deelnemende filters moeten deterministische expressies zijn: als uw query een WHERE component heeft, moet het filter altijd hetzelfde resultaat voor dezelfde invoer produceren. Is bijvoorbeeld WHERE region = 'US' deterministisch, maar expressies zoals rand() of uuid() niet.

Een rollup-overeenkomst komt niet in aanmerking voor niet-additieve maatstaven, omdat deze niet correct opnieuw geaggregeerd kunnen worden op basis van deelresultaten. Zie Additieve metingen.

Als u bijvoorbeeld dezelfde materialisatie gebruikt met dimensies [region, order_date] en meetwaarden [total_revenue, order_count], is een query die alleen op region groepeert en om total_revenue vraagt een rollup-overeenkomst. De query heeft minder dimensies nodig dan wat is gematerialiseerd, dus de engine aggregeert de dagelijkse totalen naar totalen op regionaal niveau.

Note

Rollup-overeenkomst is niet beschikbaar wanneer de metriekweergave een one_to_many-join gebruikt. In dat geval valt elke materialisatie alleen terug op exacte overeenkomst. Zie Een-op-veel-joins voor meer informatie over een-op-veel-joins.

Additieve metingen

Een meting is additief als het geaggregeerde resultaat correct kan worden aangevuld door bestaande geaggregeerde materialisaties opnieuw te aggregeren. Dit is de basisvereiste voor rollup-matching.

Elke aggregatie die gebruikmaakt van DISTINCT (bijvoorbeeld COUNT(DISTINCT), SUM(DISTINCT)) is niet-additief en kan niet worden geaggregeerd.

De volgende functies zijn additief:

  • SUM
  • COUNT
  • MIN
  • MAX
  • BIT_AND
  • BIT_OR
  • BIT_XOR
  • BOOL_AND
  • BOOL_OR

Aanvullende beperkingen zijn van toepassing op additieve metingen:

  • De metingdefinitie moet precies één statistische functie bevatten. Een maatstaf waarvan de definitie meerdere aggregaties combineert (bijvoorbeeld sum(cost) + min(revenue)) komt niet in aanmerking voor roll-up-overeenstemming.
  • Als de metingdefinitie een FILTER component bevat, moet deze deterministisch zijn.
  • De meting kan geen venstermeting zijn (bijvoorbeeld een doorlopende totaal van 7 dagen of een jaar-op-jaarvergelijking die is gedefinieerd met een vensterblok).

De volgende tabel bevat een overzicht van de wijze waarop algemene metingspatronen worden toegewezen aan overeenkomende typen:

Patroon meting Overeenkomsttype Reden
Eén additief aggregaat (SUM, COUNT, MIN) MAX Geschikt voor rollup Kan opnieuw worden samengevoegd vanuit gedeeltelijke resultaten
COUNT(DISTINCT) of andere niet-additieve aggregaties Alleen exacte overeenkomsten Kan niet opnieuw worden samengevoegd
Meerdere aggregaties in één expressie (SUM(x) + MIN(y)) Alleen exacte overeenkomsten Kan afzonderlijke aggregaties voor samenvouwen niet isoleren
Additieve aggregatie met deterministische FILTER Geschikt voor rollup Filter is deterministisch, aggregaat is additief
Venstermeting Alleen exacte overeenkomsten Vensterkader is afhankelijk van het exacte graan

Niet-geaggregeerde match

De query komt niet overeen met een vooraf berekende aggregatie, maar het dure voorbereidingswerk (joins en filters) is al klaar. Het herschrijven van query's begint met de voorbereide gegevensset van de niet-samengevoegde materialisatie in plaats van terug te gaan naar de brontabellen.

Als er een niet-geaggregeerde materialisatie bestaat, kan deze strategie altijd als terugvaloptie worden gebruikt voordat naar de bron wordt gegaan. Elke queryvorm kan hiervan gebruikmaken, onder voorbehoud van de beperkingen die worden beschreven in de Query-herschrijfmodus.

Uw query groepeert bijvoorbeeld op category en vraagt om unique_customers, maar geen enkele geaggregeerde materialisatie bevat die velden en maatstaven. Er is echter een niet-geaggregeerde materialisatie beschikbaar met de samengevoegde, gefilterde gegevensset die klaarstaat. De queryoptimalisatie leest uit die voorbereide gegevensset en wordt uitgevoerd GROUP BY category, COUNT(DISTINCT customer_id) op het moment van de query, in plaats van de onbewerkte tabellen helemaal opnieuw samen te voegen.

Nagaan of een query gebruikmaakt van gematerialiseerde weergaven

Er zijn twee manieren om te controleren of een query gebruikmaakt van een gerealiseerde weergave:

  • Voer EXPLAIN EXTENDED uit voor uw query om het queryplan te bekijken. Als de materialisatie is gebruikt, bevat het bladknooppunt __materialization_mat_<pipeline ID>___metric_view_mat_ en de naam van de materialisatie uit het YAML-bestand.
  • Bekijk het queryprofiel, zoals hieronder wordt weergegeven.

Queryprofiel met weergave van materialisatiegebruik

Materialisatielevenscyclus

In deze sectie wordt uitgelegd hoe materialisaties gedurende hun levenscyclus worden gemaakt, beheerd en vernieuwd.

Aanmaken en aanpassen

Wanneer u een metrische weergave (met behulp van CREATE, ALTERof Catalogusverkenner) maakt of wijzigt, wordt de definitie van de metrische weergave onmiddellijk bijgewerkt. Gematerialiseerde weergaven worden asynchroon op de achtergrond vernieuwd via een beheerde pijplijn.

Een nieuwe materialisatie definiëren in de Catalogusverkenner-editor:

  1. Klik op Materialisaties.
  2. Klik op Planning om een planning in te stellen. U kunt een intervalperiode selecteren of de materialisatie zo instellen dat deze op een bepaald tijdstip wordt uitgevoerd.
  3. Selecteer een type. Er is slechts één niet-samengevoegde materialisatie toegestaan per metrische weergave. Zie Typen materialisaties voor metrische weergaven voor meer informatie.
  4. Gebruik de vervolgkeuzelijst Velden om de velden te selecteren die u wilt opnemen in de materialisatie.
  5. Gebruik de vervolgkeuzelijst Metingen om de metingen te selecteren die u wilt opnemen.

Wanneer u een metrische weergave maakt, maakt Databricks een Lakeflow-pijplijn en plant deze meteen een eerste update in als er gematerialiseerde weergaven zijn opgegeven. De metrische weergave blijft bevraagbaar zonder materialisaties door terug te vallen op het bevragen van de brongegevens.

Wanneer u een metrische weergave wijzigt, plant Databricks geen nieuwe updates, tenzij u materialisatie voor het eerst inschakelt. Gerealiseerde weergaven worden pas gebruikt voor het automatisch herschrijven van query's als de volgende geplande update is voltooid.

Bij het wijzigen van het materialisatieschema wordt geen vernieuwing gestart.

Zonder een schema voert de pijplijn bij het aanmaken een initiële update uit, maar latere vernieuwingen moeten handmatig worden gestart, anders verouderen de gegevens. Databricks raadt aan altijd een planning te definiëren, zodat gegevens actueel blijven, tenzij u test of prototypen uitvoert.

Zie Handmatig vernieuwen voor een nauwkeurigere controle over het vernieuwingsgedrag.

Onderliggende pijplijn controleren

Materialisatie voor metrische weergaven wordt geïmplementeerd met behulp van Lakeflow-pijplijnen. U kunt de pijplijn op twee manieren openen:

  • In Catalog Explorer: Het tabblad Overzicht voor de metrische weergave bevat een directe koppeling onder de kop Vernieuwingsschema . Zie Wat is Catalog Explorer?voor meer informatie over toegang tot Catalog Explorer.
  • SQL gebruiken: Voer DESCRIBE EXTENDED uit. De sectie Informatie vernieuwen bevat de pijplijnkoppeling en de huidige vernieuwingsstatus.
DESCRIBE EXTENDED my_metric_view;

Voorbeelduitvoer:

-- Returns additional metadata such as parent schema, owner, access time etc.
> DESCRIBE EXTENDED my_metric_view;
                      col_name                       data_type    comment
 ------------------------------- ------------------------------ ----------
                           ...                             ...        ...

 # Detailed Table Information
                           ...                             ...

                      Language                            YAML
              Table properties                             ...
 # Refresh Information
         Latest Refresh Status                       Succeeded
                Latest Refresh                     https://...
              Refresh Schedule                   EVERY 6 HOURS

Handmatig vernieuwen

Via de koppeling naar de Lakeflow-pijplijnpagina kunt u handmatig een pijplijnupdate starten om de materialisaties bij te werken. U kunt ook handmatig vernieuwen activeren met behulp van de volgende SQL-opdracht:

REFRESH MATERIALIZED VIEW <metric-view-name>

Stapsgewijs vernieuwen

Gematerialiseerde views maken waar mogelijk gebruik van incrementele vernieuwing en hebben dezelfde beperkingen als standaard gematerialiseerde views met betrekking tot gegevensbronnen en planstructuur.

Zie Incrementeel vernieuwen voor gerealiseerde weergaven voor details over voorwaarden en beperkingen.

Billing

Het vernieuwen van gematerialiseerde weergaven brengt gebruikskosten voor Lakeflow-pijplijnen met zich mee. Zie Wat is het DBU-verbruik van een serverloze pijplijn om het DBU-verbruik van de pijplijn te vinden.

Bekende beperkingen

De volgende beperkingen gelden voor materialisatie voor metrische weergaven:

  • U kunt een metrische weergave die parameters definieert, niet materialiseren.
  • Nadat een materialisatie is gemaakt voor een metrische weergave, kunt u de eigenaar niet meer wijzigen.
  • Databricks biedt geen ondersteuning voor groepseigendom van gerealiseerde metrische weergaven.
  • Alleen de strategie voor exacte overeenkomsten komt in aanmerking voor metriekweergaven met één-op-veel-joins.
  • De materialisatie schedule biedt geen ondersteuning voor de TRIGGER ON UPDATE component.
  • Last updated on