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.

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 Microsoft Fabric platform transzparensen 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 kis Parquet-fájlok nagy száma többletterhelést okoz, és negatívan befolyásolja a lekérdezés teljesítményét. A kiszámítható és hatékony teljesítmény biztosítása érdekében tartsa karban a táblatárolót úgy, hogy minden Parquet-fájl kétmillió sort tartalmazzon. Ez a sorszám kiegyensúlyozott párhuzamosságot biztosít anélkül, hogy az adathalmazt túlzottan kis szeletekre töredékeli.

A sorok számának útmutatása mellett a fájlméret is ugyanilyen fontos. Az SQL Analytics-végpont akkor teljesít a legjobban, ha a Parquet-fájlok elég nagyok ahhoz, hogy minimalizálják a fájlkezelési többletterhelést, de nem olyan nagyok, hogy korlátozzák a párhuzamos vizsgálat hatékonyságát. A legtöbb számítási feladat esetében az egyes Parquet-fájlok 400 MB-hoz közeli megtartása a legjobb egyensúlyt teremti. Az egyensúly eléréséhez kövesse az alábbi lépéseket:

1. Állítsa be maxRecordsPerFile 2 000 000-et az adatváltozások előtt.
2. Végezze el az adatmódosításokat (adatbetöltés, frissítések, törlések).
3. Állítsa maxFileSize 4 GB-ra.
4. Futtassa a OPTIMIZE programot. A(z) OPTIMIZE használatának részleteiért lásd: Táblakarbantartás futtatása Lakehouse-ból.

A következő szkript sablont biztosít ezekhez a lépésekhez, és egy tóházban kell végrehajtani:

from delta.tables import DeltaTable

# 1. CONFIGURE LIMITS

# Cap files to 2M rows during writes. This should be done before data ingestion occurs. 
spark.conf.set("spark.sql.files.maxRecordsPerFile", 2000000)

# 2. INGEST DATA
# Here, you ingest data into your table 

# 3. CAP FILE SIZE (~4GB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 4 * 1024 * 1024 * 1024)

# 4. RUN OPTIMIZE (bin-packing)
spark.sql("""
    OPTIMIZE myTable
""")

Az egészséges fájlméretek fenntartása érdekében rendszeresen futtassa a Delta optimalizálási műveleteit, például OPTIMIZEa gyakori növekményes beszúrásokat, frissítéseket és törléseket fogadó táblák esetében. Ezek a karbantartási műveletek kis fájlokat tömörítenek a megfelelő méretű fájlokba, így biztosítva, hogy az SQL Analytics-végpont hatékonyan tudja feldolgozni a lekérdezéseket. A karbantartást igénylő táblák intelligens optimalizálásához használjon egy adatfolyamot és a sys.sp_get_table_health_metrics tárolt T-SQL-eljárást annak meghatározásához, hogy egy táblának mikor van szüksége a OPTIMIZE parancsra. Oktatóanyagért tekintse meg a Lakehouse-táblák optimalizálása állapotellenőrzések alapján című témakört.

Partícióméret-szempontok

A lakehouse-beli deltatáblák partícióoszlopának kiválasztása az SQL Analytics-végpont módosításainak szinkronizálásához szükséges időt is befolyásolja. 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övesse a deltatáblák karbantartására és optimalizálására vonatkozó ajánlott eljárásokat. 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. Egy vagy több okból előfordulhat, hogy egy deltatáblában nagyszámú parquet fájl található.

• 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

Az alábbi jegyzetfüzet segítségével kinyomtathat egy jelentést, amely részletesen ismerteti a deltatáblát alátámasztó partíciók méretét és részleteit.

1. Először adja meg a delta tábla ABFSS-útvonalát a(z) delta_table_path változóban.
   • 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 a deltatábla összes partíciójának kimenetét adja ki.
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

• Különböző számítási feladatok tábláinak karbantartása és -optimalizálása
• Delta Lake-táblaoptimalizálás és V-Order
• Tábla tömörítése
• Fájlméret finomhangolása
• Lakehouse SQL Analytics-végpont használati esetei