Jaa

Tutustu Direct Lake -semanttisten mallien tallennustilaan

  • Artikkeli

Tässä artikkelissa esitellään Direct Lake - tallennuskäsitteet. Se kuvaa Delta-taulukoita ja Parquet-tiedostoja. Artikkelissa kuvataan myös, miten voit optimoida Delta-taulukoita Direct Laken semanttisille malleille ja miten voit ylläpitää niitä luotettavan ja nopean kyselyjen suorituskyvyn takaamiseksi.

Delta-taulukot

OneLakessa on Delta-taulukoita. Ne järjestävät tiedostopohjaiset tiedot riveihin ja sarakkeisiin, ja ne ovat Microsoft Fabric -käsittelymoduulien, kuten muistikirjojen, Kuston, lakehousen ja varaston, käytettävissä. Voit tehdä kyselyn Delta-taulukoista käyttämällä Data Analysis Expressions -lausekkeita (DAX), MDX-lausekkeita, T-SQL:ää (Transact-SQL), Spark SQL:ää ja jopa Pythonia.

Muistiinpano

Delta eli Delta Lake on avoimen lähdekoodin tallennusmuoto. Tämä tarkoittaa sitä, että Fabric voi myös tehdä kyselyjä Delta-taulukoista, jotka ovat muiden työkalujen ja toimittajien luomia.

Delta-taulukot tallentavat tietonsa Parquet-tiedostoihin, jotka tallennetaan yleensä Lakehouse-järjestelmään, jota Direct Lake -semanttinen malli käyttää tietojen lataamiseen. Parquet-tiedostoja voi kuitenkin tallentaa myös ulkoisesti. Ulkoisiin parquet-tiedostoihin voidaan viitata käyttämällä OneLake-pikakuvaketta, joka osoittaa tiettyyn tallennussijaintiin, kuten Azure Data Lake Storage (ADLS) Gen2:een, Amazon S3 -tallennustiliin tai Dataverseen. Lähes kaikissa tapauksissa laskentamoduulit käyttävät Parquet-tiedostoja tekemällä kyselyjä Delta-taulukoista. Yleensä semanttiset Direct Lake -mallit lataavat kuitenkin saraketiedot suoraan OneLaken optimoiduista Parquet-tiedostoista käyttämällä transkoodausta.

Tietojen versiointi

Delta-taulukot koostuvat yhdestä tai useammasta Parquet-tiedostosta. Näihin tiedostoihin liittyy joukko JSON-pohjaisia linkkitiedostoja, jotka seuraavat kunkin Delta-taulukkoon liittyvän Parquet-tiedoston järjestystä ja luonnetta.

On tärkeää ymmärtää, että pohjana olevat Parquet-tiedostot ovat luonteeltaan lisääviä. Tästä johtuen nimi Delta viittaa lisäävään tietojen muokkamiseen. Aina, kun delta-taulukkoon tehdään kirjoitustoiminto, esimerkiksi kun tietoja lisätään, päivitetään tai poistetaan, luodaan uusia Parquet-tiedostoja, jotka edustavat tietojen muokkauksia versiona. Parquet-tiedostot ovat siis muuttumattomia eli niitä ei koskaan muokata. Tämän vuoksi on mahdollista, että tiedot monistetaan monta kertaa delta-taulukon Parquet-tiedostojoukosta. Delta-kehys käyttää linkkitiedostoja määrittääkseen, mitkä fyysiset Parquet-tiedostot vaaditaan oikean kyselyn tuloksen tuottamiseen.

Otetaan esimerkiksi Delta-taulukko, jota tässä artikkelissa käytetään erilaisten tietojen muokkaustoimintojen selittämiseen. Taulukossa on kaksi saraketta ja siinä on kolme riviä.

Tuotetunnus StockOnHand
A 1
B 2
C 3

Delta-taulukon tiedot tallennetaan yhteen Parquet-tiedostoon, joka sisältää kaikki tiedot. On olemassa yksi linkkitiedosto, joka sisältää metatietoja siitä, milloin tiedot lisättiin (liitetty).

  • Parquet-tiedosto 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Linkkitiedosto 1:
    • Sisältää aikaleiman, kun Parquet file 1 luotiin, ja tietueet, jotka liitettiin tietoihin.

Lisäystoiminnot

Mieti, mitä tapahtuu, kun lisäämistoiminto tapahtuu: Tuotteen uusi rivi C , jonka varastossa on -arvo 4 , lisätään. Tämän toiminnon tuloksena luodaan uusi Parquet-tiedosto ja linkkitiedosto, joten Parquet-tiedostoja on nyt kaksi ja linkkitiedostoja kaksi.

  • Parquet-tiedosto 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet-tiedosto 2:
    • ProductID: D
    • StockOnHand: 4
  • Linkkitiedosto 1:
    • Sisältää aikaleiman, kun Parquet file 1 luotiin, ja tietueet, jotka liitettiin tietoihin.
  • Linkkitiedosto 2:
    • Sisältää aikaleiman, kun Parquet file 2 luotiin, ja tietueet, jotka liitettiin tietoihin.

Tässä vaiheessa Delta-taulukon kysely palauttaa seuraavan tuloksen. Vaikka tulos olisi peräisin useista Parquet-tiedostoista, sillä ei ole merkitystä.

Tuotetunnus StockOnHand
A 1
B 2
C 3
D 4

Jokainen seuraava lisäystoiminto luo uusia Parquet-tiedostoja ja linkittää tiedostoja. Tämä tarkoittaa, että Parquet-tiedostojen ja linkkitiedostojen määrä kasvaa jokaisella lisäystoiminnolla.

Päivitä toimintoja

Mieti sitten, mitä tapahtuu, kun tapahtuu päivitystoiminto: tuotteen D varaston arvoksi 10on nyt muutettu . Tämän toiminnon avulla luodaan uusi Parquet-tiedosto ja linkkitiedosto, joten Parquet-tiedostoja on nyt kolme ja linkkitiedostoja kolme.

  • Parquet-tiedosto 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet-tiedosto 2:
    • ProductID: D
    • StockOnHand: 4
  • Parquet-tiedosto 3:
    • ProductID: C
    • StockOnHand: 10
  • Linkkitiedosto 1:
    • Sisältää aikaleiman, kun Parquet file 1 luotiin, ja tietueet, jotka liitettiin tietoihin.
  • Linkkitiedosto 2:
    • Sisältää aikaleiman, kun Parquet file 2 luotiin, ja tietueet, jotka liitettiin tietoihin.
  • Linkkitiedosto 3:
    • Sisältää aikaleiman, kun Parquet file 3 luotiin, ja tietueet, jotka päivitettiin.

Tässä vaiheessa Delta-taulukon kysely palauttaa seuraavan tuloksen.

Tuotetunnus StockOnHand
A 1
B 2
K 10
D 4

Tuotteen C tiedot ovat nyt olemassa useissa Parquet-tiedostoissa. Delta-taulukkoon lähetetyt kyselyt yhdistävät kuitenkin linkkitiedostot määrittääkseen, mitä tietoja käytetään oikean tuloksen antamiseen.

Poista toiminnot

Mieti sitten, mitä tapahtuu, kun poistotoiminto tapahtuu: tuotteen B rivi poistetaan. Tämän toiminnon tuloksena saadaan uusi Parquet-tiedosto ja linkkitiedosto, joten Parquet-tiedostoja on nyt neljä ja linkkitiedostoja neljä.

  • Parquet-tiedosto 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet-tiedosto 2:
    • ProductID: D
    • StockOnHand: 4
  • Parquet-tiedosto 3:
    • ProductID: C
    • StockOnHand: 10
  • Parquet-tiedosto 4:
    • ProductID: A, C, D
    • StockOnHand: 1, 10, 4
  • Linkkitiedosto 1:
    • Sisältää aikaleiman, kun Parquet file 1 luotiin, ja tietueet, jotka liitettiin tietoihin.
  • Linkkitiedosto 2:
    • Sisältää aikaleiman, kun Parquet file 2 luotiin, ja tietueet, jotka liitettiin tietoihin.
  • Linkkitiedosto 3:
    • Sisältää aikaleiman, kun Parquet file 3 luotiin, ja tietueet, jotka päivitettiin.
  • Linkkitiedosto 4:
    • Sisältää aikaleiman, kun Parquet file 4 luotiin, ja tietueet, jotka tiedot on poistettu.

Huomaa, että Parquet file 4 se ei enää sisällä tuotteen Btietoja, mutta se sisältää tietoja taulukon kaikista muista riveistä.

Tässä vaiheessa Delta-taulukon kysely palauttaa seuraavan tuloksen.

Tuotetunnus StockOnHand
A 1
K 10
D 4

Muistiinpano

Tämä esimerkki on yksinkertainen, koska siihen liittyy pieni taulukko, vain muutama toiminto ja vain pieniä muokkauksia. Suuret taulukot, jotka kokevat useita kirjoitustoimintoja ja jotka sisältävät useita tietorivejä, luovat useampia parquet-tiedostoja versiota kohti.

Tärkeä

Tästä voi aiheutua useita Parquet-tiedostoja sen mukaan, miten määrität Delta-taulukot ja kuinka usein tietojen muokkaustoimintoja tehdään. Huomaa, että jokaisessa Fabric-kapasiteetin luvasta on suojakaiteita. Jos Delta-taulukon Parquet-tiedostojen määrä ylittää varastointiyksikkösi rajan, kyselyt palataan DirectQueryyn, mikä voi hidastaa kyselyn suorituskykyä.

Jos haluat hallita Parquet-tiedostojen määrää, katso kohta Taulukoiden ylläpito myöhemmin tässä artikkelissa.

Delta-aikamatkat

Linkkitiedostot mahdollistavat tietojen kyselemisen aiemmasta ajankohdasta. Tätä ominaisuutta kutsutaan Delta-aikamatkaksi. Aikaisempaa ajankohtaa voisi olla aikaleima tai versio.

Tutustu seuraaviin kyselyesimerkkiin.

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

Vihje

Voit myös tehdä kyselyn taulukkoon käyttämällä tiivistelmäsyntaksia @ , joka määrittää aikaleiman tai version osana taulukon nimeä. Aikaleiman on oltava yyyyMMddHHmmssSSS muodossa. Voit määrittää version jälkeen @ käyttämällä -versiota esiliittimenä v .

Tässä ovat edelliset kyselyesimerkit, jotka on kirjoitettu uudelleen tiivistelmäsyntaksilla.

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

Tärkeä

Taulukkoversiot, joihin pääsee aikaan matkustamalla, määräytyvät tapahtumalokitiedostojen säilytyskynnysarvon ja VACUUM-toimintojen määritetyn säilytysajan yhdistelmällä (kuvataan myöhemmin Delta-taulukon ylläpito-osassa ). Jos suoritat VACUUM-funktion päivittäin oletusarvoilla, aikasijainnille on saatavilla seitsemän päivän tiedot.

Kehystys

Framing on Direct Lake -toiminto, joka määrittää Delta-taulukon version, jota tulee käyttää tietojen lataamiseen semanttiseen mallisarakkeeseen. Yhtä tärkeää on se, että versio myös määrittää, mitä tulee sulkea pois, kun tiedot ladataan.

Määritystoiminto leimaa kunkin Delta-taulukon aikaleiman/version semanttisiin mallitaulukoihin. Kun semanttisen mallin täytyy tässä vaiheessa ladata tiedot Delta-taulukosta, uusimpaan kehystoimintoon liittyvää aikaleimaa/versiota käytetään sen määrittämiseen, mitä tietoja ladataan. Kaikki myöhemmät tietojen muutokset, jotka tehdään Delta-taulukolle viimeisimmän määritystoiminnon jälkeen, ohitetaan (seuraavaan kehystoimintoon asti).

Tärkeä

Koska kehystetty semanttinen malli viittaa tiettyyn Delta-taulukkoversioon, lähteen on varmistettava, että Delta-taulukkoversio säilytetään, kunnes uusi versio on valmis. Muussa tapauksessa käyttäjät voivat kohdata virheitä, kun Delta-taulukon tiedostoja on käytettävä mallissa ja tuottajan kuormitus on poistanut ne tai poistanut ne.

Lisätietoja kehyksestä on direct lake -yleiskatsauksessa.

Taulukon osiointi

Delta-taulukot voidaan osioida niin, että rivien alijoukko tallennetaan yhteen Parquet-tiedostojen joukkoon. Osiot voivat nopeuttaa kyselyitä ja kirjoitustoimintoja.

Otetaan esimerkiksi Delta-taulukko, jossa on miljardi riviä kahden vuoden myyntitietoja. Vaikka kaikki tiedot voidaan tallentaa yhteen Parquet-tiedostojen joukkoon, tämä tietomäärä ei ole optimaalinen luku- ja kirjoitustoiminnoille. Sen sijaan suorituskykyä voidaan parantaa levittämällä miljardeja tietorivejä useissa Parquet-tiedostosarjoissa.

Osion avain on määritettävä määritettäessä taulukon osiointia. Osion avain määrittää, mitkä rivit tallennetaan mihinkin sarjaan. Delta-taulukoilla osion avain voidaan määrittää määritetyn sarakkeen (tai sarakkeiden) erillisten arvojen, kuten päivämäärätaulukon kuukausi/vuosi-sarakkeen, perusteella. Tässä tapauksessa kahden vuoden tiedot jaettaisiin 24 osioon (2 vuotta x 12 kuukautta).

Fabric-laskentamoduulit eivät tiedä taulukon osioista. Kun lisäät uusia osion avainarvoja, uudet osiot luodaan automaattisesti. OneLakessa on yksi alikansio kullekin yksilöivälle osion avainarvolle, ja kukin alikansio tallentaa oman Parquet-tiedostojen ja linkkitiedostojen joukon. Vähintään yksi Parquet-tiedosto ja yksi linkkitiedosto on oltava olemassa, mutta jokaisen alikansion tiedostojen todellinen määrä voi vaihdella. Kun tietojen muokkaustoimintoja tehdään, kukin osio ylläpitää omaa Parquet-tiedostojen ja linkkitiedostojen joukkoa seuratakseen, mitä palautetaan tietylle aikaleimalle tai versiolle.

Jos osioidyn Delta-taulukon kysely suodatetaan vain myyntitietojen viimeisimpään kolmeen kuukauteen, parquet-tiedostojen ja linkitetiedostojen, joita on käytettävä, alijoukko voidaan tunnistaa nopeasti. Näin voit ohittaa useita Parquet-tiedostoja kokonaan, mikä parantaa lukemisen suorituskykyä.

Kyselyt, jotka eivät suodata osion avainta, eivät välttämättä aina toimi paremmin. Näin voi olla, kun Delta-taulukko tallentaa kaikki tiedot yhteen suureen Parquet-tiedostojoukkoon ja tiedosto- tai riviryhmä on pirstoutunut. Vaikka tietojen noutaminen useista Parquet-tiedostoista on mahdollista rinnakkaistaa useiden klusterisolmujen välillä, monet pienet Parquet-tiedostot voivat vaikuttaa haitallisesti tiedostoon I/O ja siten kyselyn suorituskykyyn. Tästä syystä on parasta välttää Delta-taulukoiden osiointia useimmissa tapauksissa, ellei kirjoitustoiminnot tai poimi, muunna ja lataa (ETL) hyötyisi siitä selvästi.

Ositamisen edut lisäävät, päivittävät ja poistavat toimintoja, koska tiedostotoiminto tapahtuu vain alikansioissa, jotka vastaavat muokattujen tai poistettujen rivien osion avainta. Jos esimerkiksi tietoerä lisätään osioituun Delta-taulukkoon, tietoja arvioidaan sen määrittämiseksi, mitä osion avainarvoja erässä on. Tiedot ohjataan sitten vain soveltuviin osioiden kansioihin.

Kun ymmärrät, miten Delta-taulukot käyttävät osioita, voit suunnitella optimaalisia ETL-skenaarioita, jotka vähentävät suurten Delta-taulukoiden päivittämiseen käytettäviä kirjoitustoimintoja. Kirjoitustehoa parannetaan vähentämällä luotavien uusien Parquet-tiedostojen määrää ja kokoa. Jos kyseessä on kuukauden/vuoden mukaan ositettu suuri Delta-taulukko, uudet tiedot lisäävät vain uudet Parquet-tiedostot uusimpaan osioon. Edellisten kalenterikuukausien alikansiot eivät ole koskemattomia. Jos jotakin edellisten kalenterikuukausien tietoja on muokattava, vain asiaan liittyvät osiokansiot saavat uudet osio- ja linkkitiedostot.

Tärkeä

Jos Delta-taulukon päätarkoitus on semanttisten mallien (ja muiden kyselykuormitusten) tietolähteenä, on yleensä parempi välttää osiointia mieluummin sarakkeiden lataamisen optimoimiseksi muistiin.

Semanttisissa Direct Lake -malleissa tai SQL-analytiikan päätepisteessä paras tapa optimoida Delta-taulukon osiot on antaa Fabricin hallita automaattisesti Parquet-tiedostoja kullekin Delta-taulukon versiolle. Kun jätät hallinnan Fabric-käyttöön, kyselyn suorituskyvyn tulisi olla hyvä rinnakkaisuus, mutta se ei välttämättä tarjoa parasta kirjoitustehoa.

Jos sinun on optimoitava kirjoitustoiminnot, harkitse osioiden käyttöä, jotta voit optimoida kirjoitustoimintoja Delta-taulukoihin osion avaimen perusteella. Ota kuitenkin huomioon, että Delta-taulukon osiointi voi heikentää lukemisen suorituskykyä. Tästä syystä suosittelemme, että testaat luku- ja kirjoitustoiminnot huolellisesti luomalla useita kopioita samasta Delta-taulukosta eri kokoonpanoilla aikalukujen vertailemiseksi.

Varoitus

Jos osioit suuren kardinaliteetin sarakkeen, se voi aiheuttaa liikaa parquet-tiedostoja. Huomaa, että jokaisessa Fabric-kapasiteetin luvasta on suojakaiteita. Jos Delta-taulukon Parquet-tiedostojen määrä ylittää varastointiyksikkösi rajan, kyselyt palataan DirectQueryyn, mikä voi hidastaa kyselyn suorituskykyä.

Jäsennä tiedostot

Delta-taulukon pohjana oleva tallennustila on vähintään yksi Parquet-tiedosto. Parquet-tiedostomuotoa käytetään yleensä kerran kirjoitetuissa ja luku-moneen-sovelluksissa . Uusia parquet-tiedostoja luodaan aina, kun Delta-taulukon tietoja muokataan joko lisäys-, päivitys- tai poistotoiminnolla.

Muistiinpano

Voit käyttää Delta-taulukoihin liittyviä Parquet-tiedostoja työkalun, kuten OneLake-tiedostonhallinnan, avulla. Tiedostoja voi ladata, kopioida tai siirtää muihin kohteisiin yhtä helposti kuin muiden tiedostojen siirtäminen. Parquet-tiedostojen ja JSON-pohjaisten linkkitiedostojen yhdistelmän avulla laskentamoduulit voivat kuitenkin tehdä tiedostoja vastaan kyselyjä Delta-taulukkona.

Parquet-tiedoston muoto

Parquet-tiedoston sisäinen muoto eroaa muista yleisistä tietojen tallennusmuodoista, kuten CSV, TSV, XMLA ja JSON. Nämä muodot järjestävät tiedot rivien mukaan, kun taas Parquet järjestää tiedot sarakkeiden mukaan. Lisäksi Parquet-tiedostomuoto eroaa näistä muodoista, koska se järjestää tietorivit vähintään yhteen riviryhmään.

Power BI:n semanttisen mallin sisäinen tietorakenne on sarakepohjainen, mikä tarkoittaa, että Parquet-tiedostoilla on paljon yhteistä Power BI:n kanssa. Tämä samankaltaisuus tarkoittaa sitä, että semanttinen Direct Lake -malli voi tehokkaasti ladata tietoja Parquet-tiedostoista suoraan muistiin. Itse asiassa erittäin suuret tietomäärät voidaan ladata muutamassa sekunnissa. Verrata tätä ominaisuutta tuontisen semanttisen mallin päivitykseen, jonka on noudettava lohkoja tai lähdetietoja, käsiteltävä, koodattava, talletettava ja ladattava sitten muistiin. Semanttisen tuontimallin päivitystoiminto voi myös kuluttaa merkittävästi käsittelymääriä (muistia ja suoritinta) ja sen suorittamiseen kuluu paljon aikaa. Delta-taulukoilla kuitenkin suurin osa pyrkimyksistä valmistaa semanttiseen malliin suoraan lataamiseen soveltuvat tiedot tehdään, kun Parquet-tiedosto luodaan.

Tietojen tallentaminen Parquet-tiedostoihin

Tarkastele seuraavaa tietojoukkoa.

Päivämäärä Tuotetunnus StockOnHand
2024-09-16 A 10
2024-09-16 B 11
2024-09-17 A 13
…

Kun tämä tietojoukko tallennetaan Parquet-tiedostomuodossa, se saattaa näyttää seuraavalta.

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

Tiedot pakataan korvaamalla hakemistoavaimet yleisille arvoille ja käyttämällä suorituksen pituista koodausta (RLE). RLE pyrkii pakkaamaan samojen arvojen sarjan pienemmäksi esitykseksi. Seuraavassa esimerkissä otsikossa luodaan numeeristen avainten ja arvojen hakemisto, ja tietoarvojen sijaan käytetään pienempiä avainarvoja.

Header:
    Dictionary: [
        (1, 2024-09-16), (2, 2024-09-17),
        (3, A), (4, B),
        (5, 10), (6, 11), (7, 13)
        …
    ]
RowGroup1:
    Date: 1, 1, 2…
    ProductID: 3, 4, 3…
    StockOnHand: 5, 6, 7…
Footer:

Kun semanttinen Direct Lake -malli tarvitsee tietoja laskeakseen sarakkeen summan StockOnHand ryhmiteltynä :n mukaan ProductID, vaaditaan vain sanasto ja kahteen sarakkeeseen liittyvät tiedot. Suurissa tiedostoissa, jotka sisältävät useita sarakkeita, merkittävät osat Parquet-tiedostosta voidaan ohittaa lukuprosessin nopeuttamiseksi.

Muistiinpano

Parquet-tiedoston sisältö ei ole ihmisen luettavissa, joten se ei sovellu avattavaksi tekstieditorissa. Saatavilla on kuitenkin monia avoimen lähdekoodin työkaluja, jotka voivat avata ja paljastaa Parquet-tiedoston sisällön. Näiden työkalujen avulla voit myös tarkastaa metatiedot, kuten tiedoston sisältämien rivien ja riviryhmien määrän.

V-järjestys

Fabric tukee V-Order-nimistä lisäoptimointia. V-Order on Parquet-tiedostomuotoon kirjoitusajan optimointi. Kun V-Order on käytössä, se tuottaa pienemmän ja siten nopeamman tiedoston luettavaksi. Tämä optimointi on erityisen tärkeää semanttisen Direct Lake -mallin kannalta, koska se valmistelee tiedot muistiin lataamista varten nopeasti ja vähentää kapasiteettiresurssien vaatimuksia. Se myös nopeuttaa kyselyn suorituskykyä, koska muistia on skannattava vähemmän.

Fabric-kohteiden, kuten tietoputkien, tietovoiden ja muistikirjojen, luomat ja lataamat Delta-taulukot käyttävät automaattisesti V-Orderia. Tämä optimointi ei ehkä kuitenkaan ole käytössä Fabric Lakehouseen ladatuissa Parquet-tiedostoissa, joihin pikakuvake viittaa. Vaikka optimoimattomia Parquet-tiedostoja voidaan yhä lukea, lukukyky ei todennäköisesti ole yhtä nopea kuin vastaava Parquet-tiedosto, jossa V-tilaus on käytössä.

Muistiinpano

Parquet-tiedostot, joissa käytetään V-järjestystä, ovat edelleen avoimen lähdekoodin Parquet-tiedostomuodon mukaisia. Siksi ne voidaan lukea muilla kuin Fabric-työkaluilla.

Lisätietoja on kohdassa Delta Lake -taulukon optimointi ja V-järjestys.

Delta-taulukon optimointi

Tässä osiossa kuvataan useita aiheita Delta-taulukoiden optimointiin semanttisille malleille.

Tietojen määrä

Vaikka Delta-taulukot voivat kasvaa tallentamaan erittäin suuria tietomääriä, Fabric-kapasiteetin suojakaiteet asettavat niille semanttisille malleille rajoituksia, jotka kyselevät niitä. Kun nämä rajat ylitetään, kyselyt palataan DirectQueryyn, mikä voi hidastaa kyselyn suorituskykyä.

Harkitse siis suuren faktataulukon rivimäärän rajoittamista lisäämällä sen askelväliä (tallenna yhteenvedetyt tiedot), vähentämällä dimensiota tai tallentamalla vähemmän historiaa.

Varmista myös, että V-Order on käytössä, koska se tuottaa pienemmän ja siten nopeamman tiedoston luettavaksi.

Sarakkeen tietotyyppi

Pyri pienentämään kardinaliteettia (yksilöllisten arvojen määrää) kunkin Delta-taulukon jokaisessa sarakkeessa. Tämä johtuu siitä, että kaikki sarakkeet pakataan ja tallennetaan hajautuskoodauksen avulla. Hajautuskoodaus edellyttää V-Order-optimointia numeerisen tunnisteen määrittämiseksi kullekin sarakkeen sisältämälle yksilöivälle arvolle. Kyseessä on numeerinen tunniste, joka on tallennettu ja joka edellyttää hajautusarvon hakua tallennuksen ja kyselyn aikana.

Kun käytät likimääräisiä numeerisia tietotyyppejä (kuten liukulukua ja reaalilukua), harkitse arvojen pyöristämistä ja pienemmän tarkkuuden käyttämistä.

Tarpeettomat sarakkeet

Kuten minkä tahansa tietotaulukon kohdalla, Delta-taulukoiden tulee tallentaa vain pakolliset sarakkeet. Tämän artikkelin kontekstissa tämä tarkoittaa semanttisen mallin edellyttämää, vaikka muut analytiikkakuormitukset voivat tehdä kyselyn Delta-taulukoille.

Delta-taulukoissa tulee olla sarakkeita, joita semanttinen malli vaatii suodatusta, ryhmittelyä, lajittelua ja yhteenvetoa varten, malliyhteyksiä tukevien sarakkeiden lisäksi. Vaikka tarpeettomat sarakkeet eivät vaikuta semanttisen mallin kyselyn suorituskykyyn (koska niitä ei ladata muistiin), ne aiheuttavat suuremman tallennuskoon ja vaativat siksi enemmän käsittelyresursseja lataamiseen ja ylläpitoon.

Koska semanttiset Direct Lake -mallit eivät tue laskettuja sarakkeita, tällaiset sarakkeet tulee muodostaa Delta-taulukoissa. Ota huomioon, että tämä rakennemenetelmä on semanttisten Tuonti- ja DirectQuery-mallien anti-pattern. Jos sinulla on FirstName esimerkiksi ja LastName sarakkeita ja tarvitset sarakkeen FullName , muodosta tämän sarakkeen arvot, kun lisäät rivejä Delta-taulukkoon.

Ota huomioon, että jotkin semanttiset malliyhteenvedot saattavat olla riippuvaisia useammasta kuin yhdestä sarakkeesta. Jos haluat esimerkiksi laskea myynnin, mallin mittari laskee kahden sarakkeen summan: Quantity ja Price. Jos kumpaakaan näistä sarakkeista ei käytetä itsenäisesti, olisi tehokkaampaa muodostaa myynnin laskutoimitus yhtenä sarakkeena kuin tallentaa sen komponenttiarvot erillisiin sarakkeisiin.

Riviryhmän koko

Sisäisesti Parquet-tiedosto järjestää tietorivit useiksi riviryhmiksi kussakin tiedostossa. Esimerkiksi Parquet-tiedosto, joka sisältää 30 000 riviä, voi osittua ne kolmeksi riviryhmäksi, joilla kullakin on 10 000 riviä.

Riviryhmän rivien määrä vaikuttaa siihen, miten nopeasti Direct Lake voi lukea tietoja. Jos rivien määrää on vähemmän, suurempi määrä riviryhmiä vaikuttaa todennäköisesti negatiivisesti saraketietojen lataamiseen semanttiseen malliin liiallisen I/O-arvon vuoksi.

Emme yleensä suosittele riviryhmän oletuskoon muuttamista. Voit kuitenkin harkita suurten Delta-taulukoiden riviryhmän koon muuttamista. Muista testata luku- ja kirjoitussuorituskyky huolellisesti luomalla useita kopioita samoista Delta-taulukoista, joilla on eri kokoonpanot ajoitusten vertailemiseksi.

Tärkeä

Huomaa, että jokaisessa Fabric-kapasiteetin luvasta on suojakaiteita. Jos Delta-taulukon riviryhmien määrä ylittää SKU:n rajan, kyselyt palataan DirectQueryyn, mikä voi hidastaa kyselyn suorituskykyä.

Delta-taulukoiden ylläpito

Ajan mittaan, kun kirjoitustoimintoja tehdään, Delta-taulukkoversiot kerääntyvät. Saatat lopulta saavuttaa pisteen, jossa lukimisen suorituskykyyn kohdistuva negatiivinen vaikutus tulee tuntuvaksi. Mikä pahinta, jos parquet-tiedostojen määrä per taulukko tai riviryhmä per taulukko tai taulukon rivien määrä ylittää kapasiteettisi suojakaiteet, kyselyt palataan DirectQueryyn, mikä voi hidastaa kyselyn suorituskykyä. Siksi on tärkeää, että ylläpidät Delta-taulukoita säännöllisesti.

OPTIMOI

OPTIMIZE-toiminnolla voit optimoida Delta-taulukon yhdistääksesi pienempiä tiedostoja suuremmiksi. Voit myös määrittää lausekkeen WHERE kohdistamaan vain suodatetun alijoukon riveistä, jotka vastaavat tiettyä osion predikaattia. Vain osion avaimiin liittyviä suodattimia tuetaan. Komentoa OPTIMIZE voidaan käyttää myös V-Order-järjestykseen kompaktien kohteiden pienentämiseksi ja Parquet-tiedostojen uudelleenkirjoittamiseksi.

Suosittelemme, että suoritat tämän komennon säännöllisesti suurissa, usein päivitetyissä Delta-taulukoissa, ehkä joka päivä, kun ETL-prosessisi valmistuu. Tasapainota kompromissi kyselyn suorituskyvyn ja taulukon optimoinnin edellyttämien resurssien käytön kustannusten välillä.

IMUROIDA

VACUUM-määrityksen avulla voit poistaa tiedostot, joihin ei enää viitata ja/tai jotka ovat asetettua säilytyskynnystä vanhempia. Aseta asianmukainen säilytysaika, muuten et ehkä menetä aikamatkaa takaisin runkoa vanhempaan versioon, joka on leimattu semanttisiin mallitaulukoihin.

Tärkeä

Koska kehystetty semanttinen malli viittaa tiettyyn Delta-taulukkoversioon, lähteen on varmistettava, että Delta-taulukkoversio säilytetään, kunnes uusi versio on valmis. Muussa tapauksessa käyttäjät voivat kohdata virheitä, kun Delta-taulukon tiedostoja on käytettävä mallissa ja tuottajan kuormitus on poistanut ne tai poistanut ne.

JÄRJESTÄ TAULUKKO UUDELLEEN

REORG TABLE -toiminnolla voit järjestää Delta-taulukon uudelleen kirjoittamalla tiedostot uudelleen, jolloin pehmeästi poistetut tiedot poistetaan, esimerkiksi kun pudotat sarakkeen käyttämällä ALTER TABLE DROP COLUMN -toimintoa.

Taulukon ylläpidon automatisoiminen

Voit automatisoida taulukkojen ylläpitotoimia Lakehouse-ohjelmointirajapinnalla. Lisätietoja on kohdassa Lakehousen hallinta Microsoft Fabric REST -ohjelmointirajapinnan avulla.

Vihje

Voit myös käyttää Fabric-portaalin Lakehouse Table -ylläpitotoimintoa Delta-taulukoiden hallinnan yksinkertaistamiseen.

Liittyvä sisältö