SQL-analytiikan päätepisteiden suorituskykyyn liittyvät seikat

SQL-analytiikan päätepiste mahdollistaa datan kyselyn järvenrakennuksessa käyttämällä T-SQL-kieltä ja TDS-protokollaa. Se hyödyntää Fabric tietovarasto moottoria.

Vinkki

Kattavia poikkikuormitusohjeita Delta-taulukoiden optimointiin SQL-analytiikan päätelaitteiden kulutukseen, mukaan lukien tiedostokoko ja riviryhmäsuositukset, löytyy kohdasta Cross-workload table ylläpito ja optimointi.

Jokaisella Lakehousella on yksi SQL-analytiikan päätepiste. Työtilan SQL-analytiikan päätepisteiden määrä vastaa kyseisessä työtilassa valmistettujen Lakehouse-tietokantojen ja peilattujen tietokantojen määrää.

Taustaprosessi vastaa järvitalon muutosten skannauksesta ja SQL-analytiikan päätepisteen up-topäivämääränä kaikille työtilaan tehtyjen muutosten osalta. Fabric-alusta hallinnoi synkronointiprosessia läpinäkyvästi. Kun Lakehousessa havaitaan muutos, taustaprosessi päivittää metatiedot ja SQL-analytiikan päätepiste kuvastaa Lakehouse-taulukoihin tehtyjä muutoksia. Normaaleissa käyttöehdoissa lakehouse- ja SQL-analytiikan päätepisteiden välinen viive on alle minuutti. Todellinen kesto voi vaihdella muutamasta sekunnista minuutteihin riippuen monista tässä artikkelissa käsitellyistä tekijöistä. Taustaprosessi toimii SQL-analytiikan päätepisteen ollessa aktiivinen ja pysähtyy 15 minuutin jälkeen ilman kyselytoimintaa.

Ohjausta

Automaattiset metatietojen etsintä seuraa Lakehouseihin tehtyjä muutoksia ja on yksittäinen esiintymä Fabric-työtilaa kohden. Jos huomaat lisääntyneen viiveen muutosten synkronoinnissa lakehousen ja SQL-analytiikan päätepisteen välillä, se voi johtua suuresta määrästä lakehouseja yhdessä työtilassa. Tällaisessa tilanteessa kannattaa harkita jokaisen järvitalon siirtämistä erilliseen työtilaan, sillä tämä lähestymistapa mahdollistaa automaattisen metatietojen löytämisen skaalautumisen.
Jäsennystiedostot ovat rakenteittain muuttumattomia. Kun päivitys tai poisto tapahtuu, Delta-taulukko lisää uusia Parquet-tiedostoja muutosjoukkoon, mikä lisää tiedostojen määrää ajan myötä päivitysten ja poistojen tiheyden mukaan. Jos et aikatauluta ylläpitoa, tämä kaava aiheuttaa lopulta lukukulun ja tämä ehto vaikuttaa siihen, kuinka kauan muutosten synkronointi SQL Analytics päätepisteeseen kuluu. Tämän ongelman ratkaisemiseksi varaa säännölliset järvenmökkäyksen pöytien hoitotoimenpiteet.
Joissain tapauksissa saatat huomata, että lakehouseen tehdyt muutokset eivät näy siihen liittyvässä SQL-analytiikan päätepisteessä. Esimerkiksi voit luoda uuden taulukon Lakehousessa, mutta sitä ei vielä ole listattu SQL-analytiikan päätepisteessä. Tai saatat sitoa suuren määrän rivejä pöytään järvenrakennuksessa, mutta tämä data ei vielä näy SQL-analytiikan päätepisteessä. Voit aloittaa tarpeen mukaan metatietojen synkronoinnin Fabric-portaalissa tai käyttää Refresh SQL -analytiikan päätepisteiden metadata REST API:ta.
Automaattinen synkronointiprosessi ei tue kaikkia Delta-ominaisuuksia. Lisätietoja kunkin Fabric-moduulin tukemista toiminnoista on kohdassa Delta Lake -taulukkomuodon yhteentoimivuus.
Jos Extract Transform and Load (ETL) -käsittelyn aikana tapahtuu erittäin suuri määrä taulukon muutoksia, odotettu viive syntyy, kunnes kaikki muutokset on käsitelty.

Lakehouse-taulukoiden optimointi SQL-analytiikan päätepisteen kyselyihin

Kun SQL-analytiikan päätepiste lukee lakehouseen tallennettuja tauluja, kyselyjen suorituskyky riippuu vahvasti taustalla olevien Parquet-tiedostojen fyysisestä asettelusta. Moottori rinnakkaistaa skannaukset Parquet-tiedostotasolla. Liian monet pienet tiedostot lisäävät tiedostojen ja metatietojen kuormitusta, kun taas liian pienet tiedostot rajoittavat skannauksen rinnakkaisuutta.

Sparkin kirjoittamille tauluille käytä oletusasetuksia Fabric Spark Runtime 2.0:ssa tai uudemmissa versioissa. Nämä ajonaikat mahdollistavat oletuksena adaptiivisen kohdetiedostokoon valitsemisen taulukon mukaan, 128 MB:stä pienemmille tauluille aina 1 GB:iin suurimmilla tauluilla. Vältä staattisten kohteiden asettamista tai satunnaista rivimäärärajoitusta oletusasetusten päälle. Rivirajoitus ei ota huomioon rivin leveyttä ja voi luoda pieniä tiedostoja kapeille tauluille.

Jos käytät Fabric Spark Runtime 1.3:ta, ota käyttöön adaptiiviset kohdetiedostojen koko ja tiedostotason tiivistyskohteet, jotka ovat saatavilla valinnaisina ominaisuuksina.

V-Order hyödyttää ensisijaisesti Power BI Direct Lakea, ja vaikka se voi parantaa pakkausta joissain työkuormissa, sitä ei yleensä vaadita tai suositella oletusarvoisesti optimaalisen SQL-analytiikan päätepisteen suorituskyvyn saavuttamiseksi.

Oletuskirjoitusasetukset eivät korvaa taulun ylläpitoa. Käytä seuraavia käytäntöjä terveen asettelun säilyttämiseksi taulukoiden muuttuessa:

Ota automaattinen tiivistäminen käyttöön työkuormille, joissa ajoittain lisätty synkroninen kirjoitusviive on hyväksyttävä. Automaattinen tiivistys on Spark-ominaisuus, joka toimii vain, kun taulukossa on liikaa pieniä tiedostoja.
Aikatauluta määräaikaiset OPTIMIZE työt työkuormille, joissa automaattisen tiivistyksen aiheuttama lisätty viive ei täytä datan päivitys-SLA-ehtoja.
Suorita VACUUM säilytys- ja aikamatkustusvaatimusten mukaisesti poistaaksesi tiedostot, joihin Delta-loki ei enää viittaa. VACUUM Vähentää säilytettyä tallennustilaa, mutta ei paranna aktiivista tiedostoasettelua.
Vältä korkean kardinaalisuuden osiointia ja räätälöityjä kirjoitusasetuksia, jotka tuottavat paljon pieniä tiedostoja.

Jos et käytä automaattista tiivistämistä, tunnistaaksesi ylläpitoa vaativat taulut, käytä dataputkea ja sys.sp_get_table_health_metrics T-SQL-tallennettua proseduuria ennen suoritusta OPTIMIZE. Opastusta varten katso Optimoi Lakehouse-taulukot terveystarkastusten perusteella.

Muistio

Ohjeita järvenrakennuspöytien yleiseen ylläpitoon löytyy kohdasta Lakehousen ruokkauspöytähuolto.

Osion kokoon huomioitavat seikat

Osioasettelu vaikuttaa siihen, kuinka kauan SQL-analytiikkapäätepisteellä kestää löytää ja synkronoida muutokset. Suuri määrä osioita tai pieniä Parquet-tiedostoja lisää metatietojen skannauksen ylikuormitusta. Noudata näitä käytäntöjä:

Vältä korkean kardinaalisuuden osiosarakkeita, jotka voivat luoda osion jokaiselle ainutlaatuiselle arvolle. Valitse sarakke, joka tuottaa osioita, jotka ovat lähellä tai yli 1 GB. Lisätietoja löytyy Delta Lake -taulukon jakamisesta.
Eräajo- ja suoratoistokäsittely voi luoda pieniä tiedostoja, kun muutokset ovat usein tai pieniä. Käytä säännöllistä järvenpöytien hoitoa näiden kansioiden tiivistämiseen.

Arvioidaksesi kunkin osion koon ja tiedostomäärän, käytä esimerkkiskriptiä osion yksityiskohtiin.

Osion tietojen mallikomentosarja

Käytä seuraavaa muistikirjaa tulostaaksesi raportin, jossa kerrotaan Delta-taulukon taustalla olevien osioiden koko ja yksityiskohdat.

Ensiksi anna ABFSS-polku Delta-taulukollesi muuttujassa delta_table_path.
- Voit hakea delta-taulukon ABFSS-polun Fabric-portaalin resurssienhallinnasta. Napsauta taulukon nimeä hiiren kakkospainikkeella ja valitse COPY PATH sitten vaihtoehtoluettelosta.
Skripti tuottaa kaikki osiot Delta-taululle.
Komentosarja iteroi kunkin osion läpi laskeakseen tiedostojen kokonaiskoon ja -määrän.
Komentosarja tulostaa osioiden, tiedostojen osiokohtaisen ja osiokohtaisen koon tiedot gigatavuina.

Voit kopioida koko skriptin seuraavasta koodilohkosta:

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

Palaute

Onko tästä sivusta apua?

Last updated on 2026-09-16