Teljesítményre vonatkozó irányelvek a Fabric Data Warehouse

A következőre vonatkozik:✅ Microsoft Fabric raktár

Ez a cikk ajánlott eljárásokat tartalmaz az adatbetöltéshez, a táblakezeléshez, az adat-előkészítéshez, a statisztikákhoz és a lekérdezésekhez a raktárakban és az SQL Analytics-végpontokban. A teljesítmény finomhangolása és optimalizálása egyedi kihívásokat jelenthet, de értékes lehetőségeket is kínál az adatmegoldások képességeinek maximalizálásához.

Jótanács

A Delta-táblázatoptimalizálási stratégiákkal kapcsolatos átfogó, számítási feladatok közötti útmutatásért, beleértve a Spark által írt táblákra vagy a Fabric Data Warehouse által használt tükrözésekre vonatkozó javaslatokat, tekintse meg a Cross-számítási feladatok táblakarbantartását és optimalizálását.

A raktár teljesítményének figyeléséhez lásd: Monitor Fabric Data warehouse.

Lekérdezési teljesítmény

statisztika

A statisztikák olyan tartós objektumok, amelyek a táblák oszlopaiban lévő adatokat jelölik. A Lekérdezésoptimalizáló statisztikák segítségével választja ki és becsüli meg a lekérdezéstervek költségeit. A Fabric Data Warehouse és a Lakehouse SQL Analytics-végpontok hisztogramstatisztikákat, átlagos oszlophossz-statisztikákat és tábla számosságstatisztikákat használnak és kezelnek automatikusan. További információ: Statistics in Fabric Data Warehouse.

  • A CREATE STATISTICS és UPDATE STATISTICS T-SQL parancsok támogatottak az egyoszlopos hisztogram-statisztikákhoz. Ezeket akkor használhatja, ha elég nagy az idő a táblaátalakítások és a lekérdezési számítási feladatok között, például karbantartási időszak vagy egyéb állásidő alatt. Ez csökkenti annak a valószínűségét, hogy a SELECT lekérdezéseknek először frissíteniük kell a statisztikákat.
  • Próbáljon meg olyan táblázatsémát definiálni, amely megőrzi az adattípus-paritást a gyakori oszlop-összehasonlításokban. Ha például tudja, hogy az oszlopok gyakran lesznek összehasonlítva egy WHERE záradékban egymással, vagy predikátumként JOIN ... ON használják, győződjön meg arról, hogy az adattípusok egyeznek. Ha nem lehet pontosan ugyanazokat az adattípusokat használni, használjon hasonló adattípusokat, amelyek kompatibilisek az implicit konverzióhoz. Kerülje a explicit adatkonvertálást. További információ: Adattípus-átalakítás.

Jótanács

A Lakehouse-felhasználók számára a ACE-Cardinality statisztikája pontosabban használhatja a táblák Delta-naplófájljaiból származó információkat. Győződjön meg arról, hogy a Spark által létrehozott Delta-táblák tartalmazzák a következő táblázatsorok számát: spark.conf.set("spark.databricks.delta.stats.collect", "true"). További információ: Automatizált táblastatisztikák konfigurálása és kezelése a Fabric Sparkban.

Ha az Apache Spark 3.5.0-s futtatókörnyezet előtti időbélyegoszlopon szűri a lakehouse-táblákat, a rendszer nem hozza létre az időbélyegoszlopok sorcsoportszintű statisztikáit. A statisztikák hiánya megnehezíti a rendszerek, például a Fabric Warehouse számára a sorcsoportok eltávolításának alkalmazását (más néven adatkiugrást vagy predikátumleküldést), ami olyan teljesítményoptimalizálás, amely kihagyja az irreleváns sorcsoportokat a lekérdezés végrehajtása során. Ezen statisztikák nélkül előfordulhat, hogy az időbélyegoszlopokat tartalmazó lekérdezések szűréséhez több adatot kell beolvasni, ami jelentős teljesítménycsökkenéshez vezet. A Fabricben frissítheti az Apache Spark-futtatókörnyezetet. Az Apache Spark 3.5.0-s és újabb verziói sorcsoportszintű statisztikákat hozhatnak létre az időbélyegoszlopokhoz. Ezután újra létre kell hoznia a táblát, és be kell vennie az adatokat a sorcsoportszintű statisztikák létrehozásához.

Hideg gyorsítótár teljesítmény

A Fabric Data Warehouse lekérdezésének végrehajtása váratlanul lassabb lehet, mint a későbbi futtatások. Ezt hidegindításnak nevezzük, amelyet a környezetet feldolgozásra előkészítő rendszer inicializálási vagy skálázási tevékenységei okoznak.

A hideg általában akkor indul el, ha:

  • Az adatok a OneLake-ből a memóriába töltődnek be, mert első alkalommal érhetők el, és még nem gyorsítótárazva vannak.
  • Ha első alkalommal férnek hozzá adatokhoz, a lekérdezések végrehajtása késleltetve lesz, amíg a szükséges statisztikák automatikusan létre nem jönnek.
  • A Fabric Data Warehouse bizonyos inaktivitás után automatikusan szünetelteti a csomópontokat a költségek csökkentése érdekében, és az automatikus skálázás részeként csomópontokat ad hozzá. A csomópontok újraindítása vagy létrehozása általában kevesebb, mint egy másodpercet vesz igénybe.

Ezek a műveletek növelhetik a lekérdezések időtartamát. A hidegindítások részlegesek lehetnek. Előfordulhat, hogy egyes számítási csomópontok, adatok vagy statisztikák már elérhetők vagy gyorsítótárazva vannak a memóriában, míg a lekérdezés megvárja, amíg mások elérhetővé válnak.

A Fabric Data Warehouse memóriában és lemezen történő gyorsítótárazása teljesen átlátható, és automatikusan aktiválva van. A gyorsítótárazás intelligensen minimalizálja a távoli storage olvasási igényét a helyi gyorsítótárak használatával. A Fabric Data Warehouse kifinomult hozzáférési mintákat alkalmaz az adatok tárolóból történő olvasásának javítása és a lekérdezések végrehajtási sebességének növelése érdekében. További információ: Gyorsítótárazás a Fabric adattárházakban.

A queryinsights.exec_requests_history nézet lekérdezésével észlelheti a távoli storage adatok memóriába való beolvasása által okozott hidegindítási effektusokat. Ellenőrizze a data_scanned_remote_storage_mb oszlopot.

  • A data_scanned_remote_storage_mb nem nulla értéke hidegindítást jelez. A lekérdezés végrehajtása során az adatok lekérése a OneLake-ből történt. A későbbi nézeteknek bizonyíthatóan gyorsabbnak kell lenniük a queryinsights.exec_requests_history alatt.
  • A nulla érték a tökéletes állapot a data_scanned_remote_storage_mb-ben, ahol az összes adat gyorsítótárazódik. A lekérdezési eredmények kiszolgálásához nem volt szükség csomópontmódosításokra vagy adatokra a OneLake-ből.

Fontos

Ne ítélje meg a lekérdezés teljesítményét az első végrehajtás alapján. Mindig ellenőrizze data_scanned_remote_storage_mb , hogy a lekérdezésre hatással volt-e a hidegindítás. A későbbi végrehajtások gyakran jelentősen gyorsabbak, és a tényleges teljesítményre jellemzőek, ami csökkenti az átlagos végrehajtási időt.

Lekérdezések sztringoszlopokkal rendelkező táblákon

Használja a legkisebb karakterlánc oszlop hosszát, amely képes befogadni az értékeket. A Fabric Warehouse folyamatosan fejlődik; A nagy sztring típusú adattípusok, különösen a nagy objektumok (LOB-k) használata esetén azonban a teljesítmény alacsonyabb lehet. Egy oszlop adattípusához customer_name például vegye figyelembe az üzleti követelményeket és a várt adatokat, és a n vagy a varchar(n)) helyett használjon megfelelő hosszúságot a deklaráláskor( például varchar(100)). A statisztikák és a lekérdezési költségek becslése pontosabb, ha az adattípus hossza pontosabb a tényleges adatokhoz.

  • A Fabric Data Warehouse T-SQL-ben tekintse meg az útmutatást a sztring adattípusok megfelelő hosszának kiválasztásához.
  • A Sparkban nem definiált hosszúságú Lakehouse táblák sztringoszlopait a Fabric Warehouse varchar(8000)-ként ismeri fel. Az optimális teljesítmény érdekében a SparkSQL-ben használja a CREATE TABLE utasítást a sztringoszlop definiálásához, ahol a varchar(n) a maximális oszlophosszt adja meg, amely értékek befogadására képes.

Tranzakciók és egyidejűség

A Fabric Data Warehouse egy modern, natív felhőbeli architektúrára épül, amely egyesíti a tranzakciós integritást, a pillanatképek elkülönítését és az elosztott számításokat, hogy nagy léptékben magas egyidejűséget és konzisztenciát biztosítson. További információ: Tranzakciók a Raktártáblákban.

A Fabric Data Warehouse pillanatkép-elkülönítéssel támogatja az ACID-kompatibilis tranzakciókat. Ez a következőt jelenti:

  • Az olvasási és írási műveletek egyetlen tranzakcióba csoportosíthatók standard T-SQL (BEGIN TRANSACTION, COMMIT, ROLLBACK) használatával
  • Minden vagy semmi szemantika: Ha egy tranzakció több táblára terjed ki, és egy művelet meghiúsul, a teljes tranzakció vissza lesz állítva.
  • Olvasási konzisztencia: SELECT a tranzakción belüli lekérdezések az adatok konzisztens pillanatképét látják, amelyet az egyidejű írások nem érintenek.

A Fabric Warehouse-tranzakciók támogatása:

  • Adatdefiníciós nyelv (DDL) tranzakciókon belül: Egy tranzakcióblokkba belefoglalhat CREATE TABLE .
  • Adatbázisközi tranzakciók: Ugyanazon a munkaterületen belül támogatott, beleértve az SQL Analytics-végpontokból származó olvasásokat is.
  • Parquet-alapú visszaállítás: Mivel a Fabric Data Warehouse nem módosítható Parquet-fájlokban tárolja az adatokat, a visszaállítások gyorsak. A visszaállítások egyszerűen a korábbi fájlverziókat állítják vissza.
  • Automatic data compaction and checkpointing:Data compaction optimalizálja a storage és olvasási teljesítményt a kis Parquet-fájlok egyesítésével és a logikailag törölt sorok eltávolításával.
  • Automatikus ellenőrzőpontozás: Minden írási művelet (INSERT, UPDATE, DELETE) hozzáfűz egy új JSON-naplófájlt a Delta Lake tranzakciónaplójához. Idővel ez több száz vagy több ezer naplófájlt eredményezhet, különösen streamelési vagy nagy gyakoriságú betöltési forgatókönyvekben. Az automatikus ellenőrzőpontolás javítja a metaadatok olvasási hatékonyságát azáltal, hogy a tranzakciónaplókat összegzi egyetlen ellenőrzőpont-fájlba. Ellenőrzőpont nélkül minden olvasásnak be kell vizsgálnia a tranzakciónapló teljes előzményeit. Az ellenőrzőpontokkal csak a legújabb ellenőrzőpont fájlt és az utána lévő naplófájlokat olvassa el. Ez drasztikusan csökkenti az I/O és a metaadatok elemzését, különösen nagy vagy gyakran frissített táblák esetén.

Mind a tömörítés, mind az ellenőrzőpontok kezelése kritikus fontosságú az adatbázis táblázat állapota szempontjából, különösen hosszan futó vagy nagy párhuzamosságú környezetekben.

Egyidejűség-vezérlés és elkülönítés

A Fabric Data Warehouse kizárólag pillanatkép-elkülönítést használ. A rendszer figyelmen kívül hagyja az elkülönítési szint T-SQL-en keresztüli módosítására tett kísérleteket.

Ajánlott eljárások tranzakciókkal

  • Használjon explicit tranzakciókat okosan. Mindig COMMIT vagy ROLLBACK. Ne hagyja nyitva a tranzakciókat.
    • Rövid élettartamú tranzakciók megtartása. Kerülje a hosszú ideig futó tranzakciókat, amelyek szükségtelenül tartják a zárolásokat, különösen az explicit tranzakciók esetében, amelyek DDL-eket tartalmaznak. Ez versengést okozhat a rendszerkatalógus-nézetekre (például SELECT) vonatkozó utasításokkal sys.tables, és problémákat okozhat a Fabric portálon, amely rendszerkatalógus-nézetekre támaszkodik.
  • Adjon hozzá újrapróbálkozási logikát késleltetéssel az alkalmazásokban vagy a csővezetékekben az átmeneti ütközések kezeléséhez.
    • Exponenciális visszalépéssel elkerülheti az átmeneti hálózati fennakadásokat rontó újrapróbálkozási viharokat.
    • További információ: Retry sablon.
  • A raktár zárolásainak és ütközéseinek monitorozása.

Visszaadott adathalmaz méretének csökkentése

A nagy adatméretű lekérdezések köztes lekérdezések végrehajtásakor vagy a végső lekérdezési eredményben nagyobb lekérdezési teljesítménnyel kapcsolatos problémát tapasztalhatnak. A visszaadott adathalmaz méretének csökkentése érdekében fontolja meg a következő stratégiákat:

  • Nagyméretű táblák partícionálása vagy fürtözése (Folyékony fürtözés) a Lakehouse-ban.
  • Korlátozza a visszaadott oszlopok számát. SELECT * költséges lehet.
  • Korlátozza a visszaadott sorok számát. A lehető legtöbb adatszűrést végezze el a raktárban, ne az ügyfélalkalmazásokban.
    • Próbálja meg szűrni a csatlakozás előtt, hogy csökkentse az adathalmazt a lekérdezés végrehajtásának korai szakaszában.
    • Alacsony számosságú oszlopokon történő szűréssel csökkentse a nagy adathalmazokat, mielőtt JOIN műveleteket végezne.
    • A szűréshez és összekapcsoláshoz ideálisak a magas számosságú oszlopok. Ezeket gyakran használják záradékokban WHERE , és a predikátumot a lekérdezés végrehajtásának korábbi szakaszában alkalmazzák az adatok szűréséhez.
  • A Fabric Data Warehouse-ban, mivel az elsődleges kulcs és az egyedi kulcskorlátozások nincsenek betartva, az ilyen korlátozásokkal rendelkező oszlopok nem feltétlenül jó jelöltek a JOIN művelethez.

Lekérdezési tervek és lekérdezési tippek

A Fabric Data Warehouse a lekérdezésoptimalizáló létrehoz egy lekérdezés-végrehajtási tervet, amely meghatározza az SQL-lekérdezések végrehajtásának leghatékonyabb módját. A speciális felhasználók megvizsgálhatják a lekérdezési terv lekérdezési teljesítményével kapcsolatos problémákat, vagy lekérdezési tippeket adhatnak hozzá.

  • A felhasználók a SHOWPLAN_XMLSQL Server Management Studio használatával tekinthetik meg a tervet a lekérdezés végrehajtása nélkül.
  • A választható lekérdezési tippek hozzáadhatók egy SQL-utasításhoz, hogy további utasításokat adjanak a lekérdezésoptimalizálónak a tervezés előtt. A lekérdezési tippek hozzáadása a lekérdezési számítási feladatok speciális ismeretét igényli, ezért általában más ajánlott eljárások implementálása után használják, de a probléma továbbra is fennáll.

Nem méretezhető műveletek

A Fabric Data Warehouse egy nagymértékben párhuzamos feldolgozási (MPP)-architektúrára épül, ahol a lekérdezések több számítási csomóponton futnak. Bizonyos esetekben az egycsomópontos végrehajtás indokolt:

  • A teljes lekérdezésterv végrehajtásához csak egy számítási csomópont szükséges.
  • A terv részfa elfér egy számítási csomóponton belül.
  • A lekérdezés szemantikájának kielégítése érdekében a teljes lekérdezést vagy a lekérdezés egy részét egyetlen csomóponton kell végrehajtani. Ilyenek például TOP a műveletek, a globális rendezés, a párhuzamos végrehajtások eredményeinek rendezését igénylő lekérdezések egyetlen eredmény létrehozásához, vagy az eredmények utolsó lépéshez való csatlakoztatása.

Ezekben az esetekben a felhasználók "Egy vagy több nem méretezhető művelet észlelhető" figyelmeztető üzenetet kaphatnak, és a lekérdezés hosszú végrehajtás után lassan vagy sikertelenül futhat.

  • Érdemes lehet csökkenteni a lekérdezés szűrt adathalmazának méretét.
  • Ha a lekérdezés szemantikája nem igényel egycsomópontos végrehajtást, próbálkozzon például egy elosztott lekérdezési terv kényszerítésével a FORCE DISTRIBUTED PLANOPTION (FORCE DISTRIBUTED PLAN); használatával.

Az SQL Analytics-végpont lekérdezése

Az SQL Analytics-végponttal lekérdezheti a Spark SQL-lel feltöltött Lakehouse-táblákat anélkül, hogy adatokat másolt vagy betöltött volna a Warehouse-ba.

Az alábbi ajánlott eljárások vonatkoznak a Lakehouse-beli raktáradatok SQL Analytics-végponton keresztüli lekérdezésére. Az SQL Analytics-végpont teljesítményével kapcsolatos további információkért tekintse meg az SQL Analytics-végpontok teljesítményével kapcsolatos szempontokat.

Jótanács

Az alábbi ajánlott eljárások vonatkoznak arra, hogy a Spark használatával dolgozza fel az adatokat egy olyan lakehouse-ba, amelyet lekérdezhet az SQL Analytics-végpont.

Rendszeres táblakarbantartás végrehajtása a Lakehouse-táblákhoz

A Microsoft Fabric a Warehouse automatikusan optimalizálja az adatelrendezéseket, és elvégzi a szemétgyűjtést és tömörítést. Egy Lakehouse-hoz jobban szabályozhatja a táblák karbantartását. A táblák optimalizálása és porszívózása szükséges, és jelentősen csökkentheti a nagy adathalmazokhoz szükséges vizsgálati időt. A Lakehouse-ban a táblakarbantartás a gyors elérési útvonalakra is kiterjedhet, és így jelentősen javíthatja a teljesítményt.

Tóparti táblázatok vagy billentyűparancsok optimalizálása sok kis fájllal

Ha sok kis fájl van, azzal többletterhelést okoz a fájl metaadatainak olvasásához. A Fabric portálon vagy egy jegyzetfüzetben a OPTIMIZE paranccsal kis méretű fájlokat egyesíthet nagyobb fájlokká. Ismételje meg ezt a folyamatot, ha a fájlok száma jelentősen megváltozik.

A Fabric Lakehouse-ban lévő táblázat optimalizálásához nyissa meg a Lakehouse-t a Fabric portálon. Az Explorerben kattintson a jobb gombbal a táblára, és válassza a Karbantartás lehetőséget. Válassza ki a beállításokat a Karbantartási parancsok futtatása lapon, majd válassza a Futtatás most lehetőséget.

Az ugyanabban a régióban található lakehouse-táblák vagy billentyűparancsok lekérdezése

A Fabric ott végzi a számítást, ahol a Fabric kapacitása található. Az adatok lekérdezése, például a saját Azure Data Lake Storage vagy a OneLake-ben, egy másik régióban a hálózati késés miatt többletterhelést okoz. Győződjön meg arról, hogy az adatok ugyanabban a régióban találhatóak. A teljesítménykövetelményektől függően fontolja meg, hogy csak kis táblákat, például dimenziótáblákat tartson meg egy távoli régióban.

Lakehouse-táblák és -gyorslinkek szűrése ugyanazon oszlopokon

Ha gyakran szűr táblázatsorokat adott oszlopokra, fontolja meg a tábla particionálását.

A particionálás jól működik alacsony számosságú oszlopokhoz vagy kiszámítható számosságú oszlopokhoz, például évekhez vagy dátumokhoz. További információ: Lakehouse-oktatóanyag – Lakehouse-adatok előkészítése és átalakítása , valamint adatok betöltése a Lakehouse-ba partíció használatával.

A fürtözés jól működik a magas szelektivitású oszlopok esetében. Ha vannak más, gyakran szűréshez használt oszlopai, amelyek nem particionálási oszlopok, fontolja meg a tábla fürtözését a Spark SQL-szintaxissal történő optimalizálás használatávalZORDER BY. További információkat a Delta Lake tábla optimalizálásról talál.

Adatklaszterezés

Meghatározott oszlopokban az adatok klaszterezése is elvégezhető a CREATE TABLE és CREATE TABLE AS SELECT (CTAS) T-SQL utasításokban. Az adatosztályozás úgy működik, hogy a betöltés során hasonló értékeket tartalmazó sorokat a tároló szomszédos helyein tárolják.

  • Az adatok térkitöltő görbével vannak rendezve, hogy több dimenzióban megőrizzék a lokalitást, így a klaszterezési oszlopokban hasonló értékeket tartalmazó sorok fizikailag közel helyezkednek el egymáshoz. Ez a megközelítés jelentősen javítja a lekérdezési teljesítményt a fájl kihagyásával és a beolvasott fájlok számának csökkentésével.
  • Az adatfürtök metaadatai a betöltés során beágyazódnak a jegyzékbe, így az adatbázis-motor intelligens döntéseket hozhat arról, hogy mely fájlokhoz férjen hozzá a felhasználói lekérdezések során. Ez a metaadatok és a hasonló értékeket tartalmazó sorok együttes tárolása biztosítja, hogy a szűrő predikátumokkal rendelkező lekérdezések kihagyják a predikátum hatókörén kívül eső teljes fájlokat és sorcsoportokat.

Ha például egy lekérdezés egy tábla adatainak csak 10% célozza meg, a fürtözés biztosítja, hogy csak a szűrő tartományában lévő adatokat tartalmazó fájlok legyenek beolvasva, csökkentve az I/O-t és a számítási felhasználást. A nagyobb táblázatok jobban kihasználják az adatok csoportosítását, mivel a fájl átugrás előnyei az adatmennyiséggel arányosan nőnek.

Adattípus-optimalizálás

A megfelelő adattípusok kiválasztása elengedhetetlen a raktár teljesítményéhez és storage hatékonyságához. Az alábbi irányelvek segítenek biztosítani, hogy a sématerv támogatja a gyors lekérdezéseket, a hatékony storage és a karbantarthatóságot.

A Fabric Data Warehouse által támogatott adattípusokról további információt a Fabric Data Warehouse c0 Adattípusai című cikkben talál.

Jótanács

Ha külső eszközökkel hoz létre táblákat vagy lekérdezéseket, például egy kódelső üzembe helyezési módszertant, gondosan tekintse át az oszlop adattípusát. A karakter adattípus hosszának és lekérdezéseinek az alábbi ajánlott eljárásokat kell követniük.

Adattípusok egyeztetése adatszemantika szerint

A clarity és a teljesítmény biztosítása érdekében fontos, hogy az egyes oszlopok adattípusa igazodjon az általa tárolt adatok tényleges jellegéhez és viselkedéséhez.

  • A dátum, az idő vagy a datetime2(n) időértékeket használja sztringek helyett.
  • Numerikus értékekhez egész számtípusokat használhat, kivéve, ha formázásra (például kezdő nullákra) van szükség.
  • A formázás megőrzésekor használjon karaktertípusokat (karakter, varchar) (például nullával kezdődő számok, termékkódok, kötőjeles számok).

Egész számtípusok használata

Értékek, például azonosítók, számlálók vagy más egész számok tárolásakor előnyben részesítse az egész számtípusokat (smallint, int, bigint) a decimális/számokkal szemben. Az egész számtípusok kevesebb storage igényelnek, mint azok az adattípusok, amelyek lehetővé teszik a tizedesvesszőtől jobbra lévő számjegyek használatát. Ennek eredményeképpen gyorsabb aritmetikai és összehasonlító műveleteket tesznek lehetővé, és javítják az indexelést és a lekérdezési teljesítményt.

Vegye figyelembe a Fabric Data Warehouse által támogatott összes egész adattípus értéktartományait. További információ: int, bigint, smallint (Transact-SQL).

Fontolja meg a decimális és numerikus pontosság és skálázás használatát

Ha decimális/számokat kell használnia, az oszlop létrehozásakor válassza ki az adatoknak megfelelő legkisebb pontosságot és skálázást . A túlkiépítési pontosság növeli a tárolási követelményeket, és az adatok növekedésével ronthatja a teljesítményt.

  • A raktár várható növekedésének és igényeinek előrejelzése. Ha például legfeljebb négy számjegyet szeretne tárolni a tizedesvessző jobb oldalán, használja a decimal(9,4) vagy decimal(19,4) a leghatékonyabb tároláshoz.
  • Decimális/numerikus oszlop létrehozásakor mindig adjon meg pontosságot és skálázást. Ha egy egyszerűen decimaldefiniált táblában jön létre, és nem adja meg (p,s) a pontosságot és a skálázást, a decimális/numerikus oszlopot decimal(18,0)a program a következőképpen hozza létre. A 18 pontosságú decimal soronként 9 bájt storage használ fel. A skála 0 nem tárol adatot a tizedesjel jobb oldalán. Sok üzleti egész szám esetében a smallint, a int, a bigint sokkal hatékonyabb, mint decimal(18,0). Egy kilencjegyű egész szám például egész számként adattípusként tárolható 4 bájtnyi storage soronként.

A teljes információt a decimális és numerikus (Transact-SQL) című cikkben talál.

Fontolja meg, hogy mikor érdemes a varchar típust a char típus helyett használni

Sztringoszlopok esetén használjon varchar(n) a char(n) helyett, kivéve, ha kifejezetten szükség van rögzített hosszúságú kitöltésre. A varchar oszlop csak a sorok tényleges sztringhosszát tárolja, plusz egy kis többletterhelést, és csökkenti a felesleges helyet, ami javítja az I/O hatékonyságát.

  • A varchar(n) függvényt olyan értékekhez használhatja, mint a nevek, címek és leírások, mivel széles körben változó értékekkel rendelkeznek. A statisztikák és a lekérdezési költségek becslése pontosabb, ha az adattípus hossza pontosabb a tényleges adatokhoz.
  • Használjon char(n)-t, ha tudja, hogy a sztring minden alkalommal rögzített hosszúságú lesz. Ha például a karakterláncot 000000000char(9) formátumban tárolja, akkor van értelme, ha a karakterlánc mindig pontosan 9 numerikus karakter, amely nullával kezdődhet.
  • Az oszlop adattípus-deklarációjában a n hossza a tároló bájtok száma. Az olyan többbájtos kódolású karakterkészletek esetében, mint az UTF-8, a Fabric Data Warehouse, a latin karakterek és a számok kódolása 1 bájtnyi storage vesz igénybe. Vannak azonban olyan Unicode-karakterek, amelyek 1 bájtnál több bájtot igényelnek, például japán karakterek, amelyek tárolásához 3 bájt szükséges, így a ténylegesen tárolt Unicode-karakterek száma kisebb lehet az adattípus hosszánál n. További információ: karakter- és varchar argumentumok.

Ha lehetséges, kerülje a null értékű oszlopokat

Oszlopokat határozzon meg NOT NULL amikor az adatmodell megengedi. Alapértelmezés szerint egy tábla oszlopa engedélyezi NULL az értékeket. A null értékű oszlopok a következő jellemzőkkel rendelkeznek:

  • Metaadat-többletterhelést adnak hozzá.
  • Csökkentheti a lekérdezésoptimalizálások és -statisztikák hatékonyságát.
  • Hatással lehet a nagy léptékű elemzési lekérdezések teljesítményére.

Adatbetöltés és előkészítés egy raktárban

MÁSOLÁS BELE

A T-SQL COPY INTO parancs a Azure Data Lake Storage-ból a Fabric Data Warehouse való adatbetöltés ajánlott módja. További információkért és példákért lásd: Adatok betöltése a raktárba a COPY utasítással.

A legjobb teljesítmény érdekében vegye figyelembe az alábbi javaslatokat:

  • Fájlméret: Győződjön meg arról, hogy minden betöltött fájl ideálisan 100 MB és 1 GB között van a maximális átviteli sebesség érdekében. Ez segít optimalizálni az adatbeviteli folyamatot és javítani a teljesítményt.
  • Fájlok száma: A párhuzamosság és a lekérdezési teljesítmény maximalizálása érdekében törekedjen nagy számú fájl létrehozására. Hozzon létre a lehető legtöbb fájlt, miközben a fájlok méretének legalább 100 MB-nak kell lennie.
  • Párhuzamos betöltés: Több COPY INTO párhuzamosan futó utasítás használata az adatok különböző táblákba való betöltéséhez. Ez a megközelítés jelentősen csökkentheti az ETL/ELT ablakot a párhuzamosság miatt.
  • Kapacitás mérete: Nagyobb adatmennyiségek esetén fontolja meg a nagyobb hálókapacitásra való skálázást, hogy a párhuzamos feldolgozás és a nagyobb adatmennyiségek elhelyezéséhez szükséges további számítási erőforrásokat beszerezhesse.

A Fabric Data Warehouse támogatja a BULK INSERT utasítást is, amely a COPY INTO szinonimája. Ugyanez a javaslat vonatkozik a BULK INSERT utasításra is.

CTAS vagy INSERT

Használja a CREATE TABLE AS SELECT (CTAS) vagy INSERTSELECT FROM Lakehouse table/shortcut parancsokkal kombinálva. Ezek a módszerek hatékonyabbak és hatékonyabbak lehetnek, mint a pipelines használata, ami gyorsabb és megbízhatóbb adatátvitelt tesz lehetővé. További információkért és példákért lásd: Adatok betöltése a Raktárba a Transact-SQL használatával.

A párhuzamosság számának növelését és a nagyobb hálókapacitásra való skálázást a CTAS-/INSERT-műveletekre is alkalmazni kell az átviteli sebesség növelése érdekében.

Az OPENROWSET használatával adatokat olvassunk az Azure Data Lake Storage-ból vagy Blob Storage-ból.

A OPENROWSET függvény lehetővé teszi CSV- vagy Parquet-fájlok olvasását Azure Data Lake-ből vagy Azure Blob storage, anélkül, hogy betölti azt a Warehouse-ba. További információkért és példákért lásd: Fájltartalom tallózása OPENROWSET függvény használatával.

További információ és példák a külső adatok lekérdezéséről: Külső data lake-fájlok lekérdezése Fabric Data Warehouse vagy SQL Analytics-végpont használatával.

Ha az OPENROWSET függvény használatával olvas adatokat, vegye figyelembe a következő javaslatokat a legjobb teljesítmény érdekében:

  • Parketta: Ha gyakran kérdezi le a fájlokat, próbálja meg a Parquetet használni a CSV helyett, vagy konvertálja a CSV-t Parquetre. A Parquet egy oszlopos formátum. Mivel az adatok tömörítve vannak, a fájlmérete kisebb, mint az azonos adatokat tartalmazó CSV-fájlok. A Fabric Data Warehouse kihagyja azokat az oszlopokat és sorokat, amelyekre nincs szükség egy lekérdezésben, ha Parquet-fájlokat olvas.
  • Fájlméret: Győződjön meg arról, hogy minden betöltött fájl ideálisan 100 MB és 1 GB között van a maximális átviteli sebesség érdekében. Ez segít optimalizálni az adatbeviteli folyamatot és javítani a teljesítményt. Jobb, ha ugyanolyan méretű fájlokkal rendelkezik.
  • Fájlok száma: A párhuzamosság és a lekérdezési teljesítmény maximalizálása érdekében törekedjen nagy számú fájl létrehozására. Hozzon létre a lehető legtöbb fájlt, miközben a fájlok méretének legalább 100 MB-nak kell lennie.
  • Feloszt: Az adatok particionálása partíciók különböző mappákba vagy fájlnevekbe való tárolásával, ha a számítási feladat partícióoszlopok alapján szűri őket.
  • Becslés: Ha úgy érzi, hogy a teljesítmény nem felel meg a várakozásoknak, próbálja meg ROWS_PER_BATCH értékét a mögöttes fájlok sorainak számához beállítani.
  • Kapacitás mérete: Nagyobb adatmennyiségek esetén fontolja meg a nagyobb termékváltozatra való horizontális felskálázást, hogy több számítási erőforrás legyen szükséges a párhuzamos feldolgozás és a nagyobb adatmennyiségek további tárolásához.

Kerülje a lassú beszúrásokat, frissítéseket és törléseket

A Fabric Data Warehouse hatékony fájlelrendezésének és optimális lekérdezési teljesítményének biztosítása érdekében kerülje a kis méretű INSERT, UPDATE és DELETE tranzakciók használatát. Ezek a sorszintű módosítások minden művelethez létrehoznak egy új Parquet-fájlt, ami sok kis fájlt és töredezett sorcsoportot eredményez. Ez a töredezettség a következőhöz vezet:

  • A nem hatékony fájlvizsgálat miatt megnövekedett lekérdezési késés.
  • Magasabb storage és számítási költségek.
  • Nagyobb támaszkodás a háttértömörítéses folyamatokra.

Ajánlott megközelítések:

  • Batch-tranzakciók, amelyek a Fabric Data Warehouse-ba írnak.
    • Például a sok kis INSERT utasítás helyett csoportosítsa előzetesen az adatokat, majd szúrja be azokat egyetlen INSERT utasítással.
  • Használja a COPY INTO parancsot tömeges beszúrásokhoz, és amikor csak lehetséges, végezze el a frissítéseket és a törléseket kötegekben.
  • A sorcsoportok hatékony kialakítása érdekében minimálisan 100 MB-os importált fájlméretet tartson fenn.
  • Az adatbetöltéssel kapcsolatos további útmutatásért és ajánlott eljárásokért tekintse meg az adatok raktárba való betöltésének ajánlott eljárásait.

Adattömörség

A Fabric Data Warehouse az adattömörítő egy háttéroptimalizálási folyamat, amely kisebb, nem hatékony Parquet-fájlokat egyesít kevesebb, nagyobb fájlba. Ezeket a fájlokat gyakran kis adatcsepegések, INSERT, UPDATE vagy DELETE műveletek által hozzák létre. Az adattömörítés csökkenti a fájlok töredezettségét, javítja a sorcsoportok hatékonyságát, és javítja a lekérdezések általános teljesítményét.

Bár a Fabric Data Warehouse motor automatikusan feloldja a töredezettségeket az adattömörítés révén, a teljesítmény a folyamat befejezéséig csökkenhet. Az adattömörülés automatikusan fut a Fabric Data Warehouse felhasználói beavatkozása nélkül.

Az adattömörülés nem vonatkozik a Lakehouse-ra. Az SQL Analytics-végpontokon keresztül elért Lakehouse-táblák esetében fontos, hogy kövesse a Lakehouse ajánlott eljárásait, és manuálisan futtassa a OPTIMIZE parancsot a jelentős adatváltozások után az optimális storage elrendezés fenntartása érdekében.

Adattömörítési preempció

A Fabric Data Warehouse intelligensen és aktívan elkerüli a háttértömörítéses feladatok és a felhasználói műveletek közötti írás-írás ütközéseket. 2025 októberétől engedélyezve van az adattömörítési preempció.

A tömörítés ellenőrzi a felhasználói lekérdezések által tárolt megosztott zárolásokat. Ha az adatkompaktálás zárolást érzékel a kezdés előtt, akkor várakozik, és később újra próbálkozik. Ha az adattömörítés elindul, és a véglegesítés előtt zárolást észlel, a tömörítés megszakad, hogy elkerülje az írási ütközést a felhasználói lekérdezéssel.

Az írási-írási ütközések továbbra is lehetségesek a Fabric Data Warehouse háttéradat-tömörítési szolgáltatással. Írási-írási ütközést lehet létrehozni az adattömörítéssel, például ha egy alkalmazás explicit tranzakciót használ, és nem ütköző műveletet (például INSERT) hajt végre egy ütköző művelet előtt (UPDATE, DELETE, ). MERGE Az adattömörítés sikeresen végrehajtható, ami miatt az explicit tranzakció később konfliktus miatt meghiúsul. Az írási-írási vagy frissítési ütközésekről további információt a Microsoft Fabric Warehouse táblák tranzakciói című témakörben talál.

V-Order a Szöveti Adattárházban

V-Order egy írási időbeli optimalizálás a Parquet fájlformátumhoz, amely lehetővé teszi a gyors olvasást a Microsoft Fabricban. A V-Order in Fabric Data Warehouse javítja a lekérdezési teljesítményt azáltal, hogy rendezést és tömörítést alkalmaz a táblázatfájlokra.

Alapértelmezés szerint a V-Order minden raktárban engedélyezve van annak biztosítása érdekében, hogy az olvasási műveletek, különösen az elemzési lekérdezések a lehető leggyorsabbak és leghatékonyabbak legyenek.

A V-Order azonban egy kis betöltési többletterhelést vezet be, amely írásintenzív munkaterheléseknél észrevehető. Ezért a V-Order letiltását csak olyan raktárak esetében érdemes figyelembe venni, amelyek szigorúan írásigényesek, és nem használják a gyakori lekérdezésekhez. Fontos megjegyezni, hogy ha a V-Order le van tiltva egy raktárban, nem lehet újra engedélyezni.

Mielőtt úgy dönt, hogy letiltja a V-Ordert, a felhasználóknak alaposan tesztelniük kell a számítási feladataik teljesítményét, hogy a kompromisszum indokolt legyen. Gyakori minta egy átmeneti raktár használata, amelyben a V-Order le van tiltva a nagy átviteli sebességű betöltéshez, az adatok átalakításához és a mögöttes adatok V-Order-kompatibilis Data Warehouse való betöltéséhez a jobb olvasási teljesítmény érdekében. További információért lásd: A V-rendelés letiltása raktárban a Microsoft Fabric-ben.

Táblák klónozása a táblázatok másolása helyett

Táblázási klónok a Fabric Data Warehouse gyors és hatékony módszert nyújtanak a táblák létrehozására adatok másolása nélkül. Nulla másolású klónozási módszer esetén csak a tábla metaadatai duplikálódnak, míg a mögöttes adatfájlokra közvetlenül a OneLake-ből hivatkozik. Ez lehetővé teszi, hogy a felhasználók szinte azonnal konzisztens, megbízható táblamásolatokat hozzanak létre, anélkül, hogy a teljes adatkettőzéssel járna.

A nulla másolású klónok ideálisak olyan forgatókönyvekhez, mint a fejlesztés, a tesztelés és a biztonsági mentés, amely nagy teljesítményű, storage hatékony megoldást kínál, amely segít csökkenteni az infrastruktúra költségeit.

  • A klónozott táblák a forrás összes kulcsfontosságú biztonsági funkcióját is kimásolják, beleértve a Row-Level Security (RLS), a Column-Level Security (CLS) és a dinamikus adatmaszkolás (DDM) szolgáltatást is, anélkül, hogy újra kellene alkalmazni a házirendeket a klónozás után.
  • A klónok az adatmegőrzési időszakon belül egy adott időpontból hozhatók létre, ami támogatja az időutazási képességeket.
  • A klónozott táblák a forrástól függetlenül léteznek, a forrás módosításai nem befolyásolják a klónt, és a klón módosításai nem érintik a forrást. A forrás vagy a klón egymástól függetlenül eldobható.

Metaadat-nézetek lekérdezése

A nézetekkel kapcsolatos további információkért lásd: queryinsightsLekérdezési elemzések a Fabric-adattárházakban.

A lekérdezési életciklus DMV-kkel kapcsolatos további információkért lásd: Kapcsolatok, munkamenetek és kérések monitorozása DMV-kkel.

Kapcsolódó tartalom

  • Last updated on