Osvědčené postupy pro deklarativní kanály Lakeflow Spark

Tato stránka popisuje doporučené vzory pro navrhování, sestavování a provoz kanálů pomocí deklarativních kanálů Sparku Lakeflow. Tyto pokyny použijte při spuštění nového kanálu nebo vylepšení existujícího kanálu.

Volba správného typu datové sady

Deklarativní kanály Sparku Lakeflow nabízejí tři typy datových sad: streamovací tabulky, materializovaná zobrazení a dočasná zobrazení. Volba správného typu pro každou vrstvu kanálu se vyhne zbytečným nákladům na výpočetní prostředky a kód se snadno zdůvodní.

Streamované tabulky jsou správnou volbou pro příjem dat a streamovací transformace s nízkou latencí. Každý vstupní řádek se čte a zpracovává pouze jednou, což je činí ideální pro úlohy typu jen pro přidání, zpracování velkých objemů dat a zpracování řízené událostmi z cloudového úložiště nebo zprávové sběrnice.

Materializovaná zobrazení jsou správnou volbou pro složité transformace a analytické dotazy. Jejich výsledky jsou předem vypočítané a aktuální pomocí přírůstkové aktualizace, takže dotazy na ně jsou rychlé. Data v materializovaném zobrazení nemůžete přímo upravovat – definice dotazu řídí výstup.

Dočasná zobrazení jsou zobrazení v rámci pipeline, která organizují logiku transformace, aniž by se data ukládala do úložiště. Použijte je pro přechodné kroky, které nepotřebují vlastní tabulku.

Následující tabulka shrnuje, kdy použít jednotlivé typy:

Případ použití	Doporučený typ	Reason
Příjem dat z cloudového úložiště nebo sběrnice zpráv	Tabulka pro streamování	Zpracovává každý záznam jednou; zvládá velkoobjemové a jen doplňující úlohy.
Streamy CDC (vložení, aktualizace, odstranění)	Tabulka pro streamování	Slouží jako cíl pro seřazený příjem duplicitních APPLY CHANGES INTO dat CDC.
Komplexní agregace a spojení	Materializované zobrazení	Postupné obnovení; vyhýbá se úplnému přepočítání při každé aktualizaci.
Urychlení dotazů řídicího panelu	Materializované zobrazení	Předem vypočítané výsledky umožňují rychlejší dotazy než u nezpracovaných tabulek.
Střední transformace (žádní následní čtenáři)	Dočasné zobrazení	Uspořádá logiku kanálu bez nákladů na úložiště.

Další informace najdete v tématu Streamování tabulek, materializovaných zobrazení a konceptů deklarativních kanálů Sparku Lakeflow.

Místo imperativního MERGE použijte deklarativní CDC.

Implementace zachytávání dat změn (CDC) s imperativními příkazy SQL MERGE vyžaduje významný vlastní kód pro zpracování řazení událostí, odstranění duplicitních dat, částečné aktualizace a vývoj schématu správně. Každý z těchto obav se musí vyřešit nezávisle a výsledný kód je obtížné udržovat a testovat.

Deklarativní kanály Sparku Lakeflow poskytují APPLY CHANGES INTO příkaz (SQL) a apply_changes() funkci (Python), které zpracovávají řazení, odstranění duplicitních dat, události mimo pořadí a vývoj schématu deklarativně. Popisujete tvar změnového kanálu a cílové tabulky – pipeline zpracovává zbytek. APPLY CHANGES INTO podporuje SCD Type 1 (přepsání) i SCD Type 2 (zachování historie).

Další informace najdete v tématu Zachytávání změn dat a snímky a API AUTO CDC: Zjednodušení zachytávání změn dat pomocí pipeline.

Prosazujte kvalitu dat pomocí očekávání

Očekávání jsou pravdivé nebo nepravdivé výrazy SQL použité na každému řádku procházejícímu datovou sadou. Když řádek nesplňuje podmínku, kanál reaguje podle nakonfigurované politiky porušení. Očekávání generují metriky do protokolu událostí kanálu bez ohledu na politiku, takže můžete sledovat trendy kvality dat v průběhu času.

Zvolte zásady pro porušení.

K dispozici jsou tři zásady postupu při porušení. Vyberte ten, který odpovídá vaší toleranci pro špatná data:

• upozornění (výchozí): Záznamy, které nejsou platné, se zapisují do cílové tabulky a označí se příznakem v metrikách. Tuto zásadu použijte, když potřebujete zachytit všechna data, ale chcete mít přehled o problémech s kvalitou.
• drop: Záznamy, které nejsou platné, se před zápisem zahodí. Použijte tuto možnost, když jsou očekávané chybné řádky a nemají se šířit dále.
• selhání: Aktualizace potrubí se zastaví u prvního neplatného záznamu. Tuto možnost použijte pro kritická data, u kterých jakýkoli chybný záznam indikuje závažný nadřazený problém.

Následující příklady ukazují jednotlivé zásady použité u tabulky streamování:

SQL

-- Warn: write invalid records but track them in metrics
CREATE OR REFRESH STREAMING TABLE orders_raw (
  CONSTRAINT valid_order_id EXPECT (order_id IS NOT NULL)
) AS SELECT * FROM STREAM read_files("/volumes/raw/orders", format => "json");

-- Drop: discard invalid records before writing
CREATE OR REFRESH STREAMING TABLE orders_clean (
  CONSTRAINT non_negative_amount EXPECT (amount >= 0) ON VIOLATION DROP ROW
) AS SELECT * FROM STREAM(orders_raw);

-- Fail: stop the pipeline on any invalid record
CREATE OR REFRESH STREAMING TABLE orders_critical (
  CONSTRAINT required_customer_id EXPECT (customer_id IS NOT NULL) ON VIOLATION FAIL UPDATE
) AS SELECT * FROM STREAM(orders_clean);

Python

from pyspark import pipelines as dp

# Warn: write invalid records but track them in metrics
@dp.table
@dp.expect("valid_order_id", "order_id IS NOT NULL")
def orders_raw():
    return spark.readStream.format("cloudFiles") \
        .option("cloudFiles.format", "json") \
        .load("/volumes/raw/orders")

# Drop: discard invalid records before writing
@dp.table
@dp.expect_or_drop("non_negative_amount", "amount >= 0")
def orders_clean():
    return spark.readStream.table("orders_raw")

# Fail: stop the pipeline on any invalid record
@dp.table
@dp.expect_or_fail("required_customer_id", "customer_id IS NOT NULL")
def orders_critical():
    return spark.readStream.table("orders_clean")

Umístit neplatné záznamy do karantény

Pokud chcete zachovat vyřazené záznamy pro šetření místo jejich tichého zahození, použijte vzor karantény. Směrujte řádky, které selžou ověření, do samostatné tabulky pro streamování pomocí dvou toků: jeden, který zahodí neplatné řádky z hlavní tabulky, a druhý, který zapisuje pouze neplatné řádky do tabulky karantény. Díky tomu můžete zkoumat, opravovat a znovu zpracovávat špatná data, aniž byste kontaminovali čistou datovou sadu.

Podrobný příklad vzoru karantény najdete v tématu Doporučení k očekávání a pokročilé vzory.

Další informace o očekáváních naleznete v tématu Správa kvality dat pomocí kanálových očekávání.

Parametrizace vašich datových toků

Kanály mají výchozí nastavení katalogu a schématu, takže kód, který čte a zapisuje v rámci stejného katalogu a schématu, funguje napříč prostředími bez jakýchkoli parametrů. Pokud ale váš pipeline potřebuje odkazovat na další katalog nebo schéma — například čerpání dat ze sdíleného zdrojového katalogu, který se liší mezi vývojovým a produkčním prostředím — vyhněte se hardcodování těchto názvů přímo ve zdrojovém kódu. Místo toho je definujte jako parametry konfigurace kanálu (páry klíč-hodnota nastavené v nastavení kanálu) a odkazujte na ně v kódu. To umožňuje správné spuštění jediného základu kódu napříč prostředími prohozením hodnot parametrů.

SQL

CREATE OR REFRESH MATERIALIZED VIEW transaction_summary AS
SELECT account_id, COUNT(txn_id) AS txn_count, SUM(amount) AS total_amount
FROM ${source_catalog}.sales.transactions
GROUP BY account_id;

Python

from pyspark import pipelines as dp
from pyspark.sql.functions import count, sum

@dp.materialized_view
def transaction_summary():
    source_catalog = spark.conf.get("source_catalog")
    return spark.read.table(f"{source_catalog}.sales.transactions") \
        .groupBy("account_id") \
        .agg(
            count("txn_id").alias("txn_count"),
            sum("amount").alias("total_amount")
        )

Podrobnější informace najdete v tématu Použití parametrů s kanály.

Volba správného režimu kanálu pro každé prostředí

Režimy aktualizací pro vývoj a produkční prostředí

Kanály se spouštějí buď ve vývojovém módu aktualizace, nebo v produkčním módu aktualizace. Zvolte režim, který odpovídá vašemu cíli.

V režimu vývoje pipelina opakovaně používá dlouhotrvající cluster napříč aktualizacemi a neprovádí opakované pokusy při chybách. Tím se zrychlí cyklus iterace při vytváření a testování kódu kanálu, protože se okamžitě zobrazí podrobnosti o chybě bez čekání na restartování clusteru.

V produkčním režimu se cluster po dokončení každé aktualizace okamžitě vypne, což snižuje náklady na výpočetní prostředky. Pipeline také používá stupňované opakované pokusy, včetně restartování clusteru, pro automatické zpracování přechodných selhání infrastruktury. Pro všechna plánovaná spuštění pipeline použijte produkční režim.

Aktivované vs. režim průběžného kanálu

Aktivovaný režim zpracovává všechna dostupná data a pak se zastaví. Je to správná volba pro velkou většinu kanálů: ty, které běží podle plánu (každou hodinu, denně nebo na vyžádání) a nevyžadují aktuálnost dat v dílčí minutě.

Nepřetržitý režim udržuje cluster spuštěný a zpracovává nová data při jejich doručení. Je to vhodné jenom v případě, že váš případ použití vyžaduje latenci v rozsahu sekund do minut. Vzhledem k tomu, že nepřetržitý režim vyžaduje vždy zapnutý cluster, je výrazně dražší než aktivovaný režim.

Další informace najdete v tématu Aktivované vs. režim průběžného kanálu a konfigurace kanálů.

Použijte liquid clustering pro rozložení dat

Liquid Clustering nahrazuje statické dělení pro optimalizaci rozložení dat v tabulkách Delta. Na rozdíl od particionování, které vyžaduje, abyste si předem vybrali sloupec pro oddíl a může vést k nerovnoměrné distribuci dat, když jsou hodnoty rozloženy nerovnoměrně, liquid clustering je schopné automatického ladění, odolné vůči nerovnoměrnostem a přírůstkové – při každém spuštění se přepíšou pouze ta data, která potřebují reorganizaci.

Sloupce clusteringu můžete kdykoli změnit bez přepsání celé tabulky při vývoji vzorů dotazů.

Definujte sloupce clusteringu v definici tabulky streamování:

SQL

CREATE OR REFRESH STREAMING TABLE events
CLUSTER BY (event_date, region)
AS SELECT * FROM STREAM read_files("/volumes/raw/events", format => "parquet");

Python

from pyspark import pipelines as dp

@dp.table(cluster_by=["event_date", "region"])
def events():
    return spark.readStream.format("cloudFiles") \
        .option("cloudFiles.format", "parquet") \
        .load("/volumes/raw/events")

Pokud si nejste jisti, podle kterých sloupců seskupovat, použijte CLUSTER BY AUTO, aby Databricks automaticky vybral optimální sloupce pro clustering na základě vaší pracovní zátěže dotazů.

Další informace najdete v tématu Streamování tabulek a Použití Liquid Clusteringu pro tabulky.

Správa kanálů pomocí CI/CD a deklarativních balíčků automatizace

Správa verzí zdrojového kódu kanálu a použití deklarativních automatizačních sad ke správě nasazení napříč prostředími

Další informace najdete v tématu Vytvoření kanálu řízeného zdrojem, převod kanálu na projekt sady a použití parametrů s kanály.

Uložte kód kanálu ve správě verzí

Uložte všechny zdrojové soubory pipeline (Python a SQL) společně s konfigurací balíčku v úložišti Git. Správa verzí úplného projektu poskytuje kompletní historii změn, usnadňuje spolupráci a umožňuje ověřit změny ve vývojovém prostředí před jejich povýšením do produkčního prostředí.

Databricks doporučuje deklarativní automatizační sady pro správu tohoto pracovního postupu. Sada definuje konfiguraci kanálu v YAML společně se zdrojovým kódem a rozhraní příkazového databricks bundle řádku umožňuje ověřovat, nasazovat a spouštět kanály z terminálu nebo systému CI/CD.

Použijte cílové balíčky pro izolaci prostředí

Balíčky umožňují více cílů (například dev, staging, prod), z nichž každý má svou vlastní sadu předefinovaných názvů katalogů, politiky clusterů, adresy oznámení a další nastavení. Zkombinujte cíle balíčku s parametry procesu, abyste při nasazení vložili správné hodnoty specifické pro prostředí a udrželi tak zdrojový kód bez konstant prostředí.

Typický pracovní postup vypadá takto:

1. Vývojář pracuje ve větvi funkce a nasazuje do osobního vývojového kanálu v katalogu pro vývoj.
2. Při sloučení s hlavní větví CI systém provede databricks bundle validate a databricks bundle deploy --target staging k ověření a nasazení pipeline do přípravného prostředí.
3. Po uplynutí testování se systém CI nasadí do produkčního prostředí s databricks bundle deploy --target prod.

Osvědčené postupy streamování

Pomocí těchto vzorů můžete spravovat stav, řídit zpožděná data a udržovat kanály streamování spolehlivé.

Další informace najdete v tématu Optimalizace stavového zpracování pomocí vodoznaků, obnova pipeline po selhání kontrolního bodu streamování a doplňování historických dat pomocí pipeline.

Použijte vodoznaky pro stavové operace

Vodoznaky váží stav, který pipeline uchovává v paměti během stavových streamingových operací, jako jsou agregace s okny a odstranění duplicitních dat. Bez vodoznaku roste stav nevázaný, protože kanál shromažďuje data pro každý možný klíč a nakonec způsobuje chyby kvůli nedostatku paměti u dlouhotrvajících kanálů.

Vodoznak určuje sloupec časového razítka a hranici tolerance pro pozdní data. Záznamy, které přicházejí po uplynutí prahové hodnoty, se zahodí. Zvolte prahovou hodnotu, která vyrovnává odolnost vůči pozdním datům oproti nákladům na paměť při zachování otevřeného stavu.

Následující příklad vypočítá agregaci 1minutového přeskakujícího okna se tříminutovým vodoznakem:

SQL

CREATE OR REFRESH STREAMING TABLE event_counts AS
SELECT window(event_time, '1 minute') AS time_window, region, COUNT(*) AS cnt
FROM STREAM(events_raw)
  WATERMARK event_time DELAY OF INTERVAL 3 MINUTES
GROUP BY time_window, region;

Python

from pyspark import pipelines as dp
from pyspark.sql.functions import window

@dp.table
def event_counts():
    return (
        spark.readStream.table("events_raw")
            .withWatermark("event_time", "3 minutes")
            .groupBy(window("event_time", "1 minute"), "region")
            .count()
    )

Poznámka:

Pokud chcete zajistit, aby se agregace zpracovávaly přírůstkově, a ne plně přepočítané při každé aktualizaci, musíte definovat vodoznak.

Vysvětlení stavu streamování a úplné aktualizace

Stav streamování je přírůstkový: potrubí vytváří a udržuje stav napříč aktualizacemi, místo aby jej pokaždé znovu počítalo od začátku. To znamená, že stavové streamování je efektivní, ale také to znamená, že pokud změníte logiku stavového dotazu (například upravíte prahovou hodnotu meze nebo změníte sloupce agregace), stávající stav už nebude kompatibilní s novou logikou. V takovém případě je nutné provést úplnou aktualizaci, která znovu zpracuje všechna historická data pomocí nové logiky a znovu sestaví stav úplně od začátku.

Úplná aktualizace může také vést ke ztrátě dat, pokud zdroj neuchovává historická data. Například zdroj Kafka s krátkou dobou uchovávání může mít k dispozici pouze posledních pár minut dat v době aktualizace, což vede k tabulce, která obsahuje mnohem méně dat než dříve. Pečlivě naplánujte změny logiky stavového dotazu, zejména u velkých objemových datových proudů, kde je úplná aktualizace nákladná nebo kde zdroj má omezené uchovávání dat. Použití architektury medailonu pomáhá vytvořením bronzových tabulek s minimální transformací, umožňuje přepočítat stříbrné nebo zlaté tabulky z bronzových tabulek s úplnou historií.

Propojení stream-streamů

Spojení streamů vyžadují vodoznak na obou stranách streamu a časově ohraničenou podmínku spojení. Časový interval v podmínce spojení určuje streamovacímu enginu, kdy nejsou možné žádné další shody, což umožňuje odstranění stavu, který již nelze spárovat. Pokud vynecháte vodoznaky nebo časovou podmínku, stav se rozroste bez omezení.

Následující příklad spojí události zobrazení reklamy s událostmi kliknutí, které vyžadují, aby kliknutí probíhalo během tří minut zobrazení:

SQL

CREATE OR REFRESH STREAMING TABLE impression_clicks AS
SELECT imp.ad_id, imp.impression_time, clk.click_time
FROM STREAM(ad_impressions)
    WATERMARK impression_time DELAY OF INTERVAL 3 MINUTES AS imp
JOIN STREAM(user_clicks)
    WATERMARK click_time DELAY OF INTERVAL 3 MINUTES AS clk
ON imp.ad_id = clk.ad_id
  AND clk.click_time BETWEEN imp.impression_time
    AND imp.impression_time + INTERVAL 3 MINUTES;

Python

from pyspark import pipelines as dp
from pyspark.sql.functions import expr

dp.create_streaming_table("impression_clicks")

@dp.append_flow(target="impression_clicks")
def join_impressions_and_clicks():
    impressions = spark.readStream.table("ad_impressions") \
        .withWatermark("impression_time", "3 minutes")
    clicks = spark.readStream.table("user_clicks") \
        .withWatermark("click_time", "3 minutes")
    return impressions.alias("imp").join(
        clicks.alias("clk"),
        expr("""
            imp.ad_id = clk.ad_id AND
            clk.click_time BETWEEN imp.impression_time AND imp.impression_time + INTERVAL 3 MINUTES
        """),
        "leftOuter"
    )

Když spojíte datový proud se statickou tabulkou (tzv. spojením snímku), snímek statické tabulky se aktualizuje na začátku každé mikrodávky. To znamená, že pozdní příchod záznamů dimenzí se zpětně nepoužije na fakta, která již byla zpracována. Pokud je vyžadována retroaktivní aplikace, použijte materializované zobrazení nebo restrukturalizujte datový tok.

Optimalizace výkonu kanálu

Tyto techniky použijte ke snížení nákladů na výpočty a zrychlení aktualizací procesů.

Další informace naleznete v tématu Materializovaná zobrazení a Optimalizovat stavové zpracování pomocí vodoznaků.

Vyhněte se malým souborům

Časté spouštění pipeline u zdroje s malým objemem zapisuje velké množství malých souborů do cloudového úložiště. Malé soubory snižují výkon čtení, protože každý soubor vyžaduje samostatné vyhledávání metadat a cyklus vstupně-výstupních operací, a rozhraní API cloudového úložiště zpomalují operace výpisu při velkém rozsahu. Abyste tomu předešli, zvolte interval aktivační události, který odpovídá vašemu datovému svazku: spouštění aktivovaných kanálů podle plánu, které umožňuje smysluplné množství dat se hromadit mezi aktualizacemi, a ne nepřetržitě.

Zpracování nerovnoměrné distribuce dat

Dochází k vychýlení dat, když jsou hodnoty v klíči operace spojení (join) nebo seskupení (groupBy) nerovnoměrně rozděleny mezi oddíly, což způsobuje, že malý počet úloh zpracovává většinu dat. Tím se vytvoří hotspoty, které zvyšují koncový čas aktualizace. Pomocí liquid clusteringu můžete řešit zkreslení v uložených tabulkách. V případě zkreslení, ke kterému dochází během výpočtu v reálném čase, sůl vysoce zkreslené klíče připojením náhodné přípony kbelíku před seskupením a agregací ve dvou fázích.

Další informace najdete v tématu Použití clusteringu liquid pro rozložení dat.

Použijte přírůstkovou aktualizaci pro materializovaná zobrazení

Pokud použijete materializované zobrazení pro velkou agregaci, pokusí se deklarativní kanály Spark automaticky přírůstkově aktualizovat – zpracovávají pouze změny v předcházejících krocích od poslední aktualizace a nepřepočítávají úplnou sadu výsledků. Přírůstková aktualizace je výrazně levnější než opětovné spuštění dotazu úplně od začátku u každé aktivační události kanálu. Chcete-li maximalizovat pravděpodobnost, že materializované zobrazení lze přírůstkově aktualizovat, zapsat jednoduché, deterministické agregační dotazy a vyhnout se konstruktorům, které brání přírůstkové zpracování, jako jsou ne deterministické funkce.

Viz Přírůstková aktualizace pro materializovaná zobrazení.

Optimalizace spojení

Pro spojení, kde jednou stranou je malá dimenzní tabulka, přidejte nápovědu k vysílání, která instruuje Spark, aby tuto menší tabulku vysílal všem vykonávačům místo provádění spojení s tříděním:

SQL

CREATE OR REFRESH MATERIALIZED VIEW enriched_orders AS
SELECT o.*, /*+ BROADCAST(p) */ p.product_name, p.category
FROM orders o
JOIN products p ON o.product_id = p.product_id;

Python

from pyspark import pipelines as dp
from pyspark.sql.functions import broadcast

@dp.materialized_view
def enriched_orders():
    orders = spark.read.table("orders")
    products = spark.read.table("products")
    return orders.join(broadcast(products), "product_id")

Pro proximální spojení časových řad (například vyhledání nejbližší události v rámci časového rozsahu) použijte podmínku spojení s rozsahem a zajistěte, aby obě strany měly časový vodoznak, pokud se připojují datové proudy, nebo zvažte přidělení událostí do časových intervalů před jejich propojením.

Sledujte své datové řetězce

Protokol událostí potrubí je hlavním prvkem pozorovatelnosti v deklarativních potrubích Lakeflow Spark. Každé spuštění kanálu zapisuje strukturované záznamy do protokolu událostí, který zahrnuje průběh provádění, očekávané výsledky kvality dat, rodokmen dat a podrobnosti o chybách. Protokol událostí je tabulka Delta, kterou můžete dotazovat přímo.

Pokud chcete dotazovat protokol událostí bez znalosti základní cesty k úložišti, použijte event_log() funkci s hodnotou tabulky ve sdíleném clusteru nebo SQL Warehouse:

SELECT * FROM event_log('<pipeline-id>')
WHERE event_type = 'flow_progress'
ORDER BY timestamp DESC
LIMIT 100;

Vytvářejte řídicí panely kvality dat dotazováním protokolu událostí na očekávané metriky. Sloupec details obsahuje vnořenou strukturu JSON s počtem pass/fail pro každé omezení, které můžete použít ke sledování trendů kvality v průběhu času a upozorňování na regrese.

Pro upozorňování řízené událostmi můžete pomocí háků událostí aktivovat vlastní webhooky nebo služby oznámení (například Slack nebo PagerDuty), když kanál selže nebo dojde k porušení prahové hodnoty kvality dat. Hooky událostí jsou funkce Pythonu, které se spouští v reakci na události v rámci potrubí.

Další informace najdete v tématu Monitorování kanálů, protokolu událostí kanálu a definování vlastního monitorování kanálů pomocí hooků událostí.

Použití bezserverového výpočetního prostředí

Databricks doporučuje bezserverové výpočetní prostředky pro nové kanály. U serverless prostředí není potřeba ruční konfigurace clusteru — Databricks automaticky spravuje infrastrukturu. Bezserverové kanály využívají vylepšené automatické škálování, které může škálovat horizontálně (více exekutorů) i svisle (větší velikost exekutoru) v reakci na požadavky úloh. Kanály bez serveru vždy používají Katalog Unity, takže správa a sledování původu dat jsou ve výchozím nastavení integrované.

Další informace najdete v tématu Konfigurace bezserverového kanálu.

Uspořádejte datové toky pomocí architektury medailónu

Architektura medailonu uspořádá data do tří logických vrstev – bronzových, stříbrných a zlatých – z nichž každá má odlišný účel. Mapování typů datových sad deklarativních kanálů Sparku Lakeflow na správnou vrstvu udržuje odpovědnosti jednotlivých vrstev jasně a usnadňuje údržbu kanálů.

• Bronzová: Používejte streamované tabulky k ingestování nezpracovaných dat z cloudového úložiště, sběrnic zpráv nebo zdrojů CDC. Bronzové tabulky zachovávají nezpracovaná zdrojová data s minimální transformací, což umožňuje, aby se v případě, že se požadavky změnily, znovu zpracovávat ze zdroje ve vrstvě bronzové.
• Silver: Používejte streamované tabulky pro přírůstkové transformace na úrovni řádků (filtrování, čištění a analýza). Použijte materializovaná zobrazení, když logika silver-layer zahrnuje obohacovací spojení proti tabulkám dimenzí nebo komplexní agregace, jež těží z přírůstkové aktualizace.
• Zlato: Pomocí materializovaných pohledů můžete předpočítat agregace, výpočty a souhrny sloužící řídicím panelům, nástrojům pro vytváření sestav a následným uživatelům.

Kdykoli je to možné, oddělte ingestní (bronzové) a transformační (stříbrné a zlaté) do samostatných DAGů kanálu. Oddělení vrstev umožňuje jednotlivě naplánovat, monitorovat a řešit potíže každé vrstvy, přičemž selhání v transformačním kanálu neblokuje nový příjem dat na bronzovou vrstvu.

Další informace naleznete v tématu Streamované tabulky a Materializovaná zobrazení.