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. A Fabric Data Warehouse motort használja ki.

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 akkor fut, amikor az SQL analitika végpont aktív, és 15 perc után leáll lekérdezés nélkül.

Ú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. Elkezdheted a metadat-szinkronizációt a Fabric portálban, vagy használhatod a Refresh SQL analitika végpont metadata REST API-t.
  • 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.

A V-Order elsősorban a Power BI Direct Lake-et támogatja, és bár javíthatja a tömörítést bizonyos munkaterheléseknél, általában alapból nem kötelező vagy ajánlott az optimális SQL analitikai végpontteljesítmény érdekében.

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 partíció elrendezése befolyásolja, mennyi időbe telik az SQL analitikai végpont a változások felfedezése és szinkronizálása. Nagy számú partíció vagy kis Parquet fájl növeli a metaadat-szkennelési költségeket. Kövesse az alábbi eljárásokat:

  • Kerüld a magas kardinalitású partíciós oszlopokat, amelyek minden egyedi értékhez külön partíciót hozhatnak létre. Válassz egy oszlopot, amely 1 GB vagy annál nagyobb partíciókat eredményez. További információért lásd: Delta Lake táblafelosztás.
  • A kötegelt és a streamalapú adatbetöltés kis fájlokat hozhat létre, ha a változások gyakoriak vagy kicsik. A fájlok tömörítéséhez rendszeresen használjon Lakehouse-táblakarbantartást.

Az egyes partíciók méretének és fájlszámának értékeléséhez a mintaszkriptet használjuk a partíció részleteihez.

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']}")

Kapcsolódó tartalom

  • Last updated on