Direct Lake -kyselyn suorituskyvyn ymmärtäminen

Semanttisen mallin rakenteen ja kyselyn monimutkaisuuden lisäksi Direct Laken suorituskyky riippuu erityisesti hyvin viritetyistä Delta-taulukoista, jotta sarakkeiden lataaminen on tehokasta ja nopeaa (transkoodausta) ja optimaalinen kyselyn suorittaminen. Varmista, että käytät V-Order-optimointia. Pidä myös Parquet-tiedostojen määrä pienenä, käytä suuria riviryhmiä ja pyri minimoimaan tietopäivitysten vaikutukset Delta-lokiin. Nämä ovat yleisiä parhaita käytäntöjä, jotka voivat auttaa varmistamaan nopean kyselyn suorittamisen kylmässä, puolilämmitys-, lämmin- ja kuumassa Direct Lake -tilassa.

Tässä artikkelissa kerrotaan, miten Direct Laken suorituskyky riippuu Delta-taulukon kunnosta ja tehokkaista tietojen päivityksistä. Näiden riippuvuuksien ymmärtäminen on tärkeää. Opit, että Parquet-tiedostojen tietojen asettelu on yhtä tärkeää kyselyn suorituskyvyn kannalta kuin hyvä semanttinen mallirakenne ja hyvin viritettyjen tietojen analysointilausekkeen (DAX) mittarit.

Mitä sinun tarvitsee tietää

Tässä artikkelissa oletetaan, että olet jo tutustunut seuraaviin käsitteisiin:

• OneLaken Delta-taulukot: Tarkempia tietoja OneLaken Delta-taulukoista on saatavilla Microsoft Fabric fundamentals -dokumentaatiossa.
• Parquet-tiedostot, riviryhmät ja Delta-loki: Parquet-tiedostomuotoa, mukaan lukien sitä, miten tiedot on järjestetty riviryhmiin ja sarakelohkoihin, ja miten metatietoja käsitellään, käsitellään Parquet-tiedostomuotoa käsittelevässä dokumentaatiossa. Katso myös Delta-tapahtumalokiprotokollan dokumentaatio.
• Delta-taulukkooptimointi ja V-Order: Tutustu Fabric Lakehouse -dokumentaatioon Delta-taulukoiden ylläpidosta, kuten Delta Lake -taulukon optimoinnista ja V-Orderista.
• Framing ja transkoodaus: Direct Lake -järjestelmän semanttisen mallin (kehystys) ja sarakkeen tietojen lataaminen (transkoodaus) päivittäminen ovat tärkeitä käsitteitä, joita käsitellään Direct Lake -yleiskatsauksen johdantotasolla.
• Kaava ja säilömoduuli: Kun DAX-kysely suoritetaan, kaavamoduuli luo kyselysuunnitelman ja hakee tarvittavat tiedot ja alkuperäiset koosteet säilömoduulista. Tässä artikkelissa käsitellyt optimoinnit keskittyvät säilömoduuliin. Lisätietoja kaavamoduulista ja säilömoduulista on Analysis Servicesin kehittäjien dokumentaatiossa.
• VertiPaq ja VertiScan: Tuontitilassa ja Direct Lake -tilassa säilömoduuli käyttää VertiPaq-moduuliaan sarakkeen ylläpitämiseen muistissa. VertiScan mahdollistaa kaavamoduulin vuorovaikutuksen VertiPaqin kanssa. Lisätietoja on Analysis Servicesin kehittäjien dokumentaatiossa.
• Sanaston koodaus: Sekä Parquet-tiedostot että VertiPaq käyttävät hakemistokoodausta. Se on tietojen pakkaustekniikka, jota käytetään eri tietotyyppien yksittäisissä sarakkeissa, kuten int, long, date ja char. Se toimii tallentamalla kaikki yksilölliset sarakearvot muistiin kokonaislukuna käyttämällä Suorituksen pituus -koodausta (RLE) /Bit-Packing Hybridikoodausta. VertiPaq käyttää aina hakemistokoodausta, mutta Parquet saattaa joissakin tilanteissa vaihtaa pelkkään koodaamiseen tai delta-koodaamiseen, kuten Parquet File-Format -dokumentaation koodauksessa selitetään, jolloin Direct Lake -koodaus uudelleen koodaaisi tiedot niin, että ne vaikuttavat transkoodauksen suorituskykyyn.
• Sarakelohkot ja sarakesegmentit: Katso, miten Parquet ja VertiPaq tallentavat saraketiedot tehokkaaksi tietojen noutamiseksi. Taulukon jokainen sarake on jaettu pienempiin paloihin, jotka voidaan käsitellä ja pakata itsenäisesti. VertiPaq kutsuu näitä lohkoja segmenteillä. Voit noutaa DISCOVER_STORAGE_TABLE_COLUMN_SEGMENTS rakennerivijoukon avulla tietoja Direct Lake -semanttisen mallin sarakesegmenteistä.
• Python ja Jupyter Notebooks: Jupyter Notebooks tarjoaa vuorovaikutteisen ympäristön Python-koodin kirjoittamiseen ja suorittamiseen. Pythonin perustietämyksestä on hyötyä, jos haluat seurata tämän luvun myöhempiä koodikatkelmia. Lisätietoja on artikkelissa Python-kielen viittaus. Lisätietoja muistikirjojen käytöstä Microsoft Fabricissa on kohdassa Muistikirjojen käyttö – Microsoft Fabric.

Mikä vaikuttaa Direct Lake -kyselyn suorituskykyyn

Tässä osiossa on yhteenveto direct lake -järjestelmän suorituskykyyn vaikuttavista tärkeimmistä tekijöistä. Seuraavissa osioissa on tarkempia selityksiä:

• V-tilausten pakkaaminen: Pakkaamisen tehokkuus voi vaikuttaa kyselyn suorituskykyyn, sillä parempi pakkaus johtaa nopeampaan tietojen lataamiseen ja tehokkaampaan kyselyjen käsittelemiseen. Tietojen lataaminen on nopeaa, koska suoratoistettavien tietojen siirto tehostaa koodausta. Kyselyn suorituskyky on myös optimaalinen, koska V-Order-pakkaus mahdollistaa sen, että VertiScan voi laskea tulokset suoraan pakattujen tietojen päälle ohittaen pakkaamisvaiheen.
• Tietotyypit: Asianmukaisten tietotyyppien käyttäminen sarakkeille voi parantaa pakkausta ja suorituskykyä. Käytä mahdollisuuksien mukaan esimerkiksi kokonaislukutietotyyppejä merkkijonojen sijaan ja vältä kokonaislukujen tallentamista merkkijonoina.
• Segmentin koko ja määrä: VertiPaq tallentaa saraketiedot segmentteihin. Suuri määrä pienempiä segmenttejä voi vaikuttaa kielteisesti kyselyn suorituskykyyn. Suurissa taulukoissa Direct Lake suosii suuria segmenttien kokoja, kuten 1–16 miljoonaa riviä.
• Sarakkeen kardinaliteetti: Suuren kardinaliteetin sarakkeet (sarakkeet, joilla on useita yksilöllisiä arvoja) voivat hidastaa suorituskykyä. Kardinaliteetin vähentäminen mahdollisuuksien mukaan voi auttaa.
• Indeksit ja koosteet: Sarakkeet, joiden kardinaliteetti on pienempi, hyötyvät hakemiston koodaamisesta, mikä voi nopeuttaa kyselyitä vähentämällä luettavan tiedon määrää.
• DirectQuery-varatoiminto: Varatoiminnot saattavat hidastaa kyselyn suorituskykyä, koska tiedot on nyt noudettava Fabric-tietolähteen SQL-analytiikan päätepisteestä. Lisäksi varajärjestelyt perustuvat hybridikyselysuunnitelmiin, joiden avulla sekä DirectQuery että VertiScan tukevat joitakin kompromisseja suorituskykyyn silloinkin, kun Direct Laken ei tarvitse varajärjestelyitä. Jos mahdollista, poista DirectQuery-varatila käytöstä, jotta vältät hybridikyselysuunnitelmat.
• Muistin sijainnin aste: Direct Lake -semanttiset mallit voivat olla kylmässä, puolisotaa, lämmintä tai kuumaa tilaa, jossa suorituskyky on yhä parempi kylmästä kuumaan. Siirtyminen nopeasti kylmästä lämpimään on avain hyvään Direct Lake -suorituskykyyn.
  • Kylmä: VertiPaq-myymälä on tyhjä. Kaikki tiedot, joita tarvitaan DAX-kyselyyn vastaamiseen, on ladattava Delta-taulukoista.
  • Semiwarm: Direct Lake pudottaa vain kyseiset sarakesegmentit poistettuihin riviryhmiin kuuluvien kehysten aikana. Tämä tarkoittaa sitä, että vain päivitetyt tai äskettäin lisätyt tiedot on ladattava. Semanttinen Direct Lake -malli voi myös siirtyä puolisotatilaan muistipaineen alla, kun sen on purettava segmentit ja liitettävä indeksit muistipaineen vuoksi.
  • Lämmin: DAX-kyselyyn vastaamiseen tarvittavat saraketiedot ovat jo täysin ladattuja muistiin.
  • Kuumana: Saraketiedot on jo ladattu kokonaan muistiin, VertiScan-välimuistit täytetään ja DAX-kyselyt kohdistuvat välimuistiin.
• Muistipaine: Direct Lake -järven on ladattava kaikki saraketiedot, joita tarvitaan DAX-kyselyn vastaamiseen muistiin, mikä voi tyhjentää käytettävissä olevat muistiresurssit. Jos muisti ei riitä, Direct Laken on purettava aiemmin ladatut saraketiedot, jotka Direct Lake saattaa sitten joutua lataamaan uudelleen myöhemmissä DAX-kyselyissä. Direct Lake -semanttisten mallien riittävä koon muuttaminen voi auttaa välttämään useita uudelleenlataamisia.

Muistin tallentaminen ja kyselyjen suorituskyky

Direct Lake toimii parhaiten lämpimässä tai kuumassa tilassa, kun taas kylmät tilat hidastavat suorituskykyä. Direct Lake välttää putoamasta takaisin kylmään mahdollisimman paljon käyttämällä lisäävää framingia.

Bootstrapping

Kun ensimmäinen semanttinen malli on latautunut, mikään saraketiedot ei vielä asu muistissa. Direct Lake on kylmä. Kun asiakas lähettää DAX-kyselyn Direct Lake -semanttiseen malliin kylmässä tilassa, Direct Laken on suoritettava seuraavat päätehtävät, jotta DAX-kysely voidaan käsitellä ja siihen voidaan vastata:

• VertiPaq-sanakirjan transkoodaus. Direct Laken on yhdistettävä jokaisen sarakelohkon paikalliset Parquet-sanastot, jotta sarakkeelle voidaan luoda yleinen VertiPaq-sanasto. Tämä yhdistämistoiminto vaikuttaa kyselyn vastausaikaan.

• Parquet-sarakelohkojen lataaminen sarakesegmenteiksi. Useimmissa tapauksissa kyse on Parquet-tietotunnuksien suorasta uudelleenyhteenlaskusta VertiPaq-tunnuksiin, kun molemmat osapuolet voivat käyttää RLE-/Bit-Packing Hybridikoodausta. Jos Parquet-sanastot käyttävät tavallista koodausta, VertiPaq-kohteen on muunnettava arvot RLE/Bit-Packing Hybridikoodaus, mikä kestää kauemmin.

  • Direct Lake -tallennustilan suorituskyky on optimaalinen V-tilatuille parquet-tiedostoille, koska V-järjestys parantaa RLE-pakkaamisen laatua. Direct Lake voi ladata tiukasti pakattuja V-tilattuja tietoja nopeammin kuin vähemmän pakattuja tietoja.

• Luodaan liitosindeksejä. Jos DAX-kysely käyttää sarakkeita useista taulukoista, Direct Laken on luotava liitosindeksejä taulukkosuhteiden mukaisesti, jotta VertiScan voi liittää taulukot oikein. Jotta voit luoda liitosindeksejä, Direct Laken on ladattava suhteeseen osallistuvien avainsarakkeiden sanastot ja perusavainsarakkeen sarakesegmentit (sarake taulukkosuhteen Yksi-puolella).

• Delta-poistovektoreiden käyttäminen. Jos lähde-Delta-taulukko käyttää poistovektoreita, Direct Laken on ladattava nämä poistovektorit varmistaakseen, että poistettuja tietoja ei käsitellä kyselyssä.

  Huomautus

  Kylmä tila voidaan johtaa myös lähettämällä processClearprocessFull malliin XMLA-komento. Komento ProcessClear poistaa kaikki tiedot ja liitoksen kehystetyllä Delta-taulukkoversiolla. ProcessFull XMLA-komento suorittaa määrityksen sitoakseen mallin uusimpaan saatavilla olevaan Delta-vahvistusversioon.

Lisäävä framing

Framingin aikana Direct Lake analysoi jokaisen Delta-taulukon Delta-lokin ja pudottaa ladatut sarakesegmentit ja liitosindeksit vain, kun pohjana olevat tiedot ovat muuttuneet. Sanastot säilytetään tarpeettoman transkoodauksen välttämiseksi, ja uudet arvot yksinkertaisesti lisätään olemassa oleviin sanastoja. Tämä lisäävä kehysmenetelmä vähentää uudelleenlataamista ja hyödyttää kylmää kyselyä.

Voit analysoida lisäävän veljeskunnan tehokkuutta käyttämällä INFO.STORAGETABLECOLUMNSEGMENTS() DAX-funktiota, joka rivittää DISCOVER_STORAGE_TABLE_COLUMN_SEGMENTS rakennerivijoukon. Varmista merkityksellinen tulos noudattamalla seuraavia ohjeita:

1. Tee kysely Direct Lake -semanttisesta mallista ja varmista, että se on lämpimässä tai kuumassa tilassa.
2. Päivitä Semanttinen Delta-taulukko, jota haluat tutkia, ja päivitä semanttinen Direct Lake -malli framingin suorittamiseksi.
3. Suorita DAX-kysely sarakkeen segmentin tietojen noutamiseksi -funktion INFO.STORAGETABLECOLUMNSEGMENTS() avulla, kuten seuraavassa näyttökuvassa. Näyttökuvassa käytetään pientä esimerkkitaulukkoa havainnollistamistarkoituksiin. Jokaisella sarakkeella on vain yksi segmentti. Segmentit eivät asu muistissa. Tämä ilmaisee todellista kylmää tilaa. Jos malli oli lämmin ennen kehystä, tämä tarkoittaa, että Delta-taulukko päivitettiin käyttäen tuhoisaa tietojen latausmallia, mikä tekee lisäävän veljeskunnan käytöstä mahdotonta. Delta-taulukon päivitysmalleja käsitellään myöhemmin tässä artikkelissa.

Huomautus

Kun Delta-taulukko ei saa päivityksiä, uudelleenlataamista ei tarvita jo muistissa jo oleville sarakkeille. Käytettäessä ei-passiivisia päivitysmalleja kyselyiden suorituskykyvaikutus on framingin jälkeen paljon pienempi, koska lisäävä framointi mahdollistaa olennaisesti Direct Laken nykyisen muistissa olevien tietojen merkittävän osan päivittämisen.

Koko muistinsijainnit

Kun sanastot, sarakesegmentit ja liitosindeksit on ladattu, Direct Lake saavuttaa lämpimän tilan kyselyjen suorituskyvyllä tuontitilaa vastaavine kyselyineen. Molemmissa tiloissa sarakesegmenttien määrä ja koko ovat ratkaisevassa roolissa kyselyn suorituskyvyn optimoinnissa.

Delta-taulukoiden erot

Parquet-tiedostot järjestävät tiedot sarakkeiden mukaan rivien sijaan. Direct Lake järjestää tiedot myös sarakkeiden mukaan. Tasaus helpottaa saumatonta integrointia, mutta siinä on tärkeitä eroja, jotka koskevat erityisesti riviryhmiä ja sanastoja.

Riviryhmät verrattuna sarakesegmentteihin

Parquet-tiedoston riviryhmä koostuu sarakelohkoista, ja kukin lohko sisältää tietyn sarakkeen tiedot. Semanttisen mallin sarakesegmentti sen sijaan sisältää myös saraketietojen lohkon.

Delta-taulukon riviryhmän kokonaismäärän ja vastaavan semanttisen mallitaulukon kunkin sarakkeen segmenttien määrän välillä on suora yhteys. Jos esimerkiksi delta-taulukossa kaikissa sen nykyisissä Parquet-tiedostoissa on yhteensä kolme riviryhmää, vastaavassa semanttisessa mallitaulukossa on kolme segmenttiä saraketta kohden, kuten seuraavassa kaaviossa on kuvattu. Toisin sanoen, jos Delta-taulukossa on suuri määrä pieniä riviryhmiä, vastaavalla semanttisella mallitaulukolla olisi myös suuri määrä pieniä sarakesegmenttejä. Tämä vaikuttaisi kielteisesti kyselyn suorituskykyyn.

Huomautus

Koska Direct Lake suosii suuria sarakesegmenttejä, Delta-lähdetaulukoiden riviryhmien tulisi ihannetapauksessa olla suuria.

Paikalliset sanastot vs. yleinen sanasto

Delta-taulukon riviryhmien kokonaismäärällä on myös suora vaikutus hakemiston transkoodauksen suorituskykyyn, koska Parquet-tiedostot käyttävät paikallisia sanastoja, kun taas Direct Laken semanttiset mallit käyttävät jokaiselle sarakkeelle yleistä sanastoa seuraavassa kaaviossa esitetyllä tavalla. Mitä suurempi on riviryhmien määrä, sitä suurempi on direct laken yhdistettävien paikallisten sanastoiden määrä yleisen sanaston luomista varten ja sitä kauemmin transkoodauksen suorittaminen kestää.

Delta-taulukon päivitysmallit

Menetelmä, jolla tietoja käytetään Delta-taulukkoon, voi vaikuttaa suuresti lisäävän veljeskunnan tehokkuuteen. Jos esimerkiksi käytät Korvaa-vaihtoehtoa , kun tietoja ladataan olemassa olevaan taulukkoon, delta-loki poistetaan jokaisen latauksen yhteydessä. Tämä tarkoittaa, että Direct Lake ei voi käyttää lisäävää framingia, ja sen on ladattava kaikki tiedot, sanastot ja liity indeksit uudelleen. Tällaiset tuhoisat päivitysmallit vaikuttavat kielteisesti kyselyn suorituskykyyn.

Tässä osiossa käsitellään Delta-taulukon päivitysmalleja, joiden avulla Direct Lake voi käyttää lisäävää asetusta, ja VertiPaq-sarakesäilöelementtien, kuten sanakirjaen, sarakesegmenttien ja liitosindeksien, säilyttäminen, mikä maksimoi transkoodauksen tehokkuuden ja parantaa kyselyn kylmää suorituskykyä.

Erän käsittely ilman osiointia

Tämä päivitysmalli kerää ja käsittelee tietoja suurina erinä ajoitettuina aikaväleinä, esimerkiksi viikoittain tai kuukausittain. Kun uusia tietoja saapuu, vanhat tiedot poistetaan usein liukuvasti tai liukuvasti, jotta taulukon koko pysyy hallinnassa. Vanhojen tietojen poistaminen voi kuitenkin olla haastavaa, jos tiedot on jaettu useimmille Parquet-tiedostoille. Esimerkiksi yhden päivän poistaminen 30 päivästä voi vaikuttaa Parquet-tiedostojen 95% 5%sijaan. Tässä tapauksessa Direct Laken olisi ladattava uudelleen 95% tietoja jopa suhteellisen pienessä poistotoiminnossa . Sama ongelma koskee myös olemassa olevien rivien päivityksiä, koska päivitykset ovat yhdistettyjä poistoja ja liityksiä. Voit analysoida poisto - ja päivitystoimintojen vaikutusta Delta Analyzerin avulla, kuten jäljempänä tässä artikkelissa selitetään.

Erän käsittely ja osiointi

Delta-taulukon osiointi voi auttaa vähentämään poistotoimintojen vaikutusta, kun taulukko jaetaan pienempiin Parquet-tiedostoihin, jotka on tallennettu kansioihin osion sarakkeen eri arvojen perusteella. Usein käytettyjä osiosarakkeita ovat päivämäärä-, alue- tai muut dimensioluokat. Edellisessä esimerkissä, jossa poistetaan yksi päivä 30 päivästä, päivämäärän mukaan ositettu Delta-taulukko rajoittaisi poistot vain kyseisen päivän osion parquet-tiedostoihin. On kuitenkin tärkeää huomata, että laaja osiointi voi johtaa Parquet-tiedostojen ja riviryhmien määrän huomattavaan lisääntymiseen, mikä lisää semanttisen Direct Lake -mallin sarakesegmenttejä liikaa ja vaikuttaa kielteisesti kyselyn suorituskykyyn. Pienen kardinaliteetin osion sarakkeen valitseminen on elintärkeää kyselyn suorituskyvyn kannalta. Parhaana käytäntönä sarakkeessa pitäisi olla alle 100–200 erillistä arvoa.

Lisäävä lataaminen

Lisäävän lataamisen myötä päivitysprosessi lisää uusia tietoja vain Delta-taulukkoon vaikuttamatta olemassa oleviin Parquet-tiedostoihin ja riviryhmiin. Poistoja ei ole. Direct Lake voi ladata uudet tiedot asteittain ilman, että olemassa olevia VertiPaq-sarakesäilöelementtejä tarvitsee hylätä ja ladata uudelleen. Tämä menetelmä toimii hyvin Direct Laken lisäävän framingin kanssa. Delta-taulukon osiointia ei tarvita.

Streamin käsittely

Tietojen käsitteleminen lähes reaaliaikaisesti voi niiden saapuessa aiheuttaa pienten Parquet-tiedostojen ja riviryhmien lisääntymisen, mikä voi vaikuttaa kielteisesti Direct Laken suorituskykyyn. Kuten lisäävän latausmallin kohdalla, Delta-taulukkoa ei tarvitse osittaa. Taulukoiden usein toistuva ylläpito on kuitenkin välttämätöntä sen varmistamiseksi, että Parquet-tiedostojen ja riviryhmien määrä pysyy Direct Lake -yleiskatsauksen artikkelissa määritettyjen suojakaiteiden rajojen puitteissa. Muista toisin sanoen suorittaa Spark-optimointi säännöllisesti, esimerkiksi päivittäin tai jopa useammin. SparkIn optimointi käsitellään uudelleen seuraavassa osiossa.

Huomautus

Todellinen reaaliaikainen analyysi on paras toteuttaa hyödyntäen Eventstreams-, KQL-tietokantoja ja Eventhouse-funktioita. Katso ohjeet Microsoft FabricinReal-Time Intelligence -dokumentaatiosta .

Delta-taulukoiden ylläpito

Tärkeimpiä ylläpitotehtäviä ovat Delta-taulukoiden imurointi ja optimointi. Voit automatisoida ylläpitotoimia käyttämällä Lakehouse-ohjelmointirajapintoja Lakehousen hallinta Microsoft Fabric REST - ohjelmointirajapinnoilla -ohjeissa kuvatulla tavalla.

Imurointi

Imurointi poistaa Parquet-tiedostot, jotka eivät enää sisälly nykyiseen Delta-vahvistusversioon ja jotka ovat vanhempia kuin määritetty säilytyskynnysarvo. Näiden parquet-tiedostojen poistaminen ei vaikuta Direct Laken suorituskykyyn, koska Direct Lake lataa vain parquet-tiedostot, jotka ovat nykyisessä vahvistusversiossa. Jos suoritat VACUUM-funktion päivittäin oletusarvoilla, viimeisten seitsemän päivän Delta-vahvistusversiot säilytetään aikamatkaa varten.

Tärkeää

Koska kehystetty semanttinen Direct Lake -malli viittaa tiettyyn Delta-vahvistusversioon, sinun on varmistettava, että Delta-taulukko säilyttää tämän version, kunnes päivität mallin (kehyksen) uudelleen siirtääksesi sen nykyiseen versioon. Muussa tapauksessa käyttäjät kohtaavat kyselyvirheitä, kun Semanttinen Direct Lake -malli yrittää käyttää Parquet-tiedostoja, joita ei enää ole olemassa.

Spark-optimointi

Delta-taulukon optimointi yhdistää useita pieniä Parquet-tiedostoja vähemmän suuriksi tiedostoiksi. Koska tämä voi vaikuttaa direct laken kylmään suorituskykyyn, hyvä käytäntö on optimoida harvoin, esimerkiksi viikonloppuisin tai kuukauden lopussa. Optimoi useammin, jos pienet Parquet-tiedostot kertyvät nopeasti (suuren taajuuden pienet päivitykset), jotta Delta-taulukko pysyy suojakaiteen rajoissa.

Osiointi voi auttaa minimoimaan optimointivaikutuksen lisäävässä kehyksessä, koska osiointi tehokkaasti liittää tiedot. Esimerkiksi suuren Delta-taulukon osittaminen pienen kardinaliteetin date_key sarakkeen perusteella rajoittaisi viikoittaisen ylläpidon enintään seitsemään osioon. Delta-taulukko säilyttää suurimman osan olemassa olevista Parquet-tiedostoista. Direct Laken pitäisi ladata uudelleen vain seitsemän päivän tiedot.

Delta-taulukon päivitysten analysointi

Delta Analyzerin tai vastaavien työkalujen avulla voit tutkia, miten Delta-taulukon päivitykset vaikuttavat Parquet-tiedostoihin ja riviryhmiin. Delta Analyzerin avulla voit seurata Parquet-tiedostojen, riviryhmien, sarakelohkojen ja sarakkeiden seuraavasti liittämis-, päivitys- ja poistotoimintoja . Delta Analyzer on saatavilla erillisenä Jupyter-muistikirjana. Se on käytettävissä myös semanttisen linkin labratöiden kirjastossa. Seuraavissa osioissa käytetään semanttista link-labia. Tämä kirjasto on helppo asentaa muistikirjaan komennolla %pip install semantic-link-labs .

Riviryhmän koko

Direct Lake -semanttisille malleille ihanteellinen riviryhmän koko on 1–16 miljoonaa riviä, mutta Fabric saattaa kuitenkin käyttää suurempia riviryhmäkokoja suurissa taulukoissa, jos tiedot ovat pakattavissa. Emme yleensä suosittele riviryhmän oletuskoon muuttamista. Paras on antaa Fabricin hallita Delta-taulukkoasettelua. Mutta on myös hyvä tarkistaa se kahdesti.

Seuraava Python-koodi voi toimia lähtökohtana analysoimaan riviryhmän kokoja ja muita tietoja Delta-taulukosta Fabric-muistikirjaan yhdistetyssä Lakehousessa. Seuraava taulukko näyttää tiedot mallitaulukolle, jossa on miljardi riviä.

import sempy_labs as labs
from IPython.display import HTML
from IPython.display import clear_output

table_name = "<Provide your table name>"

# Load the Delta table and run Delta Analyzer
df = spark.read.format("delta").load(f"Tables/{table_name}")
da_results = labs.delta_analyzer(table_name)

# Display the table summary in an HTML table.
clear_output()

df1 = da_results['Summary'].iloc[0]

html_table = "<table border='1'><tr><th>Column Name</th><th>{table_name}</th></tr>"
for column in da_results['Summary'].columns:
    html_table += f"<tr><td>{column}</td><td>{df1[column]}</td></tr>"
html_table += "</table>"

display(HTML(html_table))

Tuloste:

Parametri	Arvo
Taulukon nimi	sales_1
Rivimäärä	1000000000
Riviryhmät	24
Jäsennä tiedostot	8
Rivien enimmäismäärä riviryhmää kohden	51210000
Rivikohtaisen ryhmän vähimmäisarvo	22580000
Rivien keskiarvo per riviryhmä	41666666.666666664
VOrder käytössä	Tosi
Kokonaiskoko	7700808430
Aikaleima	2025-03-24 03:01:02.794979

Delta Analyzer -yhteenveto näyttää riviryhmän keskimääräisen koon, joka on noin 40 miljoonaa riviä. Tämä on suurempi kuin suositeltu riviryhmän suositeltu enimmäiskoko, joka on 16 miljoonaa riviä. Onneksi suurempi riviryhmän koko ei aiheuta merkittäviä ongelmia Direct Lake -järjestelmässä. Suuremmat riviryhmät helpottavat jatkuvia segmenttitöitä pienellä kuormituksella säilömoduulissa. Vastaavasti pienet riviryhmät, jotka ovat merkittävästi alle miljoona riviä, voivat aiheuttaa suorituskykyongelmia.

Edellisessä esimerkissä on tärkeää, että Fabric jakoi riviryhmät kahdeksalle Parquet-tiedostolle. Tämä vastaa Fabric-kapasiteetin ydinten määrää tehokkaiden rinnakkaisten lukutoimintojen tukemiseksi. Tärkeää on myös se, että yksittäiset riviryhmän koot eivät poikkea keskiarvosta liian kauas. Suuret muunnelmat voivat heikentää optimaalisen kyselyjen suorituskykyä muuntamattomalla VertiScan-kuormituksella.

Vieritysikkunan päivitykset

Havainnollistamiseksi seuraava Python-koodimalli simuloi vieritysikkunan päivitystä. Koodi poistaa vanhimman DateID:n rivit delta-mallitaulukosta. Sitten se päivittää näiden rivien DateID-tunnuksen ja lisää ne takaisin mallitaulukkoon uusimpina riveinä.

from pyspark.sql.functions import lit

table_name = "<Provide your table name>"
table_df = spark.read.format("delta").load(f"Tables/{table_name}")

# Get the rows of the oldest DateID.
rows_df = table_df[table_df["DateID"] == 20200101]
rows_df = spark.createDataFrame(rows_df.rdd, schema=rows_df.schema)

# Delete these rows from the table
table_df.createOrReplaceTempView(f"{table_name}_view")
spark.sql(f"DELETE From {table_name}_view WHERE DateID = '20200101'")

# Update the DateID and append the rows as new data
rows_df = rows_df.withColumn("DateID", lit(20250101))
rows_df.write.format("delta").mode("append").save(f"Tables/{table_name}")

Semantic-link-labs-kirjastonget_delta_table_history funktio voi auttaa analysoimaan tämän vieritysikkunan päivityksen vaikutusta. Katso seuraava Python-koodiesimerkki. Katso myös taulukko, jossa on koodikatkelman jälkeinen tulos.

import sempy_labs as labs
from IPython.display import HTML
from IPython.display import clear_output

table_name = "<Provide your table name>"
da_results = labs.get_delta_table_history(table_name)

# Create a single HTML table for specified columns
html_table = "<table border='1'>"
# Add data rows for specified columns
for index, row in da_results.iterrows():
    for column in ['Version', 'Operation', 'Operation Parameters', 'Operation Metrics']:
        if column == 'Version':
            html_table += f"<tr><td><b>Version</b></td><td><b>{row[column]}</b></td></tr>"
        else:
            html_table += f"<tr><td>{column}</td><td>{row[column]}</td></tr>"
html_table += "</table>"

# Display the HTML table
display(HTML(html_table))

Tuloste:

Versio	Kuvaus	Arvo
2	Operaatio	KIRJOITTAA
	Toiminnon parametrit	{'mode': 'Liitä', 'partitionBy': '[]'}
	Toiminnon mittarit	{'numFiles': '1', 'numOutputRows': '548665', 'numOutputBytes': '4103076'}
1	Operaatio	POISTAA
	Toiminnon parametrit	{'predicate': '["(DateID#3910 = 20200101)"]'}
	Toiminnon mittarit	{'numRemovedFiles': '8', 'numRemovedBytes': '7700855198', 'numCopiedRows': '999451335', 'numDeletionVectorsAdded': '0', 'numDeletionVectorsRemoved': '0', 'numAddedChangeFiles': '0', 'executionTimeMs': '123446', 'numDeletionVectorsUpdated': '0', 'numDeletedRows': '548665', 'scanTimeMs': '4820', 'numAddedFiles': '18', 'numAddedBytes': '7696900084', 'rewriteTimeMs': '198625'}
0	Operaatio	KIRJOITTAA
	Toiminnon parametrit	{'mode': 'Overwrite', 'partitionBy': '[]'}
	Toiminnon mittarit	{'numFiles': '8', 'numOutputRows': '100000000', 'numOutputBytes': '7700892169'}

Yllä oleva Delta Analyzer -historia näyttää, että tässä Delta-taulukossa on nyt seuraavat kolme versiota:

• Versio 0: Tämä on alkuperäinen versio, jossa on kahdeksan Parquet-tiedostoa ja 24 riviryhmää edellisessä osiossa kuvatulla tavalla.
• Versio 1: Tämä versio vastaa poistotoimintoa . Vaikka vain yhden päivän tiedot (DateID = "20200101") poistettiin mallitaulukosta, jossa oli viiden vuoden myyntitapahtumat, se vaikutti kaikkiin kahdeksaan Parquet-tiedostoon. Toimintomittari-kohdassa numRemovedFiles on kahdeksan [Parquet-tiedostoa] ja numAddedFiles 18 [Parquet-tiedostoa]. Tämä tarkoittaa sitä, että poistotoiminto korvasi alkuperäiset kahdeksan Parquet-tiedostoa 18 uudella Parquet-tiedostolla.
• Versio 3: Toiminnon mittarit paljastavat, että Delta-taulukkoon lisättiin vielä yksi Parquet-tiedosto, jossa on 548 665 riviä.

Vieritysikkunan päivityksen jälkeen uusin Delta-vahvistusversio sisältää 19 Parquet-tiedostoa ja 21 riviryhmää, joiden koko voi olla 500–50 miljoonaa riviä. Vieritysikkunan 548 665 rivin päivitys vaikutti koko miljardin rivin Delta-taulukkoon. Se korvasi kaikki Parquet-tiedostot ja riviryhmät. Lisäävän kehyksen ei voida odottaa parantavan kylmää suorituskykyä tässä tapauksessa, eikä riviryhmien kokojen lisääntynyt vaihtelu todennäköisesti hyödytä lämmintä suorituskykyä.

Delta-taulukon päivitykset

Seuraava Python-koodi päivittää Delta-taulukon oleellisesti samalla tavalla kuin edellisessä osiossa kuvattiin. Maanpinnalla päivitysfunktio muuttaa vain annetulle DateID:lle vastaavien olemassa olevien rivien DateID-arvoa. Parquet-tiedostot ovat kuitenkin muuttumattomia, eikä niitä voi muokata. Pinnan alla päivitystoiminto poistaa olemassa olevat Parquet-tiedostot ja lisää uusia Parquet-tiedostoja. Tulos ja vaikutus ovat samat kuin vieritysikkunan päivityksessä.

from pyspark.sql.functions import col, when
from delta.tables import DeltaTable

# Load the Delta table
table_name = "<Provide your table name>"
delta_table = DeltaTable.forPath(spark, f"Tables/{table_name}")

# Define the condition and the column to update
condition = col("DateID") == 20200101
column_name = "DateID"
new_value = 20250101

# Update the DateID column based on the condition
delta_table.update(
    condition,
    {column_name: when(condition, new_value).otherwise(col(column_name))}
)

Osioituja vieritysikkunan päivityksiä

Osiointi voi auttaa vähentämään taulukkopäivitysten vaikutusta. Päivämääräavaimien käyttäminen voi olla houkuttelevaa, mutta nopea kardinaliteettitarkistus voi paljastaa, ettei tämä ole paras vaihtoehto. Esimerkiksi tähän mennessä käsitelty mallitaulukko sisältää viiden edellisen vuoden myyntitapahtumat, jotka vastaavat noin 1 800 erillistä päivämääräarvoa. Tämä kardinaliteetti on liian suuri. Osiosarakkeessa tulee olla alle 200 erillistä arvoa.

column_name = 'DateID'
table_name = "<Provide your table name>"
table_df = spark.read.format("delta").load(f"Tables/{table_name}")

distinct_count = table_df.select(column_name).distinct().count()
print(f"The '{column_name}' column has {distinct_count} distinct values.")

if distinct_count <= 200:
    print(f"The '{column_name}' column is a good partitioning candidate.")
    table_df.write.format("delta").partitionBy(column_name).save(f"Tables/{table_name}_by_date_id")
    print(f"Table '{table_name}_by_date_id' partitioned and saved successfully.")
else:   
    print(f"The cardinality of the '{column_name}' column is possibly too high.")

Tuloste:

The 'DateID' column has 1825 distinct values.
The cardinality of the 'DateID' column is possibly too high.

Jos sopivaa osion saraketta ei ole, se voidaan luoda keinotekoisesti vähentämällä olemassa olevan sarakkeen kardinaliteettia. Seuraava Python-koodi lisää Kuukausi-sarakkeen poistamalla dateID-tunnuksen viimeiset kaksi numeroa. Tämä tuottaa 60 erillistä arvoa. Mallikoodi tallentaa sitten Kuukausi-sarakkeen osioiman Delta-taulukon.

from pyspark.sql.functions import col, expr

column_name = 'DateID'
table_name = "sales_1"
table_df = spark.read.format("delta").load(f"Tables/{table_name}")

partition_column = 'Month'
partitioned_table = f"{table_name}_by_month"
table_df = table_df.withColumn(partition_column, expr(f"int({column_name} / 100)"))

distinct_count = table_df.select(partition_column).distinct().count()
print(f"The '{partition_column}' column has {distinct_count} distinct values.")

if distinct_count <= 200:
    print(f"The '{partition_column}' column is a good partitioning candidate.")
    table_df.write.format("delta").partitionBy(partition_column).save(f"Tables/{partitioned_table}")
    print(f"Table '{partitioned_table}' partitioned and saved successfully.")
else:   
    print(f"The cardinality of the '{partition_column}' column is possibly too high.")

Tuloste:

The 'Month' column has 60 distinct values.
The 'Month' column is a good partitioning candidate.
Table 'sales_1_by_month' partitioned and saved successfully.

Delta Analyzer -yhteenveto näyttää nyt, että Delta-taulukon asettelu on hyvin tasattu Direct Lakeen. Riviryhmän keskimääräinen koko on noin 16 miljoonaa riviä, ja riviryhmien kokojen ja siten segmentin koon keskimääräinen absoluuttinen poikkeama on pienempi kuin miljoona riviä.

Parametri	Arvo
Taulukon nimi	sales_1_by_month
Rivimäärä	1000000000
Riviryhmät	60
Jäsennä tiedostot	60
Rivien enimmäismäärä riviryhmää kohden	16997436
Rivikohtaisen ryhmän vähimmäisarvo	15339311
Rivien keskiarvo per riviryhmä	16666666.666666666
VOrder käytössä	Tosi
Kokonaiskoko	7447946016
Aikaleima	2025-03-24 03:01:02.794979

Kun vieritysikkuna on päivitetty osioitua esimerkkitaulukkoa vastaan, Delta Analyzer -historia näyttää, että se on vaikuttanut vain yhteen Parquet-tiedostoon. Katso seuraava tulostetaulukko. Versiossa 2 on tarkalleen 16 445 655 riviä, jotka on kopioitu vanhasta Parquet-tiedostosta korvaavaksi Parquet-tiedostoksi, ja versio 3 lisää uuden Parquet-tiedoston, jossa on 548 665 riviä. Yhteensä Direct Laken tarvitsee ladata uudelleen vain noin 17 miljoonaa riviä, mikä on huomattava parannus yli miljardin rivin uudelleenlataamiseen ilman osiointia.

Versio	Kuvaus	Arvo
2	Operaatio	KIRJOITTAA
	Toiminnon parametrit	{'mode': 'Liitä', 'partitionBy': '["Kuukausi"]'}
	Toiminnon mittarit	{'numFiles': '1', 'numOutputRows': '548665', 'numOutputBytes': '4103076'}
1	Operaatio	POISTAA
	Toiminnon parametrit	{'predicate': '["(DateID#3910 = 20200101)"]'}
	Toiminnon mittarit	{'numRemovedFiles': '1', 'numRemovedBytes': '126464179', 'numCopiedRows': '16445655', 'numDeletionVectorsAdded': '0', 'numDeletionVectorsRemoved': '0', 'numAddedChangeFiles': '0', 'executionTimeMs': '19065', '19065', 'numAddedChangeFiles': '0', 'executionTimeMs': '19065', '19065', 'numAddedChangeFiles': '0', 'executionTimeMs': '19065', '19065', 'numAddedChangeFiles': '0', 'executionTimeMs': '19065', '19065', 'numAddedChangeFiles': '0', 'executionTimeMs': '19065', '19065', 'numAddedChangeFiles': '0', 'executionTimeMs': '19065', '0', 'numAddedChange "numDeletionVectorsUpdated": '0', 'numDeletedRows': '548665', 'scanTimeMs': '1926', 'numAddedFiles': '1', 'numAddedBytes': '121275513', 'rewriteTimeMs': '17138'}
0	Operaatio	KIRJOITTAA
	Toiminnon parametrit	{'mode': 'Overwrite', 'partitionBy': '["Month"]'}
	Toiminnon mittarit	{'numFiles': '60', 'numOutputRows': '100000000', 'numOutputBytes': '7447681467'}

Liitä vain -malli, jota seuraa Spark Optimize

Vain lisätyt mallit eivät vaikuta olemassa oleviin Parquet-tiedostoihin. Ne toimivat hyvin Direct Laken lisäävän veljeskunnan kanssa. Muista kuitenkin optimoida Delta-taulukot Parquet-tiedostojen ja riviryhmien yhdistämiseksi tässä artikkelissa aiemmin kuvatulla tavalla. Pienet ja yleisimpiä liittämiset voivat kerätä tiedostoja nopeasti ja vääristää riviryhmien kokojen yhtenäisyyttä.

Seuraava tulos näyttää Delta Analyzer -historian osittamattomalle taulukolle verrattuna ositettuun taulukkoon. Historia sisältää seitsemän liitettä ja yhden myöhemmän optimointitoiminnon .

Versio	Kuvaus	Oletusarvon asettelussa	Ositetun asettelun arvo
8	Operaatio	OPTIMOIDA	OPTIMOIDA
	Toiminnon parametrit	{'predicate': '[]', 'auto': 'false', 'clusterBy': '[]', 'vorder': 'true', 'zOrderBy': '[]'}	{'predicate': '["('Month >= 202501)"]', 'auto': 'false', 'clusterBy': '[]', 'vorder': 'true', 'zOrderBy': '[]'}
	Toiminnon mittarit	{'numRemovedFiles': '8', 'numRemovedBytes': '991234561', 'p25FileSize': '990694179', 'numDeletionVectorsRemoved': '0', 'minFileSize': '990694179', 'numAddedFiles': '1', 'maxFileSize': '990694179', 'p75FileSize': '990694179', 'p50FileSize': '990694179', 'numAddedBytes': '990694179'}	{'numRemovedFiles': '7', 'numRemovedBytes': '28658548', 'p25FileSize': '28308495', 'numDeletionVectorsRemoved': '0', 'minFileSize': '28308495', 'numAddedFiles': '1', 'maxFileSize': '28308495', 'p75FileSize': '28308495', 'p50FileSize': '28308495', 'numAddedBytes': '28308495'}
7	Operaatio	KIRJOITTAA	KIRJOITTAA
	Toiminnon parametrit	{'mode': 'Liitä', 'partitionBy': '[]'}	{'mode': 'Liitä', 'partitionBy': '["Kuukausi"]'}
	Toiminnon mittarit	{'numFiles': '1', 'numOutputRows': '547453', 'numOutputBytes': '4091802'}	{'numFiles': '1', 'numOutputRows': '547453', 'numOutputBytes': '4091802'}
6	Operaatio	KIRJOITTAA	KIRJOITTAA
	Toiminnon parametrit	{'mode': 'Liitä', 'partitionBy': '[]'}	{'mode': 'Liitä', 'partitionBy': '["Kuukausi"]'}
	Toiminnon mittarit	{'numFiles': '1', 'numOutputRows': '548176', 'numOutputBytes': '4095497'}	{'numFiles': '1', 'numOutputRows': '548176', 'numOutputBytes': '4095497'}
5	Operaatio	KIRJOITTAA	KIRJOITTAA
	Toiminnon parametrit	{'mode': 'Liitä', 'partitionBy': '[]'}	{'mode': 'Liitä', 'partitionBy': '["Kuukausi"]'}
	Toiminnon mittarit	{'numFiles': '1', 'numOutputRows': '547952', 'numOutputBytes': '4090107'}	{'numFiles': '1', 'numOutputRows': '547952', 'numOutputBytes': '4093015'}
4	Operaatio	KIRJOITTAA	KIRJOITTAA
	Toiminnon parametrit	{'mode': 'Liitä', 'partitionBy': '[]'}	{'mode': 'Liitä', 'partitionBy': '["Kuukausi"]'}
	Toiminnon mittarit	{'numFiles': '1', 'numOutputRows': '548631', 'numOutputBytes': '4093134'}	{'numFiles': '1', 'numOutputRows': '548631', 'numOutputBytes': '4094376'}
3	Operaatio	KIRJOITTAA	KIRJOITTAA
	Toiminnon parametrit	{'mode': 'Liitä', 'partitionBy': '[]'}	{'mode': 'Liitä', 'partitionBy': '["Kuukausi"]'}
	Toiminnon mittarit	{'numFiles': '1', 'numOutputRows': '548671', 'numOutputBytes': '4101221'}	{'numFiles': '1', 'numOutputRows': '548671', 'numOutputBytes': '4101221'}
2	Operaatio	KIRJOITTAA	KIRJOITTAA
	Toiminnon parametrit	{'mode': 'Liitä', 'partitionBy': '[]'}	{'mode': 'Liitä', 'partitionBy': '["Kuukausi"]'}
	Toiminnon mittarit	{'numFiles': '1', 'numOutputRows': '546530', 'numOutputBytes': '4081589'}	{'numFiles': '1', 'numOutputRows': '546530', 'numOutputBytes': '4081589'}
1	Operaatio	KIRJOITTAA	KIRJOITTAA
	Toiminnon parametrit	{'mode': 'Liitä', 'partitionBy': '[]'}	{'mode': 'Liitä', 'partitionBy': '["Kuukausi"]'}
	Toiminnon mittarit	{'numFiles': '1', 'numOutputRows': '548665', 'numOutputBytes': '4101048'}	{'numFiles': '1', 'numOutputRows': '548665', 'numOutputBytes': '4101048'}
0	Operaatio	KIRJOITTAA	KIRJOITTAA
	Toiminnon parametrit	{'mode': 'Overwrite', 'partitionBy': '[]'}	{'mode': 'Overwrite', 'partitionBy': '["Month"]'}
	Toiminnon mittarit	{'numFiles': '8', 'numOutputRows': '100000000', 'numOutputBytes': '7700855198'}	{'numFiles': '60', 'numOutputRows': '100000000', 'numOutputBytes': '7447681467'}

Version 8 operaatiomittareita tarkastellessa kannattaa huomauttaa, että osioimattoman esitettyjä yhdistettyjä kahdeksan Parquet-tiedostoa optimointitoiminto , joka vaikuttaa noin 1 Gt:n tietoihin, kun osioidun taulukon optimointitoiminto yhdisti seitsemän Parquet-tiedostoa, jotka vaikuttivat vain noin 25 Mt:n tietoihin. Tästä seuraa, että Direct Lake toimisi paremmin osioidussa taulukossa.

Huomioitavat asiat ja rajoitukset

Direct Lake -suorituskyvyn optimoimisessa huomioitavia seikkoja ja rajoituksia ovat seuraavat:

• Vältä tuhoisia päivityskuvioita suurissa Delta-taulukoissa säilyttääksesi lisäävän framingin Direct Lakessa.
• Pieniä Delta-taulukoita ei tarvitse optimoida lisäävää veljeskuntaa varten.
• Pyri luomaan Direct Lakeen sarakesegmenttejä, joissa on 1–16 miljoonaa riviä. Direct Lake käyttää mieluummin suuria sarakesegmenttejä.
• Vältä suuren kardinaliteetin osion sarakkeita, koska Direct Lake -transkoodaus on tehottomampaa useiden pienten Parquet-tiedostojen ja riviryhmien kanssa kuin pienemmissä suurissa Parquet-tiedostoissa ja riviryhmissä.
• Tietokone- ja muistiresurssien odottamattoman kysynnän vuoksi semanttinen malli voidaan ladata uudelleen toiseen Fabric-klusterisolmuun kylmässä tilassa.
• Direct Lake ei käytä delta\Parquet-tilastoja riviryhmälle\tiedoston ohittamiselle tietojen lataamisen optimoimiseksi.