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.

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 vain, kun SQL-analytiikan päätepiste on aktiivinen, ja se pysähtyy 15 minuutin passiivisuuden jälkeen.

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ä. Sinulla on mahdollisuus aloittaa metadatan synkronointi pyynnöstä.
• 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.

Et tarvitse V-Orderia parantaaksesi SQL-analytiikan päätepisteiden suorituskykyä, sillä Spark kirjoittaa parquet-tiedostoja, jotka ovat Snappy-pakattuja vähentääkseen sekä luku- että kirjoitus-/tuloa.

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.

Osion kokoon huomioitavat seikat

Delta-taulun osion sarakkeen valinta järvenrakennuksessa vaikuttaa myös siihen, kuinka kauan muutosten synkronointi SQL-analytiikkapäätepisteeseen kuluu. Osiosarakkeen osioiden määrä ja koko ovat tärkeitä suorituskyvyn kannalta:

• Jos sarakkeen kardinaliteetti on suuri (enimmäkseen tai kokonaan yksilöllisistä arvoista), tuloksena on suuri määrä osioita. Suuri määrä osioita vaikuttaa kielteisesti metatietojen etsinnän tarkistuksen suorituskykyyn muutosten osalta. Jos sarakkeen kardinaliteetti on suuri, valitse toinen sarake osiointia varten.
• Kunkin osion koko voi myös vaikuttaa suorituskykyyn. Käytä sarakkeeta, jonka osuus on vähintään (tai lähellä) 1 GB. Noudata parhaita käytäntöjä Delta-taulukoiden ylläpidosta ja jakamisesta. Jos haluat Python-skriptin osioiden arviointiin, katso Esimerkkiskripti osion yksityiskohtia varten.

Suuri määrä pienikokoisia parquet-tiedostoja pidentää aikaa, joka lakehousen ja siihen liittyvän SQL-analytiikan päätepisteen välisten muutosten synkronoimiseen kuluu. Saatat päätyä suureen määrään parquet-tiedostoja Delta-taulukossa yhdestä tai useammasta syystä:

• Jos valitset osion Delta-taululle, jossa on paljon uniikkeja arvoja, taulukko on jaettu kunkin yksilöllisen arvon mukaan ja se voi olla ylijakoinen. Valitse osiosarake, jonka kardinaliteetti ei ole suuri, ja saat tulokseksi yksittäiset osiot, joiden kunkin koko on vähintään 1 Gt.
• Erien ja virtautettavien tietojen käsittelynopeudet saattavat myös aiheuttaa pieniä tiedostoja sen mukaan, miten usein ja kuinka suuria muutoksia lakehouse-järjestelmään kirjoitetaan. Esimerkiksi järvenrakennukseen voi tulla pieni määrä muutoksia, mikä johtaa pieniin parkettitiedostoihin. Tämän ongelman ratkaisemiseksi ota käyttöön säännöllinen järvimajan pöytien hoito.

Osion tietojen mallikomentosarja

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

1. 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.
2. Skripti tuottaa kaikki osiot Delta-taululle.
3. Komentosarja iteroi kunkin osion läpi laskeakseen tiedostojen kokonaiskoon ja -määrän.
4. 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']}")

Automaattisesti muodostettu rakenne Lakehousen SQL-analytiikan päätepisteessä

Sql-analytiikan päätepiste luo automaattisesti jokaiselle Lakehousen Delta-taulukolle taulukon, joka sisältää asianmukaisen rakenteen. SQL-analytiikan päätelaitemoottori perustuu Fabric tietovarasto-moottoriin.

Lisätietoja löytyy SQL-analytiikan päätepisteiden metatietojen synkronoinnista. Voit myös ohjelmallisesti pakottaa automaattisen metatietojen skannauksen päivityksen käyttämällä Refresh SQL -päätepisteen metatietoja REST API:lla.

Liittyvä sisältö

• Työkuormataulukon ylläpito ja optimointi
• Delta-järven taulukon optimointi ja V-järjestys
• Pöydän tiivistys
• Tiedostokoon säätäminen
• Lakehouse SQL -analytiikan päätepisteiden käyttötapaukset