Megosztás:

Inkrementális frissítés materializált lekérdezésekhez

Ez a cikk ismerteti a materializált nézetek növekményes frissítéseinek szemantikáját és követelményeit, és azonosítja a növekményes frissítést támogató SQL-műveleteket, kulcsszavakat és záradékokat. Ismerteti a növekményes és a teljes frissítés közötti különbségeket, és javaslatokat tartalmaz a materializált nézetek és a streamelési táblák közötti választáshoz.

Ha kiszolgáló nélküli folyamatokkal futtat frissítéseket a materializált nézeteken, számos lekérdezés növekményesen frissíthető. A növekményes frissítések a materializált nézet meghatározásához használt adatforrások változásainak észlelésével és az eredmény növekményes számításával takarítják meg a számítási költségeket.

Kiszolgáló nélküli számításon futtatott frissítések

A frissítési műveletek kiszolgáló nélküli folyamatokon futnak, függetlenül attól, hogy a műveletet a Databricks SQL-ben vagy a Lakeflow Spark Deklaratív folyamataiban határozták-e meg.

A Databricks SQL használatával definiált materializált nézetek esetében a munkaterületnek nem kell engedélyeznie a kiszolgáló nélküli Lakeflow Spark Deklaratív folyamatokat. A frissítés automatikusan kiszolgáló nélküli folyamatot használ.

A Lakeflow Spark Deklaratív folyamatok használatával definiált materializált nézetek esetében a folyamatot kiszolgáló nélküli használatra kell konfigurálnia. Lásd : Kiszolgáló nélküli folyamat konfigurálása.

Milyen a materializált nézetek frissítési szemantikája?

A materializált nézetek a kötegelt lekérdezésekkel egyenértékű eredményeket garantálnak. Vegyük például a következő összesítő lekérdezést:

SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Ha ezt a lekérdezést bármely Azure Databricks-termékkel futtatja, az eredményt kötegelt szemantikával számítja ki a forrás transactions_tableösszes rekordjának összesítése érdekében, ami azt jelenti, hogy a rendszer minden forrásadatot egy műveletben vizsgál és összesít.

Note

Egyes Azure Databricks-termékek gyorsítótárazása automatikusan eredményt ad a munkameneteken belül vagy a munkamenetek között, ha az adatforrások nem változtak az utolsó lekérdezés futtatása után. Az automatikus gyorsítótárazási viselkedés eltér a materializált nézetektől.

Az alábbi példa materializált nézetté alakítja a kötegelt lekérdezést:

SQL

CREATE OR REPLACE MATERIALIZED VIEW transaction_summary AS
SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Python

@dp.materialized_view()
def transaction_summary():
  return (spark.read.table("transactions_table")
    .groupBy("account_id")
    .agg(
      count("*").alias("txn_count"),
      sum("txn_amount").alias("account_revenue")
    )
  )

Materializált nézet frissítésekor a kiszámított eredmény megegyezik a kötegelt lekérdezés szemantikájával. Ez a lekérdezés egy olyan materializált nézet példája, amely növekményesen frissíthető, ami azt jelenti, hogy a frissítési művelet mindent megtesz annak érdekében, hogy csak a forrásban lévő új vagy módosított adatokat dolgozza fel, transactions_table az eredmények kiszámításához.

Az adatforrás szempontjai a materializált nézetek esetében

Bár bármilyen adatforráshoz definiálhat materializált nézetet, nem minden adatforrás alkalmas a materializált nézetekre. Vegye figyelembe a következő kikötéseket és javaslatokat:

Important

A materializált nézetek minden erőfeszítést megtesznek a támogatott műveletek eredményeinek növekményes frissítésére. Az adatforrások egyes módosításai teljes frissítést igényelnek. A teljes frissítés futtatása helyett megadhat egy sikertelen frissítési szabályzatot .

A materializált nézetek összes adatforrásának robusztusnak kell lennie a teljes frissítés szemantikája érdekében, még akkor is, ha a materializált nézetet meghatározó lekérdezés támogatja a növekményes frissítést.

  • Azoknál a lekérdezéseknél, ahol a teljes frissítés túlságosan költséges, adatfolyam-táblák használatával garantálhatja a pontos egyszeri feldolgozást. Ilyenek például a nagyon nagy táblák.
  • Ne definiáljon materializált nézetet adatforráshoz, ha a rekordokat csak egyszer kell feldolgozni. Ehelyett használjon streamelési táblázatokat. Ilyenek például a következők:
    • Olyan adatforrások, amelyek nem őrzik meg az adatelőzményeket, például a Kafkát.
    • Betöltési műveletek, például olyan lekérdezések, amelyek az Automatikus betöltő használatával töltik be az adatokat a felhőobjektum-tárolóból.
    • Minden olyan adatforrás, ahol a feldolgozás után törölni vagy archiválni szeretné az adatokat, de az alsóbb rétegbeli táblákban meg kell őriznie az adatokat. Például egy dátumparticionált tábla, amelyben egy bizonyos küszöbértéknél régebbi rekordokat szeretne törölni.
  • Nem minden adatforrás támogatja a növekményes frissítéseket. Az alábbi adatforrások támogatják a növekményes frissítést:
    • Delta-táblák, beleértve a Unity Catalog által felügyelt táblákat és a Delta Lake által támogatott külső táblákat.
    • Materializált nézetek.
    • Streaming táblák, ideértve a AUTO CDC ... INTO műveletek céljait.
  • Egyes növekményes frissítési műveletekhez engedélyezni kell a sorkövetést a lekérdezett adatforrásokon. A sorkövetés olyan Delta Lake-funkció, amelyet csak a Delta-táblák támogatnak, amelyek materializált nézeteket, streamelő táblákat és Unity Catalog által felügyelt táblákat tartalmaznak. Lásd : Sorkövetés a Databricksben.
  • A definiált sorszűrőkkel vagy oszlopmaszkokkal rendelkező adatforrások nem támogatják a növekményes frissítést. Sorszűrők és oszlopmaszkok megtekintése

Materializált nézetek optimalizálása

A legjobb teljesítmény érdekében a Databricks a következő funkciók engedélyezését javasolja az összes materializált nézetforrástáblán:

Ezeket a funkciókat a létrehozás során vagy később is beállíthatja az ALTER TABLE utasítással (a Databricks SQL-ből futtatva). Például:

ALTER TABLE <table-name> SET TBLPROPERTIES (
  delta.enableDeletionVectors = true,
  delta.enableRowTracking = true,
  delta.enableChangeDataFeed = true);

A materializált nézetek frissítési típusai

A materializált nézet frissítésekor megadhatja, hogy egyszerű vagy teljes frissítést kér.

  • A frissítés növekményes frissítést kísérel meg végrehajtani, de szükség esetén az adatok teljes újrafordítását hajtja végre. A növekményes frissítés csak akkor érhető el, ha a csatlakoztatott számítás kiszolgáló nélküli.
  • A teljes frissítés mindig újraszámítja a materializált nézet összes bemenetét, és alaphelyzetbe állítja az összes ellenőrzőpontot.

A használt frissítés típusának meghatározásához lásd: Frissítés típusának meghatározása.

Alapértelmezett frissítés

A materializált nézet alapértelmezett frissítése a kiszolgáló nélküli környezetben növekményes frissítést próbál végrehajtani. A növekményes frissítés az utolsó frissítés után módosítja a mögöttes adatokat, majd hozzáfűzi az adatokat a táblához. Az alaptábláktól és a belefoglalt műveletektől függően csak bizonyos típusú materializált nézetek frissíthetők növekményesen. Ha növekményes frissítés nem lehetséges, vagy a csatlakoztatott számítás a kiszolgáló nélküli helyett klasszikus, a rendszer teljes újrafordítást hajt végre.

Note

Az Azure Databricks teljes vagy növekményes frissítést alkalmaz. A döntés azon alapul, hogy melyik lehetőség költséghatékonyabb, és hogy egy lekérdezés támogatja-e a növekményes frissítést. Ennek a viselkedésnek a módosításához tekintse meg a frissítési szabályzatot.

A növekményes frissítés és a teljes újraszámítás kimenete megegyezik. Az Azure Databricks egy költségelemzést futtat, amely kiválasztja az olcsóbb megoldást a növekményes frissítés és a teljes újrafordítás között.

Csak a kiszolgáló nélküli folyamatokkal frissített materializált nézetek használhatnak növekményes frissítést. A kiszolgáló nélküli adathpipelinesokat nem használó materializált nézetek mindig teljesen újraszámításra kerülnek.

Ha materializált nézeteket hoz létre egy SQL-raktárral vagy kiszolgáló nélküli Lakeflow Spark Deklaratív Pipelines-szel, az Azure Databricks inkrementálisan frissíti őket, ha a lekérdezéseket támogatják. Ha egy lekérdezés nem támogatott kifejezéseket használ, az Azure Databricks teljes újrafordítást futtat, ami növelheti a költségeket.

A használt frissítés típusának meghatározásához lásd: Frissítés típusának meghatározása.

Teljes frissítés

A teljes frissítés felülírja az eredményeket a materializált nézetben a tábla és az ellenőrzőpontok törlésével, valamint a forrásban elérhető összes adat újrafeldolgozásával.

A Databricks SQL használatával definiált materializált nézetek teljes frissítéséhez használja a következő szintaxist:

REFRESH MATERIALIZED VIEW mv_name FULL

A Lakeflow Spark Deklaratív folyamatokban definiált materializált nézetek esetében dönthet úgy, hogy teljes frissítést futtat a kijelölt adathalmazokon vagy a folyamat összes adathalmazán. Lásd folyamatfrissítés szemantikáját.

Important

Ha egy teljes frissítés olyan adatforráson fut, ahol az adatmegőrzési küszöbérték vagy a manuális törlés miatt a rekordok el lettek távolítva, az eltávolított rekordok nem jelennek meg a számított eredményekben. Előfordulhat, hogy nem tudja helyreállítani a régi adatokat, ha az adatok már nem érhetők el a forrásban. Ez a forrásadatokban már nem létező oszlopok sémáját is módosíthatja.

Materializált nézet növekményes frissítésének támogatása

Az alábbi táblázat az SQL-kulcsszó vagy záradék növekményes frissítésének támogatását sorolja fel. Ha egy adott lekérdezést szeretne tesztelni a növekményesség érdekében, használhatja EXPLAIN CREATE MATERIALIZED VIEWa következőt: .

Important

Egyes kulcsszavakhoz és záradékokhoz engedélyezni kell a sorkövetést a lekérdezett adatforrásokon. Lásd : Sorkövetés a Databricksben.

Ezek a kulcsszavak és záradékok csillaggal (*) vannak megjelölve az alábbi táblázatban.

SQL-kulcsszó vagy záradék PySpark-adatkeret egyenértékű Növekményes frissítés támogatása
SELECT Kifejezések* df.select() vagy df.selectExpr() Igen, a determinisztikus beépített függvényeket és a nem módosítható, felhasználó által definiált függvényeket (UDF-eket) tartalmazó kifejezések támogatottak.
GROUP BY df.groupBy().agg() Yes
WITH Adatkeret változóinak láncolása. Igen, a gyakori táblakifejezések támogatottak.
UNION ALL* df.union vagy df.unionAll Yes
FROM df = spark.read... A támogatott alaptáblák közé tartoznak a Delta-táblák, a materializált nézetek és a streamelési táblák.
WHERE, HAVING* \, \, \ Olyan szűrő záradékok, mint például WHERE és HAVING, támogatottak.
INNER JOIN* df.join() Yes
LEFT OUTER JOIN* df.join(... how="left") Yes
FULL OUTER JOIN* df.join(... how="full") Yes
RIGHT OUTER JOIN* df.join(... how="right") Yes
OVER df.over(window.partitionBy) függvények Yes. Az ablakfüggvények inkrementalizálásához meg kell adni a PARTITION_BY oszlopokat.
QUALIFY df.over(w).filter(...) Yes
EXPECTATIONS @dp.expect Igen, az elvárásokat tartalmazó materializált nézetek növekményesen frissíthetők. A növekményes frissítés azonban nem támogatott a következő esetekben:
  • Amikor a materializált nézet elvárásokat tartalmazó nézetből olvas.
  • Ha a materializált nézet DROP elvárást tartalmaz, és NOT NULL oszlopokat foglal magában a sémájában.
UDFs UDFs Az Azure Databricks megpróbálja észlelni, hogy egy UDF mikor változtatja meg a viselkedést, és teljes frissítést hajt végre. A más függvényeket vagy kódtárakat meghívó UDF-ek azonban úgy módosíthatják a viselkedést, hogy az Azure Databricks nem ismeri fel. Amikor egy UDF viselkedése megváltozik, az Ön felelőssége, hogy teljes frissítést végezzen a frissített UDF teljes materializált nézetre való alkalmazásához.
Nem determinisztikus függvények Nem determinisztikus függvények A nem determinisztikus időfüggvényeket a záradékok támogatják WHERE . Ide tartoznak az olyan függvények, mint a current_date(), current_timestamp()és now()a . Más nem determinisztikus függvények nem támogatottak.
Nem delta források Nem delta források Az olyan források, mint a kötetek, a külső helyek és a külföldi katalógusok nem támogatottak.

Frissítés típusának meghatározása

A materializált nézetfrissítések teljesítményének optimalizálásához az Azure Databricks költségmodellt használ a frissítéshez használt technika kiválasztásához. Az alábbi táblázat a következő technikákat ismerteti:

Technique Növekményes frissítés? Description
FULL_RECOMPUTE No A materializált nézet teljesen újraszámítva lett
NO_OP Nem alkalmazható A materializált nézet nem frissült, mert a rendszer nem észlelt módosításokat az alaptáblában.
Bármelyik:
  • ROW_BASED
  • PARTITION_OVERWRITE
  • WINDOW_FUNCTION
  • APPEND_ONLY
  • GROUP_AGGREGATE
  • GENERIC_AGGREGATE
 Yes A materializált nézet növekményesen frissült a megadott technikával.

Lásd még: Frissítési szabályzat.

A technika meghatározásához, amelyet használtak, kérdezze le a Lakeflow Spark Deklaratív csővezetékek eseménynaplóját, ahol a event_type értéke planning_information.

SELECT
  timestamp,
  message
FROM
  event_log(TABLE(<fully-qualified-table-name>))
WHERE
  event_type = 'planning_information'
ORDER BY
  timestamp desc;

Cserélje le <fully-qualified-table-name> a materializált nézet teljes kvalifikált nevére, beleértve a katalógust és a sémát is.

Mintakimenet ehhez a parancshoz:

timestamp üzenet
2025-03-21T22:23:16.497+00:00 Flow 'sales' has been planned in :re[LDP] to be executed as ROW_BASED.

Lásd a folyamat eseménynaplóját.

Szabályzat frissítése

Important

Ez a funkció bétaverzióban érhető el. A munkaterület rendszergazdái az Előnézetek lapon szabályozhatják a funkcióhoz való hozzáférést. Lásd: Az Azure Databricks előzetes verziójának kezelése.

Az Azure Databricks alapértelmezés szerint automatikusan kiválasztja a legköltséghatékonyabb – növekményes vagy teljes – frissítési stratégiát a lekérdezési struktúra, az adatváltozás mennyisége és a rendszerköltség-modellezés alapján. Ez az alapértelmezett viselkedés manuális konfigurálás nélkül optimalizálja a frissítési teljesítményt.

Egyes számítási feladatok azonban kiszámíthatóbb vagy explicit módon szabályozott frissítési viselkedést igényelnek. Ezeknek a forgatókönyveknek a támogatásához megadhatja a REFRESH POLICY a materializált nézet definíciójában. A frissítési szabályzat szabályozza, hogy az Azure Databricks növekményes frissítést hajt-e végre, mikor lehet vissza a teljes frissítésre, és hogy a frissítés sikertelen legyen-e a teljes újrafordítás végrehajtása helyett.

A használatával REFRESH POLICYkonfigurálhatja a rendszert a következőre:

  • AUTO (alapértelmezett) – Automatikus, költségalapú kijelölés használata. A Databricks a hatékonyság és a lekérdezési képességek alapján növekményes vagy teljes frissítést választ. A legtöbb felhasználó számára ajánlott.
  • INCREMENTAL – A növekményes frissítés előnyben részesítése. A Databricks lehetőség szerint növekményes frissítést végez. Ha a lekérdezési terv már nem támogatja a növekményes frissítést, visszatér a teljes frissítéshez.
  • INCREMENTAL STRICT - Szigorúan igényel növekményes frissítést. A normál művelet során inkrementális frissítés szükséges. Ha a növekményesítés nem lehetséges, a frissítési vagy létrehozási művelet meghiúsul.
  • FULL – Mindig végezzen teljes frissítést. A Databricks soha nem végez növekményes frissítést, még akkor sem, ha a lekérdezés növekményes.

SQL

-- Create a materialized view with an incremental refresh policy
CREATE MATERIALIZED VIEW IF NOT EXISTS my_mv
REFRESH POLICY INCREMENTAL
AS SELECT a, sum(b) FROM my_catalog.example.my_table GROUP BY a;

Python

from pyspark import pipelines as dp

@dp.materialized_view(
  refresh_policy = 'incremental_strict'
)
def my_mv():
  return spark.read("main.default.source_table")

Az optimális frissítési szabályzat a számítási feladatok jellemzőitől függ:

  • AUTO a legtöbb számítási feladathoz megfelelő. Kiegyensúlyozza a költségeket és a teljesítményt, és automatikusan alkalmazkodik a lekérdezési viselkedés változásaihoz.
  • INCREMENTAL akkor hasznos, ha a növekményes frissítés előnyökkel jár, de az Azure Databricks számára elfogadható a teljes frissítés, ha a növekményesítés ideiglenesen elérhetetlenné válik (például ha a sorkövetés ki van kapcsolva egy forrástáblán).
  • INCREMENTAL STRICT akkor kell használni, ha növekményes frissítésre van szükség a költség-, teljesítmény- vagy SLA-korlátozások teljesítéséhez, és a váratlan teljes frissítés elfogadhatatlan. Ez a szabályzat akkor ajánlott, ha a felhasználók a frissítés sikertelenségét részesítik előnyben, így a teljes frissítés helyett hibakeresést végezhetnek.
  • FULL akkor megfelelő, ha a növekményes frissítés kevés előnnyel jár, az adathalmaz kicsi, vagy a lekérdezési struktúra gyakran változik a növekményesítést megakadályozó módon.

További részletekért és szintaxisért lásd a REFRESH POLICY záradékot (adatcsatornákat), vagy, ha az adathalmaz a Databricks SQL-ben van definiálva, REFRESH a POLICY záradékot.

  • Last updated on