Jaa

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

Koskee:✅ SQL-analytiikan päätepiste Microsoft Fabricissa

SQL-analytiikan päätepisteen avulla voit tehdä kyselyjä lakehousessa 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 on vastuussa Lakehousen muutosten skannaamisesta ja SQL-analytiikan päätepisteiden pitämisestä ajan tasalla kaikista lakehouseihin määritetyistä muutoksista työtilassa. Synkronointiprosessia hallitsee läpinäkyvästi Microsoft Fabric -ympäristö. 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 monien tässä artikkelissa käsiteltyjen tekijöiden mukaan. Taustaprosessi toimii vain, kun SQL-analytiikan päätepiste on aktiivinen ja se pysähtyy 15 minuutin passiivisuuden jälkeen.

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

SQL-analytiikan päätepiste hallitsee automaattisesti luotuja taulukoita, jotta työtilan käyttäjät eivät voi muokata niitä. Käyttäjät voivat täydentää tietokantamallia lisäämällä omia SQL-rakenteensa, näkymänsä, toimintosanansa ja muita tietokantaobjekteja.

Sql-analytiikan päätepiste luo automaattisesti jokaiselle Lakehousen Delta-taulukolle taulukon, joka sisältää asianmukaisen rakenteen. Jos haluat käyttää SQL-analytiikan päätepisteen automaattisesti luotuja rakennetietotyyppejä, tutustu ohjeartikkeliin Microsoft Fabricin tietotyypit.

SQL-analytiikan päätepisteen taulukot luodaan pienellä viiveellä. Kun luot tai päivität Delta Lake -taulun järvessä, SQL-analytiikan päätepistetaulukko, joka viittaa Delta Lake -taulukkoon, luodaan ja päivitetään automaattisesti.

Taulukon päivittämiseen kuluva aika liittyy siihen, miten optimoituja Delta-taulukot ovat. Jos haluat lisätietoja, tutustu Delta Lake -taulukon optimointiin ja V-Orderiin , jos haluat lisätietoja tärkeistä skenaarioista, ja syvällisempää opasta siitä, miten voit ylläpitää tehokkaasti Delta-taulukoita suorituskyvyn parantamiseksi.

Voit manuaalisesti pakottaa automaattisen metatietojen skannauksen Fabric-portaalissa. Päivitä rakenne valitsemalla SQL-analytiikan päätepisteen sivulla Päivitä-painike Resurssienhallinta-työkalurivillä. Siirry kyselyn SQL-analytiikan päätepisteeseen ja etsi päivityspainike seuraavassa kuvassa esitetyllä tavalla.

Kangasportaalin näyttökuva, jossa näkyy SQL-analytiikan päätepisteen Päivitysrakenne-painike.

Voit myös ohjelmallisesti pakottaa automaattisen metatietojen tarkistuksen päivittämään käyttämällä Päivitä SQL -päätepisteen metatietojen REST-ohjelmointirajapintaa.

Ohjeet

  • Automaattiset metatietojen etsintä seuraa Lakehouseihin tehtyjä muutoksia ja on yksittäinen esiintymä Fabric-työtilaa kohden. Jos havaitset lisääntyneitä viiveitä muutosten synkronoinnissa lakehousen ja SQL-analytiikan päätepisteen välillä, syynä voi olla suuri määrä lakehouseja yhdessä työtilassa. Tällaisessa skenaariossa harkitse kunkin lakehousen siirtämistä erilliseen työtilaan, sillä se mahdollistaa automaattisen metatietojen etsimisen skaalaamisen.
  • Jäsennystiedostot ovat rakenteittain muuttumattomia. Kun kyseessä on päivitys- tai poistotoiminto, Delta-taulukko lisää uudet parquet-tiedostot muutosjoukon kanssa, mikä kasvattaa tiedostojen määrää ajan kuluessa päivitysten ja poistojen tiheyden mukaan. Jos ylläpitoa ei ole ajoitettu, tämä malli luo lukukuormituksen, mikä vaikuttaa aikaan, joka kuluu muutosten synkronoimiseen SQL-analytiikan päätepisteeseen. Voit korjata tämän ajoittaaksesi säännöllisesti Lakehousen taulukoiden ylläpitotoimia.
  • Joissain tapauksissa saatat huomata, että lakehouseen tehdyt muutokset eivät näy siihen liittyvässä SQL-analytiikan päätepisteessä. Olet ehkä esimerkiksi luonut uuden taulukon Lakehousessa, mutta sitä ei ole vielä lueteltu SQL-analytiikan päätepisteessä. Tai saatat olla sitonut suuren määrän rivejä pöytään järvenrakennuksessa, mutta tämä data ei vielä näy SQL-analytiikan päätepisteessä. Suosittelemme, että aloitat tarvittaessa suoritettavan metatietojen synkronoinnin, joka käynnistetään SQL-kyselyeditorin Päivitä valintanauha -vaihtoehdosta tai Päivitä SQL-päätepisteiden metatiedot REST-ohjelmointirajapinnasta. Tämä vaihtoehto pakottaa pyydettäessä suoritettavat metatietojen synkronoinnin sen sijaan, että odottaisivat taustan metatietojen synkronointia loppuun.
  • Automaattinen synkronointiprosessi ei ymmärrä kaikkia Delta-ominaisuuksia. Lisätietoja kunkin Fabric-moduulin tukemista toiminnoista on kohdassa Delta Lake -taulukkomuodon yhteentoimivuus.
  • Jos Extract Transform and Load (ETL) -prosessoinnin aikana tapahtuu erittäin suuri määrä taulukoiden muutoksia, odotettu viive voi syntyä, kunnes kaikki muutokset on käsitelty.

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

Kun SQL-analytiikan päätepiste lukee lakehouseen tallennettuja tauluja, kyselyiden suorituskykyyn vaikuttaa vahvasti taustalla olevien parquet-tiedostojen fyysinen asettelu.

Suuri määrä pieniä parkettitiedostoja aiheuttaa ylikuormitusta ja vaikuttaa negatiivisesti kyselyjen suorituskykyyn. Ennustettavan ja tehokkaan suorituskyvyn varmistamiseksi suosittelemme ylläpitämään taulukkotallennusta siten, että jokaisessa parquet-tiedostossa on kaksi miljoonaa riviä. Tämä rivimäärä tarjoaa tasapainoisen rinnakkaisuuden ilman, että aineisto pilkkoutuu liian pieniin osiin.

Rivimääräohjeistuksen lisäksi tiedostokoko on yhtä tärkeä. SQL-analytiikan päätepiste toimii parhaiten, kun parquet-tiedostot ovat tarpeeksi suuria minimoimaan tiedostojen käsittelyn ylikuormituksen, mutta eivät niin suuria, että ne rajoittaisivat rinnakkaisskannauksen tehokkuutta. Useimmissa työkuormissa yksittäisten parquet-tiedostojen pitäminen lähellä 400 MB:tä on paras tasapaino. Tämän tasapainon saavuttamiseksi käytä seuraavia vaiheita:

  1. Asetettuna maxRecordsPerFile 2 000 000:een ennen datan muutoksia.
  2. Suorita datan muutokset (datan vastaanotto, päivitykset, poistot).
  3. Asetettu maxFileSize 400 MB:iin.
  4. Suorita OPTIMIZE. Lisätietoja käytöstä OPTIMIZElöytyy taulukon ylläpitotoiminnoista.

Seuraava skripti tarjoaa mallin näille vaiheille, ja ne tulisi suorittaa järvenrakennuksessa:

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 (~400 MB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 400 * 1024 * 1024)

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

Jotta tiedostokoot pysyvät terveinä, käyttäjien tulisi ajoittain suorittaa Delta-optimointitoimintoja, kuten OPTIMIZE, erityisesti tauluille, jotka saavat usein asteittaisia kirjoituksia, päivityksiä ja poistoja. Nämä ylläpitotoiminnot tiivistävät pienet tiedostot sopivan kokoisiksi, auttaen varmistamaan, että SQL-analytiikan päätepiste pystyy käsittelemään kyselyt tehokkaasti.

Note

Lakehouse-pöytien yleiseen ylläpitoon saat katso artikkelista Execute ad-hoc table maintenance on a Delta table using Lakehouse.

Osion kokoon huomioitavat seikat

Lakehousen delta-taulukon osiosarakkeen valinta vaikuttaa myös aikaan, joka kuluu muutosten synkronoimiseen SQL-analytiikan päätepisteeseen. 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. Suosituksemme on käyttää saraketta, jonka osion koko olisi vähintään (tai lähellä) 1 Gt. Suosittelemme seuraamaan parhaita käytäntöjä delta-taulukoiden ylläpitoa varten. optimointi. Jos haluat python-komentosarjan arvioivan osioita, katso osion tiedot kohdasta Näytekomentosarja.

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

  • Jos valitset osion delta-taulukolle, jossa on paljon yksilöllisiä arvoja, se ositetaan kunkin yksilöllisen arvon mukaan ja se saattaa olla yliositettu. 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 korjaamiseksi suosittelemme lakehouse-taulukoiden säännöllistä ylläpitoa.

Osion tietojen mallikomentosarja

Seuraavan muistikirjan avulla voit tulostaa raportin, jossa on yksityiskohtaiset tiedot delta-taulukkoa tukevien osioiden koosta ja yksityiskohdista.

  1. Ensin sinun on annettava delta-taulukkosi ABSFF-polku 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. Komentosarja tulostaa kaikki delta-taulukon osiot.
  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.

Koko komentosarja voidaan kopioida 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']}")

Liittyvä sisältö

  • Last updated on