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.

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. Microsoft 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.

Suuri määrä pieniä Parquet-tiedostoja aiheuttaa ylikuormitusta ja vaikuttaa negatiivisesti kyselyjen suorituskykyyn. Ennustettavan ja tehokkaan suorituskyvyn varmistamiseksi ylläpidä taulukkotallennus 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 4 GB:ksi.
  4. Suorita OPTIMIZE. Lisätietoja käytöstä OPTIMIZElöytyy kohdasta Suorita pöytähuolto Lakehouselta.

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

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

Tiedostokoon ylläpitämiseksi suorita säännöllisesti Delta-optimointioperaatioita, kuten OPTIMIZE, erityisesti taulukoille, jotka saavat usein lisäyksiä, 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.

Muistio

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

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. 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 optimoinnista. 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 saada suuren määrän parquet-tiedostoja delta-taulukkoon 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

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

  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. 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.

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ö

  • Last updated on