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éséhez, ami azt jelenti, hogy a rendszer minden forrásadatot beolvas és összesít egy műveletben.

Note

Egyes Azure Databricks termékek automatikusan gyorsítótáraznak 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.
    • A Unity Catalog által felügyelt Iceberg-táblák (v2 és v3). Az Iceberg v3 használata ajánlott a legjobb növekményes frissítési támogatáshoz. Lásd: Apache Iceberg v3-funkciók használata. Külföldi Iceberg táblák nem támogatottak.
  • 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

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. Azure Databricks egy költségelemzés futtatásával választja ki az olcsóbb lehetőséget 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 adattárházzal vagy szerver nélküli Lakeflow Spark deklaratív adatfolyamokkal, az Azure Databricks fokozatosan frissíti őket, amennyiben a lekérdezések támogatottak. Ha egy lekérdezés nem támogatott kifejezéseket használ, az Azure Databricks teljes újraszámítást hajt végre, 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.
WITH RECURSIVE N/A Nem. A rekurzív CTE-ket használó materializált nézetek nem jogosultak növekményes frissítésre, és visszaesnek a teljes újrakalkulációra.
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 Unity Catalog által felügyelt Iceberg-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 Azure Databricks megpróbálja észlelni, hogy egy UDF mikor módosítja a viselkedést, és teljes frissítést hajt végre. Azonban a más függvényeket vagy kódtárakat meghívó UDF-ek olyan módon módosíthatják a viselkedést, amit 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.x
Nem támogatott források Nem támogatott források Az olyan források, mint a kötetek, a külső helyek és a külföldi katalógusok nem támogatottak. Külföldi Iceberg táblák nem támogatottak. A Unity Catalog által felügyelt Iceberg-táblák 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 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 Databricks Runtime 17.3-ban és újabb verziókban érhető el.

Alapértelmezés szerint Azure Databricks 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 meghatározza, hogy az Azure Databricks végrehajt-e növekményes frissítést, mikor térhet vissza teljes frissítésre, és hogy a frissítés inkább sikertelen legyen, mint hogy teljes újraszámítást végezzen.

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öket biztosít, de elfogadható, ha Azure Databricks teljes frissítést hajt végre, ha a növekményesítés átmenetileg elérhetetlenné válik (például amikor a forrástáblán a sorkövetés ki van kapcsolva).
  • 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