SQL Analytics-végpont teljesítményével kapcsolatos szempontok

Az SQL Analytics-végpont lehetővé teszi a lakehouse-beli adatok lekérdezését T-SQL-nyelv és TDS-protokoll használatával.

Jótanács

Az SQL Analytics-végponthasználat deltatábláinak optimalizálásával kapcsolatos átfogó, számítási feladatok közötti útmutatásért, beleértve a fájlméretet és a sorcsoportra vonatkozó javaslatokat, tekintse meg a számítási feladatok közötti táblák karbantartását és optimalizálását.

Minden lakehouse-nak van egy SQL Analytics-végpontja. A munkaterületen található SQL Analytics-végpontok száma megegyezik az adott munkaterületen kiépített tóházak és tükrözött adatbázisok számával.

Egy háttérfolyamat felel a lakehouse változásainak figyeléséért, valamint azért, hogy a munkaterület lakehouse-aiban véglegesített összes módosítás alapján naprakészen tartsa az SQL-elemzési végpontot. A Fabric platform átláthatóan kezeli a szinkronizálási folyamatot. Ha változás észlelhető egy lakehouse-ban, a háttérfolyamat frissíti a metaadatokat, az SQL Analytics-végpont pedig a lakehouse-táblákban lekötött változásokat tükrözi. Normál üzemeltetési körülmények között a lakehouse és az SQL Analytics-végpont közötti késés kevesebb, mint egy perc. A tényleges időtartam néhány másodperctől percig változhat a cikk által tárgyalt számos tényezőtől függően. A háttérfolyamat csak akkor fut, ha az SQL Analytics-végpont aktív, és 15 perc inaktivitás után leáll.

Útmutatás

  • Az automatikus metaadatok felderítése nyomon követi a lakehouse-okkal kapcsolatos módosításokat, és egy Fabric munkaterületen csak egy példányban létezik. Ha megnövekedett késést tapasztal a lakehouse-k és az SQL Analytics-végpont közötti szinkronizálási módosítások esetében, annak oka lehet, hogy egy munkaterületen sok tóház található. Ilyen esetben fontolja meg az egyes lakehouse-k külön munkaterületre való migrálását, mivel ez a megközelítés lehetővé teszi az automatikus metaadatok felderítésének skálázását.
  • A parquet-fájlok tervezés szerint nem módosíthatók. Frissítés vagy törlési művelet esetén a Delta-tábla új Parquet-fájlokat ad hozzá a módosításkészlettel, ami a frissítések és törlések gyakoriságától függően idővel növeli a fájlok számát. Ha nem ütemez karbantartást, ez a minta végül olvasási többletterhelést okoz, és ez a feltétel befolyásolja az SQL Analytics-végpont módosításainak szinkronizálásához szükséges időt. A probléma megoldásához ütemezze a lakehouse-táblák rendszeres karbantartási műveleteit.
  • Bizonyos esetekben megfigyelheti, hogy a lakehouse-ban végrehajtott módosítások nem láthatók a társított SQL Analytics-végponton. Létrehozhat például egy új táblát a Lakehouse-ban, de még nem szerepel az SQL Analytics-végpontban. Előfordulhat például, hogy sok sort rögzít egy lakehouse-ban lévő táblába, de ezek az adatok még nem láthatók az SQL-analitikai végponton. Lehetősége van igény szerinti metaadat-szinkronizálás indítására.
  • Az automatikus szinkronizálási folyamat nem támogatja az összes Delta-funkciót. A Fabricben az egyes motorok által támogatott funkciókkal kapcsolatos további információkért lásd a Delta Lake táblaformátum együttműködési lehetőségeit.
  • Ha rendkívül nagy mennyiségű táblamódosítás történik az ETL-feldolgozás során, a várt késés az összes módosítás feldolgozásáig következik be.

Lakehouse-táblák optimalizálása az SQL Analytics-végpont lekérdezéséhez

Amikor az SQL Analytics-végpont egy tóházban tárolt táblákat olvas be, a lekérdezési teljesítmény nagymértékben függ az alapul szolgáló Parquet-fájlok fizikai elrendezésétől. A motor a beolvasásokat a Parquet-fájlok szintjén párhuzamosítja. Túl sok kis fájl növeli a fájl- és metaadat-terhet, míg a túl kevés fájl korlátozhatja a szkennelés párhuzamosságát.

A Spark által írt táblákhoz használd az alapértelmezett beállításokat a Fabric Spark runtime 2.0 vagy újabb verzióban. Ezek a futásidők alapértelmezés szerint lehetővé teszik az adaptív célfájl méret kiválasztását a táblázat szerinti legoptimálisabb célfájlméret kiválasztásához, kisebb táblák esetén 128 MB-tól 1 GB-ig a legnagyobb tábláknál. Kerüld el, hogy az alapértelmezett konfigurációkon felül rögzített célértékeket vagy tetszőleges sorszámlimitet állíts be. A sorkorlát nem veszi figyelembe a sorszélességet, és kis fájlokat hozhat létre keskeny táblákhoz.

Ha a Fabric Spark runtime 1.3-at használod, engedélyezd az adaptív célfájlméret és a fájlszintű tömörítési célokat, amelyek opt-in funkcióként elérhetők.

Nincs szükség V-Orderre az SQL analitikai végpont teljesítményének javításához, mivel a Spark Snappy tömörített parquet fájlokat ír, hogy csökkentse az olvasási és írási I/O-t.

Az alapértelmezett írási beállítások nem helyettesítik a táblakarbantartást. Alkalmazza az alábbi módszereket az egészséges elrendezés megőrzésére a táblázatok változásakor:

  • Engedélyezze az automatikus tömörítést olyan munkák esetén, ahol a időszakosan hozzáadott szinkron írási késleltetés elfogadható. Az automatikus tömörítés egy Spark funkció, amely csak akkor fut, ha túl sok kis fájl van egy táblázatban.
  • Ütemezz időszakos OPTIMIZE feladatokat olyan terhelésekhez, ahol az automatikus tömörítés által hozzáadott időszakos késleltetés nem felel meg az adatfrissítési SLA-knak.
  • A megtartási és az időutazási követelményeidnek megfelelően futtasd a(z) VACUUM parancsot a Delta-napló által már nem hivatkozott fájlok eltávolításához. VACUUM csökkenti a megtartott tárhelyet, de nem javítja az aktív fájlelrendezést.
  • Kerüld a magas kardinalitású partíciókat és a testreszabott író konfigurációkat, amelyek sok apró fájlt hoznak létre.

Ha nem használod az automatikus tömörítést, a karbantartásra szoruló táblák azonosításához használj adatvezetéket és a sys.sp_get_table_health_metrics T-SQL tárolt eljárást a OPTIMIZEfuttatás előtt. Oktatóanyagért tekintse meg a Lakehouse-táblák optimalizálása állapotellenőrzések alapján című témakört.

Note

A lakehouse-táblák általános karbantartásával kapcsolatos útmutatásért lásd a következőt: Táblakarbantartás futtatása a Lakehouse-ban.

Partícióméret-szempontok

A Delta tábla partícióoszlopának kiválasztása egy tóházban szintén befolyásolja, mennyi időbe telik a változások szinkronizálása az SQL analitikai végponttal. A partícióoszlop partícióinak száma és mérete fontos a teljesítmény szempontjából:

  • A nagy számosságú (többnyire vagy teljesen egyedi értékekből álló) oszlop nagy számú partíciót eredményez. Sok partíció negatívan befolyásolja a metaadatok felderítésének teljesítményét a módosítások keresésekor. Ha egy oszlop számossága magas, válasszon egy másik oszlopot a particionáláshoz.
  • Az egyes partíciók mérete a teljesítményt is befolyásolhatja. Olyan oszlopot használjon, amely legalább 1 GB-os (vagy ahhoz közeli) partíciót eredményez. Kövesd a legjobb gyakorlatokat a Delta táblák karbantartásához és partíciójához. A partíciók kiértékeléséhez Python szkriptet a Sample szkriptben találja a partíció részleteiről.

Nagy mennyiségű kis méretű parquet-fájl növeli a lakehouse és a hozzá tartozó SQL Analytics-végpont közötti módosítások szinkronizálásának idejét. Előfordulhat, hogy egy Delta-táblában egy vagy több ok miatt sok parquet-fájl lesz:

  • Ha egy Delta-táblához olyan partíciót választ, amely sok egyedi értéket tartalmaz, a tábla minden egyes egyedi érték szerint lesz particionálva, ezért előfordulhat, hogy túlzottan particionált lesz. Válasszon olyan partícióoszlopot, amely nem rendelkezik magas számossággal, és egyenként legalább 1 GB-ot eredményez.
  • A kötegelt és streamelési adatbetöltési arányok kis fájlokat is eredményezhetnek a lakehouse-ba írt módosítások gyakoriságától és méretétől függően. Előfordulhat például, hogy egy kis mennyiségű módosítás érkezik a tóházba, ami kis parkettafájlokat eredményez. A probléma megoldásához valósítsa meg a lakehouse-táblák rendszeres karbantartását.

Példaszkript a partíció részleteihez

A következő jegyzetfüzetet használva nyomtasd ki a jelentést, amely részletezi a Delta tábla alapját képező partíciók méretét és részleteit.

  1. Először adja meg az ABFSS útvonalat a Delta táblához a változóban delta_table_path.
    • A Delta-tábla ABFSS-elérési útját a Fabric portál Explorer részéből szerezheti be. Kattintson a jobb gombbal a tábla nevére, majd válasszon COPY PATH a lehetőségek listájából.
  2. A szkript adja ki az összes partíciót a Delta táblához.
  3. A szkript minden partíción végigfut a fájlok teljes méretének és számának kiszámításához.
  4. A szkript a partíciók részleteit, a partíciónkénti fájlokat és a partíciónkénti méretet adja ki GB-ban.

A teljes szkriptet a következő kódblokkból másolhatja:

# Purpose: Print out details of partitions, files per partitions, and size per partition in GB.
from notebookutils import mssparkutils

# Define ABFSS path for your delta table. You can get ABFSS path of a delta table by simply right-clicking on table name and selecting COPY PATH from the list of options.
delta_table_path = "abfss://<workspace id>@<onelake>.dfs.fabric.microsoft.com/<lakehouse id>/Tables/<tablename>"

# List all partitions for given delta table
partitions = mssparkutils.fs.ls(delta_table_path)

# Initialize a dictionary to store partition details
partition_details = {}

# Iterate through each partition
for partition in partitions:
  if partition.isDir:
      partition_name = partition.name
      partition_path = partition.path
      files = mssparkutils.fs.ls(partition_path)
      
      # Calculate the total size of the partition

      total_size = sum(file.size for file in files if not file.isDir)
      
      # Count the number of files

      file_count = sum(1 for file in files if not file.isDir)
      
      # Write partition details

      partition_details[partition_name] = {
          "size_bytes": total_size,
          "file_count": file_count
      }
      
# Print the partition details
for partition_name, details in partition_details.items():
  print(f"{partition_name}, Size: {details['size_bytes']:.2f} bytes, Number of files: {details['file_count']}")

Automatikusan létrehozott séma a Lakehouse SQL Analytics-végpontjában

A Lakehouse minden Delta-táblájához az SQL Analytics-végpont automatikusan létrehoz egy táblát a megfelelő sémában. Az SQL Analytics végpontmotorja a Fabric Data Warehouse motoron alapul.

További információ: SQL Analytics-végpont metaadatainak szinkronizálása. Az automatikus metaadat-vizsgálat frissítését programozott módon is kényszerítheti az SQL-végpont metaadatainak REST API-val történő frissítésével.

Kapcsolódó tartalom

  • Last updated on