Ajánlott eljárások adatok dedikált SQL-készletbe való betöltéséhez az Azure Synapse Analyticsben

Jótanács

Microsoft Fabric Data Warehouse egy nagyvállalati szintű relációs raktár egy Data Lake-alaprendszeren, jövőre kész architektúrával, beépített AI-vel és új funkciókkal. Ha még nem ismerkedik adattárházzal, kezdje a Fabric Data Warehouse. A meglévő dedikált SQL-készlet számítási feladatai frissíthetők Fabric az adatelemzés, a valós idejű elemzés és a jelentéskészítés új képességeinek eléréséhez.

Ebben a cikkben javaslatokat és teljesítményoptimalizálásokat talál az adatok betöltéséhez.

Adatok előkészítése az Azure Storage-ban

A késés minimalizálása érdekében helyezze át a tárolási réteget és a dedikált SQL-készletet.

Az adatok ORC-fájlformátumba való exportálásakor előfordulhat, hogy a Java memórián kívüli hibákba ütközik, ha nagy méretű szövegoszlopok vannak. A korlátozás megkerüléséhez exportálja csak az oszlopok egy részét.

A PolyBase nem tudja betölteni az 1 000 000 bájtnál több adatot tartalmazó sorokat. Amikor adatokat helyez el a szövegfájlokban az Azure Blob Storage-ban vagy az Azure Data Lake Store-ban, azoknak 1 000 000 bájtnál kevesebb adatnak kell lenniük. Ez a bájtkorlátozás a táblasémától függetlenül igaz.

Minden fájlformátum különböző teljesítményjellemzőkkel rendelkezik. A leggyorsabb betöltéshez használjon tömörített, tagolt szövegfájlokat. Az UTF-8 és az UTF-16 teljesítménye között minimális a különbség.

Nagyméretű tömörített fájlok felosztása kisebb tömörített fájlokra.

Terhelések futtatása elegendő számítási kapacitással

A leggyorsabb betöltési sebesség érdekében egyszerre csak egy betöltési feladatot futtasson. Ha ez nem lehetséges, futtasson egyszerre minimális mennyiségű terhelést. Ha nagy betöltési feladatra számít, fontolja meg a dedikált SQL-készlet felskálázását a betöltés előtt.

A terhelések megfelelő számítási erőforrásokkal való futtatásához hozzon létre terhelések futtatására kijelölt betöltési felhasználókat. Rendelje hozzá az egyes betöltési felhasználókat egy adott erőforrásosztályhoz vagy számítási feladatcsoporthoz. A terhelés futtatásához jelentkezzen be a betöltési felhasználók egyikeként, majd futtassa a terhelést. A terhelés a felhasználó erőforrásosztályával fut. Ez a módszer egyszerűbb, mint a felhasználó erőforrásosztályának módosítása az aktuális erőforrásosztály igényeinek megfelelően.

Felhasználó létrehozása betöltéshez

Ez a példa létrehoz egy betöltési felhasználót, aki egy adott számítási feladatcsoportba van besorolva. Első lépésként csatlakozzon a mesterhez, és hozzon létre egy felhasználói fiókot.

   -- Connect to master
   CREATE LOGIN loader WITH PASSWORD = 'a123STRONGpassword!';

Csatlakozzon a dedikált SQL-készlethez, és hozzon létre egy felhasználót. Az alábbi kód feltételezi, hogy csatlakozik a mySampleDataWarehouse nevű adatbázishoz. Bemutatja, hogyan hozhat létre egy betöltő nevű felhasználót, és hogyan ad engedélyt a felhasználóknak táblák létrehozására és betöltésére a COPY utasításhasználatával. Ezután a felhasználót a DataLoads számítási feladatcsoportba sorolja be maximális erőforrásokkal.

   -- Connect to the dedicated SQL pool
   CREATE USER loader FOR LOGIN loader;
   GRANT ADMINISTER DATABASE BULK OPERATIONS TO loader;
   GRANT INSERT ON <yourtablename> TO loader;
   GRANT SELECT ON <yourtablename> TO loader;
   GRANT CREATE TABLE TO loader;
   GRANT ALTER ON SCHEMA::dbo TO loader;
   
   CREATE WORKLOAD GROUP DataLoads
   WITH ( 
       MIN_PERCENTAGE_RESOURCE = 0
       ,CAP_PERCENTAGE_RESOURCE = 100
       ,REQUEST_MIN_RESOURCE_GRANT_PERCENT = 100
	);

   CREATE WORKLOAD CLASSIFIER [wgcELTLogin]
   WITH (
	     WORKLOAD_GROUP = 'DataLoads'
       ,MEMBERNAME = 'loader'
   );



Fontos

Ez egy szélsőséges példa az SQL-készlet 100% erőforrásának egyetlen terhelésre való kiosztására. Ez 1 maximális egyidejűséget biztosít. Vegye figyelembe, hogy ezt csak a kezdeti terheléshez használhatja, ahol más számítási feladatcsoportokat kell létrehoznia saját konfigurációkkal az erőforrások számítási feladatok közötti egyensúlyához.

Ha a terhelést a terhelési csoport erőforrásaival szeretné futtatni, jelentkezzen be betöltőként, és futtassa a terhelést.

Több felhasználó betöltésének engedélyezése

Gyakran előfordul, hogy több felhasználó is betölti az adatokat egy adattárházba. A CREATE TABLE AS SELECT (Transact-SQL) használatához az adatbázis CONTROL engedélye szükséges. A CONTROL engedély hozzáférést biztosít az összes sémához. Előfordulhat, hogy nem szeretné, hogy az összes betöltési felhasználó szabályozhassa az összes sémához való hozzáférést. Az engedélyek korlátozásához használja a DENY CONTROL utasítást.

Vegyük például az adatbázis sémáit, schema_A az A részleg számára és schema_B a B részleg számára. Tegyük fel, hogy az adatbázis felhasználói, user_A és user_B, a PolyBase betöltés felhasználói az A és B részlegekben. Mindkettő megkapta a CONTROL-adatbázis engedélyeit. Az A és b séma létrehozói a DENY használatával zárolják a sémákat:

   DENY CONTROL ON SCHEMA :: schema_A TO user_B;
   DENY CONTROL ON SCHEMA :: schema_B TO user_A;

User_A és user_B ki vannak zárva a másik osztály sémájából.

Betöltés átmeneti táblába

Az adatok adattárháztáblába való áthelyezésének leggyorsabb betöltési sebességének elérése érdekében töltse be az adatokat egy átmeneti táblába. Határozza meg az előkészítési táblát halomként, és használja a körkörös terjesztést elosztási opcióként.

Vegye figyelembe, hogy a betöltés általában kétlépéses folyamat, amelyben először feltölt egy átmeneti táblába, majd beszúrja az adatokat egy éles adatraktár táblába. Ha a gyártási tábla kivonateloszlást használ, a teljes betöltési és beszúrási idő gyorsabb lehet, ha az előkészítési táblát is kivonateloszlással definiálja. Az előkészítési táblába való adatok betöltése hosszabb időt vesz igénybe, de a sorok cél táblába való beszúrásának második lépése nem jár adatáthelyezéssel.

Betöltés oszlop-tárolós indexbe

Az oszlopcentrikus indexek nagy mennyiségű memóriát igényelnek az adatok kiváló minőségű sorcsoportokba való tömörítéséhez. A legjobb tömörítési és indexelési hatékonyság érdekében az oszlopcentrikus indexnek minden sorcsoportba legfeljebb 1 048 576 sort kell tömörítenie. Memóriaterhelés esetén előfordulhat, hogy az oszlopcentrikus index nem tudja elérni a maximális tömörítési sebességet. Ez hatással van a lekérdezési teljesítményre. A részletes elemzésért tekintse meg a Columnstore memóriaoptimalizálásait.

  • Annak érdekében, hogy a betöltési felhasználó elegendő memóriával rendelkezzen a maximális tömörítési sebesség eléréséhez, használjon olyan felhasználókat, amelyek egy közepes vagy nagy erőforrásosztály tagjai.
  • Töltsön be elegendő sort az új sorcsoportok teljes kitöltéséhez. A tömeges betöltés során minden 1 048 576 sor közvetlenül az oszloptárba lesz tömörítve teljes sorcsoportként. A 102 400-nál kevesebb sorból álló terhelések a sorokat a deltastore-ba küldik, ahol a sorok egy b-fa indexben vannak tárolva. Ha túl kevés sort tölt be, előfordulhat, hogy mind a deltastore-ba kerül, és nem kerülnek azonnal tömörítésre oszlopalapú formátumba.

A köteg méretének növelése az SQLBulkCopy API vagy a BCP használatakor

A COPY utasítással való betöltés a legmagasabb átviteli sebességet biztosítja dedikált SQL-készletekkel. Ha nem tudja betölteni a COPY-t, és az SqLBulkCopy API-t vagy a bcp-t kell használnia, érdemes megfontolnia a köteg méretének növelését a jobb átviteli sebesség érdekében.

Jótanács

Az optimális kötegméret meghatározásához ajánlott alapkonfiguráció a 100 K és 1 M sor közötti kötegméret.

Betöltési hibák kezelése

Egy külső táblát használó terhelés a "Lekérdezés megszakadt– a maximális elutasítási küszöbérték elérésekor egy külső forrásból történő olvasáskor" hibával meghiúsulhat. Ez az üzenet azt jelzi, hogy a külső adatok piszkos rekordokat tartalmaznak. Az adatrekordok akkor minősülnek piszkosnak, ha az adattípusok és az oszlopok száma nem egyezik a külső tábla oszlopdefinícióival, vagy ha az adatok nem felelnek meg a megadott külső fájlformátumnak.

A piszkos rekordok javításához győződjön meg arról, hogy a külső tábla és a külső fájlformátum definíciói helyesek, és a külső adatok megfelelnek ezeknek a definícióknak. Ha a külső adatrekordok egy részhalmaza piszkos, a " CREATE EXTERNAL TABLE" (KÜLSŐ TÁBLA LÉTREHOZÁSA) elvetési beállításaival elutasíthatja ezeket a rekordokat a lekérdezésekhez.

Adatok beszúrása a produciós táblába

Egy INSERT utasítássalrendelkező kis táblába történő egyszeri betöltés, vagy akár egy keresés rendszeres újrabetöltése is elég jól teljesíthet egy olyan utasítással, mint INSERT INTO MyLookup VALUES (1, 'Type 1'). Az egyszeri beszúrások azonban nem olyan hatékonyak, mint a tömeges betöltés.

Ha a nap folyamán ezer vagy több egyedi beszúrást kell végrehajtania, gyűjtse össze őket kötegbe, hogy tömegesen betölthesse. A folyamatokat úgy fejlesztheti ki, hogy hozzáfűzzék az egyes beszúrásokat egy fájlhoz, majd hozzon létre egy másik folyamatot, amely rendszeresen betölti a fájlt.

Statisztikák létrehozása a betöltés után

A lekérdezési teljesítmény javítása érdekében fontos, hogy statisztikákat hozzon létre az összes tábla összes oszlopán az első betöltés után, vagy jelentős változások következnek be az adatokban. A statisztikák létrehozása manuálisan is elvégezhető, vagy engedélyezheti automatikusan létrehozott statisztikákat.

A statisztikák részletes ismertetését a Statisztikacímű cikkben találja. Az alábbi példa bemutatja, hogyan hozhat létre manuálisan statisztikákat a Customer_Speed tábla öt oszlopán.

create statistics [SensorKey] on [Customer_Speed] ([SensorKey]);
create statistics [CustomerKey] on [Customer_Speed] ([CustomerKey]);
create statistics [GeographyKey] on [Customer_Speed] ([GeographyKey]);
create statistics [Speed] on [Customer_Speed] ([Speed]);
create statistics [YearMeasured] on [Customer_Speed] ([YearMeasured]);

Tárolási kulcsok forgatása

Érdemes rendszeresen módosítani a blobtároló hozzáférési kulcsát. A Blob Storage-fiókhoz két tárkulcsa van, amelyek lehetővé teszik a kulcsok közötti váltást.

Az Azure Storage-fiókkulcsok elforgatása:

Minden olyan tárfiók esetében, amelynek a kulcsa módosult, az ALTER DATABASE SCOPED CREDENTIAL parancsot kell kibocsáta.

Példa:

Az eredeti kulcs létrejön

CREATE DATABASE SCOPED CREDENTIAL my_credential WITH IDENTITY = 'my_identity', SECRET = 'key1'

Kulcs elforgatása az 1. kulcsról a 2. kulcsra

ALTER DATABASE SCOPED CREDENTIAL my_credential WITH IDENTITY = 'my_identity', SECRET = 'key2'

A mögöttes külső adatforrásokat nem kell másként módosítani.

Kapcsolódó tartalom

  • Last updated on