Megosztás:

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

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.

Betöltő felhasználó létrehozása

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) az adatbázis CONTROL jogosultságait igényli. 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 az á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. Adja meg az előkészítési táblát halomként, és használja a körkörös elosztási beállítást.

Vegye figyelembe, hogy a betöltés általában egy két lépésből álló folyamat, amelyben először betölt egy átmeneti táblába, majd beszúrja az adatokat egy éles adatraktár táblába. Ha az éles tábla kivonateloszlást használ, előfordulhat, hogy a teljes betöltési és beszúrási idő gyorsabb lesz, ha az előkészítési táblát szintén kivonateloszlással definiálja. Az előkészítési táblába való betöltés hosszabb időt vesz igénybe, de a sorok éles táblába való beszúrásának második lépése nem jár adatáthelyezéssel a disztribúciók között.

Betöltés oszlopalapú 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. További részletekért lásd a Columnstore memóriaoptimalizálásitémakört.

  • 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-val, és a SqLBulkCopy API vagy a bcp-t kell használnia, érdemes lehet növelni a csomagméretet 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

Az adatbetöltés, amely külső táblát használ, meghiúsulhat a "Lekérdezés megszakítva – a maximális elvetési küszöbérték elérésekor külső forrásból történő olvasás során". 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 nem megfelelő, elutasíthatja ezeket a rekordokat a lekérdezésekhez a "KÜLSŐ TÁBLA LÉTREHOZÁSA" elutasítási beállításaival.

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 több ezer vagy annál több egyszeri beszúrása van a nap folyamán, csoportosítsa a beszúrásokat, hogy egyszerre töltse be őket. 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ókra, amelynek módosult a kulcsa, ki kell adni ALTER DATABASE SCOPED CREDENTIAL.

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