Önálló materializált nézetek használata

A független materializált nézetek előre kiszámítják és gyorsítótárban tárolják a lekérdezések eredményeit a teljesítmény javítása, valamint az adatfeldolgozási és elemzési munkaterhelések költségeinek csökkentése érdekében.

Önálló materializált nézeteket hozhat létre és frissíthet egy Databricks SQL-raktárból vagy egy kiszolgáló nélküli általános számításon futó jegyzetfüzetből. A két számítási lehetőség közötti különbségekkel kapcsolatos részletekért lásd az önálló folyamatokra vonatkozó követelményeket.

Ha egy jegyzetfüzetből, Python használatával szeretne önálló materializált nézeteket létrehozni és frissíteni, tekintse meg a Python használata önálló folyamatokkal című cikket.

Mik azok az önálló materializált nézetek?

Az önálló materializált nézet egy Unity Catalog által felügyelt tábla, amely fizikailag tárolja a Lakeflow-folyamaton kívül definiált lekérdezések eredményeit. A standard nézetekkel ellentétben, amelyek igény szerint kiszámítják az eredményeket, a materializált nézetek gyorsítótárazják az eredményeket, és frissítik őket az alapul szolgáló forrástáblák változásával, akár ütemezés szerint, akár automatikusan.

A materializált nézetek jól alkalmasak előre kiszámított eredmények irányítópultok és jelentések számára való biztosítására, valamint olyan transzformációkhoz, amelyek tisztítják, gazdagítják és denormalizálják az alaptáblákat. A drága vagy gyakran használt lekérdezések előkiszámításával a materializált nézetek csökkentik a lekérdezések késleltetését és az erőforrás-fogyasztást. Sok esetben növekményesen kiszámíthatják a forrástáblák változásait, így tovább javíthatják a hatékonyságot és a végfelhasználói élményt.

A batch extract, transform and load (ETL) munkaterheléseknél, amelyek időszakosan felülírnak egy időablakot vagy partíciót, például javítások, későn érkező adatok vagy megfelelőségi törlések, használjunk helyette REPLACE WHERE folyamatot . Lásd, mikor érdemes REPLACE WHERE vagy materializált nézeteket használni.

A materializált nézetek gyakori használati esetei a következők:

  • A BI irányítópult naprakészen tartása minimális végfelhasználói lekérdezési késedelemmel.
  • Összetett, rétegzett átalakítások létrehozása.
  • Minden olyan használati eset, amely konzisztens teljesítményt igényel up-to-date megállapításokkal.

Amikor materializált nézetet hoz létre egy Databricks SQL Warehouse-ban, egy kiszolgáló nélküli folyamat jön létre a létrehozás feldolgozásához és a materializált nézetre való frissítéshez. A katalóguskezelőben figyelheti a frissítési műveletek állapotát. Lásd: Részletek megtekintése a következővel DESCRIBE EXTENDED: .

Követelmények

Az önálló materializált nézetek létrehozására, frissítésére és lekérdezésére vonatkozó számítási lehetőségekről, engedélyekről és egyéb követelményekről az önálló folyamatokra vonatkozó követelmények című témakörben olvashat.

A materializált nézetek használatára vonatkozó egyéb korlátozásokról a Korlátozások című témakörben olvashat.

Materializált nézet létrehozása

Az önálló materializált nézetműveletek CREATE a Databricks SQL Warehouse használatával hoznak létre és töltenek be adatokat a materializált nézetben. A materializált nézet létrehozása szinkron művelet, ami azt jelenti, hogy a CREATE MATERIALIZED VIEW parancs blokkolódik, amíg a materializált nézet létre nem jön, és a kezdeti adatbetöltés be nem fejeződik. A rendszer automatikusan létrehoz egy kiszolgáló nélküli folyamatot minden önálló materializált nézethez. A materializált nézet frissítésekor a folyamat feldolgozza a frissítést.

Materializált nézet létrehozásához használja az utasítást CREATE MATERIALIZED VIEW . Létrehozási utasítás elküldéséhez használja az SQL-szerkesztőt az Azure Databricks felhasználói felületén, a Databricks SQL CLI-ben vagy a Databricks SQL API-ban.

A materializált nézetet létrehozó felhasználó a materializált nézet tulajdonosa.

Alkalmi materializált nézet

Az alábbi példa létrehozza a materializált nézetet mv1 az alaptáblából base_table1:

-- This query defines the materialized view:
CREATE OR REPLACE MATERIALIZED VIEW mv1
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

Trigger által vezérelt materializált nézet

Az alábbi példa egy materializált nézetet hoz létre, amely automatikusan frissül, amikor a felsőbb rétegbeli forrásadatok megváltoznak a használatával TRIGGER ON UPDATE. Ezt a megközelítést éles számítási feladatokhoz használhatja, különösen akkor, ha a felsőbb rétegbeli függőségek nem kiszámítható ütemezés szerint futnak.

-- Refresh automatically when the source table is updated.
CREATE OR REPLACE MATERIALIZED VIEW mv_trigger
  TRIGGER ON UPDATE
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

Ütemezett materializált nézet

Az alábbi példa egy materializált nézetet hoz létre, amely napi CRON-frissítési ütemezéssel rendelkezik 3:30 (UTC) időpontban. A záradékban szereplő SELECT kifejezéseknek és összesítéseknek aliasokat kell használniuk. GROUP BY az oszlophivatkozások nem igényelnek aliasokat.

-- Refresh nightly at 3:30 AM UTC.
-- The cron expression uses six space-separated fields: seconds minutes hours day-of-month month day-of-week
-- Use '?' for either day-of-month or day-of-week to leave it unspecified.
CREATE OR REPLACE MATERIALIZED VIEW daily_revenue_by_region
  SCHEDULE CRON '0 30 3 * * ?' AT TIME ZONE 'UTC'
AS SELECT
  date_trunc('day', order_time) AS sales_date,
  region,
  sum(revenue) AS total_revenue,
  count(*) AS order_count
FROM
  orders
GROUP BY sales_date, region;

További ütemezési lehetőségek, például SCHEDULE EVERY szintaxis és további CRON-példák: Frissítés ütemezése.

Amikor az CREATE OR REPLACE MATERIALIZED VIEW utasítással materializált nézetet hoz létre, a kezdeti adatfrissítés és betöltés azonnal megkezdődik. Ez nem használja fel az SQL Warehouse számítását. Ehelyett egy kiszolgáló nélküli folyamatot használnak a létrehozáshoz és az azt követő frissítésekhez. Lásd : Hogyan frissülnek az önálló materializált nézetek?.

Az alaptáblán lévő oszlopbejegyzések automatikusan propagálásra kerülnek az új materializált nézetbe csak a létrehozás során. Ütemezés, táblakorlátozások vagy egyéb tulajdonságok hozzáadásához módosítsa a materializált nézetdefiníciót (az SQL-lekérdezést).

Ugyanazon SQL-utasítás frissíti a materializált nézetet, ha azt ismételten végrehajtják, vagy ütemezés szerint. Az ily módon végrehajtott frissítés bármely más frissítésként működik. További részletekért lásd : Materializált nézet frissítése.

A materializált nézetek konfigurálásáról további információt az önálló materializált nézetek konfigurálása című témakörben talál. A materializált nézet létrehozásának teljes szintaxisát lásd: CREATE MATERIALIZED VIEW. Az adatok különböző formátumokban és különböző helyekről való betöltéséről további információt az adatok betöltése folyamatokban című témakörben talál.

Adatok betöltése külső rendszerekből

A támogatott adatforrások esetében a Lakehouse Federation használatával materializált nézetek hozhatók létre külső adatokon. A Lakehouse Federation által nem támogatott forrásokból származó adatok betöltéséről további információt az Adatformátum beállításai című témakörben talál. Az adatok betöltésével kapcsolatos általános információk, például példák: Adatok betöltése folyamatokban.

Bizalmas adatok elrejtése

A materializált nézetek használatával elrejtheti a bizalmas adatokat a táblához hozzáférő felhasználók elől. Ennek egyik módja a lekérdezés létrehozása anélkül, hogy az első körben ezeket az adatokat tartalmazná. A lekérdezési felhasználó engedélyei alapján azonban maszkolhatja az oszlopokat vagy szűrheti a sorokat. Elrejtheti például a tax_id csoportban HumanResourcesDeptnem szereplő felhasználók oszlopát. Ehhez használja a ROW FILTER és MASK szintaxist a materializált nézet létrehozása során. További információ: Sorszűrők és oszlopmaszkok.

Materializált nézet frissítése

A materializált nézet frissítése frissíti a nézetet, hogy az tükrözze az alaptábla frissítéskor történt legutóbbi módosításait.

A materializált nézet definiálásakor az CREATE OR REPLACE MATERIALIZED VIEW utasítás a nézet létrehozásához és az ütemezett frissítésekhez is használható. Az utasítással REFRESH MATERIALIZED VIEW frissítheti a materializált nézetet anélkül, hogy újra meg kellene adnia a lekérdezést. A parancs SQL-szintaxisáról és paramétereiről részletesen a REFRESH (MATERIALIZED VIEW vagy STREAMING TABLE) olvashat. A növekményesen frissíthető materializált nézetek típusairól további információt a materializált nézetek növekményes frissítése című témakörben talál.

Frissítési utasítás elküldéséhez használja az SQL-szerkesztőt az Azure Databricks felhasználói felületén, egy SQL-raktárhoz csatolt jegyzetfüzetet, a Databricks SQL CLI-t vagy a Databricks SQL API-t.

A tulajdonos és bármely felhasználó, aki megkapta a REFRESH jogosultságot a táblában, frissítheti a materializált nézetet.

Az alábbi példa frissíti a mv1 materializált nézetet:

REFRESH MATERIALIZED VIEW mv1;

A művelet alapértelmezés szerint szinkron, ami azt jelenti, hogy a parancs megáll, amíg a frissítési művelet be nem fejeződik. Aszinkron módon történő frissítéshez adja hozzá a kulcsszót.

REFRESH MATERIALIZED VIEW mv1 ASYNC;

A frissítések ütemezéséről további információt a Frissítések ütemezése című témakörben talál.

Hogyan frissülnek az önálló materializált nézetek?

A materializált nézetek automatikusan kiszolgáló nélküli folyamatokat hoznak létre és használnak a frissítési műveletek feldolgozásához. A frissítést a folyamat felügyeli, a frissítést pedig a materializált nézet létrehozásához használt Databricks SQL Warehouse figyeli. A materializált nézetek ütemezés szerint futó folyamattal frissíthetők. Az önálló materializált nézetek csak aktivált módban futnak. Lásd: Indított és folyamatos folyamatmód.

Az ütemezett frissítések frissítési értesítéseket tartalmazhatnak, és beállíthatja a frissítés teljesítménymódot .

Növekményes frissítés

A materializált nézetek két módszer egyikével frissülnek.

  • Növekményes frissítés – A rendszer kiértékeli a nézet lekérdezését, hogy azonosítsa az utolsó frissítés után történt változásokat, és csak az új vagy módosított adatokat egyesítse.
  • Teljes frissítés – Ha egy növekményes frissítés nem hajtható végre, vagy nem költséghatékony, a rendszer a teljes lekérdezést futtatja, és a materializált nézetben lévő meglévő adatokat lecseréli az új eredményekre.

A lekérdezés szerkezete és a forrásadatok típusa határozza meg, hogy támogatott-e a növekményes frissítés. A növekményes frissítés támogatásához a forrásadatokat Delta-táblákban kell tárolni, és engedélyezve van a sorkövetés. A változásadatcsatorna engedélyezése a jobb növekményes frissítési teljesítmény érdekében ajánlott. Annak megtekintéséhez, hogy egy lekérdezés növekményes-e, használja a Databricks SQL-utasítást EXPLAIN CREATE MATERIALIZED VIEW . A materializált nézet létrehozása után figyelheti annak frissítési viselkedését annak ellenőrzéséhez, hogy a nézet növekményesen vagy teljes frissítéssel frissül-e.

Az Azure Databricks alapértelmezés szerint költségmodellt használ a teljes és a növekményes frissítés közötti költséghatékonyabb lehetőség kiválasztásához. Ezt a viselkedést felülbírálhatja a növekményes vagy teljes frissítések előnyben részesítéséhez a materializált nézet SQL-definíciójának beállításával REFRESH POLICY .

A frissítéstípusokról és a növekményes frissítésekre való optimalizálásról további információt a materializált nézetek növekményes frissítése című témakörben talál.

Aszinkron frissítések

Alapértelmezés szerint a frissítési műveletek szinkron módon lesznek végrehajtva. A frissítési műveletet aszinkron módon is beállíthatja. Ezt a frissítési paranccsal állíthatja be a ASYNC kulcsszóval. Lásd REFRESH : (MATERIALIZED VIEW vagy STREAMING TABLE). Az egyes megközelítésekhez társított viselkedés a következő:

  • Szinkron: A szinkron frissítés megakadályozza, hogy más műveletek folytassanak a frissítés befejezéséig. Ha az eredményre a következő lépéshez van szükség, például a frissítési műveletek vezénylési eszközökben, például a Lakeflow Jobsban történő szekvenálásakor, használjon szinkron frissítést. A materializált nézetek feladattal való vezényléséhez használja az SQL-feladat típusát. Lásd Lakeflow Jobs.
  • Aszinkron: Az aszinkron frissítés egy háttérfeladatot indít el a kiszolgáló nélküli számításban, amikor egy materializált nézet frissítése megkezdődik, így a parancs az adatbetöltés befejeződése előtt visszatérhet. Ez a frissítési típus költségmegtakarítást okozhat, mert a művelet nem feltétlenül rendelkezik számítási kapacitással abban a raktárban, ahol a parancsot kezdeményezik. Ha a frissítés tétlenné válik, és más feladatok nem futnak, a raktár leállhat, miközben a frissítés más rendelkezésre álló számítást használ. Az aszinkron frissítések emellett több művelet párhuzamos indítását is támogatják.

Rekordok végleges törlése materializált nézetből, engedélyezett törlési vektorokkal

Important

A REORG utasítás támogatása materializált nézetekkel a nyilvános előzetes verzió.

Note

  • A materializált nézettel rendelkező REORG utasítás használatához a Databricks Runtime 15.4-et vagy újabb verzióját kell használni.
  • Bár az REORG utasítást bármilyen materializált nézetben használhatja, csak akkor szükséges, ha rekordokat töröl egy materializált nézetből, és engedélyezve vannak a törlési vektorok . A parancsnak nincs hatása, ha materializált nézettel használja a törlési vektorok engedélyezése nélkül.

Ha a materializált nézet alapjául szolgáló tárolóból fizikailag törölni szeretné a rekordokat, és engedélyezve van a törlési vektorok(például a GDPR-megfelelőség), további lépéseket kell tenni annak biztosítása érdekében, hogy a VACUUM művelet a materializált nézet adatain fusson.

Rekordok fizikai törlése:

  1. Futtasson egy REORG utasítást a materializált nézet ellen, megadva a APPLY (PURGE) paramétert. Például: REORG TABLE <materialized-view-name> APPLY (PURGE);. Lásd: REORG TABLE.
  2. Várja meg, amíg a materializált nézet adatmegőrzési ideje eltelik. Az alapértelmezett adatmegőrzési időszak hét nap, de konfigurálható a delta.deletedFileRetentionDuration táblatulajdonság használatával. Lásd: Adatmegőrzés konfigurálása időutazásos lekérdezésekhez.
  3. REFRESH a materializált nézet. Lásd Materializált nézet frissítése. A művelet után 24 órán belül a rendszer automatikusan futtatja a REFRESH folyamatkarbantartási feladatokat, beleértve a VACUUM rekordok végleges törléséhez szükséges műveletet is.

Materializált nézet törlése

Note

A materializált nézet elvetésére vonatkozó parancs elküldéséhez a materializált nézet tulajdonosának kell lennie, vagy MANAGE jogosultsággal kell rendelkeznie a materializált nézetben.

Materializált nézet elvetéséhez használja a DROP VIEW utasítást. A DROP utasítás elküldéséhez használhatja az SQL-szerkesztőt a Azure Databricks felhasználói felületén, a Databricks SQL CLI vagy a Databricks SQL API. Az alábbi példa elveti a mv1 materializált nézetet:

DROP MATERIALIZED VIEW mv1;

A Katalógus Explorerrel is törölhet egy materializált nézetet.

  1. Kattintson az Adatok ikonra.Katalógus az oldalsávon.
  2. A katalógusböngésző bal oldali katalógusfában nyissa meg a katalógust, és válassza ki azt a sémát, amelyben a materializált nézet található.
  3. Nyissa meg a Táblák elemet a kiválasztott séma alatt, és kattintson a materializált nézetre.
  4. A kebab menü Kebab menü ikonján válassza a Törlés lehetőséget.

A materializált nézet költségeinek megismerése

A CREATE MATERIALIZED VIEW vagy REFRESH MATERIALIZED VIEW futtatásakor Azure Databricks automatikusan létrehoz és futtat egy kiszolgáló nélküli folyamatot a művelet feldolgozásához. Ez a folyamat független attól a Databricks SQL-raktártól vagy számítási erőforrástól, amelyről a parancsot elküldte. A raktár klasztermérete nem korlátozza a frissítés által használt számítási kapacitást vagy költséget.

  • A frissítési folyamat kiszolgáló nélküli számításon fut, kiszolgáló nélküli Lakeflow-folyamatok dbU-jaként számlázva.
  • A kiszolgáló nélküli folyamat elkülönül a raktártól. A raktárból származó számítás csak a művelet koordinálására szolgál, az adatfeldolgozásra nem.
  • A költség a feldolgozott adatok mennyiségével skálázható, nem az SQL Warehouse méretével.
  • A Materialized nézet frissítési költségeinek monitorozásához használjon rendszertáblákat. Lásd : Mi a materializált nézet vagy streamelési tábla DBU-felhasználása?.
  • A materializált nézetet kezelő mögöttes folyamat megtekintése:
    1. Kattintson az Feladatok & Folyamatok lehetőségre az Azure Databricks munkaterület balra lévő oldalsávjában.
    2. Kattintson a Folyamat típusa elemre. Ezután válassza az MV/ST lehetőséget az önálló materializált nézetek megtekintéséhez.

Note

A kiszolgáló nélküli számítási díjak akkor is felmerülhetnek, ha az eredeti raktár dedikált számítást használ.

Sorkövetés engedélyezése

A Delta-táblák növekményes frissítéseinek támogatásához engedélyezni kell a sorkövetést ezekhez a forrástáblákhoz. Ha újra létrehoz egy forrástáblát, újra engedélyeznie kell a sorkövetést.

Az alábbi példa bemutatja, hogyan engedélyezheti a sorkövetést egy táblán:

ALTER TABLE source_table SET TBLPROPERTIES (delta.enableRowTracking = true);

További részletekért lásd a sorok nyomon követése az Azure Databricksben

Korlátozások

  • A számítási lehetőségekről és a munkaterületre vonatkozó követelményekről lásd az önálló folyamatok követelményeit.
  • A növekményes frissítési követelményekkel kapcsolatban lásd a materializált nézetek növekményes frissítését.
  • A materializált nézetek nem támogatják az identitásoszlopokat és a helyettesítő kulcsokat.
  • Ha egy materializált nézet egy olyan oszlopon használ összegösszesítést, amely NULL-able, és az oszlopban csak NULL értékek maradnak, akkor a materializált nézet eredményül kapott összesített értéke nulla lesz NULL helyett.
  • Nem lehet módosító adatfolyamot olvasni egy materializált nézetből, hacsak nem engedélyezed a változásadat adatfolyamot minden olyan materializált nézeten, ahol szükség van rá. Lásd: Olvasd el a változásadatfolyamot materializált nézetből (Beta).
  • Az időutazási lekérdezések nem támogatottak materializált nézetekben.
  • A materializált nézeteket támogató mögöttes fájlok tartalmazhatnak olyan felsőbb rétegbeli táblákból származó adatokat (beleértve a személyazonosításra alkalmas adatokat is), amelyek nem jelennek meg a materializált nézetdefinícióban. Ezeket az adatokat a rendszer automatikusan hozzáadja a mögöttes tárolóhoz, hogy támogassa a materializált nézetek növekményes frissítését. Mivel a materializált nézet alapjául szolgáló fájlok a materializált nézet sémájának nem részét képező felsőbb rétegbeli táblákból származó adatok feltárását kockáztathatják, a Databricks azt javasolja, hogy ne ossza meg az alapul szolgáló tárolót a nem megbízható alsóbb rétegbeli felhasználókkal. Tegyük fel például, hogy egy materializált nézet definíciója tartalmaz egy záradékot COUNT(DISTINCT field_a) . Annak ellenére, hogy a materializált nézetdefiníció csak az összesítő záradékot COUNT DISTINCT tartalmazza, a mögöttes fájlok tartalmazzák a tényleges értékek field_alistáját.
  • Előfordulhat, hogy kiszolgáló nélküli számítási költségek merülnek fel, még akkor is, ha ezeket a funkciókat dedikált számításon használja.
  • Ha Azure Private Link-kapcsolatot kell használnia a materializált nézettel, forduljon a Databricks képviselőjéhez.

Külső ügyfelek materializált nézeteinek elérése

Ha olyan külső Delta Lake- vagy Iceberg-ügyfelekről szeretne materializált nézeteket elérni, amelyek nem támogatják a nyitott API-kat, használhat kompatibilitási módot. A kompatibilitási mód létrehozza a materializált nézet írásvédett verzióját, amely bármely Delta Lake- vagy Iceberg-ügyfél számára elérhető.

További erőforrások