Materializace pro zobrazení metrik

Důležité

Tato funkce je ve verzi Public Preview.

Materializace zobrazení metrik zrychluje dotazy pomocí materializovaných zobrazení k předpočítávání agregací. Kanály Lakeflow orchestrují uživatelsky definovaná materializovaná zobrazení pro dané zobrazení metriky. Optimalizátor dotazů v době dotazu směruje dotazy do nejlepšího materializovaného zobrazení pomocí automatického porovnávání agregovaných dotazů (přepisování dotazů). Na zobrazení metrik se dotazujete jako obvykle, bez jakéhokoli dalšího ručního zásahu. Databricks aktualizuje materializace, aby byly aktuální. Také vybere, kterou materializaci použít pro rychlejší dotazy při nižších nákladech.

Jak materializace funguje

Materializace zobrazení metrik zahrnuje dvě fáze: definování materializace a spouštění dotazů.

Definiční fáze

Když definujete zobrazení metriky s materializací, zadáte pole, míry a plán aktualizace v YAML zobrazení metrik. Z této definice vytvoří Databricks spravovaný kanál Lakeflow , který sestaví a udržuje materializovaná zobrazení.

Díky tomu je definice metriky oddělená od způsobu uložení:

• Zobrazení metrik je objekt katalogu Unity, který definuje pole, míry a spojení metriky spolu s konfigurací materializace (plán a členitost). Je to jediný zdroj pravdy pro to, co metrika znamená.
• Datové potrubí převede tuto definici na jedno nebo více materializovaných zobrazení, z nichž každé je předem vypočítáno na konkrétní úrovni granularity. Databricks při dotazu vybere, který z nich načte.

Provedení dotazu

Když spustíte SELECT ... FROM <metric_view>, optimalizátor dotazů použije k optimalizaci výkonu přepisování dotazů s podporou agregace:

• Rychlá cesta: Čte z předem vypočítaných materializovaných zobrazení, pokud existuje vhodná materializace.
• Záložní cesta: Když není k dispozici žádná vhodná materializace, čte se přímo ze zdrojových dat.

Optimalizátor dotazů automaticky vyrovnává výkon a aktuálnost výběrem mezi materializovanými a zdrojovými daty. Výsledky se zobrazí transparentně bez ohledu na to, jakou cestu optimalizátor používá. Další informace o spouštění dotazů nad zobrazeními metrik najdete v tématu Dotazování zobrazení metrik.

Požadavky

Použití materializace pro zobrazení metrik:

• Váš pracovní prostor musí mít povolený bezserverový výpočetní výkon. To je nutné ke spuštění kanálů Lakeflow.
• SQL Warehouse nebo výpočetní prostředek, na kterém běží Databricks Runtime 17.3 nebo novější.

Note

Materializace vyžaduje Databricks Runtime 17.3 nebo vyšší. Vytvoření zobrazení metrik bez materializace se podporuje v Databricks Runtime 16.4 a novějších. Informace o minimální verzi runtime pro každou funkci najdete na stránce Dostupnost funkce zobrazení metrik.

Referenční informace ke konfiguraci

Materializaci nakonfigurujete v poli materialization na nejvyšší úrovni v definici YAML zobrazení metrik. Toto pole určuje přepsání dotazu mode (vždy relaxed), volitelnou aktualizaci schedule a seznam prvků materialized_views, které se mají zachovat. Každé materializované zobrazení je buď aggregated, které předem vypočítá specifické dimenze a míry, nebo unaggregated, které materializuje celý datový model.

Úplnou specifikaci jednotlivých polí, včetně povinných a nepovinných polí, povolených hodnot a omezení klauzule schedule, naleznete v části Materialization.

Příklad definice

Následující příklad definuje zobrazení metriky s jednou neagregovanou materializací a dvěma agregovanými materializacemi:

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

Blok materialization používá klíčové slovo dimensions: k vypsání polí, která se mají materializovat, i když definice na nejvyšší úrovni používá fields:. Tato dvě klíčová slova jsou ekvivalentní. Viz pole.

Materializace revenue_breakdown používá cluster_by a partition_by k řízení toho, jak jsou materializovaná data fyzicky uložena, stejně jako klauzule CLUSTER BY a PARTITION BY u materializovaného pohledu. Úplnou specifikaci pole naleznete v tématu Materializace.

Vytvoření zobrazení metrik pomocí SQL

Chcete-li vytvořit toto zobrazení metriky mimo Catalog Explorer, zabalte YAML do CREATE OR REPLACE VIEW ... WITH METRICS LANGUAGE YAML AS a umístěte definici mezi oddělovače $$:

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
$$

Režim přepsání dotazu

V režimu relaxed automatické přepisování dotazu pouze ověřuje, zda kandidátní materializovaná zobrazení mají potřebná pole a měřené hodnoty pro obsloužení dotazu.

Přeskočí se následující kontroly:

• Aktuálnost: Neověřuje, zda je materializace aktuální.
• Nastavení SQL: Neověřuje, zda se nastavení, jako jsou TIMEZONE nebo ANSI_MODE, shodují.
• Determinismus: Neověřuje, že materializované výsledky jsou plně deterministické.

Dotazy, které odpovídají materializaci, používají poslední aktualizaci. Dotazy, které se neshodují, se vrátí ke zdroji a vrátí živá data. V důsledku toho se aktuálnost dat může lišit v závislosti na tom, jestli se dotaz kvalifikuje k přepsání. Pokud chcete ověřit konzistenci, zarovnejte plán aktualizace materializace se zdrojovým kanálem. Pokud se například zdroj denně aktualizuje pomocí dávkového zpracování, naplánujte obnovení materializace tak, aby se spustilo po dokončení tohoto procesu. Případně můžete použít neagregovanou materializaci k zajištění toho, aby všechny dotazy načítaly ze stejného snímku.

Materializaci nemůžete vytvořit, pokud zobrazení metrik nebo některá z jeho zdrojových tabulek používá:

• Zabezpečení na úrovni řádků (RLS),maskování na úrovni sloupců (CLM) nebo zásady ABAC Předem vypočítané výsledky můžou obejít řízení přístupu pro jednotlivé uživatele, které se mají vynucovat v době dotazu.
• Výrazy závislé na invokeru, jejichž výsledek se změní na základě toho, current_user() kdo dotaz spouští (například nebo is_member()). Materializace se předem vypočítá jednou a sdílí se, takže její poskytnutí jinému uživateli by vrátilo nesprávné nebo nezabezpečené výsledky.

Databricks toto omezení ověřuje při vytvoření, úpravě nebo aktualizaci materializace. Tyto operace selžou s chybovým stavem METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED (SQLSTATE 42K0E). Viz METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED.

Typy materializací pro zobrazení metrik

Následující části popisují typy materializovaných zobrazení dostupných pro zobrazení metrik a poskytují pokyny k výběru vhodné konfigurace pro zdroje dat a vzory dotazů.

Agregovaný typ

Tento typ předem vypočítá agregace pro zadané kombinace měr a polí pro cílené pokrytí.

Agregovaný typ použijte, pokud jsou často dotazovány konkrétní kombinace dimenzí a měr. U agregovaných materializací lze použít strategii přesné shody i strategii shody při agregaci, které pro tyto vzory zajišťují nejlepší výkon dotazů.

Optimální agregace:

• Zahrnout nejčastěji používané dimenze do GROUP BY klauzulí.
• Zahrňte všechny potenciální sloupce filtru (sloupce použité v WHERE době dotazu).
• Materializujte na nejpodrobnější úrovni, kterou vaše dotazy vyžadují. Například materializace v (region, sku, event_day) může sloužit ke všemu následujícímu:
  • GROUP BY region
  • GROUP BY region, event_month
  • GROUP BY sku s WHERE region = 'US'
• Vyhněte se rozměrům tak členitým, že vytvářejí převážně skupiny s jedním řádkem (například nezpracované časové razítko s přesností milisekund). To nemá žádné výhody a nafoukne úložiště.
• Dávejte pozor na neaditivní míry. Nedatné míry nelze znovu agregovat z částečných výsledků (například COUNT(DISTINCT), MEDIAN, a percentilů) a vyžadovat přesnou shodu s materializací.

Jedna agregace může obsluhovat pouze dotazy, které přesně odpovídají jejím konkrétním dimenzím (přesná shoda) nebo podmnožině jejích dimenzí (souhrnná shoda). Databricks doporučuje vytvořit více agregovaných materializací pro různé obrazce dotazů.

Neagregovaný typ

Tento typ materializuje celý neagregovaný datový model (pole source, joins, filter a fields) pro širší pokrytí s menším dopadem na výkon ve srovnání s agregovaným typem.

Pokud platí některý z následujících typů, použijte neagregovaný typ:

• Pohled na metriky vyžaduje nákladné transformace zdroje nebo spojení tabulek.
• Vzory dotazů jsou nepředvídatelné nebo se liší.
• Všichni uživatelé dotazující se na zobrazení metrik musí vidět konzistenci v datech.

Díky neagregovaným materializovaným zobrazením se náročné operace nad zdrojovými zobrazeními a spojeními provádějí jen při aktualizaci, nikoli při každém dotazu. Pokud existují agregované i neagregované materializace, Databricks vypočítá agregované materializace z neagregované materializace. To poskytuje konzistentní stav a zabraňuje zbytečnému opakovanému přepočítávání zdroje. Neagregovaná shoda je vždy způsobilá bez ohledu na tvar dotazu, s výhradou omezení popsaných v režimu přepisu dotazu.

Neagregovaná materializace nepomůže, pokud je zdrojem přímý odkaz na tabulku bez selektivního filtru. V takovém případě nemá žádné výhody při přímém dotazování zdroje.

Další informace o tom, jak a kdy používat tyto typy materializace, najdete v tématu Výběr typu materializace pro zobrazení metrik.

Automatické přepsání dotazu

Když zadáte dotaz na zobrazení metrik, přepis dotazu automaticky nasměruje váš dotaz na nejlepší dostupnou materializaci. Používá tři strategie přepisování dotazů: přesnou shodu, souhrnnou shodu a neagregovanou shodu.

Dotaz se automaticky spustí s nejlepší materializací místo základních tabulek pomocí tohoto algoritmu.

1. Nejprve se optimalizátor dotazu pokusí o přesnou shodu.
2. Pokud neexistuje přesná shoda, optimalizátor dotazů se pokusí najít shodu po agregaci.
3. Pokud neexistuje žádná shoda souhrnu a existuje neagregovaná materializace, optimalizátor dotazů se pokusí o neagregovanou shodu.
4. Pokud neexistuje žádná neagregovaná shoda, dotaz čte přímo ze zdrojových tabulek.

Následující části popisují, jak jednotlivé strategie fungují.

Note

Materializace musí být dokončeny, než se může projevit přepsání dotazu.

Přesná shoda

Dotaz vyžaduje přesně to, co bylo v materializovaném zobrazení předpočítáno. Přepis dotazu načte uložený výsledek bez dalšího zpracování, což umožňuje rychlé získání výsledků.

Abyste splnili podmínky pro přesnou shodu:

• Výrazy dotazu GROUP BY musí přesně odpovídat dimenzím materializace.
• Metriky dotazu musí být podmnožinou metrik materializace.

Například materializace má rozměry [region, order_date] a míry [total_revenue, order_count]. Dotaz, který seskupuje podle region a order_date a požaduje total_revenue, je přesná shoda, protože dimenze jsou stejné a metrika byla předem vypočtena.

Souhrnná shoda

Dotaz vyžaduje souhrn na obecnější úrovni, než byla předem vypočtena. Optimalizátor přečte předem vypočítaný výsledek a znovu ho agreguje až na úroveň potřeb dotazu.

Abyste se kvalifikovali pro shodu rollup:

• Hrubší granularita: Dotaz seskupuje podle menšího počtu dimenzí nebo podle hrubší časové granularity než materializace.
• Všechny metriky jsou aditivní: Každá metrika, kterou váš dotaz vyžaduje, musí být taková, kterou lze správně přepočítat kombinací dílčích výsledků (například SUM z SUM nebo MAX z MAX). MEDIAN nejde sbalit, protože závisí na distribuci ve skupině.
• Všechny zúčastněné filtry musí být deterministické výrazy: Pokud váš dotaz obsahuje WHERE klauzuli, musí filtr vždy vytvořit stejný výsledek pro stejný vstup. Například WHERE region = 'US' je deterministický, ale výrazy jako rand() nebo uuid() deterministické nejsou.

Shodu rollupu nelze použít pro neaditivní míry, protože je nelze správně znovu agregovat z dílčích výsledků. Viz aditivní míry.

Například při použití stejné materializace s dimenzemi [region, order_date] a mírami [total_revenue, order_count] je dotaz, který seskupuje pouze podle region a požaduje total_revenue, shodou typu rollup. Dotaz vyžaduje méně dimenzí, než bylo materializováno, takže engine agreguje denní součty na součty na úrovni regionů.

Aditivní míry

Míra je aditivní, pokud lze její agregovaný výsledek správně přepočítat opětovnou agregací z existujících agregovaných materializací. Toto je základní požadavek na párování rollupů.

Jakákoli agregace využívající DISTINCT (například COUNT(DISTINCT), SUM(DISTINCT)) je neaditivní a nelze ji dále agregovat.

Následující funkce jsou doplňkové:

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

Na aditivní opatření se vztahují další omezení:

• Definice míry musí obsahovat přesně jednu agregační funkci. Míra, jejíž definice kombinuje více agregací (například sum(cost) + min(revenue)) nemá nárok na porovnávání souhrnů.
• Pokud definice míry obsahuje FILTER klauzuli, musí být deterministická.
• Metrika nemůže být metrikou okna (například průběžný 7denní součet nebo meziroční porovnání definované blokem okna).

Neagregovaná shoda

Dotaz neodpovídá žádné předem vypočítané agregaci, ale náročná příprava (spojení a filtry) už je hotová. Přepsání dotazu začíná z připravené datové sady neagregované materializace místo návratu ke zdrojovým tabulkám.

Pokud existuje neagregovaná materializace, tato strategie je před přechodem do zdroje vždy způsobilá jako záložní. Libovolný obrazec dotazu ho může používat, s výhradou omezení popsaných v režimu přepsání dotazu.

Například váš dotaz seskupuje podle category a požaduje unique_customers, ale žádná agregovaná materializace nezahrnuje tato pole a metriky. Existuje však neagregovaná materializace, ve které je připravena spojená a filtrovaná datová sada. Optimalizátor dotazů čte z této připravené datové sady a spouští GROUP BY category, COUNT(DISTINCT customer_id) v době dotazu namísto toho, aby znovu spojoval původní tabulky od začátku.

Ověřte, že dotaz používá materializovaná zobrazení

Existují dva způsoby, jak zkontrolovat, jestli dotaz používá materializované zobrazení:

• Spusťte EXPLAIN EXTENDED nad dotazem a zobrazí se plán dotazu. Pokud byla použita materializace, listový uzel obsahuje __materialization_mat_<pipeline ID>___metric_view_mat_ a název materializace ze souboru YAML.
• Podívejte se na profil dotazu, jak je znázorněno níže.

Životní cyklus materializace

Tato část vysvětluje, jak se materializace vytvářejí, spravují a aktualizují v průběhu jejich životního cyklu.

Vytvoření a úprava

Když vytváříte nebo upravujete zobrazení metrik (pomocí CREATEALTER, nebo Průzkumníka katalogu), definice zobrazení metrik se okamžitě aktualizuje. Materializovaná zobrazení se aktualizují asynchronně na pozadí pomocí spravovaného kanálu.

Definování nové materializace v editoru Průzkumníka katalogu:

1. Klikněte na Materializace.
2. Chcete-li nastavit plán, klikněte na Plán . Můžete vybrat intervalovou dobu nebo nastavit materializaci tak, aby běžela v určitém čase.
3. Vyberte typ. Pro každé zobrazení metrik je povolena pouze jedna neagregovaná materializace. Další informace naleznete v tématu Typy materializace pro zobrazení metrik.
4. Pomocí rozevíracího seznamu Pole vyberte pole, která mají být zahrnuta do materializace.
5. Pomocí rozevíracího seznamu Míry vyberte míry, které chcete zahrnout.

Když vytvoříte zobrazení metrik, Databricks vytvoří kanál Lakeflow a okamžitě naplánuje počáteční aktualizaci, pokud jsou specifikována materializovaná zobrazení. Zobrazení metrik zůstává dotazovatelné bez materializace tím, že se vrátíte k dotazování ze zdrojových dat.

Když upravíte zobrazení metrik, Databricks nenaplánuje nové aktualizace, pokud materializaci nepovolujete poprvé. Materializovaná zobrazení se nepoužívají k automatickému přepsání dotazů, dokud se nedokončí další plánovaná aktualizace.

Změna plánu materializace neaktivuje aktualizaci.

Bez plánu spuštění pipeline při vytvoření provede počáteční aktualizaci, ale další aktualizace je nutné spouštět ručně, jinak data zastarají. Databricks doporučuje vždy definovat plán, aby data zůstala aktuální, pokud netestujete nebo vytváříte prototypy.

Podrobné řízení chování při aktualizaci najdete v tématu Ruční aktualizace .

Kontrola podkladového kanálu

Materializace pro zobrazení metrik se implementuje pomocí kanálů Lakeflow. K kanálu se dostanete dvěma způsoby:

• V Průzkumníku katalogu: Karta Přehled pro zobrazení metrik obsahuje přímý odkaz pod nadpisem Plán aktualizace . Informace o tom, jak získat přístup k Průzkumníku katalogu, najdete v tématu Co je Průzkumník katalogu?
• Pomocí SQL: Spusťte DESCRIBE EXTENDED. Oddíl Informace o aktualizaci obsahuje odkaz na kanál a aktuální stav aktualizace.

DESCRIBE EXTENDED my_metric_view;

Příklad výstupu:

-- 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

Ruční aktualizace

Z odkazu na stránku kanálu Lakeflow můžete ručně spustit aktualizaci kanálu a aktualizovat materializace. Ruční aktualizaci můžete aktivovat také pomocí následujícího příkazu SQL:

REFRESH MATERIALIZED VIEW <metric-view-name>

Přírůstková aktualizace

Materializovaná zobrazení používají přírůstkovou aktualizaci, kdykoli je to možné, a mají stejná omezení jako standardní materializovaná zobrazení týkající se zdrojů dat a struktury plánu.

Podrobnosti o požadavcích a omezeních najdete v tématu Přírůstková aktualizace materializovaných zobrazení.

Billing

Aktualizace materializovaných zobrazení způsobuje poplatky za využití kanálů Lakeflow. Pokud chcete zjistit spotřebu jednotek DBU kanálu, přečtěte si téma Co je spotřeba DBU bezserverového kanálu?.

Známá omezení

Pro materializaci zobrazení metrik platí následující omezení:

• Zobrazení metrik, které definuje parametry, se nedá materializovat.
• Po vytvoření materializace pro zobrazení metrik nemůžete vlastníka změnit.
• Databricks nepodporuje, aby vlastníkem materializovaných zobrazení metrik byla skupina.
• Pouze strategii přesné shody lze použít pro zobrazení metrik se spojeními 1:N.