Delen via

Prestatierichtlijnen in Fabric Data Warehouse

Van toepassing op:✅ Warehouse in Microsoft Fabric

Dit artikel bevat aanbevolen procedures voor gegevensopname, tabelbeheer, gegevensvoorbereiding, statistieken en query's in magazijnen en SQL-analyse-eindpunten. Prestaties afstemmen en optimaliseren kunnen unieke uitdagingen opleveren, maar ze bieden ook waardevolle mogelijkheden om de mogelijkheden van uw gegevensoplossingen te maximaliseren.

Zie Monitor Fabric Data warehouse om de prestaties van uw magazijn te bewaken.

Optimalisatie van gegevenstypen

Het kiezen van de juiste gegevenstypen is essentieel voor prestaties en opslagefficiëntie in uw magazijn. De volgende richtlijnen helpen ervoor te zorgen dat uw schemaontwerp snelle query's, efficiënte opslag en onderhoudbaarheid ondersteunt.

Zie Gegevenstypen in Fabric Data Warehouse voor meer informatie over gegevenstypen die worden ondersteund door Fabric Data Warehouse.

Aanbeveling

Als u externe hulpprogramma's gebruikt om tabellen of query's te genereren, zoals met een methodologie voor de implementatie van code-first, controleert u de kolomgegevenstypen zorgvuldig. Lengten en query's van tekengegevenstypen moeten deze aanbevolen procedures volgen.

Gegevenstypen koppelen aan gegevenssemantiek

Om zowel duidelijkheid als prestaties te garanderen, is het belangrijk om het gegevenstype van elke kolom af te stemmen op de werkelijke aard en het gedrag van de gegevens die worden opgeslagen.

  • Gebruik datum, tijd of datum/tijd2(n) voor tijdelijke waarden in plaats van ze op te slaan als tekenreeksen.
  • Gebruik gehele getallen voor numerieke waarden, tenzij opmaak (bijvoorbeeld voorloopnullen) vereist is.
  • Gebruik tekentypen (teken, varchar) wanneer het behouden van opmaak essentieel is (bijvoorbeeld getallen die kunnen beginnen met nul, productcodes, getallen met streepjes).

Gebruik hele getaltypen voor gehele getallen

Bij het opslaan van waarden zoals id's, tellers of andere gehele getallen geeft u de voorkeur aan gehele getallen (smallint, int, bigint) boven decimale/numerieke waarden. Voor gehele getallen is minder opslag vereist dan gegevenstypen die cijfers rechts van het decimaalteken toestaan. Hierdoor kunnen sneller rekenkundige en vergelijkingsbewerkingen worden uitgevoerd en de indexering en queryprestaties worden verbeterd.

Houd rekening met de waardebereiken voor elk gegevenstype dat door Fabric Data Warehouse wordt ondersteund. Voor meer informatie, int, bigint, smallint (Transact-SQL).

Overweeg het gebruik van decimale en numerieke precisie en schaal

Als u decimale/numerieke waarden moet gebruiken, kiest u bij het maken van de kolom de kleinste precisie en schaal die geschikt is voor uw gegevens. De precisie van overinrichting verhoogt de opslagvereisten en kan de prestaties verslechteren naarmate de hoeveelheid gegevens toeneemt.

  • Verwacht de verwachte groei en behoeften van uw magazijn. Als u bijvoorbeeld niet meer dan vier cijfers rechts van het decimaalteken wilt opslaan, gebruikt u decimaal(9;4) of decimaal(19;4) voor de meest efficiënte opslag.
  • Geef altijd precisie en schaal op bij het maken van een decimale numerieke/ kolom. Wanneer u een tabel maakt die is gedefinieerd als alleen decimal, zonder (p,s) op te geven voor precisie en schaal, wordt een decimaal/ numerieke kolom gemaakt als decimal(18,0). Een decimaal met een precisie van 18 verbruikt 9 bytes opslagruimte per rij. Bij een schaal van 0 worden er geen gegevens opgeslagen achter de komma. Voor veel bedrijfsmatige gehele getallen, smallint, int, bigint zijn veel efficiënter dan decimal(18,0). Een geheel getal van negen cijfers kan bijvoorbeeld worden opgeslagen als een geheel getal voor 4 bytes opslagruimte per rij.

Zie decimaal en numeriek (Transact-SQL) voor volledige informatie.

Overweeg wanneer varchar boven char te gebruiken

Gebruik varchar(n) in plaats van char(n) voor tekenreekskolommen, tenzij opvulling met vaste lengte expliciet is vereist. In een varchar-kolom wordt alleen de werkelijke tekenreekslengte per rij opgeslagen, plus een kleine overhead, en wordt er minder ruimte verspild, waardoor de I/O-efficiëntie wordt verbeterd.

  • Gebruik varchar(n) voor waarden zoals namen, adressen en beschrijvingen, omdat ze veel variabele waarden hebben. Statistieken en schatting van querykosten zijn nauwkeuriger wanneer de lengte van het gegevenstype nauwkeuriger is voor de werkelijke gegevens.
  • Gebruik char(n) wanneer u weet dat de tekenreeks elke keer een vaste lengte heeft. Het opslaan van de tekenreeks als een teken (9) is bijvoorbeeld zinvol als de tekenreeks 000000000 altijd exact 9 numerieke tekens is die met een nul kunnen beginnen.
  • De lengte n in de declaratie van het kolomgegevenstype is de opslagbytes. Voor tekensets met meerderebyte-codering, zoals UTF-8, neemt de codering voor Fabric Data Warehouse, Latijnse tekens en cijfers 1 byte aan opslag in beslag. Er zijn echter Unicode-tekens waarvoor meer dan 1 byte is vereist, zoals Japanse tekens waarvoor 3 bytes nodig zijn om op te slaan, zodat het aantal Unicode-tekens dat daadwerkelijk is opgeslagen, kleiner kan zijn dan de lengte nvan het gegevenstype. Zie char- en varchar-argumenten voor meer informatie.

Vermijd waar mogelijk null-kolommen

Definieer kolommen als NOT NULL wanneer het gegevensmodel toestaat. Standaard staat een kolom in een tabel waarden toe NULL . Kolommen met Null-waarden hebben de volgende kenmerken:

  • Ze voegen overhead voor metagegevens toe.
  • Kan de effectiviteit van queryoptimalisaties en statistieken verminderen.
  • Dit kan van invloed zijn op de prestaties in grootschalige analytische query's.

Gegevensopname en voorbereiding in een magazijn

KOPIEER NAAR

De T-SQL COPY INTO-opdracht is de aanbevolen manier voor het opnemen van gegevens uit Azure Data Lake Storage in Fabric Data Warehouse. Zie Gegevens opnemen in uw magazijn met behulp van de COPY-instructie voor meer informatie en voorbeelden.

Houd rekening met de volgende aanbevelingen voor de beste prestaties:

  • Bestandsgrootte: Zorg ervoor dat elk bestand dat u opneemt, ideaal is tussen 100 MB en 1 GB voor gemaximaliseerde doorvoer. Dit helpt bij het optimaliseren van het opnameproces en het verbeteren van de prestaties.
  • Aantal bestanden: Als u parallelle uitvoering en queryprestaties wilt maximaliseren, wilt u een groot aantal bestanden genereren. Geef prioriteit aan het maken van zoveel mogelijk bestanden terwijl u een minimale bestandsgrootte van 100 MB behoudt.
  • Parallel laden: Gebruik meerdere COPY INTO instructies die parallel worden uitgevoerd om gegevens in verschillende tabellen te laden. Deze benadering kan ETL/ELT-venster aanzienlijk verminderen vanwege parallelle uitvoering.
  • Capaciteitsgrootte: Voor grotere gegevensvolumes kunt u overwegen om uit te schalen naar grotere infrastructuurcapaciteit om de extra rekenresources te verkrijgen die nodig zijn voor extra aantal parallelle verwerking en grotere gegevensvolumes.

Fabric Data Warehouse biedt ook ondersteuning voor BULK INSERT-instructies die synoniem staan aan COPY INTO. Dezelfde aanbeveling is van toepassing op BULK INSERT instructie.

CTAS of INSERT

Gebruik CREATE TABLE AS SELECT (CTAS) of INSERT gecombineerd met SELECT FROM commando's voor Lakehouse-tabellen en snelkoppelingen. Deze methoden kunnen efficiënter en efficiënter zijn dan het gebruik van pijplijnen, waardoor snellere en betrouwbaardere gegevensoverdracht mogelijk is. Zie Gegevens opnemen in uw warehouse met behulp van Transact-SQL voor meer informatie en voorbeelden.

Het concept van het verhogen van parallelisme en schaalbaarheid naar grotere Fabriccapaciteit is ook van toepassing op CTAS-/INSERT-bewerkingen om de doorvoer te verhogen.

Gegevens lezen uit Azure Data Lake Storage of Blob Storage met OPENROWSET

Met de functie OPENROWSET kunt u CSV- of Parquet-bestanden lezen uit Azure Data Lake of Azure Blob Storage, zonder deze op te nemen in Warehouse. Zie Bladeren in bestandsinhoud met de functie OPENROWSET voor meer informatie en voorbeelden.

Houd bij het lezen van gegevens met de functie OPENROWSET rekening met de volgende aanbevelingen voor de beste prestaties:

  • Parket: Gebruik Parquet in plaats van CSV of converteer CSV naar Parquet als u regelmatig query's uitvoert op de bestanden. Parquet is een kolomindeling. Omdat gegevens worden gecomprimeerd, zijn de bestandsgrootten kleiner dan CSV-bestanden die dezelfde gegevens bevatten. Fabric Data Warehouse slaat de kolommen en rijen over die niet nodig zijn in een query als u Parquet-bestanden leest.
  • Bestandsgrootte: Zorg ervoor dat elk bestand dat u opneemt, ideaal is tussen 100 MB en 1 GB voor gemaximaliseerde doorvoer. Dit helpt bij het optimaliseren van het opnameproces en het verbeteren van de prestaties. Het is beter om bestanden met gelijke grootte te hebben.
  • Aantal bestanden: Als u parallelle uitvoering en queryprestaties wilt maximaliseren, wilt u een groot aantal bestanden genereren. Geef prioriteit aan het maken van zoveel mogelijk bestanden terwijl u een minimale bestandsgrootte van 100 MB behoudt.
  • Verdelen: Partitioneer uw gegevens door partities op te slaan in verschillende mappen of bestandsnamen als uw workload ze filtert op partitiekolommen.
  • Schatting: Probeer zo in te stellen ROWS_PER_BATCH dat het aantal rijen in de onderliggende bestanden overeenkomt als u denkt dat u niet de verwachte prestaties krijgt.
  • Capaciteitsgrootte: Voor grotere gegevensvolumes kunt u overwegen om uit te schalen naar een grotere SKU om meer rekenresources te krijgen die nodig zijn voor extra aantal parallelle verwerkingen en grotere gegevensvolumes.

Vermijd invoegingen, updates en verwijderingen in een trickle

Om een efficiënte bestandsindeling en optimale queryprestaties in Fabric Data Warehouse te garanderen, vermijdt u het gebruik van veel kleine INSERT, UPDATEen DELETE transacties. Deze wijzigingen op rijniveau genereren een nieuw Parquet-bestand voor elke bewerking, wat resulteert in een groot aantal kleine bestanden en gefragmenteerde rijgroepen. Deze fragmentatie leidt tot:

  • Verhoogde querylatentie vanwege inefficiënt scannen van bestanden.
  • Hogere opslag- en rekenkosten.
  • Grotere afhankelijkheid van compressieprocessen op de achtergrond.

Aanbevolen benaderingen:

  • Batchtransacties die schrijven naar Fabric Data Warehouse.
    • In plaats van veel kleine INSERT instructies kunt u bijvoorbeeld gegevens vooraf fasen en gegevens in één INSERT instructie invoegen.
  • Gebruik COPY INTO voor bulkinvoegingen en het uitvoeren van updates en verwijderingen in batches, indien mogelijk.
  • Behoud een minimale geïmporteerde bestandsgrootte van 100 MB om efficiënte rijgroepvorming te garanderen.
  • Zie Best practices voor het opnemen van gegevens in een magazijn voor meer richtlijnen en aanbevolen procedures voor het opnemen van gegevens.

Gegevenscompressie

In Fabric Data Warehouse is het comprimeren van gegevens een achtergrondoptimalisatieproces in Fabric Data Warehouse waarmee kleine, inefficiënte Parquet-bestanden worden samengevoegd tot minder, grotere bestanden. Vaak worden deze bestanden gemaakt door frequente trickle INSERT, UPDATEof DELETE bewerkingen. Gegevenscompressie vermindert bestandsfragmentatie, verbetert de efficiëntie van rijgroepen en verbetert de algehele queryprestaties.

Hoewel de Fabric Data Warehouse-engine automatisch fragmentatie in de loop van de tijd oplost door gegevenscompressie, kunnen de prestaties afnemen totdat het proces is voltooid. Gegevenscompressie wordt automatisch uitgevoerd zonder tussenkomst van de gebruiker voor Fabric Data Warehouse.

Gegevenscompressie is niet van toepassing op lakehouse. Voor Lakehouse-tabellen die worden geopend via SQL Analytics-eindpunten, is het belangrijk om de aanbevolen procedures van Lakehouse te volgen en de opdracht OPTIMIZE handmatig uit te voeren nadat belangrijke gegevenswijzigingen zijn aangebracht om de optimale opslagindeling te behouden.

V-Order in Fabric Data Warehouse

V-Order is een optimalisatie van schrijftijd voor de Parquet-bestandsindeling die snelle leesbewerkingen in de Microsoft Fabric mogelijk maakt. V-Order in Fabric Data Warehouse verbetert de queryprestaties door sortering en compressie toe te passen op tabelbestanden.

V-Order is standaard ingeschakeld voor alle magazijnen om ervoor te zorgen dat leesbewerkingen, met name analytische query's, zo snel en efficiënt mogelijk zijn.

V-Order introduceert echter een kleine invoeroverhead, die merkbaar is in schrijfintensieve workloads. Daarom moet het uitschakelen van V-Order alleen worden overwogen voor magazijnen die strikt schrijfintensief zijn en niet worden gebruikt voor frequente query's. Het is belangrijk om te weten dat nadat V-Order is uitgeschakeld in een magazijn, deze niet opnieuw kan worden ingeschakeld.

Voordat gebruikers besluiten om V-Order uit te schakelen, moeten ze hun workloadprestaties grondig testen om ervoor te zorgen dat de afweging gerechtvaardigd is. Een veelvoorkomend patroon is het gebruik van een faseringswarehouse waarbij V-Order is uitgeschakeld voor opname met hoge doorvoer, gegevenstransformatie en het opnemen van de onderliggende gegevens in een datawarehouse met V-volgorde voor betere leesprestaties. Zie V-order uitschakelen in Magazijn in Microsoft Fabric voor meer informatie.

Tabellen klonen in plaats van tabellen te kopiëren

Tabelklonen in Fabric Data Warehouse bieden een snelle en efficiënte manier om tabellen te maken zonder gegevens te kopiëren. Met een zero-copy kloning worden alleen de metagegevens van de tabel gedupliceerd, terwijl er rechtstreeks naar de onderliggende gegevensbestanden in OneLake wordt verwezen. Hierdoor kunnen gebruikers vrijwel onmiddellijk consistente, betrouwbare tabelkopieën maken, zonder de overhead van volledige gegevensduplicatie.

Klonen met nulkopie zijn ideaal voor scenario's zoals ontwikkeling, testen en back-ups, die een krachtige, opslagefficiënte oplossing bieden waarmee de infrastructuurkosten worden verlaagd.

  • Gekloonde tabellen kopiëren ook alle belangrijke beveiligingsfuncties van de bron, waaronder Row-Level Security (RLS), Column-Level Security (CLS) en DDM (Dynamic Data Masking), zonder dat u beleid opnieuw hoeft toe te dienen na het klonen.
  • Klonen kunnen worden gemaakt vanaf een specifiek tijdstip binnen de gegevensretentieperiode, met ondersteuning voor mogelijkheden voor tijdreizen.
  • Gekloonde tabellen bestaan onafhankelijk van hun bron, wijzigingen in de bron hebben geen invloed op de kloon en wijzigingen in de kloon hebben geen invloed op de bron. De bron of de kloon kan onafhankelijk worden verwijderd.

Prestaties van zoekopdracht

statistieken

Statistieken zijn persistente objecten die gegevens in de kolommen van uw tabellen vertegenwoordigen. Query Optimizer maakt gebruik van statistieken om de kosten van een queryplan te kiezen en te schatten. Gebruik van het Fabric Data Warehouse- en Lakehouse SQL-analyse-eindpunt en onderhoudt automatisch histogramstatistieken, gemiddelde kolomlengtestatistieken en tabelkardinaliteitsstatistieken. Zie Statistieken in Fabric Data Warehouse voor meer informatie.

  • De T-SQL-opdrachten CREATE STATISTICS en UPDATE STATISTICS worden ondersteund voor histogramstatistieken met één kolom. U kunt deze gebruiken als er een groot genoeg venster is tussen uw tabeltransformaties en uw queryworkload, zoals tijdens een onderhoudsvenster of andere downtime. Dit vermindert de kans dat uw SELECT query's eerst statistieken moeten bijwerken.
  • Probeer een tabelschema te definiëren dat pariteit van gegevenstypen bij algemene kolomvergelijkingen onderhoudt. Als u bijvoorbeeld weet dat kolommen vaak worden vergeleken met elkaar in een WHERE component of als predicaat JOIN ... ON worden gebruikt, moet u ervoor zorgen dat de gegevenstypen overeenkomen. Als het niet mogelijk is om exact dezelfde gegevenstypen te gebruiken, gebruikt u vergelijkbare gegevenstypen die compatibel zijn voor impliciete conversie. Vermijd expliciete gegevensconversies. Zie Gegevenstypeconversievoor meer informatie.

Aanbeveling

Voor Lakehouse-gebruikers kan de ACE-Cardinality statistiek gegevens uit de Delta-logboekbestanden van uw tabellen gebruiken om nauwkeuriger te zijn. Zorg ervoor dat uw door Spark gegenereerde Delta-tabellen het aantal rijen van de tabel bevatten met: spark.conf.set("spark.databricks.delta.stats.collect", "true"). Zie Geautomatiseerde tabelstatistieken configureren en beheren in Fabric Spark voor meer informatie.

Wanneer u Lakehouse-tabellen filtert op tijdstempelkolom vóór Apache Spark Runtime 3.5.0, worden statistieken op rijgroepniveau voor tijdstempelkolommen niet gegenereerd. Dit gebrek aan statistieken maakt het moeilijk voor systemen, zoals Fabric Warehouse, om rowgroup-verwijdering toe te passen (ook wel gegevens overslaan of pushdown predicaat genoemd), wat prestatieoptimalisatie is die irrelevante rijgroepen overslaat tijdens het uitvoeren van query's. Zonder deze statistieken moeten query's met tijdstempelkolommen mogelijk meer gegevens scannen, wat leidt tot aanzienlijke prestatievermindering. U kunt de Apache Spark-runtime bijwerken in Fabric. Apache Spark 3.5.0 en hogere versies kunnen statistieken op rijgroepniveau genereren voor tijdstempelkolommen. Vervolgens moet u de tabel opnieuw maken en de gegevens opnemen om statistieken op rijgroepniveau te laten genereren.

Prestaties van koude cache

De eerste uitvoering van een query in Fabric Data Warehouse kan onverwacht langzamer zijn dan de volgende uitvoeringen. Dit wordt een koude start genoemd, veroorzaakt door systeem initialisatie- of schaalactiviteiten die de omgeving voorbereiden voor verwerking.

Koude starts treden meestal op wanneer:

  • Gegevens worden vanuit OneLake in het geheugen geladen omdat ze voor het eerst worden geopend en nog niet in de cache worden opgeslagen.
  • Als gegevens voor het eerst worden geopend, wordt de uitvoering van query's vertraagd totdat de benodigde statistieken automatisch worden gegenereerd.
  • Fabric Data Warehouse onderbreekt automatisch knooppunten na een bepaalde periode van inactiviteit om de kosten te verlagen en voegt knooppunten toe als onderdeel van automatisch schalen. Het hervatten of maken van knooppunten duurt doorgaans minder dan één seconde.

Deze bewerkingen kunnen de querytijden verhogen. Koude starten kunnen gedeeltelijk zijn. Sommige rekenknooppunten, gegevens of statistieken zijn mogelijk al beschikbaar of in de cache opgeslagen in het geheugen, terwijl de query wacht tot anderen beschikbaar zijn. Zie Caching in Fabric datawarehousing voor meer informatie.

U kunt koude starteffecten detecteren die worden veroorzaakt door het ophalen van gegevens uit externe opslag in het geheugen door een query uit te voeren op de queryinsights.exec_requests_history weergave. Controleer de data_scanned_remote_storage_mb kolom:

  • De niet-nulwaarde in data_scanned_remote_storage_mb geeft een koude start aan. Gegevens zijn opgehaald uit OneLake tijdens de uitvoering van de query. Volgende weergaven moeten duidelijk sneller zijn in queryinsights.exec_requests_history.
  • Een waarde van nul in data_scanned_remote_storage_mb is de perfecte staat waarin alle gegevens in de cache zijn opgeslagen. Er zijn geen knooppuntwijzigingen of gegevens uit OneLake nodig om de queryresultaten te leveren.

Belangrijk

Beoordeel de queryprestaties niet op basis van de eerste uitvoering. Controleer altijd data_scanned_remote_storage_mb om te bepalen of de query is beïnvloed door een koude start. Latere uitvoeringen zijn vaak aanzienlijk sneller en vertegenwoordigen de werkelijke prestaties, waardoor de gemiddelde uitvoeringstijd wordt verlaagd.

Query's op tabellen met tekstkolommen

Gebruik de kleinste lengte voor de kolom voor tekenreeksen die waarden kan bevatten. Fabric Warehouse verbetert voortdurend; U kunt echter suboptimale prestaties ervaren als u grote tekenreeksgegevenstypen gebruikt, met name grote objecten (LOBs). Voor het gegevenstype van een customer_name kolom kunt u bijvoorbeeld rekening houden met uw zakelijke vereisten en verwachte gegevens en een geschikte lengte n gebruiken bij het declareren varchar(n)van , zoals varchar(100), in plaats van varchar(8000) of varchar(max). Statistieken en schatting van querykosten zijn nauwkeuriger wanneer de lengte van het gegevenstype nauwkeuriger is voor de werkelijke gegevens.

  • Zie de richtlijnen voor het kiezen van de juiste lengte voor tekenreeksgegevenstypen in Fabric Data Warehouse T-SQL.
  • Tekenreekskolommen van Lakehouse-tabellen zonder gedefinieerde lengte in Spark worden door Fabric Warehouse herkend als varchar(8000). Voor optimale prestaties gebruikt u de instructie in SparkSQL om een CREATE TABLE tekenreekskolom te definiëren als varchar(n), waarbij n de maximale kolomlengte geschikt is voor waarden.

Transacties en gelijktijdigheid

Fabric Data Warehouse is gebouwd op een moderne, cloudeigen architectuur die transactionele integriteit, isolatie van momentopnamen en gedistribueerde rekenkracht combineert om hoge gelijktijdigheid en consistentie op schaal te bieden. Zie Transacties in magazijntabellen voor meer informatie.

Fabric Data Warehouse ondersteunt ACID-compatibele transacties met behulp van momentopname-isolatie. Dit betekent:

  • Lees- en schrijfbewerkingen kunnen worden gegroepeerd in één transactie met behulp van standaard T-SQL (BEGIN TRANSACTION, COMMIT, ROLLBACK)
  • Alles-of-niets-semantiek: als een transactie meerdere tabellen omvat en één bewerking mislukt, wordt de hele transactie teruggedraaid.
  • Leesconsistentie: SELECT query's binnen een transactie zien een consistente momentopname van de gegevens, niet beïnvloed door gelijktijdige schrijfbewerkingen.

Ondersteuning voor Fabric Warehouse-transacties:

  • DDL (Data Definition Language) binnen transacties: U kunt opnemen CREATE TABLE in een transactieblok.
  • Transacties tussen databases: Ondersteund in dezelfde werkruimte, inclusief leesbewerkingen van SQL-analyse-eindpunten.
  • Terugdraaien op basis van Parquet: Omdat Fabric Data Warehouse gegevens opslaat in onveranderbare Parquet-bestanden, is terugdraaien snel. Rollbacks draaien simpelweg naar vorige bestandsversies terug.
  • Automatische gegevenscompressie en controlepunten:gegevenscompressie optimaliseert de opslag- en leesprestaties door kleine Parquet-bestanden samen te voegen en logisch verwijderde rijen te verwijderen.
  • Automatische controlepunten: Elke schrijfbewerking (INSERT, UPDATE, DELETE) voegt een nieuw JSON-logboekbestand toe aan het Delta Lake-transactielogboek. In de loop van de tijd kan dit leiden tot honderden of duizenden logboekbestanden, met name in scenario's voor streaming of opname met hoge frequentie. Automatische controlepunten verbeteren de efficiëntie van het lezen van metagegevens door transactielogboeken samen te vatten in één controlepuntbestand. Zonder controlepunten moet elke leesbewerking de volledige geschiedenis van het transactielogboek scannen. Met controlepunten worden alleen het meest recente controlepuntbestand en de logboeken na het gelezen. Dit vermindert het parseren van I/O en metagegevens, met name voor grote of regelmatig bijgewerkte tabellen.

Zowel compactie als controlepunten zijn essentieel voor de gezondheid van de tabel, met name in langlopende of omgevingen met hoge gelijktijdigheid.

Gelijktijdigheidsbeheer en isolatie

Fabric Data Warehouse maakt uitsluitend gebruik van isolatie van momentopnamen. Pogingen om het isolatieniveau via T-SQL te wijzigen, worden genegeerd.

Beste praktijken voor transacties

  • Gebruik expliciete transacties verstandig. Altijd COMMIT of ROLLBACK. Laat transacties niet open.
    • Houd transacties met een korte levensduur. Vermijd langlopende transacties die vergrendelingen onnodig bevatten, met name voor expliciete transacties die DDLs bevatten. Dit kan conflicten veroorzaken met SELECT instructies voor systeemcatalogusweergaven (zoals sys.tables) en kan problemen veroorzaken met de Fabric-portal die afhankelijk zijn van systeemcatalogusweergaven.
  • Voeg herhalingslogica toe met vertraging in pijplijnen of apps om tijdelijke conflicten af te handelen.
    • Gebruik exponentieel uitstel om herhalingsstormen te voorkomen die tijdelijke netwerkonderbrekingen verergeren.
    • Zie Herhaalpatroon voor meer informatie.
  • Controleer vergrendelingen en conflicten in het magazijn.

De grootte van de geretourneerde gegevensset verkleinen

Query's met een grote hoeveelheid gegevens kunnen bij het uitvoeren van tussenliggende stappen of bij het produceren van het uiteindelijke queryresultaat meer prestatieproblemen ondervinden. Als u de grootte van de geretourneerde gegevensset wilt verminderen, kunt u de volgende strategieën overwegen:

  • Partitioneer grote tabellen in Lakehouse.
  • Beperk het aantal geretourneerde kolommen. SELECT * kan kostbaar zijn.
  • Beperk het aantal geretourneerde rijen. Voer zoveel mogelijk gegevensfilters uit in het magazijn, niet in clienttoepassingen.
    • Probeer te filteren voordat u deelneemt om de gegevensset vroeg in de uitvoering van de query te verminderen.
    • Filter op kolommen met een lage kardinaliteit om grote datasets vroeg te beperken vóór JOINs.
    • Kolommen met een hoge kardinaliteit zijn ideaal voor filteren en JOIN's. Deze worden vaak gebruikt in WHERE clausules en profiteren wanneer het predicaat in een eerdere fase bij het uitvoeren van query's wordt toegepast om gegevens te filteren.
  • Omdat in Fabric Data Warehouse primaire sleutel- en unieke sleutelbeperkingen niet worden afgedwongen, zijn kolommen met deze beperkingen niet noodzakelijkerwijs goede kandidaten voor JOI's.

Queryplannen en queryhints

In Fabric Data Warehouse genereert de queryoptimalisatie een queryuitvoeringsplan om de meest efficiënte manier te bepalen om een SQL-query uit te voeren. Geavanceerde gebruikers kunnen overwegen om problemen met queryprestaties te onderzoeken met het queryplan of door queryhints toe te voegen.

  • Gebruikers kunnen SHOWPLAN_XML in SQL Server Management Studio gebruiken om het plan weer te geven zonder de query uit te voeren.
  • Optionele queryhints kunnen worden toegevoegd aan een SQL-instructie om meer instructies te geven voor de queryoptimalisatie vóór het genereren van het plan. Voor het toevoegen van queryhints is geavanceerde kennis van queryworkloads vereist. Deze worden daarom meestal gebruikt nadat andere aanbevolen procedures zijn geïmplementeerd, maar het probleem blijft bestaan.

Niet-schaalbare bewerkingen

Fabric Data Warehouse is gebouwd op een MPP-architectuur (Massively Parallel Processing), waar query's worden uitgevoerd op meerdere rekenknooppunten. In sommige scenario's is uitvoering van één knooppunt gerechtvaardigd:

  • Voor de volledige uitvoering van het queryplan is slechts één rekenknooppunt vereist.
  • Een plan-substructuur kan binnen één rekenknooppunt passen.
  • De volledige query of een deel van de query moet worden uitgevoerd op één knooppunt om te voldoen aan de semantiek van de query. Bijvoorbeeld TOP bewerkingen, globale sortering, query's waarvoor sorteerresultaten van parallelle uitvoeringen nodig zijn om één resultaat te produceren of resultaten voor de laatste stap samen te voegen.

In deze gevallen kunnen gebruikers een waarschuwingsbericht 'Een of meer niet-schaalbare bewerkingen worden gedetecteerd' ontvangen en de query kan langzaam worden uitgevoerd of mislukken na een lange uitvoering.

  • Overweeg om de gefilterde gegevensset van de query te verkleinen.
  • Als voor de semantiek van de query geen uitvoering met één knooppunt is vereist, kunt u bijvoorbeeld een gedistribueerd queryplan afdwingen met FORCE DISTRIBUTED PLANOPTION (FORCE DISTRIBUTED PLAN);.

Query's uitvoeren op het SQL Analytics-eindpunt

U kunt het SQL Analytics-eindpunt gebruiken om query's uit te voeren op Lakehouse-tabellen die zijn gevuld met Spark SQL, zonder gegevens te kopiëren of op te nemen in het warehouse.

De volgende best practices zijn van toepassing op het uitvoeren van query's op magazijngegevens in Lakehouse via het SQL-analyse-eindpunt. Zie prestatieoverwegingen voor SQL Analytics-eindpunten voor meer informatie over de prestaties van SQL Analytics-eindpunten.

Aanbeveling

De volgende aanbevolen procedures zijn van toepassing op het gebruik van Spark om gegevens te verwerken in een lakehouse die kan worden opgevraagd door het SQL-analyse-eindpunt.

Regelmatig tabelonderhoud uitvoeren voor Lakehouse-tabellen

In Microsoft Fabric optimaliseert het magazijn automatisch gegevensindelingen en voert garbagecollection en compressie uit. Voor een Lakehouse hebt u meer controle over tabelonderhoud. Tabeloptimalisatie en vacuüm zijn nodig en kunnen de scantijd die nodig is voor grote gegevenssets aanzienlijk verminderen. Tabelonderhoud in Lakehouse is ook van toepassing op snelkoppelingen en kan u helpen de prestaties daar aanzienlijk te verbeteren.

Lakehouse-tabellen of snelkoppelingen optimaliseren met veel kleine bestanden

Veel kleine bestanden maken overhead voor het lezen van metagegevens van bestanden. Gebruik de opdracht OPTIMIZE in de Fabric-portal of een notebook om kleine bestanden te combineren in grotere bestanden. Herhaal dit proces wanneer het aantal bestanden aanzienlijk verandert.

Als u een tabel in een Fabric Lakehouse wilt optimaliseren, opent u het Lakehouse in de Fabric-portal. Klik in Explorer met de rechtermuisknop op de tabel en selecteer Onderhoud. Kies opties op de pagina Onderhoudsopdrachten uitvoeren en selecteer Nu uitvoeren.

Voer een query uit op tabellen of snelkoppelingen in het lakehouse in dezelfde regio

Fabric maakt gebruik van rekenkracht waar de Fabric capaciteit zich bevindt. Het opvragen van gegevens, zoals in uw eigen Azure Data Lake Storage of in OneLake, resulteert in een andere regio in prestatieoverhead vanwege netwerklatentie. Zorg ervoor dat gegevens zich in dezelfde regio bevinden. Afhankelijk van uw prestatievereisten kunt u overwegen om alleen kleine tabellen zoals dimensietabellen in een externe regio te bewaren.

Lakehouse-tabellen en snelkoppelingen filteren op dezelfde kolommen

Als u vaak tabelrijen op specifieke kolommen filtert, kunt u overwegen de tabel te partitioneren.

Partitionering werkt goed voor kolommen met lage kardinaliteit of kolommen met voorspelbare kardinaliteit, zoals jaren of datums. Zie de zelfstudie Lakehouse: Lakehouse-gegevens voorbereiden en transformeren en gegevens laden in Lakehouse met behulp van partities.

Clustering werkt goed voor kolommen met hoge selectiviteit. Als u andere kolommen hebt die u vaak gebruikt voor filteren, behalve het partitioneren van kolommen, kunt u overwegen om de tabel te clusteren met behulp van optimaliseren met de Spark SQL-syntaxis ZORDER BY. Zie Optimalisatie van Delta Lake-tabellen voor meer informatie.

Querymetagegevensweergaven

Voor meer informatie over de queryinsights weergaven, zie Query-inzichten in datawarehousing in Fabric.

Voor meer informatie over de levenscyclus van query's, zie Verbindingen, sessies en aanvragen bewaken met DMVs.

Gerelateerde inhoud